Erlang is getting too big

[Thomas Lindgren]

A question on #6 below: shouldn't it be that the guard
_fails_ if a subexpression crashes?

Anyway, a couple of short comments:

1. Do we WANT to unify guards and expressions?
Personally, I think it might be good, but not if the
solution is messier than what it replaces. It's not a
"must have" for me.

2. Assuming that we do:

Another approach to unifying guards with expressions
would be to introduce the appropriate type tests as
BIFs. Apart from float/1, this seems straightforward? 

For float/1 used in expressions, change the BIF to a
type test and write a lint-like program to detect (and
maybe rewrite) all occurrences in existing source
code.

(The linker could also direct calls to float/1 in "old
BEAM code" to the float-making BIF, and calls in "new
code" to the float-testing BIF.)

That way, it seems to me we would avoid having an
extra set of tests identical in all but name. Well,
unless I've overlooked something crucial. (Please
don't say 'backwards compatibility' :-)

Best,
Thomas

--- Richard Carlsson <richardc@REDACTED> wrote:
> 
> On Tue, 14 Oct 2003, Bengt Kleberg wrote:
> 
> > Thomas Lindgren wrote:
> > ...deleted
> > > 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.
> >
> > eiffel has 'andalso' and 'orelse'. the only :-)
> people that finds 'and'
> > and 'or' strange are the ones that has a c
> background.
> 
> Perhaps the most complicated part of the Erlang
> language are the clause
> guards. They are a mess, although we've tried to
> clear up a few things.
> 
> 	1. Guards are comma-separated sequences
> (conjunctions) of "tests",
> 	   i.e., the commas mean logical "and". (So far so
> good.)
> 
> 	2. Later, it was added that you could have
> alternative lists
>            of tests, if you separated them with
> semicolon as in
> 	      "t01, t02, t03; t11, t12, t13; t21, t22, t23
> ->"
> 	   (a disjunction of conjunctions.) So, the
> semicolons mean
> 	   logical "or" in this context. (This addition was
> probably
> 	   one of the less motivated ones. I've never used
> it myself.)
> 
> 	3. A "test" is either a comparison "X == Y", "X >
> Y" etc, or
> 	   a call to a built-in test function like
> "integer(X)" or
> 	   "float(Y)". (I.e., it is not just any boolean
> expression.)
> 
> 	4. Guard tests have a separate name space!
> "integer(X)" above
> 	   is not defined outside guards, so you can't
> write:
> 
> 	       Bool = (f(X) and integer(Y))
> 
> 	   in normal Erlang code - unless you define
> "integer/1"
> 	   yourself. (But you can't override the tests used
> in guards.)
> 	   The test "float(X)" overrides the built-in
> typecast function
> 	   of the same name. You _can_ write the following:
> 
> 	       Bool = (f(X) and float(Y))
> 
> 	   but you might be surprised when "float(Y)" does
> not return a
> 	   boolean.
> 
> 	5  The subexpressions of guard tests are "guard
> expressions",
> 	   which are a limited subset of normal
> expressions. Basically:
> 	   variables, constants, operators and calls to a
> subset of the
> 	   "automatically recognized" BIFs are allowed, but
> nothing else.
> 
> 	6. Guard tests are implicitly "wrapped in a catch",
> so that if
> 	   a subexpression crashes (the tests themselves
> can't crash),
> 	   they quietly evaluate to "true" instead.
> (Thankfully, the
> 	   number of programmers crazy enough to actually
> make use of
> 	   this "feature" is very small. I have not seen it
> used in OTP
> 	   and I would like to have it removed from the
> language.)
> 
> 	7. The boolean operators "and" and "or" (and "not"
> and "xor")
> 	   have been in Erlang quite a while, but were
> defined to be
> 	   strict, i.e., always evaluate both arguments.
> Furthermore,
> 	   they could originally not be used anywhere in a
> guard(!).
> 
> 	8. When "and" and "or" were eventually allowed in
> guards, they
> 	   actually got the same semantics (within guards)
> as "," and
>            ";" respectively, since guards cannot
> have side effects
> 	   (and thus it does not matter if you use strict
> evaluation or
> 	   not, space/time aside). But there is no point in
> using and/or
> 	   instead of comma and semicolon unless you like
> longer lines.
> 	   Stick to the normal separators. It's just in
> subexpressions
> 	   that you might use and/or/not/xor once in a blue
> moon.
> 
> 	9. 'andalso' and 'orelse' (the non-strict versions
> of 'and' and
> 	   'or' can be useful for avoiding deep nesting of
> case
> 	   switches`, and can make the code much more
> concise. For
> 	   example:
> 
> 		case f(X) of
> 		    true -> true;
> 		    false ->
> 		        case g(X) of
> 		            false ->
> 		                case h(X) of
> 		                    true -> true;
> 		                    fasle -> false
> 		                end;
> 		            true -> false
> 		        end
> 		end
> 
> 	   is equivalent to
> 
> 		f(X) orelse (not g(X) andalso h(X))
> 
> 	   Now, how long did it take for you to verify that
> the
> 	   first version really implements the second one?
> What
> 	   happens if you misspell 'true' or 'false'
> somewhere?
> 	   (Personally, I'd have preferred 'and' and 'or'
> to be
> 	   defined as non-strict to begin with.)
> 
> And now, for 10,000 dollars*:
> 
>     What does the following do, if X is a
> floating-point number?
> 
> 	if float(X), (float(X) == true) -> true;
> 	   true -> false
> 	end
> 
> What we've tried to do in the last years is to make
> the differences
> between normal expressions and guards smaller. It's
> not easy, as I hope
> you can see from the above. It was in order to clear
> up the confusion
> with the guard test namespace that we added the
> "is_..." versions of the
> type tests. These have the same definition
> everywhere, and you can even
> call "erlang:is_integer(X)" if you need to. I think
> they are a good
> thing.  It is much easier to say to a beginner "Oh,
> 'integer(X)' is
> old-style - avoid that and use 'is_integer(X)'
> instead." instead of
> trying to explain why he can't write 'integer(X)' in
> other places than
> guard tests.
> 
> A new book would certainly be in order, if anyone
> could find a
> publisher.
> 
> 	/Richard
> 
> 
> * Altairian dollars.
> 
> 
> 
> Richard Carlsson (richardc@REDACTED)   (This space
> intentionally left blank.)
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com