Re: A "killer" macro

On Sep 13, 10:30 am, Eli Bendersky <eli...@xxxxxxxxx> wrote:
On Sep 13, 12:34 pm, Rainer Joswig <jos...@xxxxxxx> wrote:



In article <1189675849.006869.263...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Eli Bendersky <eli...@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.

This is a good point. But it's true because of macros. With macros and
Lisp's uniform syntax, I can not only write a library that implements
anything I might deem important, but also make it look
indistinguishable from native Lisp - extend the language itself.



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, but this already exists in other languages. Javascript has JSON
which is almost like the Lisp way of storing data in s-expressions.
YAML is also popular (and 99% equivalent to JSON).





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.

Yes, true - "at its core it is very extensible" *because* of macros.

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.

Leaving inefficiency apart for the moment[1], Ruby has anything Lisp
has except macros. Ruby is the latest and greatest in the evolution
path of modern programming languages and their convergence path with
Lisp. Again, I'll use Norvig's "seven points that make Lisp
different".

Ruby:

* It has a convenient built-in syntax for arrays and hash tables
* Garbage collection
* Dynamic typing - in fact the closest to Lisp yet (except maybe
Smalltalk, with which I'm not familiar) with its duck typing
philosophy
* First class functions, with the syntactic sugar called "blocks"
which makes a lot of higher-order functional paradigms very convenient
* Interactive Environment - Ruby's "irb" is in many ways equivalent to
the REPL. And Ruby slowly but surely gets the support of good IDEs -
Emacs, Eclipse, Visual Studio, NetBeans and so on.
* Extensibility - everything is modifiable, full reflection
capabilities - you can even change built-in classes on the fly.
module_eval and class_eval allow for much safer code generation than
the string eval of Perl. Ruby is open enough to be the most convenient
language, after Lisp of course, for writing DSLs.

* Uniform syntax: Bzzzzt! Nope. None, and so no *real* macros either.
Ruby loses to Lisp on this point, and this is a big point,
admittedly.

But when you tell people about this last point, they say - fine, but
what's so great about these macros.
And so we come back to the original reason for my starting this
thread!

Eli

[1] I see no reason why Ruby should be inherently less efficient than
any other interpreted language.

I would not know. But it is surely less efficiente than a compiled
language like Common Lisp.

With its new VM in development, it has
hope yet. And anyway, performance alone can't play that big a role.
Ruby's interoperability with C is much simpler to work out than CL's
CFFI, and writing critical code in C is very possible.

CFFI is used to interface to existing libraries written in C. With
CL, thanks to the built in function COMPILE, you almost never need to
resort to C.

Cheers

Marco


.

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: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... with a prefix language. ... the only thing that *really* sets Lisp apart is macros. ... Ruby and C# are very different. ...
    (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)