2007/5/3, Ralph Boland <rpboland at gmail.com>:
> 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.

override #compilerClass
IIRC once compilers for Logo and JS were made using this technique.
There will of course be issues with the debugger, you'd have to at
least implement a decompiler.
One thing to remember about jumps in Squeak bytecodes is that they
have many limits (to their lengths).
You might also want to consider generating IR of the NewCompiler
instead of bytecodes directly.

Cheers
Philippe

> 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
>
>
>
>