Re: A "killer" macro

In article <1189675849.006869.263540@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Eli Bendersky <eliben@xxxxxxxxx> wrote:

Lisp excels at _____ (fill in the blank). Now you've at least
eliminated some possibilities in your search.

(Maybe you already filled-in the blank with this macro capability you
spoke of. However, if it is difficult to find something here dramatic
enough to impress your friends, perhaps you can list other Lisp
"standout" features? Or perhaps Lisp doesn't have one thing ultra-
dramatic in one particular category, but a lot of less dramatic things
in many categories, and these things all add up in the end? If
nothing else, at least Lisp's syntax isn't nearly as grotesque and
burdensome as something like Java's. Come on - look at a Java "Hello
World" program, with the class declaration, the "public static void
main," the "System.blah.whatever.printblah" hideousness, etc. - but
then again if it hasn't already occurred to a Java programmer to hate
all of that stuff, you are probably barking up the wrong tree with
trying to convert that particular person.)

Regards.

But you see, as I mentioned in my original post, Lisp really stands
out only in its macros, because all the rest was already implemented
in other languages.

Unfortunately in hundreds of languages. In Lisp you can have
it in one language.

Sure with XML now everybody can describe data (and even procedures)
with a prefix language. Unfortunately the mechanisms are
ugly, monstrous and much less integrated.

In Lisp I write

(service-call "SVCL"
(04 18 customer-name)
(19 23 customer-id)
(24 27 call-type-code)
(28 35 date-of-call-string))

and READ reads it. Plain and simple. No monstrous XML
parser. If I want to do something with it I apply
a function. If I want to compile it with the compiler
to some efficient procedure, I write a macro and
add it to the expression:

(DEFMAPPING service-call "SVCL"
(04 18 customer-name)
(19 23 customer-id)
(24 27 call-type-code)
(28 35 date-of-call-string))

Still I'm able to READ it, pretty print it, transform it.
All with mildly simple mechanisms.

Yes, 20 years ago Lisp was amazing - compared with
C, Fortran and Pascal, but these days with Perl, Ruby and even C# 3.0
around, the only thing that *really* sets Lisp apart is macros.

Eli

That's plain wrong.

Macros are available in other programming languages, too.

Common Lisp is a multi-paradigm language that enables
interactive software development of small to very
large programs with somehow useful efficiency.
At its core it is very extensible to be able to
add very different programming paradigms.

PERL, Ruby and C# are very different. In Common Lisp
you can do most that those can in one package.
Ruby is totally inefficient (besides what is implemented
in C in its core) and there is little hope that it
can be better. You can write most Ruby stuff relatively
easy in Lisp, but if you try to use Ruby for Lisp
software be prepared for a hard time.
C# is a static language in the
tradition of C, C++ and others with more complication
bolted on the totally wrong base language. Sure
you can have closures in C#, but the result is ugly.
I you bolt wings on Frankenstein's monster, do you
think it will be a beautiful bird?

I try to minimize my writing of macros, that's not the single
important feature for me. I have not found
any environment for Ruby, Perl or C# that works
like Allegro CL, MCL, LispWorks or even Symbolics Genera.
The only ones that are close are Smalltalk environments
and some less known others.

--
http://lispm.dyndns.org
.

Relevant Pages

  • Re: Two questions together
    ... How powerful are the macros? ... > "programmable language" and as far as I know this feature is provided ... It is also said that one can hammer the Lisp so that ... I really love Lisp's syntax:) But I just want ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... How is OCaml on adding readmacros, which Lisp can do easily. ... I would not ask that of a parsed language. ... We're confident that using macros is useful to us, ... debate has legitimate points on both sides. ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... but then Ruby is dog slow anyway: ... Having notational convenience via macros plus efficiency is a big win ... From my perspective as a Ruby programmer learning Lisp, ... thought of having a more powerful language *and* orderof magnitude ...
    (comp.lang.lisp)
  • Re: Is Lisp ready to become popular?
    ... the lack of "standard" networking libraries and the like, the fact that free Lisps depend on Emacs as an editor and Emacs is _not_ the default editor of many developers, the unfortunate fact that Lisp syntax is so obviously different. ... It's generating a fair amount of conversation in the Java community. ... Tate is clearly impressed by Ruby, but he dismisses Lisp's chances based on its "history and reputation to overcome". ... or in a programming language ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... reason I turned to Lisp is that many, or even most, people in the C++ ... it is also a good idea to be careful with adding new macros. ... Hence an ideal language for implementing an interpreter for Simulink models would allow one to define block types directly, like e.g. so: ... So the actual implementation of the functionality provided by define-node-type is mostly achieved through functional libraries, MOP hackery, etc., and it is indeed still possible to define new node types by hand via defclass, defmethod and various globally-defined macro helpers, but a node definition is much more concise. ...
    (comp.lang.lisp)