I've been thinking a lot about this lately -- I'm working on my composite dynamic invocation resolver framework (which is probably a more correct term for it than "MOP over invokedynamic" :-) ) but for now I'm hacking the lower level infrastructural bits - automatic discovery and composition of available resolvers. I haven't yet got to the point of nomenclature, although it is of course also of paramount importance.
My current thinking is to create the nomenclature conventions in such a manner as to allow a significant amount of flexibility to caller to identify the desired call target. Acting on the assumption that linking is supposed to be infrequent for any particular call site with a monomorphic cache, I think that the names could carry quite a lot of information and actually be close to an URI scheme. Of course, there should be a sweet spot somewhere in there. On the one hand, a too rigid call target identification convention will be in danger of becoming obsolete in the future. A too open one runs the risk of placing a too big burden on individual language runtime implementers to provide target resolutions for too many obscure cases (which would hinder adoptions, I mean, if JRuby would create a "ruby:" scheme, and Jython a "python:" scheme, and Rhino a "javascript:" scheme, then they'd all need to mutually understand one another's scheme, that's not really interoperability, is it? Or rather it is, in the sense that every runtime accommodates semantics from all the others, which is an O(n^2) proposition for n languages and it's precisely the intent of a MOP to dwindle that down to a more manageable size). Some of the usual contentious cases that crop up are distinction of addressing an object's property vs. an element of an object that has container semantics (where such a distinction is applicable and desirable, i.e. in JavaScript it is not even applicable). I'm glad you seem to have tackled this already in your nomenclature proposal. I think that even if we define some usual operations ourselves up front, we should probably create a separate namespace for them to denote "usual Java semantics", maybe just use "java:", or "dyn:"? i.e. "java:operator", "java:for" etc. I'd even go as far as to not even leave normal method calls unadorned. Where you'd call method foo, I might go for Dynamic.<Dynamic>#"dyn:call:foo"(a,b,...) Of course, it's possible that I'm falling into the trap of too many indirection levels here - a dynamic call naming syntax for dynamic call :-) It's just that I like to have everything nicely compartmentalized, so the idea of actual functionality encoded at the namespace top level feels uncomfortable. Anyway, I've finally added comments to both <http://wikis.sun.com/display/mlvm/DynamicJava > and <http://wikis.sun.com/display/mlvm/Nomenclature> with some more refined versions of all the above rambling :-) Needless to say, my day job is very efficient at not leaving me much time to spend on this, so I'm reacting slowly - apologies for that. BTW, what's the preferred discussion venue for this? Those wiki pages, or this e-mail thread? Attila. On 2009.04.22., at 10:02, John Rose wrote: > Oops, and for the MOP stuff, I wrote up some notes on (a possible) > canonical encoding of Java constructs as invokedynamic expressions. > It was a initially part of my Project Coin proposal, except I > deleted it on the (reasonable) grounds that it is too much too early > to bake into the language. > > Some variation of this encoding should become (part of) a MOP for > JVM languages. Since you are inventing such a thing now, I thought > I'd share my notes, even though they are half baked. There are > specific subtle choices in the rendering side-effecting operators > which allow a wide range of (both imperative and functional) data > structures to be usefully bound to operators like ++ and +=. Also, > the treatment of && and ||, taken from Lisp, obviates the need for a > separate "Elvis" operator. > > Enjoy: > > http://wikis.sun.com/display/mlvm/DynamicJava > > -- John > > On Apr 22, 2009, at 12:29 AM, John Rose wrote: > >> Thanks, Attila, for jumping in with the MVLM build stuff.... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
