I just returned from a dinner a few members of the Linux Israeli scene had with Richard Stallman (of GNU fame), as he his now visiting Israel. I got the opportunity to talk with him, and asked him the GNU project insistance of using guile for extensibility. He said the reason for that was that converting any other language to Scheme was a good a choice out of the fact Scheme was so simple, powerful and generic. I said converting Perl 5 code to Scheme would not be too trivial at all, and he said that was the case for converting Perl to almost everything else. :-) (despite this joke, I'm sure converting many languages to Scheme would be incredibly problematic) Then I noted that they should try the GIMP approach instead: and use a procedural database to integrate several languages back-ends. Then, he said that the type system would not be flexible enough for that. After a while that it was a challenge: create a bridge in ANSI C, that will be flexible enough to interoperate code between many virtual machines: perl 5, python, Ruby, Java, Haskell, O'Caml, etc. The codename is dubbed "Aristo", which is the Hebrew pronouncation and spelling of "Aristotle". (it's simpler and without the "totel" at the end). Now what I need is some advice on designing a type system: OK, I can have arrays of ints, and associative arrays from strings to ints, etc. But an array of records whose one field is an array of ints, the other a linked list of strings, the other an associative array from floats to this record itself, is something I'd rather not have to do type interference with. (usually you don't need such strict typing requirements). Here are some of my ideas, so far. Let me know what you think: 1. Aristo can only be written in ANSI C. Any other language will be unacceptable, as all implementations of the back-ends are written in ANSI C. 2. Aristo should have a nice nested namespace organization, with import and export features, package-scope globals etc. The gimp flat list (in which namespace collision is maintained by prefixes) is not scalable. 3. There should be a union type which is a type identifier followed by the type value, which could assume any value. It is possible some types will not be unions and will be plain types without the type value. 4. A standard enum can be used to store the object meta-type, and a standard pointer/long union can be used to store the data. Almost anything will be done using indirection. 5. Types should be declared using a machine-readable type definition, that can be understood by humans. 6. Maybe I can take a look at GIMP PDB for code and ideas, but probably not much. From my impression it's more of an ad-hoc system for the GIMP. 7. A procedure can restrict the types that pass to it, but I'm not sure to what extent. 8. I'll have to translate between conventions of different languages inside each language back-end. 9. It's first implementation will probably not have all the functionality I'd like it to have, but better to release early and release often. Your ideas and comments are most welcome. At the moment Aristo is at the pre-coding stage. (I'm just thinking about its design). But I'd rather have something well-designed and well-scrutinized in mind before I start actual coding. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif@vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ He who re-invents the wheel, understands much better how a wheel works.