> 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: Yes, it could be worked around. But I'd
prefer to keep as many hacks out of it as possible.
Alain: You're absolutely right. Good principle.
Anthony: The regexp support is tempting, but not
enough. Besides, if I want regexp, I can always grab a
regexp package.
Alain: A regexp package for C/C++, correct? If so,
then things couldn't be better.
> Alain: Clearly you definitely prefer C over Perl.
Anthony: I prefer perl for a lot of quick prototyping
& short things which don't require the most speed
possible.
Alain: How about the rapid-prototyping of new NuTalk
syntax? I am/was considering Perl for this.
Otherwise, I will either have to learn C/C++, or
merely suggest new syntax to our programmers - which
they can choose to do or not (of course) - Both are
not really satisfactory.
Alain: Is it (or will it become) possible with the
current arrangement for us non-programmers to
prototype new NuTalk syntax?
Anthony: When I want to do something longer, or need
speed, or need to play with memory, it's either C or
C+.
Alain: Of course. It makes sense.
Anthony: Or sometimes even assembly :)
Alain: Showoff! ;-))
Anthony: I don't like playing with the low-level stuff
except when it makes it easier, or faster ...
Alain: Nothing faster or more efficient than assembly,
that's for sure. One can do wonders with a mere 1K,
too!
Anthony: ...[and I need it faster].
Alain: This need-for-speed, Anthony, is it specific to
something that you are doing, or is it just the
general principle that faster is always better?
Anthony: HyperCard is not actually going to do the
parsing. It's going to handle the grammar, and spit
out C/C++ to do the parsing.
Alain: Could you please clarify the meaning of "handle
the grammar". Do you mean by this that the NuTalk
sentences are broken down into their generic
functional syntactical components (verb, subject,
object, etc )? If so, then what do you mean by
"parsing"?
> Alain: But there are things that are no longer
> relevant and some that never were:
> debug hintBits, debug pureQuickDraw true, debug
> maxmem,
Anthony: We'll probably keep a lot of 'debug' commands
and even add a bunch more -- those commands were never
intended for end users; they were intended to help
debug HyperCard. We'll need simular commands to debug
NuCard.
Alain: As long as they are genuinely useful. Also, we
could package them separately. After all, they are for
programmers only. Why include them in the
user-friendly scripting syntax for the rest of us?
> dial, heapSpace, annuity, etc.
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.
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).
> 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. The
listing of the paths of all of the Documents, for
example, is much too sizable (in my opinion).
Furthermore, Documents and such are not PART of
HyperCard. They are part of the surrounding
environment.
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: NuCard would perhaps call a function in the
Home stack, perhaps called "NuCard:FindStack" to find
the stack. That function would be responsible to find
it in the search path, and update search paths.
Alain: Why doesn't NuCard simply do this automatically
and invisibly, without using the Home stack?
Anthony: Also, the user could customize the stack
search this way. Default behavior in HC is to use the
first stack found, but the user could customize NuCard
to prompt which stack to use.
Alain: set the multiFindDialog to <logical>
Anthony: The user could even customize it to do a full
search on the hard disk to find it.
Alain: It should do this automatically when the
preliminary search in Documents (and such) fails. Or
we could provide a another new property:
set the searchFileSystem to <logical>
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
