Why no is_octet(N) guard?
Thu Mar 10 23:47:55 CET 2005
> Joe Armstrong wrote:
> > I disagree - please not more special purpose guards when a general
> mechanism > will do and why just is_octet? what about is_digit,
> > is_ascii, is_unicode, is_bananna?
That's the point! And thus the definitive answer should be "let us allow user-
defined functions in guards"!
Quoting Kostis Sagonas <>:
> All this discussion is somehow unnecessary. Erlang at some point
> *should* be extended with the ability to allow arbitrary user-defined
> guards. Conservatively checking whether a (module-local for a start)
> function is side-effect free is not exactly rocket science...
Well, my two cents. I know that there was already a discussion on these issues
and I'll re-read it soon.
When I'm invoking a BIF, I'm "calling a function"; when I'm invoking a user-
defined function, I'm "calling a function": from the semantic point of view,
there's no difference. So, if we stop the discussion here, there is no reason
for not allowing the user-defined guards. But if we go further and talk about
side-effects, it is clear that a user-defined guards *should not* cause any
change of state. So we could think to something like:
my_guard (X) -> ...
my_func (X) when my_guard (X) -> ...
This could solves two problems:
- the programmer is forced to understand that user-defined guards could be
dangerous and thus explicitly signal "safe" guards;
- the compiler must not analyze if a guard is user-defined, checking also its
subsequent other function calls, searching for a possible side-effects.
Now the issue is compiling user-defined guards, since they cannot be translated
into matching op-codes in function heads.
1. let the compiler to understand if the guard is a BIF or not, and behave
2. introduce another reserved keyword for user-defined guards, something like:
my_guard (X) -> ...
if my_guard (X) -> ...
Why? Once again, the programmer is completely aware that there are two
mechanisms in guards: BIF--side-effect free, fast and directly compiled--and
user-defined functions--with side-effects, not directly compiled, etc..
BTW.... at this point, I do not understand why standard Erlang "if" cannot
invoke user-defined functions: it is not a side-effect problem but I think that
it's related to the fact that an "if" is compiled like a "when". Isn't it?
IMHO, it is no so good to see something like:
case my_func() of
true -> ...
false -> ...
Eng. Corrado Santoro, Ph.D.
University of Catania - Engineering Faculty
Department of Computer Science and
Viale A. Doria, 6 - 95125 CATANIA (ITALY)
Tel: +39 095 7382380 Fax: +39 095 338280
+39 095 7382365
+39 095 7382364
Personal Home Page:
NUXI Home Page:
This mail sent through IMP: http://www.cdc.unict.it/
More information about the erlang-questions