4 ms·

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there ar

There are such DSLs on top of Common Lisp. But usually not on the scope of a full programming language like Pascal. It is not that typical anymore, but there are examples in that direction. --------------------------- I have found two examples: 1. Python in Lisp: http://github.com/franzinc/cl-python http://github.com/franzinc/cl-python 2. Ruby on Lisp: http://jng.imagine27.com/articles/2010-10-07-084756_ruby_subset_implementation.html http://jng.imagine27.com/articles/2010-10-07-084756_ruby_sub... I will try to write little subset of Pascal as eDSL on Lisp.

lispm 16y ago
Usually these languages like Python are implemented on top of Lisp using a special parser. Of that there are many, from C, Python to special research languages. Then there are a lot of languages with lispy syntax. Typical examples were Prolog dialects with Lisp syntax (and optional Prolog syntax). The example that languages are embedded into a single s-expression (like in the LOOP macro) is also possible, but different. It would not make sense to use Python that way, since the low level syntax of Python is different from what Lisp s-expressions provide. For example s-expressions are not preserving any textual layout (indentation) when read - something that a language that uses indentation in its syntax would need, but would not get from being embedded in a single s-expression.
- kung-fu-master 16y ago
  Hmmm... it's interesting... I came to conclusion that it is easier to do external DSL, not embedded. Parse source code on Pascal and then translate it into S-expressions. Am I right? Btw, if I'm gonna write external DSL, I can do that in any language for example on Python. So, what's the difference?
sedachv 16y ago
There is also cl-javascript: http://github.com/akapav/js http://github.com/akapav/js The advantage of doing a "language X to CL" translator is that it's going to be much simpler than doing it in another language (the number of features offered by CL is a huge superset of that available in any other language; the only exception is continuations), the result will be faster (the example Ruby translator is faster than Ruby, cl-javascript is faster than SpiderMonkey, etc, mostly due to SBCL being a reasonably good compiler), and you will have access to really good debugging tools (Clozure is really good at this - see http://openmcl.clozure.com/ccl-documentation.html#watched-objects http://openmcl.clozure.com/ccl-documentation.html#watched-ob... for example).

lispm 16y ago

Usually these languages like Python are implemented on top of Lisp using a special parser. Of that there are many, from C, Python to special research languages. Then there are a lot of languages with lispy syntax. Typical examples were Prolog dialects with Lisp syntax (and optional Prolog syntax). The example that languages are embedded into a single s-expression (like in the LOOP macro) is also possible, but different. It would not make sense to use Python that way, since the low level syntax of Python is different from what Lisp s-expressions provide. For example s-expressions are not preserving any textual layout (indentation) when read - something that a language that uses indentation in its syntax would need, but would not get from being embedded in a single s-expression.

kung-fu-master 16y ago
Hmmm... it's interesting... I came to conclusion that it is easier to do external DSL, not embedded. Parse source code on Pascal and then translate it into S-expressions. Am I right? Btw, if I'm gonna write external DSL, I can do that in any language for example on Python. So, what's the difference?

sedachv 16y ago

There is also cl-javascript: http://github.com/akapav/js http://github.com/akapav/js The advantage of doing a "language X to CL" translator is that it's going to be much simpler than doing it in another language (the number of features offered by CL is a huge superset of that available in any other language; the only exception is continuations), the result will be faster (the example Ruby translator is faster than Ruby, cl-javascript is faster than SpiderMonkey, etc, mostly due to SBCL being a reasonably good compiler), and you will have access to really good debugging tools (Clozure is really good at this - see http://openmcl.clozure.com/ccl-documentation.html#watched-objects http://openmcl.clozure.com/ccl-documentation.html#watched-ob... for example).