I once came up with a joke obfuscated programming language that
attempted to use XML as a programming language:
http://www.markcarter.me.uk/computing/xs.html
People have been predicting programming languages based on XML, as a
kind of nightmarish take on s-exprs. Well, now their nightmares have
become manifest, as the world now has MetaL:
> MetaL is shorthand for Meta-programming Language. Meta-programming is a method to develop computer programs. It works by generating source code in a target language from a program specification in a higher level language.
>
> MetaL programs source code is based on XML. MetaL compiler engine can be used to generate the same program from MetaL source code to potentially any target language. Currently supported target languages are PHP, Java and Perl. The support for other languages can be added any time.
Taken from:
http://www.meta-language.net/#metal
Mark Carter <··@privacy.net> wrote:
>> MetaL is shorthand for Meta-programming Language. Meta-programming is
>> a method to develop computer programs. It works by generating source
>> code in a target language from a program specification in a higher
>> level language.
and more from the FAQ http://www.meta-language.net/faq.html#good :
| Language of powerful commands
| Programs written in a language with powerful commands require less code
| to be written. Therefore it takes to develop such programs and
| consequently, less time to market them.
But the example from http://www.meta-language.net/sample.html#class-metal
is 1552 lines of really unreadable code and the generated PHP code is 290
lines.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Mark Carter <··@privacy.net> wrote:
>
> >> MetaL is shorthand for Meta-programming Language. Meta-programming is
> >> a method to develop computer programs. It works by generating source
> >> code in a target language from a program specification in a higher
> >> level language.
>
> and more from the FAQ http://www.meta-language.net/faq.html#good :
>
> | Language of powerful commands
>
> | Programs written in a language with powerful commands require less code
> | to be written. Therefore it takes to develop such programs and
> | consequently, less time to market them.
>
> But the example from http://www.meta-language.net/sample.html#class-metal
> is 1552 lines of really unreadable code and the generated PHP code is 290
> lines.
I guess they just aren't trying hard enough. I'm sure with the right
XML Schema, they can get that to 3000 lines of XML for a full 10:1
code explosion over PHP. Acheiving 10:1 with Java will probably be a
little trickier, but I'm sure it can be done.
So is the programming done by pounding out XML, or can it be made more
painful by submitting forms via HTTP? Perhaps a DHTML front end can
be supplied to work with UML style diagrams to produce the XML.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On 10 Dec 2004 11:33:35 -0500, David Steuber <·····@david-steuber.com>
wrote:
> Frank Buss <··@frank-buss.de> writes:
>
>> Mark Carter <··@privacy.net> wrote:
>>
>> >> MetaL is shorthand for Meta-programming Language. Meta-programming is
>> >> a method to develop computer programs. It works by generating source
>> >> code in a target language from a program specification in a higher
>> >> level language.
>>
>> and more from the FAQ http://www.meta-language.net/faq.html#good :
>>
>> | Language of powerful commands
>>
>> | Programs written in a language with powerful commands require less
>> code
>> | to be written. Therefore it takes to develop such programs and
>> | consequently, less time to market them.
>>
>> But the example from
>> http://www.meta-language.net/sample.html#class-metal
>> is 1552 lines of really unreadable code and the generated PHP code is
>> 290
>> lines.
>
> I guess they just aren't trying hard enough. I'm sure with the right
> XML Schema, they can get that to 3000 lines of XML for a full 10:1
> code explosion over PHP. Acheiving 10:1 with Java will probably be a
> little trickier, but I'm sure it can be done.
>
> So is the programming done by pounding out XML, or can it be made more
> painful by submitting forms via HTTP? Perhaps a DHTML front end can
> be supplied to work with UML style diagrams to produce the XML.
>
lol.. Perhaps Intel should fund the world wide web consortium.
Sun has already created a market for it's workstations with
Java..
How else will we convince people they need to scrap their current
machine to get a even bigger one?
BLOAT WARE is incuraged by hardware developers..
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Karl A. Krueger
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <cpd48m$62u$1@baldur.whoi.edu>
John Thingstad <··············@chello.no> wrote:
> On 10 Dec 2004 11:33:35 -0500, David Steuber <·····@david-steuber.com>
> wrote:
>> So is the programming done by pounding out XML, or can it be made more
>> painful by submitting forms via HTTP? Perhaps a DHTML front end can
>> be supplied to work with UML style diagrams to produce the XML.
>
> lol.. Perhaps Intel should fund the world wide web consortium.
> Sun has already created a market for it's workstations with
> Java..
> How else will we convince people they need to scrap their current
> machine to get a even bigger one?
> BLOAT WARE is incuraged by hardware developers..
It sounds like conspiracy theory, but I recall that when Intel was
pushing one of the Pentium models (Pentium II?) they were advertising it
as "making the Internet go faster" ... and running a rewards program for
Web developers who filled their sites with heavy multimedia that would
require faster processors to render well.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.
Frank Buss <··@frank-buss.de> writes:
> Mark Carter <··@privacy.net> wrote:
>
>>> MetaL is shorthand for Meta-programming Language. Meta-programming is
>>> a method to develop computer programs. It works by generating source
>>> code in a target language from a program specification in a higher
>>> level language.
>
> and more from the FAQ http://www.meta-language.net/faq.html#good :
>
> | Language of powerful commands
>
> | Programs written in a language with powerful commands require less code
> | to be written. Therefore it takes to develop such programs and
> | consequently, less time to market them.
>
> But the example from http://www.meta-language.net/sample.html#class-metal
> is 1552 lines of really unreadable code and the generated PHP code is 290
> lines.
Okay, so that's terrifying. But on the off chance that MetaL takes off
we're all set--just write a sexp->MetaL compiler and then we can
program MetaL in a Lispy language and probably be much more productive
than folks programming on the bare, er, MetaL.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Duane Rettig
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <4zn0mngee.fsf@franz.com>
Peter Seibel <·····@javamonkey.com> writes:
> Frank Buss <··@frank-buss.de> writes:
>
> > Mark Carter <··@privacy.net> wrote:
> >
> >>> MetaL is shorthand for Meta-programming Language. Meta-programming is
> >>> a method to develop computer programs. It works by generating source
> >>> code in a target language from a program specification in a higher
> >>> level language.
> >
> > and more from the FAQ http://www.meta-language.net/faq.html#good :
> >
> > | Language of powerful commands
> >
> > | Programs written in a language with powerful commands require less code
> > | to be written. Therefore it takes to develop such programs and
> > | consequently, less time to market them.
> >
> > But the example from http://www.meta-language.net/sample.html#class-metal
> > is 1552 lines of really unreadable code and the generated PHP code is 290
> > lines.
>
> Okay, so that's terrifying. But on the off chance that MetaL takes off
> we're all set--just write a sexp->MetaL compiler and then we can
> program MetaL in a Lispy language and probably be much more productive
> than folks programming on the bare, er, MetaL.
And we'll name ours MetaLite, and nickname theirs Heavy MetaL.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Manuel Lemos
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <41BA423A.2000408@acm.org>
Hello,
Thank you for your interest in MetaL. As the author of this language
concept I would like to clarify that I am not a linguist nor I developed
the language as an academic experiment. It was meant to address real
world problems in a different way, but it was not with the goal to
replace existing languages.
Given these facts, below you may find more explanations regarding your
points. Please excuse me for any errors as I am not a native english
speaker (writer).
Frank Buss wrote:
> Mark Carter <··@privacy.net> wrote:
>
>>>MetaL is shorthand for Meta-programming Language. Meta-programming is
>>>a method to develop computer programs. It works by generating source
>>>code in a target language from a program specification in a higher
>>>level language.
>
> and more from the FAQ http://www.meta-language.net/faq.html#good :
>
> | Language of powerful commands
>
> | Programs written in a language with powerful commands require less code
> | to be written. Therefore it takes to develop such programs and
> | consequently, less time to market them.
>
> But the example from http://www.meta-language.net/sample.html#class-metal
> is 1552 lines of really unreadable code and the generated PHP code is 290
> lines.
Well, most new languages will look to you as unreadable in the beginning
unless they use a syntax that is similar to the ones you know.
MetaL practically lets you define a new syntax and the add new language
commands with your own compiler modules or with commands that act like
macros.
The sample code was not meant to show that it can be used to reduce the
amount of code that you need to write. It is rather meant to present a
proof of concept to show that this is not just theory and you can indeed
generate equivalent code at least in PHP and in Java from a single
source code in MetaL.
The sample code also shows that it can generate separate documentation
for PHP and Java versions, which does not weight in the generated PHP or
Java source code.
Today I only develop in PHP but I do not know about the future. In the
past I used to develop in C for Commodore Amiga computers. It was great
but some day Commodore went out of business and the code of my Amiga
applications and components could hardly be reused in any project for
other platforms. This was my main motivation to avoid developing
applications that are too much dependent on specific languages and
platforms.
Anyway, the greatest gains, even in code size, do not comes from level 1
meta-programming. As you noticed, most MetaL commands used in the sample
code were translated in a few commands in PHP, mainly because PHP is
already a language of powerful commands, especially considering Web
application development needs.
The greatest gains come meta-programming level 2 and eventually higher
levels that can be built above that.
In level 1 you just translate meta-programming commands into commands of
the target language. In level 2 you have two levels of translation. So,
the constructs of level 2 tend to be much more powerful in terms of how
much code can be generate and how many project features can be
implemented with much less effort.
The MetaL compiler engine is so flexible that it can be used to build as
many meta-programming levels as necessary because it is a matter of
pipelining the results of processing source code in one level to the
levels below.
This is probably too abstract without a real example. So, let me tell
you about a level 2 meta-programming project based on the MetaL engine.
Metastorage is an application meant for generation persistence layers to
store objects in persistence storage containers such as SQL based
databases, XML, flat file databases, data on LDAP servers, etc...
Currently only SQL databases are supported as persistent object containers.
http://www.meta-language.net/metastorage.html
Metastorage takes a description of a component data model in a simple
XML format that describes classes of objects, object properties,
relationships, validation rules, and methods that the developer realizes
that the described classes should have to implement many different types
of operations to manipulate the class objects. Here is an example of the
Metastorage component format:
http://www.meta-language.net/metastorage-documentation.html#example
Metastorage is in reality a script that calls the MetaL compiler engine
to execute certain actions implemented by a special persistence module
and other base MetaL compiler modules.
From a component description, Metastorage is capable of generating
classes of objects in a given target language (currently only PHP is
fully supported) that implement the described persistence operations
interface.
Metastorage also generate a RDBMS independent database schema
description in Metabase XML format and a special class to install or
update the described schema using the Metabase API. Metabase is a PHP
package meant to provide total (read as much as possible) database
independence to the applications, from the database access to the schema
management. You can read more about Metabase here:
http://www.meta-language.net/documentation.html#metabase
Additionally Metastorage may also generate classes that manage Web based
forms to provide a user interface to manipulate the objects of the
persistent classes. The presentation of the forms is configured with
themes. Here are some of the resulting screenshots of actual HTML pages:
http://www.meta-language.net/screenshots.html#forms
As a bonus, Metastorage may also generate UML class diagrams of all the
generated classes. The diagrams are outputted in the DOT format for AT&T
GraphViz. Therefore, the diagrams may be rendered in many common image
or document formats.
It is very useful for illustrating the documentation of projects that
use Metastorage generated code as it helps making the project data
structure clearer, even to computing iliterate people. Here is an
example of a generated UML class diagram:
http://www.meta-language.net/screenshots.html#diagrams
The latest version of Metastorage, yet to be released some time soon,
also includes the ability to generate report data generation classes,
which are much more appropriate than persistent object classes to
generate listings, reports and other read-only batch operations.
Although, Metastorage format looks very much like a static data
description format, you should see it as an example of level 2
meta-programming source code.
As a matter of fact it even includes a full fledged Object Query
Language (OQL) that lets developers describe filter expressions that
should be used by certain methods to specify how their class objects
should be queried and filtered. Here are more details about this OQL:
http://www.meta-language.net/metastorage-documentation.html#class-function-parameter-filter-description
Well, there is a lot more to say about MetaL and the potential of XML
based meta-programming, but I have already talked a lot about this
subject now. Neverless, feel free to ask any questions that you may have.
--
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
Manuel Lemos wrote:
> Well, there is a lot more to say about MetaL and the potential of
> XML based meta-programming, but I have already talked a lot about
> this subject now. Neverless, feel free to ask any questions that
> you may have.
Do you know Lisp?
--tcr.
Hello,
······@freebits.de wrote:
>>Well, there is a lot more to say about MetaL and the potential of
>>XML based meta-programming, but I have already talked a lot about
>>this subject now. Neverless, feel free to ask any questions that
>>you may have.
>
> Do you know Lisp?
I used to program in a dialect of List used by application installer
scripts for Amiga computers.
--
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
Jlu wrote:
> > Do you know Lisp?
>
> Do you know Pliant?
No, I didn't. Thanks for sharing.
Do I interpret your question correctly that you wanted to point
out that there are different languages than Lisp which offer
sufficiently advanced macro facilities? (Not to mention that
Pliant got heavily influenced by Lisp on exactly that.)
--tcr.
Jlu wrote:
>
>> Do you know Lisp?
>
> Do you know Pliant?
Is it comPliant with ANSI CL spec? :-)
It looks interesting for a change. But I'm not sure if my time would be
well-spent looking at it seriously. Upon very superficial examination, it
looks like it doesn't have:
* dynamic typing
* safety
* garbage collection
* runtime patching (?)
* reader macros
* God knows what else...
If someone with solid knowledge of both CL and Pliant wrote a thorough
comparison, I might have looked further.
* Manuel Lemos (······@acm.org)
...
> Well, most new languages will look to you as unreadable in the beginning
> unless they use a syntax that is similar to the ones you know.
Yes, but... (see end)
>
> MetaL practically lets you define a new syntax and the add new language
> commands with your own compiler modules or with commands that act like
> macros.
>
Wich is what Lisp already had a long time.
...
> Well, there is a lot more to say about MetaL and the potential of XML
> based meta-programming,
The 'XML based' is the basic flaw. Something like
<case>
<value>34</value>
<do>
<set>
<variable>character</variable>
<string>&quot;</string>
</set>
<break />
</do>
</case>
is so terribly more cluttered than *any* language I know of that
I immediately back off.
Furthermore, even if the metaprogramming lets me define new syntax
it will still bear the XML notational overhead, *and* my transformers
will have to produce the stuff above.
In short: Yeah, it works, but why bother with a (badly reinvented) wheel?
Just because of the current XML craze?
Andreas
--
np: 4'33
Hello,
Andreas Krey wrote:
>>MetaL practically lets you define a new syntax and the add new language
>>commands with your own compiler modules or with commands that act like
>>macros.
>>
> Wich is what Lisp already had a long time.
I do not know enough of Lisp to comment.
MetaL commands are implemented by modules of the MetaL compiler which is
totally written in PHP (not in MetaL). These modules implement functions
that are associated to command tags.
When the MetaL compiler traverses the MetaL source it invokes the
compiler module associated to each tag and executes some action. This is
very similar to Ant (of Java), except that the result from the actions
is a stream of commands in the target language. This stream may be
processed recursively (in case of nested tags) and the final result is
typically a source code file in the target language.
From then on, you take the resulting code and integrate it in your
applications of the target language, which may or may not have been
totally written in MetaL. I suppose this is different from what is done
in Lisp.
>>Well, there is a lot more to say about MetaL and the potential of XML
>>based meta-programming,
>
> The 'XML based' is the basic flaw. Something like
>
> <case>
> <value>34</value>
> <do>
> <set>
> <variable>character</variable>
> <string>&quot;</string>
> </set>
> <break />
> </do>
> </case>
>
> is so terribly more cluttered than *any* language I know of that
> I immediately back off.
Right, I agree that XML requires typing redundant text. I even have
suggested the W3C consortium to simplify the requirements, for instance
allowing the end tag be just </> and the example above would look simpler:
<case>
<value>34</>
<do>
<set>
<variable>character</>
<string>&quot;</>
</>
<break />
</>
</>
Anyway, when asked a member of the consortium how to propose to allow
such simplifications for XML 2.0, he told me that I could propose it but
it would hardly be accepted. So, I did not bother to propose as it
seemed like I would be wasting my time.
> Furthermore, even if the metaprogramming lets me define new syntax
> it will still bear the XML notational overhead, *and* my transformers
> will have to produce the stuff above.
>
> In short: Yeah, it works, but why bother with a (badly reinvented) wheel?
> Just because of the current XML craze?
There are other reasons to prefer XML as it is explained in this
presentation slide:
http://www.meta-language.net/metal/15_8.html
--
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
On Sat, 11 Dec 2004 15:16:40 -0200, Manuel Lemos wrote:
>> In short: Yeah, it works, but why bother with a (badly reinvented)
>> wheel? Just because of the current XML craze?
>
> There are other reasons to prefer XML as it is explained in this
> presentation slide:
>
> http://www.meta-language.net/metal/15_8.html
The slide is wrong. The hard part of writing a compiler is not the
parser. Using XML as a programming language syntax solves the easy part,
badly. XML "parsers" are arguably not real parsers anyway, since they
don't really understand what they are reading. You still need to add that
step after your XML "parser" has tokenised the input for you.
Do yourself a favour: just learn Lisp.
Cheers,
Bill.
William Bland <·······@abstractnonsense.com> writes:
> The hard part of writing a compiler is not the parser.
This reminds me of a discussion� here from September 2004.
Footnotes:
� http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/968c69373eb8e276/141ba3f03c080340
--
Steven E. Harris
Hello,
William Bland wrote:
>>>In short: Yeah, it works, but why bother with a (badly reinvented)
>>>wheel? Just because of the current XML craze?
>>There are other reasons to prefer XML as it is explained in this
>>presentation slide:
>>
>>http://www.meta-language.net/metal/15_8.html
>
> The slide is wrong. The hard part of writing a compiler is not the
The slide does not say the parser is the hard part of a compiler. It
says that XML parsers are widely available for every language and it
comes built-in including for PHP which is the language in which the
MetaL compiler is written.
The same could not be said about Lisp parsers. Actually, if any Lisp
parsers were available for PHP, I would probably have coniderered it.
> parser. Using XML as a programming language syntax solves the easy part,
> badly. XML "parsers" are arguably not real parsers anyway, since they
> don't really understand what they are reading. You still need to add that
> step after your XML "parser" has tokenised the input for you.
>
> Do yourself a favour: just learn Lisp.
I just came here because Frank Buss notified me of a message posted here
raising some concerns about MetaL. I am not interested in language
competitions. Everybody has preferences and I respect that. So, if this
is going to turn into an unproductive language flame war, please excuse
me for not going to take part of that.
--
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
On Sat, 11 Dec 2004 16:40:38 -0200, Manuel Lemos wrote:
> Everybody has preferences and I respect that.
Me too... to a certain extent. But I do refuse to be part of the awful
"all languages are Turing complete, so we must not say that any one of
them is better than any other" mindset. I prefer Lisp for good reasons,
and I'm happy to pass them on to anyone who is interested.
> So, if this is going to turn into an unproductive language flame war,
> please excuse me for not going to take part of that.
I'm not trying to start any kind of flame war at all. Just trying to give
some good advice.
Best wishes,
Bill.
Hello,
William Bland wrote:
>>Everybody has preferences and I respect that.
>
> Me too... to a certain extent. But I do refuse to be part of the awful
> "all languages are Turing complete, so we must not say that any one of
> them is better than any other" mindset. I prefer Lisp for good reasons,
> and I'm happy to pass them on to anyone who is interested.
I do not disagree with that thought. I just think that since different
people value different aspects of each language, it does not make much
sense to expect that everybody should agree that Lisp is the one and
only language that everybody should appreciate.
>>So, if this is going to turn into an unproductive language flame war,
>>please excuse me for not going to take part of that.
>
> I'm not trying to start any kind of flame war at all. Just trying to give
> some good advice.
I appreciate the intention, but statements like "go and learn my
favorite language" does not seem to be a productive way to make a point
about the benefits of that language to other people that do not
appreciate it that much, especially after I have mentioned that I
already learned Lisp dialect in the past.
--
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
"Manuel Lemos" <······@acm.org> wrote in message
····················@individual.net...
> Hello,
>
> William Bland wrote:
>>>Everybody has preferences and I respect that.
>>
>> Me too... to a certain extent. But I do refuse to be part of the awful
>> "all languages are Turing complete, so we must not say that any one of
>> them is better than any other" mindset. I prefer Lisp for good reasons,
>> and I'm happy to pass them on to anyone who is interested.
>
> I do not disagree with that thought. I just think that since different
> people value different aspects of each language, it does not make much
> sense to expect that everybody should agree that Lisp is the one and only
> language that everybody should appreciate.
If you are still reading the thread Manuel, I think the suggestion to study
up on Lisp is more that just "here! try my favorite language!" You are
apparently interested in language features and language design issues that
are at the heart of the Lisp language. So the perception you probably have
of dismissive responses is not meant personally. And the serious
recommendations to just check out lisp are offered because it solves very
elegantly what issues you seem to be interested in.
>>>So, if this is going to turn into an unproductive language flame war,
>>>please excuse me for not going to take part of that.
>>
>> I'm not trying to start any kind of flame war at all. Just trying to
>> give
>> some good advice.
>
> I appreciate the intention, but statements like "go and learn my favorite
> language" does not seem to be a productive way to make a point about the
> benefits of that language to other people that do not appreciate it that
> much, especially after I have mentioned that I already learned Lisp
> dialect in the past.
Check out Common Lisp.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Hello,
on 12/11/2004 10:35 PM Coby Beck said the following:
>>>>Everybody has preferences and I respect that.
>>>Me too... to a certain extent. But I do refuse to be part of the awful
>>>"all languages are Turing complete, so we must not say that any one of
>>>them is better than any other" mindset. I prefer Lisp for good reasons,
>>>and I'm happy to pass them on to anyone who is interested.
>>I do not disagree with that thought. I just think that since different
>>people value different aspects of each language, it does not make much
>>sense to expect that everybody should agree that Lisp is the one and only
>>language that everybody should appreciate.
>
> If you are still reading the thread Manuel, I think the suggestion to study
> up on Lisp is more that just "here! try my favorite language!" You are
> apparently interested in language features and language design issues that
> are at the heart of the Lisp language. So the perception you probably have
> of dismissive responses is not meant personally. And the serious
> recommendations to just check out lisp are offered because it solves very
> elegantly what issues you seem to be interested in.
Maybe I am not expressing myself clearly. When I say it is not
productive to tell me "go and study Lisp", I mean that I do not have the
time to dig into Lisp specifications to figure what about that language
that could help me in any way.
Last time that I studied and wrote a Lisp dialect I do not recall seeing
any support for meta-programming. Maybe you are calling meta-programming
to something else that is different than what is in my mind.
OTOH, it would be more productive if you or anybody else with interest
in clarifying how Lisp could help me, given the fact that I already have
a working meta-programming engine in place and running for over 5 years
to generate applications and components that are widely used by me and
many users.
--
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
Manuel Lemos <······@acm.org> wrote:
> OTOH, it would be more productive if you or anybody else with interest
> in clarifying how Lisp could help me, given the fact that I already
> have a working meta-programming engine in place and running for over 5
> years to generate applications and components that are widely used by
> me and many users.
I've tried to show you a simple example, but you wrote that you don't
understand it. So first I'll try to explain it and what are the adavantages
of Lisp meta-programming.
First the Loop construct in Lisp:
CL-USER > (dotimes (i 10) (princ 1))
1111111111
to explain it, the translation in Java:
for (int i = 0; i < 10; i++) System.out.print(i);
Now it would be nice to use meta-programming for general iteration, so that
you just can write (iterate 10 (princ 1)), instead of using the dotimes-
construct and a not used variable. For this reason you can use a macro:
(defmacro iterate (n &body body)
(let ((i (gensym)))
`(dotimes (,i ,n) ,@body)))
I'll explain it in detail, because there are some key features of Lisp
involved.
First a simple explanation how Lisp works. If you want to execute a
function, you write a list. The first argument is the function name and all
other arguments are arguments, which are evaluated before the function is
called (I use the ==> syntax to show the result of an expression):
(+ 1 2) ==> 3
(+ a b) ==> 3 , if a == 1 and b == 2
To create a list, use the "list" function:
(list a b) ==> (1 2)
If you don't want to evaluate an argument, you can quote it:
(list 'a 'b) ==> (a b)
Now a simple example to explain defmacro:
(defmacro foo (x) (list '+ x x))
You can call it like this:
(foo 1)
and it expands to (+ 1 1), which results in 2. The important code
generation aspect is, that the macro generates a list at compile time,
which in turn is expanded again, until all macros are expanded and then it
is compiled to the machine code. So a Lisp macro writes Lisp code.
You can simplify it with a backquote:
(defmacro foo (x) `(+ ,x ,x))
This quotes anything after the backquote, but evaluates everything after a
comma. ",@" is used to splice in a list.
The "let"-block is used to bind variables. For example
(let ((i 10)) (princ i))
could be translated to Java like this:
int i = 10;
System.out.print(i);
"gensym" creates a new symbol, so (let ((i (gensym))) binds a symbol name
to the variable "i". I used this in my iterate macro, because otherwise you
couldn't define "i" outside of iterate and use it in the body, because it
would be hided by the loop variable "i". With gensym the variable "i" gets
a new symbol name, which is generated in the list with ",i", which is
returned by the macro.
I think the main advantage: You use Lisp within a Lisp macro to generate
Lisp code. I don't know how your system handles this (this was one reason,
why I asked you to provide a translation of my simple example, to learn how
your system works), but I think it is cumbersome to implement the code
generation part in another language than the description to generate the
code.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hello,
on 12/18/2004 08:08 PM Frank Buss said the following:
> I think the main advantage: You use Lisp within a Lisp macro to generate
> Lisp code. I don't know how your system handles this (this was one reason,
> why I asked you to provide a translation of my simple example, to learn how
> your system works), but I think it is cumbersome to implement the code
> generation part in another language than the description to generate the
> code.
MetaL compiler flow module provides support for level 0 (macro
expansion) metaprogramming but IMO that is a very limited form of
metaprogramming.
Unless I misunderstood anything about LISP macros, it is not even unique
to LISP. C has support for macros via the preprocessor, C++ has template
classes and Java now has generics. There is no point in comparing the
capabilities of each language macro expansion capabilities because that
is not the topic here.
What is more interesting about the metaprogramming capabilities provided
by MetaL is not metaprogramming features of level 0 (macro expansion) or
even level 1 (generate code in other languages).
The real power comes from level 2 metaprogramming features and
eventually beyhond. Level 2 means that you write a code specification in
an high level syntax. That that specification is translated into MetaL
level 1/level 0 XML source code, which gets translated to the final
target language of choice. Currently PHP, Java, and Perl are supported
but it could be also LISP.
Currently the only level 2 module of MetaL compiler that was develop is
for generating persistence layers, i.e. classes that retrieve,
manipulate store objects that are kept in SQL databases or eventually
other persistence storage containers.
Personally I am using this persistence module to develop database
applications with much more productivity as such applications would take
much more time to write, test and debug if they were written by hand.
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. This is the
main goal of MetaL.
--
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
Manuel Lemos <······@acm.org> schrieb:
> MetaL compiler flow module provides support for level 0 (macro
> expansion) metaprogramming but IMO that is a very limited form of
> metaprogramming.
Not in Lisp. In Lisp, with macro expansion you can do arbitrary
source->source transformations, using the full power of Lisp to do so.
Which I think is what you mean by:
> The real power comes from level 2 metaprogramming features and
> eventually beyhond. Level 2 means that you write a code specification in
> an high level syntax. That that specification is translated into MetaL
> level 1/level 0 XML source code, which gets translated to the final
> target language of choice.
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.
> 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.
Something about this doesn't make sense to me, but it's hard to put my
finger on it. It just seems like, to whatever degree two languages are
different enough that you'd choose one over the other, it would be that
much harder (and pointless) to create one source file that generates
good libraries for both. Like if you use Java it's probably because you
want packages, Swing, the JVM, threads, or static typing, and if you use
PHP it's probably because you want dynamic typing, eval, builtin
bindings for every useful-for-web-apps C library in existence, and so
on, and by programming in MetaL you get neither.
There's opportunities for convergence but I personally think it's at the
level of the virtual machine, and even there you get impedance
mismatches -- there's complaints that all the .Net CLR-supported
languages are just superficial variations on C#, and you can bet we'll
never see a good Haskell->CLI compiler.
Hello,
on 01/05/2005 06:19 AM Adrian Kubala said the following:
> Manuel Lemos <······@acm.org> schrieb:
>>MetaL compiler flow module provides support for level 0 (macro
>>expansion) metaprogramming but IMO that is a very limited form of
>>metaprogramming.
>
> Not in Lisp. In Lisp, with macro expansion you can do arbitrary
> source->source transformations, using the full power of Lisp to do so.
> Which I think is what you mean by:
>
>>The real power comes from level 2 metaprogramming features and
>>eventually beyhond. Level 2 means that you write a code specification in
>>an high level syntax. That that specification is translated into MetaL
>>level 1/level 0 XML source code, which gets translated to the final
>>target language of choice.
>
> 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...?
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.
So, if Lisp macros are only useful for those that program in Lisp, they
are indeed a limited form of metaprogramming as I stated above.
>>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.
>
> Something about this doesn't make sense to me, but it's hard to put my
> finger on it. It just seems like, to whatever degree two languages are
> different enough that you'd choose one over the other, it would be that
> much harder (and pointless) to create one source file that generates
> good libraries for both. Like if you use Java it's probably because you
> want packages, Swing, the JVM, threads, or static typing, and if you use
> PHP it's probably because you want dynamic typing, eval, builtin
> bindings for every useful-for-web-apps C library in existence, and so
> on, and by programming in MetaL you get neither.
>
> There's opportunities for convergence but I personally think it's at the
> level of the virtual machine, and even there you get impedance
> mismatches -- there's complaints that all the .Net CLR-supported
> languages are just superficial variations on C#, and you can bet we'll
> never see a good Haskell->CLI compiler.
You seem to be making too many assumptions about the potential of MetaL
without really knowing it.
The MetaL engine is implemented by modules that generate code in a
target language that may indeed use certain libraries that may even
exist only for a specific language.
Most MetaL modules for specific purposes, say database access for
instamce, indeed generate code that calls existing libraries specific
for each language. If I need a module to work for a different language I
may have to develop adapter code that implements equivalent
functionality for the new language.
As you may understand by now, the portability is not immediately
guaranteed. Some work may need to be done to support a new language.
This is still a fraction of the work that I would have to do if I had to
rewrite my applications that depend specific purpose libraries.
For instance, Metastorage is a level 2 metaprogramming application for
generating classes that basically perform object relational mappings.
The part that generates level 1 code will not need to be touched to
support a new language.
--
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
Manuel Lemos <······@acm.org> schrieb:
> As you may understand by now, the portability is not immediately
> guaranteed. Some work may need to be done to support a new language.
> This is still a fraction of the work that I would have to do if I had
> to rewrite my applications that depend specific purpose libraries.
There are many other solutions besides rewriting your code. To name a
few: FFI, client-server architectures, bytecode compilation, and
language-to-language compilation. All of which are significantly more
general-purpose and probably about the same amount of work as
implementing the appropriate MetaL translation.
Hello,
on 01/12/2005 05:53 AM Adrian Kubala said the following:
>>As you may understand by now, the portability is not immediately
>>guaranteed. Some work may need to be done to support a new language.
>>This is still a fraction of the work that I would have to do if I had
>>to rewrite my applications that depend specific purpose libraries.
>
> There are many other solutions besides rewriting your code. To name a
> few: FFI, client-server architectures, bytecode compilation, and
> language-to-language compilation. All of which are significantly more
> general-purpose and probably about the same amount of work as
> implementing the appropriate MetaL translation.
Language-to-language translation is what MetaL engine does. The matter
is that when you use MetaL most of the translation effort is done
because the actual language bindings code is a small part of the MetaL
engine.
--
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
Manuel Lemos <······@acm.org> schrieb:
> Language-to-language translation is what MetaL engine does. The matter
> is that when you use MetaL most of the translation effort is done
> because the actual language bindings code is a small part of the MetaL
> engine.
I meant, taking an idiomatic PHP program and translating it into usable
Java. MetaL just does MetaL->language. And I think the matter is that
most of the translation effort is done because the programmer has
implemented their solution in a lowest-common-denominator form that's
easy to translate to a few fairly similar target languages.
Hello,
on 01/15/2005 03:53 PM Adrian Kubala said the following:
> Manuel Lemos <······@acm.org> schrieb:
>>Language-to-language translation is what MetaL engine does. The matter
>>is that when you use MetaL most of the translation effort is done
>>because the actual language bindings code is a small part of the MetaL
>>engine.
>
> I meant, taking an idiomatic PHP program and translating it into usable
> Java. MetaL just does MetaL->language. And I think the matter is that
> most of the translation effort is done because the programmer has
> implemented their solution in a lowest-common-denominator form that's
> easy to translate to a few fairly similar target languages.
No, I have already explained before that I implemented constructs that
are not available in all languages, like using variables without
explicitly declaring them first, or switch/case constructs with text
values which PHP supports but Java doesn't.
--
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
On Fri, 21 Jan 2005 03:23:37 -0200, Manuel Lemos wrote:
> No, I have already explained before that I implemented constructs that
> are not available in all languages, like using variables without
> explicitly declaring them first, or switch/case constructs with text
> values which PHP supports but Java doesn't.
Yes, those are *incredibly* advanced language features.
Really.
Learn Lisp if you want to see some language features that you haven't seen
before. *Then* come back and tell me you can do it all already using
MetaL.
Cheers,
Bill.
Manuel Lemos <······@acm.org> schrieb:
> on 01/15/2005 03:53 PM Adrian Kubala said the following:
>> [...] I think the matter is that most of the translation effort is
>> done because the programmer has implemented their solution in a
>> lowest-common-denominator form that's easy to translate to a few
>> fairly similar target languages.
>
> No, I have already explained before that I implemented constructs that
> are not available in all languages, like using variables without
> explicitly declaring them first, or switch/case constructs with text
> values which PHP supports but Java doesn't.
Those differences are pretty trivial. As I explained in another post,
some sets of language features are fundamentally irreconcilable. Let me
give a concrete example:
http://sixfingeredman.net/tmp/dbdate_reader.txt
The key feature of this code is that it uses PHP's ability to evaluate
code at runtime to compile a pattern into code to match and interpret
it. How would you do this in Java?
Here's another one:
http://sixfingeredman.net/tmp/functional.txt
Anonymous functions, runtime definition of functions -- impossible
(AFAIK) in the standard JRE. There's even some functions like metamap,
metafold, etc that start to look like simple Lisp macros.
You might feel this is not typical PHP, but I do this *all the time*,
and if I have to give these features up to use MetaL, then I think I may
as well program in Java directly. These examples could have been done
even better in Lisp (where these idioms and other even "stranger" ones
are much more common), but I wanted to hammer in the point that even
between closely-related languages there are irreconcilable differences
in features.
Hello,
on 01/21/2005 03:22 PM Adrian Kubala said the following:
>>>[...] I think the matter is that most of the translation effort is
>>>done because the programmer has implemented their solution in a
>>>lowest-common-denominator form that's easy to translate to a few
>>>fairly similar target languages.
>>No, I have already explained before that I implemented constructs that
>>are not available in all languages, like using variables without
>>explicitly declaring them first, or switch/case constructs with text
>>values which PHP supports but Java doesn't.
>
> Those differences are pretty trivial. As I explained in another post,
> some sets of language features are fundamentally irreconcilable. Let me
> give a concrete example:
> http://sixfingeredman.net/tmp/dbdate_reader.txt
>
> The key feature of this code is that it uses PHP's ability to evaluate
> code at runtime to compile a pattern into code to match and interpret
> it. How would you do this in Java?
>
> Here's another one:
> http://sixfingeredman.net/tmp/functional.txt
>
> Anonymous functions, runtime definition of functions -- impossible
> (AFAIK) in the standard JRE. There's even some functions like metamap,
> metafold, etc that start to look like simple Lisp macros.
>
> You might feel this is not typical PHP, but I do this *all the time*,
> and if I have to give these features up to use MetaL, then I think I may
> as well program in Java directly. These examples could have been done
> even better in Lisp (where these idioms and other even "stranger" ones
> are much more common), but I wanted to hammer in the point that even
> between closely-related languages there are irreconcilable differences
> in features.
You are still missing the point of MetaL. MetaL was designed for people
like me that do not want to get stuck with a specific language, which
seems to not be your case. In your case, MetaL would not be useful
because you insist on using PHP esoteric features and even believe that
your examples are necessarily a good thing.
I have written hundreds of thousands of lines of PHP code and I have
never used code that adds functions at run time, not because that is a
PHP specific feature, but it because IMO that is a bad practice.
What happens is that to use such features you necessarily need to have
an interpreter/compiler engine enabled at runtime.
That means that when you run such functions they will call the op code
compiler and will dynamically associate the generated code to the
function lookup table. This prevents the user of compiler caching
extensions as it is not worth to cache something that needs to be parsed
and compiled at run time.
Compiler cache extensions provide major speed boost to PHP scripts
because they avoid the need to recompile scripts on each execution, but
using such esoteric functions in PHP to add functions at run time cannot
benefit from cache extensions speedup, so the scripts that use such
feature will always be much slower than they could be.
Still, I am not a Java expert, but I suspect that you may need to review
your claim that you could not do in Java what you did in PHP after you
study these pages:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Compiler.html
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html
Even if we could reach the conclusion that we could not use such
language specific features in other languages, that should hint you that
what you want to use is probably not a good thing or something for which
the target language that miss other language features may not be suited
for the purposes you intend.
--
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
On Sun, 23 Jan 2005 19:57:25 -0200, Manuel Lemos wrote:
> Even if we could reach the conclusion that we could not use such
> language specific features in other languages, that should hint you that
> what you want to use is probably not a good thing...
I agree Manuel. Lisp is clearly very sick - it has *loads* of features
that other languages don't have! The designers of Lisp must have been
crazy. Don't they know that all languages should have roughly the same
set of features, so that we can build things like MetaL on top of them?
*sigh*
Cheers,
Bill.
Manuel Lemos wrote:
[...]
>>
>> 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.
>
> 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.
After two weeks of that i decided that the project would be better
written in lisp. and i have not touched php since. My postgres
autoloader now generates CLSQL view-classes.
>>> 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
would be very hard to generate good lisp code from your XML templates,
because they use idioms that a lisp programmer would not use.
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).
drewc
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
Manuel Lemos <······@acm.org> writes:
>
> 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.
>
I keep waiting for him to start telling us about the garbage
collection module he's been working on...
Gregm
Manuel Lemos <······@acm.org> writes:
> Hello,
>
> on 12/18/2004 08:08 PM Frank Buss said the following:
> > I think the main advantage: You use Lisp within a Lisp macro to
> > generate Lisp code. I don't know how your system handles this (this
> > was one reason, why I asked you to provide a translation of my
> > simple example, to learn how your system works), but I think it is
> > cumbersome to implement the code generation part in another language
> > than the description to generate the code.
>
> MetaL compiler flow module provides support for level 0 (macro
> expansion) metaprogramming but IMO that is a very limited form of
> metaprogramming.
>
> Unless I misunderstood anything about LISP macros, it is not even
> unique to LISP. C has support for macros via the preprocessor, C++ has
> template classes and Java now has generics. There is no point in
> comparing the capabilities of each language macro expansion
> capabilities because that is not the topic here.
You have indeed misunderstood basically _everything_ about what Lisp
macros are and what capabilities they provide. They do not operate on
text, but on the preparsed syntax trees derived from the textual
input. There is actually nothing in MetaL that you can't do with Lisp
macros, if for no other reason than you could implement MetaL _as_ a
Lisp macro(s).
> The real power comes from level 2 metaprogramming features and
> eventually beyhond. Level 2 means that you write a code specification
> in an high level syntax. That that specification is translated into
This sort of thing is done all the time with Lisp macros. In fact
that is probably their main use, i.e., defining and implementing
domain specific languages. These, of course, provide for very high
level syntax for the description of terms, problems, and solutions in
the language of the domain.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Hello,
on 01/05/2005 08:41 PM jayessay said the following:
>>>I think the main advantage: You use Lisp within a Lisp macro to
>>>generate Lisp code. I don't know how your system handles this (this
>>>was one reason, why I asked you to provide a translation of my
>>>simple example, to learn how your system works), but I think it is
>>>cumbersome to implement the code generation part in another language
>>>than the description to generate the code.
>>MetaL compiler flow module provides support for level 0 (macro
>>expansion) metaprogramming but IMO that is a very limited form of
>>metaprogramming.
>>
>>Unless I misunderstood anything about LISP macros, it is not even
>>unique to LISP. C has support for macros via the preprocessor, C++ has
>>template classes and Java now has generics. There is no point in
>>comparing the capabilities of each language macro expansion
>>capabilities because that is not the topic here.
>
> You have indeed misunderstood basically _everything_ about what Lisp
> macros are and what capabilities they provide. They do not operate on
> text, but on the preparsed syntax trees derived from the textual
> input. There is actually nothing in MetaL that you can't do with Lisp
> macros, if for no other reason than you could implement MetaL _as_ a
> Lisp macro(s).
If you read me again, you notice that I am saying that there is no point
in comparing the capabilities of each language macro capabilities as
that is not the topic.
I developed MetaL to generate PHP code mainly and then Java and then
Perl. Eventually it will generate other language if I or anybody else
sees any purpose of developing whatever it is necessary to make it happen.
Actually MetaL is even used to perform actions or generate files which
are not even source code of any programming language. For instance, the
persistence module generates database schema definitions in Metabase
schema format and UML diagrams in the AT&T GraphViz format.
Another example, the build module makes the MetaL engine act like a
makefile like build tool, that just manage compilation and other types
of actions but it does not generate any code itself.
I would be surprised if you can make a Lisp macro to perform these kinds
of actions, but since I admitedly do not know enough of Lisp, I am
always open to other approaches to make the things that I do with the
MetaL engine.
>>The real power comes from level 2 metaprogramming features and
>>eventually beyhond. Level 2 means that you write a code specification
>>in an high level syntax. That that specification is translated into
>
> This sort of thing is done all the time with Lisp macros. In fact
> that is probably their main use, i.e., defining and implementing
> domain specific languages. These, of course, provide for very high
> level syntax for the description of terms, problems, and solutions in
> the language of the domain.
Can you give me an example of an application of Lisp macros that
performs anything similar to Metastorage?
http://www.meta-language.net/metastorage.html
--
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
Manuel Lemos <······@acm.org> wrote:
> Actually MetaL is even used to perform actions or generate files which
> are not even source code of any programming language. For instance,
> the persistence module generates database schema definitions in
> Metabase schema format and UML diagrams in the AT&T GraphViz format.
[...]
> I would be surprised if you can make a Lisp macro to perform these
> kinds of actions, but since I admitedly do not know enough of Lisp, I
> am always open to other approaches to make the things that I do with
> the MetaL engine.
it is very easy to implement this in Lisp. For makefile, build and install
tool take a look at http://constantly.at/lisp/asdf/ .
Ok, now lets develop a schema generator. A Java project (I'm still not
confident enough in Lisp to write production Lisp code for customers)
switches from MySQL to PostgreSQL, so this is a nice lesson for me to
translate the hard-coded MySQL schema to a higher level description, from
which I can generate MySQL and PostgreSQL.
It is a simple application, I have ony a small set of types: autoincrement
primary keys, 32 bit ints, < 256 char strings and large strings. No foreign
keys or other special database features.
First I show you, how you can use my solution. I'm using strings to avoid
uppercase translation and because I don't need the table and column names
as symbols:
(define-table "user"
'(("id" key)
("token" text)
("email" string)
("firstName" string)
("lastName" string)
("accountBalance" int)))
another example:
(define-table "crossTable"
'(("id1" int)
("id2" int)))
and calling it like this:
(write-schema-file "mysql-schema")
(write-schema-file "postgres-schema")
generates these two files:
mysql-schema.txt:
------------------------------------
create table crossTable (
id1 int,
id2 int);
create table user (
id int auto_increment,
token mediumtext,
email varchar(255),
firstName varchar(255),
lastName varchar(255),
accountBalance int,
primary key (id));
------------------------------------
postgres-schema.txt:
------------------------------------
create table crossTable (
id1 int,
id2 int);
create table user (
id serial primary key,
token text,
email varchar(255),
firstName varchar(255),
lastName varchar(255),
accountBalance int);
------------------------------------
And now the implementation of the write-schema-file, define-table, helper
functions and declarations:
(defparameter *tables* ())
(defun define-table (name columns)
(push (list name columns) *tables*))
(defun schema (name columns types)
(format t "create table ~a (~%" name)
(let ((key-name)
(first t))
(dolist (column columns)
(destructuring-bind (name type) column
(let ((db-type (cdr (assoc type types))))
(when (eql type 'key) (setf key-name name))
(if first
(setf first nil)
(format t ",~%"))
(format t " ~a ~a" name db-type))))
key-name))
(defun mysql-schema (name columns)
(let* ((types '((int . "int")
(string . "varchar(255)")
(text . "mediumtext")
(key . "int auto_increment")))
(key-name (schema name columns types)))
(if key-name
(format t ",~% primary key (~a));~%" key-name)
(format t ");~%"))))
(defun postgres-schema (name columns)
(let* ((types '((int . "int")
(string . "varchar(255)")
(text . "text")
(key . "serial primary key"))))
(schema name columns types))
(format t ");~%"))
(defun write-schema-file (schema)
(let ((filename (concatenate 'string schema ".txt")))
(with-open-file (s filename :direction :output :if-exists :supersede)
(let ((*standard-output* s))
(dolist (table *tables*)
(destructuring-bind (name columns) table
(funcall (intern (string-upcase schema)) name columns)
(terpri)))))))
No (own) macro needed, but the use of higher order functions makes the code
easier to read and enhance. But of course, the code is not optimal, I'm
still thinking too much like a Java programmer, probably the code can be
halfed in size by a Lisp master :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hello,
on 01/12/2005 09:24 PM Frank Buss said the following:
>>Actually MetaL is even used to perform actions or generate files which
>>are not even source code of any programming language. For instance,
>>the persistence module generates database schema definitions in
>>Metabase schema format and UML diagrams in the AT&T GraphViz format.
>
> [...]
>
>>I would be surprised if you can make a Lisp macro to perform these
>>kinds of actions, but since I admitedly do not know enough of Lisp, I
>>am always open to other approaches to make the things that I do with
>>the MetaL engine.
>
> it is very easy to implement this in Lisp. For makefile, build and install
> tool take a look at http://constantly.at/lisp/asdf/ .
>
> Ok, now lets develop a schema generator. A Java project (I'm still not
> confident enough in Lisp to write production Lisp code for customers)
> switches from MySQL to PostgreSQL, so this is a nice lesson for me to
> translate the hard-coded MySQL schema to a higher level description, from
> which I can generate MySQL and PostgreSQL.
If I got you write, what you are telling me is what I suspected. The
Lisp compiler (or whatever compile time enviroment) does not generate
code in other languages, unlike MetaL. If you want to generate code in
other languages in Lisp, you need to write a Lisp program which only
generates code once it is run.
So, unlike MetaL, Lisp is not a dedicated code generation language (like
most traditional languages). This also means that in Lisp you can only
implement level 0 metaprogramming (macro expansion), and not
metaprogramming level 1, 2, etc..
So, if I really got you right, I am not say that this is a deficiency
Lisp, but rather just a clear fact that distinguish MetaL from Lisp.
Although I have tried to make it clear several times, often I felt that
the purpose of MetaL is misunderstood as people that are particularly
attached to some language tend to see in MetaL as a threat to their
favorite language.
MetaL did not come to replace any language. MetaL was developed to
simplify the software development process, like most code generation
tools, at the same time that it aims to be immune to trends of usage of
different languages over time.
--
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
Manuel Lemos <······@acm.org> writes:
> If I got you write, what you are telling me is what I suspected. The
> Lisp compiler (or whatever compile time enviroment) does not generate
> code in other languages, unlike MetaL. If you want to generate code in
> other languages in Lisp, you need to write a Lisp program which only
> generates code once it is run.
You must be at least as wise as Gandalf if you're able to have MetaL
generate code without running it.
> [...]
> Although I have tried to make it clear several times, often I felt
> that the purpose of MetaL is misunderstood as people that are
> particularly attached to some language tend to see in MetaL as a
> threat to their favorite language.
Indeed, if the source language for the MetaL translator was
Common-Lisp we would be much happier.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Hello,
on 01/14/2005 07:49 PM Pascal Bourguignon said the following:
>>If I got you write, what you are telling me is what I suspected. The
>>Lisp compiler (or whatever compile time enviroment) does not generate
>>code in other languages, unlike MetaL. If you want to generate code in
>>other languages in Lisp, you need to write a Lisp program which only
>>generates code once it is run.
>
> You must be at least as wise as Gandalf if you're able to have MetaL
> generate code without running it.
If you studied the MetaL engine, you would know that once you compile
source code in the MetaL language, what comes out of it is code a target
language of choice, and not an executable generator program that
produces code only when it is run.
--
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
Manuel Lemos wrote:
> Hello,
>
> on 01/14/2005 07:49 PM Pascal Bourguignon said the following:
>
>>> If I got you write, what you are telling me is what I suspected. The
>>> Lisp compiler (or whatever compile time enviroment) does not generate
>>> code in other languages, unlike MetaL. If you want to generate code in
>>> other languages in Lisp, you need to write a Lisp program which only
>>> generates code once it is run.
>>
>>
>> You must be at least as wise as Gandalf if you're able to have MetaL
>> generate code without running it.
>
>
> If you studied the MetaL engine, you would know that once you compile
> source code in the MetaL language, what comes out of it is code a target
> language of choice, and not an executable generator program that
> produces code only when it is run.
>
You are not making any sense at all. Your compiler (written in php
right?) has to run over the metal source at some point to produce the
output .. non? Or have you invented some quantum magic to avoid ever
having to run your compiler?
The same thing would happen if you wrote your compiler in lisp, only,
since lisp was designed to do the sort of thing you are using php+metal
to do, it would be a lot simpler. Your compiler would be compiled to
machine code, where your php is interpreted and slow.
Lisp users have been doing this sort of thing for 50 years, you might
want to start listening and stop pretending you invented the idea. you
may learn somthing.
drewc
Manuel Lemos <······@acm.org> wrote:
> If I got you write, what you are telling me is what I suspected. The
> Lisp compiler (or whatever compile time enviroment) does not generate
> code in other languages, unlike MetaL. If you want to generate code in
> other languages in Lisp, you need to write a Lisp program which only
> generates code once it is run.
Please explain me the difference:
MetaL:
test.metal:
<xml>
<something>....
</something>
</xml>
php-command-line MetaL-Generator.php test.metal > test.php
Lisp:
(defparameter *test*
'(something ... ))
(lisp-generator *test* "test.php")
> So, unlike MetaL, Lisp is not a dedicated code generation language
> (like most traditional languages).
you are right, it is more than just a code generation language.
> This also means that in Lisp you
> can only implement level 0 metaprogramming (macro expansion), and not
> metaprogramming level 1, 2, etc..
no, this is wrong. You can do everything in Lisp, what you can do with
your PHP modules and XML. Just show me an example in MetaL for level n
metaprogramming (a simple one, to concentrate on the concept, not the
details of database mapping etc.) and I'll show you how it would look
like in Common Lisp.
But I don't want to convince you to use Lisp. I think this is not
possible. If you have programmed in C/C++, like I, and only read about
Lisp, you may think it's not worth to try it, until you actually doing
some Lisp coding yourself :-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Manuel Lemos <······@acm.org> writes:
> Hello,
>
> on 01/05/2005 08:41 PM jayessay said the following:
> >>Unless I misunderstood anything about LISP macros, it is not even
> >>unique to LISP. C has support for macros via the preprocessor, C++ has
> >>template classes and Java now has generics. There is no point in
> >>comparing the capabilities of each language macro expansion
> >>capabilities because that is not the topic here.
> > You have indeed misunderstood basically _everything_ about what Lisp
> > macros are and what capabilities they provide. They do not operate on
> > text, but on the preparsed syntax trees derived from the textual
> > input. There is actually nothing in MetaL that you can't do with Lisp
> > macros, if for no other reason than you could implement MetaL _as_ a
> > Lisp macro(s).
>
> If you read me again, you notice that I am saying that there is no
> point in comparing the capabilities of each language macro
> capabilities as that is not the topic.
That's not what the above was about. As others have said as well, the
above should indicate to anyone even fairly familiar with generative
techniques, languages, and compiling that Lisp macros afford the
developer a direct means to operate on the semantic structures derived
from a given syntactic definition and an example input. Since they
have full access to any other function or macro, in Lisp or your own
code, they obviously can analyze these structures in any way as well
as transform them and generate any kind of output from them.
> Actually MetaL is even used to perform actions or generate files which
> are not even source code of any programming language. For instance,
> the persistence module generates database schema definitions in
> Metabase schema format and UML diagrams in the AT&T GraphViz format.
>
> Another example, the build module makes the MetaL engine act like a
> makefile like build tool, that just manage compilation and other types
> of actions but it does not generate any code itself.
>
> I would be surprised if you can make a Lisp macro to perform these
> kinds of actions, but since I admitedly do not know enough of Lisp, I
> am always open to other approaches to make the things that I do with
> the MetaL engine.
Then be surprised. There is nothing special about any of the above
for Lisp macros. Simply note that Lisp macros are just functions that
happen to be "special" in when and how they are called. They are
fully capable of any processing, including any kind of I/O.
> >>The real power comes from level 2 metaprogramming features and
> >>eventually beyhond. Level 2 means that you write a code specification
> >>in an high level syntax. That that specification is translated into
> > This sort of thing is done all the time with Lisp macros. In fact
> > that is probably their main use, i.e., defining and implementing
> > domain specific languages. These, of course, provide for very high
> > level syntax for the description of terms, problems, and solutions in
> > the language of the domain.
>
> Can you give me an example of an application of Lisp macros that
> performs anything similar to Metastorage?
>
> http://www.meta-language.net/metastorage.html
This doesn't look like anything more than the sort of stuff provided
by any of a number of Lisp db packages and/or persistent object
storage packages, where high level syntax (mini domain language) is
provided by macros which generate the appropriate calls for the given
db backend based on <type, implementation, version>.
Look, I don't think anyone is saying that your MetaL isn't useful in
at least some contexts (generating PHP and/or Java for certain scoped
domains). Since you appear to be making some $$ off of it, it's
clearly useful to you. The issue is that you seem to think it is
somehow new or unique in it's fundamental intent and/or ability from
what even a LISP of 40 years ago was already able to do via macros let
alone what Common Lisp of today can do. It's not. Indeed, it is
_significantly_ less.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Hello,
on 01/15/2005 12:15 AM jayessay said the following:
>>Actually MetaL is even used to perform actions or generate files which
>>are not even source code of any programming language. For instance,
>>the persistence module generates database schema definitions in
>>Metabase schema format and UML diagrams in the AT&T GraphViz format.
>>
>>Another example, the build module makes the MetaL engine act like a
>>makefile like build tool, that just manage compilation and other types
>>of actions but it does not generate any code itself.
>>
>>I would be surprised if you can make a Lisp macro to perform these
>>kinds of actions, but since I admitedly do not know enough of Lisp, I
>>am always open to other approaches to make the things that I do with
>>the MetaL engine.
>
> Then be surprised. There is nothing special about any of the above
> for Lisp macros. Simply note that Lisp macros are just functions that
> happen to be "special" in when and how they are called. They are
> fully capable of any processing, including any kind of I/O.
From what it was explained to me, what I understood is that you can
perform any actions right, but you have to write and compile the Lisp
source code that performs such actions but only when it is run.
Maybe I am not expressing myself clearly, but what I am trying to
explain is that with MetaL you do not have to write a generator program
to generate code in a target language. The MetaL engine (actually its
modules to be accurate) is the generator itself. So, the result of the
MetaL engine compilation is not a program to generate target code, but
rather the target code itself which may be in a language of choice, in
theory including Lisp.
>>>>The real power comes from level 2 metaprogramming features and
>>>>eventually beyhond. Level 2 means that you write a code specification
>>>>in an high level syntax. That that specification is translated into
>>>This sort of thing is done all the time with Lisp macros. In fact
>>>that is probably their main use, i.e., defining and implementing
>>>domain specific languages. These, of course, provide for very high
>>>level syntax for the description of terms, problems, and solutions in
>>>the language of the domain.
>>Can you give me an example of an application of Lisp macros that
>>performs anything similar to Metastorage?
>>
>>http://www.meta-language.net/metastorage.html
>
> This doesn't look like anything more than the sort of stuff provided
> by any of a number of Lisp db packages and/or persistent object
> storage packages, where high level syntax (mini domain language) is
> provided by macros which generate the appropriate calls for the given
> db backend based on <type, implementation, version>.
The detail is that is only useful if you are interested only in Lisp. If
you want to use Lisp to make it generate code in another language, you
need to make those macros expand to code that only generates code in
other language once it is compiled and run.
In case you wonder what is the difference in practice, what I can tell
you is probably best answered by the FAQ response, specifically the
first phrase of the second paragraph.
http://www.meta-language.net/metastorage-faq.html#good
In case I am still not being very clear, let me explain with a concrete
example. I am completely running out of time, so this may be may last
attempt to explain how MetaL works.
Metastorage basically works by calling the MetaL compiler engine that
first generates a model definition (level 2 meta-programing domain
specific language) into intermediate XML code that uses only level 1
meta-programming modules .
Although this is done in a single MetaL engine invocation, there is then
a second stage that processes the (XML) MetaL code generated by the
first stage and generates final code (not executable code) in a target
language of choice. It can do more things but lets forget that for now.
So, as you may see, what comes out of the MetaL engine is not reallya
program that generates code but rather final generated source code itself.
> Look, I don't think anyone is saying that your MetaL isn't useful in
> at least some contexts (generating PHP and/or Java for certain scoped
Actually I should have said that about Lisp. I did not come here to say
MetaL is better than Lisp because I believe we are talking of different
things that can hardly be compared.
I am not religious about any language. I developed MetaL because I
realized it would be a good thing to my future to become as unattached
to any language as much as possible. Still, I respect the preferences of
other developers because it is not my business to solve the problems
that they have to solve to do their work.
Just a reminder, that just I came here because a developer of this
newsgroups brought to my attention to this thread where pertinent
questions were being raised about the point of MetaL.
> domains). Since you appear to be making some $$ off of it, it's
Before anybody gets the wrong idea, I am not making money from MetaL itself.
Although it is solely my business, I do not have a problem to explain
that I make a living from a popular repository of classes of objects
written in PHP named PHPClasses.org . Since the site generates enough
income from the advertising placed in the site, I dedicate full time to
it, not really to MetaL.
The part where MetaL became relevant to that site is that I have
developed some components that I use as part of the site source code
using MetaL.
Now, for the users and for the advertisers of the site, it is totally
irrelevant the use of MetaL anywhere as it does not make me generate
more or less money for having used it.
At most, what I can say is that some components where generated by
Metastorage, which is a MetaL application, effectively were built in
less time than if I would have written, tested and debugged them by
hand. So, it did not increase the income, but it reduced my development
costs.
> clearly useful to you. The issue is that you seem to think it is
> somehow new or unique in it's fundamental intent and/or ability from
> what even a LISP of 40 years ago was already able to do via macros let
> alone what Common Lisp of today can do. It's not. Indeed, it is
> _significantly_ less.
I do not think MetaL was ever done to compete with Lisp or anything like
that as it was never meant to be an alternative language but rather a
more efficient and independent development method. I developed MetaL to
be free from any ties to any specific language.
I believe that MetaL can be used to improve the development process of
applications in any language, including Lisp, although I am not going to
try to convince any one here. So, MetaL should be seen as a tool that
may add value, not like a threat to any developer that has specific
language preferences.
--
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
Manuel Lemos <······@acm.org> writes:
<a lot of boring stuff that still shows an abysmal level of
understanding that this MetaL thing is neither new nor unique in
either ability or intent from what is easily done with Lisp domain
level code generators, and is in fact far less capable due to hard
coded limitations in its structure and semantics>
You are obviously closed to anything not consistent with your
preconceived world view and therefore currently hopeless and even
important: irrelevant.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Florian Weimer
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <87hdlv1pt1.fsf@deneb.enyo.de>
* Manuel Lemos:
> Unless I misunderstood anything about LISP macros, it is not even unique
> to LISP. C has support for macros via the preprocessor, C++ has template
> classes and Java now has generics.
The only thing that comes close to Lisp macros is C++ template
metaprogramming. However, template metaprogramming has the unwanted
property that it's radically different from the usual imperative
programming style, and there is virtually no debugging support (the
error messages from the compiler are abysmal, you can only test
template expansion by running the generated code).
Your other examples are mostly equivalent to text substitution and not
nearly as powerful. Java generics deliberately do not support partial
specialization in the way C++ does (and which opens the door to
template metaprogramming). The C preprocessor doesn't even provide
loops.
Manuel Lemos <······@acm.org> wrote:
> What is more interesting about the metaprogramming capabilities
> provided by MetaL is not metaprogramming features of level 0 (macro
> expansion) or even level 1 (generate code in other languages).
>
> The real power comes from level 2 metaprogramming features and
> eventually beyhond. Level 2 means that you write a code specification
> in an high level syntax. That that specification is translated into
> MetaL level 1/level 0 XML source code, which gets translated to the
> final target language of choice. Currently PHP, Java, and Perl are
> supported but it could be also LISP.
What you called level 2 metaprogramming is possible in Lisp, too. But as
far as I understand, you have to implement the expansion code in PHP for
your MetaL system. First a high-level description in XML, then
transforming it with a MetaL PHP module to a lower level XML description
and then transforming it again to Java or PHP with another MetaL PHP
module. This limits the things you can do or makes it too cumbersome. In
Lisp you use Lisp for transforming a macro to a lower level and the macro
code itself can use macros to help writing the macros easier, or you
could use the transformed macros for transforming other things (for
example you could implement the MetaL system with Lisp macros, which then
are used to translate XML to PHP, Lisp or Java).
Sometimes it might be necessary to use PHP or Java, for example if the
customer wants it, but your MetaL system shows, that PHP and Java are too
limited to use it without any external preprocessor, if you don't want to
write redundant code. This is ok, but in Lisp you write anything in Lisp;
you don't need to switch between different programming languages or
representations, and while writing your Lisp program, you enhance the
language itself to remove any redundant code.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hello,
on 01/08/2005 10:57 PM Frank Buss said the following:
>>What is more interesting about the metaprogramming capabilities
>>provided by MetaL is not metaprogramming features of level 0 (macro
>>expansion) or even level 1 (generate code in other languages).
>>
>>The real power comes from level 2 metaprogramming features and
>>eventually beyhond. Level 2 means that you write a code specification
>>in an high level syntax. That that specification is translated into
>>MetaL level 1/level 0 XML source code, which gets translated to the
>>final target language of choice. Currently PHP, Java, and Perl are
>>supported but it could be also LISP.
>
> What you called level 2 metaprogramming is possible in Lisp, too. But as
> far as I understand, you have to implement the expansion code in PHP for
No, the whole MetaL engine is written in PHP. So all modules are written
in PHP. If I would have written the MetaL engine in Lisp or other
language, it would only be natural that its modules would be all in that
language.
> your MetaL system. First a high-level description in XML, then
> transforming it with a MetaL PHP module to a lower level XML description
> and then transforming it again to Java or PHP with another MetaL PHP
> module. This limits the things you can do or makes it too cumbersome. In
I can understand that you find it cumbersome because you only want to
program in Lisp but it is all in PHP. If it was all in Lisp, would you
still find it cumbersome?
> Lisp you use Lisp for transforming a macro to a lower level and the macro
> code itself can use macros to help writing the macros easier, or you
> could use the transformed macros for transforming other things (for
> example you could implement the MetaL system with Lisp macros, which then
> are used to translate XML to PHP, Lisp or Java).
>
> Sometimes it might be necessary to use PHP or Java, for example if the
> customer wants it, but your MetaL system shows, that PHP and Java are too
> limited to use it without any external preprocessor, if you don't want to
> write redundant code. This is ok, but in Lisp you write anything in Lisp;
> you don't need to switch between different programming languages or
> representations, and while writing your Lisp program, you enhance the
> language itself to remove any redundant code.
I think I was not clear that developed MetaL not to generate code in any
specific language but rather to not ever be tied to any language.
The reason is actually simple. As time goes, old languages tend to go
out of fashion because new types of applications become more proeminent
and for those newer languages become more appropriate.
Now I develop in PHP but in the future I may never use it. I do not have
a crystal ball but I would not be surprised if you no longer program in
Lisp in the future too. That is just natural.
This may be different where you live but where I live and in many places
there is no market for Lisp programmers. It seems to be an old language
that has gone out of fashion. Some how this chart confirms that feeling:
http://www.tiobe.com/tiobe_index/tekst.htm
This does not mean that Lisp or any similar languages do not have their
merits. It just means that if most of your work is tied to Lisp, in the
future you may not have a way to reuse your code libraries in jobs that
are based on other languages.
For many people, their opinions on their favorite languages will
eventually become irrelevant as they do not get to decide which language
to use in their work because it is who ever that pays for it that
decides. If you work for yourself or you are who gets to decide what to
use in your work, that is great for you, but I understand that most
programmers are not that lucky.
This may seem a dramatic view of the future for people that are so
attached to their language of choice and that language is becoming more
irrelevant to the world over the time.
I realized that is a natural trend when the company Commodore went out
of business in 1994 and that marked the end of the Amiga computers era,
which is what I used then and was so attached. There are still some
believers of the Amiga computers until today, but its market is
basically gone for quite some time.
Then all my code libraries that I wrote in C for the Amiga OS became
irrelevant. I could hardly reuse anything that could be reused for other
platforms as they were so dependent on Amiga OS features, despite C is
still a very proeminent language.
In 1997 I started developing Web applications but doing them in C is a
royal pain. Then PHP appeared a a glue language of many useful C
libraries and since its syntax was very much like C, I sticked to it
until today.
However, the ghost of the Commodore Amiga fate made me wonder until wehn
I would stick to PHP. Since I was sure that would not last forever, in
1999 I started working on MetaL.
Is MetaL the perfect solution? Of course not. Would it be better if it
was written in Lisp? Probably not. Could MetaL be used to generate Lisp
code? Of course yes, when somebody write Lisp bindings. Would it be
useful to generate Lisp? Very likely yes, but until I or somebody else
needs to develop Lisp and write its bindings I will not be sure of how
useful it may be.
--
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
Manuel Lemos <······@acm.org> schrieb:
> The reason is actually simple. As time goes, old languages tend to go
> out of fashion because new types of applications become more
> proeminent and for those newer languages become more appropriate.
You're right -- some languages are more appropriate for some tasks than
others. The problem with MetaL is that it doesn't let you write programs
in the appropriate language, it only lets you write them in MetaL. If
you want the unique features that make a language worth using, then you
loose compatibility with other languages -- it's a fact of life.
If you've only used C, PHP, and Java it would make sense that you think
the only differences in languages are the available libraries. Try
Scheme, Haskell, Oz, Erlang, etc., and you'll see that language features
really do make a difference.
> Could MetaL be used to generate Lisp code?
Here's an idea -- instead of using the programmer to generate MetaL
which generates Lisp, have the programmer generate Lisp directly. It's
more fun too.
Hello,
on 01/12/2005 05:40 AM Adrian Kubala said the following:
> Manuel Lemos <······@acm.org> schrieb:
>>The reason is actually simple. As time goes, old languages tend to go
>>out of fashion because new types of applications become more
>>proeminent and for those newer languages become more appropriate.
>
> You're right -- some languages are more appropriate for some tasks than
> others. The problem with MetaL is that it doesn't let you write programs
> in the appropriate language, it only lets you write them in MetaL. If
> you want the unique features that make a language worth using, then you
> loose compatibility with other languages -- it's a fact of life.
No, you are misunderstanding how it works. You can use the MetaL engine
to generate code in virtually any target language. Then you can mix
MetaL generated code with handwritten code in the choosen target
language if that makes sense for what you are doing.
For instance, I developed Metastorage tool around MetaL persistence
module. I write an high level specification (metaprogramming level 2) of
my data model and it generates classes in my target language of choice
to implement an object-relational API so I can store my application
objects in an SQL database. Then I use handwritten code to call the
persistence API generated by the MetaL engine.
I could have written the whole application in MetaL but since that was
not my starting point I didn't. But as you may understand by now,
nothing stopped me from integrating MetaL generated code with
handwritten code.
Actually MetaL generated code looks very much like handwritten code,
except that this persistence module made me generate a significant bunch
of code in a fraction of time that I would have taken to write, test and
debug manually.
> If you've only used C, PHP, and Java it would make sense that you think
> the only differences in languages are the available libraries. Try
> Scheme, Haskell, Oz, Erlang, etc., and you'll see that language features
> really do make a difference.
Sure, but as long as you can do the same things with different
languages, any other features of those last languages that are not
directly supported by first languages can be emulated with higher level
MetaL commands if it makes sense to have them. As long as I use the
commands of MetaL language, there is no problem.
Let me give you an example. In Java, there is no support for string
arguments in switch/case constructs like there is in PHP. That did not
prevent me from implementing that in MetaL. The MetaL flow module
implements a switch/case construct that translates to appropriate code
in Java and in PHP that work in an equivalent way. Here you can see an
example:
http://www.meta-language.net/sample.html
Another more complex example is that fact that in PHP you do not need to
declare variables but in Java you do. No problem, in MetaL variable
types are declared implicitly by type coercion.
<set>
<variable>s</variable>
<string>value</string>
</set>
Implicitly the variable s is declared as of type string. Further
assignments of the variable to a different type result in a compile time
error.
As you may also see in the sample mentioned above, the resulting code
also includes the necessary explicit variable declarations in the
generated Java code, while in PHP there are no variable declarations.
As you may see by now, some situations with differences between the
languages may not be easy to solve but they were solved with a success
level to convince me that MetaL is not only a viable concept but is also
useful because over each metaprogramming level that the engine modules
implement I can reach higher levels of productivity with becoming stuck
with any target language.
>>Could MetaL be used to generate Lisp code?
>
> Here's an idea -- instead of using the programmer to generate MetaL
> which generates Lisp, have the programmer generate Lisp directly. It's
> more fun too.
Become stuck with Lisp or any other target language that may not be
suitable for the programming job that I have at hand is precisely what I
wanted to avoid.
--
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
Manuel Lemos <······@acm.org> schrieb:
> For instance, I developed Metastorage tool around MetaL persistence
> module. I write an high level specification (metaprogramming level 2)
> of my data model and it generates classes in my target language of
> choice to implement an object-relational API so I can store my
> application objects in an SQL database. Then I use handwritten code to
> call the persistence API generated by the MetaL engine.
This does sound useful, but what I'm challenging is the point of MetaL
targetting multiple languages. Once you've produced your hand-written
PHP code, having your object-relational mapping in Java is pointless.
>> If you've only used C, PHP, and Java it would make sense that you
>> think the only differences in languages are the available libraries.
>> Try Scheme, Haskell, Oz, Erlang, etc., and you'll see that language
>> features really do make a difference.
>
> Sure, but as long as you can do the same things with different
> languages, any other features of those last languages that are not
> directly supported by first languages can be emulated with higher
> level MetaL commands if it makes sense to have them. As long as I use
> the commands of MetaL language, there is no problem.
There is a problem, because it's not usually a matter of one feature
being higher-level than another. Features work together to achieve
synergy. For example, Lisp uses a simple syntax that makes macros
relatively powerful and easy to write, and Haskell doesn't. So you have
to choose a side -- pretty mathematical syntax with less powerful
macros, or relatively-ugly sexp syntax with powerful macros. Or Erlang,
for example, pretty much demands that you implement your program as a
interacting processes, while in most other languages the thread overhead
makes this the wrong approach. C gives you pointers but sacrifices
safety. On a smaller level, the character of the implementation will be
different -- a Scheme program would make heavy use of higher-order- and
anonymous functions, while a PHP program wouldn't. Even if you manage to
target both of them, on one side or the other the code will feel awkward
because it's non-idiomatic.
>> Here's an idea -- instead of using the programmer to generate MetaL
>> which generates Lisp, have the programmer generate Lisp directly.
>> It's more fun too.
>
> Become stuck with Lisp or any other target language that may not be
> suitable for the programming job that I have at hand is precisely what
> I wanted to avoid.
Aha, here's the crux: your target language isn't nearly as important as
your SOURCE language. I mean, look at the most popular languages --
Java, C, C++; they each have basically one target, but people use them
because... well heck if I know. But the point is, if I can write a
solution faster and better in Lisp than in MetaL, nobody cares that I
can automatically turn my crappy MetaL solution into a dozen other
languages.
Adrian Kubala wrote:
>- pretty mathematical syntax
> with less powerful macros, or relatively-ugly sexp syntax with
powerful macros. Or
Pretty, eh? Huh, one of the main reasons I don't like haskell is
because of the ugly complicated syntax. I waste a hell of a lot of time
puzzling out silly issues of syntax when reading other people's
idiomatic haskell code. The vaguely interesting theoretical meat of the
language just seems to have been buried under, well, a whole heap o'
crud [1][2]. Sure, it might all correspond to someone else's notion of
pretty, but not mine.
[1] http://www.cs.uu.nl/~afie/haskell/tourofsyntax.html
[2] http://www.haskell.org/onlinereport/syntax-iso.html
Hello,
on 01/15/2005 04:18 PM Adrian Kubala said the following:
> Manuel Lemos <······@acm.org> schrieb:
>>For instance, I developed Metastorage tool around MetaL persistence
>>module. I write an high level specification (metaprogramming level 2)
>>of my data model and it generates classes in my target language of
>>choice to implement an object-relational API so I can store my
>>application objects in an SQL database. Then I use handwritten code to
>>call the persistence API generated by the MetaL engine.
>
> This does sound useful, but what I'm challenging is the point of MetaL
> targetting multiple languages. Once you've produced your hand-written
> PHP code, having your object-relational mapping in Java is pointless.
Using hand written code is an option, not a requirement. In my I case I
just have chosen that way, because I needed to integrate with an
application that was already hand written totally in PHP.
>>>If you've only used C, PHP, and Java it would make sense that you
>>>think the only differences in languages are the available libraries.
>>>Try Scheme, Haskell, Oz, Erlang, etc., and you'll see that language
>>>features really do make a difference.
>>Sure, but as long as you can do the same things with different
>>languages, any other features of those last languages that are not
>>directly supported by first languages can be emulated with higher
>>level MetaL commands if it makes sense to have them. As long as I use
>>the commands of MetaL language, there is no problem.
>
> There is a problem, because it's not usually a matter of one feature
> being higher-level than another. Features work together to achieve
Right, that is one of the strong points of using MetaL. You can add more
modules or more commands to existing modules that implement new
constructs that integrate existing code that uses previously existing
commands.
>>>Here's an idea -- instead of using the programmer to generate MetaL
>>>which generates Lisp, have the programmer generate Lisp directly.
>>>It's more fun too.
>>Become stuck with Lisp or any other target language that may not be
>>suitable for the programming job that I have at hand is precisely what
>>I wanted to avoid.
>
> Aha, here's the crux: your target language isn't nearly as important as
> your SOURCE language. I mean, look at the most popular languages --
> Java, C, C++; they each have basically one target, but people use them
> because... well heck if I know. But the point is, if I can write a
> solution faster and better in Lisp than in MetaL, nobody cares that I
> can automatically turn my crappy MetaL solution into a dozen other
> languages.
I care. I developed MetaL for myself. It effectively reduces my
development costs, especially usinl level 2 metaprogramming modules like
the persistence module used by Metastorage. If it becomes useful
directly or indirectly to others fine, but that was not my main goal.
The reality is that many developers are benefiting from MetaL, many of
them without knowing because I used MetaL to develop work that I shared
with many tens of thousands of users that are working with my MetaL
generated code.
You see, my point was never to impose my language is better than yours.
I did not develop MetaL to satisfy my ego. The way I see it, I use MetaL
for purposes that I find better than using it than with other languages.
Now, if you or anybody else agrees with my reasoning, that is another
question.
--
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
Manuel Lemos <······@acm.org> writes:
> on 01/12/2005 05:40 AM Adrian Kubala said the following:
> > If you've only used C, PHP, and Java it would make sense that you
> > think the only differences in languages are the available
> > libraries. Try Scheme, Haskell, Oz, Erlang, etc., and you'll see
> > that language features really do make a difference.
>
> Sure, but as long as you can do the same things with different
> languages, any other features of those last languages that are not
> directly supported by first languages can be emulated with higher
> level MetaL commands if it makes sense to have them. As long as I
> use the commands of MetaL language, there is no problem.
If I may butt in, I believe you have missed Mr. Kubala's point.
Languages that support functional programming, such as Scheme,
Haskell, Common Lisp, etc., include capabilities that do not translate
at all directly to the capabilities of C, PHP, and Java. For example,
please demonstrate how you would provide higher order functions (see
http://c2.com/cgi/wiki?HigherOrderFunction if you are unfamiliar with the
term) in MetaL. Lexical closures (see the same site) would be a
challenge as well, I imagine.
> > > Could MetaL be used to generate Lisp code?
> > Here's an idea -- instead of using the programmer to generate
> > MetaL which generates Lisp, have the programmer generate Lisp
> > directly. It's more fun too.
>
> Become stuck with Lisp or any other target language that may not be
> suitable for the programming job that I have at hand is precisely
> what I wanted to avoid.
The point that you seem to be missing is that when you use Lisp
you aren't stuck. Lisp provides all of the benefits you are claiming
for MetaL. You would really benefit from learning Lisp, even if you
chose or find it necessary to use other languages in the future.
Regards,
Patrick May
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Patrick May <···@spe.com> schrieb:
> Manuel Lemos <······@acm.org> writes:
>> Sure, but as long as you can do the same things with different
>> languages, any other features of those last languages that are not
>> directly supported by first languages can be emulated with higher
>> level MetaL commands if it makes sense to have them. As long as I
>> use the commands of MetaL language, there is no problem.
>
> [...] For example, please demonstrate how you would provide higher
> order functions (see http://c2.com/cgi/wiki?HigherOrderFunction if you
> are unfamiliar with the term) in MetaL. Lexical closures (see the
> same site) would be a challenge as well, I imagine.
Actually, these two things would not be hard technically to provide in
Java or PHP -- you use objects with one method, called in C++ (wrongly
IMHO) "functors" or "function objects". I imagine the static analysis
necessary to do this transparently and pervasively would be pretty
challenging though. More to the point, targetting both a functional and
procedural language with the same code, on one side or the other you'll
end up with highly awkward, non-idiomatic interfaces.
Adrian Kubala <······@sixfingeredman.net> writes:
> Patrick May <···@spe.com> schrieb:
> > [...] For example, please demonstrate how you would provide higher
> > order functions (see http://c2.com/cgi/wiki?HigherOrderFunction if
> > you are unfamiliar with the term) in MetaL. Lexical closures (see
> > the same site) would be a challenge as well, I imagine.
>
> Actually, these two things would not be hard technically to provide
> in Java or PHP -- you use objects with one method, called in C++
> (wrongly IMHO) "functors" or "function objects". I imagine the
> static analysis necessary to do this transparently and pervasively
> would be pretty challenging though. More to the point, targetting
> both a functional and procedural language with the same code, on one
> side or the other you'll end up with highly awkward, non-idiomatic
> interfaces.
I agree. What I, rather too tersely, was asking was how MetaL
would allow generation of both Lisp and Java, for example, from the
same input. Not only would the code be non-idiomatic, at best, but I
suspect that supporting functions as first class objects that can be
created dynamically would be quite challenging.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Well reading some here, there is a kind of problem.
It is write, MetaL can produce/understand/simulate code written in any
other language, assuming, MetaL has a modul parat. So fare ok. Now, as
you know, every other language has a hand full of special tricks, to
make things work. This would than also be possible, using MetaL. This
sounds like you are saying, PHP is able to do all that. And this can't
be right, because PHP/MetaL than is the smallest key, passing every
keyhole that exist and this is not taken place. In fact, PHP programmers
can tell you many limits inside the PHP, so they go on developing. Or do
you want to say MetaL/PHP is for other languages what ASM is for a '86
processor? Why does than someone use Forth or here Lisp or for speed ASM
direct?
Comparing the problem to natural languages and translations procedures
it turns out that Amyra(? as I have the name in my head-memory) is such
a key-language, the word-origins can easyly translate into any known
language on this planet. Amira is spoken as a dialekt near the
Titicacasea from a small group, ~2000 people and it is said this is an
very old language. In praxis the language translating procedure
translate first into Amira and from there to the wished language,
keeping the originaly sense intact. But, as I read, translate-internals
use neural-net technix to optimize the procedure and therefor the
way-to-do will change over time to something unknown.
For MetaL this can be a tornaround, if I don't misunderstod somthig
basicly andif Manuel Lemos invest more time and knowhow, but as I then
can say, you will be afraid about Lisp...
stefan
Manuel Lemos wrote:
> I think I was not clear that developed MetaL not to generate code in any
> specific language but rather to not ever be tied to any language.
But MetaL is a language, so I am tied to it. You somehow have created a
language which is Above All Languages? We thought that was Lisp, so you
might be preaching to the wrong audience.
>
> The reason is actually simple. As time goes, old languages tend to go
> out of fashion because new types of applications become more proeminent
> and for those newer languages become more appropriate.
>
> Now I develop in PHP but in the future I may never use it. I do not have
> a crystal ball but I would not be surprised if you no longer program in
> Lisp in the future too. That is just natural.
That is a terribly simplistic and naiive argument. It presumes all
languages are equal. COBOL went out of favor, so MetaL will go out of
favor. No!, you protest. MetaL is different. That is what Lispniks say,
too. Welcome to the club.
>
> This may be different where you live but where I live and in many places
> there is no market for Lisp programmers. It seems to be an old language
> that has gone out of fashion.
Yes, Lisp is dead. More and more people are discovering it every day, so
it is damn near impossible to get a good night's sleep in the morgue any
more.
And believe me you, to the extent Lisp is dead, it is because it is
nothing like the languages Java and C. MetaL won't have that problem, of
course. (Ha!)
> For many people, their opinions on their favorite languages will
> eventually become irrelevant as they do not get to decide which language
> to use in their work because it is who ever that pays for it that
> decides. If you work for yourself or you are who gets to decide what to
> use in your work, that is great for you, but I understand that most
> programmers are not that lucky.
You are confused. You want to be a visionary leading us into the future,
but you make job listings the criterion. There are no job listings for
your favorite language, so you might want to get a grip and stop
insulting everyone by saying we are idiots clinging to dead languages.
Your language is stillborn (sorry, but as long as we are calling a spade
a spade, there you go.)
> Is MetaL the perfect solution? Of course not. Would it be better if it
> was written in Lisp? Probably not.
Cute. Would it it be too bothersome to support that conclusion?
Incredibly good developers have been evolving CL for forty years. You
are one unsubstantiated bozo working for how long? Take a hike.
> ...until I or somebody else
> needs to develop Lisp and write its bindings I will not be sure of how
> useful it may be.
<sob> You have probably done some neat work on MetaL. It almost
certainly cannot possibly approach the work done by vastly more/better
programmers on Lisp. Stare at your navel and ask yourself if you really
think you can have achieved a better language than Lisp developers over
forty years. No, you will conclude. But MetaL is /portable/ to any
number of crappy languages. (a) big deal (aa) so is Lisp (b) why not
just use Lisp?
KT
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Manuel Lemos <······@acm.org> wrote:
>> your MetaL system. First a high-level description in XML, then
>> transforming it with a MetaL PHP module to a lower level XML
>> description and then transforming it again to Java or PHP with
>> another MetaL PHP module. This limits the things you can do or makes
>> it too cumbersome. In
>
> I can understand that you find it cumbersome because you only want to
> program in Lisp but it is all in PHP. If it was all in Lisp, would you
> still find it cumbersome?
no, it is not all in PHP. The MetaL description files are in XML, as far
as I understand MetaL, and the transformer is written in PHP. In Lisp all
is written in Lisp, the input data, the transformer and the output. And
if you want, or you can write a Lisp transformer, which produces lower
level output, like PHP.
> I think I was not clear that developed MetaL not to generate code in
> any specific language but rather to not ever be tied to any language.
I admit, this is a nice feature of MetaL. You write a general, language
independent description of you database and some PHP modules can
transform it to PHP. If you need to transform it to other languages, you
need to change the transform modules, only, not hundreds of database
descriptions. Ok, Lisp has invented this idea 40 years ago, but really a
nice idea.
> The reason is actually simple. As time goes, old languages tend to go
> out of fashion because new types of applications become more
> proeminent and for those newer languages become more appropriate.
you are right, PHP is far more popular than Lisp and for easy tasks, like
website counters or small guest books, it is a nice tool, but Lisp is
still popular for good programmers. I'm programming in PHP, Java, C++ and
some long time ago in Assembler on 6502 and 68000 (yes, Amiga), and I've
tested Haskell and Python a bit, but I think Lisp is the most advanced
language, with which you can implement a given task the best way: Faster
coding time than in other languages, less redundant code, interactive
testing and developing, better re-usability, shorter code and more
readable.
Take a look at some success stories:
http://www.franz.com/success/
But I don't want to compare the languages. There might be reasons, why
you have to use PHP, perhaps the customer don't want a Lisp
implementation, because there are much more PHP programmers out there,
who can maintain a PHP program or you have to maintain a PHP program, or
you want to develop a new web-board, which must run on every cheap web-
host and you have to use PHP, because they don't want to install Lisp on
it.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hello,
on 01/12/2005 05:16 PM Frank Buss said the following:
>>>your MetaL system. First a high-level description in XML, then
>>>transforming it with a MetaL PHP module to a lower level XML
>>>description and then transforming it again to Java or PHP with
>>>another MetaL PHP module. This limits the things you can do or makes
>>>it too cumbersome. In
>>I can understand that you find it cumbersome because you only want to
>>program in Lisp but it is all in PHP. If it was all in Lisp, would you
>>still find it cumbersome?
>
> no, it is not all in PHP. The MetaL description files are in XML, as far
> as I understand MetaL, and the transformer is written in PHP. In Lisp all
> is written in Lisp, the input data, the transformer and the output. And
> if you want, or you can write a Lisp transformer, which produces lower
> level output, like PHP.
I have developed a MetaL transformer in PHP that generates PHP and other
languages from the same MetaL code. To support other languages not yet
supported I need to add bindings code is is a very small part of the engine.
If I got Lisp right, if you want to do the same in Lisp you need to
write a new transformer program to support each language because unlike
MetaL, Lisp was not thought explicitly to generate code in many
different language, although you can do it in Lisp with a greater
development effort.
>>I think I was not clear that developed MetaL not to generate code in
>>any specific language but rather to not ever be tied to any language.
>
> I admit, this is a nice feature of MetaL. You write a general, language
> independent description of you database and some PHP modules can
> transform it to PHP. If you need to transform it to other languages, you
> need to change the transform modules, only, not hundreds of database
> descriptions. Ok, Lisp has invented this idea 40 years ago, but really a
> nice idea.
Ok, I think I am making progress in try to express myself regarding the
point of MetaL
>>The reason is actually simple. As time goes, old languages tend to go
>>out of fashion because new types of applications become more
>>proeminent and for those newer languages become more appropriate.
>
> you are right, PHP is far more popular than Lisp and for easy tasks, like
> website counters or small guest books, it is a nice tool, but Lisp is
You forgot the irony smiley because you made it sound the PHP is only
popular because it is good for easy tasks like website counters and
small guest books, as if anybody else using PHP for other non-easy tasks
should not use PHP and maybe use Lisp.
I don't mean to advocate for PHP but you made it sound for instance that
the decision of Yahoo (and many other well known companies) to develop
all their new sites in PHP is wrong because their sites are not to
perform just those easy tasks that you mentioned! ;-)
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
> still popular for good programmers. I'm programming in PHP, Java, C++ and
> some long time ago in Assembler on 6502 and 68000 (yes, Amiga), and I've
> tested Haskell and Python a bit, but I think Lisp is the most advanced
> language, with which you can implement a given task the best way: Faster
> coding time than in other languages, less redundant code, interactive
> testing and developing, better re-usability, shorter code and more
> readable.
Favourite languages are like faces, each one has their own.
> Take a look at some success stories:
>
> http://www.franz.com/success/
It is not in question whether you can or you cannot develop great
applications in List.
My point is that when you do not get to decide which language you need
to use to do your job, often you need to use another language that
somebody else decided that is more appropriate.
Even if you disagree or simply not simpathize with the idea of using a
different language than your favorite, sometimes you have to put up with
it, especially when it is your job that is at stake.
> But I don't want to compare the languages. There might be reasons, why
> you have to use PHP, perhaps the customer don't want a Lisp
> implementation, because there are much more PHP programmers out there,
> who can maintain a PHP program or you have to maintain a PHP program, or
> you want to develop a new web-board, which must run on every cheap web-
> host and you have to use PHP, because they don't want to install Lisp on
> it.
In my case, I get to decide what I use. Since I only develop my own Web
sites from which I generate my income, IMO PHP is now the adequate
language for the type of sites that I develop. I know there is mod_lisp
for Apache, but last time that I looked it did not seem to be as mature
for Web development like PHP.
Other than that, since most of my sites were not fully developed with
MetaL, the cost of switching to another language would be unbearable.
--
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
Manuel Lemos <······@acm.org> wrote:
> I have developed a MetaL transformer in PHP that generates PHP and
> other languages from the same MetaL code. To support other languages
> not yet supported I need to add bindings code is is a very small part
> of the engine.
>
> If I got Lisp right, if you want to do the same in Lisp you need to
> write a new transformer program to support each language because
> unlike MetaL, Lisp was not thought explicitly to generate code in many
> different language, although you can do it in Lisp with a greater
> development effort.
no, you are wrong, it is easier in Lisp.
For the other readers I'll explain, how it is implemented in MetaL. First
you have the XML-file built.input, which defines all available bindings.
The important part of this file looks like this:
<target>
<name>PHP</name>
<dependency>all</dependency>
<argument>
<name>targetlanguage</name>
<value>PHP</value>
</argument>
<argument>
<name>bindings</name>
<value>include/php.bindings</value>
</argument>
</target>
<target>
<name>Java</name>
<dependency>all</dependency>
<argument>
<name>targetlanguage</name>
<value>Java</value>
</argument>
<argument>
<name>bindings</name>
<value>include/java.bindings</value>
</argument>
</target>
something from java.bindings:
<class>
<source>expressions</source>
<target>metal_expressions_class</target>
<languagebindings>java_expressions_class</languagebindings>
<file>
<path>metal_base.php</path>
<symbol>METAL_BASE_INCLUDED</symbol>
</file>
<file>
<path>metal_expressions.php</path>
<symbol>METAL_EXPRESSIONS_INCLUDED</symbol>
</file>
<file>
<path>language_base_bindings.php</path>
<symbol>METAL_LANGUAGE_BASE_BINDINGS_INCLUDED</symbol>
</file>
<file>
<path>java_expressions.php</path>
<symbol>METAL_JAVA_EXPRESSIONS_BINDINGS_INCLUDED</symbol>
</file>
</class>
and something from java_expressions.php:
class java_expressions_class extends metal_language_bindings_class
{
Function Execute(&$compiler,&$context,&$class,$function,&$message)
{
switch($function)
{
case "length":
$context->result[]=array(
"Data"=>array(
"Value"=>$message["string"].".length()",
"Type"=>"INTEGER",
"Side"=>"RIGHT"
),
"Type"=>"EXPRESSION"
);
break;
}
return(1);
}
};
}
The same from php_expressions.php:
class php_expressions_class extends metal_language_bindings_class
{
Function Execute(&$compiler,&$context,&$class,$function,&$message)
{
switch($function)
{
case "length":
$context->result[]=array(
"Data"=>array(
"Value"=>"strlen(".$message["string"].")",
"Type"=>"INTEGER",
"Side"=>"RIGHT"
),
"Type"=>"EXPRESSION"
);
break;
}
return(1);
}
};
To implement a new language binding, you have to provide a new
*_expressions file and register it in another XML-file, but you don't have
to touch the general engine, very flexible. But still too complicated and
redundant.
Let's see how it could be implemented in Lisp.
I want to do something like this:
(defparameter *input*
'((function "helloWorld"
(def-var "test" "Hello World!")
(data "test"))
(function "helloUniverse"
(def-var "test" "Hello Universe!")
(data "test"))))
And when I call it like this:
(compile-input *input* :target-language 'php)
I want this output:
function helloWorld() {
$test = "Hello World!";
echo test;
}
function helloUniverse() {
$test = "Hello Universe!";
echo test;
}
And for Java:
(compile-input *input* :target-language 'java)
public void helloWorld() {
String test = "Hello World!";
System.out.println(test);
}
public void helloUniverse() {
String test = "Hello Universe!";
System.out.println(test);
}
The implementation is easy and I don't need any macros. The code is 60
lines, including the engine. In MetaL the description for one function in
both languages, without the engine, is over 90 lines. And with the use of
macros it could be made even less redundant.
It is not as complex as MetaL, which knows expressions and different
variable types, but it can be enhanced to implement the full features of
MetaL, while still being only a fraction of the size of your code.
But note, while my example is better, shorter etc. compared to MetaL, this
is not very Lisp-like, because usually you don't invent a language, which
has nearly the same syntax as Java or PHP and generates text output, but
you invent a language with macros in Lisp, which operates on the syntax
tree, or function, higher order functions, classes etc., which solves your
current problem.
(defparameter *bindings* (make-hash-table))
(defun define-binding (name binding)
(setf (gethash name *bindings*) binding))
(defun get-binding (name)
(gethash name *bindings*))
(defun php-function (binding arguments)
(destructuring-bind (name &rest commands) arguments
(format t "function ~A() {~%" name)
(dolist (command commands)
(compile-command binding command))
(format t "}~%" name)
(terpri)))
(defun php-def-var (binding arguments)
(declare (ignore binding))
(destructuring-bind (name value) arguments
(format t " $~A = ~S;~%" name value)))
(defun php-data (binding arguments)
(declare (ignore binding))
(format t " echo ~A;~%" (car arguments)))
(defun java-function (binding arguments)
(destructuring-bind (name &rest commands) arguments
(format t "public void ~A() {~%" name)
(dolist (command commands)
(compile-command binding command))
(format t "}~%" name)
(terpri)))
(defun java-def-var (binding arguments)
(declare (ignore binding))
(destructuring-bind (name value) arguments
(format t " String ~A = ~S;~%" name value)))
(defun java-data (binding arguments)
(declare (ignore binding))
(format t " System.out.println(~A);~%" (car arguments)))
(define-binding 'php
'((function #'php-function)
(def-var #'php-def-var)
(data #'php-data)))
(define-binding 'java
'((function #'java-function)
(def-var #'java-def-var)
(data #'java-data)))
(defun compile-command (binding command)
(destructuring-bind (command-name &rest arguments) command
(funcall (cadadr (assoc command-name binding)) binding arguments)))
(defun compile-input (input &key target-language)
(let ((binding (get-binding target-language)))
(dolist (command input)
(compile-command binding command))))
> I don't mean to advocate for PHP but you made it sound for instance
> that the decision of Yahoo (and many other well known companies) to
> develop all their new sites in PHP is wrong because their sites are
> not to perform just those easy tasks that you mentioned! ;-)
>
> http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
as I understand the article, they were planning to use PHP. At the time of
the article, their system looks like this:
� Site
� 74 properties
� mail, shopping, sports, news, games, pets, etc.
� 25 int�l sites
� 13 languages
� Code
� 8.1M lines of C/C++
� 3.0M lines of Perl
� 612 developers
but after trying it one year, looks like they have problems with
performance and application/presentation mixing:
http://www.php-con.com/2003/west/pdf/michael_radwin_archive.pdf
In contrast, Common Lisp is designed to produce fast compiled native code
and can be as fast as C/C++. And there are some nice HTML template engines.
PS: Yahoo Store was written in Lisp:
http://www.paulgraham.com/avg.html
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> no, you are wrong, it is easier in Lisp.
Wow, I kicked this thread off over a month ago, and it still seems to
have legs. I must admit that I lost interest in the discussion ages ago,
but couldn't resist mentioning an article in Slashdot that was posted
yesterday:
gManZboy writes "Programming writer and instructor Greg Wilson is
proposing that the next generation of programming languages will use XML
to store not only such things as formatting (so you can see indentation
your way, and I can see it my way, via XSLT) but even programmatic
entities -- like: <invoke-expr
method="myMethod"><evaluate>record</evaluate></invoke-expr>. Wacky, but
perhaps wacky enough to be possible?"
Link:
http://developers.slashdot.org/article.pl?sid=05/01/18/2157249
Up spake Mark Carter:
> http://developers.slashdot.org/article.pl?sid=05/01/18/2157249
See also <··············@javamonkey.com>.
--
-trent
For Sale: 15GB iPod, lightly used, 167 songs loaded. The RIAA says it's
worth about twenty-five million. I'll let it go for five, plus shipping.
Hello,
on 01/15/2005 01:19 AM Frank Buss said the following:
>>I have developed a MetaL transformer in PHP that generates PHP and
>>other languages from the same MetaL code. To support other languages
>>not yet supported I need to add bindings code is is a very small part
>>of the engine.
>>
>>If I got Lisp right, if you want to do the same in Lisp you need to
>>write a new transformer program to support each language because
>>unlike MetaL, Lisp was not thought explicitly to generate code in many
>>different language, although you can do it in Lisp with a greater
>>development effort.
>
> no, you are wrong, it is easier in Lisp.
>
> For the other readers I'll explain, how it is implemented in MetaL. First
Thank you for the effort of actually trying to understand how it works
internally. At least now you have a better knowlegde of the MetaL engine
so you can comment with first hand knowlegde and not with assumptions.
> you have the XML-file built.input, which defines all available bindings.
> The important part of this file looks like this:
Correction, this is the source of the equivalent to a makefile. As you
know makefiles are used to manage the build process calling the compiler
only if any targets need to be rebuilt.
If you wanted to compare MetaL version of and hello world script, you
looked at the wrong files.
> To implement a new language binding, you have to provide a new
> *_expressions file and register it in another XML-file, but you don't have
> to touch the general engine, very flexible. But still too complicated and
> redundant.
Your last phrase would only be true if you wanted to generate an hello
world script. In the perspective, the development of any compiler just
to generate hello world script would be too complicated and redundant
but as you noticed MetaL can be used to generate code that is actually
more complicated than the MetaL engine itself.
> Let's see how it could be implemented in Lisp.
>
> I want to do something like this:
>
> (defparameter *input*
> '((function "helloWorld"
> (def-var "test" "Hello World!")
> (data "test"))
> (function "helloUniverse"
> (def-var "test" "Hello Universe!")
> (data "test"))))
>
> And when I call it like this:
>
> (compile-input *input* :target-language 'php)
>
> I want this output:
>
> function helloWorld() {
> $test = "Hello World!";
> echo test;
> }
>
> function helloUniverse() {
> $test = "Hello Universe!";
> echo test;
> }
>
>
> And for Java:
>
> (compile-input *input* :target-language 'java)
>
> public void helloWorld() {
> String test = "Hello World!";
> System.out.println(test);
> }
>
> public void helloUniverse() {
> String test = "Hello Universe!";
> System.out.println(test);
> }
This is an excellent example to demonstrate the weakness of your
approach, which is a the weakness of all hand made generators meant just
specific tasks, like writing an hello world script in this case. Let me
explain with some source from the test directory of the standard MetaL
distribution.
The output of the simple helloworld script in MetaL is like this:
<output>
<script>
<string>Hello World! </string>
</script>
</output>
Once compiled to generate Java it comes like this:
public final class helloworld
{
public static void main(String[] args)
{
System.out.print("Hello World!\n");
}
}
In PHP:
<?php
echo "Hello World!\n";
?>
In Perl:
#!/usr/local/bin/perl
print("Hello World!\n");
The problem of your approach is that, although it generates source code
files, what comes out of it may be syntatically wrong and not work at
all because it does not embed sufficient knowlegde about generating code
in different target languages. It just (thinks) it knows how to generate
code that outputs hello world.
For instance, your Java example simply would not work because everything
in Java is a class, even your program main entry point must be a class.
That is not like that in other language but MetaL has a module that
knows that.
That module is the one that implements the command triggered in the
MetaL source code above with the tag <script>. That command knows how to
bundle the code defined with its tag and generate an adequate source
code file in the target language that can be run as a program entry point.
Sure, you can improve your example macros make them more aware of the
details of generating code in different target languages. That means
adding more code to handle all the details that may or may not be
different between all the target languages that you may support.
That is my point about hand written generators meant for specific
purposes. As you evolve your generator to deal with all the language
specific details and support more language features, you end of with
much more complex macros or whatever code you use in Lisp to provide
similar power to what MetaL engine modules provide today, which
basically demonstrates that you have a oversimplified view of how to
generate code in different target languages in your following statements.
> The implementation is easy and I don't need any macros. The code is 60
> lines, including the engine. In MetaL the description for one function in
> both languages, without the engine, is over 90 lines. And with the use of
> macros it could be made even less redundant.
>
> It is not as complex as MetaL, which knows expressions and different
> variable types, but it can be enhanced to implement the full features of
> MetaL, while still being only a fraction of the size of your code.
> But note, while my example is better, shorter etc. compared to MetaL, this
> is not very Lisp-like, because usually you don't invent a language, which
> has nearly the same syntax as Java or PHP and generates text output, but
> you invent a language with macros in Lisp, which operates on the syntax
> tree, or function, higher order functions, classes etc., which solves your
> current problem.
You still miss the point that in MetaL I can add any modules that
implement such Lisp-like features if I or anybody else sees any point to
it . The question is, would there be any good reasons to implement such
Lisp-like features? Maybe yes, maybe know.
The way I see it, what matters about software development is what your
programs can do within a given set of requirements. As long as the
requirements are properly fullfilled, the discussion of the means should
be left for theory students.
>>I don't mean to advocate for PHP but you made it sound for instance
>>that the decision of Yahoo (and many other well known companies) to
>>develop all their new sites in PHP is wrong because their sites are
>>not to perform just those easy tasks that you mentioned! ;-)
>>
>>http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
>
> as I understand the article, they were planning to use PHP. At the time of
Is it my impression or you really do not believe they are using PHP more
and more?
FYI, 2002 was the year of introduction of PHP as standard for new sites
. They hired Rasmus Lerdorf, the inventor of PHP, and I am sure that was
not for any other thing than helping them developing better PHP
applications.
Anyway, what I meant just mentioning Yahoo is to present an example of
Internet company that knows what they are doing. Their business is not
PHP. They used PHP because they thought about it and reached the
conclusion that it was good to improve their site development process.
I could have mentioned the millions of sites that use PHP but that was
not my point. The point is that you seem to underestimate the software
development knowledge of people just because they use PHP.
Have it crossed your mind that they may be using PHP because they have
studied the subject of developing Web applications and who gets to
decided reached the conclusion that PHP is the best language for their
purposes and that may not be necessarily for the same reasons why you
would choose the same or other languages for the same purposes?
> the article, their system looks like this:
>
> • Site
> – 74 properties
>
> • mail, shopping, sports, news, games, pets, etc.
> – 25 int’l sites
> – 13 languages
>
> • Code
> – 8.1M lines of C/C++
> – 3.0M lines of Perl
> – 612 developers
Maybe you have not got it right, but what I understood is that they
would be using PHP for new sites. That should not be understood as if
they would be migrating existing sites to PHP. I think that would be
stupid as you should not change the team that is working.
> but after trying it one year, looks like they have problems with
> performance and application/presentation mixing:
>
> http://www.php-con.com/2003/west/pdf/michael_radwin_archive.pdf
You should understand that as a presentation about the challenges that
they faced and how they did solve them.
> In contrast, Common Lisp is designed to produce fast compiled native code
> and can be as fast as C/C++. And there are some nice HTML template engines.
I don't think you know PHP. PHP is mostly a glue language. When you call
PHP functions, you are mostly running code of the C libraries that it
links to. PHP has over 2000 functions spread by tens of extensions
written mostly in C.
Sure, it is going to be very inneficient if you write code to execute
CPU consuming tasks without resorting to any dedicated extensions for
the purpose.
However, Web applications are mostly serving HTML pages, which are
basically made of text. Outputting text is a simple task.
Even if you need to go through a time consuming process to generate the
HTML text of your pages, like for instance accessing databases, you can
use smart techniques like using caching methods and avoid most of the
overhead of regenerating the same text to present to different users.
Still, if here and there you need to squeeze as much performance as you
can from each PHP script, be aware that AFAIK there is at least one PHP
to executable compiler named Roadsend and several bytecode optimizer and
caching extensions.
http://www.roadsend.com/
> PS: Yahoo Store was written in Lisp:
>
> http://www.paulgraham.com/avg.html
This just confirms what I said above regarding that who gets to decide
reached the conclusion that Lisp would be a good choice for that purpose.
--
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
On Fri, 21 Jan 2005 02:43:41 -0200, Manuel Lemos wrote:
>
> The way I see it, what matters about software development is what your
> programs can do within a given set of requirements. As long as the
> requirements are properly fullfilled, the discussion of the means should
> be left for theory students.
>
This is only true if you intend to implement the system, take all the
praise and cash, and then wonder off onto the next project without so much
as a thought for the poor bastards who have to pick up where you left off.
"It does what the requirements say it should do" is only the beginning.
Cheers,
Bill.
From: Rahul Jain
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <87pszw2gfk.fsf@nyct.net>
William Bland <·······@abstractnonsense.com> writes:
> "It does what the requirements say it should do" is only the beginning.
No, "The requirements are wrong" is only the beginning. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sun, 23 Jan 2005 12:39:27 -0500, Rahul Jain wrote:
> William Bland <·······@abstractnonsense.com> writes:
>
>> "It does what the requirements say it should do" is only the beginning.
>
> No, "The requirements are wrong" is only the beginning. :)
ROTFL!
So true :-)
Cheers,
Bill.
Manuel Lemos <······@acm.org> schrieb:
> I don't mean to advocate for PHP but you made it sound for instance that
> the decision of Yahoo (and many other well known companies) to develop
> all their new sites in PHP is wrong because their sites are not to
> perform just those easy tasks that you mentioned! ;-)
These decisions are made for political and business reasons: it's easier
to find programmers who will do PHP than Lisp. I've been a professional
PHP programmer for the last 5 years and I can promise, the only
technical advantages of PHP are its ease-of-use for writing SIMPLE
web-based apps (which is not the case for Yahoo), its C-like syntax
(which is not really an advantage), and its huge number of bindings to
handy C libraries (which is not terribly important if your language has
a good FFI). Its disadvantages are numerous -- no packages or
namespaces, no concept of servlets, crappy GC (it can't collect circular
references), no syntactical abstraction (even C has token-level macros),
and before PHP5 no exceptions and really wacky call-by-reference
semantics. Why, in a few more years PHP might finally be as usable as
Python!
> My point is that when you do not get to decide which language you need
> to use to do your job, often you need to use another language that
> somebody else decided that is more appropriate.
And that somebody would not like it if you give them: 1. MetaL source,
or 2. MetaL-generated source that nobody else can modify because that
would break your ability to update it from your MetaL source.
Hello,
on 01/15/2005 04:35 PM Adrian Kubala said the following:
>>I don't mean to advocate for PHP but you made it sound for instance that
>>the decision of Yahoo (and many other well known companies) to develop
>>all their new sites in PHP is wrong because their sites are not to
>>perform just those easy tasks that you mentioned! ;-)
>
> These decisions are made for political and business reasons: it's easier
> to find programmers who will do PHP than Lisp. I've been a professional
That is not a reason but rather a consequence. PHP 1.0 was released
first in 1994. Then there were certainly more Lisp developers than PHP
developers. Why it became easier to find PHP developers than Lisp?
Other people may have other views, but the way I see it is that PHP is
focused on Web application development which is a thing that became more
and more relevant to software developers.
I could go on and discuss why PHP continues to be even more popular
every day, but as I mentioned, I am not here to advocate PHP, not even
MetaL.
What I say is that maybe if you look closer you will probably find
perfectly reasonable motives for choosing PHP without ending up
underestimating the intelligence of people that did not choose Lisp.
> PHP programmer for the last 5 years and I can promise, the only
> technical advantages of PHP are its ease-of-use for writing SIMPLE
> web-based apps (which is not the case for Yahoo), its C-like syntax
> (which is not really an advantage), and its huge number of bindings to
> handy C libraries (which is not terribly important if your language has
> a good FFI). Its disadvantages are numerous -- no packages or
> namespaces, no concept of servlets, crappy GC (it can't collect circular
> references), no syntactical abstraction (even C has token-level macros),
> and before PHP5 no exceptions and really wacky call-by-reference
> semantics. Why, in a few more years PHP might finally be as usable as
> Python!
If you stopped and realized how many killer applications and sites have
been written in PHP, maybe you could understand how all those academic
arguments may become irrelevant in the real world on which people have
chosen PHP to develop such applications and site.
>>My point is that when you do not get to decide which language you need
>>to use to do your job, often you need to use another language that
>>somebody else decided that is more appropriate.
>
> And that somebody would not like it if you give them: 1. MetaL source,
> or 2. MetaL-generated source that nobody else can modify because that
> would break your ability to update it from your MetaL source.
That is not what the world thinks about what I have developed using
MetaL. As a matter of fact that most of the users of my MetaL generated
code do not even know what MetaL is and the code that they got from me
was originally written in MetaL. It is irrelevant for them. The
functionality that is provided is more relevant than the way I wrote the
code originally.
--
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
On Fri, 21 Jan 2005 03:33:43 -0200, Manuel Lemos wrote:
> That is not what the world thinks about what I have developed using
> MetaL. As a matter of fact that most of the users of my MetaL generated
> code do not even know what MetaL is and the code that they got from me
> was originally written in MetaL. It is irrelevant for them. The
> functionality that is provided is more relevant than the way I wrote the
> code originally.
You might be interested to read
http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
The conclusion (which I heartily agree with) seems to be that code
generation is a bad thing unless you treat the output as simply an
intermediate stage that will not be edited by human hands, but will
simply be passed on to the compiler/interpreter of whatever language you
are targeting.
So what happens when people start trying to tweak the code you gave them?
Or are you assuming the "I am the library designer and you are mere users"
stance? That doesn't usually work very well in my experience.
Cheers,
Bill.
William Bland <·······@abstractnonsense.com> writes:
> On Fri, 21 Jan 2005 03:33:43 -0200, Manuel Lemos wrote:
>
> > That is not what the world thinks about what I have developed using
> > MetaL. As a matter of fact that most of the users of my MetaL generated
> > code do not even know what MetaL is and the code that they got from me
> > was originally written in MetaL. It is irrelevant for them. The
> > functionality that is provided is more relevant than the way I wrote the
> > code originally.
>
> You might be interested to read
>
> http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
>
> The conclusion (which I heartily agree with) seems to be that code
> generation is a bad thing unless you treat the output as simply an
> intermediate stage that will not be edited by human hands, but will
> simply be passed on to the compiler/interpreter of whatever language you
> are targeting.
>
> So what happens when people start trying to tweak the code you gave them?
> Or are you assuming the "I am the library designer and you are mere users"
> stance? That doesn't usually work very well in my experience.
And would be categorically dismissed in any large-scale development
environment I've been part of. Its leads to an unmaintainable
situation. Either MetaL as the development environment will have to
be abandoned in favor of the code it generated at some point, or for
the life-cycle of the project one part of the bigger system will use
this highly idiosyncratic "precompiler" that no-one really
understands. When life-cycle is a few months or the project is small,
then who cares- but when its 5 or 10 years and involves 10s or
hundreds of people, the issue is really important.
Its bad enough when systems mix ADA and C, this would end up causing a
nightmare in the long run. You can see the potential for the same
sort of scenario with the super-duper "Software Engineering"
development environments.
Gregm
Hello,
on 01/21/2005 03:48 AM William Bland said the following:
>>That is not what the world thinks about what I have developed using
>>MetaL. As a matter of fact that most of the users of my MetaL generated
>>code do not even know what MetaL is and the code that they got from me
>>was originally written in MetaL. It is irrelevant for them. The
>>functionality that is provided is more relevant than the way I wrote the
>>code originally.
>
> You might be interested to read
>
> http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
>
> The conclusion (which I heartily agree with) seems to be that code
> generation is a bad thing unless you treat the output as simply an
> intermediate stage that will not be edited by human hands, but will
> simply be passed on to the compiler/interpreter of whatever language you
> are targeting.
>
> So what happens when people start trying to tweak the code you gave them?
> Or are you assuming the "I am the library designer and you are mere users"
> stance? That doesn't usually work very well in my experience.
I believe that most people that actively oppose to code generation is
just due to FUD. Basically they just expose the fear that soon or later
the code generators will replace them as developers and fight any
manifests about the advantages of using code generation methods like the
ultimate threat to their survival as software developers.
This is basically the same fear of people that worked in factories at
least that since the beginning of the industrial revolution have
complained against factory owners that buy machine to replace human job
positions in order to become more productive and often more reliable.
There is no reason for this kind of threat if you are open minded and
willing to adapt. Today you write code by hand, but if you prepare
yourself to the eventuality of the use of code generator machines in the
future, you will most likely find yourself a new job as a code generator
machine operator. You will get less tired, produce more, your employer
will be happier and you will eventually earn more because intellectual
jobs usually pay more than arm jobs.
As for the design smell, if you have used a code generator and run into
problems due to limitations of the generated code that made you need to
change it where it was originally not intended to be changed, that is
just a sign that the generator needs work to address your needs.
That is the reason why I released MetaL as Open Source. Actually I only
released it as Open Source one I started developing Metastorage. I use
it for my own needs but once it started being used by others, they
provided feedback regarding any bugs and limitations. That has been
helping MetaL and its applications to be improved.
This Metastorage FAQ answers better specifically your question regarding
when users start changing the generated code:
http://www.meta-language.net/metastorage-faq.html#good
--
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
Manuel Lemos schrieb:
Hi.
> I believe that most people that actively oppose to code generation is
> just due to FUD. Basically they just expose the fear that soon or later
> the code generators will replace them as developers and fight any
> manifests about the advantages of using code generation methods like the
> ultimate threat to their survival as software developers.
And a few years later no one can do handwritten code, because all use
the fabulous code-generator, at least some stupid scripts.
> As for the design smell, if you have used a code generator and run into
> problems due to limitations of the generated code that made you need to
> change it where it was originally not intended to be changed, that is
> just a sign that the generator needs work to address your needs.
But therefor one will use an other code-generator to generate the
missing expansions-pack. All human programmer were not able to write
code, better than the generated code.
> That is the reason why I released MetaL as Open Source. Actually I only
> released it as Open Source one I started developing Metastorage. I use
> it for my own needs but once it started being used by others, they
> provided feedback regarding any bugs and limitations. That has been
> helping MetaL and its applications to be improved.
Manuel Lemos. You are surely a very busy person and not a
code-generator-seller to the lisp-people. Believe me, first you have to
shredder all kind of boxes, before a lispner stops doing his favor. And
as you know, there is always something to do...
stefan
Manuel Lemos <······@acm.org> writes:
> Last time that I studied and wrote a Lisp dialect I do not recall
> seeing any support for meta-programming. Maybe you are calling
When was that last time?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: David Golden
Subject: Amiga Installer "Lisp" (was Re: Python gets macros - now XML does too)
Date:
Message-ID: <M_mxd.44230$Z14.20743@news.indigo.ie>
Paolo Amoroso wrote:
> Manuel Lemos <······@acm.org> writes:
>
>> Last time that I studied and wrote a Lisp dialect I do not recall
>> seeing any support for meta-programming. Maybe you are calling
>
> When was that last time?
>
>
He might mean Amiga Installer scripting (~ early 1990s) as he previously
mentioned, in which case he'd be right, near enough - metaprogramming
support was minimal in that...
Installer "lisp" was a sexp-syntax language alright, but not exactly an
amazing example of lisp. It was a little interpreted language with
lots of domain-specific functions that handled walking users through
installing amiga applications. Kindof like lisp plus defsystem plus
gui-wizard-builder minus lisp. Seriously, scanning the docs now, I
don't think it even had QUOTE, DEFMACRO would have been light-years
away.
Manuel, if you're basing your opinion of Lisp on Amiga Installer "Lisp",
you're way, way off (apart from the syntax)!
For the terminally curious, you can get a flavour of it from the
examples in the InstallerNG.lha [1] archive on the rather moribund
Aminet (lha decompression is in debian nonfree somewhere).
Note if you're reading the documentation, it's in a pre-HTML hypertext
markup format called "AmigaGuide", tag syntax @{blah}
[1] ftp://de.aminet.net/pub/aminet/util/sys/InstallerNG.lha
From: Manuel Lemos
Subject: Re: Amiga Installer "Lisp" (was Re: Python gets macros - now XML does too)
Date:
Message-ID: <340iclF45vnvmU2@individual.net>
Hello,
on 12/19/2004 08:09 PM David Golden said the following:
>>>Last time that I studied and wrote a Lisp dialect I do not recall
>>>seeing any support for meta-programming. Maybe you are calling
>>When was that last time?
>>
>>
>
> He might mean Amiga Installer scripting (~ early 1990s) as he previously
> mentioned, in which case he'd be right, near enough - metaprogramming
> support was minimal in that...
>
> Installer "lisp" was a sexp-syntax language alright, but not exactly an
> amazing example of lisp. It was a little interpreted language with
> lots of domain-specific functions that handled walking users through
> installing amiga applications. Kindof like lisp plus defsystem plus
> gui-wizard-builder minus lisp. Seriously, scanning the docs now, I
> don't think it even had QUOTE, DEFMACRO would have been light-years
> away.
Right.
> Manuel, if you're basing your opinion of Lisp on Amiga Installer "Lisp",
> you're way, way off (apart from the syntax)!
I do not have nothing against or for LISP. I just said that I did not
recall any metaprogramming features of LISP when I tried it.
--
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
Manuel Lemos <······@acm.org> writes:
> Last time that I studied and wrote a Lisp dialect I do not recall
> seeing any support for meta-programming. Maybe you are calling
> meta-programming to something else that is different than what is in
> my mind.
That doesn't sound like a LISP at all. Or maybe you just didn't
understand it - if it had macros, it had meta-programming support.
> OTOH, it would be more productive if you or anybody else with interest
> in clarifying how Lisp could help me, given the fact that I already
> have a working meta-programming engine in place and running for over 5
> years to generate applications and components that are widely used by
> me and many users.
Part of the issue, I believe, is that Lisp has had supreme support for
meta-programming for more than 40 years, with world wide use in
thousands of applications. So it is always sad in a way when you find
someone trying to reinvent a part of it badly. And even worse when
they don't understand this even after it has been pointed out.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Manuel Lemos <······@acm.org> writes:
> I just came here because Frank Buss notified me of a message posted
> here raising some concerns about MetaL. I am not interested in
> language competitions. Everybody has preferences and I respect
> that. So, if this is going to turn into an unproductive language flame
> war, please excuse me for not going to take part of that.
No, I don't think that was the intention.
A suggestion: read a decent book on Lisp, like P Graham's "ANSI Common
Lisp", or a few chapters in Norvigs "Paradigms in Artificial
Intelligence Programming". You will not regret it.
Mario S. Mommer wrote:
> Manuel Lemos <······@acm.org> writes:
>
>>I just came here because Frank Buss notified me of a message posted
>>here raising some concerns about MetaL. I am not interested in
>>language competitions. Everybody has preferences and I respect
>>that. So, if this is going to turn into an unproductive language flame
>>war, please excuse me for not going to take part of that.
>
> No, I don't think that was the intention.
>
> A suggestion: read a decent book on Lisp, like P Graham's "ANSI Common
> Lisp", or a few chapters in Norvigs "Paradigms in Artificial
> Intelligence Programming". You will not regret it.
...seconded. Even if you decide to stick with PHP+MetaL, you will learn
lots of things that are probably valuable for your work.
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
"Manuel Lemos" <······@acm.org> wrote in message
····················@individual.net...
> Hello,
>
> Right, I agree that XML requires typing redundant text. I even have
> suggested the W3C consortium to simplify the requirements, for instance
> allowing the end tag be just </> and the example above would look simpler:
(no offense intended to Manuel Lemos but sarcasm follows!)
Hey, and actually we could even get rid of the closing '>' char in the start
tag and..hmm and then we could reduce '</>' to '>'. Now let's see... '<'
and '>' are common operator symbols too...wait a minute! Let's use '(' and
')' instead ..now we are on to something! So simple, yet so versatile...
Wonder if that has ever been done before!?
>
> <case>
> <value>34</>
> <do>
> <set>
> <variable>character</>
> <string>&quot;</>
> </>
> <break />
> </>
> </>
(case foo
(34 (setf character #\")))
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
Hello,
Coby Beck wrote:
>><case>
>> <value>34</>
>> <do>
>> <set>
>> <variable>character</>
>> <string>&quot;</>
>> </>
>> <break />
>> </>
>></>
>
> (case foo
> (34 (setf character #\")))
The problem of your simplification is that you loose the ability to
determine which module of the compiler will implement each command.
Consider just this part:
<set>
<variable>character</variable>
<string>&quot;</string>
</set>
The engine will traverse the XML document and when it finds the <set>
tag it figures that it should be implemented by the set function of the
expressions module. That function traverses the tags inside anf finds
the <variable> and <string> tags. Then it tells the engine to call the
respective module that implements that, and so on if there are any
nested tags.
Since you have omitted the actual tags that were meant to identify each
compiler module should implement each command, you are forced to make a
contextual interpretation of the result of the Lisp parser. The way I
see it, that adds too much complexity to engine and eventually
compromises the ability extend the engine with modules that may process
the source differently.
--
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
Manuel Lemos wrote:
> [ <set>
> <variable>character</variable>
> <string>&quot;</string>
> </set>
> vs.
> (setf character #\")
> ]
>
> The engine will traverse the XML document and when it finds the
> <set> tag it figures that it should be implemented by the set
> function of the expressions module. That function traverses the
> tags inside anf finds the <variable> and <string> tags. Then it
> tells the engine to call the respective module that implements
> that, and so on if there are any nested tags.
>
> Since you have omitted the actual tags that were meant to
> identify each compiler module should implement each command, you
> are forced to make a contextual interpretation of the result of
> the Lisp parser.
In how far aren't you "mak[ing] a contextual interpretation" in the
evaluation process as you just described? Doesn't it, simplificated,
boil down to a case analysis on different kinds of expressions?
Probably on behalf of predicates like "Is this a variable?", "Is
this a string?" and so on, I can't see a difference to Lisp with
respect to that.
--tcr
Hello,
Tobias C. Rittweiler wrote:
> Manuel Lemos wrote:
>
>>[ <set>
>> <variable>character</variable>
>> <string>&quot;</string>
>> </set>
>> vs.
>> (setf character #\")
>>]
>>
>>The engine will traverse the XML document and when it finds the
>><set> tag it figures that it should be implemented by the set
>>function of the expressions module. That function traverses the
>>tags inside anf finds the <variable> and <string> tags. Then it
>>tells the engine to call the respective module that implements
>>that, and so on if there are any nested tags.
>>
>>Since you have omitted the actual tags that were meant to
>>identify each compiler module should implement each command, you
>>are forced to make a contextual interpretation of the result of
>>the Lisp parser.
>
> In how far aren't you "mak[ing] a contextual interpretation" in the
> evaluation process as you just described? Doesn't it, simplificated,
> boil down to a case analysis on different kinds of expressions?
> Probably on behalf of predicates like "Is this a variable?", "Is
> this a string?" and so on, I can't see a difference to Lisp with
> respect to that.
As I mentioned each of those three tags are evaluated separatly. The
<set> command triggers the evaluation of <variable> and <string> . They
return a stream that defines an expression each.
<variable> returns a LEFT/RIGHT hand side expression that can be of ANY
type. The <string> returns an RIGHT hand side expression of type STRING.
Then <set> looks at the return expressions and after figuring that they
are compatible, it outputs a stream that is just made of a command
statement assigning the LEFT hand side expression to the RIGHT hand side.
As you may understand by now, the <set> command does not have to
understand the syntax of its operands nor how they were formed. All it
needs to know is their types and if they can be used on the LEFT and
RIGHT hand sides respectively. If this condition is not satisfied, it
returns a compiler error.
Nothing in the processing method requires that the parser makes a
contextual interpretation of the expressions as that only happens at the
code generation time.
--
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
Manuel Lemos wrote:
> Hello,
>
> Tobias C. Rittweiler wrote:
> > Manuel Lemos wrote:
> >
> >>[ <set>
> >> <variable>character</variable>
> >> <string>&quot;</string>
> >> </set>
> >> vs.
> >> (setf character #\")
> >>]
> >>
> >>The engine will traverse the XML document and when it finds the
> >><set> tag it figures that it should be implemented by the set
> >>function of the expressions module. That function traverses the
> >>tags inside anf finds the <variable> and <string> tags. Then it
> >>tells the engine to call the respective module that implements
> >>that, and so on if there are any nested tags.
> >>
> >>Since you have omitted the actual tags that were meant to
> >>identify each compiler module should implement each command, you
> >>are forced to make a contextual interpretation of the result of
> >>the Lisp parser.
> >
> > In how far aren't you "mak[ing] a contextual interpretation" in the
> > evaluation process as you just described? Doesn't it,
simplificated,
> > boil down to a case analysis on different kinds of expressions?
> > Probably on behalf of predicates like "Is this a variable?", "Is
> > this a string?" and so on, I can't see a difference to Lisp with
> > respect to that.
>
> As I mentioned each of those three tags are evaluated separatly. The
> <set> command triggers the evaluation of <variable> and <string> .
They
> return a stream that defines an expression each.
>
> <variable> returns a LEFT/RIGHT hand side expression that can be of
ANY
> type. The <string> returns an RIGHT hand side expression of type
STRING.
>
> Then <set> looks at the return expressions and after figuring that
they
> are compatible, it outputs a stream that is just made of a command
> statement assigning the LEFT hand side expression to the RIGHT hand
side.
>
> As you may understand by now, the <set> command does not have to
> understand the syntax of its operands nor how they were formed. All
it
> needs to know is their types and if they can be used on the LEFT and
> RIGHT hand sides respectively. If this condition is not satisfied, it
> returns a compiler error.
>
> Nothing in the processing method requires that the parser makes a
> contextual interpretation of the expressions as that only happens at
the
> code generation time.
>
> --
>
> 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
* Tobias C. Rittweiler (······@freebits.de)
...
> In how far aren't you "mak[ing] a contextual interpretation" in the
> evaluation process as you just described? Doesn't it, simplificated,
> boil down to a case analysis on different kinds of expressions?
> Probably on behalf of predicates like "Is this a variable?", "Is
> this a string?" and so on, I can't see a difference to Lisp with
> respect to that.
>
In Lisp, the distinction is implicit to some degree, by use
of different data types resp. syntactical elements. Numbers
and strings eval to themselves, symbols don't. In the xml form,
you need <string>blub</> and <number>1234</> versus <var>x</>.
Question is whether this is is a good thing.
Andreas
--
np: 4'33
Manuel Lemos <······@acm.org> writes:
> Hello,
>
> Coby Beck wrote:
> >><case>
> >> <value>34</>
> >> <do>
> >> <set>
> >> <variable>character</>
> >> <string>&quot;</>
> >> </>
> >> <break />
> >> </>
> >></>
> > (case foo
> > (34 (setf character #\")))
>
> The problem of your simplification is that you loose the ability to
> determine which module of the compiler will implement each
> command. Consider just this part:
>
> <set>
> <variable>character</variable>
> <string>&quot;</string>
> </set>
>
> The engine will traverse the XML document and when it finds the <set>
> tag it figures that it should be implemented by the set function of
> the expressions module. That function traverses the tags inside anf
> finds the <variable> and <string> tags. Then it tells the engine to
> call the respective module that implements that, and so on if there
> are any nested tags.
>
> Since you have omitted the actual tags that were meant to identify
> each compiler module should implement each command, you are forced to
> make a contextual interpretation of the result of the Lisp parser. The
> way I see it, that adds too much complexity to engine and eventually
> compromises the ability extend the engine with modules that may
> process the source differently.
:-) :-) :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
Manuel Lemos wrote:
> The problem of your simplification is that you loose the ability to
> determine which module of the compiler will implement each command.
> Consider just this part:
>
> <set>
> <variable>character</variable>
> <string>&quot;</string>
> </set>
>
> The engine will traverse the XML document and when it finds the <set>
> tag it figures that it should be implemented by the set function of the
> expressions module. That function traverses the tags inside anf finds
> the <variable> and <string> tags. Then it tells the engine to call the
> respective module that implements that, and so on if there are any
> nested tags.
In what significant way does this differ from setf expansion in Common Lisp?
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
Hello,
on 12/11/2004 08:21 PM Pascal Costanza said the following:
>> The problem of your simplification is that you loose the ability to
>> determine which module of the compiler will implement each command.
>> Consider just this part:
>>
>> <set>
>> <variable>character</variable>
>> <string>&quot;</string>
>> </set>
>>
>> The engine will traverse the XML document and when it finds the <set>
>> tag it figures that it should be implemented by the set function of
>> the expressions module. That function traverses the tags inside anf
>> finds the <variable> and <string> tags. Then it tells the engine to
>> call the respective module that implements that, and so on if there
>> are any nested tags.
>
> In what significant way does this differ from setf expansion in Common
> Lisp?
If you had (setf setf setf) you would have not analyse the context to
determine the what each setf expression means.
--
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
Manuel Lemos <······@acm.org> writes:
> Hello,
>
> Andreas Krey wrote:
> >>MetaL practically lets you define a new syntax and the add new language
> >>commands with your own compiler modules or with commands that act like
> >>macros.
> >>
> > Wich is what Lisp already had a long time.
>
> I do not know enough of Lisp to comment.
[...]
> Right, I agree that XML requires typing redundant text. I even have
> suggested the W3C consortium to simplify the requirements, for
> instance allowing the end tag be just </> and the example above would
> look simpler:
>
> <case>
> <value>34</>
> <do>
> <set>
> <variable>character</>
> <string>&quot;</>
> </>
> <break />
> </>
> </>
You, my good man, really need to learn more about Lisp. If nothing
else, it will give you lots of new ideas for your MetaL project.
Bj�rn
Manuel Lemos <······@acm.org> writes:
> Well, most new languages will look to you as unreadable in the beginning
> unless they use a syntax that is similar to the ones you know.
Not necessarily. When I first approached languages in the Lisp
family, they seemed to me more readable than the ones I already knew.
But other's mileages may--and probably do--vary.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Manuel Lemos <······@acm.org> writes:
> Metastorage [...] Metabase is a PHP package
Hi Manuel,
I have just a short question: How much of you Meta* projects is
actually implemented in this xml-based language and how much is
written in php, java, etc.?
Thanks,
Matthias
Hello,
Matthias wrote:
>>Metastorage [...] Metabase is a PHP package
>
> I have just a short question: How much of you Meta* projects is
> actually implemented in this xml-based language and how much is
> written in php, java, etc.?
The only part of Metabase that was written in MetaL is the documentation
manual and tutorials. The MetaL compiler engine comes with a module for
processing documents. It pipes document definitions that are translated
by other modules into final document files. Currently only the HTML
document module is available but this was thought to easily plug other
modules for instance for PDF and other document formats.
Metastorage consists mostly of the MetaL compiler persistence which is a
set of plain PHP classes and also a few MetaL scripts for managing the
build process.
There was once a Web ERP project that was totally written in MetaL but
it was canceled (long story from the .com bubble days). From this ERP
project several pure MetaL components were extracted for general purpose
tasks, some listed here, but they are not really Meta* projects:
http://www.meta-language.net/metal/27.html
--
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
Manuel Lemos <······@acm.org> wrote:
> Today I only develop in PHP but I do not know about the future. In the
> past I used to develop in C for Commodore Amiga computers. It was
> great but some day Commodore went out of business and the code of my
> Amiga applications and components could hardly be reused in any
> project for other platforms.
if your programs are in standard C, you can re-use it on every platform and
you have to rewrite only the platform specific parts.
> This was my main motivation to avoid
> developing applications that are too much dependent on specific
> languages and platforms.
Your MetaL doesn't look very language independent, because the XML notation
looks very much like a Java program, only written with XML tags. This is
the reason why you have to write so much MetaL to generate just one line of
PHP or Java code and it may be diffcult for example to generate Haskell
code from it.
BTW: I didn't found a formal specification of the MetaL language, which
makes it difficult to write own programs for testing MetaL.
> http://www.meta-language.net/metastorage-documentation.html#example
>
> Metastorage is in reality a script that calls the MetaL compiler
> engine to execute certain actions implemented by a special persistence
> module and other base MetaL compiler modules.
I can't see how this uses level 2 meta programming. It doesn't look very
elegant to implement the actions in PHP and not in MetaL, but perhaps I
didn't understand your concept fully. Can you give a more simpler example
to show the concept? Something like this in Lisp:
In Lisp you can execute a block some times like this:
CL-USER > (dotimes (i 10) (princ 1))
1111111111
Ok, but if you don't need the variable, you can write a macro:
(defmacro iterate (n &body body)
(let ((i (gensym)))
`(dotimes (,i ,n) ,@body)))
now you can write it shorter:
CL-USER > (iterate 10 (princ 1))
1111111111
This is the first level of meta-programming. Lisp expands it automaticly
and you can take a look, how it would look like:
CL-USER > (macroexpand-1 '(iterate 10 (princ 1)))
(DOTIMES (#:G539 10) (PRINC 1))
(the "#:G539" is the internal generated symbol name, which was generated by
gensym, because if you use a fixed local variable name, this would hide a
variable of the same name, which you otherwise could use in the loop body).
"macroexpand-1" expands only one times every macro, if you use
"macroexpand", then all macros are expanded, which would result in a longer
epxression, because "dotimes" is a macro, too, but I ignore this for this
example and continue to write one higher level by myself.
Just a simple example. If I want to create a square, I could write it like
this:
(iterate 4
(iterate 4 (princ "*"))
(terpri))
and the output:
****
****
****
****
If you want to specify the expression for outputting a character and for
newline, but you don't want to write every time the nested structure, it
would be a good idea to implement it as a macro:
(defmacro square (n one-element newline)
`(iterate ,n
(iterate ,n ,one-element)
,newline))
Then you can use it like this:
CL-USER > (square 3 (princ "x") (format t "~%"))
xxx
xxx
xxx
How does this example look like in MetaL?
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hello,
Frank Buss wrote:
>>Today I only develop in PHP but I do not know about the future. In the
>>past I used to develop in C for Commodore Amiga computers. It was
>>great but some day Commodore went out of business and the code of my
>>Amiga applications and components could hardly be reused in any
>>project for other platforms.
>
> if your programs are in standard C, you can re-use it on every platform and
> you have to rewrite only the platform specific parts.
In theory yes, but in practice, have you ever tried to develop Web
applications in C?
Actually, C is so inconvinient that it actually motivated the creation
of PHP, which was originally a just simple HTML templating language.
>>This was my main motivation to avoid
>>developing applications that are too much dependent on specific
>>languages and platforms.
>
> Your MetaL doesn't look very language independent, because the XML notation
> looks very much like a Java program, only written with XML tags. This is
> the reason why you have to write so much MetaL to generate just one line of
> PHP or Java code and it may be diffcult for example to generate Haskell
> code from it.
Right but the point was not write less code in all cases but rather
write once and just add new modules to support new languages in the future.
Another point, is that you are picking on code that just use modules for
implementing basic language structures. There are other more powerful
modules that provide dramatic development effort as well provide other
important features like separation of applications presentation from
control logic.
> BTW: I didn't found a formal specification of the MetaL language, which
> makes it difficult to write own programs for testing MetaL.
Unfortunately I never made time to write any specification. MetaL is now
an Open Source project but I only bother to open its source because I
wanted to open the source of Metastorage in order to attract as many
users as possible to participate in the tests by actually use it.
Anyway, an eventual specification of MetaL as language would basically
say that the commands of the language are implemented by modules that
give meaning to each of the commands. From then on, the specification
would be at the module level detailing each command individually.
>>http://www.meta-language.net/metastorage-documentation.html#example
>>
>>Metastorage is in reality a script that calls the MetaL compiler
>>engine to execute certain actions implemented by a special persistence
>>module and other base MetaL compiler modules.
>
> I can't see how this uses level 2 meta programming. It doesn't look very
> elegant to implement the actions in PHP and not in MetaL, but perhaps I
> didn't understand your concept fully. Can you give a more simpler example
> to show the concept? Something like this in Lisp:
In the case of Metastorage, the source code just described a set of
related classes of objects that should perform some actions according to
some parameters.
The meaning of these classes and their behaviour is interpreted by the
persistence module. This module generates descriptions of XML documents
that are actual source code of the described classes in meta-programming
level 1.
So, you may be already understanding there the compilation of a
Metastorage component happens in two steps:
1) Translating Metastorage component class definitions in MetaL XML
source code.
2) Translating Metal XML source code into the final target language
source code.
> How does this example look like in MetaL?
I do not recall enough of Lisp to completely understand the code that
you presented. However, I can tell you that there is a flow module that
provides many types of flow control structions including loops,
conditions, switch/case, macros, etc.. There is also a module for
defining classes of objects with functions and variables. With these
modules it seemed that you could write equivalent code in MetaL to do
what you described in Lisp.
--
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
In article <············@newsreader2.netcologne.de>,
Frank Buss <··@frank-buss.de> wrote:
> Manuel Lemos <······@acm.org> wrote:
>
> > Today I only develop in PHP but I do not know about the future. In the
> > past I used to develop in C for Commodore Amiga computers. It was
> > great but some day Commodore went out of business and the code of my
> > Amiga applications and components could hardly be reused in any
> > project for other platforms.
>
> if your programs are in standard C, you can re-use it on every platform and
> you have to rewrite only the platform specific parts.
>
> > This was my main motivation to avoid
> > developing applications that are too much dependent on specific
> > languages and platforms.
>
> Your MetaL doesn't look very language independent, because the XML notation
> looks very much like a Java program, only written with XML tags. This is
> the reason why you have to write so much MetaL to generate just one line of
> PHP or Java code and it may be diffcult for example to generate Haskell
> code from it.
>
> BTW: I didn't found a formal specification of the MetaL language, which
> makes it difficult to write own programs for testing MetaL.
>
> > http://www.meta-language.net/metastorage-documentation.html#example
> >
> > Metastorage is in reality a script that calls the MetaL compiler
> > engine to execute certain actions implemented by a special persistence
> > module and other base MetaL compiler modules.
>
> I can't see how this uses level 2 meta programming. It doesn't look very
> elegant to implement the actions in PHP and not in MetaL, but perhaps I
> didn't understand your concept fully. Can you give a more simpler example
> to show the concept? Something like this in Lisp:
>
> In Lisp you can execute a block some times like this:
>
> CL-USER > (dotimes (i 10) (princ 1))
> 1111111111
>
> Ok, but if you don't need the variable, you can write a macro:
>
> (defmacro iterate (n &body body)
> (let ((i (gensym)))
> `(dotimes (,i ,n) ,@body)))
>
> now you can write it shorter:
>
> CL-USER > (iterate 10 (princ 1))
> 1111111111
>
> This is the first level of meta-programming. Lisp expands it automaticly
> and you can take a look, how it would look like:
>
> CL-USER > (macroexpand-1 '(iterate 10 (princ 1)))
> (DOTIMES (#:G539 10) (PRINC 1))
>
> (the "#:G539" is the internal generated symbol name, which was generated by
> gensym, because if you use a fixed local variable name, this would hide a
> variable of the same name, which you otherwise could use in the loop body).
>
> "macroexpand-1" expands only one times every macro, if you use
> "macroexpand", then all macros are expanded, which would result in a longer
> epxression, because "dotimes" is a macro, too, but I ignore this for this
> example and continue to write one higher level by myself.
>
> Just a simple example. If I want to create a square, I could write it like
> this:
>
> (iterate 4
> (iterate 4 (princ "*"))
> (terpri))
>
> and the output:
>
> ****
> ****
> ****
> ****
>
> If you want to specify the expression for outputting a character and for
> newline, but you don't want to write every time the nested structure, it
> would be a good idea to implement it as a macro:
>
> (defmacro square (n one-element newline)
> `(iterate ,n
> (iterate ,n ,one-element)
> ,newline))
>
> Then you can use it like this:
>
> CL-USER > (square 3 (princ "x") (format t "~%"))
> xxx
> xxx
> xxx
>
> How does this example look like in MetaL?
I'm still not sure for what you need a macro like SQUARE. plain old functions are
good enough. for a newline I would just call TERPRI and saving the overhead
for calling FORMAT,
Rainer Joswig <······@lisp.de> wrote:
> I'm still not sure for what you need a macro like SQUARE. plain old
> functions are good enough.
ok, not really useful, but my goal was to provide a simple example. And you
can use it for other things than printing chars, without using lambda:
(loop for i from 1 to 9 do
(let ((square-char (digit-char i)))
(square i
(print-char-on-special-hardware square-char)
(newline-on-special-hardware))))
> for a newline I would just call TERPRI and
> saving the overhead for calling FORMAT,
yes, I just want to write something different from my first manually
expanded code.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
In article <············@newsreader2.netcologne.de>,
Frank Buss <··@frank-buss.de> wrote:
> Rainer Joswig <······@lisp.de> wrote:
>
> > I'm still not sure for what you need a macro like SQUARE. plain old
> > functions are good enough.
>
> ok, not really useful, but my goal was to provide a simple example. And you
> can use it for other things than printing chars, without using lambda:
>
> (loop for i from 1 to 9 do
> (let ((square-char (digit-char i)))
> (square i
> (print-char-on-special-hardware square-char)
> (newline-on-special-hardware))))
From a programming style point of view, I find this could be improved.
You want to make it clear what is a macro expression, where you
have special places for code that is not evaluated like
in a function call.
I would
a) rename SQUARE to something like WITH-SQUARE, WITH-OUPUT-AS-SQUARE, ...
b) put the count variable into a list
c) let the rest stuff be a &body
plus I would not put LETs inside of LOOP, when LOOP already
provides the iteration form that would be useful:
The code would look like that:
(loop for i from 1 to 9
for square-char = (digit-char i)
do (with-output-as-square (i)
(print-char-on-special-hardware square-char)
(newline-on-special-hardware)))
But the really best thing is to use functional abstraction:
(square i
(lambda ()
(print-char-on-special-hardware square-char)
(newline-on-special-hardware)))
Functional abstraction is from a maintenance perspective
MUCH better. You can debug it, you get late-binding, etc.
If you ever drop into a debugger, you will see the calls on the
stack (unless you are using heavy optimization or other things)
and you see what is going on. If you use macros as means
of abstraction you can forget about debugging things
easily. You will see forms in the debugger that you haven't
seen before ;-) (because they are machine generated) and
it is really hard to find the generating source code them.
And debugging time is REALLY expensive. Function calls
to draw squares are cheap in comparison.
So, rule one: don't use macros unless you REALLY need them
(kind of the same like you need to think when you use
APPEND, EVAL and the like).
Use macros to extend the language, but not for 'ordinary'
programming. Don't even use macros if you want code inlining.
> > for a newline I would just call TERPRI and
> > saving the overhead for calling FORMAT,
>
> yes, I just want to write something different from my first manually
> expanded code.
Rainer Joswig <······@lisp.de> writes:
> > If you want to specify the expression for outputting a character and for
> > newline, but you don't want to write every time the nested structure, it
> > would be a good idea to implement it as a macro:
> >
> > (defmacro square (n one-element newline)
> > `(iterate ,n
> > (iterate ,n ,one-element)
> > ,newline))
> >
> > Then you can use it like this:
> >
> > CL-USER > (square 3 (princ "x") (format t "~%"))
> > xxx
> > xxx
> > xxx
> >
> > How does this example look like in MetaL?
>
> I'm still not sure for what you need a macro like SQUARE. plain old
> functions are good enough. for a newline I would just call TERPRI
> and saving the overhead for calling FORMAT,
Because you don't get it. You don't see abstraction when it's shown in
front of your nose.
square is not a function. It's a new control structure, a new
statement in a new language built in the meta language Common-Lisp.
(let ((n 0))
(square 5
(incf n 1)
(incf n 100))
n)
==> 525
(let ((n '()))
(square 5
(push '- n)
(push '/ n))
n)
==> (/ - - - - - / - - - - - / - - - - - / - - - - - / - - - - -)
(let ((n '())(m '()))
(square 5
(push '- n)
(progn (push n m) (setf n '())))
m)
==> ((- - - - -) (- - - - -) (- - - - -) (- - - - -) (- - - - -))
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@mouse-potato.com> wrote:
> Rainer Joswig <······@lisp.de> writes:
> > > If you want to specify the expression for outputting a character and for
> > > newline, but you don't want to write every time the nested structure, it
> > > would be a good idea to implement it as a macro:
> > >
> > > (defmacro square (n one-element newline)
> > > `(iterate ,n
> > > (iterate ,n ,one-element)
> > > ,newline))
> > >
> > > Then you can use it like this:
> > >
> > > CL-USER > (square 3 (princ "x") (format t "~%"))
> > > xxx
> > > xxx
> > > xxx
> > >
> > > How does this example look like in MetaL?
> >
> > I'm still not sure for what you need a macro like SQUARE. plain old
> > functions are good enough. for a newline I would just call TERPRI
> > and saving the overhead for calling FORMAT,
>
> Because you don't get it. You don't see abstraction when it's shown in
> front of your nose.
Pascal, thanks to let me know. You are in my kill-list now. ;-)
>
> square is not a function. It's a new control structure, a new
> statement in a new language built in the meta language Common-Lisp.
>
>
> (let ((n 0))
> (square 5
> (incf n 1)
> (incf n 100))
> n)
>
> ==> 525
>
>
> (let ((n '()))
> (square 5
> (push '- n)
> (push '/ n))
> n)
>
> ==> (/ - - - - - / - - - - - / - - - - - / - - - - - / - - - - -)
>
>
>
> (let ((n '())(m '()))
> (square 5
> (push '- n)
> (progn (push n m) (setf n '())))
> m)
>
> ==> ((- - - - -) (- - - - -) (- - - - -) (- - - - -) (- - - - -))
Manuel Lemos wrote:
>
>
> Well, most new languages will look to you as unreadable in the beginning
> unless they use a syntax that is similar to the ones you know.
>
I started to write functions which I think perfom what you specifiied in
your MetaL example.
http://www.meta-language.net/sample.html#class-metal
For your xml_write_class and the first function
escapedata I wrote:
(defclass xml-writer-class ()
((structure :initform nil :accessor %structure)
(nodes :initform nil :accessor nodes)
(stylesheet :initform "" :accessor stylesheet)
(stylesheettype :initform "text/xsl" :accessor stylesheettype)
(dtdtype :initform "" :accessor dtdtype)
(dtddefinition :initform "" :accessor dtddefinition)
(dtdurl :initform "" :accessor dtdurl)
(outputencoding :initform :utf-8 :accessor outputencoding)
(inputencoding :initform :iso-8859-1 :accessor inputencoding)
(linebreak :initform #\newline :accessor linebreak)
(indenttext :initform " " :accessor indenttext)
(error :initform "" :accessor %error)))
(defmethod escapedata ((obj xml-writer-class) (data string))
(declare (ignore obj))
(with-output-to-string (escapedata)
(loop for character across data
do
(write-string
(case character
(#\" """)
(#\& "&")
(#\' "'")
(#\< "<")
(#\> ">")
(otherwise
(if (< (char-int character) 32)
(format nil "&#~D;" (char-int character))
(string character))))
escapedata))))
These are a far cry from your translations into PHP and Java. I would
have to say that the MetaL spec is not declarative enough. It pretty well
specifies a contrived way (i.e. Java and PHP coding conventions) to
implement the algorithm.
Wade
Hello,
on 12/11/2004 11:35 PM Wade Humeniuk said the following:
>> Well, most new languages will look to you as unreadable in the beginning
>> unless they use a syntax that is similar to the ones you know.
>>
>
> I started to write functions which I think perfom what you specifiied in
> your MetaL example.
>
> http://www.meta-language.net/sample.html#class-metal
>
> For your xml_write_class and the first function
> escapedata I wrote:
>
> (defclass xml-writer-class ()
> ((structure :initform nil :accessor %structure)
> (nodes :initform nil :accessor nodes)
> (stylesheet :initform "" :accessor stylesheet)
> (stylesheettype :initform "text/xsl" :accessor stylesheettype)
> (dtdtype :initform "" :accessor dtdtype)
> (dtddefinition :initform "" :accessor dtddefinition)
> (dtdurl :initform "" :accessor dtdurl)
> (outputencoding :initform :utf-8 :accessor outputencoding)
> (inputencoding :initform :iso-8859-1 :accessor inputencoding)
> (linebreak :initform #\newline :accessor linebreak)
> (indenttext :initform " " :accessor indenttext)
> (error :initform "" :accessor %error)))
>
> (defmethod escapedata ((obj xml-writer-class) (data string))
> (declare (ignore obj))
> (with-output-to-string (escapedata)
> (loop for character across data
> do
> (write-string
> (case character
> (#\" """)
> (#\& "&")
> (#\' "'")
> (#\< "<")
> (#\> ">")
> (otherwise
> (if (< (char-int character) 32)
> (format nil "&#~D;" (char-int character))
> (string character))))
> escapedata))))
>
> These are a far cry from your translations into PHP and Java. I would
> have to say that the MetaL spec is not declarative enough. It pretty well
> specifies a contrived way (i.e. Java and PHP coding conventions) to
> implement the algorithm.
I am not sure what is your point.
--
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
In article <···············@individual.net>,
Manuel Lemos <······@acm.org> wrote:
> on 12/11/2004 11:35 PM Wade Humeniuk said the following:
> > For your xml_write_class and the first function
> > escapedata I wrote:
> >
[snip]
> >
> > (defmethod escapedata ((obj xml-writer-class) (data string))
> > (declare (ignore obj))
> > (with-output-to-string (escapedata)
> > (loop for character across data
> > do
> > (write-string
> > (case character
> > (#\" """)
> > (#\& "&")
> > (#\' "'")
> > (#\< "<")
> > (#\> ">")
> > (otherwise
> > (if (< (char-int character) 32)
> > (format nil "&#~D;" (char-int character))
> > (string character))))
> > escapedata))))
> >
> > These are a far cry from your translations into PHP and Java. I would
> > have to say that the MetaL spec is not declarative enough. It pretty well
> > specifies a contrived way (i.e. Java and PHP coding conventions) to
> > implement the algorithm.
>
> I am not sure what is your point.
from your web site:
MetaL is shorthand for Meta-programming Language.
Meta-programming is a method to develop computer programs. It
works by generating source code in a target language from a
program specification in a higher level language.
I think his point is that you have specified a rather Java/PHP-specific
solution in your MetaL code for that example. There's no way you could
go from your MetaL specification to Wade's code above, even though they
do the same thing.
If you had written your MetaL spec for this problem with higher-level
abstractions, it is conceivable that your program specification could
generate the rather idiomatic Lisp code above and simultaneously be able
to output the lower-level Java and PHP code in your example. Instead
you've encoded the lower-level stuff into your specification, which
limits generating higher level code without a rather taxing analysis
process.
(It's possible that this example was simply rushed and not a typical
sample of MetaL code.)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Brian Downing wrote:
>
> from your web site:
>
> MetaL is shorthand for Meta-programming Language.
> Meta-programming is a method to develop computer programs. It
> works by generating source code in a target language from a
> program specification in a higher level language.
>
> I think his point is that you have specified a rather Java/PHP-specific
> solution in your MetaL code for that example. There's no way you could
> go from your MetaL specification to Wade's code above, even though they
> do the same thing.
>
> If you had written your MetaL spec for this problem with higher-level
> abstractions, it is conceivable that your program specification could
> generate the rather idiomatic Lisp code above and simultaneously be able
> to output the lower-level Java and PHP code in your example. Instead
> you've encoded the lower-level stuff into your specification, which
> limits generating higher level code without a rather taxing analysis
> process.
>
Yes, I agree with that. The MetaL specfies the solution in terms of
variables specifing C-like array indexes and iteration. For me the MetaL
spec is not a spec but a lowest-common-denominator algoritm that can
be implemented in both PHP and Java. It really needs to be specified with
higher level abstractions.
In Lisp I think the specification should look something like:
(defmethod escapedata ((obj xml-writer-class) (data string))
(declare (ignore obj))
(element-wise-substitution data
:output-encoding (string :encoding (encoding data))
:associative-mapping
'((#\" """)
(#\& "&")
(#\' "'")
(#\< "<")
(#\> ">")
((< integer-encoding 32) (string-concatenate "&#" integer-encoding ";"))
(t #'identity))))
And my stab at an xml like syntax:
<method>escapedata<owned>xml-writer-class</owned>
<args><string encoding=any>data</string></args>
<substitite>
<source>data</source>
<method>element-wise</method>
<mapping>associative</mapping>
<output-encoding><encoding>data</encoding></output-encoding>
<mapping>
<from><iencoding>34</iencoding></from><to>&quot;</to>
<from><iencoding>38</iencoding></from><to>&amp;</to>
<from><iencoding>39</iencoding></from><to>&apos;</to>
<from><iencoding>60</iencoding></from><to>&lt;</to>
<from><iencoding>62</iencoding></from><to>&gt;</to>
<from><iencoding><lower>0</lower><upper>31</upper><iencoding></from>
<to><concatenate>
<value>&#</value>
<value><iencoding /></value>
<value>;</value>
</concatenate>
</to>
<from><iencoding>any</ienconding></from><to>identity</to>
</mapping>
</substitute>
</method>
Wade
There's no rule that says you have to have all the data in elements in
XML; it's normal that a syntax designed for human use will have
attributes for data about the elements, eg:
<template name="escapedata"
xmlns="http://www.w3.org/1999/XSL/Transform">
<param name="data"/>
<foreach select="string-to-codepoints($data)">
<choose>
<when test=".=34">&quot;</when>
<when test=".=38">&amp;</when>
<when test=".=39">&apos;</when>
<when test=".=60">&lt;</when>
<when test=".=62">&gt;</when>
<!-- nul is not valid even if you escape it -->
<when test=".>0 and .<32">&#<value-of
select='.'/>;</when>
<otherwise><value-of
select='codepoints-to-string((.))'/></otherwise>
</choose>
</foreach>
</template>
(though I haven't tested that that runs)
Pete
From: Rahul Jain
Subject: Re: Python gets macros - now XML does too
Date:
Message-ID: <87brcn7xkz.fsf@nyct.net>
Pete Kirkham <·················@cafemosaic.co.uk> writes:
> There's no rule that says you have to have all the data in elements in
> XML; it's normal that a syntax designed for human use will have
> attributes for data about the elements, eg:
>
> <template name="escapedata"
> xmlns="http://www.w3.org/1999/XSL/Transform">
> <param name="data"/>
> <foreach select="string-to-codepoints($data)">
How about if I want to do <foreach select="<choose> .... </choose>"> ?
Attributes are not XML-valued. They are CDATA (freeform string)-valued.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
I don't want to turn this thread into an xslt2 tutorial, but
<xsl:variable name="foo"><choose> .... </choose></xsl:variable>
<xsl:foreach select="$foo">
would be one idiom for such cases
Pete
Hello,
on 12/19/2004 11:45 PM Brian Downing said the following:
>>>These are a far cry from your translations into PHP and Java. I would
>>>have to say that the MetaL spec is not declarative enough. It pretty well
>>>specifies a contrived way (i.e. Java and PHP coding conventions) to
>>>implement the algorithm.
>>I am not sure what is your point.
>
> from your web site:
>
> MetaL is shorthand for Meta-programming Language.
> Meta-programming is a method to develop computer programs. It
> works by generating source code in a target language from a
> program specification in a higher level language.
>
> I think his point is that you have specified a rather Java/PHP-specific
> solution in your MetaL code for that example. There's no way you could
> go from your MetaL specification to Wade's code above, even though they
> do the same thing.
I see, but it seems you are viewing it from the wrong perspective. Let
me explain.
The point of MetaL is that from the same MetaL source code it can
generate equivalent code in different target languages, just like a C
compiler that can generate assembly code for different CPUs.
> If you had written your MetaL spec for this problem with higher-level
> abstractions, it is conceivable that your program specification could
> generate the rather idiomatic Lisp code above and simultaneously be able
> to output the lower-level Java and PHP code in your example. Instead
> you've encoded the lower-level stuff into your specification, which
> limits generating higher level code without a rather taxing analysis
> process.
>
> (It's possible that this example was simply rushed and not a typical
> sample of MetaL code.)
The MetaL compiler engine is modular. This means that I can add as many
modules as I want. There is no closed spec for the language because I
can add, remove, exchange any modules as it pleases me or whover feels
compeled to hack it.
That sample code that you have seen is just an example that uses
whatever modules were necessary to create a class for creating XML
documents (at runtime).
Currently there are about 30 modules but many more could be used for
implementing higher or lower level language constructs. It is just a
matter of need.
--
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