From: Random832 <random832@fastmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: why are there [v e c t o r s] in Lisp?
Date: Thu, 15 Oct 2015 22:56:27 -0400 [thread overview]
Message-ID: <87io67zfl0.fsf@fastmail.com> (raw)
In-Reply-To: 87d1wfplu5.fsf@debian.uxu
Emanuel Berg <embe8573@student.uu.se> writes:
> If a list just contains say a bunch of known integers
> that don't need to be computed, is there anything that
> stops this list from being stored in "contiguous
> memory" with the list functions as well as the
> constant access time "vector" functions available?
Well, what happens if you cdr that list? Does it make a
copy? Wasted memory, wasted time, won't track if you change
the original. Yeah, yeah, in platonic ideal lisp you *can't*
change lists, but this is the real world, where even scheme
lets you do it. Does it keep a reference to the original
list? Then what if you take the cd^{4000}r of a list of
5000, then throw away the original? Wasted memory
again. Java used to have this issue with strings. I suppose
you could have the underlying array somehow know what the
earliest index that a reference actually exists for is, and
magically throw away everything before it during garbage
collection, if there's too much wasted space. But that seems
rather a lot of work.
> By the way: in my previous post strings were mentioned
> and it sounded like they were sugar for lists of chars
> - this isn't the case (you can't `car' a string) but
> it could have been and it isn't harmful (I think) to
> think of strings that way.
The thing is, if you can car a string people will wonder why
you can't cdr it. And with mutable objects it's hard to make
cdr work right. (fsvo "right")
next prev parent reply other threads:[~2015-10-16 2:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.428.1444957396.7904.help-gnu-emacs@gnu.org>
2015-10-16 1:51 ` why are there [v e c t o r s] in Lisp? Pascal J. Bourguignon
2015-10-16 2:31 ` Emanuel Berg
2015-10-16 2:29 ` Random832
2015-10-16 2:51 ` Emanuel Berg
2015-10-16 2:56 ` Random832 [this message]
2015-10-16 23:30 ` Emanuel Berg
[not found] ` <mailman.482.1445037713.7904.help-gnu-emacs@gnu.org>
2015-10-17 1:55 ` Pascal J. Bourguignon
2015-10-17 4:47 ` Emanuel Berg
[not found] ` <mailman.494.1445057637.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:25 ` Pascal J. Bourguignon
2015-10-17 21:12 ` Emanuel Berg
[not found] ` <mailman.519.1445115776.7904.help-gnu-emacs@gnu.org>
2015-10-18 1:08 ` Pascal J. Bourguignon
[not found] ` <mailman.432.1444964227.7904.help-gnu-emacs@gnu.org>
2015-10-16 3:57 ` Pascal J. Bourguignon
2015-10-16 4:17 ` Random832
[not found] ` <mailman.434.1444970033.7904.help-gnu-emacs@gnu.org>
2015-10-16 5:16 ` Pascal J. Bourguignon
[not found] ` <mailman.429.1444962165.7904.help-gnu-emacs@gnu.org>
2015-10-16 3:31 ` Pascal J. Bourguignon
2015-10-16 23:46 ` Emanuel Berg
[not found] ` <mailman.483.1445038647.7904.help-gnu-emacs@gnu.org>
2015-10-17 2:04 ` Pascal J. Bourguignon
2015-10-17 4:40 ` Random832
2015-10-17 5:00 ` Emanuel Berg
2015-10-17 4:40 ` Emanuel Berg
[not found] ` <mailman.491.1445056308.7904.help-gnu-emacs@gnu.org>
2015-10-17 5:53 ` Barry Margolin
2015-10-17 15:16 ` Pascal J. Bourguignon
2015-10-17 21:06 ` Emanuel Berg
[not found] ` <mailman.518.1445115463.7904.help-gnu-emacs@gnu.org>
2015-10-18 1:07 ` Pascal J. Bourguignon
2015-10-18 12:32 ` Emanuel Berg
[not found] ` <mailman.551.1445171034.7904.help-gnu-emacs@gnu.org>
2015-10-18 12:55 ` Pascal J. Bourguignon
2015-10-18 14:28 ` Emanuel Berg
2015-10-18 21:17 ` Robert Thorpe
[not found] ` <mailman.557.1445177952.7904.help-gnu-emacs@gnu.org>
2015-10-18 19:48 ` Barry Margolin
2015-10-18 21:25 ` Emanuel Berg
2015-10-18 21:39 ` Random832
2015-10-19 0:46 ` Pascal J. Bourguignon
2015-10-17 5:56 ` Barry Margolin
2015-10-17 15:06 ` Emanuel Berg
2015-10-16 13:32 ` Barry Margolin
2015-10-16 23:47 ` Emanuel Berg
[not found] <mailman.581.1445203060.7904.help-gnu-emacs@gnu.org>
2015-10-19 0:45 ` Pascal J. Bourguignon
2015-10-16 1:12 Emanuel Berg
2015-10-17 1:11 ` Aurélien Aptel
2015-10-17 4:22 ` Emanuel Berg
2015-10-17 7:58 ` Jude DaShiell
2015-10-19 16:33 ` Nick Dokos
[not found] ` <mailman.490.1445055179.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:09 ` Pascal J. Bourguignon
[not found] ` <mailman.488.1445044303.7904.help-gnu-emacs@gnu.org>
2015-10-17 2:22 ` Pascal J. Bourguignon
2015-10-17 4:56 ` Emanuel Berg
2015-10-17 5:49 ` Barry Margolin
2015-10-17 15:04 ` Emanuel Berg
[not found] ` <mailman.506.1445093727.7904.help-gnu-emacs@gnu.org>
2015-10-17 15:20 ` Pascal J. Bourguignon
2015-10-17 15:38 ` Emanuel Berg
[not found] ` <mailman.511.1445095810.7904.help-gnu-emacs@gnu.org>
2015-10-17 16:01 ` Javier
2015-10-17 16:03 ` Javier
2015-10-17 16:34 ` Pascal J. Bourguignon
2015-10-17 21:18 ` Emanuel Berg
2015-10-17 16:15 ` Pascal J. Bourguignon
2015-10-17 21:37 ` Emanuel Berg
2015-10-17 15:18 ` Pascal J. Bourguignon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87io67zfl0.fsf@fastmail.com \
--to=random832@fastmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).