Python's DSLs

[Cameron Laird]

In article <1hf1iaz.1qdpj4h1mj5f71N%aleax at mac.com>,
Alex Martelli <aleax at mac.com> wrote:
>Cameron Laird <claird at lairds.us> wrote:
>   ...
>> On this one isolated matter, though, I'm confused, Alex:  I sure
>> think *I* have been writing DSLs as specializations of Python,
>> and NOT as "a language in its own right".  Have I been fooling
>> myself, or are you making the point that Lisp-based DSLs live in
>> a larger syntactic universe than Python's, or ...?
>
>With Lisp (or Scheme, for that matter), a DSL "lives" in exactly the
>same world as the base language, while being able to add or tweak
>whatever syntax it needs; with Python (or C++ or Java, for that matter),
>a DSL is either a completely separate beast (parsed, compiled, perhaps
>interpreted in the "host" language), or else it uses exactly the same
>syntax as used in the host language.  To rapidly build, experiment with,
>and tweak, DSL's, a language with macros is thus advantaged.
>
>As to how crucial that is for _production_ (as opposed to _research_)
>purposes, well, obviously I prefer having no macros (or else I'd use
>some form of Lisp, or perhaps Dylan -- at least for my own private
>purposes, such as my long-standing personal research into the
>fundamentals of contract bridge -- while in fact I prefer to use Python
>for those purposes just as for others).  But that doesn't make me blind
>to the advantages of macros for DSL-building purposes (if I was totally
>sold on both Python AND macros, I think I might build a macro
>preprocessor on top of Python -- the current ASL-based compiler probably
>makes that task much more feasible than it used to be -- but, macros
>would be somewhat complicated as in Dylan, not extremely easy as in
>Scheme [[or, I guess, Common Lisp, though I have no real experience with
>those -- on the surface they look murkier than Scheme's, but that may be
>just an issue of habit on my part]]).
>
>
>Alex

Ah!  I understand much better now.

You correctly distinguish, say, Lisp, Dylan, ... from Python, C,
Java, ... for their syntactic aptness at construction of DSLs.
I don't want that to mislead readers, though, who might thus fail
to see how Python *is* different from C, Java, ..., in its
convenience for implementation of a particular kind of Python-
looking DSL.  As you know, it's easy (if heavy with security
consequences) in Python to eval(), and it's not in C or Java.
The Python run-time builds in a complete interpreter, and that's
different from the base functionality of C or Java.

A consequence is that, in Python, it's an exercise for a beginner
to write, say an assembler whose syntax is a sequence of function
calls (<URL: http://www.unixreview.com/documents/s=9133/ur0404e/ >).
C or Java can't really boast the same.