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):
>Bug Tracker's polling is done. So is it's bug reporting. The only thing
>not implemented is editing a volunteer profile -- that is, changing your
>password.
>
>Visit it at:
> <http://cgibin.erols.com/derobert/cgi-bin/bug.pl>
>
>Tell me any problems you come up with. Play around with it. Add a few
>polls, a few fake bug reports (maybe even some real ones?). Vote on a few
>polls.
>
>Try and break it.
>
>To get yourself on the team for "Test Program":
> 1) Volunteer for Test Program. Do this by selecting Test Program and
> using the volunteer button.
> 2) Return to the main menu
> 3) Edit the programmers for "Test Program"
> 4) Add yourself. The maintainer password is "password" (without quotes)
>
>Now you can do all kinds of things.
>
>Only people on the program should be able to cast ballots for it -- but
>anyone registered can propose a poll.
>
>
>Things I've still got to add in:
> Assigning bugs
> Reporting poll results
>
>
>Once again, visit it at <http://cgibin.erols.com/derobert/cgi-bin/bug.pl>.
Anyway, now: The future of Interpreter
Well, at present Interpreter does not compile under certain compilers and
certain versions of Bison. And the grammar is scarry; the emulator little
better. The parser is a finite state machine (i.e., impossible to debug in
both MacsBug and any source-level debugger). And I'm tired of 20-page
printouts of @#@!# from the debug option.
Solution: Dump Bison.
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" :)
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.
Now, a quick Q-and-A session:
Q. Won't LR(�) produce slower and much larger parsers?
A. Yes, they'll be slower. But no, they should not be much larger. I plant
to use a bush-like structure to do this.
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.
Q. What advantages will this provide?
A. Quicker Interpreter writing; fewer bugs; more portability. Plus, with LR(�)
a LOT more 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?
## end quick Q-A session ##
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.
[Note: If it did not come out, � = infinity]
