[erlang-questions] Proposal for is_iolist/1 guard

[Richard O'Keefe]

On 28 May 2009, at 5:48 pm, Alpár Jüttner wrote:

>
>> Now guards are a special sublanguage in Erlang.
>> They are supposed to be fast.  The one thing that
>> stops them always being fast is that length/1 is
>> allowed, which was arguably a mistake.  However,
>> at least length/1 is tail recursive, so all
>> existing guards can execute in bounded space, if
>> not (thanks to length/1, drat it) bounded time.
>
> Once we abandoned the bounded time requirement (which would indeed  
> look
> a reasonable assumption), why do we want bounded space?

I've been saying off and on for a long time that we ought to get
rid of length/1 from the guard sublanguage.  I believe I've proposed
these guards before:

         is_list(T, L)     is true when T is a list at least up to  
length L
         is_list(T, L, U)  is true when length(T) >= L, length(T) =< U
         is_tuple(T, L)    is true tuple_size(T) >= L
         is_tuple(T, L, U) is true when tuple_size(T) >= L, =< U

Now a check for length(L) == 4 has cost determined by the size of
L, which could be anything.  But a check for is_list(L, 4, 4) has
cost limited by the argument 4.

I once trawled through all the Erlang code I had available and
didn't find anything that really *required* the unbounded length/1
BIF in guards if you had these or you were willing to reprogram
just a little bit.

Of course this still leaves ... X ... X ... in patterns, and X == Y
in guard tests, but it doesn't seem to be common for people to
_intend_ these to be applied to data structures of unknown and
possibly very large size.

> It there any
> (theoretical/practical) reasoning behind? Do we want to avoid garbage
> collection?

The practical issue is that bounded space here really means SMALL space
whereas unbounded space might mean LARGE space that _can't_ be garbage
collected.  Sadly, we can't manage without garbage collection inside
guards, because guards can do arithmetic, and floating point numbers
need boxes and integers can be bignums.  But at least we can hope to
avoid _fruitless_ garbage collection.