all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: why are there [v e c t o r s] in Lisp?
Date: Fri, 16 Oct 2015 07:16:08 +0200	[thread overview]
Message-ID: <871tcve6lj.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: mailman.434.1444970033.7904.help-gnu-emacs@gnu.org

Random832 <random832@fastmail.com> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> Random832 <random832@fastmail.com> writes:
>>> Well, what happens if you cdr that list? Does it make a
>>> copy? 
>>
>> cdr'ing is no problem you just increment your pointer.
>>
>>> 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")
>>
>> It's rplacd which becomes much more complex.
>
> You didn't mention my issue with "list of 5000 elements, cdr
> 4000 times" - does the garbage collector know to discard the
> first 4000 elements which are no longer reachable?

Well, I don't know if the implementations that had cdr-coding could
collect the prefix of the vector of cars that wasn't referenced anymore.
It's a little complexity for the garbage collector, but not too hard to
implement. The problem is more when you want to discard the 1 element
which is no longer reachable: this becomes quite costly.


>> Also, when you program with such a system, you might be afraid that
>> rplacd leads to fragmented chains, and will have a tendency to call
>> copy-list to compact them.
>
> Hmm... can the garbage collector compact them?

Compacting lists at garbage collection time is indeed a good idea, when
you have cdr-coding.  On the other hand, I believe the implementations
that had cdr-coding had a simple mark-and-sweap garbage collector, not a
copying one.  Some archeology would be in order there.


>>  But indeed, copy-list means that less
>> structure is shared, and therefore would waste time and memory.  This is
>> what they do in C++ and why they believe lists are costly.
>
> Also with this kind of list I think you still lose the
> ability to have constant-time indexing, since you have to
> check every cell for the cdr bit.

Of course.  Worse, to have O(1) indexing, you'd need to know the length
in advance, and this is what is killing, you cannot have an efficient
length when you have mutation and structure sharing.  rplacd would have
to update an unbound number of length slots.




However, it is possible to have a compiler that will map lists to
vectors in the generated code, as long as this compiler is able to
perform global analysis to ensure the semantics.  With global analysis,
you can easily determine whether there is structure sharing, whether
rplaca is used, and determine the length of the list at compilation time
or know to store it.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk


  parent reply	other threads:[~2015-10-16  5:16 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
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 [this message]
     [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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871tcve6lj.fsf@kuiper.lan.informatimago.com \
    --to=pjb@informatimago.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.