[plt-scheme] to define, or to let

Anton van Straaten wrote:
> It's not just about implementations and compilers, though.  Code
> involves communication to other humans, also, and this is often the
> more difficult part of its job, or at least the one it does less well
> (since by some accounts, too much effort has been put into doing
> compilation well).

I agree that communicating with other humans is much more important than
giving hints to a mechanical optimizer, although I'm loath to completely
ignore the latter. The LET vs LET* thing is nice because it lets the
programmer encode his intent for the benefit of both humans and the
compiler.

> The unspecified eval order constructs allow programmers to document
> their intent, and that can be important.  If they make an error and
> their documented intent doesn't match the program's actual semantics,
> that's an error.

That's how I see it too.

> The concern is that this sort of error is a difficult one to catch,
> and from a formal semantics perspective it's a doozy, which raises
> bogeyman terms like unsafe, unsound, unpredictable, unverifiable and
> non-deterministic (in the bad sense).

Yeah, it's ugly, but it's a trade-off. If you allow "sequence doesn't
matter" constructs, you can end up with ambiguous program behavior. But
if you remove them, you get ambiguous program meaning. I would much
rather have the former than the latter.

> There's a simple solution to this, and it's one that most implementations,
> including PLT, can be seen as already using (although they don't say so
> explicitly).  That is, within any single implementation, a fixed evaluation
> order can be used, which gives even erroneous programs a predictable
> semantics.
> 
> However, even if an implementation guarantees a fixed evaluation order, I am
> suggesting that this should not be taken to mean that it is acceptable to
> rely on order dependency in constructs like LET, or ordinary argument
> evaluation.

I agree that this is a reasonable implementation choice, and I agree
with your advice to users. I'd personally prefer an implementation that
uses a "perverse" fixed order (i.e., anything but left-to-right). That
will catch many trivial cases, especially newbie mistakes where the user
is simply ignorant of the fact that LET means "sequence doesn't matter."
In other words, it discourages users from relying on the safety net.

More generally, when a language offers unsequenced constructs like LET,
I prefer implementations that either (1) try to detect unintentional
misuse of those constructs, or (2) use the information for optimization.
The first choice favors correctness, and the second favors efficiency.

> I would explain the issue of code communicating to humans as well as
> compilers.

Definitely.

> Finally, I would claim that on certain days, such as Halloween, the
> language's icon would be replaced by a scary face.  On these days, you would
> not be able to depend on argument evaluation order in constructs that don't
> guarantee it.  If you have been a good girl or boy and written your code
> correctly throughout the year, your programs will not break.  If you have
> not been good, then your soul will be unsafe, its likely fate unverifiable.

Great idea!
-- 
Bradd W. Szonye
http://www.szonye.com/bradd