I am developing a replacement for SmaCC (far from complete).
Once it is completed I am interested in being able to define languages
and have code in these languages placed directly in a
Smalltalk (probably Squeak) image.
I haven't figured out how this will work.
Somewhere there will need to be a specification
that a given class or method contains not Smalltalk code
but code from some language X.
The compiler for language X  would generate Smalltalk byte codes
that would be stored in the image much like bytes codes of Smalltalk
methods.
Some example languages:
   1) Regular expressions
   2) bash shell scripts (Linux)
   3) sed scripts    (Linux)
   4) C

There are tons of issues here to be resolved much later.

Meanwhile, I thought of two languages worth adding to the list:

     4)  SLang
     5)  Assembler for the virtual machine.

The reason for  4)  is to allow users to write code that they mean
to be efficient.  My understanding is that SLang is  C like and gives
similar performance.  Of course translating SLang methods to byte
codes will slow it down but it should still be useful when performance
matters.
The reason for  5)  is the same though I admit it would be odd for
someone who is so committed to performance to write his code in
assembler to then choose to write his code for a Smalltalk virtual machine.

Questions:

   a)  Is it a good idea to be able to embed other languages/language
compilers
into a Smalltalk image?  I am sure many will object to this idea
but I hope there are some supporters as well, as least in principle.
At this point I am just interested in hearing what the pros and cons are.

   b)  I am just writing an easier to use, more powerful, and faster SmaCC.
To generate byte codes from a language specification
more compiler utilities are needed.
Has anyone done any work in this area,
either in Squeak or other versions of Smalltalk?

  c) If efficiency is desired when converting a regular expression
to a finite state machine, then one option is to represent
the finite state machine in machine code  or a language that
supports computed gotos and collections of goto locations.
A transition in the finite state machine might be represented by
an instruction of the form:

goto  followStatesOfThisState at: inputValue  ifAbsent:  [self
reportInvalidInputAndExit].

 If I write a compiler to generate Squeak virtual machine bytes codes
corresponding to an input regular expression
will I be able to generate instructions
equivalent to the goto instruction above?


Of course there are many problems.  The biggest concern I have is that
we can't allow the user to generate virtual machine codes that blow the
system out of the water.  Admittedly this problem could kill the whole
idea.  Perhaps there are security issues as well.


Once the above has been completed I hope to start another project.
I want to build a replacement for the Linux shell bash which I call squash.

Squash would be a running Squeak image which provides the user with an
interface similar to when running the bash shell in Linux.
It would also be possible to write squash shell scripts that provided
functionality
similar to bash shell scripts.  Unlike bash shell scripts, however,  squash
shell
scripts would be compiled into files of byte codes called squash executable
files.
It would also be possible to have other languages whose compilers generate
squash executable files and have the squash shell execute them.

What does all of us give us (at least on Linux)?
Well, I think it gives us:

  1) A version of Squeak that interfaces with other languages much better
than now, thus making Squeak (Smalltalk) much more useful to the
software community in general.
  2)  The option of using Squeak where scripting languages are now used.
And since in the Squeak case the code is compiled into byte codes it
should run faster than would be the case for many scripting languages.
   3) Since the squash shell scripting language
will have the entire Squeak image available to it,
it should be a powerful language to write shell scripts in.

Comments welcome, especially negative (but constructive) ones.
I am looking for comments on whether this is a good or bad idea,
not a detailed description of what all the problems are,
though the latter may be useful too.

Ralph Boland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070503/4951bfae/attachment.htm