Syntactic sugar poll

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Erik.Johansson
I have a suggestion for a very small change that seems to arouse strong feelings.

Since I am doing a lot of assembly hacking I often need to use hexadecimal constants. All my debuggers and C compilers write hexadecimal constants as 0xN, but in Erlang I have to write it as 16#N. There are two problems with this, I can not copy and paste hexadecimal numbers between Erlang and other applications, and it looks really ugly. Now, don't get me wrong the general base#number syntax is flexible and useful but would it not be nice to have 0xN as syntactic sugar for 16#N in Erlang.

What do you think? Would it be nice to have this feature?
Are there any reasons for not allowing this feature?

I use it in the shell in my system (together with my fixes for printing hexadecimal numbers) but since it is not a part of standard Erlang I can't use it in Erlang code that I write (at least not in portable code ;) which is a shame.

All that is need to get it to work is this little patch:
-------------------------------------------------------------------
lib/stdlib/src/erl_scan.erl
505a506,512
+ scan_after_int([$x|Cs], Ncs, Toks, SPos, CPos) ->
+     case list_to_integer(reverse(Ncs)) of
+       0 ->
+           scan_based_int(Cs, 0, 16, Toks, SPos, CPos);
+       Base ->
+           scan_error({base,Base}, CPos)
+     end;
-------------------------------------------------------------------
 
Please, support this bill today!

/Erik
--------------------------------------
 N. Erik M. Johansson
  Studentv?gen 13:33
  752 34 Uppsala (Sweden)
 happi
 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.



Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Miguel Barreiro Paz-2

        Hi,

> Since I am doing a lot of assembly hacking I often need to use
> hexadecimal constants. All my debuggers and C compilers write
> hexadecimal constants as 0xN, but in Erlang I have to write it as
> 16#N. There are two problems with this, I can not copy and paste

        I for one would like the 0xN syntax, maybe just for the sake of
old assembly tradition. On the other hand I'm very happy that Erlang keeps
the needed features and (usually) drops what is superfluous (so we have
.erl instead of .perl, you know); thus I would understand it if people
felt this sugar unnecessary.

Regards,

Miguel




Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Maurice Castro
In reply to this post by Erik.Johansson
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, in this
case in particular I suspect that we might be on a slippery slope.

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)

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.

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.

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)

Please vote NO and save Erlang from the 0x convention.

Written and presented by Maurice Castro for the NO case.


Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Claes Wikström
In reply to this post by Erik.Johansson

> What do you think? Would it be nice to have this feature?
> Are there any reasons for not allowing this feature?


I vote yes (If I have a vote)

/klacke


--
Claes Wikstrom                        -- Caps lock is nowhere and
Alteon WebSystems                     -- everything is under control          
http://www.bluetail.com/~klacke     
cellphone: +46 70 2097763


Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Miguel Barreiro Paz-2
In reply to this post by Maurice Castro


        Hi,

> 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

        So net:ping('mynode') would yield interesting results :)

Regards,

Miguel




Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Erik.Johansson
In reply to this post by Maurice Castro

----- Original Message -----
From: "Maurice Castro" <maurice>
>
> 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
 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.




Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Francesco Mazzoli-2
  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>
>
>>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
> 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.
>
>
>
>





Reply | Threaded
Open this post in threaded view
|

Syntactic sugar poll

Maurice Castro
In reply to this post by Miguel Barreiro Paz-2
>
>
> Hi,
>
> > 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
>
> So net:ping('mynode') would yield interesting results :)

The trouble with simple examples is that they often overlook inconvenient
complexities in order to maintain brevity. When writing the example I
was aware of the atom, string and comment deficiencies that would result.
Here are 2 solutions:

1) The script as provided can be used without change if programmers
        refrain from using 0x other than for hexadecimal ... very few
        programs will fail

2) A lex based preprocessor (attached) should handle all the cases
        mentioned which are also valid Erlang programs. Lex was chosen as
        a compact representation.

The key issue is do you extend a language, increasing maintenance costs,
and education costs for all, when those who have a specific need have
the option of handling the problem themselves with preprocessing or
metaprogramming.

        Maurice Castro
-------------- next part --------------
%{
#include <stdio.h>
%}
%x STRING
%x ATOM
%x COMMENT
%%
' {BEGIN ATOM; ECHO;}
<ATOM>' {BEGIN INITIAL; ECHO;}
\" {BEGIN STRING; ECHO;}
<STRING>\" {BEGIN INITIAL; ECHO;}
% {BEGIN COMMENT; ECHO;}
<COMMENT>.*$ {BEGIN INITIAL; ECHO;}
<INITIAL>0x {printf("16#");}
%%

int main(int argc, char *argv[])
{
        ++argv, --argc;  /* skip over program name */
        if (argc > 0)
                yyin = fopen(argv[0], "r");
        else
                yyin = stdin;
        yylex();
}