[erlang-questions] Advanced Erlang Subtleties

[James Churchman]

a final one..

if you have for example a record like :

-record(server_opts,{port, ip="127.0.0.1", max_connections=10}).

then you can obviously do :

make_a_record()->#server_opts{max_connections=100}.

and to update a record :

update_a_record()->
MyRec = make_a_record(),
MyUpdatedRec = MyRec#server_opts{ip="10.20.30.40"}.

but you can't skip out the intermediate variable like so :

update_a_record()->
make_a_record()#server_opts{ip="10.20.30.40"}.

it gives ":17: syntax error before: '#'"

but wrapping in round brackets allows this :

update_a_record()->
(make_a_record())#server_opts{ip="10.20.30.40"}.

not sure why this is they case, but anyhow this might save a few lines :-)


On 20 May 2011 18:02, James Churchman <jameschurchman@REDACTED> wrote:

> yes this is where i think erlang really gets the balance correct, being
> dynamically typed ( so far less repetitive defining types where the type is
> either obvious or does not matter and is just begin "messaged" threw .. tho
> i know other people are strongly in favour of static typing)  but not
> Loosely Typed so avoids the huge amounts of ambiguity like what happens when
> you "add" or "subtract" different types as does JS, leading to the bug
> showing up a huge distance way from the code that was at fault..
> unfortunately JS also has hundreds of faults & bugs ( around 270 at my count
> ;-) ) in the original implementation that due to a big of a chicken / egg
> scenario cant really ever be changed :-) things like "crashing late" come
> from the fact that early versions had no error handling at all! ( eg no try
> catch )
>
> >A nice example of how semantics is so much more important than syntax…
>
> yes and shows that purely putting new syntax's onto an existing language
> only aid developer productivity & readability a bit and generally don't make
> the code (much) more reliable
>
> On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz <jws@REDACTED>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  => true
>
> Javascript:
>
> "12" + 1 => "121"
> "12" - 1  => 11
> "12" > 2 => true
> "12" > 15 => false
>
> Overloading 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 me
> hours of debugging - since my debugger wrote strings without
> the quotes so I couldn't see the difference between "123" and 123
> when 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 with
> and 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110522/908bc9d8/attachment.htm>