RE: Array interface refactoring

2006-02-22 Thread Simon Peyton-Jones
|  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
| has been started.)

Library design is certainly part of the Haskell' process, as I
understand it.  And the refactoring you describe sounds sensible and
desirable.  What it needs is someone willing to take up the cudgels and
do it.  Library design takes real work.

Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Array interface refactoring

2006-02-21 Thread Donald Bruce Stewart
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 various Array interfaces
 seem a bit inconsistent and make learning/using arrays
 complicated.  I *do* understand how to use arrays in
 Haskell, but I think that the interface could be
 cleaned up.
 
 Examples of current confusions:
  IArray and Array are dupes (obvious);
  listArray for IArray, but newListArray for MArrays;
  ! for IArray, but readArray for MArrays.

And unsafeRead/unsafeWrite are too verbose. They are usually (almost
always?) safe (since the code does its own checks), so perhaps this
essential-for-performance interface should have nicer names? 

They're not in the same unsafe league that unsafePerformIO is.  Just
something I pondered during the shootout massacre a couple of weeks
back.

Cheers,
  Don
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime


Re: Array interface refactoring

2006-02-21 Thread 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 using it if you weren't certain that your program will behave
properly.

 so perhaps this essential-for-performance interface should have nicer
 names? 

Any primitive with can destroy the nice properties of Haskell when
*misused* should be marked as unsafe. The point is that you can do
anything with other nice, non-unsafe functions and you will still stay
within the semantics of the language.

If you don't like those long names, nobody is stopping you from defining
your own local bindings. Thanks to inlining, it should be as efficient
as using unsafeWrite/unsafeRead directly.

 They're not in the same unsafe league that unsafePerformIO is.

Why not? With unsafeWrite you can write to any address in memory, so you
can crash the program, change values which should be constant, etc.
Perhaps unsafeRead is not that dangerous, but you can surely cause SEGV
with it.

Or am I missing something?

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML)  (Linux || FreeBSD || math)
for work in Warsaw, Poland
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime