At 1:32 PM -0800 on 11/20/99, Alain Farmer wrote:
>> Anthony: Bison will not be used in the next
>> Interpreter. Instead, I intend to write my own
>> parser-generator tool, which will be done in (yes)
>> HyperCard. Maybe portions in other things, but I
>> doubt it. It will at least have a pretty HC
>front-end.
>
>> Alain: Surely Perl would be a much better choice
>> for a parser-generator tool
>> (e.g. pattern-matching with GREP)
>
>Anthony: Nope -- not powerful enough, IMO. For writing
>this parser I'm going to be doing some serious pointer
>work -- and Perl does not let me do that. Does Perl
>even have pointers?
>
>Alain: Perl doesn't force us to do any low-level
>memory-management stuff like C does, so I also doubt
>that Perl has any pointers. They could probably be
>improvized though.
Yes, it could be worked around. But I'd prefer to keep as many hacks out of
it as possible. The regexp support is tempting, but not enough. Besides, if
I want regexp, I can always grab a regexp package.
>
>Anthony: Besides, Perl is less portable than
>plain-ol-C.
>
>Alain: Time and time again, Anthony, you have made it
>abundantly clear that you definitely prefer C over
>Perl.
Depends on the task. BugTracker is written in Perl, for example -- but then
again, I intend to fix that sometime.
I prefer perl for a lot of quick prototyping & short things which don't
require the most speed possible.
When I want to do something longer, or need speed, or need to play with
memory, it's either C or C++. Or sometimes even assembly :)
I don't like playing with the low-level stuff except when it makes it
easier, or faster [and I need it faster].
>I understand. C is much more powerful because of
>its low-levelness but, consequently, its also has a
>MUCH steeper learning curve. C is not for the faint at
>heart!
It's not that bad. You don't have to use all the low-level stuff... With
C++ you can probably even write a sizable program without ever thinking
about that stuff. BugTracker could be one of those :)
>
>Alain: But, more to the point Anthony, you wrote above
>"I intend to write my own parser-generator tool which
>will be done in (yes) HyperCard". So I believed that
>the comparison being made was between HyperTalk and
>Perl. I like HyperTalk's chunking ability .. always
>have .. but it still doesn't compare to what you can
>do with Perl.
Agreed. However, HyperCard is not actually going to do the parsing. It's
going to handle the grammar, and spit out C/C++ to do the parsing.
>But there are things
>that are no longer relevant and some that never were:
>debug hintBits, debug pureQuicDraw true, debug maxmem,
We'll probably keep a lot of 'debug' commands and even add a bunch more --
those commands were never intended for end users; they were intended to
help debug HyperCard. We'll need simular commands to debug NuCard.
>dial, heapSpace, annuity, etc.
Heapspace definitely goes -- only makes sense on the MacOS. But why are
dial and annuity obsolete?
>The HC-managed Applications, Documents and
>Stacks global variables should be functions instead,
>and they should be completely managed by the app
>instead of one or more handlers in the Home Stack
>script. I could go on ...
Why not properties as well? If a stack wants to add to them, why not?
Also, I think they should _completely_ be managed by the Home stack. Right
now, HyperCard performs some magic with them, and you're never quite sure
why it works.
NuCard would perhaps call a function in the Home stack, perhaps called
"NuCard:FindStack" (an illegal name, but the parser could special-case it),
to find the stack. That function would be responsible to find it in the
search path, and update search paths.
Also, the user could customize the stack search this way. Default behavior
in HC is to use the first stack found, but the user could customize NuCard
to prompt which stack to use. The user could even customize it to do a full
search on the hard disk to find it.
