- Libraries - Haskell.org

RE: Cabal Issues
by Simon Marlow 23 Apr '05

23 Apr '05

On 16 April 2005 02:23, Isaac Jones wrote: > Ashley Yakeley <ashley(a)semantic.org> writes: > >> I've just started using Cabal, for my time library implementation >> (<http://semantic.org/TimeLib/>). I have some issues: >> >> 1. If I do "runghc Setup.hs haddock" and then "runghc Setup.hs >> install", the documentation doesn't appear to get installed anywhere. > > Where do folks think that the docs should go? Or should we add a > haddock-prefix flag to configure? GHC puts them in /usr/local/share/<package>/html Perhaps /usr/local/share/doc/<package>/html would be better? Cheers, Simon

2 1

RE: Cabal vs Haskell [sic]
by Simon Peyton-Jones 22 Apr '05

22 Apr '05

| > Moreover, I think Simon does too. He proposes that we should lift the | > overlap restriction by having module names map to (cabal-package, | > module) pairs. | | Well, the overlap restriction exists in the language already. | If you want to lift it, you really need to change the language. | Simon's proposal (which I support) is a hack to permit the restriction | to be lifted without changing existing code, by re-interpreting all | module imports to have an implicit (disambiguating) prefix. It is | just an engineering tradeoff to ensure that huge mounds of legacy code | are not broken purely for the sake of some rather rare overlap case. My motivation is actually this. In a function definition, the caller of the function need not care what the function's local variables are called. But in a Haskell program, the importer of a module M *does* need to care about the names of modules that are imported by M (i.e. are part of M's internal implementation). He needs to care because he can't use those module names. Indeed two modules M and N might simply be unusable in the same program, merely because the implementers of M and N happened to choose the same name for an internal sub-module. I think that's undesirable. The "solution" I was advocating arranges that a *package* must use unique module names, but two packages need not care about the modules used inside each other. But this solution only works smoothly for internal modules. What if packages P and Q both expose a module called M? Then you can't import M-from-P and M-from-Q into the same importing module, because the importing module has no way to say which M he means. And this observation points towards a simpler solution: rather than invisibly pre-pend the package name, just get the programmer to do so. So package P exposes a module called P.M and package Q exposes Q.M. All P's internal modules are called P.something, and similarly for Q. (We rely on some social mechanism for allocating new package names, as now.) Now of course you can import P.M and Q.M in a single module. That would be simple. It might be pretty inconvenient to say 'import Base.Data.List' rather than just 'import Data.List'. But nothing forces you to do this -- and indeed we don't do it for the current 'base' package. The point is that it's an easy way for a package author to ensure their package won't conflict with others. If they choose not to avail themselves of it, it's more likely that their package will be unusable because of accidental name conflicts. Bottom line: the current story is pretty defensible. I'm not sure that keeping names unique by implicitly using package-ids is worth the bother. Simon

2 1

RE: Binary IO
by Simon Marlow 22 Apr '05

22 Apr '05

On 22 April 2005 11:35, Benjamin Franksen wrote: > On Friday 22 April 2005 10:38, Simon Marlow wrote: >> Lifting this constraint in GHC is a bit tricky because we currenly >> use the OS's text<->binary translation to do I/O (doesn't matter on >> Unix, right now). > > So what? If the handle is in text mode, you won't get the exact bytes > as they are in the file, when calling hGetWord8 (at least on some > systems). But that is exactly what I would expect if the handle is in > text mode. If I need the exact binary representation of a text file, I > have to use binary, of course. So if you open a file in text mode and read it with hGetWord8, what bytes do you expect to get, exactly? Perhaps each byte of the UCS-4 representation? Big endian or little endian order? You could specify some meaning, but I don't think it would be a useful interface. And if you can't specify it precisely, it shouldn't be there. >> I presume that hPutWord8 (fromIntegral (ord '\n')) should not flush a >> line-buffered Handle, > > I can't see a reason not to flush it. Could you explain why you think > it should not? What have terminal settings to do with file handle > modes?? Well, I have the notion that EOL is a text concept, so doesn't belong in binary I/O. On the other hand, it's easy enough to specify that writing the byte 0xa to a line-buffered binary handle has the effect of flushing it, just as we say that writing the character '\n' to a line-buffered text handle triggers a flush. So I'm happy to leave things as they are. Cheers, Simon

3 2

Re: [Haskell] haddock -cpp ? Cabal support for haddock ?
by Isaac Jones 22 Apr '05

22 Apr '05

(CC'ing libraries) (snip) >> > I'd certainly welcome Cabal support for other haddock features as >> > well (--source, --read-interface). I am not sure where to put all >> > these arguments in the .cabal file. >> >> Cabal doesn't support these yet, though. Maybe in the future. > > Dear Isaac, > > for the next release, I think *every* external program used by Cabal > should get a xyz-options (free form) tag to give additional options. We > already have them for linker, c-compiler, and hs-compiler, but not yet > for preprocessors and doc generators (haddock). This is very easy to > implement, does no harm at all, and greatly increases cabal's > flexibility as a build tool. (BTW, I can send you a darcs patch if you > are too busy at the moment.) And in the other thread you said: >> > I made the necessary changes for hsc2hs-options in a few minutes You added hsc2hs-options to the package description? Cool. I'm happy to get a patch to add options fields to all the preprocessors and haddock and anything else we may have missed. There are basically 3 ways that people can customize their packages: - the .cabal file - the Setup script with UserHooks - flags to configure I was originally thinking of these extra flags as something to pass to configure, but actually putting them in the description file would be more consistent with what we have already... One trick, though, is to make sure that the parser test cases for cabal still run when you make the changes. It's all too common for someone to add a field and break the parser or pretty printer. The important thing is that when you parse it, pretty print it, and parse it again it comes out the same. Check out tests/ModuleTest.hs > (BTW, I can send you a darcs patch if you are too busy at the > moment.) I like patches whether I'm busy or not. It'll definitely get done faster ;) BTW, I'm tracking this feature request in the Debian bug tracking system for the haskell-cabal package. peace, isaac

2 1

RE: Binary IO
by Simon Marlow 22 Apr '05

22 Apr '05

On 22 April 2005 11:42, Henning Thielemann wrote: > On Fri, 22 Apr 2005, Simon Marlow wrote: > >> Does anyone have any *objections* to introducing >> >> System.IO.hGetWord8 :: Handle -> IO Word8 >> System.IO.hPutWord8 :: Word8 -> Handle -> IO Word8 > > Sorry, I didn't follow the thread ... what about > System.IO.hPutWord8 :: Handle -> Word8 -> IO () > that is, switched argument order and no result duh, sorry. Yes, that's the right type. > Will there be function names without 'h' prefix but qualification in > future, e.g. System.IO.Binary.Handle.putWord8 ? I think this is something for the next-generation I/O library. Cheers, Simon

1 0

RE: Cabal vs Haskell [sic]
by Simon Marlow 22 Apr '05

22 Apr '05

one minor correction: On 22 April 2005 11:08, Malcolm Wallace wrote: > "Needed to build" tells me which interfaces must be available at > compile-time, no more and no less. I found recently that ghc-pkg > (whose input format is essentially Cabal+extras) has a separate > "builds" field, you mean "depends", I think. And a comment on this: > As it happens, different compilers blur the boundary between interface > and implementation to a greater or lesser extent. To qualify this, I'd say that compilers differ in where they place the boundary between interface and implementation *of object code only*. The interface exposed by a source code module is perfectly well defined, by the language definition. I think it's important to make this distinction (I'm sure Malcolm is aware of it, but I just wanted to make sure it was expressed clearly). Build-depends uses the source-code notion of interface, not the object code. So, build-depends has the same meaning for all compilers. Again, this is an important point to bear in mind. Where the meaning differs, is when you want to replace the object code of an installed package with new object code. For example, upgrading a shared library. This might be a nice feature to have, but it requires us to think very carefully about the public interface of object code (and hence restrict some optimisations, in the case of GHC). Cheers, Simon

1 0

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