Enhanced type guard syntax]

[Peter-Henry Mander]

Hi Gurus,

After spending a weekend thinking about totally unrelated things, and 
now that my mind is somewhat refreshed, my opinion is _NO_, please don't 
change the notation. The only "gain" is a change in syntax. I'm 
perfectly happy to read the "English" version.

As for optimisation, where I've needed high speed bit-crunching I've 
resorted to C and C-node servers. This kinda dodges the 
language-improvement issue, but I'm simply being pragmatic, and it has 
worked very well for what I've done. Speed in Erlang isn't a big issue 
for me.

As for type-checking and code-correctness a code analyser would be a 
wonderfully powerful design tool. Erlang already has the remarkable 
quality of expressing algorithms clearly. I make lots of syntactic 
errors when writing (wither semicolon?), but once I've cleaned them up, 
most of the time the code semantics are correct and works as desired. Yay!

But in practice I've rarely had such obscure problems as "how did an 
atom end up being used as a number?". Maybe the excellent error trapping 
and recovery mechanisms in Erlang could be to "blame" for this? I found 
debugging Erlang code is relatively easy, because the error reports are 
exact and meaningful, and the programs don't go quietly mad before 
failing miles down the execution path.

Pete.

Richard A. O'Keefe wrote:
> Concerning the examples:
> 
> 	foo(X == 2 * Y)
> 		% foo(X, Y) when X == 2*Y
> 	foo(X > Y)
> 		% foo(X, Y) when X > Y
> 
> am I the only one who is bothered (to put it politely) that the
> "improved" versions _look_ as if they have one argument, but are
> supposedly equivalent to functions with _two_ arguments, and that
> there's no obvious way to tell which argument is which?
> 
> For some reason, Haskell programmers don't seem to might writing
> 
> 	foo x y | x == 2*y =
> 	...
> 	foo x y | x < y    =
> 	...
> 
> "Chris" wrote:
> 
> 	I also don't think it's any more difficult to read, once you
> 	unlearn the arbitrary convention that "comma seperates arguments".
> 	
> It may be arbitrary, but so are all human communication conventions,
> and this one has been going strong in programming languages for 50 years.
> "As a language design idea in its own right", I very much dislike a
> notation where I can't tell which argument is which.
> 
> Now let's consider
> 
>     f([X|_], [Y|_]) when X < Y -> ...
> 
> how do you write _that_ without commas?  Good ideas (like abstract patterns)
> work in general cases.
> 
> 
>