I don't know on what level this should be handled, if it should be under the python: specific part or if it's something general, but I would like to add keyword arguments to the mix.
So that a call that on the syntactic level of a language looks like this: function(positional1, positional2, key=val1, other=val2) could get translated into something like: keyword:function:key:other (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;) Although that only works for keyword arguments as they are permitted in Python, which is after any positional arguments. For languages that allow mixed keyword and positional arguments we need some other pattern. Comments? Suggestions? /Tobias On Thu, Apr 23, 2009 at 12:15 AM, John Rose <john.r...@sun.com> wrote: > > Hi Attila, and jvm-l-ers. As some of us discussed around the JVM Lang > Summit last year, invokedynamic forces the question of naming, since > it uses strings as request IDs. I wrote up some questions about this > here, and copied below FTR: > http://wikis.sun.com/display/mlvm/Nomenclature > > Enjoy, > -- John > > Nomenclature is important to a JVM MOP since the main programmable > channel in invokedynamic is a name string. Based on the mangling > convention described earlier, we will used colon delimiters to > structure names into simple token sequences, and use those structured > names to manage linkage across the JVM and across languages. > Here are some key questions in designing such names. > > 1. Should the names be reasonably pleasant to read (modulo mangling > effects, which can be hidden in polite company)? Default answer: yes. > The dynamic Java design sketch in this wikiuses simple keywords, and > they seem to read well. > > 2. How does a language (or other MOP player) reserve a part of the > namespace? Is it enough to say that certain early adopters get short- > hand prefixes like ruby:, python:, etc? Probably. Eventually we'll > need something like fully qualified names, like :com.acme:acmeslang: > > 3. Does the notation allow elision? For example, if every MOP-name in > a compilation unit belongs to AcmeSlang, maybe we can declare that > acmeslang: is optional. But, there should be (a) a way to escape to > other name spaces, and (b) no need for an escape to access standard > prefixes like method:. Another way of phrasing this is, can you say > the equivalent of import acmeslang:*, issue names like event:foo to > mean AcmeSlang events, and then issue fully qualified ZeugmaChat names > like :com.zeugma:event:bar. I thinks this kind of importing or context > sensitivity is important, that conciseness of bytecodes is a medium- > important goal. > > 3. What are the common notions that can be permanently imported? > Anything that the JVM defines natively needs a name. This includes > method: and field: and element: and perhapsclass: (if a class or > interface can be an operation--and if class:x then also just int, > boolean). Certainly new:. Maybe array element getters and setters > Maybe also set:field:. > > 4. Also there are well-accepted notions which might as well be common > across languages. Those native to the JVM all have natural > generalizations to this level (e.g., element applied to a list or > other collection, new applied to factory or mixin APIs). There are as: > (conversion) and operator: (symbols which appear as non-name > operations), and perhaps even if: and for:, although these probably > fall down into language specifics. We need a notion of events for > reactive or event-driven programming in the relevant languages. > > 5. The notion of imperative side effects factors tantalizingly across > most operators (field, element, method call). This probably means we > need a nomenclature syntax for inverting a getter name into a setter > name, regularly. Hence the set: prefix, as in set:field:f, set:method:f. > > 6. Similarly, there are other modifiers that factor across some of the > other constructs: Null handling notations foo?.bar, multiple-value > notations foo*.bar or foo(*bar), complex get/set patterns foo*bar = > baz or foo() += bar. How are these extra conditions mixed into the > basic selection of field/element/method? Are these extra notations > mixed in as prefixes (}}nullable:method:foo}}) or suffixes > method:foo:nullable? Probably prefix-only, to avoid ambiguity. Or is > there a way to mix several syntactic aspects together on an equal > footing? (Yikes!) > > 7. How do we leave open spaces for reified generics, if the JVM gets > them, or if a language chooses to simulate them? This is another > (complex) case of name modification. Keeping the prefix convention, > but adding bracket tokens, maybe we have of{:int:}:class:list. > > 8. What other degrees of freedom are needed for structured names? > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
