Allen's lambda syntax proposal

Jon Zeppieri jaz at bu.edu
Mon Dec 8 07:20:20 PST 2008


On Mon, Dec 8, 2008 at 4:01 AM, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
> Breton Slivka wrote:
>> On Sat, Dec 6, 2008 at 9:57 AM, Michael Day <mikeday at yeslogic.com> wrote:
>>
>> > (1) Expression lambdas: lambdas whose body is an expression.
>> >
>> > var x = lambda(y, z) y + z
>> >
>> > Solves the problem with completion leakage, solves the nested
>> > return/break/continue issue. However, quite limited in usage, and makes it
>> > difficult to use lambdas to replace functions as they can't contain loop
>> > statements. (Hello, recursion! :)
>>
>> [snip]
>>
>> 2) It would be really nice to have a callable value that was
>> garaunteed not to have side effects. a lambda with an expression body
>> might not be that. Nevertheless, this would enable a parallelized
>> array "map" function that's safe to use. In the absence of "real"
>> multithreading, this kind of parallelism would be a boon for
>> applications like 3d games, or image processing.
>>
>
> This little comment got lost in the recent deluge of emails, but I too
> would really like some mechanism to avoid or see if a function causes
> side effects (and not just mutability).


Without a static type system, there's very little you can do.  For
example, let's say you wanted a guarantee that a call to some function
F doesn't mutate any variables.  A simple analysis can determine
(conservatively) that F's own code doesn't perform any assignments,
but the problem is that you also have to prove the same property for
the entire possible call tree rooted at F.  So, if F is passed a
function and (potentially) calls it, that function has to be proven
pure, as well.

Sure, you could abandon the proof requirement and turn it into an
assertion, so that if F is annotated as "mutation-free" and if, at
runtime, it tries to perform an assignment, an exception is thrown.
But this doesn't work so well for other computational effects.
Throwing an exception itself is an effect, and it would be pointless
to throw an exception when your code illegally attempts... to throw an
exception.

Non-termination is an effect, and it's notoriously immune to runtime checks.

I/O effects are possibly the most interesting from a practical
perspective, but they're outside the scope of the ES standard.

-Jon


More information about the Es-discuss mailing list