I knew I should not have posted that without re-reviewing FCM, which I'm rather rusty at. Thanks for correcting me, John.
I'm also intrigued that anyone would have serious interest in a closure proposal that did not support long returns, but did support functional (structural) types. Le sigh - that means that you can effectively consider 4 closure proposals: 1. Long Returns, Structural Types. (BGGA) 2. No Long Returns, Structural Types. (FCM) 3. No Long Returns, No Structural Types. (CICE) 4. Long Returns, No Structural Types. (None of the proposals I know of, but in my opinion the right answer). While syntax issues can always be toyed with and modified without changing the guts of any closure proposal, and even the notion of adding delegates (heavily used in FCM) can easily be added or expanded upon in any of the other closure proposals, long returns v. no long returns, and structural types v. no structural types, has deep impacts that cannot easily be changed later. You could graft long returns on FCM or CICE later, but once you've already used 'return' for the notion of a local return, then a future long return addition can never be transparent - you'd have to have a different syntax for returning out of the containing block, which all by itself is a pretty big negative mark - that would mean that any attempt to add language features by way of just writing a utility method are permanently crippled by the fact that the 'return' syntax is not transparent, and thus the need to know that something is a library call instead of a language feature will always be a leaky abstraction. Similar story for structural types: Once they exist you can't undo them. Trying to graft structural types on CICE syntax would be all sorts of weird. On Jan 13, 8:59 pm, "John Nilsson" <[email protected]> wrote: > On Tue, Jan 13, 2009 at 11:19 AM, Reinier Zwitserloot > <[email protected]>wrote: > > > 1. BGGA has structural types. You could have a List of (int, int => > > double)s, in BGGA. The idea of a function that takes 2 ints and > > produces a double is itself just as much a type as a "String" or an > > "InputStream". In all the other ones, you don't get these. Instead you > > have to create an interface with 1 method in it. > > Actually in FCM the type would be #(double(int,int)) > > "Method types will be implemented as a compiler-generated interface. > Considerable investigation and study of the implementation of this concept > has already been undertaken as part of the BGGA proposal [4] (function > types). As such, we don't attempt to duplicate that work here." > > http://docs.google.com/View?docid=ddhp95vd_6hg3qhc > > Just as a datapoint. Long returns kind of frightens me so that is why I'm > currently more interested in FCM. > > BR, > John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
