Sean Leather | 1 Nov 01:39 2008
Picon

Re: darcs patch: Added list operations for arrows


I also agree with you. See, for example, EMGM's use of generic versions of
Prelude functions.

What is EMGM?

My apologies for not providing the appropriate link.

  http://www.cs.uu.nl/wiki/GenericProgramming/EMGM

In summary: datatype-generic programming using type classes with a sum-of-products view.

Sean
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Duncan Coutts | 1 Nov 16:12 2008
Picon
Picon

Re: darcs patch: Added list operations for arrows

On Fri, 2008-10-31 at 16:17 +0100, Sean Leather wrote:
> 
>         > Here here!
>         >
>         > 'A.filter' rather than 'filterA' (with a suitable qualified
>         import).
>         >
>         > Duncan
>         
>         
>         Hmm, is this meant ironically or seriously?  Sorry, I just
>         don't know.
> 
> I believe this is a Duncan-esque form of agreement with your
> recommendation.

Indeed :-)

Sorry for the ambiguity.

I kind of accept some of the fooM functions since they've been there for
so long, but new ones make me itch to fix them.

Duncan
Duncan Coutts | 1 Nov 21:58 2008
Picon
Picon

Re: HUnit in Hackage

On Wed, 2008-10-22 at 14:45 -0700, Duncan Coutts wrote:
> On Tue, 2008-10-21 at 16:53 -0700, Jon Strait wrote:
> > Just some quick user feedback/questions.
> > 
> > The current HUnit in Hackage depends on base (==4.*).  I'm running  GHC
> > 6.8.3 with base 3.0.2.0.   Is there an easier way to upgrade base
> > without rebuilding GHC?  Otherwise, the Cabal upgrade refuses to work
> > unless I uninstall my older HUnit completely, do the Cabal upgrade, then
> > re-install the older HUnit.  I have other packages which depend on
> > HUnit, so this must be done every time.  Or is there a way to tell Cabal
> > Install that I want to mask off HUnit for upgrading when I do a Cabal
> > upgrade?
> 
> I've updated the hunit package so that the latest version will build
> with either base 3 or 4 (ie with ghc-6.8 or 6.10).
> 
> I'll upload that to hackage soon.

Now done, it should work with all recent versions of ghc (since 6.6).

Duncan
Don Stewart | 3 Nov 05:47 2008

Arch Haskell News: Nov 02 2008

News about the Haskell packages for Arch Linux.

Highlights,

    * 672 Haskell packages now supported in Arch Linux, up 33 from two weeks ago.

Noteworthy,

    * haskell-tcache-0.5.3: “A Transactional data cache with configurable persistence”
    * haskell-yampa-0.9.2.3: “Library for programming hybrid systems.”
    * haskell-network-bytestring-0.1.1.3: “Fast and memory efficient low-level networking”
    * haskell-checkers-0.1.1: “Check properties on standard classes and data structures.”
    * haskell-coreerlang-0.0.1: “Facilities for manipulating Core Erlang source code: an abstract
syntax, parser and pretty-printer.”

Full update list,

    http://archhaskell.wordpress.com/2008/11/03/arch-haskell-news-nov-02-2008/

-- Don

How's your favourite distro doing? If its not up to scratch, talk to someone.
Jules Bean | 5 Nov 10:48 2008
Picon

Re: darcs patch: Added list operations for arrows

Wolfgang Jeltsch wrote:
> Another point is that filterA uses just a single letter for “arrow”.  This 
> concept quickly leads to ambiguities.  For example, in mappend, the “m” 
> stands for “monoid” while in msum, it stands for “monad”.  Something like 
> filterArrow would have the disadvantage that it is longer.  With qualified 
> imports, the user of the library can decide whether to use a single letter 
> (A.filter) or something more descriptive (Arrow.filter).

I would not like this. Let me first say that I *do* understand your 
point. It is certainly ugly to use these funny adhoc namespacing 
techniques. But I think it's less ugly than the alternatives we have, 
because:

Our module system - or at least our module import/export system - is not 
sufficiently expressive.

I would definitely not like to have to use

Monoid.append
Arrow.filter
Monad.filter
Monad.map

...just on grounds of verbosity. Too many characters = ugly code.

But the alternative - to use short module aliases - does not scale well. 
I need to add appropriately qualified import statements to every single 
module in my project. We can't reexport qualifications.

;-(

I'm interested in suggestions on how we could make our namespace 
management better so that this problem is more manageable.

Jules
Johannes Waldmann | 5 Nov 22:34 2008
Picon

System[.Posix].Process question

Hello.

I am looking for something like System.Process.runInteractiveProcess
(which gives me the in/out/err handles, which I like) but instead of 
ProcessHandle,
I want a System.Posix.Types.ProcessID because I want to send a specific 
signal later.
It seems that to a ProcessHandle I can only send SIGKILL
(via System.Process.terminateProcess), and this is bad
because the target process cannot intercept and handle it.
In my case, it needs to cleanup (namely, kill its children).

Thanks, J.W.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Evan Laforge | 6 Nov 00:08 2008
Picon

Re: darcs patch: Added list operations for arrows

> I would definitely not like to have to use
>
> Monoid.append
> Arrow.filter
> Monad.filter
> Monad.map
>
> ...just on grounds of verbosity. Too many characters = ugly code.

I think that depends a lot on individual taste and what you're used
to.  The above looks fine to me (and I use that style exclusively in
my own code, except infix operators).  It would also probably look
normal to any python programmer.  Even though python supports both
qualified and unqualified, the default is qualified, and it's what
people are used to.

> But the alternative - to use short module aliases - does not scale well. I
> need to add appropriately qualified import statements to every single module
> in my project. We can't reexport qualifications.

Well, you do have to explicitly import every module you use, but
that's true of unqualified import too, so I'm not sure what the not
scaling part here is.  Do you object to the idea that you have to give
each module a name by hand and nothing stops you from being
inconsistent about the names you give one module?  I use the complete
module name with a few exceptions, but even with that I sometimes have
to put a bit of redundancy in module names to not conflict with a
similar name in a neighbor package.

Re-exporting qualified names doesn't seem like it would help... you'd
still get name clashes unless it was done python style like
Mod1.Mod2.f, but that's even more verbose.  However, in a module that
pulls together a lot of other modules using just one or two functions
from each (which is the one likely to do lots of intra package imports
and get clashes), I like the extra verbosity.  The wider the scope of
a name the longer it can be.  It seems to scale just fine for me, and
I have modules that import 40 or so other modules... in fact the more
you import the more I appreciate qualified names.
Dave Tapley | 7 Nov 17:25 2008
Picon

Hello

Hi everyone,

Just signed up to the list having attended the London HUG meet
yesterday. You'll see me in #haskell as DukeDave.

Looking forwards to helping with any menial non-expert tasks to help get
some a Haskell platform up :)

Dave,
Duncan Coutts | 7 Nov 18:04 2008
Picon
Picon

Re: Hello

On Fri, 2008-11-07 at 16:25 +0000, Dave Tapley wrote:
> Hi everyone,
> 
> Just signed up to the list having attended the London HUG meet
> yesterday. You'll see me in #haskell as DukeDave.

Great.

> Looking forwards to helping with any menial non-expert tasks to help get
> some a Haskell platform up :)

I guess we should start by listing the open questions on the wiki page.
That'll help us with our discussion and gives us a place to record
decisions.

Duncan
Johannes Waldmann | 10 Nov 10:09 2008
Picon

parsec 3 vs. 2 - what's the deal?

Hello.

Should I migrate from parsec-2 to parsec-3? Why? And if yes, then how?

The hackage description (of version 3) says "it's well documented ... on
the home page", but when I go there, I find docs for version 2 only.

If I'm still using parsec-2 for teaching, will this harm my students?

J.W.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane