At 6:07 PM -0800 on 11/22/99, Alain Farmer wrote:
>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?
Somewhat. Not too much. Remember, NuParser is a point-and-click parser
generator.
The bytecode translator should not be that bad.
The compiler, perhaps a little worse.
>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.
No software to buy -- you can download all of it.
>
>> 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 ?
I'd like to, but the problem is that I have not yet written the thing, so
it's hard to speak of details.
It may eventaully be possible to do some of the dirty work in NuTalk. We'll
see. This would involve chaning NuParser, adding some to the bytecode
compiler (done by step-by-step instructions), and then writing a NuTalk
function.
>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).
True. I think we should ditch the built-in dial command, add full control
of serial ports, and then just have a dial function in the home stack.
>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?
For the core syntax, I recomend everything be integrated. There is no
problem with extra functions as plugins (though I'd just have the start
using command and a stack).
The problemn is writing a parser that can be extended at runtime is not
easy. The Nuparser plans _might_ allow it, but the plugins would be hard to
write, and would require absolute perfection, or the whole thing would fall
apart.
There may be other wasy to do it -- such as having each plugin have its own
parser, and just passing off to the next parser on a parse failure, but
even that would require a lot of hard work to make work right. For anyone
who thinks this sounds easy: It would involve a reduce through multiple
parsers, each with different value systems [I'll explain those later --
they're NuParser-specific]. Ouch.
And in either case, if you thaught extension conflicts were bad, just wait
until you see plugin conflicts.
>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?
No. The script editor requests this property from HC to get the script to edit.
>
>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?
Not sure, but it's not really relevant to the script interface.
>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.
I exceeded the 30K limit long ago -- so I devised a plugin system used
"start using stack". Probelm solved.
But, more importantly, OC will not have a silly 30K limit. You won't be
deprived of meager space, because you won't have that problem.
>
>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>]
I thaught we were talking about search paths, not bookmarks?
