newbie question

[Thomas Lindgren]

--- "Thomas Johnsson XA (LN/EAB)"
<thomas.xa.johnsson@REDACTED> wrote:
> There are situations where it is important that
> guards are fast and side effect-free (in receive,
> for example).
> Conditions in if-expressions is *not* one of those
> places, IMHO. (Except for the usual good reasons to 
> to program as 'functionally' as possible).
> Ie, there is no reason that I can see why the
> if-condition has to be a guard syntactically rather
> than an expression.
> I just forces the programmer to write something more
> clumsy.
> 
> Or is there some light I haven't yet seen?

For what it's worth, I nowadays tend to agree with
you.

(Also, as an aside, it might be worth noting that a
'cond' expression was floated some time ago, which as
far as I could tell was more lenient. But perhaps we
can for once use Occam's razor and not multiply
entities without necessity.)

As far as I can tell, there are three problems with
arbitrary guards:

1. Guards should run quickly. Since there are
non-constant time guards already, this does not seem
to be a big issue in practice. It may be related to
point 2.

2. Suspending a process inside a guard is/can be
messy. But this seems to be essentially an
implementation restriction. From the compiler PoV,
there is no real problem. (The system can suspend
inside the case-expression we were forced to write
instead, after all, though receives will need some
attention.)

3. Side-effects inside guards are difficult to reason
about. There are two solutions I can see: (cheap and
cheerful) leave it up to the programmer (motivated
below), or (nicer) check a flag before doing a side
effect. If the flag is set, fail/throw an exception.
Manage the flag appropriately when doing function
calls in a guard.

(As a historical note, the concurrent logic
programming languages contemporary with Erlang's
design also had problems with guards, and restricted
them to "flat", simple tests; but those problems were
related to concurrency and are really not applicable
to Erlang, as far as I can see.)

In summary, my main gripe with guards echoes yours: if
keeping guards restricted means we have to write
convoluted case-expressions instead of guards, what
have we gained? The case expression can behave however
it wants, so the guard restriction has not helped.

The root problem, I suspect, is that we want to write
modular, abstracted code, and restrictive guards
merely guide us away from using them.

So, IMO, guards could instead be generalized to
syntactic sugar for real expressions with no loss to
the language.

Best,
Thomas



		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html