related link

John Nilsson john at milsson.nu
Mon Feb 8 09:21:19 PST 2010


In my, admittedly rather naïve, mind such a static construct could
be modelled as transparent closures with the added restriction that it is to
in-lined at compile time, and as such would disallow any treatment of them
as run-time constructs. F.ex. moving references around would be a static
error.

The rather narrow goal in my mind being to allow "non-local returns" without
the scary stuff ;)

When you said "has been shown" did you have any particular paper in mind?
(I'm rather curious about PL-research)

BR,
John

On Mon, Feb 8, 2010 at 12:36 AM, Neal Gafter <neal at gafter.com> wrote:

> John-
>
> It hasn't been shown that a simple macro facility can support control
> constructs in a library in the absence of transparent closures (I'd welcome
> your attempt to do so).  However, it has been shown that transparent
> closures are sufficient.  Macros are nice in making the syntax of such
> control APIs more convenient; BGGA and CfJ 0.6b <
> http://www.javac.info/closures-v06b.html> address the convenience issue by
> supporting one particular but common special case (where a function is
> accepted by an API as its last parameter) rather than attempting to add a
> complete hygienic macro system.
>
> Cheers,
> Neal
>
>
> On Sun, Feb 7, 2010 at 2:50 PM, John Nilsson <john at milsson.nu> wrote:
>
>> It seems to me that project lambda fits better with, well, lambdas.
>>
>> The other goals would probably be better addressed with some static
>> construct, like macros.
>>
>> BR,
>> John
>>
>> On Sun, Feb 7, 2010 at 6:10 PM, Neal Gafter <neal at gafter.com> wrote:
>>
>>> Jesse-
>>>
>>> That article provides a good understanding of the goals of BGGA and CfJ
>>> 0.6a/b (and the openjdk closures project), as contrasted with the goals
>>> of
>>> the current effort (openjdk project lambda).
>>>
>>> Cheers,
>>> Neal
>>>
>>> On Sun, Feb 7, 2010 at 9:02 AM, Jesse Kuhnert <jkuhnert at gmail.com>
>>> wrote:
>>>
>>> > With no intention of implying that either language is close enough to
>>> > be compared directly,  just that it's a lengthy analysis of the
>>> > subject matter here which might provide more mental fuel.
>>> >
>>> > http://yehudakatz.com/2010/02/07/the-building-blocks-of-ruby/
>>> >
>>> >
>>>
>>>
>>
>


More information about the lambda-dev mailing list