length() in guards
Mon Sep 29 13:32:13 CEST 2003
We have already thought of a possible optimization in the compiler to
convert such as "length(L) > 3" to an internal "length_gt(L, 3)", but it
was not possible without changing the semantics of length(L).
Reason: if L is an improper list, length(L) crashes, so the guard test
length(L) must fail, hence the guard test must search to the end of the
Changing the semantics of (or putting restrictions on) length(L) is not
something we are very keen on (to put it mildly).
Introducing is_length_gt(List, Length) and such with different semantics
than length(List) for improper lists does at least not break (the
sacred) backwards compatibility.
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Bengt Kleberg wrote:
> Richard A. O'Keefe wrote:
>> One of the perennial questions about Erlang is "can't we generalise
>> guards to allow any expression?" The standard response is that the
>> guard tests and expressions are supposed to have certain properties.
>> And the standard retort to that is that length/1 does't have them.
>> A tiny restriction would tame length/1 in guards.
>> The restriction is
>> "a call to length/1 may appear in a guard only as an entire
>> operand of a comparison (==, /=, <, >=, >, <=, =:=, -/=)
>> in which the other operand is not a call to length/1".
> > What do people think?
> what about:
> is_length_equal( Var, Length )
> is_length_greater( Var, Length )
> is_length_less( Var, Length )
> this would make it easier to remember, imho.
More information about the erlang-questions