There should be a new built in function for guards,
is_between(Term, Lower_Bound, Upper_Bound)
which succeeds when
are all integers, and
Lower_Bound =< Term =< Upper_Bound.
A new guard BIF is added.
is_between(Term, LB, UB)
In expression use, if LB or UB is not an integer, a badarith exception is thrown, just like an attempt to do remainder or bitwise operations on non-integer arguments. In guard use, that exception becomes failure.
This is a type test which succeeds (or returns true) if Term is an integer and lies between LB and UB inclusive, and fails (or returns false) for other values of Term.
As an expression, it has the same effect as
( X = Term, Y = LB, Z = UB, Y bor Z, ( is_integer(X), X >= Y, X =< Z ) )
where X, Y, and Z are new variables that are not exported.
is_integer(tom, dick, harry)
should raise an exception, not return false, as
is only tested after LB and UB have been found to be integers.
As a guard test, it has the same effect as
( X = Term, Y = LB, Z = UB, is_integer(Y), is_integer(Z), is_integer(X), X >= Y, X =< Z )
would have, were that allowed. However, it admits a much more efficient implementation.
Currently some people test whether a variable is a byte thus:
-define(is_byte(X), (X >= 0 andalso X =< 255)).
This is actual current practice. However, it fails to check
X is an integer, so
?is_byte(1.5) succeeds, it may
X twice, so
?is_byte((Pid ! 0)) will send two messages,
not the expected one, and the current Erlang compiler generates
noticeably worse code in guards for ‘andalso’ and ‘orelse’ than
it does for ‘,’ and ‘;’.
It is also useful to test whether a subscript is in range,
-define(in_range(X, T), (X >= 1 andalso X =< size(T))).
which has similar problems.
is_between, we can replace these definitions with
-define(is_byte(X), is_between(X, 0, 255)). -define(in_range(X, T), is_between(X, 1, size(T))).
which are free of those problems
One alternative to this design would be to follow the example of Common Lisp (and the even earlier example of the systems programming language on HP 3000s) and allow
E1 =< E2 =< E3 % (<= E1 E2 E3) in Lisp
(and possibly also
E1 =< E2 < E3 E1 < E2 =< E3 E1 < E2 < E3) % (< E1 E2 E3) in Lisp
as guards and expressions, evaluating each expression exactl
once. I am very fond of this syntax and would be pleased to
see it. This would resolve the double evaluation of
possible non-evaluation of
E3, and the inefficiency of ‘andalso’.
However, it would not address the problem that a byte or an
index is not just a NUMBER in a certain range, but an INTEGER.
If Erlang had multiple comparison syntax, there would still be
a use for
Code that defines a function named
is_between/3 will be
affected. Since the Erlang compiler parses an entire
module before semantic analysis, it’s easy to
There is none. However, we can sketch one. Two new BEAM instructions are required:
The test does
if Src2 is not an integer, goto Lbl. if Src3 is not an integer, goto Lbl. if Src1 is not an integer, goto Lbl. if Src1 < Src2, goto Lbl. if Src3 < Src1, goto Lbl.
The bif does
if Src2 is not an integer, except! if Src3 is not an integer, except! if Src1 is not an integer or Src1 < Src2 or Src3 < Src1 then move 'false' to Dst else move 'true' to Dst.
Nothing here is fundamentally new, and only my unfamiliarity with how to add instructions to the emulator prevents me doing it. And my total ignorance of how to tell HiPE about them!
There might be some point in having variants of these instructions for use when Src2 and Src3 are integer literals; I would certainly expect HiPE to elide redundant tests here.
The compiler would simply recognise
is_between/3 and emit the
appropriate BEAM rather like it recognises
My ignorance of how to extend the emulator is exceeded by my
ignorance of how to extend the compiler. Certainly we’d need
... is_bif(erlang, is_between, 3) -> true; ... is_guard_bif(erlang, is_between, 3) -> true; ... is_pure(erlang, is_between, 3) -> true; ...
(but NOT an
is_safe rule) in
erl_bifs.erl. Or would we? I’ve
not been able to figure out where
is_guard_bif/3 is called.
There will need to be a new entry in genop.tab as well.
erl_internal.erl is in
OK, so a couple of functions in
erl_internal.erl need to be patched
is_between/3; what needs changing to generate BEAM?
The annoying thing is that if I knew my way around the compiler,
it would be easier to add this than to write it up.
Here’s some text to go in the documentation:
is_integer(Term, LB, UB) -> bool() Types: Term = term() LB = integer() UB = integer()
Returns true if Term is an integer lying between LB and UB inclusive (LB =< Term, Term =< UB); otherwise returns false. In an expression, raises an exception if LB or UB is not an integer. Having UB < LB is not an error.
Allowed in guard tests.
This document has been placed in the public domain.