>Well, first, let me remind you about BugTracker. For all the features it
>offers, I really think you should check it out. Here is a repost of the
>origonal message (by me, of course):
Anthony,
I already looked at it. It's nice, but you should add directions which
button does what, and what info is needed to complete forms etc. Some
button names are less than self-explanatory.
>Solution: Dump Bison.
May I be the one to say "I told you so!"? Not that I really did tell you
so, but it just feels great to hit on people when they're lying on the
floor for a second. <g>
>Bison will not be used in the next Intepreter. Instead, I intend to write
>my own parser-genrerator 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. It is named "NuParser" :)
I'm not sure whether it wouldn't be possible to just write your own parser
w/o such a tool? Not that I know much about parsers, Pittman's book is
pretty hard to read, but now that I know the principles of assembly, I feel
like writing one would be rather easy.
>This will not be a bison re-write. Two fundamental differences will be:
> a) NuParser will include features to make bytecodes easy.
> b) NuParser will not be LR(1); it will be LR(�).
> c) NuParser will be GUI-based.
> d) NuParser will allow you to decide which path is taken in a
> reduce/reduce conflict.
Just one thing: Remember to encapsulate platform-specific code in an own
class. That is, a class XMemory for memory management, a MacMemory class
for Mac-specific memory management (that can be replaced with another
XMemory-derived class e.g. if you want to compile for Windows). This way,
unportable code will require few changes. Abstraction is the concept to
use. Thanks, autographs later. <g>
>Q. Don't you care that it will be slower?
>A. No.
>
>Q. Why?
>A. Because the parse will be done once, at script save. If it takes a
>second or
> two to save a script, big deal.
I hope you're talking about 32k scripts here? I don't want to wait even
longer for longer scripts. Nosir. Oh, and just in case you need an
assurance that your interpreter is still fast enough -- I think there's
still a copy of our favorite slomo "Velocity" on the UFP server... :-)
>Q. What advantages will this provide?
>A. Quicker Interpreter writing; fewer bugs; more portability. Plus, with LR(�)
> a LOT more flexibility
I *like* flexibility :-))
>Q. Will other xCard companies want your head for using a LR(�) parser -- and
> no doubt making it more English-like by doing so?
>A. You'll have to ask them. Scott?
Stop picking on Scott. He's a nice quy. He gives me cards. And a nice mail
footer. And he comes from Unix. What more could you want?
(and not that this was my main motivation, but remember he's hosting this
list. ... Shhhh!)
>This will work cross-platform, because parsers will be generatable for
>other platforms, if not fully cross-platform. And the bytescodes will be
>cross-
>platform. Eventaully, Interpreter will generate the parser itself.
The more cross-platform, the better. My goal for XBF is writing one
version that will compile under any ANSI-compliant compiler. Of course,
I'll later add Macintosh optimizations, and I hope we'll also get a version
optimized for Windows etc. But there should be a 'generic' code set to get
ports started very quickly.
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
