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. Last
Daniel Llorens daniel.llor...@bluewin.ch 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
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 why
Date: Fri, 12 Apr 2013 17:43:14 -0400
From: Mark H Weaver m...@netris.org
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
On 15 April 2013 19:29, Daniel Llorens daniel.llor...@bluewin.ch 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
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 functions
On 15 April 2013 22:08, Daniel Llorens daniel.llor...@bluewin.ch 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
Daniel Llorens daniel.llor...@bluewin.ch writes:
Date: Fri, 12 Apr 2013 17:43:14 -0400
From: Mark H Weaver m...@netris.org
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
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 vector-like
On Apr 12, 2013, at 01:53, Daniel Hartwig wrote:
On 11 April 2013 07:07, Daniel Llorens daniel.llor...@bluewin.ch 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
On 12 April 2013 15:23, Daniel Llorens daniel.llor...@bluewin.ch 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
On 12 April 2013 18:15, Daniel Hartwig mand...@gmail.com 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.
Message: 8
Date: Fri, 12 Apr 2013 18:15:05 +0800
From: Daniel Hartwig mand...@gmail.com
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
On 12 April 2013 20:37, Daniel Llorens daniel.llor...@bluewin.ch 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
Daniel Hartwig mand...@gmail.com writes:
On 12 April 2013 15:23, Daniel Llorens daniel.llor...@bluewin.ch 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
Date: Fri, 12 Apr 2013 22:06:38 +0800
From: Daniel Hartwig mand...@gmail.com
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
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.
On 11 April 2013 07:07, Daniel Llorens daniel.llor...@bluewin.ch 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
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.
19 matches
Mail list logo
