RE: Array interface refactoring
On 23 February 2006 01:24, John Meacham wrote:
On Wed, Feb 22, 2006 at 06:47:19PM +0000, 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 resizable arrays.
Indeed. this has bothered me a whole lot too. I keep on trying to implement an expanding circular buffer and then being sad when it can't be done.
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 rather than bounds. since they are all already in the monad this will work just fine.
it would be almost perfectly backwards compatable, the only change would be some code might need to list HasBounds in their type signatures seperatly. If we can get this in before the next release of ghc that would be really great.
I've added a ticket, scheduled for 6.6. Cheers, Simon
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 rather than bounds. since they are all already in the monad this will work just fine.
it would be almost perfectly backwards compatable, the only change would be some code might need to list HasBounds in their type signatures seperatly. If we can get this in before the next release of ghc that would be really great.
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 implementation. then anyone who implemented resizable arrays will get possibility to make them an instance of MArray class. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
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 implementation. then anyone who implemented resizable arrays will get possibility to make them an instance of MArray class.
That is the plan. none of the current Array implementations will change, they will still be instances of both MArray and HasBounds. it is just that HasBounds will no longer be a superclass of MArray, however that doesn't affect performance in any appreciable way. (and array operations pretty much always end up specialized anyway so all class overhead disapears.) John -- John Meacham - ⑆repetae.net⑆john⑈
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 doesn't affect performance in any appreciable way. our plans are equal :) JM> (and array JM> operations pretty much always end up specialized anyway so all class JM> overhead disapears.) this depends. IArray/MArray interfaces currently contains only a few operations and all other implemented in fixed manner, so you can't omit any overheads -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 23/02/06, Bulat Ziganshin
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 doesn't affect performance in any appreciable way.
our plans are equal :)
JM> (and array JM> operations pretty much always end up specialized anyway so all class JM> overhead disapears.)
this depends. IArray/MArray interfaces currently contains only a few operations and all other implemented in fixed manner, so you can't omit any overheads
Well, there's always RULES pragmas. I can see that freeze and thaw get rewritten in some cases, there's also a bunch for listArray. - Cale
participants (4)
-
Bulat Ziganshin -
Cale Gibbard -
John Meacham -
Simon Marlow