[erlang-questions] Bug ?!

[Richard A. O'Keefe]

	> 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?)
	
Any Prolog manual.  Look for op/3.
The SWI Prolog manual is available for free download (SWI is open source).

	> 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)

I don't know how this misunderstanding arose.  I thought I said quite
explicitly before that ", .." was the old spelling for "|".  The pattern
[X,Y,..Z] in DEC-10 Prolog meant *precisely* the same as [X,Y|Z].
It certainly didn't check that Z was a list.  (It couldn't:  in Prolog
that would have required pattern matching to be able to *generate* the
infinite set of lists.)

There is one lingering trace of ",.." in ISO Prolog, and that is the
"univ" predicate (=..)/2.

	> 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.
	
You expect beginners to know that there _is_ such a rule?
It's not an obvious feature of a pattern language; Unix wildcard filenames
have no such rule, and the pattern matching language in Interlisp didn't.
(My first abandoned Prolog project was a translator from Interlisp list
patterns to Prolog patterns.  By the time I understood the relationship
between the two well enough, I found that I no longer wanted it!)

	> 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, because that is unknowable, and in my experience, close to 0.
Clearly your experience, with a different keyboard, is different.

	> 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.
	
The connotation it drags in for me is "Kleene closure" (think "* in regular
expressions"), which is exactly right.

	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?
	
To put it another way, should
	
	f(X = [*]) -> g(X).
	
have the effect of

	f(X) when is_list(X) -> g(X).

or of

	f(X) when length(X) >= 0 -> g(X).

If Erlang didn't already have length() in guards, I would be
feeling awkward about introducing a kind of pattern that could take
a long time.  (Mind you, f(X, X) can ALSO take a long time.)
In cases where I would like to use [*], I would be processing all the
elements later on (or at any rate touching all the cells), so the
cost would pay off.  I have always felt that is_list(X) is a very
misleading way to express is_empty_or_a_pair(X).  So

    [*]			in a pattern is equivalent to
	X		in the pattern and
	length(X) >= 0	added to the guard.