Semantics and abstract syntax of lambdas

Jon Zeppieri jaz at bu.edu
Fri Dec 5 21:01:44 PST 2008


On Fri, Dec 5, 2008 at 9:20 PM, David-Sarah Hopwood
<david.hopwood at industrial-designers.co.uk> wrote:
>
> Semantic or abstract-syntax issues that are not settled include:
>
>  - how to avoid the hazard pointed out by Mark Miller where a value
>   can be unintentionally leaked from the tail position of a lambda;

Can we take a step back?  Before determining "how to avoid the
hazard," perhaps we should discuss whether it's worth avoiding.

First, a question for the people who see a hazard here:  is the hazard
somehow peculiar to the ES lambda proposal?  Because from Mark's
description, he would have equal justification for citing a hazard in
the design of Scheme, Lisp, &c.  Since I've never heard a schemer
complain about this before, I'm more than a little skeptical of the
danger.

Here is Brendan's example:

   lambda (secret) { compute(secret); void 0; }

Brendan notes that "too few will remember to [add the void statement],
so implicit return values will tend to leak."

Should I read this as "too few ES programmers, who aren't used to
expression languages, will forget... &c."?  If so, then why does
anyone suspect that people unfamiliar and uncomfortable with
expression languages will abandon functions for lambdas?  If not,
should I draw the conclusion that expression languages are
intrinsically broken?  (I'm not buying that.)


>
>  - whether the primitive form of a lambda has a block, statement, or
>   expression as its body;

The only problem with the proto-proposal to limit lambda bodies to
expressions (which is otherwise a good idea) is that the ES expression
sub-language isn't powerful enough.  The ternary expression is awful
for conditionals more complex than "if a then b else c."  Without a
let expression, people would be nesting immediately applied lambdas,
which quickly becomes unwieldy.  Without a letrec expression, they
would be forced into vomit-inducing syntactic horrors to bind local
recursive functions.

So, unless people want to expand the expression grammar significantly,
I think the expression body is a nonstarter.

A statement body (as opposed to a block body, I mean) just seems
bizarre.  Does it have some advantage?  For now, I think Dave's
proposal wins.

-Jon


More information about the Es-discuss mailing list