>No doubt. But since AppleScript is not case-sensitive, it should fix this
>itself.
Anthony,
AppleScript doesn't fix anything. It just takes over everything as the
programmer spelled it in the dictionary, assuming he knows what he wants.
After all, imagine AS made everything lowercase. What if some token
consisted of a shorthand form of a word which has to be capitalized (like
OODL). Who could read it if AS made it lowercase?
>True. But that's why you update your token table on each compile.
>
>But if you look at some of that disassembled OpenTalk, it's worse. I pitty
>the person who winds up getting to write the debugger (Ouch. It's probably
>me)
If you don't get it to become a lot more readable, it will certainly be
you. OTOH, what about an option to carry along variable names etc. for
easier debugging?
> "Application Stuffit Lite� can't understand the
> [10 lines of nonsence] message. Sei ein Wurm!
> Sei gl�cklich! Ein Wurm haben kein AppleScript."
>
> (OK, I added the worm stuff... Uli, how bad did
> I screw that up? And which gender is a worm
> these days?)
It's almost perfect. Only you forgot to conjugate "haben". It's "hat" in
this case.
>Hmmm... hate the new QT as much as I do? Just dump in the old MoviePlayer.
>And, btw, LinuxPPC is _FAST_.
QT 4? Just installed it. Looks cool, but I usually want to work, not to
play. And the UI elements are not very self-explanatory (not to mention the
volume control which is awkward to use). I'm using the 2.5 Movie Player
anyway. It works around the problem that I haven't got QT Pro.
>And using HC's hierarchy is a Good Thing? Ak! Makes it hard to compile
>scripts...
> (...)
>I don't see why not. It's an imperitive... It tells the compiler: "Include
>whatever [into my source]"
> (...)
>#include is fine; it's preprocessed. I'd just read the file before passing
>the script to the frontend. Call that layer the preprocessor.
The problem comes if you have multiple objects and one includes the
other's script. You have to keep track of changes in one script and
invalidate all others that include it, you have to take care of circular
includes...
I don't mind if we put include in the standalone interpreter, but for
OpenCard we should leave it out. And insert script doesn't make compilation
hard. You can only "insert" a script of an object, which means the script
you include has already been compiled. You just have to make sure handler
calls get through a dynamic message-passing hierarchy, which we'll need
anyway.
If we support multiple stacks in one file, we could then easily add dummy
stacks as libraries.
>How about "using script file <file>". No, never mind. That sounds like it
>establishes that there is a point at which you un-use it.
Right. I think include is really a way of outdated thinking. It is good
for compiled languages like C/C++ or today's Pascal, where you build your
programs out of one text file basically (most environments today do
'auto-include' by giving you project files, but DWIM). But in a real
Object-Oriented environment like HC, I think it's much more natural to use
objects instead of text files. You can use the aforementioned scheme to
have libraries which are shared by multiple stacks.
>Another thing, though. With the HT compiler, one could make semi-protected
>libraries for distribution.
You mean storing the scripts in tokenized form, thus preventing that
people read the scripts with a text editor and increasing execution speed?
no problem. But please don't do a real compiler. A JITC, maybe, but I think
one of HyperTalk's greatest advantages is that you can easily change a
thing and re-run, without needing to re-compile anything. It's a speed
improvement and much more user-friendly.
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
