Why no is_octet(N) guard?

[Corrado Santoro]

> 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_alpha_numberic,
>  > 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 <kostis@REDACTED>:
> 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:

-module(test).
-safe([my_guard/1]).

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.

Proposals:
1. let the compiler to understand if the guard is a BIF or not, and behave 
accordingly;
2. introduce another reserved keyword for user-defined guards, something like:

-module(test).
-safe([my_guard/1]).

my_guard (X) -> ...

my_func (X)
  when is_atom(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 -> ...
end,


Ciao,
--Corrado

-- 
====================================================== 
Eng. Corrado Santoro, Ph.D. 
 
University of Catania - Engineering Faculty 
Department of Computer Science and 
Telecommunications Engineering 
Viale A. Doria, 6 - 95125 CATANIA (ITALY) 
 
Tel: +39 095 7382380           Fax: +39 095 338280 
     +39 095 7382365 
     +39 095 7382364 
 
EMail: csanto@REDACTED 
Personal Home Page: 
            http://www.diit.unict.it/users/csanto 
 
NUXI Home Page: 
            http://nuxi.iit.unict.it 
======================================================

-------------------------------------------------
This mail sent through IMP: http://www.cdc.unict.it/