Info on Smalltalk DSLs or Metaprogramming...
Ramon Leon
ramon.leon at allresnet.com
Thu Aug 31 16:08:37 UTC 2006
> As I understand it, the term embedded DSL already refers to
> DSLs that are created by bending the syntax of an existing
> language--basically making a new language from building
> blocks of an old language. The other sort (external DSL) is
> where you use yaCC or smaCC or something similar to build
> actual parsers/compilers.
Agreed.
> Based on these definitions, I have always been talking about
> creating an embedded DSL. Yes, people keep recommending that
> I create an embedded DSL. Yes, this is good advice. Yes, this
> is what I plan on doing. For some reason, I keep getting
> replies that suggest that I'm resisting this advice, and that
> I'm bounding off to create a full parser. I'm a little bit
> confused by this.
Well, sorry if I misunderstood you, my apologies. It's just that with the
talk about not liking : for arguments, or not wanting a receiver, and not
wanting to quote strings and such, I was led to believe you didn't want an
embedded DSL, that you wanted to parse your own special syntax.
> I think the discussion got off track because people asked me
> a few questions (What would your ideal syntax be? Why do you
> think ruby syntax might be better for DSL's?) and I tried to
> answer them. I probably should have changed the subject line
> or something. So, when answering a question, I might have
> said, "I'd like to be able to do something like XYZ", but
> that didn't mean I wanted to go out and actually implement
> XYZ. I was simply answering a hypothetical question.
Ah!
> I'm still interested in an embedded DSL.
> However, I'm not convinced that simply altering an existing
> language so it is closer to the domain should count as a DSL.
That's the very definition of DSL.
> Some people count it--but to me it seems like that's just
> programming. C's functions, OOPs objects and Lisp's macros
> all serve the same basic function--they allow you to define
> additions to the language to more- closely model your domain.
> Where do we draw the line between programming and DSLs?
When I read the code, do I see C, or do I see lot's of stuff related to the
problem domain. If reading Lisp, do I see lot's of cons, car, cdr, map,
filter, or do I see something more domain specific. Some people program
"in" the language, some people program "on" the language. It's all just
programming, doing a DSL is just a style.
> >> When I spoke about DSL's, I was particularly talking about
> reading in
> >> and evaluating text files.
I would consider that an interpreter, and an external DSL, not an embedded
DSL, unless the text needed no preprocessing to evaluate. If you have to
pre-process it first, it's an interpreter, and an external DSL.
> Still, to return to my previous question, where do we draw the line?
> For me (and this is strictly a personal definition, don't
> feel obligated to adopt it), a DSL must be able to interpret
> code that was not part of the original application (support
> files that ship with the application, like configuration
> files, are OK). I'm talking about raw strings that have not
> been previously compiled. A DSL evaluates these strings on the fly.
Hmm, I think an interpreter evaluates strings on the fly, a DSL is just a
description of the possible syntax, and is orthogonal to evaluation.
> The code in question could come from a file, could be entered
> interactively at the command line, or could be sent across
> the network. It really doesn't matter where it comes from.
> The important thing is, in some way the code is external to
> the executable.
Again, I don't see this at all related to being a DSL. I could do this with
the syntax of any language that supported some kind of eval function. Being
a DSL is about syntax, not about where the code comes from.
> Why do I like this definition? For me, there are very
> practical reasons. Creating a system to evaluate external
> strings is more complicated than simply writing an object or
> macro. There are the obvious IO issues. More importantly, you
> need to decide whether you're looking at each line as a
> separate command, or whether you're dealing with the entire
> string as a single chunk. Strings can be interpreted as new
> objects and method calls, as method calls on a given object
> inside your code, or as numerous other possible variations.
It seems your definition of DSL == my definition of interpreter, no wonder I
misunderstand you so much.
> Also, this definition seems to match closely with the
> discussion on "Domain Languages" in the Pragmatic Programmer
> book--which has been my initial source for all things DSL.
Unfortunately, I loaned my copy out and it seems to have disappeared. :(
> Sorry to repeat myself, but I feel like I've tried to say
> this before--somehow the idea keeps getting lost under the cushions.
> Again, I think this is largely my fault--I should have
> separated the tangential conversations (e.g. the differences
> between Ruby and Smalltalk syntax as applied to DSL's in
> general) from the main point (what are the best practices for
> developing an embedded DSL to process externally provided
> strings in Smalltalk?).
>
> I'll try to be clearer in the future.
>
> -Rich-
No problem, happy to continue the discussion, I find it fascinating.
More information about the Squeak-dev
mailing list
|