At 12:37 AM -0800 on 11/11/99, Michael Fair wrote:
>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...are
> intimately familiar with the OC bytecodes and can use a
> hex editor,
Hell, not even I can do that :(
> 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.
I think that'd be _very_ annoying and confusing. Consider typical
know-nothing user. "It says 'NuCard'. I have 'NuCard'. It won't work. This
'NuCard' thing must be sh*t."
>
>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.
Please look at the decompiler in Interpreter. It decompiles into something
like assembly code -- not NuTalk. Decompiling into NuTalk is not a project
I'd wish upon my worst enemy.
>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).
Variable names & comments are not bytecoded. In fact, it gets worse. They
are encoded by number. But variable numbers can be re-used (I think...
don't quite remember).
> 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".
Interesting idea, but this is not AppleScript so it may be somewhat hard.
>All of this of course happens AFTER we get a couple decent
>engines to justify the need.
YEAH!
>
>> 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.
The design of the bytecode is fundamentally not cross platform. No superset
could be, by definition. No subset could be by design.
On a different platform, the Interpreter would simple retokenize the
uncompiled code.
>
>English -> OC byte codes -> platform specific assembly
No -- it goes like this:
English -> NullCPU assembly
Where NullCPU (I hope I got that name right!) is a platform-specific
made-up CPU.
Or are you proposing an intermediary "OC byte code"? Actually, I might be
switching to something like that -- the parser is giving me nightmares as
it is now. And it would allow a lot of stuff like that.
