- Libraries - Haskell.org

PROPOSAL: Remove Control.OldException
by Ian Lynagh 04 Aug '09

04 Aug '09

Hi all, Proposal: Remove Control.OldException http://hackage.haskell.org/trac/ghc/ticket/3381 We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead. I propose that we remove Control.OldException for GHC 6.12. If anyone does want Control.OldException, then it could be provided by a separate package. Deadline: 2nd August (2 weeks). Thanks Ian

9 13

Deciding on the decision model for adding and excluding packages
by Don Stewart 03 Aug '09

03 Aug '09

We need to start thinking about how to add or exclude packages from the Haskell Platform. I've written a summary of the discussion so far for evidence-based critieria for deciding on package notability. http://donsbot.wordpress.com/2009/08/01/heuristics-for-blessing-software-pa… Please read it over and think about what the decision model looks like. So we can feed data in, to make decisions on how to include/exclude packages. -- Don

4 7

PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO
by Ian Lynagh 03 Aug '09

03 Aug '09

Hi all, This is Add openFileTemplate, openBinaryFileTemplate to System.IO http://hackage.haskell.org/trac/ghc/ticket/3393 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) In System.IO, openTempFile and openBinaryTempFile mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like writeFileAtomic, in which case we want the default file permissions to be used. I propose that we add openFileTemplate and openBinaryFileTemplate functions, which use the default permissions. Deadline: 8th August (2 weeks). Thanks Ian

5 7

ANNOUNCE: The Haskell Platform 2009.2.0.2
by Don Stewart 01 Aug '09

01 Aug '09

We're pleased to announce the third release of the Haskell Platform: a single, standard Haskell distribution for everyone. The specification, along with installers (including Windows and Unix installers for a full Haskell environment) are available. Download the Haskell Platform 2009.2.0.2: http://hackage.haskell.org/platform/ The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Since the first release, there have been over 100,000 downloads of the installers. Thanks! -- The Platform Infrastructure Team

1 0

Data.Fixed.Fixed constructor
by Ashley Yakeley 27 Jul '09

27 Jul '09

I'm currently working on updating the Data.Fixed module in base. I am adding Typeable and Data instances (automatically derived), and several new HasResolution types (including one for 10^-2, monetary currencies being an obvious Fixed use). The Fixed type is simply a newtype of Integer. Should I expose its MkFixed constructor? Against: * MkFixed is not used in numerical calculation, and isn't itself a conversion function from Integer (obviously). * Ratio doesn't expose its constructor. For: * It's possible to recreate it anyway. * There's a Data instance, so morally the constructor is exposed. -- Ashley Yakeley

4 15

ANN: bindings-posix 0.0.2
by Maurício 27 Jul '09

27 Jul '09

bindings-posix is a low level binding to Posix. http://hackage.haskell.org/package/bindings-posix It is part of bindings-* packages, and makes use of facilities and design from package bindings-common to map the standard Posix library as described in this page: http://www.opengroup.org/onlinepubs/9699919799/basedefs/contents.html The major drawback is that it bindings to the Posix instance that runs on my computer (and probably most computers using ghc and gcc). However, if there's interest, I can add support to various layers of Posix if someone with knowledge of Posix helps me with environment variables I should use to (de)activate specific functionality. Best, Maurício

1 0

ANN: bindings-common 0.2.1
by Maurício 27 Jul '09

27 Jul '09

bindings-* packages provide low level bindings to well known foreign libraries like sqlite3 and libusb. They are supposed to be used by high level module developers who needs special functionality already available outside Haskell. Natural examples of such modules would be higher level versions of such bindings. bindings-common offers basic code that makes writing such packages easier, and provide a common design standard. http://hackage.haskell.org/package/bindings-common The major new feature of this release is the availability of hsc2hs custom macros, and a corresponding big reduction in code size. As an example, the code below is all that is necessary to write a Haskell version of a C struct, with Storable instance: -- This is 'hostent' struct from posix <netdb.h>: #bindings_starttype struct hostent #bindings_field h_name , CString #bindings_field h_aliases , Ptr CString #bindings_field h_addrtype , CInt #bindings_field h_length , CInt #bindings_field h_addr_list , Ptr CString #bindings_stoptype _ That results in http://hackage.haskell.org/packages/archive/bindings-posix/0.0.2/doc/html/B… Those hsc2hs macros have been used to map the standard C library (see module Bindings.C), as well as posix standard library (in a separate package), and are made available to modules depending on bindings-common. Best, Maurício

1 0

Haskell Platform progress report
by Don Stewart 26 Jul '09

26 Jul '09

I've tried to summarise the last 3 months of HP activity: http://donsbot.wordpress.com/2009/07/26/haskell-platform-progress-report/ Including download statistics to inspire the packaging teams prior to this week's release :-) -- Don

1 0

PROPOSAL: export copyPermissions from System.Directory
by Ian Lynagh 24 Jul '09

24 Jul '09

Hi all, This proposal is: export copyPermissions from System.Directory http://hackage.haskell.org/trac/ghc/ticket/3392 (originally part of http://hackage.haskell.org/trac/ghc/ticket/2610) The copyPermissions :: FilePath -> FilePath -> IO () function (currently an internal function) should be exported from System.Directory. It is not the same as getPermissions s >>= setPermissions d as the Permissions type this uses is lossy. Deadline: 8th August (2 weeks). Thanks Ian

1 0

Proposal: ExplicitForall
by Niklas Broberg 24 Jul '09

24 Jul '09

Hi all, (I'm writing this to several lists since it involves GHC (implementation of extensions), cabal (registration of extensions) and some future Haskell standard (formalisation of extensions).) In my quest to implement all known syntactic extensions to Haskell in my haskell-src-exts package, I've become painfully aware of the sometimes ad-hoc nature that these extensions have been added to GHC. This should not be taken as criticism per se, GHC is awesome and I'm sure a lot of thought and research has gone into all of these extensions. I think the problem (from my point of view) is rather that most of the extensions are only really "interesting" on a type system level, whereas the syntactic level is rather trivial, and thus the latter has (rightly) gotten far less formal attention. I hope my putting the light on these issues will be a help and a kickoff towards improving the state of formalisation of the known and registered (with Cabal) extensions. One of the most blatant and (to me) problematic such issues is the matter of using 'forall'. GHC has a number of extensions relating to the use of forall-quantified types in various interesting ways. With none of these extensions on, forall is not considered a keyword, so the syntax with explicit forall quantification cannot be used at all ('forall' is considered a varid). However, with *any* extension on that relates to forall-quantified types, forall is a keyword, and can syntactically be used in types *anywhere*. This doesn't mean all such types will pass the type checker, most of them won't in fact, but syntactically there is really no (or at least very little) difference. Conceptually, all of these extensions (specifically PolymorphicComponents, Rank2Types, RankNTypes, LiberalTypeSynonyms and ScopedTypeVariables (and strangely also ExistentialQuantification)) thus have one thing in common. They all enable syntactically forall-quantified types. They allow different uses of these types as far as the type system is concerned, but syntactically there is no difference between type and type (in fact there cannot be, as I discussed in a recent blog post [1]). Funnily enough there are also some uses of forall-quantified types that are common to all of these extensions - using a forall just to make polymorphism explicit in a type doesn't change anything as far as the type system is concerned, so e.g. the types '(Eq a) => a -> Bool' and 'forall a . (Eq a) => a -> Bool' are equivalent. The latter type can be given to a function when any of the listed six extensions are given, even if most of them have nothing to do with this at all! So, what I'm getting at is an idea that Isaac Dupree gave as a comment to my blog post. He said: "I wish there was a plain old ExplicitForall extension that enabled the keyword in types (without extending the type checker -- only like (id :: forall a. a -> a) would be allowed)". I think this is a really great idea. I find it conceptually appealing, since I think it covers exactly that blind spot that is the seemingly unintended intersection between all these extensions. And it also makes the separation of concern between the syntactic level and the type system more clear. Any formalisation of any of the type system extensions would not need to bother with syntactic details, but can simply be said to imply ExplicitForall. I would thus like to propose the following formalisation of the ExplicitForall extension: ========================================= ExplicitForall enables the use of the keyword 'forall' to make a type explicitly polymorphic. Syntactically, it would mean the following change to Haskell 98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: type -> 'forall' tyvars '.' type | context '=>' type | ftype ftype -> btype '->' type | btype gendecl -> vars '::' type It does not allow the use of explicitly polymorphic types in any way not already allowed by Haskell 98 for implicitly polymorphic types. ========================================= One thing to note is that I haven't touched the matter of ExistentialQuantification in the above. Syntactically this is a different beast entirely, and could well be handled separately, though it's really an artifact of the way we (by default) write our data type declarations. Using GADT-style declarations, existential quantification goes nicely along with the others by following the same syntactic rules for types, even though from a type system it is of course still quite different from the rest. But with the ordinary Haskell 98 declaration style, we could define the syntactic part of the ExistentialQuantification extension as the following: ========================================= ExistentialQuantification allows data constructors to take existentially quantified arguments. Syntactically, it means the following changes to Haskell98: * 'forall' becomes a reserved word. * '.' (dot) becomes a special (not reserved) operator. * The following syntactic rule changes: constrs -> econstr_1 '|' ... '|' econstr_n econstr -> ['forall' tyvars '.' [context '=>']] constr ========================================= My hope is that you'll all agree with me on the need and rationale for the ExplicitForall extension, and that my proposal for formalisation is good enough for adoption. I feel much less strongly about ExistentialQuantification, and would love to hear some more input on that matter, but I do think it needs to be addressed one way or the other. Thoughts? Cheers, /Niklas [1] http://nibrofun.blogspot.com/2009/06/whats-in-forall.html

5 6