«

Joachim Durchholz <> writes:

> Peter Seibel wrote:
> > Joachim Durchholz <> writes:
> >
> >>Efficiency issues aside: how are macros more intuitive than quoting?
> > Or you could do this:
> > (when (> x y) #'(lambda () (print x)))
> > which could work but seems a bit convoluted (i.e. unintuitive)
> > compared to the macro version.
>
> Um, right, but that's just a question of having the right syntactic sugar.

Uh right, that's what macros are for, providing the syntactic sugar.

-Peter

--
Peter Seibel

Lisp is the red pill. -- John Fraser, comp.lang.lisp

Peter Seibel wrote:
> Joachim Durchholz <> writes:
>
> > Peter Seibel wrote:
> > > Joachim Durchholz <> writes:
> > >
> > >>Efficiency issues aside: how are macros more intuitive than quoting?
> > > Or you could do this:
> > > (when (> x y) #'(lambda () (print x)))
> > > which could work but seems a bit convoluted (i.e. unintuitive)
> > > compared to the macro version.
> >
> > Um, right, but that's just a question of having the right syntactic
sugar.
>
> Uh right, that's what macros are for, providing the syntactic sugar.

Yes, but the point is that with a concise syntax for lambda, entire classes
of macros can become unnecessary. That's how Smalltalk handles 'if', for
example - no macros or special forms needed.

Joachim Durchholz <> writes:
> This statement is wrong if left in full generality: higher-order
> functions can control quite precisely what gets evaluated when.

They don't let you execute stuff at compile time. If you write down:

(parser '( ;; ... 10 pages of BNF ... ;;
))


Then the parser is going to be computed at runtime. HOF themselves
don't help you compute stuff at compile time. (Though one can
certainly imagine a language where compile-time execution is
controlled by pragmas.)


-Lex

"Anton van Straaten" <> writes:

> Peter Seibel wrote:
> > Joachim Durchholz <> writes:
> >
> > > Peter Seibel wrote:
> > > > Joachim Durchholz <> writes:
> > > >
> > > >>Efficiency issues aside: how are macros more intuitive than quoting?
> > > > Or you could do this:
> > > > (when (> x y) #'(lambda () (print x)))
> > > > which could work but seems a bit convoluted (i.e. unintuitive)
> > > > compared to the macro version.
> > >
> > > Um, right, but that's just a question of having the right syntactic
> sugar.
> >
> > Uh right, that's what macros are for, providing the syntactic sugar.
>
> Yes, but the point is that with a concise syntax for lambda, entire
> classes of macros can become unnecessary. That's how Smalltalk
> handles 'if', for example - no macros or special forms needed.

Okay, so I picked an unfortunate example in that it also falls in the
class of macros that become unecessary when other bits of syntactic
sugar are provided. How about this one.

Which is more intuitive?

This:

(defun foo () (print "hello, world")))

Or this:

(progn (eval-when (:compile-toplevel)
(excl::check-lock-definitions-compile-time 'foo 'function
'defun (fboundp 'foo))
(push 'foo excl::.functions-defined.))
(progn (eval-when (:compile-toplevel)
(excl::check-de-argdecl-change 'foo 'nil))
(declaim (excl::dynamic-extent-arguments nil foo)))
(setf (fdefinition 'foo)
(let ((excl::f
(named-function foo
(lambda nil
(block foo (print "hello, world"))))))
(excl::set-func_name excl::f 'foo)
excl::f))
(remprop 'foo 'excl::%fun-documentation)
(record-source-file 'foo) 'foo)

-Peter

--
Peter Seibel

Lisp is the red pill. -- John Fraser, comp.lang.lisp

On Thu, 30 Oct 2003 23:29:00 +0000, Peter Seibel wrote:

>> Yes, but the point is that with a concise syntax for lambda, entire
>> classes of macros can become unnecessary. That's how Smalltalk
>> handles 'if', for example - no macros or special forms needed.
>
> Okay, so I picked an unfortunate example in that it also falls in the
> class of macros that become unecessary when other bits of syntactic
> sugar are provided. How about this one.
[...]

Nobody says that *everything* should be expressed by higher order
functions. But with enough builtin syntax and concise anonymous function
notation (in particular using {} or [] for functions without arguments)
there are much fewer uses of macros than in Lisp, which has little builtin
syntax and ugly anonymous functions.

The remaining uses of macros are so rare that few languages choose to take
the cost of having macros (I mean full-blown Lisp-like macros which execute
arbitrary code at compile time and can examine its parameters).

The costs: syntax seems to be constrained to have a very regular surface
structure full of parentheses; the language must describe and implement a
representation of code as data which would otherwise be unnecessary; every
compiler must include an interpreter; it's hard to report errors to the
user showing the code as it's written in the source if the error is found
after macro expansion.

I'm not saying that the cost is obviously too high but that it's a
tradeoff, macros don't come for free. And that there are other ideas which
can replace many macros with different tradeoffs: namely a richer builtin
syntax and concise anonymous functions. In a lazy language there are yet
fewer uses of macros.

--
__("< Marcin Kowalczyk
\__/
^^ http://qrnik.knm.org.pl/~qrczak/

Peter Seibel wrote:

> "Anton van Straaten" <> writes:

>>Yes, but the point is that with a concise syntax for lambda, entire
>>classes of macros can become unnecessary. That's how Smalltalk
>>handles 'if', for example - no macros or special forms needed.
>
>
> Okay, so I picked an unfortunate example in that it also falls in the
> class of macros that become unecessary when other bits of syntactic
> sugar are provided.

No, I don't think so. Here is what I needed in a real program.

I had several cond statements at various places of my code. They all
didn't have a default case. At a certain stage, I needed to be sure to
get an exceptional return value for the default case instead of NIL. So
I added a macro:

(defconst *error-form*
'(mv (trans-pstate pstate :exception 'program-error) *void*))

(defmacro ev-cond* (pstate &body body)
`(cond ,@(append body `((t (let ((pstate ,pstate)) ,*error-form*))))))

*ERROR-FORM* here is the standard code that changes a program state to a
state with an exception and a *void* return type. EV-COND* is my
modified COND that simply adds a default case in which PSTATE is
correctly bound so that *ERROR-FORM* can do the right thing.

(This isn't "pure" Common Lisp, but ACL2, and the code is somewhat more
complicated than necessary because ACL2 places some severe restrictions
on the code that one can write.)

The essence of this is as follows:

(defmacro my-cond (&body body)
`(cond ,@(append body '(t (handle-the-default-case))))

With simple shadowing imports one can make this completely transparent
to client code.

How would you do this with a Smalltalk-like if expression? (This is not
a rhetoric question - I would be really interested to hear how one could
make this work.)


Pascal

Marcin 'Qrczak' Kowalczyk wrote:

> I'm not saying that the cost is obviously too high but that it's a
> tradeoff, macros don't come for free. And that there are other ideas which
> can replace many macros with different tradeoffs: namely a richer builtin
> syntax and concise anonymous functions. In a lazy language there are yet
> fewer uses of macros.

Ahh, the "in 99% of all cases" argument once again...


Pascal

Marcin 'Qrczak' Kowalczyk <> writes:

> The remaining uses of macros are so rare ...

So, just in case it wasn't completely clear to anyone watching, this
right here is the big point of disagreement. What do you think the
"remaining uses" are and why do you say they are "rare"?[1]

Common Lispers don't consider the remaining uses we make of
macros--things like defining functions, classes, and methods, our
condition (exception) system, interfacing to C code, etc. to be all
that rare.

And that's just the stuff that's built into the language (or a
particular implementation in the case of interfacing to C). Now let's
look at a sample of the code in my personal code library: test
frameworks, regular expressions, parser generators, HTML generation,
PDF generation and typesetting, genetic programming system ... hmmm,
they all seem to use macros, some of them are practically nothing
*but* macros.

Of course in languages that don't have macros, these things are done
without macros--they are either built into the language (defining
functions) or moved out into completely external tools (parser
generators). But--as we should all recognize by now--Turing
equivalence has nothing to do with language expressiveness.

-Peter

[1] Even if the uses of macros *were* rare that's doesn't seem to be
the correct metric to balance against the "costs" of macros. Normally
we weigh costs versus benefits, right? So in a way, the higher
non-Lispers estimate the "costs" of macros (need for an code-as-data
syntax, interpreter built into the compiler, etc.), the higher they
should estimate the benefits. At least if they give Lisp programmers
*any* credit at all for making a rational choice in tool selection.
Because Common Lispers love macros and find the benefits *far*
outweigh the costs. But I guess you can explain that by assuming we're
deluded.

--
Peter Seibel

Lisp is the red pill. -- John Fraser, comp.lang.lisp

In article <>, Peter Seibel wrote:
> [1] Even if the uses of macros *were* rare that's doesn't seem to be
> the correct metric to balance against the "costs" of macros. Normally
> we weigh costs versus benefits, right? So in a way, the higher
> non-Lispers estimate the "costs" of macros (need for an code-as-data
> syntax, interpreter built into the compiler, etc.), the higher they
> should estimate the benefits. At least if they give Lisp programmers
> *any* credit at all for making a rational choice in tool selection.
> Because Common Lispers love macros and find the benefits *far*
> outweigh the costs. But I guess you can explain that by assuming we're
> deluded.

No one is saying all Lispers are deluded (I hope). There are plenty
of good ideas in Lisp, but I'd like to have them without losing the
advantages of static typing and syntax requiring minimal editor support.
Template Haskell is a good step in that direction.

Simon.

"Pascal Costanza" <> wrote in message
news:bnscfb$p1k$...
>
> The essence of this is as follows:
>
> (defmacro my-cond (&body body)
> `(cond ,@(append body '(t (handle-the-default-case))))
>

Just to provide a more apparently general (and working version, analogous
to CL's ECASE:

CL-USER 90 >
(defmacro econd (&body body)
`(cond ,@(append body
`((t (error (format nil
"fell through ECOND form. could not
satisfy any of the following: ~{~%~A~}~%"
(mapcar #'(lambda (cond)
(car cond))
',body))))))))
ECOND

CL-USER 91 > (econd
((= 3 4) "foo")
((= 4 4) "bar"))
"bar"

CL-USER 92 > (econd
((= 3 4) "foo")
((= 4 5) "bar"))

Error: fell through ECOND form. could not satisfy any of the following:
(= 3 4)
(= 4 5)

1 (abort) Return to level 0.
2 Return to top loop level 0.

Type :b for backtrace, :c <option number> to proceed, or for other
options


--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")