On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
[Referring to infix operators as an alternate syntax for a named method call]
What's the downside of compiling this code in this way? If you are a Python programmer and all the objects that you are dealing with were created by Python code, then not much. However, if somebody wanted to create a language independent complex number implementation, then it wouldn't exactly be obvious to a Python programmer how one would raise such a complex number to a given power. Either the authors of the complex PMC would have to research and mimic the signatures of all the popular languages, or they would have to provide a fallback method that is accessible to all and educate people to use it.
Yes, and I think that compiling using ops makes things worse, because of languages such as Java which don't have operator overloading, so you'd have to make all functionality available as method calls anyway, so why bother with the ops? Methods are much more flexible, and don't bloat the VM.
Ultimately, Parrot will need something akin to .Net's concept of a "Common Language Specification" which defines a set of rules for designing code to interoperate. A description of .Net's CLS rules can be found in sections 7 and 11 (a total of six pages) in the CLI Partition I - Architecture document[1].
I think that ultimately, code will break down into two categories:
1) Code designed with multiple langauges in mind. 2) Code designed with only one language in mind.
Code in case (2) will be awkward to use in other languages, but it should definitely be possible to use it somehow. For case (1), we need to make this easy for library authors to do.
In terms of method naming, we may want to do something automatic ("if you name your method such and such, it will appear to Python named this, and Ruby named that, and Perl named..."), or it may be better to provide an explicit way to create language-specific method aliases. Some cases are simple ("__mul__" in Python and "*" in Ruby and "multiply" in Java should all map to the same method for mathematical objects, probably), but others are more subtle (adding two array-like things means something different in different languages, potentially: append v. componentwise add v. componentwise add only if they have the same length). Doing something "automatic" saves a bunch of redundant work in the former case, but could cause problems in the latter.[1] And whatever the approach, it should be possible (even easy) for someone to take a library designed for only one language, and provide some cross-language mapping info and turn it into a nice cross-language library, without necessarily having to dig into the source code. (I'm thinking here of being able to specify the mapping in a document separate from the source code.) This is sort of treating method names as part of the interface, and not the implementation.
[1] Automatic mapping could also cause problems in the case where I design a library and intend it to be cross-language, but where I want the API to look identical across langauges--I don't want to accidentally trip over a method name which happens got get "translated" for me, when I don't intend for that to happen. (For instance, I might name a method "pow" which controls some power level, not intending anything about exponentiation.) But, this wouldn't be a problem if the "automatic" approach were to let me somehow register a method as filling a certain role ("my method 'blah' should be called to perform numeric addition"), rather than inferring to from the method name. Probably a tricky balance between convenience and control/flexibility.
JEff
