April 2005 - Libraries

RE: Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))
by Simon Marlow 22 Apr '05

22 Apr '05

On 20 April 2005 11:56, S. Alexander Jacobson wrote: > Lastly, I think you proposal to add package naes to the source is > seriously at odds with your commment from earlier: I'm not proposing to add package names to source code. The rest of your post was based on this misconception, so I won't answer it. I realise my description of the idea wasn't as complete as it could have been. I'll try to describe the idea more precisely. (note this isn't a proposal as such). - source code continues to use module *names* only. - define module *identifier* as (package name, module name) pair - in the context of each module's source, there is assumed to be a mapping from module name to module identifier established by some external mechanism. The "external mechanism" referred to here could be GHC's -package flags, or Cabal's build-depends, for example. For the purposes of the language definition, it doesn't matter. > Also, the Haskell module hierarchy is supposed to reflect > functionality, whereas package names are purely administrative. > This is a reason for not including package names in source code. > > http://www.haskell.org//pipermail/libraries/2005-April/003513.html My position on this has (still) not changed! Cheers, Simon

5 12

RE: Environment variable does not work (especially DARCS_EDITOR)
by Simon Marlow 22 Apr '05

22 Apr '05

On 21 April 2005 17:57, Glynn Clements wrote: > Simon Marlow wrote: > >>> The test program works after applying the following patch to GHC >>> that disables nonblocking mode after the fork and before the exec. > >> If we did this, we would also need to re-enable non-blocking mode >> after the rawSystem completes. Also, this doesn't work well if >> runProcess is used and the Haskell program continues to run while >> the subprocess is executing, because the O_NONBLOCK flag is shared >> between parent and child. > > Presumably the Haskell program won't like it very much if the spawned > program disables O_NONBLOCK itself? > > Is there a reason (other than performance) why the use of O_NONBLOCK > can't be replaced with calling select/poll before accessing the > descriptor? That would work, as long as the current process is the only user of that file descriptor: otherwise there's a race condition between the select() and the read(). This is really a Unix design blunder, there ought to be a non-blocking version of read(). > Is non-blocking I/O only necessary if you need explicit concurrency? > Or do the runtime or critical libraries require it? Right, it's only important if you need concurrency. Cheers, Simon

1 0

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

On 21 April 2005 11:16, John Meacham wrote: > but a useful stopgap, because their use would guarentee your code > wouldn't suddenly stop working when ghc changes its IO system. That isn't going to happen, but I take your point. Simon

3 2

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

On 20 April 2005 22:35, Scott Turner wrote: > On 2005 April 20 Wednesday 15:56, Iavor Diatchki wrote: >> I've been playing around with decoding binary files, and I couldn't >> find a function in the libraries to read a byte from a file. Does >> anyone know if there is such a function? ....... it seems >> that we should have: >> hGetByte :: Handle -> IO Word8 > > hGetByte could be implemented on top of hGetBuf and StorableArray, > but the overhead would be ugly. Recently I needed binary input for > similar reasons, and would have used hGetByte had it been available. > I ended up performing input using a reasonable-sized buffer. In GHC, you can assume that hGetByte h = do c <- hGetChar h; return (fromIntegral (ord c)) you must open the file in binary mode (openBinaryFile). I don't think this works with Hugs, though. Personally, I think this ought to be part of the redesign of the I/O library. hGetByte and hPutByte would be a stopgap. But, not much progress is being made on an I/O redesign right now. Cheers, SImon

5 5

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

On 21 April 2005 12:07, Ross Paterson wrote: > On Thu, Apr 21, 2005 at 10:32:59AM +0100, Simon Marlow wrote: >> In GHC, you can assume that >> >> hGetByte h = do c <- hGetChar h; return (fromIntegral (ord c)) >> >> you must open the file in binary mode (openBinaryFile). I don't >> think this works with Hugs, though. > > It does, provided the file was opened in binary mode. Right, thanks for the clarification. Simon

1 0

RE: Binary IO
by Simon Marlow 21 Apr '05

21 Apr '05

You might be thinking of Hugs. GHC's behaviour hasn't changed. Cheers, Simon On 21 April 2005 13:33, Keean Schupke wrote: > But hasn't ghc just changed its IO (with regards to localisation)? If > it can happen once it can happen again. > > Keean. > > Simon Marlow wrote: > >> On 21 April 2005 11:16, John Meacham wrote: >> >> >> >>> but a useful stopgap, because their use would guarentee your code >>> wouldn't suddenly stop working when ghc changes its IO system. >>> >>> >> >> That isn't going to happen, but I take your point. >> >> Simon >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Suggestion re Data.Storable.Array
by Simon Marlow 21 Apr '05

21 Apr '05

On 21 April 2005 02:10, Paul Steckler wrote: > I recently needed to access C-like arrays > from Haskell. Everyone pointed me to > Data.Storable.Array, but that wasn't quite > what I wanted. The MArray class that provides > the interface for storable arrays insists that > it create the storage via newArray or newArray_. > But I already had the C storage I needed; I justed > wanted to wrap that in Haskell. > > I cons'ed up my own primitives, which work just > fine, but it would be nice to just use something > already in the libraries. Concretely, adding > a way to create a storable array from an existing > Ptr would've done the trick. I can see that's > less safe, but sometimes you have to live > dangerously! Ok, I've added a suitable back door: unsafeForeignPtrToStorableArray :: ForeignPtr e -> (i,i) -> IO (StorableArray i e) Cheers, Simon

1 0

RE: Cabal vs Haskell (was RE: build-depends harmful (was RE: import resolution))
by Simon Marlow 21 Apr '05

21 Apr '05

Hi Alex, I'm going to take a break from this discussion for a while. If I responded to your previous message, I feel I'd be repeating a lot of things I've already said in this thread, and not really making any progress. That's not to say there isn't progress to be made. I suggest that if you want to propose a change to Haskell and/or Cabal, you write it down as precisely as possible and send it to the list. If possible, separate proposals into smaller parts - separate changes to the Haskell definition from changes to the package system and changes to Cabal. Cheers, Simon On 20 April 2005 19:43, S. Alexander Jacobson wrote: > Simon, > > Right now, a module name in an import declaration identifies a module > specification, a module name in a module declaration identifies an > implementation, and some "external mechanism" resolves specifications > to implementations. The big issue on the table here is what exactly > this "external mechanism" should be. I'll suggest some requirements: > > 1. It should require minimal work for a user to share an > implementation. > > 2. It should work with and accross the Internet. > > 3. It should allow arbitrtary sets of implementations to be > delivered together as needed. > > 4. It should be able to work without substantial user > intervention. > > 5. Module users rather than module authors should select how > imported module names are resolved to implementations. > > 6. Interface changes should be local to users of those interfaces. > > 7. It needs to handle foreign implementations (FFI) > > Unfortunately, our existing module resolver mechanisms are severely > inadequate here. Build-depends and -package both violate #1 because > they both force users to create packages even to share standalone pure > haskell modules. The fact that module/package names can't currently > be resolved to URLs means both also violate #2 and #4. That packages > can contain at most one implementation of any module violates #3 and > #5 (and it is just a file format problem!). That package > build/install processes can modify overall system state violates #4. > Build-depends MAJORLY violates #5 and #6. On the plus side, they both > handle #7. > > I'd like Haskell to have a module resolver mechanism that fulfills our > requirements and does not have these problems. > > -Alex- > > ______________________________________________________________ > S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com > > > > On Wed, 20 Apr 2005, Simon Marlow wrote: > >> On 20 April 2005 11:56, S. Alexander Jacobson wrote: >> >>> Lastly, I think you proposal to add package naes to the source is >>> seriously at odds with your commment from earlier: >> >> I'm not proposing to add package names to source code. >> >> The rest of your post was based on this misconception, so I won't >> answer it. >> >> I realise my description of the idea wasn't as complete as it could >> have been. I'll try to describe the idea more precisely. (note >> this isn't a proposal as such). >> >> - source code continues to use module *names* only. >> >> - define module *identifier* as (package name, module name) pair >> >> - in the context of each module's source, there is assumed to be >> a mapping from module name to module identifier established by >> some external mechanism. >> >> The "external mechanism" referred to here could be GHC's -package >> flags, or Cabal's build-depends, for example. For the purposes of >> the language definition, it doesn't matter. >> >>> Also, the Haskell module hierarchy is supposed to reflect >>> functionality, whereas package names are purely administrative. >>> This is a reason for not including package names in source code. >>> >>> >>> http://www.haskell.org//pipermail/libraries/2005-April/003513.html >> >> My position on this has (still) not changed! >> >> Cheers, >> Simon

1 0

Suggestion re Data.Storable.Array
by Paul Steckler 20 Apr '05

20 Apr '05

Hi, I recently needed to access C-like arrays from Haskell. Everyone pointed me to Data.Storable.Array, but that wasn't quite what I wanted. The MArray class that provides the interface for storable arrays insists that it create the storage via newArray or newArray_. But I already had the C storage I needed; I justed wanted to wrap that in Haskell. I cons'ed up my own primitives, which work just fine, but it would be nice to just use something already in the libraries. Concretely, adding a way to create a storable array from an existing Ptr would've done the trick. I can see that's less safe, but sometimes you have to live dangerously! -- Paul

1 0

Binary IO
by Iavor Diatchki 20 Apr '05

20 Apr '05

Hello, I've been playing around with decoding binary files, and I couldn't find a function in the libraries to read a byte from a file. Does anyone know if there is such a function? If not, I think we should add one. Currently I am using hGetChar for this purpose but it seems that we should have: hGetByte :: Handle -> IO Word8 I don't think that hGetChar is good enough because characters are not bytes. In particular it seems that an implementation could consult the system's locale settings and use a variable character encoding such as UTF8. Also on a related note, is there a way to work with memory mapped files in Haskell/GHC? -Iavor

2 1