On Mon, Apr 15, 2013 at 10:00:55PM -0400, Mark H Weaver wrote:
> Unfortunately, this is rarely possible in a language like Scheme, where
> calls to procedures bound by mutable top-level variables are frequent.
> We cannot fix this without making most commonly-used top-level bindings
> immutable. L
On Apr 16, 2013, at 08:19, Mark H Weaver wrote:
> Yes, I did, and generally I strongly prefer column [1], but we have to
> be very careful what changes we make in a stable release series that
> might break compatibility with existing code. I find this frustrating
> as well, which is one reason w
Daniel Llorens writes:
> On Apr 16, 2013, at 04:00, Mark H Weaver wrote:
>
>>> [1] have vector- ops only accept vector- types. This removes container
>>> type dispatch from the vector- ops but not from the array- ops. The
>>> last patch set I've sent to the list goes in this direction. It
>>> mat
On Apr 16, 2013, at 04:00, Mark H Weaver wrote:
>> [1] have vector- ops only accept vector- types. This removes container
>> type dispatch from the vector- ops but not from the array- ops. The
>> last patch set I've sent to the list goes in this direction. It
>> matches the behavior of other vect
Daniel Llorens writes:
> Date: Fri, 12 Apr 2013 17:43:14 -0400
> From: Mark H Weaver
>
>> I've not yet had time to carefully read this thread, but I wanted to say
>> that I think we *should* prohibit passing arrays to the vector
>> interfaces. When we have native code generation, then it will b
On 15 April 2013 22:08, Daniel Llorens wrote:
>
> On Apr 15, 2013, at 14:28, Daniel Hartwig wrote:
>
>> Is it
>> really much faster to do one or the other:
>>
>> if lbnd != 0: error
>> index = …
>>
>> vs:
>>
>> index = lbnd + ...
>
> The second should actually be just
>
> index = ...
>
> You do th
On Apr 15, 2013, at 14:28, Daniel Hartwig wrote:
> Though such an array is potentially still a vector according to the simple
> explanation in the manual. So this requires introducing a more
> complicated discussion of when is an array a vector.
Not really. One just needs to say 'these function
On 15 April 2013 19:29, Daniel Llorens wrote:
>
> [1] have vector- ops only accept vector- types. …
>
> [2] force all vector objects into arrays. …
>
> For example in [1], you'd prefer vector- to *reject* strided rank-1 arrays
> (inc!=1), because those require a descriptor and you want to limit yo
Date: Fri, 12 Apr 2013 17:43:14 -0400
From: Mark H Weaver
> I've not yet had time to carefully read this thread, but I wanted to say
> that I think we *should* prohibit passing arrays to the vector
> interfaces. When we have native code generation, then it will be
> possible to make the vector
Date: Fri, 12 Apr 2013 22:06:38 +0800
From: Daniel Hartwig
> Great. This strikes a nice balance, with simple enough semantics
> and flexability to massage array data for vector-coded modules.
> I doubt _anyone_ will miss using non-0-indexed arrays that way.
I personally think that offset index
Daniel Hartwig writes:
> On 12 April 2013 15:23, Daniel Llorens wrote:
>>
>> However my proposal is also to produce the same type error when
>> the argument is a rank-1 array with base!=0 or inc!=1. These
>> may be indexed from 0, but can only be produced by using the
>> array interface, and use
On 12 April 2013 20:37, Daniel Llorens wrote:
[Tail first:]
> After [0], I'm open on allowing general, 0-indexed, rank-1
> arrays to the vector- functions, but I'll send the patches
> anyway that forbid this. The tests all pass (which maybe shows
> how poor the coverage is).
>
Great. This stri
Message: 8
Date: Fri, 12 Apr 2013 18:15:05 +0800
From: Daniel Hartwig
> Too restrictive IMO, you may as
> well just not permit any array passed to vector
> interfaces.
Being restrictive would be my preference, yes.
> [Besides, you can already get at the underlying vector
> using ?shared-array-
On 12 April 2013 18:15, Daniel Hartwig wrote:
> From your original mail:
>> a. the array implementation can rely on all [vector] types
>> having known base=0 and inc=1.
>
> Is that not already the case?
>
Ah right, not when ‘vector?’ answers #t to compatible arrays.
On 12 April 2013 15:23, Daniel Llorens wrote:
>
> Right. I want [0]
>
> (vector-ref #@1(1 2 3 4) 1) => 2
>
> to fail with a type error, which is consistent with r5rs.
>
Ah. I should have read more the later part of your mail.
> However my proposal is also to produce the same type error when
> t
On Apr 12, 2013, at 01:53, Daniel Hartwig wrote:
> On 11 April 2013 07:07, Daniel Llorens wrote:
>>
>> After the array-map patches, I've gone through the vector/array
>> implementation and there's some stuff I'd like to fix. In stable-2.0 today:
>>
>> (define a (make-typed-array ''f64 0 '(1 2
On 11 April 2013 07:07, Daniel Llorens wrote:
>
> After the array-map patches, I've gone through the vector/array
> implementation and there's some stuff I'd like to fix. In stable-2.0 today:
>
> (define a (make-typed-array ''f64 0 '(1 2))
> a
> => #1f64@1(0.0 0.0)
>
> so far so good.
>
> (unifor
On Apr 11, 2013, at 01:07, Daniel Llorens wrote:
> Force, and assume, inc and base to be 1 & 0 for uniform-vector /
> [srfi4type]vector / vector.
Correction: inc, base and lbnd to be 1, 0 and 0 is what I mean.
After the array-map patches, I've gone through the vector/array implementation
and there's some stuff I'd like to fix. In stable-2.0 today:
(define a (make-typed-array ''f64 0 '(1 2))
a
=> #1f64@1(0.0 0.0)
so far so good.
(uniform-vector? a)
=> #t
(f64vector-ref? a)
=> #t
so far so good.
(u
19 matches
Mail list logo
