Does any of you have experiences implementing Domain Specific Languages
(DSL) in Lisp?
I have been dealing with OMG's MOF and Java frameworks such as EMF to
create DSL but the more I learn about Lisp the more it seems it could
be a great way to describe models and generators for different
languages and platforms.
I was also somewhat curious that I didnt find any MOF frameworks in
Lisp and maybe the intrinsic capabilities of the Lisp language make
something like MOF irrelevant. Is that the case?
FYI: I am not a LISP expert.
"igor" <········@gmail.com> writes:
> Does any of you have experiences implementing Domain Specific Languages
> (DSL) in Lisp?
Yes. For some of us, that's *all* we do.
> I have been dealing with OMG's MOF and Java frameworks such as EMF
> to create DSL but the more I learn about Lisp the more it seems it
> could be a great way to describe models and generators for different
> languages and platforms.
We live in a strange world where folks coming from completely
different places and philosophies (the OMG/UML/RUP/whatever crowd and
Lispers) seem to be converging.
I did a duelling consultants gig a while back where the other
consultant was a Executable UML guru. He was explaining Executable
UML--how you write code (a "model compiler") that takes some data (a
"model") and translates it into code you can actually run--to the
client and looked at me shaking my head in disbelief and said, "Hmmm,
you don't seem to be buying this", and I said, "No, I *totally* buy
it; you've just described Lisp."
> I was also somewhat curious that I didnt find any MOF frameworks in
> Lisp and maybe the intrinsic capabilities of the Lisp language make
> something like MOF irrelevant. Is that the case?
Pretty much. From our jaded view, the MOF guys are just beginning to
get to the point where their wheel is roughly hexagonal or octagonal;
give 'em a few more decades and they'll have something approaching the
smooth roundness of Lisp.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
igor wrote:
> Does any of you have experiences implementing Domain Specific Languages
> (DSL) in Lisp?
>
> I have been dealing with OMG's MOF and Java frameworks such as EMF to
> create DSL but the more I learn about Lisp the more it seems it could
> be a great way to describe models and generators for different
> languages and platforms.
>
> I was also somewhat curious that I didnt find any MOF frameworks in
> Lisp and maybe the intrinsic capabilities of the Lisp language make
> something like MOF irrelevant. Is that the case?
Common Lisp (and other Lisp dialects like Scheme) comes with a very
powerful compile-time metaprogramming framework. You are using it
whenever you implement a macro, since macros are basically a seamless
source code transformation approach. Unlike C-style textual macros,
Lisp-based macros actually reflect the nested structure of source code,
so you can express nice transformation in a very convenient way. You can
learn about macro programming in almost any Common Lisp tutorial, but a
particularly good one is the book "On Lisp" by Paul Graham which you can
download for free from his website.
Many Common Lisp implementations (and again some Scheme implementations)
also come with a very powerful runtime metaprogramming framework. It is
based on the object-oriented extension of Common Lisp, the Common Lisp
Object System (CLOS) which can itself be implemented in terms of itself.
There is the CLOS Metaobject Protocol, which is basically a
specification which prescribes how certain important elements of CLOS
have to be implemented in terms of metaclasses, meta-level generic
functions and meta-level methods, so that you can write your own
metaclasses, etc., to extend and change the behavior of CLOS. This is
done in a very clean way so that you can make sure that your extensions
only apply to those parts of your program that actually request those
extensions - so you cannot accidentally break programs that rely on the
standard CLOS behavior. For example, in the CLOS MOP, you can describe
how lookup of slots/fields in classes is performed, how methods are
invoked, etc. A typical use case is the rewiring of slot/field lookup so
that they implicitly looked up in a database instead of internal memory.
Recommended literature about the CLOS MOP is Andreas Paepcke's paper
"User-Level Language Crafting", available at his website, and the book
"The Art of the Metaobject Protocol" by Kiczales et al.
These two metaprogramming frameworks - macros for compile-time and the
CLOS MOP for runtime - can be combined in very powerful ways. For
example, macros can prepare code that will eventually be executed in
custom ways by CLOS MOP extensions.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Very interesting. So in some ways what EMF does as a whole code
generation step, Lisp does using macros. Actually, the fact that macros
are part of the language makes it even more interesting since there is
no need to a code generation framework: its there with the language.
I think I am starting to see how what I am doing with Java and EMF
could be done in a much nicer/simpler way with CLOS MOP. The main
difference that I see is that in the latter case, the metamodeling
layer is not hosted (not sure if that is the right terminology here) in
Lisp, but part of the language (iow, extends it).
So I can define my little language with MOP and use macros to make them
look like native classes that the user can manipulate, etc. What about
the features that EMF provides out of the box and that are essential
for any serious development. One example of such feature is the
notification framework. How in MOP can I observe change events in a
model I created? Is there is framework in MOP that I can use or is that
something I need to build from scratch?
Persisting models is another important aspect of EMF. EMF provides a
xml standard persistence using the XMI standard but other persistence
framework could be plugged into it (there are actually only two of them
that I know of). How would that work in CLOS and MOP? Are there
libraries to use of is that something that MOP provides out of the box?
Another very important aspect are transformations, i.e. transforming
one model into another model and vice versa. Are these model
transformation benefited from CLOS and MOP?
In the little languages I create in EMF, they most of the time have two
metalayers: a definition layer and an instance layer. To give you a
concrete example a DocumentDef would be a class in the definition layer
and DocumentInstance a class in the instance layer. The app manipulates
DocumentDef and creates DocumentInstances so I have to create an
instantiation protocol that takes DocumentDef objects and
"instantiates" DocumentInstance objects. It would be nice if
DocumentDef objects were automatically also classes (the concept of
clabjects) so they could be created using the standard instantiation
protocols. Is that something that MOP can help with?
thanks!
igor wrote:
> Very interesting. So in some ways what EMF does as a whole code
> generation step, Lisp does using macros. Actually, the fact that macros
> are part of the language makes it even more interesting since there is
> no need to a code generation framework: its there with the language.
>
> I think I am starting to see how what I am doing with Java and EMF
> could be done in a much nicer/simpler way with CLOS MOP. The main
> difference that I see is that in the latter case, the metamodeling
> layer is not hosted (not sure if that is the right terminology here) in
> Lisp, but part of the language (iow, extends it).
>
> So I can define my little language with MOP and use macros to make them
> look like native classes that the user can manipulate, etc.
I would say the macros create the new keywords of the language while
CLOS is just implementation. And I do not think so much in terms of a
distinct language, since the new terms swim amongst the standard Lisp
and even other little user languages, and forms in the new language can
include standard Lisp. Graham talked instead of "building up" Lisp to
the problem domain.
> What about
> the features that EMF provides out of the box and that are essential
> for any serious development. One example of such feature is the
> notification framework. How in MOP can I observe change events in a
> model I created? Is there is framework in MOP that I can use or is that
> something I need to build from scratch?
(a) You can use before/after/around methods on slot writers or, given a
full MOP, the GF (setf slot-value-using-class).
(b) Cells, or roll your own equivalent.
>
> Persisting models is another important aspect of EMF. EMF provides a
> xml standard persistence using the XMI standard but other persistence
> framework could be plugged into it (there are actually only two of them
> that I know of). How would that work in CLOS and MOP? Are there
> libraries to use of is that something that MOP provides out of the box?
I wish. AllegroCL has/had AllegroStore, now pushes AllegroCache. Arthur
Lemmens is talking on a new persistent CLOS soon, but that may not be
ready for prime time. XML is easy to write from Lisp, and there is
cl-xml and I believe others if you want to use those.
>
>
> Another very important aspect are transformations, i.e. transforming
> one model into another model and vice versa. Are these model
> transformation benefited from CLOS and MOP?
Hunh? Whassat?
>
> In the little languages I create in EMF, they most of the time have two
> metalayers: a definition layer and an instance layer. To give you a
> concrete example a DocumentDef would be a class in the definition layer
> and DocumentInstance a class in the instance layer. The app manipulates
> DocumentDef and creates DocumentInstances so I have to create an
> instantiation protocol that takes DocumentDef objects and
> "instantiates" DocumentInstance objects. It would be nice if
> DocumentDef objects were automatically also classes (the concept of
> clabjects) so they could be created using the standard instantiation
> protocols. Is that something that MOP can help with?
I suppose you could use the MOP since classes are instance of a
metaclass, which is really just another class (inheriting from
standard-class instead of standard-object), but when I did what you
describe I just had a Document class and a Form (a Document instance)
class and parallel dual classes for fields, pages (we were modelling
paper forms), sections, groups and then it was pretty easy to iterate
over a document tree to generate a Form "instance" thereof.
As you have surmised, Lisp eliminates a lot of toolthink, we just write
code and achieve the same and more via metaprogramming. The nice thing
is that we are not bouncing around from tool to tool, it is all right in
front of us all the time. We do not need to learn the language of each
tool, and we are never held back by a limitation in a tool.
kt