Do any of the gurus of c.l.l have any recommendations on a book
covering Domain Specific Language design? In the course of my job, I
use commercial finite element analysis software to analyze structures.
Eschewing the idea that re-inventing the wheel is not value added,
each vendor has a custom DSL for their software, with varying degrees
of sophistication. Although, generally speaking, I find all of them
painful to use.
Over the past month, I've been developing a parametric model generator
in Common Lisp specifically targeting one of the FEM packages. The
code does what you would expect in this situation, perform stuff in
Common Lisp and then write commands to a file, in the FEM DSL, that
build and analyze the model. I can't describe how wonderful it is
having a layer of Common Lisp between me and their DSL.
But now I'm starting to have delusions of grandeur. I could modify my
Common Lisp code to either write the commands to a file as it does now
OR it could optionally open a direct connection to the console of the
FEM package and I could interactively drive the FEM package through
Common Lisp. Then, surely, my dreams of world domination would come
to fruition. Or maybe I'd just be able to do some wicked awesome
iterative design optimizations. I'm not picky.
But wait, why limit myself to this one package? Why not add another
layer of abstraction, design my own DSL for FEM analysis, and then
implement backends for whatever FEM package my customer requires? But
I'm not a CS guy. I don't have the first clue about designing a DSL. I
know that I really enjoy doing my work in Common Lisp and that Common
Lisp is well suited for implementing a DSL, but that is the extent of
my knowledge.
So, what I want to do is wrap the specific FEM package DSL in Common
Lisp. Then, evolve the wrapper into a backend for a non-specific FEM
interface written in Common Lisp. This seems like a fairly common use
of Common Lisp, code generation, that is. I just want to get a little
better educated about how to proceed.
See http://www.bayfronttechnologies.com/l02draco.htm
Jim Neighbors coined the term "domain analysis". His 1980 dissertation,
Software Construction using Components, resulted in the creation of a system
written in Lisp that supported the definition of domain languages and the
generation of programs written in them. I still think this is the best work
ever done in the field.
On 11/6/08 12:16 PM, in article
····································@s9g2000prm.googlegroups.com, "Thomas M.
Hermann" <··········@gmail.com> wrote:
> Do any of the gurus of c.l.l have any recommendations on a book
> covering Domain Specific Language design? In the course of my job, I
> use commercial finite element analysis software to analyze structures.
> Eschewing the idea that re-inventing the wheel is not value added,
> each vendor has a custom DSL for their software, with varying degrees
> of sophistication. Although, generally speaking, I find all of them
> painful to use.
>
> Over the past month, I've been developing a parametric model generator
> in Common Lisp specifically targeting one of the FEM packages. The
> code does what you would expect in this situation, perform stuff in
> Common Lisp and then write commands to a file, in the FEM DSL, that
> build and analyze the model. I can't describe how wonderful it is
> having a layer of Common Lisp between me and their DSL.
>
> But now I'm starting to have delusions of grandeur. I could modify my
> Common Lisp code to either write the commands to a file as it does now
> OR it could optionally open a direct connection to the console of the
> FEM package and I could interactively drive the FEM package through
> Common Lisp. Then, surely, my dreams of world domination would come
> to fruition. Or maybe I'd just be able to do some wicked awesome
> iterative design optimizations. I'm not picky.
>
> But wait, why limit myself to this one package? Why not add another
> layer of abstraction, design my own DSL for FEM analysis, and then
> implement backends for whatever FEM package my customer requires? But
> I'm not a CS guy. I don't have the first clue about designing a DSL. I
> know that I really enjoy doing my work in Common Lisp and that Common
> Lisp is well suited for implementing a DSL, but that is the extent of
> my knowledge.
>
> So, what I want to do is wrap the specific FEM package DSL in Common
> Lisp. Then, evolve the wrapper into a backend for a non-specific FEM
> interface written in Common Lisp. This seems like a fairly common use
> of Common Lisp, code generation, that is. I just want to get a little
> better educated about how to proceed.
P� Thu, 06 Nov 2008 21:16:17 +0100, skrev Thomas M. Hermann
<··········@gmail.com>:
> Do any of the gurus of c.l.l have any recommendations on a book
> covering Domain Specific Language design? In the course of my job, I
> use commercial finite element analysis software to analyze structures.
> Eschewing the idea that re-inventing the wheel is not value added,
> each vendor has a custom DSL for their software, with varying degrees
> of sophistication. Although, generally speaking, I find all of them
> painful to use.
>
Several books come to mind. Paradigms in Artificial Intelligence
Programming Common Lisp by Peter Norvig and Practical Common Lisp both
shows several domain specific languages and then there is On Lisp by Paul
graham.
> Over the past month, I've been developing a parametric model generator
> in Common Lisp specifically targeting one of the FEM packages. The
> code does what you would expect in this situation, perform stuff in
> Common Lisp and then write commands to a file, in the FEM DSL, that
> build and analyze the model. I can't describe how wonderful it is
> having a layer of Common Lisp between me and their DSL.
>
> But now I'm starting to have delusions of grandeur. I could modify my
> Common Lisp code to either write the commands to a file as it does now
> OR it could optionally open a direct connection to the console of the
> FEM package and I could interactively drive the FEM package through
> Common Lisp. Then, surely, my dreams of world domination would come
> to fruition. Or maybe I'd just be able to do some wicked awesome
> iterative design optimizations. I'm not picky.
>
> But wait, why limit myself to this one package? Why not add another
> layer of abstraction, design my own DSL for FEM analysis, and then
> implement backends for whatever FEM package my customer requires? But
> I'm not a CS guy. I don't have the first clue about designing a DSL. I
> know that I really enjoy doing my work in Common Lisp and that Common
> Lisp is well suited for implementing a DSL, but that is the extent of
> my knowledge.
>
> So, what I want to do is wrap the specific FEM package DSL in Common
> Lisp. Then, evolve the wrapper into a backend for a non-specific FEM
> interface written in Common Lisp. This seems like a fairly common use
> of Common Lisp, code generation, that is. I just want to get a little
> better educated about how to proceed.
I don't know the particulars of this particular problem.
--------------
John Thingstad
On Thu, 06 Nov 2008 12:16:17 -0800, Thomas M. Hermann wrote:
> Do any of the gurus of c.l.l have any recommendations on a book covering
> Domain Specific Language design? In the course of my job, I use
> commercial finite element analysis software to analyze structures.
> Eschewing the idea that re-inventing the wheel is not value added, each
> vendor has a custom DSL for their software, with varying degrees of
> sophistication. Although, generally speaking, I find all of them painful
> to use.
DSL design is mostly an art form that you can pick up by example and
practice. On Lisp by Graham and PAIP by Norvig are good examples, so are
parts of PCL by Seibel. But it is best if you experiment with simple
DSLs, then improve on your code gradually, or sometimes reimplement the
whole thing when you see a better way - Lisp is particularly suited for
this.
> So, what I want to do is wrap the specific FEM package DSL in Common
> Lisp. Then, evolve the wrapper into a backend for a non-specific FEM
> interface written in Common Lisp. This seems like a fairly common use of
> Common Lisp, code generation, that is. I just want to get a little
> better educated about how to proceed.
I work with finite element methods myself, but entirely in Lisp with a
bit of foreign code (like UMFpack). You need to think about your problem
domain and what you are trying to accomplish. Is it only symbolic
description of a problem which you can then feed to the backend, or
something more involved, like actual computations performed in Lisp.
Start small, build it up as you use it. Find redundancies and automate
them. If it becomes a tangled mess, take a deep breath and rewrite the
whole thing. At least that's how I work :-)
BTW, I recently came a cross a wonderful book on FEM with B-splines,
http://www.ec-securehost.com/SIAM/FR26.html
HTH,
Tamas
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Good Reference on DSL's
Date:
Message-ID: <REM-2008nov07-001@Yahoo.Com>
> From: Tamas K Papp <······@gmail.com>
> DSL design is mostly an art form that you can pick up by example
> and practice.
I agree.
> But it is best if you experiment with simple DSLs, then improve
> on your code gradually, or sometimes reimplement the whole thing
> when you see a better way - Lisp is particularly suited for this.
Or just refactor the code you already have. See later below.
> You need to think about your problem domain and what you are
> trying to accomplish.
I agree.
> Start small, build it up as you use it. Find redundancies and
> automate them. If it becomes a tangled mess, take a deep breath
> and rewrite the whole thing. At least that's how I work :-)
To reduce the amount of tangled mess that is even possible, I
suggest breaking everything down into data-processing
transformations. If you have two ways of representing some data,
called "foo" and "baz", and there's a way to convert from foo to
baz, then have a function called foo-to-baz, with documentation to
more fully explain how this transformation is done, and of course
at the very start you need to clearly document foo and baz
individually. If there are lots of ways to convert foo to baz, and
an additional parameter called "matrix" specifies exactly which
particular transformation is to be done, then you have a function
foo+matrix-to-baz which takes two parameters of types foo and
matrix respectively and returns an object of type baz. Using lots
of such keywords makes it easy to use grep to find appropriate
functions if you revisit the code months later and forget which
functions are available. And when you do need to refactor, it would
be simply writing new functions to handle any new object types
you've added, and reorganizing your dataflow involving these
functions (old and new), rather than totally rewriting the main
bulk of the code. If you want, you can call this "extreme modular
programming".
And any time you start with just one known transformation of data
from foo to baz, but later you realize there are more than one
transformation, use a keyword parameter to introduce the
specification of which transformation, with the default being the
old behaviour. This has the disadvantage that the name remains
foo-to-baz even though it takes &key matrix, but that's OK. Do the
best you can with design and naming and keywords, but don't fret if
you don't get it perfect the first time. Take full advantage of
Lisp's ability to let your application grow with experience.
Don't forget to use unwind-protect liberally in places where it's
really bad to leave something unclean after an abort. For example,
temporary network/DB/filesystem streams and sub-processes ought to
be opened inside an unwind-protect and closed during the cleanup
clause of that same unwind-protect.
Thanks for all of the replies. I have the PDF of On Lisp and purchased
PAIP several months ago. I just haven't taken the time to work through
either. The domain analysis references look interesting and I'll have
to find some time to go through them.
It seems that the consensus approach is to evolve the code. That's
probably the best because it allows me to get my current tasks done
now without going through all of the references. Then, as I go through
the references, I can start incorporating what I learn.
On Nov 6, 4:11 pm, Tamas K Papp <······@gmail.com> wrote:
> BTW, I recently came a cross a wonderful book on FEM with B-splines,
> http://www.ec-securehost.com/SIAM/FR26.html
Thanks for the pointer. I was musing about alternative shape functions
the other day but hadn't followed up my musings with any literature
review. That looks like a great start.
Cheers,
Tom