OT: Project Idea: Aristo - A Framework for Embedding and Integrating High-Level Languages

[Shlomi Fish]

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.