> Julian blackhirst :  The way i see it we should first design the
> language.

Alain :  You're probably right.

> Julian blackhirst :  I think the whole thing should be programmable.

Alain :  You're absolutely right.

> Julian blackhirst : ... for instance. Instead of having a button
> called "a" on a card you could have a make file: ... Any way you get
> the general idea.That way files could be edited in text
> editors as well. We could include a resource file for the card pict
> and other resources. That would also make it more compatible with
> windows because they have .res files.

Alain :  I like the file/resource thing because it will allow us to edit
a stack - parts and scripts - without interacting with the GUI. Its
particularly useful if you script stuff that scripts stuff.

> Julian blackhirst : We should then make a compiler:  We write the
> compiler in C/C++. The compiler compiles both the make code and the
> OpenTalk scripts. The compiler can compile to a application or a java
> applet.

Alain :  The YACC tool mentionned on this list recently create
C-compilers, if I am not mistaken.

> Julian blackhirst :  Java applets we would just have to compile to
> byte code for interpreting from the java VM.

Alain :  I am relieved that you make this sound so easy.

> Julian blackhirst :  Ok at this stage we can make stacks in text form
> and compile them with our compiler. Fine.

Alain :  See one of my comments above.

> Julian blackhirst :  Now to prove the flexibility of our wonderful new
> compiler we write an editor in our language to be compiled by our
> compiler.

Alain :  I like this "bootstrapping" strategy.

> Julian blackhirst :  The editor would look and feel just like HC but
> underneath would just
> automatically create code to compile. As we work in OpenCard it just
> generates code behind it depending on what we do. It could write the
> resources to the resource file.

Alain :  Automatically compile scripts the first time they are run, just
like HyperCard does, eh !

> Julian blackhirst : This would be the easiest, fastest and most
> reliable was to do it.

Alain :  Keep up the good work, Julian.

Reply via email to