At 3:03 PM +0100 on 11/18/99, M. Uli Kusterer wrote:
>>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.
Documentation? Yes, I should add that. Dang it, it's not even beta :)
>
>>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>
Yeh, well, take a few whacks at Bison. It's been -- um -- emotionally
disturbed by this news. Apparently, it likes being dumped as much as people
do ;-)
>
>>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?
Possible, but that code would be even scarrier. The idea is to write a tool
so I never, ever have to even open the generated C file.
>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.
You did write one, didn't you, for Velocity [sic]?
> 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>
LOL. It'll probably use malloc/free.
>
>>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?
Yes, I'm talking about large scripts.
>>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?
OK: Anyone know the name of some other xCard people <g>?
Honestly, no offense intended. I just want his opinion on if I'm going
crazy or not. It's not my goal to fragment the xTalk language (at least not
yet), so I do want his opinion on this now.
> The more cross-platform, the better. My goal for XBF is writing one
>version that will compile under any ANSI-compliant compiler.
How about any reasonable compiler, because an ANSI-compliant C++ compiler
on every platform is a fool's paradice (at least until 2050).
