Erlang language issues

[Ulf Wiger]

On Wed, 17 Apr 2002, Richard Carlsson wrote:

>On Tue, 16 Apr 2002, Thomas Lindgren wrote:
>
>> [deep guards]
>> I'm a bit ambivalent about permitting "deep guards", however.
>>
>> What do we define as a side-effect, for instance? _Reading_ the
>> database? Permitting long-running guards means we must be able to
>> context-switch inside the guard, which means the database can change
>> while we run the guard, which might be construed as an impurity.
>> (And what about read locks?) And so on.
>>
>> I believe the original restriction on guards comes from concurrent
>> logic programming, where "deep guards" had severe problems and
>> ultimately led to disallowing them.
>
>Thanks - that saved me from trying to explain this point. I also
>believe that although we might be able to extend guards in
>Erlang somewhat, and remove some strange syntactic limitations,
>we will probably never have "deep guards" - they come with deep
>problems, especially with things like context switching. (And a
>special syntax for declaring guard functions does not fix this.)
>
>	/Richard

In some way this is perhaps similar to the previous discussions
on match specifications, where posters, self() included, have
suggested a more erlang-like syntax.

http://www.erlang.org/ml-archive/erlang-questions/200010/msg00223.html

Basically, a fun() or similar could be used as a guard (or match
specification) iff it is obvious to the compiler that it is (1)
shallow, (2) pure.

/Uffe