On Apr 22, 2009, at 4:14 PM, Tobias Ivarsson wrote:
> 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;)
Yes, thanks! Though the keywords might have to be syntactically
segregated more carefully than that.
> 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?
There is a large-ish set of argument annotations which do not affect
the way the arguments would be stacked but are syntactically present
at the call site, and are significant to function linkage or runtime
typing. (The most important is the static JVM type of the stacked
argument, and that is separately conveyed in the call site's signature
descriptor.)
A. Whether a transmitted argument is spread or not (as with Lisp &REST
or Groovy *x; affects calling sequence adaptation).
B. Whether a transmitted argument is a (reified) type parameter (as in
Scala f[x] vs f(x); not sure when/if they are reified, though).
C. Whether a transmitted argument is keyword-modified (and by what
keyword).
D. If it matters, whether a transmitted argument is an appended block
(f (x) {y}).
E. Whether two or more transmitted arguments are to be grouped
logically as one. (For type complex, say.)
F. Whether a transmitted argument is to be hidden from the receiving
method. (Perhaps it is an implicit argument to a parameterizable
calling convention; can't think of an example. B above is a special
case of this.)
Many of these annotations need to shake hands with corresponding
definition-site parameter annotations.
Perhaps we do need a postfix notation, as method:foo:(:...:):.
Parameter annotations would correspond positionally to stacked
arguments. To extend the straw man to your example:
> function(positional1, positional2, key=val1, other=val2)
method:function:(:,:,:keyword=key:,:keyword=other:):
or, when presenting to polite human company, rely on ordinary
(complex) conventions for presenting token-based expressions:
method function(-, -, keyword=key, keyword=other)
Note that the latter notation isn't necessarily accurate encoding,
since a keyword might be an arbitrary string, including one containing
a comma. (No language uses this particular degree of freedom AFAIK,
but it would be crazy to build symbol spelling restrictions into a new
MOP.)
To transmit two attributes with one parameter, separate them by (say)
a plus token:
method function(-, -, notnull + keyword=key, keyword=other)
-- John
P.S. The colons are tiresome as token separators. I think any normal
presentation of these structured names would use spaces and other
normal tokenization conventions. But the internal "mangled" form
needs to take into account the fact that at least some name components
will need to be arbitrary unlimited strings. For that purpose, a
colon is as good as any other character.
P.P.S. Another thing I forgot is the send-super vs. normal-send
distinction; something like super:method: instead of method:, etc.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
