[erlang-questions] Bug ?!

[Richard Carlsson]

Richard A. O'Keefe wrote:
> 	>    (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.
> 	
> Try taking what I wrote literally.
> Remember that the set of operator-like tokens in Prolog is open,
> not closed as it is in Erlang, and I was talking about Prolog.

Ah. That was a Prolog feature that I was not aware of. (Tried briefly to 
google for some more details about this, but failed. Got a reference?)

> Remembering that we are discussing Prolog experience with ,..; consider
> 
> 
>     [.]	    [..] [...]         [....] 		are all one-element lists
>     [.,.]        [...,...]     [....,....]	are all two-element lists
>     [.,.,.]      [...,...,...] [....,....,....]	are all three-element lists
> 
> but	    [..,..]				was NOT a two-element list
> 	    [..,..,..]				was NOT a three-element list
> 
> and you can't say that wasn't confusing.

It certainly was, I agree.

> 	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.
> 
> No, that's not what I said, and they didn't try to do too much.
> What I said is that people who are used to writing English *EXPECTED*
> .. to work in ways that in fact it didn't.
> The only variant that was implemented was this:
> 
>     <list> ::= '[' ']'
>             |  '[' <term> <rest-list>
>     <rest-list> ::= ']'            
>                  |  ',' '..' <term> ']'
>                  |  ',' <term> <rest-list>

Ok, that was not as general as I first thought. I still think it was too 
much, though: a pattern that has a matching cost proportional to the 
size of the input, rather than only to the size of the pattern, is a too 
powerful primitive (in my opinion) - if one includes that, one might as 
well start adding patterns for nesting tuples to arbitrary depths. (Of 
course, such a powerful matching language could be very useful, but it 
changes the "feel" of patterns rather radically.) It now looks to me 
that since the above patterns _could_ do such a powerful matching, many 
people naturally expected that the other variants should also work, 
since they have the same or lower complexity.

> 	But let's reverse the situation:  _only_ the following forms
> 	should be allowed:  [..], [x,..], [x,y,..], and so on.
> 
> Now you are going to confuse the people who expect [X,..,Z] to work.

Not much, I don't think, if the basic rule is that patterns do not seek.

> No, the more I look at it, the better my original proposal with [*]
> looks.  '..' gets used very reasonably and effectively in Haskell.
> If '..' ever means anything in Erlang, I should prefer it to do the
> Haskell thing.

Haskell uses it for (lazily generated) sequences, as in [1,3..9] (and a 
comma is not allowed before or after the '..'). But they don't allow 
that syntax in patterns, it seems. Pity - it would have been a nice 
symmetry. And conversely, if I had ,..-patterns in a language, I would 
also like to be able to use that syntax for generating lists.

> Do I need to point out that this is not a plausible typing error?
> To get from the "," key to the "|" key you have to go up diagonally two
> and then across three.  It's not like the "," and ";" keys (up diagonally
> one, across one) which are even visually similar.  "|" is visually very
> different from ",".  It is, to state the blindingly obvious, considerably
> taller, whereas ",.." is all on one line.  We simply are not talking
> about TYPOs here, but about THINKOs, and changing the tokens isn't
> likely to help with THINKOs.

In an ideal world, every action that our body takes is the result of 
careful cerebral planning and execution. However, in reality it is not 
uncommon to think one thing and have your body do something else, even 
without your conscious self noticing. Therefore, I still would classify 
this kind of error as a typo. It is not quite the same thing as e.g. 
dividing instead of multiplying when solving an equation, or getting an 
off-by-one error when traversing an array.

> Changing "|_" to ",.." would trade 6118 shifted keypresses for
> 9342 unshifted keypresses.  This would indeed reduce the number of
> shifted keypresses by about two and a half percent, but since only about
> 1 keypress in 8 is shifted, that's not a big saving overall.

Ah, but you didn't count the number of extra keypresses needed to delete 
the mistyped character and try it again from a different key. :-)
No, it would not have a large impact on the number of shifted keypresses 
(few things would, since the overwhelming majority of all program 
characters are unshifted). But personally, I'd be happy to avoid |_ (it 
actually took me 7 keypresses to type that, since I was using Swedish 
keyboard layout and missed the "?" - oops, I meant "_").

> Changing "|_" to ",.." would still leave more than half of the uses of "|"
> in lib/stdlib/ untouched, and if "[X|Y]" is allowed it is hard to see why
> '[X|_]" wouldn't also be allowed in a pattern.  It is not clear how having
> two different notations would help.

Ah - I didn't say anything about two different notations, now did I? In 
fact, I was thinking about scrapping the separate cons operator 
altogether. But that's another thing.

> The point of the [*], {*}, <<*>> proposal was to have a simple way to
> say something that _cannot_ be currently said in a pattern, at least for
> [*] and {*}.

Yes, that would still be useful (at least for tuples). I just find it 
unfortunate to use * for that purpose in a proper programming language - 
it drags in horrible command shell connotations that put a shiver up my 
spine.

What semantics did you have in mind for '[*]' (in Erlang)? The 
is_list(X) test only checks for is-cons-or-nil. Should [*]/[..] be a 
synonym, or did you imagine it as checking for proper list-ness?

	/Richard C.