[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] 6.3.7 blobs
- To: Andy Wingo <wingo@x>
- Subject: Re: [Scheme-reports] 6.3.7 blobs
- From: John Cowan <cowan@x>
- Date: Sun, 22 May 2011 13:53:30 -0400
- Cc: scheme-reports <scheme-reports@x>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <20110521222154.GK10881@mercury.ccil.org> <firstname.lastname@example.org>
Andy Wingo scripsit:
> John! Here I was certain you would agree, like with make-vector and
See the post I just sent about blobs vs. byte vectors. A byte vector
constructor should have a fill argument, a blob constructor should not
(because blobs are typeless).
> For example, let's say I provide a primitive implementing the mmap
> syscall, and have it return a blob. Perhaps I would like to expose a
> range of that memory to a procedure, and allow it to set the memory.
> I want a shared-state sub-blob, but "sub" really doesn't combine well
> with "blob". Dunno!
I originally used "subblob" instead of "partial-blob-copy", creating a
disjoint blob in the manner of substring, but I decided the word was too
ugly. Indeed, the reason blob-copy and partial-blob-copy are distinct
is that copy-string and substring are distinct, though obviously they
could have been unified too.
If I wanted shared objects, I'd go with substring/shared (per SRFI 13,
which permits implementations to return a shared substring but does not
require it) and partial-blob/shared.
Yes, chili in the eye is bad, but so is your John Cowan
ear. However, I would suggest you wash your cowan@x
hands thoroughly before going to the toilet. http://www.ccil.org/~cowan
Scheme-reports mailing list