guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: subbytevectors


From: Andy Wingo
Subject: Re: subbytevectors
Date: Sat, 09 Jun 2012 19:07:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hello,

On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen <address@hidden> writes:

> If you want to make a case for such a facility, why not
> show some code, both without (status quo) and with (proposed)?
> It should be clear what expressiveness is gained, and how.

For example, let's say I mmap a big file.

  (define x (mmap-file "/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so"))

I did some computation and have figured out that there is a region of
interest between bytes 121241 and 121263 that interests me.  I would
like to be able to pass off that region to some other piece of code,
without giving it access to the entire bytevector.  I would also like to
be able to pass around  

> Guile 1.4.x has ‘make-shared-substring’

Guile 1.8, released in 2005, has substring/shared.  So does Guile 2.0.
IIRC -- and this was a looooooooong time ago -- Marius wanted to remove
it, for ease of implementation, but users were using it, so he had to
put it back in.

Strings and bytevectors are fundamentally different, though.

> IIRC, SRFI 13 suggests that its support for substrings would
> not be necessary if programmers wrote code using "range" style.
> Could the client code you have in mind be rephrased like that?

These are complementary strategies.  Using ranges is usually more
efficient, but more at times it is too cumbersome.  Sometimes also you
really want to restrict authority to only a certain window of the
bytevector.

For example, I am currently working on a problem that involves lots of
work on a shared bytevector.  I have to be careful to avoid printing out
the bytevector because it takes a few seconds and trashes my terminal
history.  If I had subbytevectors, this wouldn't be as acute a problem.

Andy
-- 
http://wingolog.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]