Isaac Dupree wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Isaac Dupree wrote:

...

this patch is just for 'base', I didn't look at other libraries

Fri Jun 1 16:36:25 EDT 2007 Isaac Dupree * Remove unsafeCoerce-importing kludgery in favor of Unsafe.Coerce

er, wait, can I commit here - should I do so?

Looks ok to me. Simon

Ashley Yakeley wrote:

Can we move the other unsafe stuff into the Unsafe.* hierarchy?

It's not clear to me that Unsafe.System.IO would be better than System.IO.Unsafe. What is the primary purpose of unsafePerformIO - to do IO, or to be unsafe? I see the point - to clearly separate all the unsafe stuff - but there are other categories of things that we might also want to separate (e.g. Haskell 98 vs. non-Haskell 98, portable vs. non-portable, deprecated vs. current...). We made the decision a long time ago that the hierarchy should categorise by functionality rather than any other property of modules. There are exceptions (System.Posix), but it's still a good rule of thumb. Cheers, Simon

On Tue, Jun 05, 2007 at 10:49:00AM +0100, Simon Marlow wrote:

Ashley Yakeley wrote:

...

Can we move the other unsafe stuff into the Unsafe.* hierarchy?

It's not clear to me that Unsafe.System.IO would be better than System.IO.Unsafe. What is the primary purpose of unsafePerformIO - to do IO, or to be unsafe?

I see the point - to clearly separate all the unsafe stuff - but there are other categories of things that we might also want to separate (e.g. Haskell 98 vs. non-Haskell 98, portable vs. non-portable, deprecated vs. current...). We made the decision a long time ago that the hierarchy should categorise by functionality rather than any other property of modules. There are exceptions (System.Posix), but it's still a good rule of thumb.

indeed. I agree with this. also, I really dislike the 'unsafe' categorization as a catch all for all sorts of "bad" things. I mean, we don't have 'UnsafeIx' or, unsafePoke, but we have things like 'unsafeChr' when perhaps 'uncheckedChr' would have been more appropriate. Not that I am opposed to making it clear what side conditions the user needs to worry about when using a routine, but that is what liberal haddock documentation is for. I think unsafePerformIO and unsafeCoerce are good, because they both allow you to directly break the _static_ sematics of the language. as in, they directly subvert the type system. However, I think many of the other uses should be elided (with liberal documentation) or changed to something more appropriate. This is why I think an 'Unsafe.*' would be a bad idea. it would be a dumping ground for lots of routines with nothing in common other than it made someone uncomfortable at some point. I mean, think if all the ByteString functions dealing with pointers had to move there because you might pass in a bad pointer. We really need to stop using the terms 'safe' and 'unsafe' so much actually. like the recent suggestion of a '-fsafe' flag for ghc. does that mean it makes your code safer? from which use of safe? does it only allows safe code? or assumes your code is safe so turns off type checking? something like '-funtrusted' would be more descriptive and specific. John -- John Meacham - ⑆repetae.net⑆john⑈

ashley:

John Meacham wrote:

...

This is why I think an 'Unsafe.*' would be a bad idea. it would be a dumping ground for lots of routines with nothing in common other than it made someone uncomfortable at some point.

Isn't this a good idea? I want to know about this "uncomfortableness" especially if I can use such "uncomfortable" routines to segfault my program.

...

I mean, think if all the ByteString functions dealing with pointers had to move there because you might pass in a bad pointer.

They should be moved there, shouldn't they? All the unsafe stuff is in a single module, Data.ByteString.Base. What's the purpose of this module? Wouldn't that purpose be better served if it were put in Unsafe.*?

It's more helpful to me when reading a program to see the red flag "import Unsafe.ByteString" rather than the apparently innocuous "import Data.ByteString.Base"...

They are tagged as 'unsafeFoo', of course. So using, say, unsafeTail does hint that you are to check a side condition yourself. Btw, the *.Base form is inherited from Data.Array.Base.unsafeRead/Write. The modules serve similar purposes. -- Don

ashley:

Donald Bruce Stewart wrote:

...

Btw, the *.Base form is inherited from Data.Array.Base.unsafeRead/Write. The modules serve similar purposes.

Data.Array.Base isn't exposed, is it?

Sure is -- it's where we get unchecked array reads and write from. -- Don

ashley:

Donald Bruce Stewart wrote:

...

ashley:

...

Data.Array.Base isn't exposed, is it?

Sure is -- it's where we get unchecked array reads and write from.

I'm not seeing it here: http://haskell.org/ghc/docs/latest/html/libraries/ http://haskell.org/ghc/dist/current/docs/libraries/

base.cabal: exposed-modules: ... Data.Array, Data.Array.Base, Data.Array.Diff, Data.Array.IArray, Data.Array.IO, Data.Array.MArray, Data.Array.ST, Data.Array.Storable, Data.Array.Unboxed, ... -- Don

simonmarhaskell:

Ashley Yakeley wrote:

...

Donald Bruce Stewart wrote:

...

ashley:

...

Data.Array.Base isn't exposed, is it?

Sure is -- it's where we get unchecked array reads and write from.

I'm not seeing it here: http://haskell.org/ghc/docs/latest/html/libraries/ http://haskell.org/ghc/dist/current/docs/libraries/

It's exposed but not documented. When we wrote it, the .Base module was a convenient way to structure the implementation, we didn't intend it to be imported outside of the base package. By the time we started using Cabal and had the choice whether to expose modules or not, code was already using Data.Array.Base (possibly my own code, I don't remember :-), so we left it exposed.

We should really hide Data.Array.Base, and move out of it the things that we really want to expose. Perhaps Data.Array.Unsafe?

Duncan's looking to do a similar thing with Data.ByteString, as we prepare for the 1.0 release. Roughly, internal stuff, Data.ByteString.Internal unsafe stuff, Data.ByteString.Unsafe -- Don