unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: review/merge request: wip-array-refactor
Date: Wed, 29 Jul 2009 00:41:28 +0200	[thread overview]
Message-ID: <m363dcsa5j.fsf@pobox.com> (raw)
In-Reply-To: <874ot48k4h.fsf@arudy.ossau.uklinux.net> (Neil Jerram's message of "Wed, 22 Jul 2009 22:48:14 +0100")

Hi Neil,

Thanks for the review.

On Wed 22 Jul 2009 23:48, Neil Jerram <neil@ossau.uklinux.net> writes:

> I have two overall questions in mind.
>
> - What do you have in mind as regards releasing this?  Even though it
>   looks good, I think it would be better to let it mature for a while,
>   and hence not to put it into 1.9.x/2.0.  (And we're not short of new
>   stuff in 1.9.x/2.0!)

Personally I would prefer that it come out in 2.0. I'm fairly (but not
entirely) confident of its consistency as it is, and quite confident
that it is a more maintainable, and hence fixable, codebase.

The reason that I want it in is that bytevectors are a nice api for I/O,
but once you have data in memory, often it's best to treat it as a
uniform array -- be it of u8 color components, or s32 audio samples.

Uniform vectors are almost by nature "in flight" between two places. But
it is the bytevector that is most equipped to "fly", via e.g. (rnrs io
ports); but bytevectors do not provide an ideal API for manipulation.
s32vector-ref is a better API than bytevector-s32-native-ref, if only
that the offset of the former is in native units (s32 elements), and of
the second in bytes.

I guess what I wanted to do was break uniform vectors out of their type
ghettoes. Like Perlis said, "Pascal is for building pyramids --
imposing, breathtaking, static structures built by armies pushing heavy
blocks into place. Lisp is for building organisms -- imposing,
breathtaking, dynamic structures built by squads fitting fluctuating
myriads of simpler organisms into place." I should be able to put a
64-bit float into two 32-bit words, when I'm writing an instruction
sequence for a 32-bit machine, without having to change my data type --
they are just bytes anyway.

> - What about the header file incompatibilities?  I.e. the problem that
>   if there are applications out that that #include <libguile/ramap.h>,
>   or another of the renamed ones, they will stop working.  Do you
>   think we are OK just to document this well, or should we do more
>   than that?

I thought that our only support API was that provided by #include
<libguile.h>.

We can add back compatibility header files if necessary. Do you think it
is necessary?

>> The only bits I could anticipate being controversial would be the last
>> two or three patches, in which bytevectors are given an "element type"
>> field. This is so that I can make the srfi-4 uniform vector code use
>> bytevectors as their representation -- it's one less orthogonal type
>> that the VM would have to deal with.
>>
>> Those patches also allow uniform vectors of one type to be accessed
>> using accessors for other types:
>>
> What is the detailed rationale for [the following examples]?

>>   (u8vector-ref #u32(#xffffffff) 0) => 255

I ought to be able to get at the bits of a packed (uniform) vector. The
whole point of being a uniform vector is to specify a certain bit layout
of your data.

>>   (u8vector? #u32(#xffffffff)) => #f

However, we need to preserve type dispatch:

  (cond
    ((u8vector? x) ...)
    ((s8vector? x) ...)
    ...)

>>   (bytevector? #u32(#xffffffff)) => #t

This to me is like allowing (integer? 1) and (integer? 1.0); in
/essence/ a #u32 is an array of bytes, interpreted in a certain way. In
practice, one might use real? / complex? / integer? / etc to distinguish
elements of the numeric tower; in this case we have a short tower:
uniform vectors are bytevectors.

>> commit 86d88a223c64276e7cd9b4503e7e2ecca5aae320
>> Author: Andy Wingo <wingo@pobox.com>
>> Date:   Thu Jul 16 21:51:47 2009 +0200
>>
>>     remove deprecated functions from unif.c
>>     
>>     * libguile/unif.h:
>>     * libguile/unif.c: Remove deprecated functions.
>>     
>>     * module/ice-9/deprecated.scm: Remove array-related deprecated
>>       functions.
>>     
>>     * NEWS: Update.
>
> I can understand why a lot of the NEWS deltas evaporate when they are
> logically merged into the 1.8-2.0 section, but I'm not sure about
>
> - the entry for Brainfuck
>
> - the entry on scm_set_port_seek and scm_set_port_truncate
>
> Aren't these entries still of interest?
>
> The rest of this commit looks fine.

Yes they are. Good catch.

I'll finish this response, and the response to Ludovic, later -- but I
wanted to get out the rationale now. Thanks again for the review!

Andy

-- 
http://wingolog.org/




  reply	other threads:[~2009-07-28 22:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-19 13:59 review/merge request: wip-array-refactor Andy Wingo
2009-07-22 21:48 ` Neil Jerram
2009-07-28 22:41   ` Andy Wingo [this message]
2009-07-30 21:10     ` Neil Jerram
2009-08-04 12:21       ` Andy Wingo
2009-08-09 16:41         ` Ludovic Courtès
2009-08-12 22:03           ` Andy Wingo
2009-08-13  9:16             ` Ludovic Courtès
2009-07-23 21:08 ` Ludovic Courtès
2009-07-24 22:01   ` Neil Jerram

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/guile/

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

  git send-email \
    --in-reply-to=m363dcsa5j.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    /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).