RE: Y Store /Closures

["Anton van Straaten" <address@hidden>]

Robby Findler wrote:
> Regardless, it's not clear to me that you really want to program in a
> language which leaves out important details of the semantics like order
> of evaluation.

That's only an important detail of the semantics in a language with side
effects, of course - although perhaps you're also saying that you don't want
to program in Haskell :)

Still, there's a functional-style discipline that's encouraged by requiring
that special constructs be used to sequence side effects.  It acknowledges
and calls attention not only to the presence of side effects, but also to
the need for them to be sequenced.  It can separate pure functional code
from imperative code.

Pure R5RS Scheme allows side-effects in contexts where evaluation order is
unspecified, and the result is a non-deterministic language.  Defining an
evaluation order in actual implementations makes it deterministic, which is
fine.  That doesn't mean you should rely on that order unreservedly,
however.  After all, Scheme supports a fully imperative programming style if
you want it, but it's not generally considered good form to use (set! i (+ i
1)) inside loops, for example.

A purer way for the language to deal with sequencing of side effects would
be to only allow side-effecting operations where there's no possible
ambiguity about evaluation order, such as inside sequencing constructs.
That would produce a purer language than Scheme, which an R5RS-conformant
implementation can't do.  But you can still write code as though you were
using such a language, and it has the stylistic benefits I've mentioned.

Anyway, I think it's sort of weird to be relying completely on the use of
CPS transformations while writing imperative-style code, even if it does act
as a proof of concept for "PLT BASIC"...

Anton