- Libraries - Haskell.org

'.' in usernames
by Dean Herington 05 Jul '01

05 Jul '01

The libraries description says about the "User" hierarchy: > The User hierarchy is reserved for users: a user may always use the portion of the > hierarchy which is formed from his/her email address as follows: > replace the @ by a ., reverse the order of the components, capitalise the first letter of each > component, and prepend User.. For example, > simonmar(a)microsoft.com becomes User.Com.Microsoft.Simonmar. What if the username itself contains a '.'? (This is fairly common.) That could lead to ambiguity. For example, (perhaps) both "John.Smith(a)foo.com" and "John(a)smith.foo.com" translate to "User.Com.Foo.Smith.John". Dean Herington

1 0

New summary
by Simon Marlow 05 Jul '01

05 Jul '01

Here is a new summary of the current core libs, where clicking on a module name takes you to the source (in CVSweb) for the module: http://www.haskell.org/~simonmar/core-libs.html Cheers, Simon

1 0

Document updated
by Simon Marlow 05 Jul '01

05 Jul '01

The document at http://www.haskell.org/~simonmar/libraries/libraries.html has been updated again. It now has a copy of the language extension proposal, taken from Malcolm's original proposal and edited slightly. There's also some stuff about which extensions to Haskell 98 we consider as part of the baseline (just FFI and a couple of minor things so far). Cheers, Simon

1 0

RE: cvs commit: fptools/libraries/core Numeric.hs
by Simon Marlow 05 Jul '01

05 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. I haven't gone to much trouble to retain strict H98 interfaces for libraries moved into the new hierarchy (eg. System.IO) - the differences are listed in the document in libraries/doc/libraries.sgml. But you're right, in this instance the library has the same name as the original H98 library, so the interface should be kept the same for compatibility (it'll overlap with our H98 compat libraries anyway). Cheers, Simon

1 0

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