Re: LFM + LFSP = LFE?

[Marco Baringer <address@hidden>]

sorry if is kind of rantish, but people keep saying the same things
about macros and i just don't get it.

Robert Feldt <feldt@ce.chalmers.se> writes:

> Just found matz slides form his ll2 talk and his "bullet points" about
> syntax was:
> 
> * Syntax should be stable

argeed.

[i'd really have liked to hear someone say "syntax should be
transparent"...]

>     * Human brain is not good at handling multiple rules

wrong, the human brain is actualy really really good at handling
different rules, and at switching back and forth.

>        * Especially not if they change from place to place

i'd put it this way: the human brain is great at handling multiple
rules iff the change from place to place is well defined. i've never
confused a pub with an office and have no problems dealing with the
multiple rules of good manors. like wise i have no difficulty dealing
with the different rules of the loop macro and the do macro[1]

>     * Act against macros
>        * It's powerful, too powerful

WHAT KIND OF ARGUMENT IS "TOO POWERFUL"? 

"undefined", "non-deterministic", "violently unstable" are arguments
against something, not "too powerful." calling a tool too powerful is
like calling a job too satisfying or a woman too beautiful.

---

lisp's syntax has been stable for a long time:

'(' atom atom* ')'

thats it. (ok, so maybe this is a stretch, but not really).

a note to language designers: don't worry about the syntax, the syntax
is the easy part, it's the API which is hard. i think it took me about
5 minutes to figure out the difference between at atom and a list in
common lisp, but i still try to call gethash like (gethash hash key)
as opposed to (gethash key hash) (analogous things exist in every
useful and used library). why people keep saying poorly written macros
make code hard to read/maintain yet somehow a poorly written library
doesn't will always be a mystery to me.

macros are a well defined, structured way to clearly model and express
concepts in the program's source code which don't map well onto
existing constructs, or for which existing constructs don't exist (see
CLOS, CommonSQL, SCREAMER, LOOP, SERIES, keyword/rest/whole/optional
arguments).

macros make code EASIER to read! is that clear? EASIER! why? because
the code looks like whats in my head.

since when does everything has to be a method call or a function
application or a state machine? really, in all seriousness, who
planted this weed in the collective mind of the IT/CS field? some
things are declarative, some things are OO, some things are functional
applications and some thing are something else. Mr. Language Designer
(or Mr. Compiler Writer): who are you to decide how i should my
structure program? who are you to say my entire program should look a
method call or a sequence of gotos? and why should i have to pick?

i am now going to crawl back into my hole. have a nice day.

[none of this is to say i hate Ruby (i don't know anything about it)
or SmallTalk (i have a special part in my heart for SmallTalk, it was
my first real eye opening language) or that i think common lisp is the
answer to all my questions.]

---

[1] - i talk about LOOP and DO a few times. for those who don't know
what i'm doing, here's an example of what they look like.

to iterate over every element of an array and keep an index you'd do this
with LOOP:

(loop for element across array
      for index upfrom 0
      do (...))

and this with DO:

(do ((index 0 (1+ index))
     (element (aref array 0) (aref array i)))
    ((< i (length string)))
  (..))

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen