At 8:34 AM +0000 on 11/30/99, Michael Fair wrote:
>Michael: Rather than adding a specialized keyword to
>handle this _one_ specific case, can we identify the
>domain that this functionality lives in and then create
>a more generic syntax that handles it?
>
>Maybe something like:
>abs of <expr> [by [not] traversing]
>(Or perhaps there are other things aside from just
>traversal that would be important... Maybe there
>are multiple ways to traverse to heirarchy and
>the scripter could choose one using this syntax)
Well, isn't this syntax expandable:
this card's abs of x
this stack's abs of x
card id 3's abs of x
stack "Hello World!"'s abs of x
HyperCard's abs of x
>
>Michael: This brings me to a question. I believe I
>represent a very small percentage of people at the
>moment who see the potential for using languages
>like NuTalk as our primary full time programming
>language for all our programming needs. Some people
>are developing interpreters for C and C++, while I
>would rather see a compiler for xTalks.
I'd like to see an xTalk native compiler, too.
Remember how the new NuTalk parse will be organized:
parser -> bytecoder -> compiler -> emulator
Now, honestly, don't you think I have plans to be able to easily plug in a
native-code compiler (instead of the NuCPU cross-compiler) and generate
native executables?
>Michael: I am proposing we separate the language
>from the xTalk world and treat it like a lower level
>object oriented programming language which will use
>libraries to implement most the functionality.
>Buttons, stacks, fields, etc. will not be first
>class language keywords, but rather entities within
>a library that has added those words to the system
>in a well defined way.
Aren't buttons and fields part of just any GUI? It'd be more like C, but
with a built-in cross-platform GUI toolkit.
>Michael: So I don't know who to ask this question
>to, but I would like to know if you folks agree
>that NuTalk the language should be treated as its
>very own programming language completely separate
>from the NuCard project, or do you think the two
>should be collapsed together?
Are they exclusive?
Why can't it have NuCard-specific stuff, which is only linked in if you use
it, which is treated like a GUI library?
