Enhanced type guard syntax]
Mon Sep 22 09:29:05 CEST 2003
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
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.
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.
More information about the erlang-questions