John Rose schrieb:
> 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.
frankly I am not sure I like Strings here... there would be other ways
to encode such meta information...
1) use sig for basic function and first argument for name
for example x.foo:
was: Dynamic.<Dynamic>#"field:foo"(x)
now: Dynamic.<Dynamic>#"field:"("foo",x)
The advantage is that no name mangling is needed for the name part.
True for a fixed set of names there is no problem at all, but for
arbitrary method names name mangling may give a performance penalty
here. I am thinking here of situations in which the method name is used
to check something, or to call something. The disadvantage is that
"field:foo" cannot be used directly for a map... still you can use
"field:" for maps an "foo" for a map returned by "field:"
2) use sig for name and first argument for function
Dynamic.<Dynamic>#"foo"("field:",x)
here name unmangling could be done by the VM!
2a) use int for function
Dynamic.<Dynamic>#"foo"(CONSTANTS.FIELD,x)
not much different from 2, only that a int constant is used instead of a
string, which enables the use of an array for example, instead of a map
3) use a object structure for "field:foo"
>> 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.)
no only the static type, also the dynamic type would be interesting ;)
> A. Whether a transmitted argument is spread or not (as with Lisp &REST
> or Groovy *x; affects calling sequence adaptation).
true... FYI.. we have also foo(*x), which means we put all the elements
of x on the stack and then call foo with those arguments. That means
spreading already happens before the method is called. So we need no
meta information for this here.
> 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).
but here we have to commit to a fixed set of inter language key words.
For example Groovy's as operation, which is an extended cast operation,
does not fit "as" in http://wikis.sun.com/display/mlvm/DynamicJava, but
I guess it would be "operator:as"?
> D. If it matters, whether a transmitted argument is an appended block (f
> (x) {y}).
can't you see that by the type of the argument?
> E. Whether two or more transmitted arguments are to be grouped logically
> as one. (For type complex, say.)
what is the usage for this?
> 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.)
if it is to hide, then why give it?
[...]
>> 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.)
not sure how you want to represent this, but if as string, then be aware
that this will soon need a parser ;)
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" 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/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
