> 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.
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. 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!
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.
Alain: Bottom line is that each environment has its
own area of specialization, and thus they all have
their place at one time or another.
> Anthony: It's not my goal to fragment the xTalk
> language (at least not yet)
> Alain: I am intrigued. Sounds like someone (besides
> myself) is considering a MAJOR rewrite of HyperTalk
> and lots of changes for HyperCard too.
Anthony: Well, not a major rewrite.
Alain: I overstated myself when I said MAJOR rewrite.
We want to approximate HyperTalk as it is known and
loved today, that's for sure. But there are things
that are no longer relevant and some that never were:
debug hintBits, debug pureQuicDraw true, debug maxmem,
dial, heapSpace, annuity, etc. Furthermore, the
scriptEditor's global variables should be properties
instead. 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 ...
Anthony: At least not until version 2.
Alain: ... but I didn't want to confuse the issue too
much by suggesting a million different changes before
we have at least a working first version that is quite
similar to the HyperTalk we all know and love.
Anthony: But some alternatives to the syntax os some
commands would be nice.
Alain: Indeed! I have PAGES of new syntax, most of
which are add-on instead of remove-from or
transform-into. In other words, a superset. Hence,
they will not make OpenTalk incompatible with
HyperTalk (for the most part). Differences could be
handled easily at import or compile time.
Anthony: All in all, with the bytecodes, you can code
in whatever HT language you choose.
Alain: That's ...GGRRrreeeaaattTT! (as Tony would say)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
