statements that could be expressions?

Breton Slivka zen at zenpsycho.com
Fri Jun 3 03:34:23 PDT 2011


On Fri, Jun 3, 2011 at 6:19 AM, Waldemar Horwat <waldemar at google.com> wrote:
> On 06/01/11 18:47, Breton Slivka wrote:
>>>
>>> Yes, if you make it mandatory to parenthesize statements then this would
>>> work, except for the important case of blocks.
>>>
>>>    Waldemar
>>
>> This might be a pretty radical (or stupid) thing to ask, but what if a
>> block with labeled statements were semantically the same as an object
>> with expression lambdas, or completion values assigned to its keys?
>> Then perhaps the syntactic conflict wouldn't be a conflict at all, and
>> a break [label] would be a call of the lambda at
>> [parentblockobject][label]
>> .
>
> In your proposal what are the values of the following expressions?


Well, to be backward compatible, blocks should be evaluated as they
are read. this is no different from the values in an object. so,
thinking carefully through these:

({x: y}) // an object with a key, x, that contains the lambda (->y)
({}) // the empty object/lambda
({x}) //the lambda (->x)
({x, y}) // the lambda (-> x,y)
({x; y}) // a lambda equivelent to (-> x,y)
in addition..
({|x| x*x}) // the lambda x -> x*x

this would turn an object into something that is callable like a
function, and assuming the duties that were normally the specialty of
a block. an object with no properties can still contain an expression
or list of expressions, which are callable. When an object has
properties like in the first example, normal property access retrieves
the "value" of the expression/lambda contained on that key- so
property access with potentially lazy evaluation.  the keyword "break
[label]" occuring within the same object would be an explicit flush of
the stack, and calling the lambda at that key- essentially a tail
call.


Though I will concede now that there's likely a lot of gotchas with
this idea that I haven't really thought through very clearly, like the
nature of a value that is callable like a lambda.


More information about the es-discuss mailing list