Erlang is getting too big
Tue Oct 14 13:13:55 CEST 2003
--- Bengt Kleberg <Bengt.Kleberg@REDACTED> wrote:
> Thomas Lindgren wrote:
> > Here's another part that could stand cleaning up:
> > - guard syntax 1: "," and ";"
> > - guard syntax 2: "and", "or"
> > (are they there anymore?)
> > - expression syntax 1: "and", "or"
> > - expression syntax 2: "andalso", "orelse"
> > All of them working somewhat differently.
> oops. what is the difference between ',' and 'and'?
> and ';' and 'or'? i
> have been using them to mean the same thing.
As I recall, ";" can't be nested inside a guard, while
";" appeared before guard expressions were
generalized, and the implementation at the time seemed
to require this restriction ... but once generalized
guards were worked out, it puzzles me why a new set of
operators was introduced rather than generalizing the
> eiffel has 'andalso' and 'orelse'. the only :-)
> people that finds 'and'
> and 'or' strange are the ones that has a c
My main objections are the added noise from long
names, the limited usefulness of strict and/or, and
the fact that the obvious names are used for the
And in C you use && anyway :-) (The &-operator
corresponds to 'band' not horrid 'and'.)
> > My modest proposal:
> > - drop is_* guards (unless there is a pressing
> > to keep them?)
> there is no static typing. therefore it helps (me)
> to be able to
> recognise the return value of a function from its
> name. one way of doing
> this is to teach users (by using the concept in
> guards) to call
> functions that return booleans is_*.
> moreover, there is a guard float() and a bif
> float(). the bif returns a
> float, not a boolean.
> this (imho) is confusing
If that is a big problem, why not introduce a new
float-making function, rather than a collection of
extra type tests? Seems simpler all-around.
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
More information about the erlang-questions