- Libraries - Haskell.org

Re: cvs commit: fptools/libraries/core Numeric.hs
by Alastair David Reid 04 Jul '01

04 Jul '01

Simon: > Add Numeric library here for the time being. This is a combination > of the H98 Numeric library and a few functions from GHC's NumExts. But if you put extensions in an H98 file, it's hard for users to check if they're limiting themselves to the standard. Fix 1: Rename Numeric.hs to NumericInternals.hs (or anything else you like) and make Numeric.hs just import NumericInternals and re-export the standard. Fix 2: Generalise the DEPRECATED pragma. I prefer (1) (since it places the least burden on other compilers) but (2) has its attractions. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

RE: Core libs summary
by Simon Marlow 02 Jul '01

02 Jul '01

> > > As a point of interest, is there > > > a good reason why the Exception type needs to be in the Prelude? > > > because you want to define error by something like: > > error msg = Exception.raise (Exception.Error msg) > > I'm still not entirely sure I understand why a qualified import > into the Prelude implementation (as you have illustrated here) is not > sufficient. Does Exception need to be hardwired into the Prelude? > For a comparable example, think of type Prelude.Rational which is > defined as (Ratio.Ratio Prelude.Integer). The Ratio type is not in > the prelude, just used by it. I think you two are using different notions of what "in the Prelude" means. Alastair seems to be taking it to mean "everything below Prelude in the dependency tree", and Malcolm is using "everything defined originally by the Prelude module" (I think (?)). In the core libraries, there is a great deal of stuff below the Prelude in the dependency tree. I didn't worry too much about this, because I want the Prelude to be "just another module", which the user can replace if necessary. The down side is that Hugs' startup times will be longer if it has to chase several modules in order to satisfy the Prelude's imports. But I suggest we actually see whether this is a problem or not before restricting our design. (aside: I really think we should have an alternative, reduced, Prelude that doens't export any I/O stuff for example). Cheers, Simon

2 1

Core libs summary
by Simon Marlow 29 Jun '01

29 Jun '01

Below is an automatically-generated summary of the modules in the core libs I checked in earlier, including the stability/portability status of each module. I've gone through and put in a best guess for the stability/portability status, so let me know if you think any are wrong (Hugs, NHC folks: remember that every module marked "portable" is expected to be available on all implementations - so if any of these are going to cause problems, let me know). Names with a '.' after are directories, names without a trailing '.' are modules. Cheers, Simon ------------------ Control. Concurrent. CVar ( non-portable, experimental ) Chan ( non-portable, experimental ) MVar ( non-portable, experimental ) QSem ( non-portable, experimental ) QSemN ( non-portable, experimental ) SampleVar ( non-portable, experimental ) Concurrent ( non-portable, experimental ) Exception ( non-portable, experimental ) Monad. Cont ( non-portable, experimental ) Error ( non-portable, experimental ) Fix ( non-portable, experimental ) Identity ( portable, experimental ) List ( non-portable, experimental ) Monoid ( non-portable, experimental ) RWS ( non-portable, experimental ) Reader ( non-portable, experimental ) ST. Lazy ( portable, provisional ) Strict ( portable, provisional ) ST ( non-portable, experimental ) State ( non-portable, experimental ) Trans ( portable, experimental ) Writer ( non-portable, experimental ) Monad ( portable, provisional ) Parallel. Strategies ( non-portable, experimental ) Parallel ( non-portable, experimental ) Data. Array. Base ( non-portable, experimental ) IArray ( non-portable, experimental ) IO ( non-portable, experimental ) MArray ( non-portable, experimental ) ST ( non-portable, experimental ) Unboxed ( non-portable, experimental ) Array ( portable, provisional ) Bits ( portable, experimental ) Bool ( portable, experimental ) Char ( portable, provisional ) Complex ( portable, provisional ) Dynamic ( portable, experimental ) Either ( portable, experimental ) IORef ( portable, experimental ) Int ( portable, experimental ) Ix ( portable, provisional ) List ( portable, provisional ) Maybe ( portable, experimental ) PackedString ( portable, experimental ) Ratio ( portable, provisional ) STRef ( portable, experimental ) Word ( portable, experimental ) Database. Debug. Trace ( portable, provisional ) FileFormat. Foreign. C. Error ( portable, provisional ) String ( portable, provisional ) Types ( portable, provisional ) TypesISO ( portable, provisional ) C ( portable, provisional ) ForeignPtr ( portable, provisional ) Marshal. Alloc ( portable, provisional ) Array ( portable, provisional ) Error ( portable, provisional ) Utils ( portable, provisional ) Ptr ( portable, provisional ) StablePtr ( portable, provisional ) Storable ( portable, provisional ) Foreign ( portable, provisional ) GHC. Arr ( , ) Base ( , ) ByteArr ( , ) Conc ( , ) Dynamic ( , ) Enum ( , ) Err ( , ) Exception ( , ) Float ( , ) Handle ( , ) IO ( , ) IOBase ( , ) Int ( , ) List ( , ) Main ( , ) Maybe ( , ) Num ( , ) Pack ( , ) Posix ( , ) Ptr ( , ) Read ( , ) Real ( , ) ST ( , ) STRef ( , ) Show ( , ) Stable ( , ) Storable ( , ) TopHandler ( , ) Tup ( , ) Weak ( , ) Word ( , ) Hugs. Language. NHC. Network. Prelude ( portable, provisional ) System. CPUTime ( portable, provisional ) Cmd ( portable, provisional ) Environment ( portable, provisional ) Exit ( portable, provisional ) IO. Directory ( portable, provisional ) Unsafe ( portable, provisional ) IO ( portable, provisional ) Info ( portable, provisional ) Locale ( portable, provisional ) Mem. StableName ( non-portable, experimental ) Weak ( non-portable, experimental ) Random ( portable, provisional ) Time ( portable, provisional ) Text. Read ( portable, provisional ) Show. Functions ( portable, provisional ) Show ( portable, provisional )

4 6

RE: Core libs summary
by Simon Marlow 29 Jun '01

29 Jun '01

> Ok, I've marked against your list anything that I think is problematic > for nhc98, despite being designated portable. Cool, thanks. Comments below. > Regards, > Malcolm > > ------------------ > Control. > Monad. > Identity ( portable, experimental ) > *** Re-exports Control.Monad.Fix, which > *** is designated non-portable. I've made Control.Monad.Fix portable by moving the IO and ST instances to the correct places. Identity should now be portable too. > ST. > Lazy ( portable, provisional ) > Strict ( portable, provisional ) > *** Don't both variants of ST require runtime > *** system support? If so, then not yet portable. Sorry, I thought NHC had the ST monad. Ok, I'll mark it non-portable for the time being. Actually to implement it all you need is a bit of typechecker support for runST and that's it, though. > Trans ( portable, experimental ) > *** I can't imagine what the name means, but > *** the code does look like pure Haskell'98. It's the monad transformer class. Andy G - would you like to change the name? (and would you like to be the maintainer? :-) > Monad ( portable, provisional ) > Data. > Array ( portable, provisional ) > Bits ( portable, experimental ) > *** Not portable. requires either RTS support > *** or an FFI'd implementation in C I would think. I was thinking that Bits is required by Data.Word & Data.Int, which are in turn required by the Foreign stuff, but you can perhaps get away without exporting Bits instances from these modules. However, I think Bits is desirable if not essential when doing FFI stuff - we can discuss & change the interface if you like (but IIRC it was already discussed to death when Alastair designed it). Perhaps we could make 'instance Bits Integer' optional, because that's probably the hardest bit. > Bool ( portable, experimental ) > Char ( portable, provisional ) > Complex ( portable, provisional ) > Dynamic ( portable, experimental ) > *** Doesn't contain a data decl for Dynamic, > *** but otherwise looks ok. This doesn't require > *** any RTS support does it? It requires unsafePerformIO & IORefs, but that's all. The data decl for Dynamic is in GHC.Dynamic because GHC needs it for the Exception data type. (but it's generic so it can probably be moved out of there). > Either ( portable, experimental ) > IORef ( portable, experimental ) > Int ( portable, experimental ) > Ix ( portable, provisional ) > *** H'98 compliance: rangeSize should now be > *** a class member. Yup, still ToDo. > List ( portable, provisional ) > Maybe ( portable, experimental ) > PackedString ( portable, experimental ) > *** nhc98 implements only the `classic' HBC > *** interface. In particular, none of the > *** ByteArray ops are portable. oops, I hadn't noticed it mentioned ByteArrays. Ok, I'll remove these. > Ratio ( portable, provisional ) > STRef ( portable, experimental ) > *** As with the ST monad, I believe RTS support > *** or an FFI'd implementation is required? Ok. > Word ( portable, experimental ) > Database. > Debug. > Trace ( portable, provisional ) > FileFormat. > Foreign. > *** I haven't looked at the Foreign stuff in > *** detail for quite a while, so apart from > *** some RTS implementation in nhc98, I'm > *** assuming everything else is straightforward. > GHC. > Hugs. > NHC. > *** I'd prefer Nhc or Nhc98. All caps is horrible. Ok, Nhc it is. But it looks horrible next to GHC :-) > Network. > Prelude ( portable, provisional ) > System. > *** The sample implementations of many of these > *** System libraries are not very portable, but > *** the interfaces are probably ok. The implementations of CPUTime, Cmd, Environment, Exit, Time, and Directory are all rewrites of the original GHC versions to use the new FFI & Foreign libraries, so they should be quite portable. You do need hsc2hs and a suitable config.h, though. I think it would be great if we could all use the same implementations of these libs, though. > CPUTime ( portable, provisional ) > Cmd ( portable, provisional ) > Environment ( portable, provisional ) > Exit ( portable, provisional ) > IO. > Directory ( portable, provisional ) > *** Incorrect interface: Permissions should not > *** be abstract. well spotted, thanks. > Unsafe ( portable, provisional ) > IO ( portable, provisional ) > Info ( portable, provisional ) > *** A great idea. Status should be experimental. done. > Locale ( portable, provisional ) > Random ( portable, provisional ) > Time ( portable, provisional ) > Text. > Read ( portable, provisional ) > Show. > Functions ( portable, provisional ) > Show ( portable, provisional )

1 0

RE: Core libs summary
by Simon Marlow 29 Jun '01

29 Jun '01

> > I've gone through and put in a best guess for the > > stability/portability status, so let me know if you think any are > > wrong (Hugs, NHC folks: remember that every module marked "portable" > > is expected to be available on all implementations - so if any of > > these are going to cause problems, let me know). > > (Without having looked at it at all) I'm half expecting to have to > tweak the Foreign interface a bit since the low level grungy stuff is > where compiler differences are hardest to hide. I hope you won't have to change it, but we can discuss it on ffi(a)haskell.org if there's anything that will be too hard to implement in Hugs (actually, I seriously doubt it because if you can run H/Direct and green card code on Hugs, the Foreign libraries are just a different veneer over the primitives). > Does it work on NHC? (In which case changes are a lot less likely) > > I remember that one of the ForeignObj-like datatypes pretty much > requires threads to implement it because the finaliser is an arbitrary > piece of Haskell code. This would be hard to support in Hugs and I > expect NHC would have problems too. I seem to recall NHC having some difficulty with this... Malcolm? Cheers, SImon

2 1

RE: ghc_extra_opts in package
by Simon Marlow 29 Jun '01

29 Jun '01

> > Also, this doesn't mesh well with the portability notion in the new > > libraries proposal. The idea there is that certain libraries would > > be optional depending on whether the compiler implemented certain > > extensions - with your scheme this would have to be done at the > > package level. > > Hmmm, my mental model of packages was a group of tightly coupled > modules so I wasn't making this distinction. Reasons to split groups of modules into packages: - to avoid polluting the module namespace (historical; not an issue with the new library scheme). - for separate distribution/installation - if you put all your code in one package, the .a library can get large which might slow down linking. Reasons not to use packages if you don't have to: - the user has to explicitly ask for a package (at least at the moment; it may be possible to remove this restriction in certain cases). - you can't have recursive dependencies between packages Additionally restricting a package to use a single set of extensions will probably be inconvenient both for the users and developers, at least for the core package. > > I wanted to lump all the core libraries into a single package on > > GHC, but this would mean that package "core" for GHC would require a > > different set of extensions than the same package for NHC. > > That's more because of conditional compilation than the > library/package distinction right? > > Hmmm, conditional compilation complicates the story for > source packages. > Choices: > > o one package per combination of cpp flags > > o one package with some sort of conditionals inside it: > > deps = case COMPILER of > __GHC__ => net, lang > __NHC__ => lang > __HUGS__ => greencard > > Neither is very appealing. Is there an existing story for this sort > of thing? The second way seems to me to be the only option, if you want to go down this route. For example, some of the Monad libraries require MPTC, but I don't want to split these into a separate package - hence the core package requires MPTC. But NHC won't support these modules, so its core package will be different. It's more like conditional compilation at the module level - certain modules will just be omitted altogether for certain compiler/platform combinations. Some conditional compilation may additionally happen in the implementation, but the interface for a module should be static across all implementations that support it. Cheers, Simon

1 0

RE: ghc_extra_opts in package
by Simon Marlow 28 Jun '01

28 Jun '01

> > Another issue is that it turns out to be hard to enable certain > > extensions without enabling others, because it requires you to pass > > around more state in the compiler, and in particular in the parser > > (the number of different languages being parsed increases), which is > > why we lump all the extensions together in GHC. However, I agree > > the situation isn't ideal. > > So here's a concrete suggestion: > > 1) We standardise the definition of various extensions (mptc, > unboxed types, > etc.) so that if two compilers both claim to support > feature X, then > they accept the same code. (We're pretty close to this already.) Definitely - this has been a goal for a while. I think there was a plan to have a section on www.haskell.org listing all the extensions with their specifications. > 2) We extend the package definition with a list of features > used in the > package. > > Package { > name = "net", > extensions = [ "FFI", "ExceptionHandling", ... ], > ... > } Let's be clear: these extensions are those required by the *consumer* of the package, right? The implementation of the package will likely require a different (probably super-) set of extensions. For example: "FFI" isn't typically required by the consumer of the "net" package, but it is certainly used in the implementation. Also, this doesn't mesh well with the portability notion in the new libraries proposal. The idea there is that certain libraries would be optional depending on whether the compiler implemented certain extensions - with your scheme this would have to be done at the package level. I wanted to lump all the core libraries into a single package on GHC, but this would mean that package "core" for GHC would require a different set of extensions than the same package for NHC. Cheers, Simon

2 1

FW: cvs commit: fptools/libraries/core Foreign.hs Main.hi-boot Makefile Prelude.hs fptools/libraries/core/Control Concurrent.hs Exception.hs Monad.hs Parallel.hs fptools/libraries/core/Control/Concurrent CVar.hs Chan.hs MVar.hs ...
by Simon Marlow 28 Jun '01

28 Jun '01

For those not on the GHC CVS mailing list, I've just committed a first cut of the new libraries. You can checkout the tree from GHC's CVS repository by saying 'cvs checkout libraries' (at least after the anonymous mirror has happened, within 24 hours). Cheers, Simon -----Original Message----- From: Simon Marlow [mailto:simonmar@glass.cse.ogi.edu] Sent: Thursday, June 28, 2001 3:15 PM To: cvs-fptools(a)haskell.org Subject: cvs commit: fptools/libraries/core Foreign.hs Main.hi-boot Makefile Prelude.hs fptools/libraries/core/Control Concurrent.hs Exception.hs Monad.hs Parallel.hs fptools/libraries/core/Control/Concurrent CVar.hs Chan.hs MVar.hs ... simonmar 2001/06/28 07:15:04 PDT Added files: libraries/core Foreign.hs Main.hi-boot Makefile Prelude.hs libraries/core/Control Concurrent.hs Exception.hs Monad.hs Parallel.hs libraries/core/Control/Concurrent CVar.hs Chan.hs MVar.hs QSem.hs QSemN.hs SampleVar.hs libraries/core/Control/Monad Cont.hs Error.hs Fix.hs Identity.hs List.hs Monoid.hs RWS.hs Reader.hs ST.hs State.hs Trans.hs Writer.hs libraries/core/Control/Monad/ST Lazy.hs Strict.hs libraries/core/Control/Parallel Strategies.hs libraries/core/Data Array.hs Bits.hs Bool.hs Char.hs Complex.hs Dynamic.hs Either.hs IORef.hs Int.hs Ix.hs List.hs Maybe.hs PackedString.hs Ratio.hs STRef.hs Word.hs libraries/core/Data/Array Base.hs IArray.hs IO.hs MArray.hs ST.hs Unboxed.hs libraries/core/Debug Trace.hs libraries/core/Foreign C.hs ForeignPtr.hs Ptr.hs StablePtr.hs Storable.hs libraries/core/Foreign/C Error.hs String.hs Types.hs TypesISO.hs libraries/core/Foreign/Marshal Alloc.hs Array.hs Error.hs Utils.hs libraries/core/GHC Arr.lhs Base.lhs ByteArr.lhs Conc.lhs Dynamic.lhs Enum.lhs Err.hi-boot Err.lhs Exception.lhs Float.lhs Handle.hsc Handle.hsc.orig IO.hsc IOBase.lhs Int.lhs List.lhs Main.lhs Maybe.lhs Num.hi-boot Num.lhs Pack.lhs Posix.hsc Prim.hi-boot Ptr.lhs Read.lhs Real.lhs ST.lhs STRef.lhs Show.lhs Stable.lhs Storable.lhs TopHandler.lhs Tup.lhs Weak.lhs Word.lhs libraries/core/System CPUTime.hsc Cmd.hsc Environment.hs Exit.hs IO.hs Info.hs Locale.hs Random.hs Time.hsc libraries/core/System/IO Directory.hsc Unsafe.hs libraries/core/System/Mem StableName.hs Weak.hs libraries/core/Text Read.hs Show.hs libraries/core/Text/Show Functions.hs libraries/core/cbits Makefile errno.c inputReady.c lockFile.c system.c writeError.c libraries/core/doc libraries.sgml libraries/core/include CTypes.h Dynamic.h HsCore.h PackedString.h ghc_errno.h lockFile.h Log: First cut of the Haskell Core Libraries ======================================= NOTE: it's not meant to be a working snapshot. The code is just here to look at and so the NHC/Hugs guys can start playing around with it. There is no build system. For GHC, the libraries tree is intended to be grafted onto an existing fptools/ tree, and the Makefile in libraries/core is a quick hack for that setup. This won't work at the moment without the other changes needed in fptools/ghc, which I haven't committed because they'll cause breakage. However, with the changes required these sources build a working Prelude and libraries. The layout mostly follows the one we agreed on, with one or two minor changes; in particular the Data/Array layout probably isn't final (there are several choices here). The document is in libraries/core/doc as promised. The cbits stuff is just a copy of ghc/lib/std/cbits and has GHC-specific stuff in it. We should really separate the compiler-specific C support from any compiler-independent C support there might be. Don't pay too much attention to the portability or stability status indicated in the header of each source file at the moment - I haven't gone through to make sure they're all consistent and make sense. I'm using non-literate source outside of GHC/. Hope that's ok with everyone. We need to discuss how the build system is going to work... _______________________________________________ Cvs-fptools mailing list Cvs-fptools(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-fptools

2 1

RE: Glasgow mafia meeting at PLDI
by Simon Marlow 28 Jun '01

28 Jun '01

> 24 Jun 2001 14:50:16 -0600, Alastair David Reid > <reid(a)cs.utah.edu> pisze: > > > There are an awful lot of them: one for each country in the world. > > I don't think there's a country called "Prelude" but there probably > > is one with the domain name "IO". > > There is none. I don't believe in any clash if we just mix the domain > hierarchy with the functionality hierarchy. The point is we don't have any control over the DNS namespace, so even if it doesn't clash with our hierarchy now, it might in the future. Cheers, Simon

1 0

Re: ghc_extra_opts in package
by Alastair David Reid 27 Jun '01

27 Jun '01

[Discussion moves to libraries list] Simon Marlow: > Arguably there ought to be some other indication in the source code > of what non-standard features a module requires - the closest we > come to this at the moment is that GHC allows you to say > {-# OPTIONS -fglasgow-exts #-} > to enable GHC extensions in the source. If we went in this direction, we'd need to make it compiler independent and finer grained. I also feel uncomfortable putting it in the source file but I can't quite put my finger on why. > Another issue is that it turns out to be hard to enable certain > extensions without enabling others, because it requires you to pass > around more state in the compiler, and in particular in the parser > (the number of different languages being parsed increases), which is > why we lump all the extensions together in GHC. However, I agree > the situation isn't ideal. So here's a concrete suggestion: 1) We standardise the definition of various extensions (mptc, unboxed types, etc.) so that if two compilers both claim to support feature X, then they accept the same code. (We're pretty close to this already.) Note that standardising the definition of mptc (for example) isn't the same as requiring all Haskell compilers to support it. Here's a list of proposed standards (suggestions for extra features welcome): MPTC FunctionalDependencies PatternGuards UnboxedTypes TREX PreemptiveConcurrency CooperativeConcurrency ImplicitParameters ExceptionHandling FFI 2) We extend the package definition with a list of features used in the package. Package { name = "net", extensions = [ "FFI", "ExceptionHandling", ... ], ... } 3) Package managers translate these standard feature names into a set of compiler-specific flags to pass to the compiler. It would be considered ok for a compiler to enable other extensions at the same time or to have some extensions permanently enabled. (It would also be good if at least one of the compilers supporting each feature generated a warning if you used a feature not mentioned in the package spec. This check might occur while checking static semantics, typechecking, etc. (where it is easy to be selective) instead of being enforced in the parser. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

3 2