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
-~----------~----~----~----~------~----~------~--~---
