Info on Smalltalk DSLs or Metaprogramming...
Rich Warren
rwmlist at gmail.com
Wed Aug 30 09:58:00 UTC 2006
On Aug 29, 2006, at 10:34 PM, goran at krampe.se wrote:
> But writing Smalltalk code in a file from within Squeak is
> definitely an
> odd way of doing it, unless you have a specific goal doing that.
You're not writing Smalltalk code in an external file, you're writing
DSL code (text that happens to be interpreted and parsed as Smalltalk
code). It's a subtile difference, but I think an important one.
And you might not write any code at all. You could be passing
messages as strings between remote agents. You could be automatically
parsing Unix log files. You might be scanning a text document for
tags which will be automatically replaced with computer-generated
content (for example, putting actual source code into an article
about computer programming at the last minute, so you don't have to
worry about copying-pasting and keeping things in sync as you edit
both files).
> Eh, "utilize Smalltalk syntax" (and not actually *use* the available
> Compiler) seems less useful.
> I mean, if you want Smalltalk syntax - why not use *Smalltalk* and not
> just the syntax?
> Use the Compiler that we already have and that is battle proven etc.
I'm not sure why I'm having so much trouble expressing myself on this.
Of course I'd use the compiler.
Compiler evaluate: 'some text from file'.
This is exactly what I'm talking about (and why people recommended
using smalltalk syntax directly as opposed to creating my own syntax
and building a parser).
>>
>> Here's an example of what I'm talking about. I'm about to implement a
>> neural net. I'll be experimenting with many different sizes and
>> topographies. This is an excellent opportunity for a DSL. I could
>> create several net-building scripts that are then loaded and
>> interpreted by the main application. Then, if someone wanted a
>> different topography, they could just write and load their own build
>> script. I could even build an object to automatically write out build
>> script permutations. The scripts themselves act as both source code
>> and log.
>
> And if *I* would do it I would just use Smalltalk. :) IMHO specific
> DSLs
> tend to get outgrown. They look simple from the beginning, and then
> you
> bang your head against the roof. And the effort to create them often
> (IMHO) does not pay off that much compared to "just use Smalltalk" (or
> Lisp etc).
That is certainly a valid option.
For something like this, planning a DSL can be a really helpful
experiment. Even if I end up implementing it directly, I end up with
a set of classes/methods that are cleaner and easier to use.
Also, who might use the DSL. If the end-users might want to modify
the code, then it may be better as a DSL (unless the end-users are
smalltalk programmers).
And DSLs can often serve dual purposes. A single source file might
generate both code and documentation (or in my example, function as
both executable code and as a log file). You can gain a lot by
having a single, authoritative copy of the important information
(provided you back up that copy, of course).
But, if you're not going to get anything out of it, just implement it
directly.
>
> In Gjallar we use Smalltalk as the "DSL" for defining the workflow
> graph
> for example, it looks simple enough for most readers AND we can easily
> do special things when we need to. And no time spent writing a custom,
> half buggy parser. :)
Again, I'm not talking about making a full parser. Maybe some light
preprocessing of the input (maybe), but you should use Smalltalk for
the heavy lifting, where possible.
>
> Thing is - it is fun to make languages and I think DSLs often are
> created just because it is fun to do it. Or you simply don't have a
> language where the parser/compiler is so readily available. I mean:
>
> Compiler evaluate: '3+4'
I really think we're talking about the same thing, just using
different words. '3+4' is too trivial to be a DSL, but this could work:
run: 'name' trainingSet: 'training file name' testSet: 'test file name'
And, with the right classes (and preprocessing) it could be parsed
and interpreted directly as code.
e.g.: Compiler evaluate: 'myClass ', lineFromFile.
There's no half-buggy complier. Smalltalk does (almost) all the work.
And yet, this is exactly the type of DSL I have been talking about.
I hope I'm starting to make more sense.
-Rich-
More information about the Squeak-dev
mailing list
|