> Well, I guess I was wondering how those who live in the Smalltalk
> environment and deliver products in ST deal with the issue of "little
> languages".
> ... Perhaps
> the notion of a "new" language isn't relevant...Perhaps the ST way is to
> deliver objects that have the intended functionality, and allow end
> users to configure those objects with editors, rather than have the end
> user write code.

Chris,

I'd suggest skipping your own syntax for now, and instead use Smalltalk's
own to come as close to the one you "really" want. Smalltalk's "keyword
syntax" will get you a long way, because it is far more suitable for this
than in languages where you only get to choose a name for the procedure.

In fact, "little languages" was a concern of the Smalltalk designers, and
the keyword syntax was what they came to regard as the best general-purpose
solution to this--the earlier, greater flexibility (of "Smalltalk-72") was
considered more complex than necessary.

An imagined script language statement like

draw string "hello" in window w at position  x, y using font myFont at 12
points

(or something) would in procedure-style languages be restrained to

drawstring("hello", x, y, myFont, 12, window)

whereas here you can define your own methods like

window drawString: 'hello' atPosition: x at y withFont: font size: 12


By using the keyword syntax you could start solving your 'core' problem
without writing any parser. Then, when that is done, you may have a better
answer for the question above; you could back and do the syntax if you still
think you need it. A long time ago I realized in hindsight that I could have
saved myself the whole work of parsing true SQL syntax in this way, since it
became clear afterward that the syntax was not essential to solving the
problem. 

Henrik