Re: condition systems?

[Dave Long <address@hidden>]

>               Another [interesting aspect] is that it gets you
> thinking of invariants - "if this process fails for _any_ reason,
> then", rather than "if this socket bind() fails, then.."

If a lightweight language is one which
is easy to acquire, learn, and use, it
sounds like it would be better to have
effective ways to reduce the number of
accessible program states than to have
methods which tend to increase them.

One reconciliation of failfast with a
frugality of control flow is to behave
transactionally, ensuring (at least at
source level) that sequential updates
have either all or none done.  Instead
of a lattice of states, we have two to
worry about.

In this case, the alternative use of
individual conditions (dynamic bound
non-local exits?) to manually handle
each of many cases with "some done"*
seems heavyweight by comparison.

-Dave

:: :: ::

* points in the interior of the lattice
above, of which "the bind() wasn't done" 
is but a small part, and "all done" and
"none done" are the extremes.