Re: Python gets macros - now XML does too

From: Manuel Lemos (mlemos_at_acm.org)
Date: 01/12/05


Date: Wed, 12 Jan 2005 05:12:50 -0200

Hello,

on 01/12/2005 02:07 AM drewc said the following:
>>> I guess the special thing about Level 2 is the translation can be
>>> arbitrarily complex, which is true of Lisp macros. And in practice, Lisp
>>> macros are often used to implement the "compilation" of a high-level
>>> domain-specific language as you describe.
>>
>>
>> This explanation sounds confusing to me. Are you saying that you can
>> use LISP macros to generate code in another language, say PHP, Java,
>> Perl, etc...?
>
> Of course they can, people have been trying to tell you this all along!
>
> Infact there was a post earlier today called "simple compiler to CLI
> (.NET) ilasm" where the author implements a compiler for a toy lisp that
> compiles to CLI bytecodes. using lisp and macros. if we can generate
> bytecode, PHP is simple.

No, this is not yet clear to me. Maybe I need a concrete example of how
everything works to clear my doubts.

I am not asking if you can use Lisp macros or whatever to write a
generator program that once run it generates code in another language or
  some other type of files. (Lisp -> compiled executable Lisp -> run to
generate code in PHP/Java/Perl/etc...)

What I am asking is whether your Lisp compiler outputs PHP source code
(or of any other language besides Lisp) as opposed to generate runtime
binaries? (Lisp -> PHP/Java/Perl/etc...)

>> You see, I do not have an interest now in using Lisp specifically.
>> Actually my main concern right now is PHP. I just developed MetaL
>> because I may need to switch to start developing in other languages.
>
> One of the first things i built in lisp was a macro to generate a php
> object-relational mapping that was consistent across datasources, and
> generates all the objects from the database schema automagically.

Do you have the source code available publically so I can see how the
generation of PHP works in practice?

>>>> Despite currently I only use PHP because I only develop Web
>>>> applications, I don't know about the future. If I need to switch to
>>>> another target language, I just need to develop the lower level
>>>> translation modules of MetaL to support another language, and so my
>>>> current work supporting PHP applications will not be wasted.
>
> I think the point people are trying to make here is that MetaL has
> defined semantics that are similar to the target language (php). It

I can tell that I have been unsuccessful in making clear that in MetaL
nothing is hardcoded. Maybe that is because I am not an native English
speaker and I am probably not using the right terms. So, let me try once
more.

MetaL is a modular engine. I wrote several modules for basic things that
all languages provide like flow control, expression manipulation, etc...

If you do not like for instance the capabilities of my MetaL flow
control, fine, write your own and use it in your programs.

That does not prevent you from using the other modules and each module
is completely unaware of the existence of each other although they keep
piping generated code expressions, command, etc. to each other.

This means that you also can use your flow control module together and
the engine won't get confused.

Given this, if you see limitations in the available MetaL engine
modules, you are not tied to those limitations, because not only you can
redefine the language commands but you can also create a totally new
language that performs arbitrary actions which may include things that
are not even related to generating code, like in the example of managing
a build process like make tool that I mentioned in a previous message.

> would be very hard to generate good lisp code from your XML templates,
> because they use idioms that a lisp programmer would not use.

Sure, using just the existing modules may result in code that may not be
optimal in Lisp or even PHP, in the opinion of some. But that is besides
the point. The point is that as long as I (or somebody else) writes the
necessary bindings for each module to generate code in Lisp or any other
new language, the generated code produces the same results and so I can
reuse existing MetaL code libraries to support a new language.

> For example, can you support multiple dispatch or eql predicates?
> functions as first class objects? tail call recursion? There is a lot of
> functionality in lisp that is at a higer-level then what MetaL appears
> to support (correct me if i'm wrong).

It seems you are using Lisp specific terminology that I am not sure if I
understand what it means, so it is hard for me to tell whether the
existing MetaL modules support what you are mentioning.

Anyway, if they don't support those features and they are a good thing
for developers of any language maybe it is worth improving the existing
modules or adding new modules to implement such features.

-- 
Regards,
Manuel Lemos
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/
Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html


Relevant Pages

  • Re: Python gets macros - now XML does too
    ... >>final target language of choice. ... Currently PHP, Java, and Perl are ... > What you called level 2 metaprogramming is possible in Lisp, ... of business in 1994 and that marked the end of the Amiga computers era, ...
    (comp.lang.lisp)
  • Re: OT: sexps for other languages?
    ... Following in the tradition of early C++, this language would be ... Writting an assembler is Lisp is easy. ... You benefit immediately of Lisp macros, and can use any lisp function ... you have to streamline and sexpify the assembler instruction syntax. ...
    (comp.lang.lisp)
  • Re: Python gets macros - now XML does too
    ... In Lisp, with macro expansion you can do arbitrary ... > domain-specific language as you describe. ... LISP macros to generate code in another language, say PHP, Java, Perl, ... Actually my main concern right now is PHP. ...
    (comp.lang.lisp)
  • Re: Interesting developments since "Beating the averages"?
    ... Since Lisp began its career as a family of dialects, standardization after the fact was necessary. ... python or PHP never had this problem. ... that's what Parrot is going to be: A single language with skinnable ... Parrot is a Virtual Machine. ...
    (comp.lang.lisp)
  • Lisp anxieties
    ... some experienced Lispers thought of the PHP language. ... I know what Lispers will say about PHP. ... Will lisp be able to handle that sort of load without me having to ...
    (comp.lang.lisp)