AntC | 1 Feb 07:52 2012
Picon

Re: Records in Haskell - namespacing for fields

John Lask <jvlask <at> hotmail.com> writes:

> 
> On 1/02/2012 12:26 AM, AntC wrote:
> >
> > No! no! no! For records _don't_ put records in nested/sub-modules, and 
_don't_
> > require them in separate modules (as currently). Here's how ...
> >
> 
> namespace management and record systems are intimately related, but as 
> you assert distinct issues.
> 
> taking your example of Customer_id, I expressly want to be able to 
> define in the same syntactic module (file). Two records with a field 
> with exactly the same name at two different types, say Customer_id :: 
> Int and Customer_id :: String. As I understand it, your proposal
> would not enable this.

John, you can't do this now. You can't even define in the same module two 
records with the same name with the _same_ type.

[I'd better check first why you've put Customer_id with upper case, that's a 
type, not a field. Are you sure what you're talking about?]

I'd certainly dispute that there's anything sensible in doing that (why? 
what's the use case?), and I guess my proposal is not making that easy, but it 
is possible (and in fact no more difficult than a 'fixed' type for a field).

You'd go:
(Continue reading)

Evan Laforge | 1 Feb 08:05 2012
Picon

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

So it embarrasses me to admit it, but I'm having the same problem I
always have when I install a new ghc, and that's cabal and cabal
install.

I downloaded the latest cabal-install from
http://hackage.haskell.org/package/cabal-install and that was a
mistake right off.  After fiddling around I figured out I apparently
need the one bundled with ghc... and sure enough, the source version
has a cabal-install-0.13.3.  This one has newer but also has out of
date dependencies:

Configuring cabal-install-0.13.3...
Setup.hs: At least the following dependencies are missing:
Cabal >=1.13.3 && <1.14,
base >=2.0 && <2.2,
filepath >=1.0 && <1.3,
time >=1.1 && <1.3,

But shouldn't cabal-install be updated for the version of ghc it's
with?  I cloned branch 7.4 and did a ./sync-all pull so I should have
the latest version, right?  And how are other people testing this out
if cabal-install has out of date dependencies?  And strangest, why is
the 'base' dependency so old?

And while I'm wondering about cabal, why on earth is it that so many
Setup.hs files are actually Setup.lhs and with no actual literate
contents?

Oh, and before I could have any of those problems, the binary
distribution itself didn't want to install: it was evidently compiled
(Continue reading)

Andres Löh | 1 Feb 09:00 2012

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

Hi there.

First of all: I'm aware that the current situation with cabal-install
is suboptimal and a new release it desperately needed.

Still, some general advice and attempts at explaining strange behaviour:

On Wed, Feb 1, 2012 at 8:05 AM, Evan Laforge <qdunkan <at> gmail.com> wrote:
> So it embarrasses me to admit it, but I'm having the same problem I
> always have when I install a new ghc, and that's cabal and cabal
> install.

Whenever you install GHC successfully, you *have* a version of Cabal
(the library) already. It's used by GHC to build GHC. There shouldn't
be any need to touch it. For the current GHC 7.4.1 release candidate,
that version is 1.14.0.

About cabal-install:

> I downloaded the latest cabal-install from
> http://hackage.haskell.org/package/cabal-install and that was a
> mistake right off.

Assuming you upgraded, you probably had an old version of
cabal-install. You should be able to keep using it for the time being.
The cabal binary picks up the GHC that's currently in path (or the one
you explicitly specify via --with-ghc). There's no requirement to use
it with the GHC version that it has been built with.

> After fiddling around I figured out I apparently
(Continue reading)

Simon Peyton-Jones | 1 Feb 11:40 2012
Picon

RE: ANNOUNCE: GHC 7.4.1 Release Candidate 2

Austin

The ticket (#5719) says "merge if you like but I don't think it's needed".  No one complained at the time, so
Ian didn't merge it.  He's tried merging just the patches you identify, but they don't merge cleanly any
more. So I'm afraid this particular fix won't be in 7.4.  Sorry.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of Austin Seipp
| Sent: 29 January 2012 02:27
| To: glasgow-haskell-users <at> haskell.org
| Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2
| 
| Hello again Ian,
| 
| I noticed that in December, Bas van Dijk reported a bug in the
| implementation of ConstraintKinds/associated type defaults, and the
| fix wasn't merged to 7.4.1.
| 
| The relevant email thread is archived here:
| 
| http://www.haskell.org/pipermail/glasgow-haskell-users/2011-
| December/021318.html
| 
| The relevant trac ticket is #5719 here:
| 
| http://hackage.haskell.org/trac/ghc/ticket/5719
| 
(Continue reading)

Simon Peyton-Jones | 1 Feb 13:54 2012
Picon

RE: Impredicative types error

John

Impredicative polymorphism has always been a soggy area of GHC -- the mixture of type inference and
impredicativity is a genuinely difficult problem as you'll see from reading the papers.  GHC 7 is less
ambitious than GHC 6, and does a bit less.  

Tim Sheard, Dimitrios Vytiniotis and I are working on a solid story.   But meanwhile GHC's current
implementation is a bit unpredictable, frankly.

My advice: use a newtype to wrap up the polymorphism:

newtype Denamer = MkD (forall n. Denamable n => n -> n)

getDeName :: Tc Denamer

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of John Meacham
| Sent: 31 January 2012 20:58
| To: glasgow-haskell-users <at> haskell.org
| Subject: Impredicative types error
| 
| Hi, I am running into an issue where some code that compiled and
| worked under 6.12 is failing under 7.0, the offending code is
| 
| class DeNameable a where
|     deName :: Module -> a -> a
| 
(Continue reading)

Ian Lynagh | 1 Feb 14:22 2012
Picon

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

On Wed, Feb 01, 2012 at 09:00:05AM +0100, Andres Löh wrote:
> 
> I wasn't actually aware that cabal-install is included in the ghc tree
> and can be pulled via sync-all.

It's only in the GHC tree because it lives in the same darcs repository
as Cabal (the library) now. The code in the GHC tree is not intended to
be used.

Thanks
Ian
Simon Peyton-Jones | 1 Feb 16:54 2012
Picon

RE: ANNOUNCE: GHC 7.4.1 Release Candidate 2

Trac #5623 is very much on my radar; it's just that I have been too snowed under to get to it.  It's not entirely
straightforward because the inlining machinery needs careful modification, lest one fix one
performance bug only to introduce another.

So the bug is still in 7.4 I'm afraid.  I will get to it, but I'm very interested to have feedback from anyone who
actually trips over it in practice; if you do, please add to the ticket.
	http://hackage.haskell.org/trac/ghc/ticket/5623

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of Rene de Visser
| Sent: 30 January 2012 19:15
| To: glasgow-haskell-users <at> haskell.org
| Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2
| 
| What are the plans for http://hackage.haskell.org/trac/ghc/ticket/5623 which
| seems to be still open?
| 
| Quoting form the ticket ...
| Just to spam a little more, it seems that the HEAD happily duplicates all
| computations on unboxed types. It even duplicates x+x in this example:
| 
| foo :: Float -> Float
| foo x = let y = x+x in y+yI haven't tested but this looks bad for
| performance critical code.
| 
| Rene.
| 
(Continue reading)

Simon Hengel | 1 Feb 17:16 2012
Picon

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

> And while I'm wondering about cabal, why on earth is it that so many
> Setup.hs files are actually Setup.lhs and with no actual literate
> contents?

Are you referring to the classical pattern, that allows you to add a
shebang?

    #!/usr/bin/env runhaskell

    > import Distribution.Simple
    > main = defaultMain

Cheers,
Simon
Evan Laforge | 1 Feb 19:08 2012
Picon

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

>> I downloaded the latest cabal-install from
>> http://hackage.haskell.org/package/cabal-install and that was a
>> mistake right off.
>
> Assuming you upgraded, you probably had an old version of
> cabal-install. You should be able to keep using it for the time being.
> The cabal binary picks up the GHC that's currently in path (or the one
> you explicitly specify via --with-ghc). There's no requirement to use
> it with the GHC version that it has been built with.

In fact it's a new install from scratch, no previous ghc.  I didn't
see why I should install a bunch of stuff I didn't plan on using (I do
main development on another machine), but maybe I should have
installed the platform first, and then replaced the ghc.

>> After fiddling around I figured out I apparently
>> need the one bundled with ghc... and sure enough, the source version
>> has a cabal-install-0.13.3.
>
> The current development version is indeed at 0.13.3, but since it's in
> development, your copy might or might not have the latest patches. The
> definitive darcs repository for both Cabal and cabal-install is at:
>
>  darcs get http://darcs.haskell.org/cabal/

Ah, I'll give that a try as soon as I get back home.

>> And how are other people testing this out
>> if cabal-install has out of date dependencies?  And strangest, why is
>> the 'base' dependency so old?
(Continue reading)

Simon Hengel | 1 Feb 20:13 2012
Picon

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

> I just type runghc on everything and it seems like a lot of those
> don't have the executable bit set, so I hadn't thought of that reason.

I think this is most eminent with Darcs repos.  Darcs can't revision
file permissions (--set-scripts-executable tries to remedy that).

Cheers,
Simon

Gmane