Syntactic sugar poll

[Francesco Cesarini]

  If I have a vote and our most honorable jury will consider it, it is 
NO. Since I started using Erlang in 1993, more and more additions have 
come along making what at first was a simple and straight forward 
language more complex, in some cases inconsistent, and harder to understand.

You were once given simple operations and if you needed more complex 
ones, you could use the simple constructs to build the complex ones. 
(for example, making synchronous messages through asynchronous message 
passing). With Erik's notation, we would be introducing two notations 
for doing the same thing. Not pretty. 

List comprehensions, bit syntax, funs/higher order functions, more Bifs, 
etc. etc. All of these constructs, even if powerful, have added a factor 
of complexity which scares and intimidates less experienced users and 
non programmers using the language. (oh no, here he goes again and 
defends his poor students :-) Sometimes, the new constructs do not 
follow the existing semantics of the language introducing even more 
special cases (Pattern matching of bin length's in function heads or 
shadowing of bound variables in funs as an example)... Or the 
differences between List comprehensions and Mnemosyne... Or even worse, 
notations that do not compile as combinations of characters and spaces 
can be interpreted differently by the parser (=<< in bit syntax must for 
example be written as = << otherwise the parser interprets it as =< <).

To avoid  making language more complex and avoid risking inserting more 
inconsistencies or ugly semantics, any extensions added should be a real 
necessity and kept a bare minimum. As the # notation exists today (Even 
if some people find it ugly or if it does not conform to any standard), 
I would rather stick to that.

I rest my case and point out that all my views are not necessarily those 
of my employer :-)

Francesco
--
http://www.erlang-consulting.com

Erik.Johansson wrote:

>----- Original Message ----- 
>From: "Maurice Castro" <maurice@REDACTED>
>
>>Vote NO! to adding 0x for hexadecimal constants.
>>
>>The case for leaving the language alone.
>>
>>In general I am against adding syntactic sugar to a language, 
>>
>
>Why?
>
>>in this case in particular I suspect that we might be on a slippery slope.
>>
>
>Erlang has always been on a slippery slope. ;)
>But the reason Erlang is so useful is that the development has been pragmatic, 
>only if a feature is nice and useful it is added. (Such nice features as records and 
>higher order functions have been added first as preprocessed syntactic sugar
>then later as "real" parts of the language.)  This approach has lead to some strange
>quirks, and some zealous people shun the language because it is "warty and ugly",
>but on the other hand this approach has lead to a very useful language. 
>
>>Erlang has a well worked out consistent mechanism for handling
>>constants with many bases. There is no need to extend the language to
>>satisfy these programmers as they are free to pre-process their files
>>to use their prefered convention. (eg. sed 's/0x/16#/g' file in this
>>case)
>>
>
>You know this is not true. Your sed approach would change my strings and 
>atoms too. Also, I would have no guarantee that my private notation would 
>be consistent with future versions of Erlang.
>
>How often do you write Erlang constants in another base than 2, 10 or 16?
>Base 10 is probably most common and has its own syntax (no 10# prefix 
>needed), base 16 is probaly the second most used base closely followed by
>base 2, why not give one or both of these a special syntax?
>
>>Furthermore, the case made for changing the language to include the
>>0x construct has the following additional problems:
>>
>>1) We are giving a favored place to a particular assembler's convention.
>>Assembler codes are far from standardised. Although GNU as borrowed C's
>>convention other assemblers use other conventions.  For example the
>>very popular tasm used a number followed by an `h' is a heaxadecimal
>>constant, `b' for binary, `o' for octal, `d' for decimal, or nothing
>>use the radix defined in the code.
>>
>
>Yes, but I belive the 0x notaion is the one most used today (in general not only
>in assemblers).  I am sure there are other (Pascal, Prolog, etc) programmers 
>who would like another syntax, but I am also sure that they still would recognize 
>0xN as a hexadecimal number.
>
>(I am an old tasm hacker myself but I have not used tasm for 10 years, and I do 
>not miss the base suffix asl long as I can have a base prefix.)
>
>>2) A better argument might be to adopt the C convention, however, if we
>>are going to extend the language to embrace C's way of denoting a
>>hexadecimal number we had best take the octal notation too ie 0x for
>>hexadecimal 0 for octal. The octal extension may well break existing
>>code.
>>
>
>Yes, but lets be pragmatic, who needs an octal number today? ;)
>(Hex on the other hand is a convenient way of writing numbers reprecented 
>by bytes.)
>
>>3) Although embracing the 0x convention in the current popular compiler
>>is simple, it may not be easy to implement it in other compilers
>>(fortunately for me, ec -- my pet project -- would also be simple to
>>modify to support the 0x convention)
>>
>
>Since the compiler have to handle 16# anyway, I don't see how 0x would
>make things more complicated.
>
>
>>Please vote NO and save Erlang from the 0x convention.
>>
>
>Please vote YES and give Erlang the freedom 0x convention.
>
>>Written and presented by Maurice Castro for the NO case.
>>
>
>/Erik
>-------------------------------------- 
> N. Erik M. Johansson
>  Studentvägen 13:33
>  752 34 Uppsala (Sweden)
> happi@REDACTED
> Work: +46 - (0)18 - 4711 033
> GSM : +46 - (0)70 - 631 42 59
> Home: +46 - (0)18 - 51 13 29
> http://www.csd.uu.se/~happi/ 
> Eric Conspiracy Secret Laboratories       
>--------------------------------------
>I'm Happi, you should be happy.
>Praeterea censeo 0xCA scribere Erlang posse.
>
>
>
>