Nice.  I didn't see Gjallar on the squeak projects page or on the seaside 
site.  Where are you
advertised? :)

Also, do you think those two classes you mentioned could be used to make a 
squeak script
front end?  I mean, would it be possible to change some classes of how the 
image acts on
start up to give arguments to classes like those and try to run them?

Thanks,
J J


>From: goran at krampe.se
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Info on Smalltalk DSLs or Metaprogramming...
>Date: Thu, 31 Aug 2006 11:06:40 +0200
>
>Hi Rich!
>
>Trying to give concrete useful (possibly) advice, here are a few things:
>
>	- In Gjallar we have Q2Console and Q2CodeHolder that enable "silent"
>running of Squeak code and tries hard to do autocorrections etc as the
>live Squeak env does. There are quite a number of messages that needs to
>be handled in order to cover all bases, like autoadding local varnames
>not declared etc. etc.
>
>	- A useful pattern is to use blocks for "scripts" like: '[:customer
>:invoive | ', script, ']' and then call it with the arguments and
>explain to the user that he should use "customer" and "invoice" to refer
>to those (or whatever) objects in the script. This way you get a more
>clearly defined scope instead of just running the script "inside" a
>given domain object (and thus expose all instvars etc).
>
>Then of course there are tons of nifty things you can do with actually
>building classes dynamically etc. :) And another trick is to subclass
>Parser and friends and hook into for example the logic for binding
>variables and so on. In my Namespaces implementation on SM there is a
>bit of such code that deals with resolving globals for example.
>
>regards, Göran
>