>Michael: So I don't know who to ask this question
>to, but I would like to know if you folks agree
>that NuTalk the language should be treated as its
>very own programming language completely separate
>from the NuCard project, or do you think the two
>should be collapsed together?
Michael,
I'm not the one writing the interpreter, but so far it looks like OpenTalk
will exist as an interpreted or "virtually compiled" language on its own
first. We will then later "tack on" fields, buttons etc. I'm not sure it
will be feasible to maintain fields and buttons as completely separate from
the interpreter, but I don't think that it would be much trouble to stick
with OpenTalk for now, and to fork when it's finished, remove the field and
button stuff and then add any new object types you'd want.
If it's a compiler you want, it'll get a bit more complicated. Then you'd
probably also have to rip out the execution stuff of interpreter and just
use the tokenizer and parser and write the code to generate assembly
instructions yourself. But OpenTalk will be fast, and if you want a
compiler only for speed reasons, I don't see why you wouldn't want to use
OpenTalk instead.
*BUT* if you intend to write INITs using OpenTalk, or maybe other
non-application code, I guess you'll have to start rolling your own.
Although it is (with some difficulty) possible to create C++ code resources
(C++ relies heavily on globals, which have to be hacked into CRs), you'd
need strong data typing and other things if you'd want to write an INIT,
which will probably not get into OC. Of course, Anthony has more insight
into this, so maybe I'll be proven wrong in a message.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
