Re: [Scheme-reports] Legacy caar to cddddr
Aubrey Jaffer
(23 Oct 2011 22:50 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Alex Shinn
(24 Oct 2011 14:09 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Aubrey Jaffer
(24 Oct 2011 16:02 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
John Cowan
(24 Oct 2011 21:17 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Alex Shinn
(24 Oct 2011 23:58 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Andre van Tonder
(24 Oct 2011 16:04 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Alaric Snell-Pym
(24 Oct 2011 16:09 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
Alex Shinn
(25 Oct 2011 00:07 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
John Cowan
(24 Oct 2011 17:02 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr Ray Dillinger (24 Oct 2011 21:30 UTC)
|
Re: [Scheme-reports] Legacy caar to cddddr
John Cowan
(24 Oct 2011 21:51 UTC)
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/24/2011 07:08 AM, Alex Shinn wrote: > I'd be interested to see real-world examples of (set-car! (c[ad]{3,}r x) y). > My guess is these are examples of abusing lists as records. I am not convinced that using lists (more generally, trees) as records is in fact an abuse. With trees you can easily do some kinds of things that simple records cannot as easily do. Serialization has been mentioned, but application, execution, extension, collation, flattening, etc, are also in this category. There are some types of aggregate data where native support for those operations is useful, or at least convenient, and therefore a decision to represent those aggregates as trees is not an abuse. Prominent amongst the kinds of data where trees are the most useful and reasonable expression is program source code, which is easily and simply handled in macros by these operations. Alternatives such as destructuring, while syntactically more elegant for manipulating source code, cannot replace these procedures completely because they are not applicable in other contexts and have not so far shown extensions or implementation that gives them equivalent flexibility, particularly with respect to mutation. Alternative naming schemes, such as "first, second, third ....", while perhaps simpler to explain to a new learner, cannot fully replace these procedures because they are strictly list accessors and useless for working with more general trees. It's my opinion that keeping all of the procedures c(a|d){1,4}r is not harmful and not a burden on implementors, and that doing otherwise constitutes a completely unwarranted and undesirable change in the standard. Bear -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOpdjrAAoJEAOzWkqOibfNHNgIAIe2RlLA7YYwWUz/kQtmail+ kz1o67p7CdXkIAQi7TWNMkA2p2O3eV5QTfovdMbiaABYjX+6WtlOLfNnIU+bbHDM 2tyJ/xOiVD1utuG3kqUNV6g0qqBsICYbEaZeDgufunuTe/xhg3LNb0xkmD4iGShn 2J8pPM9YfiSRqMjU5eVL93eMqVlpmDq+A1/6RFQDxbDaUo+ZrmgjGZ6HHjDbQ87T UyIaWM0AOo8hhD01bLRKjms/nBm5QblYu+fCWGuT0jmwiLvvVpm+zK3R1cE9DbuY sreHDKT10iK1yR9xwkY1GwuGMshl7iWXYVZmvDlpdqEsDo/nzp3xMwyzdhN5wXc= =4Kfz -----END PGP SIGNATURE----- _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports