I had accidentally sent a message only to DeRobertis
that proposed we use a modular plugin like system
for the specific syntax of the interpreter.
The specific advantage I saw was we could create
a GermanTalk, and a FrenchTalk, along with an
AmericanTalk. For the hard core people a CTalk,
and a C++Talk could be created.
We of course would only maintain the ones we
used and let others maintain the ones they care about.
The reason I recommend this is the opportunity to
use one's native language to program in makes for
increased productivity.
DeRobertis wrote:
> Please do consider what happens if I, on an American OC system open a
> German OC stack in your proposal. This would probably be the basis for any
> attack I'd have on the idea.
I've considered this and I saw three possible solutions. Then I
combined two to create what I consider to be a workable solution.
1) Unless you had the german interpreter installed on your system
you would be unable to open the stack. The stack would keep
all it's original code. So unless you know German, or are
intimately familiar with the OC bytecodes and can use a
hex editor, you would be unable to modify the scripts in an
intelligent manner. People from other countries would just
know that's the way it was. We would probably start with
this because it doesn't prevent us from doing anything in
the future and allows us to focus on building an interpreter.
2) If you had the American decompiler installed on your system,
the German stack would get decompiled into its American
equivalent because the decompiler deals with the bytecodes
not the German. This of course means that there would
be no translation for variable names and comments (if that
information even makes it into the binary stack file).
This would be the heart of the sharing mechanism. If we also
implemented the concept of "style themes" for the editor,
we could get around the annoyance of having our code
reformatted for us. The capitalization, and code structure
would be defined by the "theme" which could be individually
tailored. The programmer could then use whatever "theme"
was their favorite and never have worry about annoying
someone else because that other person would just load the
code into their own "theme".
3) We use a language translation product and then repair the scripts
afterward
I suggest using option two and then running the variable names
and comments through a modified option 3. Then we get
whatever we get. Option 1 will be useful for creating the
German OC binary stacks for the American decompiler to
use in the first place.
All of this of course happens AFTER we get a couple decent
engines to justify the need.
> And do remember: The bytecodes are _not_ cross-platform, for reasons
> primarily of speed.
They are not transparently cross platform, but why couldn't
we create a cross platform superset for purposes of
translation to other platforms? We would have to do
something like this if we want it to be cross platform.
English -> OC byte codes -> platform specific assembly
The OC byte codes would only appear when you
save the stack file to the hard disk as a stack (as opposed
to platform specific executable) for the purposes of making
the stack file itself cross platform.
This adds a layer of abstraction and leaves us with
the ability to support multiple languages.
The first major hurdle is standardizing on the OC
bytecode language as that will define our limitations.
The next is implementing our first interpreter.
I think it is interesting that not all xTalk interpreters will
necessarily use all of the OC bytecodes. The interesting
part about it is that one xTalk may actually have more
features than another (for instance hypertalk vs metatalk),
however both will be subsets of the OC bytecodes.
-- Michael --
