> WE'RE NOT THE ONLY ONES WITH DREAMS FOR xTALK!!! Everybody has their own
> needs for xTalk, as julian just showed, everyone needs something slightly
> different for their needs, so while we're open sourcing our "OpenCard", why
> don't we keep the compiler and interpreter seperate from the stack writing
> routines, display routines, etc, so that other people can just take the
> interpreter and stick it into their own products. Imagine, clarisWorks with an
> xTalk interpreter? We should make some form of appleevent thing to allow any
> app using the xTalk routines to control each other, like Applescript. In fact,
> when we're finished with the interpreter, someone can make some kinda OSA
> extension. oh darn, nature calls, until next time.
clap clap.
I think this is a good idea. Those of us who can programme could plug the xTalk
interpreter into whatever app framework we want to.
I personally don't think I yet have enough programming experience to write a good
interpreter for xTalk.
For those interested there is some source for implementing a regular expression parser
at:
http://hyperarchive.lcs.mit.edu/HyperArchive/Archive/dev/lib/scripting-cpp.hqx
If we get a good xTalk interpreter we can then all argue about exactly what we want to
do with it for OpenCard. What commands and functions we want to have included, what the
application will include, will it spin out java, file formats etc.
Any takers for writing this code?
Andre
BTW, not being able to reply directly to the opencard list is a hassle
