Enhanced type guard syntax]

[Martin J. Logan]

Erlang and concurrent programming relies on good programmer practice to
create reliable, comprehensible programs. Many of these idioms are
embodied in OTP. Still one can choose to use OTP or not, and if not
still write reasonable programs. Some things are too scary to leave up
to idiom and the good conscience of any erlang programmer. While more
type checking would doubtless provide some benefit to the programmer
user defined guards at the same time opens the door for real
inconsistency and uncertainty if one is not well informed and
painstaking in writing them. 

I call this with func(d, Arg).

func(a, Arg) when user_side_effect(Arg) -> a;
func(b, Arg) when user_side_effect(Arg) -> b;
func(c, Arg) when user_side_effect(Arg) -> c;
func(_, Arg) when user_side_effect(Arg) -> error.

I assume that only the fourth function will ever be executed. I
consequently assume the expressions associated with expression 4 is the
only expression having the potential to influence the state or
*significant* timing of my system. This assumption is based on the
assumption that the people writing guard expressions are following the
strict rules associated with writing such an expression. This would all
go out the window if guards are not considered sacred anymore. 

If user defined guards were to be allowed some other language/context
would have to be devised to write them. This language would provide the
necessary safeguards - like no messaging or "put" calls and such.
Basically it would not allow much past a basic declarative syntax for
defining the structure of a thing and perhaps some ability to define
these things recursively. Think we've seen this before in many other
type systems. That is fine for erlang if anyone could ever implement it
without crippling what is erlang. Having users create there own type
system, in essence, for every function(user defined guards) seems like a
no no. 

Cheers,
Martin 

On Thu, 2003-09-18 at 08:57, Joe Armstrong wrote:
> On Thu, 18 Sep 2003, Fredrik Linder wrote:
> 
> > > foo(A/integer, B/integer) ->
> > >       A * B.
> > >
> > > {X/float, Y/float} = graph:coordinates(),
> > 
> > This looks really really nice!
> > 
> > Again, I'd like to ask for user-defined guards, as it would really enhance
> > ... erlang(?).
> > 
> 
>   No - guards are extensions of patterns. They have to be  simple, 
> so that a pattern matching compiler can do a good job on them.
> 
>   If we had user defined guards somebody will write:
> 
> 	foo(X) when bar(X), a == b ->
> 	   ...
> 
>   Where bar(X) a user defined guard.
> 
>   Now what happens if somebody writes:
> 
> 	bar(P) -> P ! a, true.
> 
>   But the guard fails (ie a==b) fails, did the message get sent?????
> 
>   Cheers
> 
> /Joe
>