> Alain: A regexp package for C/C++, correct? If so,
> then things couldn't be better.
Anthony: Except that regexp is slow. I don't really
need it -- at least not for what I'm doing now.
Alain: the short answer is YES then.
Anthony: You won't have to learn much C++. You'll have
to learn the syntax for NuParser. You'll have to learn
a little C++ to bytescode and possibly assemble the
new instructions you add. You'll have to learn NullCPU
assembly. To add a new command, you'll have to change
the NuParser. Not too hard. Then you'll have to add a
little to the translator. Then, if it is not already
part of the bytecode, you'll have to add some to the
compiler.
Alain: Sounds like a lot to me! In any case, you are
confirming that I will need to be somewhat proficient
with C/C++ to contribute to OpenTalk's syntax.
Correct?
Anthony: ... but from your HC Syntax webpage, you
probably already do.
Alain: You're too kind. HyperCard's formal syntax is a
cinch compared to what you described above. Add to
that all of the software that I will have to buy,
learn, etc: language, compiler, MPW, etc.
> Alain: Is it (or will it become) possible with the
> current arrangement for us non-programmers to
> prototype new NuTalk syntax?
Anthony: It should be.
Alain: The arrangement that you outlined above? Can
you provide us with an easier way to prototype new
OpenTalk syntax? Templates or ... something ?
> Anthony: We'll probably keep a lot of 'debug'
> commands and even add a bunch more ...
> Alain: Why include them in the user-friendly
> scripting syntax for the rest of us?
Anthony : We don't. That's why they're undocumented.
But we leave them in the executable because:
a) It's more work taking them out
b) Allow a user track down a bug.
Alain: Fair enough.
> Anthony: But why are dial and annuity obsolete?
> Alain: No one is using or will use HyperCard/NuCard
> for calculating annuity and compound interest, nor
> are they using it to automate their phone calls.
There
> are better software packages out there for
Statistics
> and for phone automation.
Anthony: And why should one not be able to write such
a package with NuCard? NuCard is development tool --
and should be able to do stuff like that.
Alain: You are going to need a lot more than a "dial"
command to offer a genuine value-added phone solution
with NuCard (in my opinion).
> Alain: If we must include them, then include them
> as separate packages that offer much more than is
> currently offered in this regard. Lets keep the
> base syntax of NuTalk focused on the essentials,
> at least for the first version(s).
Anthony: We're not designing a RISC chip here, Alain.
Alain: Simpler means less complexity, less bugs, less
work to do (on marginal commands like dial for
example), quicker time to market, simpler for the user
to learn, better performance, and perhaps some other
advantages that don't come to my mind at this time.
Anthony: Annuity and dial functions are not that hard,
and VERY, VERY, VERY easy compared to plugin extension
of the syntax.
Alain: Fair enough.
Alain: Do you envision that we will eventually have a
plugin interface? Or do you recommend that everything
be integrated directly into the source code, given
that we are open source?
> Alain: 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: Why not properties as well? If a stack
> wants to add to them, why not?
> Alain: We could do them as properties. But
> properties are usually reserved for small-sized
> values.
Anthony: The script property of buttons, fields,
cards, backgrounds, and stacks
Alain: By convention, the script is a property because
each object possesses one. But isn't it just a (brief)
reference to a container managed by the Script Editor
XCMD?
Anthony: The <contents> of?
Alain: Is the content of a field considered a property
of that field? Not formally, eh, but I guess that it
is in practice. How does HC handle fld-content
internally?
> Anthony: 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.
> Alain: I disagree. If something that you would
> rather not attend to, gets done automatically and
> without your knowledge, then where is the problem?
Anthony: It will be done without any effort on your
part, by the default home stack.
Alain: My Home Stack Script is sacred. So much of my
generic stuff belongs there that the 30K limit is
never very far. The fact that the application will
deprive me of some of this meager space, by including
one or more handlers for managing something that
should be invisible to the user, is best avoided in my
opinion.
Anthony: But when you do want to attend to it, I
assure you most people don't want to spend all day
reading NuCard source code.
Alain: How about the following syntax? :
add <document or app or stack> to favorites
remove <document or app or stack> from favorites
answer favorites [of type <document or app or stack>]
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
