11 messages
Open this post in threaded view
|
Report Content as Inappropriate

Open this post in threaded view
|
Report Content as Inappropriate

Open this post in threaded view
|
Report Content as Inappropriate

Open this post in threaded view
|
Report Content as Inappropriate

 In reply to this post by Joe Armstrong-2 On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > I can see the equivalent evaluation of "250"<250 being a common mistake, > > and always being false is hardly useful. > A "<" B when A and B have different types means A is > "less complex" than B. Lists and more complex than integers > "250" is a list so "250"<250 is false. > Suppose I want to make a Key-Value database, where the Key can be anything, > including 250 and "250" to make any form of ordered tree we need a total > order over all the keys. Indeed.  If we can have only one built-in comparison, it needs to be total over all values.  It is a pity that Prolog's distinction between term comparison and number comparison wasn't carried over to Erlang :-(     Jeff Schultz _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate

 Indeed.  If we can have only one built-in comparison, it needs to betotal over all values.  It is a pity that Prolog's distinction betweenterm comparison and number comparison wasn't carried over to Erlang :-( Indeed that would have made the language a tad bigger, but stopped this ambiguity!Are there any other  good subtleties to erlang that anybody wishes to add to this list? I can't have covered all of them :-)also does anybody know the answer to my :> There is a 3rd parameter in the AST for a catch section in a Try/Catch that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does anybody know what this means? is there an extra option in a catch that is rarely used? James On 20 May 2011 04:45, Jeff Schultz wrote: On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > I can see the equivalent evaluation of "250"<250 being a common mistake, > > and always being false is hardly useful. > A "<" B when A and B have different types means A is > "less complex" than B. Lists and more complex than integers > "250" is a list so "250"<250 is false. > Suppose I want to make a Key-Value database, where the Key can be anything, > including 250 and "250" to make any form of ordered tree we need a total > order over all the keys. Indeed.  If we can have only one built-in comparison, it needs to be total over all values.  It is a pity that Prolog's distinction between term comparison and number comparison wasn't carried over to Erlang :-(    Jeff Schultz _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate

 On 05/20/2011 01:35 PM, James Churchman wrote: > also does anybody know the answer to my : >>  There is a 3rd parameter in the AST for a catch section in a Try/Catch > that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does > anybody know what this means? is there an extra option in a catch that > is rarely used? Yes, it's a cheap and compact encoding of the stack trace (as a bignum or binary, I don't remember). This is so that no time is wasted building a symbolic stack trace as a list of tuples that might simply get discarded as soon as the exception is caught, while making it possible to suspend an exception temporarily, drop back into Erlang code to match against a set of catch-patterns, and re-throw the whole thing again if nothing matched. If it's needed for anything, the blob will be unpacked into a symbolic trace. All in all, you're better off pretending you don't know anything about this, apart from the fact that effort has been made to keep exceptions as cheap as possible.      /Richard _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate

 Very interesting and makes a lot of sense.... i was hoping that 'better off pretending you don't know anything about this' was the case and there was not some huge set of optional extra stuff onto of a try catch! On 20 May 2011, at 13:34, Richard Carlsson wrote: > On 05/20/2011 01:35 PM, James Churchman wrote: >> also does anybody know the answer to my : >>> There is a 3rd parameter in the AST for a catch section in a Try/Catch >> that is always a match all ( a bit like ERROR_TYPE:ERROR:_ ) does >> anybody know what this means? is there an extra option in a catch that >> is rarely used? > > Yes, it's a cheap and compact encoding of the stack trace (as a bignum or binary, I don't remember). This is so that no time is wasted building a symbolic stack trace as a list of tuples that might simply get discarded as soon as the exception is caught, while making it possible to suspend an exception temporarily, drop back into Erlang code to match against a set of catch-patterns, and re-throw the whole thing again if nothing matched. If it's needed for anything, the blob will be unpacked into a symbolic trace. > > All in all, you're better off pretending you don't know anything about this, apart from the fact that effort has been made to keep exceptions as cheap as possible. > >    /Richard _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate

 In reply to this post by Jeff Schultz On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz wrote: On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote: > > I can see the equivalent evaluation of "250"<250 being a common mistake, > > and always being false is hardly useful. > A "<" B when A and B have different types means A is > "less complex" than B. Lists and more complex than integers > "250" is a list so "250"<250 is false.Another thought I had about this was that in some languages"10" < 20 might be true, and "20" < 10 or 20 < "10" might be false. In Erlang a string (list) is always bigger (ie more complex) than an integer.A Javascript programmer might get confused here.Erlang:  "12" + 1   => (exception) "12" - 1    => (exception) "12" > 2    => true "12" > 15  => trueJavascript: "12" + 1 => "121""12" - 1  => 11"12" > 2 => true"12" > 15 => falseOverloading plus to mean either plus or string concatenation is horrible - and shouldn't "-" mean string subtraction (sometimes)so "123" - 23 =>100 and "abc" - "a" => "bc" and "abc" - "c" => "ab" :-)I prefer the Erlang method - but then I'm probably somewhat biased here...This (Javascript) horrible way of doing things caused mehours of debugging - since my debugger wrote strings without the quotes so I couldn't see the difference between "123" and 123when printed.Javascript also crashes late, and variables in closures can be changed after binding them into the closures ... and the concurrency model is ... (isn't) - but it's fun to muck around withand do things in the browser. > Suppose I want to make a Key-Value database, where the Key can be anything, > including 250 and "250" to make any form of ordered tree we need a total > order over all the keys. Indeed.  If we can have only one built-in comparison, it needs to be total over all values.  It is a pity that Prolog's distinction between term comparison and number comparison wasn't carried over to Erlang :-(    Jeff Schultz _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate

 On 20 May 2011, at 18:23, Joe Armstrong wrote: > Javascript: > > "12" + 1 => "121" > "12" - 1  => 11 Aah, that's cute. :) A nice example of how semantics is so much more important than syntax… BR, Ulf Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions
Open this post in threaded view
|
Report Content as Inappropriate