length() in guards

[Raimo Niskanen]

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 
list.

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".
>>
> ...deleted
> 
>  > 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.
> 
> 
> bengt
>