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)

Re: [Scheme-reports] Legacy caar to cddddr Ray Dillinger 24 Oct 2011 21:30 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