At 1:24 PM -0800 on 11/21/99, Alain Farmer wrote:
>Alain: A regexp package for C/C++, correct? If so,
>then things couldn't be better.
Except that regexp is slow. I don't really need it -- at least not for what
I'm doing now.
>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.
You won't have to learn much C++. You'll have to learn the syntax for
NuParser, but from your HC Syntax webpage, you probably already do.
You'll have to learn a little C++ to bytescode & possibly assemble the new
instructions you add.
You'll have to learn NullCPU assembly.
Interpreter will work like this:
Script ----------> Tokenization ----------> bytecode --------> NullCPU
NuParser "translate" "compile"
To add a new command, you'll have to change the NuParser. Not to 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: Is it (or will it become) possible with the
>current arrangement for us non-programmers to
>prototype new NuTalk syntax?
It should be.
>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?
I only break into assembly when nothing I can do with C/C++ will make it
fast enough for whatever purpose I have in mind. I really don't like
assembly; I mainly use knowledge of it for optimization in C and for
debugging.
>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"?
Ok. Here is an example NuParser grammar:
main:
"hello, " <thing> "!"; (1)
"hello, cruel " <thing> "!"; (2)
"hello, cruel " <non-thing> "!"; (3)
thing:
"world"; (1)
"planet"; (2)
non-thing:
"existence"; # OK, thing but not concrete. (1)
NuParser converts this into C code to recognize input, and turn it into
tokenized form. To do this, each possibility is given a number. They are
shown above, in parenthesies. Note that there is no guarantee on the
numbering -- all will be done with defines.
INPUT OUTPUT
hello, world! 1 1
hello, cruel world! 2 1
hello, cruel existence! 3 1
hello, planet! 1 2
hello, existence ERROR
>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?
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) We might need them to have a user track down a bug.
>
>> 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.
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: 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).
We're not designing a RISC chip here, Alain. Annuity and dial functions are
not that hard, and VERY, VERY, VERY easy compared to plugin extension of
the syntax.
>
>> 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 script of? Property of buttons, fields, cards, backgrounds, and stacks
The <contents> of?
What's wrong with the stack search paths of NuCard?
>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?
It will be done without any effort on your part -- by the default home
stack. 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.
>
>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?
Because then I can't customize it.
>Alain: set the multiFindDialog to <logical>
>Alain: set the searchFileSystem to <logical>
OK, but what about if there are multiple documents?
set the choosefrommultiple to <logical>
Or, what about not searching certain volumes -- for example, slow network
drives?
set the dontsearchvolumes to <text>
What about changing the search order?
set the searchorder to <text>
And so on.
The reason we don't just add properties is because then we'd wind up with
30K properties.
IN SHORT: The ideas of thousands of people when allowed to innovate, all
with their own unique perspectives and experiences, can far outdo the ideas
of one.
