[erlang-questions] Bug ?!

Richard Carlsson <>
Fri Oct 6 11:22:44 CEST 2006


Richard A. O'Keefe wrote:
> Problem 1:  is ,.. one token or two?
>  (a) if you make it one token, then you have all sorts of problems:
>    (1) ,.. is one token but in [.,.,.] ,. is two tokens, and in
>        [...,...,...] ,... is two tokens again, and of course ,.2 had
>        better be comma nought-point-two.
>    (2) careful writers who put spaces after commas want to put a space
>        after this one, [a, b, .. c]

Of course. My intention was to make '..' one token. Not that I think 
this should be added to Erlang, mind you - I was just experimenting with 
language design. (Side note: in Erlang, a float cannot be written '.2' - 
it must be '0.2'.)

>  (b) if you make it two tokens, then you hve other problems:
>    (1) if you can have a space there, why not a newline? why not a comment?
>        So X = [1, 2, 3,
> 		% this can go on for some time
> 		.. L]

Sure. But that is not very different from normal Prolog/Erlang syntax:
         X = [1, 2, 3
  	    % this can go on for some time
  	     |L]
(that there is no comma after the '3' is not much of a visual cue in a 
larger chunk of code). If the |-syntax is not a problem, I don't see why 
the ..-syntax should be one.

>    (2) you have a token which would otherwise belong to an established
>        class of tokens (including +, ++, .+, --, -, .-, ..., ...., ....)
>        but which can only occur in one place and then doesn't mean what
>        they do.

I'm not sure I follow you here.

> Problem 2:  ,.. just plain doesn't work the way people expect.
>     They expect to write
> 	[..,X,Y] = L		% oops, only allowed at end
> 	[X,Y,..] = L		% oops, something must follow ..
> 	[X,Y..Z] = L		% oops, a comma must precede ..	
> 	[X,Y,..,Z] = L		% oops, a comma may not follow ..
> 	[X,Y,..Z] = L		% !!OOPS!! I was expecting Z to be the
> 				% last element of L, but it's a tail!
> 
> In fact, for someone fluent in Latin-based writing systems that make
> use of ellipses, ,.. is appallingly HARD to get right.  In particular,
> your [x,y,..] is one of the cases that wasn't allowed, any more than
> [x,y|_] was allowed.
> 
> When ,.. was removed from Prolog, no-one was sorry to see it go.

It seems that they were trying to do too much. As you noted, the variant 
that I suggested was the only one that they did _not_ implement. But 
let's reverse the situation: _only_ the following forms should be 
allowed: [..], [x,..], [x,y,..], and so on. It should be simple for 
people to remember that they cannot expect this to work except in a tail 
position. (At least as easy to remember as, say, that n in n+k must be 
 >0, and that e.g. n*n+k is not allowed but c*n+k is.)

> Given that . has so many other uses, I would expect
> that ,.. would be MORE prone to mistakes.

The trouble with the |-syntax is that it only takes a single keystroke 
to change the meaning of the constructed data, and once it has happened, 
it is pretty hard to notice that a ',' somewhere should really be a '|'. 
(I have seen this kind of bug survive for years in production code.)

> Given the conflicts between ,.. and common practice in natural language,
> and the absence of such conflicts between | and natural language,
> I would expect ,.. to be HARDER to read.

Actually, I find it quite visible. I have experimented with rewriting 
largish chunks of existing code, and overall, I think that e.g. 
f([{x,42},{y,17},..])-> has a more distinct visual signature than the 
corresponding Erlang syntax f([{x,42},{y,17}|_])->.

(Another thing entirely is of course that I have to press shift to 
produce both the | and the _ - and none of them stay in the same place 
when I switch keyboard layouts.)

     /Richard




More information about the erlang-questions mailing list