On Sun, Oct 23, 2011 at 5:04 PM, Andre van Tonder <andre@het.brown.edu> 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@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
