On 23/02/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello John,
>
> Thursday, February 23, 2006, 4:07:52 PM, you wrote:
>
> JM> That is the plan. none of the current Array implementations will
> JM> change, they will still be instances of both MArray and HasBounds. it is
> JM> just that HasBo
Hello John,
Thursday, February 23, 2006, 4:07:52 PM, you wrote:
JM> That is the plan. none of the current Array implementations will
JM> change, they will still be instances of both MArray and HasBounds. it is
JM> just that HasBounds will no longer be a superclass of MArray, however
JM> that does
On Thu, Feb 23, 2006 at 03:26:56PM +0300, Bulat Ziganshin wrote:
> SM> I've added a ticket, scheduled for 6.6.
>
> i just want to mention that current implementation is faster than this
> general one and enough for most of usages. so it will be great to make
> more general interface but use old im
Hello Simon,
Thursday, February 23, 2006, 1:56:03 PM, you wrote:
>> We could fix it fairly easily, we just need to get rid of HasBounds
>> as a superclass of MArray and add a new method 'getBounds' that
>> returns the bounds in the monad and then modify the default methods
>> to use getBounds rat
On 23 February 2006 01:24, John Meacham wrote:
> On Wed, Feb 22, 2006 at 06:47:19PM +, Ben Rudiak-Gould wrote:
>> While we're on the topic, I have a couple of problems with the
>> current array system that cut deeper than the naming:
>>
>> * The function for getting the bounds of an MArra
On Wed, Feb 22, 2006 at 06:47:19PM +, Ben Rudiak-Gould wrote:
> While we're on the topic, I have a couple of problems with the current
> array system that cut deeper than the naming:
>
> * The function for getting the bounds of an MArray is pure, so the
> interface can't accommodate
Hello Ben,
Wednesday, February 22, 2006, 9:47:19 PM, you wrote:
BRG> While we're on the topic, I have a couple of problems with the current
array
BRG> system that cut deeper than the naming:
BRG> * The function for getting the bounds of an MArray is pure, so the
BRG>interface can't
While we're on the topic, I have a couple of problems with the current array
system that cut deeper than the naming:
* The function for getting the bounds of an MArray is pure, so the
interface can't accommodate resizable arrays.
* unsafeAt, unsafeRead and unsafeWrite take 0-based
On Wed, Feb 22, 2006 at 09:59:07AM -0800, Alson Kemp wrote:
> >With unsafeWrite you can write to any address in
> >memory, so
> >you can crash the program
> hmm... If I put an incorrect index into
> IArray.write, Ix.index errors and the program
> exits/dies/crashes (without SEGV). This doesn'
> Bruce Stewart wrote:
> > And unsafeRead/unsafeWrite are too verbose. They
> are usually (almost
> > always?) safe (since the code does its own
> checks),
>
> The same can be said about most uses of
> unsafePerformIO - you wouldn't
> be using it if you weren't certain that your program
> will beh
Bulat,
> SPJ> Library design is certainly part of the
> Haskell' process, as I
> SPJ> understand it. And the refactoring you
> describe sounds sensible and
> SPJ> desirable. What it needs is someone willing to
> take up the cudgels and
> SPJ> do it. Library design takes real work.
>
> i can ta
On 22 February 2006 09:48, Donald Bruce Stewart wrote:
> It's not a terribly serious suggestion ;)
>
> I just found that using unsafeRead/Write is very important for
> shootout entries (we used it a lot -- it's the only way to beat C),
> but a lot uglier on the page than (the equally dangerous) p
Hello Simon,
Wednesday, February 22, 2006, 1:05:11 PM, you wrote:
SPJ> Library design is certainly part of the Haskell' process, as I
SPJ> understand it. And the refactoring you describe sounds sensible and
SPJ> desirable. What it needs is someone willing to take up the cudgels and
SPJ> do it.
| Perhaps this e-mail could be read more generally as a
| request to consistencify/update the (Data) libraries
| in general
...
|
| Is this possible for Haskell'? Or is this too much
| of a break? If it's possible, I'm happy to build a
| wiki page for discussion (I noticed that a short page
|
tomasz.zielonka:
> On Wed, Feb 22, 2006 at 03:39:48PM +1100, Donald Bruce Stewart wrote:
> > And unsafeRead/unsafeWrite are too verbose. They are usually (almost
> > always?) safe (since the code does its own checks),
>
> The same can be said about most uses of unsafePerformIO - you wouldn't
> be
On Wed, Feb 22, 2006 at 03:39:48PM +1100, Donald Bruce Stewart wrote:
> And unsafeRead/unsafeWrite are too verbose. They are usually (almost
> always?) safe (since the code does its own checks),
The same can be said about most uses of unsafePerformIO - you wouldn't
be using it if you weren't certa
alson:
> We had a short discussion on the IRC channel the other
> day about Arrays. I advocated that we do some
> refactoring work and didn't meet with overwhelming
> disagreement, so I wanted to propose that the Arrays
> interfaces be refactored in Haskell'.
>
> As a Haskell new-ish-bie, the var
We had a short discussion on the IRC channel the other
day about Arrays. I advocated that we do some
refactoring work and didn't meet with overwhelming
disagreement, so I wanted to propose that the Arrays
interfaces be refactored in Haskell'.
As a Haskell new-ish-bie, the various Array interfaces
18 matches
Mail list logo
