Compiler bug

[Chris Pressey]

On Fri, 12 Apr 2002 17:23:09 +0200
"Thomas Lindgren" <thomas.lindgren@REDACTED> wrote:

> 
> >Is there a up to date version of the guard expression description ?
> >Page 29-30 (Concurrent programming in erlang 2:nd edtion) lists most
> typechecks,
> >comparision and bifs allowed.
> >Erlang Extensions Since 4.4 (html docs) mentions the record/2 and
> function/1
> >typecheck, but where is is_list/1 and the use of "and", "or", and "not"
> >mentioned ?
> 
> Perhaps it is time to raise the question whether there
> are getting to be too many similar operations in Erlang as well?
> 
> For guards, we have comma, semicolon (or), and, or, not.
> (Could we merge some operations here?)
> 
> For guard operations, we have type(X) and is_type(X).
> (Could this be unified into just type(X)?)

I feel somewhat responsible for this 'improvement' as it appeared shortly
after I expressed a desire for the language to be more orthogonal. 
Doubling the number of guard tests is not my idea of orthogonality, but
it's not the only time one of my suggestions has been misinterpreted I
think.

> For expressions, we have and, or, andalso, orelse.
> (Do people use "E1 and E2" while relying on E2 being
> evaluated when E1 is false? If not, rename andalso into and,
> etc.)
> 
> What do you think?

Honestly?

- Allow ANY function in guard tests.
- Only WARN if the guard test does not operate in constant time.
- Deduce which functions operate in constant time by analysis
(A function operates in constant time iff all the functions it calls
operate in constant time AND it never calls itself or calls a function
which calls itself - i.e. no cycles in the recursion graph.  This does
not seem very difficult to determine.)
- Possibly have a module 'type' and place all the type-assertion
functions in it (type:number(X), type:list(X), etc)
- type:string(X) would be nice (list(X) and 0 =< hd(X) =< 255))

Basically, I see guards as syntactic sugar for case statements.  The
semantics are almost exactly the same except for the constant time
requirement, which has always struck me as overly strict, considering (for
example) that a type mismatch is an error (which will be completely
ignored by the compiler) while a non-constant-time guard is merely an
inefficiency (but which will result in a compiler error just as drastic as
a syntax error.)  I think it should be a warning only.

In some ways, Erlang has always struck me as a bizarre combination of
extremely low-level (assembler-like) concepts and extremely high-level
(lambda-calculus-like) concepts.  While reasoning about performance is of
course important in any language for programming soft real-time systems, I
am of the opinion that computers are better at reasoning about performance
than humans, and thus the onus should be placed more on them, allowing the
programmer to write more expressive and easier-to-maintain code.

As for short-circuiting, you shouldn't have to think about it in
referentially transparent code, and (for me at least) it's fairly rare
that I have to think about it in side-effectful code either, so I'm not
sure why orelse and andalso were introduced, when two seperate tests in
the code is more explicit and possibly clearer.

Chris