- Rob.

  Let's _quote_ from some of Michael T. Richter's eloquence on display
  for all the world to see (well, that part of the world which thinks
  Dylan is all the world, anyway):

  In <6Qi85.18115$ZI2.545...@news1.rdc1.on.wave.home.com>, Michael
  T. Richter <m...@ottawa.com>, presumably the same _gentleman_, writes:

  "Hey fuckhead"

  Granted, it's two words and three syllables, which could imply that
  Michael T. Richter is anywhere between 50% and 100% more cogent than
  Dave Bakhash's "bogus", but since the first word is but a noise word
  to get attention, it isn't worth anything at all, which means we're
  dealing with a neanderthal who is very envious of humans.   Worse,
  yet, "bogus" is _way_ more cogent than "fuckhead", but then again,
  Dave is a Lisp user and Michael is a Dylan user, and we know what
  kind of people _they_ are: ...

| Yes, Lisp has its advantages.  Readability isn't one of them.

  ... hostile, illiterate bums who hate their parens, as this new
  evidence of eloquence and cogency shows so clearly.

- Rob.

  Please leave me out of your insanity, Rob.  Please ask your doctor
  to reconsider the suggestion to use USENET for therapeutic purposes.
  You just be calm, now.  You _don't_ need to hurt yourself, OK?  You
  can get through this stressful period safely.  Just take your anti-
  psychotic medication and try to stay away from challenges to your
  beliefs, and this will all be over in a couple days, OK?  If you try
  and avoid responding to me, you'll soon feel much better, too.

In article <39618db4$...@spamkiller.newsfeeds.com>,

(let*
 ((discriminant (- (* b b) (* 4 a c)))
  (numerator (- (sqrt discriminant) b))
  (denominator (* 2 a)))
 (/ numerator denominator))

  I'm so glad you asked.  Yes, of course, but I'm trying to learn
  about the Dylan ways by studying such fine gentlemen as yourself.
  Remember, languages shape the way we think, so in order to think
  like a Dylanite or whatever your neanderthal race is called, I must
  study how you perform in the big challenge that is life.  For Dylan
  users, specifically, random, unchecked assumption are perfectly OK,
  sweeping generalizations even better, and so naturally one has to
  deal with neanderthals such as your community on your own premises.

  You _surely_ can't mean that when a number of Dylanites prove to the
  world that when they make sweeping generalizations about others, and
  the _others_ object, they have _not_ communicated clearly that it is
  OK to apply sweeping generalizations to _themselves_?  I don't think
  very highly of the Dylan community, but the sheer inability to grasp
  that when you do something to others out of moral righteousness, it
  most certainly must be OK to apply it back to yourself is too much
  -- even I don't think _that_ badly of neanderthals morons.  And lest
  you object -- _you_ have most certainly proven beyond _any_ doubt
  that there's one law for you (Dylanites) and one law for everyone
  else, so I'm just trying to do the smallest things to accomodate you
  Dylanites.  Out of courtesy, you know -- _your_ kind of courtesy.

    for (double i = 0.0;  i < 1.0;  i += 0.1) {
        print(i);
    }

Except that in this case, the "=" means `initialize', not `assign', and it
turns out that they're different.  If you're trying to argue that it's
better to have visually distinctive syntax for operations with different
semantics, then C is certainly not the right language to hold up as an
example -- even if you're not trying to be an apologist for C.

Are you really concerned that there's an in-place increment of a variable,
or merely that the value of the variable increases over time?  If the
latter, then I would claim that having to specify "in-place increment"
merely clutters the code without adding anything of interest.

    (for (0 <= i < 1 :step 1/10)
      (print i))

(All sensible combinations of <, <=, >, >= are permitted, and the :step part
is optional.)  I actually really like this syntax; I find that it describes
what is going on far more clearly than any other syntax I've seen.

Alternatively, you could use the standard LOOP macro:

    (loop for i from 0 to 9/10 by 1/10 do
      (print (float i)))

Seems entirely readable to me.  (As an aside, note that this version does
actually give you the desired answer; using floating-point arithmetic is
probably a pretty bad idea here.)

To return to your initial point that visual cues are useful, and that Lisp
syntax provides fewer such cues than many other languages: I don't deny
either the utility of visual cues, or the fact that some Lisp forms may
overuse nested parentheses (DO being an example).  But Lisp's approach to
syntax, in which you can use macros and reader macros to alter what the
programmer sees, enables you to construct syntax that is convenient for what
you're doing.  Regarding DO in particular, my experience is that many if not
most uses of this form are actually hidden away in macros that relate to
some abstraction.  Though they needn't be implemented in terms of DO, the CL
macros DOLIST, DOTIMES, DO-SYMBOLS are good examples of what I mean.

What you need is not a pratice, just a decent editor.

abe

Also, a word on "bogus".  I use that word as a rather light-hearted
word.  I didn't mean to offend or denigrate anyone's opinions or
justifications; I mearly was expressing a *difference* of opinion, where
something that was an opinion seemed to be stated as if it were fact.
It seemed to me as if the poster was implying that it's a bad thing that
in CL you could define macros, and that they generally obfuscate the
language.  Well, no one says you have to write macros, unless you're
working alone, working on a Lisp project won't be too fun for you.

For readability by inexperienced humans, I don't think either
of these approaches comes close to

    (loop for i from 0 by 0.1 below 1.0 do
      (print i))

Some Lispers detest LOOP. I'm glad it's there, because it's
a great tool for expressing simple iterations simply. (Most
iterations are simple. Hairy ones are tricky to understand
whatever language you express them in.)

For slightly more complicated iterations, compare C's

    for (p=items; p; p=p->next) {
      do_something(p);
    }

with Lisp's

    (loop for item in items do
      (do-something p))

No comparison, I reckon.

Note that the Lisp versions also isolate the binding of the
loop variable to within the loop, which is usually what you
want. Doing that in C requires more braces and an extra
declaration.

Now, I know you're not primarily defending C. But if the issue
is the readability of C's iteration constructs versus that of
Lisp's, I think it's a one-way contest, and not in the direction
you're suggesting.

Some bits of C's syntax *are* much easier for the non-immersed
to grasp. For instance, I think assignments and arithmetic are
clearer in C than in Lisp, unless you have a little reader
macro that lets you write

    { x = (5 * y + 7) / (y + 3) }

(which isn't hard; there are such things out there and in the
public domain). On the other hand, I find that I never use them;
one gets used to the syntax of Lisp.

  for (int i = 0; i < MAX_SIZE; i++)
    do_something_with(i);

i is only within the scope of that loop.

But then I grew up on Interlisp, so maybe it's
a cultural thing.

But it's great that the different facilities are there.  It's not just
in Perl that "there's more than one way to do things".  =)

--

The real point, though, was that macros, properly used, are supposed to
clarify code on the whole, make it more readable, and easier to write.
The WITH-OPEN-FILE example from another thread illustrates this nicely.

One thing I must say about the readability, or unreadability of Lisp
code is that when you're diving into other people's heavy macrologies,
things can often get very difficult to read, and know what's going on.
If it all works, then it's usually okay.  But when you're debugging
other people's code, one often depends on macroexpansion to see what's
going on.  If macros are written correctly, well documented, and maybe
even show an example or two of usage, then what is to some a burden can
easily become a friendly tool.

The C "for" construct is _used as_ a looping construct; it is rather
better compared to DO, whether we're talking the Common Lisp DO, or
the Scheme DO.  

In either case, DO, just like C's "for," represents a primitive control
structure that doesn't really structure things very strongly.  You can
do virtually anything in the clauses, as opposed to the way that LOOP
supplies both name bindings _as well as control over what they do_.

C provides neither bindings nor control; you need to pre-declare your
variables, and manually set up the clauses to do "the right things."

DO provides bindings, but no control.  You have to manually set up the
clauses to do "the right things," namely initializing, incrementing, and
comparing.

In contrast,
     (loop for i from 0 by 0.1 below 1.0 do
       (print i))
shows that LOOP is supporting all three of these things:
-> It creates a binding for "i"
-> It supplies the code to increment and test i, based on a _description_
   of what is to be done to i.

There are two _major_ cases:
a) If you're doing a relatively simple loop, LOOP is pretty nice.

b) If you're doing a _really complex_ loop, LOOP is pretty nasty, but
   so are the alternatives.

It might be a Nice Thing to revisit LOOP, and make up a "cleaner"
design.  An ambitious person might want to show us what a "better
LOOP" might look like with a sample implementation.

All that's left is for you to prove me right about you having to have the
last word again, and you can go back to being the list Village Idiot.

Macros need to be *very* carefully tested and debugged before you build
anything on top of them, in my opinion.

--
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/