Re: [Scheme-reports] Legacy caar to cddddr

[Alex Shinn <alexshinn@x>]

On Sun, Oct 23, 2011 at 5:04 PM, Andre van Tonder <andre@x> wrote:
>
> Maybe for a virgin programmer, but they don't make things clearer to someone
> who is used to the C*R deconstructors (e.g., anyone familiar with Scheme or

Names matter.  New programmers, and people coming from
other languages matter.  All else being equal to experienced
Schemers, we should pick what makes the most sense for
others.  Scheme did a good job cleaning up a lot of names
from Lisp, and it would be nice to remove the few remaining
warts.

> LISP).  Anyone who has programmed macros in this style knows that every
> additional argument in the descent simply needs another D, etc.
> SECOND, THIRD, LIST-TAIL, etc., very much lack the elegance and conciseness
> of the C*R notation.  For example, should the argument of LIST-TAIL should
> be 3 or 4?

So you're saying you can count the number of d's faster
than you can read the character 3 or 4?

> Also lost is the nice algebra of the letters internal to C*R -
> for example if I changed the syntax of the macro example by
> inserting a new parameter all I would need to do to everything
> after that element is to insert an additional D before the R - it
> is MUCH cleaner and less work to change CADR to CADDR, CADDR to
> CADDDR, than the more awkward changing of SECOND to THIRD and
> THIRD to FOURTH, etc.

And it's even less work to use pattern matching, where you just
insert the new parameter and don't have to rewrite anything.

> Another example shows their use in small graph structures: e.g., in CDADADR,
> the list of symbols DADAD describes a descent path in a binary tree at a
> glance.

I'm actually not concerned so much whether you call
it `cadr' and `caddr' or `second' and `third', but this I
find disturbing.  `cdadadr' means nothing to me, and
looks likely to throw inscrutable error messages when
used incorrectly.  Do you have a program that uses it?
I can trace through it mentally, perhaps faster than I care
to admit through years of programming in that style, but
why trace at all when pattern matching lets you see at
a glance?

This reminds me of Forth programmers insisting that
they're used to stack operations, and it takes no effort
at all to keep track of the stack in their head.  I believe
them.  I also think I'd rather focus on the real problem
than spend any time at all calculating, no matter how
trivial it has become for me.

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports