Re: Fwd: Suitable new name for Dimensional library

On Fri, 28 Sep 2007, Björn Buckwalter wrote:

> Taken further though, if someone develops another "static" unit
> library where should they put it? An arbitrarily complex tree of
> namespaces could be built trying to distinguish libraries to
> anticipate future clashes.
>
> This leads me to wonder -- is it better for a library to have a more
> or less arbitrary differentiating name rather than a descriptive name?
> Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'.
>> From their names it's not obvious what distinguishes them from other
> parsers in the same namespace but at least the tree is fairly flat and
> hopefully narrowed down enough to permit investigating each
> alternative. In the units case I imagine
> 'Numeric.Units.SomethingArbitrary' would be appropriate.

Indeed, someone might implement static unit checking by a different 
approach. We cannot predict this. So actually it seems to be better to use 
an arbitrary differentiating name, say

Numeric.Units.Bucky
Numeric.Units.Lemming

Using module names which describe only the module function might work if 
there is consensus on its relevance and its API. That is, only for very 
basic modules of a 'standard library'.

_______________________________________________
Libraries mailing list

Control.Monad, Control.Applicative vs. Data.Foldable, Data.Traversable

What is the reason for some of the standard type classes being in 'Data' 
folder and some in 'Control'? Since, say 'Reader' is a monad, an 
applicative thing, an arrow and an instance of other classes - why is it 
located in Control.Monad? Why not Data.Reader? I find it reasonable to 
have a directory for concrete data types and one directory for classes. 
Currently I cannot see, why the Reader data type is in Monad, Monad is in 
Control, but Foldable class is in Data, together with List, Tree and other 
concrete data types.

Re: Proposal: Fix abstract unix sockets (#1699)

Ian Lynagh wrote:
> Hi Lennart,
> 
> On Sun, Sep 16, 2007 at 10:16:40AM +0100, Lennart Kolmodin wrote:
>> I've added proposal #1699 to fix abstract unix sockets on Linux for the
>> network library.
> 
> You haven't suggested a deadline; between the GHC release and ICFP et al,
> perhaps 15 Oct would make sense?

Sounds excellent.

>> The patch is so far only tested under Linux (2.6.15), but should not
>> affect Windows or other OSes which does not have AUS.
> 
> So if I understand correctly, with this patch certain paths would be
> treated differently, but only on Linux machines? If someone tries to use
> AUS on a non-Linux system, will things break horribly? i.e. would it be
> better to have a separate package/module for this Linux-specific
> behaviour?

I expect an exception will be thrown by 'connect' if you try to use a
AUS on a non-linux box.
The user only difference for the users is that they can now prefix their
UnixPath with a zero. So no change of the API, iirc.
A technique previously used is to create a new constructor for AUS and
simply not expose it on systems that doesn't support it. This requires
the portability-aware devs to #ifdef on the target platform.

>> Also, due to much more socklen usage:

X11 package

I've taken over maintainership of the X11 package, as we need it for
xmonad. The previous maintainer was libraries <at> . Let me know if you've
any problems with this.

-- Don

Re: Hackage and GHC 6.8

On Sep 25, 2007, at 10:38 , Ross Paterson wrote:

> On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote:
>> Neil Davies wrote:
>>> Given that GHC 6.8 is just around the corner and, given how it has
>>> re-organised the libraries so that the dependencies in many (most/ 
>>> all)
>>> the packages in the hackage DB are now not correct.
>>>
>>> Is there a plan of how to get hackage DB up to speed with GHC 6.8 ?
>>
>> Ian, GHC HQ, can you elaborate on what the plan is on fixing the  
>> hackage
>> libraries for ghc 6.8 -- should everyone be springing into action to
>> update .cabal files and fix api changes?
>
> I'm a bit confused about the version numbering for the boot libraries.
> The versions bundled with various versions of GHC are:
>
> ghc-6.6:        base-2.0   template-haskell-2.0 unix-1.0
> ghc-6.6.1:      base-2.1.1 template-haskell-2.1 unix-2.1
> ghc-6.8 RC:     base-2.1   template-haskell-0.1 unix-2.0
>
> What versions are planned for the release?

This seems quite broken. It makes writing Cabal configurations messy.  
base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and  
presumably >= 2.2) are the split up base. Add to this that bytestring  
was in base == 2.0 (not <=2.0) and in == 2.1.1.

Re: Hackage and GHC 6.8

bringert:
> On Sep 25, 2007, at 10:38 , Ross Paterson wrote:
> 
> >On Sun, Sep 23, 2007 at 06:02:13PM -0700, Don Stewart wrote:
> >>Neil Davies wrote:
> >>>Given that GHC 6.8 is just around the corner and, given how it has
> >>>re-organised the libraries so that the dependencies in many (most/ 
> >>>all)
> >>>the packages in the hackage DB are now not correct.
> >>>
> >>>Is there a plan of how to get hackage DB up to speed with GHC 6.8 ?
> >>
> >>Ian, GHC HQ, can you elaborate on what the plan is on fixing the  
> >>hackage
> >>libraries for ghc 6.8 -- should everyone be springing into action to
> >>update .cabal files and fix api changes?
> >
> >I'm a bit confused about the version numbering for the boot libraries.
> >The versions bundled with various versions of GHC are:
> >
> >ghc-6.6:        base-2.0   template-haskell-2.0 unix-1.0
> >ghc-6.6.1:      base-2.1.1 template-haskell-2.1 unix-2.1
> >ghc-6.8 RC:     base-2.1   template-haskell-0.1 unix-2.0
> >
> >What versions are planned for the release?
> 
> This seems quite broken. It makes writing Cabal configurations messy.  
> base <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and  
> presumably >= 2.2) are the split up base. Add to this that bytestring  
> was in base == 2.0 (not <=2.0) and in == 2.1.1.

Re: Hackage and GHC 6.8

On Mon, Oct 08, 2007 at 11:10:02PM +0200, Bjorn Bringert wrote:
> On Sep 25, 2007, at 10:38 , Ross Paterson wrote:
>> I'm a bit confused about the version numbering for the boot libraries.
>> The versions bundled with various versions of GHC are:
>>
>> ghc-6.6:        base-2.0   template-haskell-2.0 unix-1.0
>> ghc-6.6.1:      base-2.1.1 template-haskell-2.1 unix-2.1
>> ghc-6.8 RC:     base-2.1   template-haskell-0.1 unix-2.0
>>
>> What versions are planned for the release?
>
> This seems quite broken. It makes writing Cabal configurations messy. base 
> <= 2.0 and == 2.1.1 are the monolithic base. base == 2.1 (and presumably >= 
> 2.2) are the split up base. Add to this that bytestring was in base == 2.0 
> (not <=2.0) and in == 2.1.1.
>
> Is there any reason not to bump the base that comes with GHC 6.8 to 
> base-2.2?

To allow specifying conservative dependencies, it is also necessary to
specify for each boot package the range of version numbers that can ship
with GHC 6.8.x (all guaranteed to have the same interface).  And, when
GHC 6.8.1 is released, to advance the version numbers of these packages
in the HEAD beyond these ranges.

Re: Fwd: Suitable new name for Dimensional library

Henning, all,

I decided to go with 'Numeric.Units.Dimensional'. I feel that
'Dimensional' provides sufficient differentiation as unit libraries go
and the preceding 'Numeric.Units' takes care of my concern of
'Dimensional' being too vague.

Thanks all for your inputs!

I've released dimensional-0.7 with the new module name space and a few
small additions w.r.t. version 0.6. It can be downloaded from the
project homepage[1] or hackage.

Regards,
Bjorn Buckwalter

[1] http://dimensional.googlecode.com/

On 10/1/07, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:
>
> On Fri, 28 Sep 2007, Björn Buckwalter wrote:
>
> > Taken further though, if someone develops another "static" unit
> > library where should they put it? An arbitrarily complex tree of
> > namespaces could be built trying to distinguish libraries to
> > anticipate future clashes.
> >
> > This leads me to wonder -- is it better for a library to have a more
> > or less arbitrary differentiating name rather than a descriptive name?
> > Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'.

Trying to install binary-0.4

In my copious free time I'm putting together a client-side library for 
AMQP.  This needs efficient packing of bytestrings, so I downloaded 
Dons' bytestring 0.4.  Unfortunately it won't install: I get

[paj <at> eiffel binary-0.4]$ ./Setup.lhs configure
Configuring binary-0.4...
configure: Dependency base-any: using base-2.1.1
Setup.lhs: cannot satisfy dependency containers-any

Should this be "collections" not "containers"?  I can't find a 
"containers" package in Hackage.

Paul.

Re: Trying to install binary-0.4

In the latest version of GHC (6.8) the base library was split up into
many smaller libraries. Among them containers. Your problem is
probably related to that. I don't have my Haskell setup nearby
unfortunately so I can't tell you exactly what the problem is.

-- Johan

On 10/10/07, Paul Johnson <paul <at> cogito.org.uk> wrote:
> In my copious free time I'm putting together a client-side library for
> AMQP.  This needs efficient packing of bytestrings, so I downloaded
> Dons' bytestring 0.4.  Unfortunately it won't install: I get
>
> [paj <at> eiffel binary-0.4]$ ./Setup.lhs configure
> Configuring binary-0.4...
> configure: Dependency base-any: using base-2.1.1
> Setup.lhs: cannot satisfy dependency containers-any
>
>
> Should this be "collections" not "containers"?  I can't find a
> "containers" package in Hackage.
>
> Paul.
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>