Re: Known problems with promoted tuples and lists in GHC 7.4.1?

[José Pedro Magalhães]

Hi David,

Are you using HEAD? If so, and you run into problems, please report them
(either here or as bugs in trac).


Thanks,
Pedro

On Wed, Jun 6, 2012 at 9:37 PM, David Menendez  wrote:

> Are there any known issues involving type-level pairs and lists? I've
> hit a few baffling type errors that went away when I refactored my
> code to use locally-defined pairs and lists instead of those provided
> by the prelude.
>
> More worryingly, I had one function that would stop passing the type
> checker if I replaced '[n] with (n ': '[]) in its signature.
>
> --
> Dave Menendez 
> 
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Kindness of strangers (or strangeness of Kinds)

[José Pedro Magalhães]

Hi,

On Thu, Jun 7, 2012 at 2:46 AM, AntC  wrote:

>
> What does the `ArgKind' message mean?
>

`ArgKind` and `OpenKind` is what previously was called `?` and `??` (or the
other
way around; I can't remember).
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TypeType#Kindsubtyping

You might also want to have a look at Richard and Stephanie's latest paper
draft, about
singletons, which is related to what you are trying in your example:
http://www.cis.upenn.edu/~eir/papers/2012/singletons/paper.pdf


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Cannot build user's guide

[José Pedro Magalhães]

Hi,

I cannot build the user's guide. Doing make html stage=0 FAST=YES under
docs/users_guide, I get:

===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final html_docs/users_guide
inplace/bin/mkUserGuidePart docs/users_guide/users_guide.xml
inplace/bin/mkUserGuidePart docs/users_guide/what_glasgow_exts_does.gen.xml
"rm" -rf docs/users_guide/users_guide/
"" --stringparam base.dir docs/users_guide/users_guide/ --stringparam
use.id.as.filename 1 --stringparam html.stylesheet fptools.css --nonet
--stringparam toc.section.depth 3 --stringparam section.autolabel 1
--stringparam section.label.includes.component.label 1
http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsldocs/users_guide/users_guide.xml
/bin/sh: 1: : Permission denied
make[2]: *** [docs/users_guide/users_guide/index.html] Error 127
make[1]: *** [html_docs/users_guide] Error 2

It seems like make is just calling an empty program name. What could I be
missing?

(Btw, validate goes through. Does validate not build the user's guide?)


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Cannot build user's guide

[José Pedro Magalhães]

Right, I was lacking the tools.


Thanks,
Pedro

On Mon, Jun 25, 2012 at 6:27 PM, Ian Lynagh  wrote:

> On Mon, Jun 25, 2012 at 02:34:34PM +0100, José Pedro Magalhães wrote:
> >
> > (Btw, validate goes through. Does validate not build the user's guide?)
>
> It only builds it if the tools are available. I think that's mainly
> because they're a bit fiddly to install on Windows.
>
>
> Thanks
> Ian
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type error when deriving Generic for an associated data type

[José Pedro Magalhães]

Hi Bas,

On Thu, Jul 12, 2012 at 11:27 AM, Bas van Dijk  wrote:

> Hi,
>
> I'm hitting on an issue when deriving Generic for an associated data type:
>
> ...
>
> The GHC trac seems to be down. Is this a known issue?
>

Yes, and it's supposed to be fixed in HEAD. Can you try it with HEAD?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADTs in the wild

[José Pedro Magalhães]

Simon,

We rely extensively on GADTs for modelling musical harmony in HarmTrace:

PDF: http://www.dreixel.net/research/pdf/fmmh.pdf
Hackage: http://hackage.haskell.org/package/HarmTrace

Not entirely sure it passes (c), though.


Cheers,
Pedro

On Tue, Aug 14, 2012 at 1:32 PM, Simon Peyton-Jones
wrote:

>  Friends
>
>
> I’m giving a series of five lectures at the Laser Summer 
> School(2-8 Sept), on “Adventures with types 
> in Haskell”.  My plan is:
> 
>
> **1.   **Type classes
>
> **2.   **Type families [examples including Repa type tags]
>
> **3.   **GADTs
>
> **4.   **Kind polymorphism
>
> **5.   **System FC and deferred type errors
>
> ** **
>
> This message is to invite you to send me your favourite example of using a
> GADT to get the job done.  Ideally I’d like to use examples that are (a)
> realistic, drawn from practice (b) compelling and (c) easy to present
> without a lot of background.  Most academic papers only have rather limited
> examples, usually eval :: Term t -> t, but I know that GADTs are widely
> used in practice.
>
> ** **
>
> Any ideas from your experience, satisfying (a-c)?  If so, and you can
> spare the time, do send me a short write-up. Copy the list, so that we can
> all benefit.
>
> ** **
>
> Many thanks
>
>
> Simon
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why is Bag's Data instance "broken"?

[José Pedro Magalhães]

Hi Philip,

On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies
wrote:

> Dear GHCers,
>
> I'm performing traversals over GHC-API results (HsSyn et al). For this
> purpose, I'm using SYB generics.
>
> I found that I couldn't use "ext1Q" for a function with type "Data x =>
> Bag x -> String", i.e. that this function was never applied. The source of
> Bag's instance of the Data class seems to explain why:
>
>
> instance Data a => Data (Bag a) where
>   gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type
> abstractly
>   toConstr _   = abstractConstr $ "Bag("++show (typeOf (undefined::a))++")"
>   gunfold _ _  = error "gunfold"
>   dataTypeOf _ = mkNoRepType "Bag"
>
>
> Is there a rationale to not allow gunfolds and to keep toConstr abstract?


As far as I understand, this is to keep `Bag` itself abstract, preventing
users from inspecting its internals.


> More to the point for my needs, is there a reason to not allow dataCast1
> casting of Bags?
>

That is a separate issue; I believe this instance is just missing a
`dataCast1 = gcast1` line.
All datatypes of kind `* -> *` should have such a definition.

(Having a look at Data.Data, I guess the same applies to `Ptr a` and
`ForeignPtr a`.
And `Array a b` seems to be missing the `dataCast2` method. I propose
fixing all of these.)


Cheers,
Pedro


>
> Regards,
> Philip
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why is Bag's Data instance "broken"?

[José Pedro Magalhães]

On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies
wrote:

> Dear GHCers,
>
> I'm performing traversals over GHC-API results (HsSyn et al). For this
> purpose, I'm using SYB generics.
>
> I found that I couldn't use "ext1Q" for a function with type "Data x =>
> Bag x -> String", i.e. that this function was never applied. The source of
> Bag's instance of the Data class seems to explain why:
>
>
> instance Data a => Data (Bag a) where
>   gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type
> abstractly
>   toConstr _   = abstractConstr $ "Bag("++show (typeOf (undefined::a))++")"
>   gunfold _ _  = error "gunfold"
>   dataTypeOf _ = mkNoRepType "Bag"
>

Btw, where is this instance defined?


Thanks,
Pedro


>
>
> Is there a rationale to not allow gunfolds and to keep toConstr abstract?
> More to the point for my needs, is there a reason to not allow dataCast1
> casting of Bags?
>
> Regards,
> Philip
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why is Bag's Data instance "broken"?

[José Pedro Magalhães]

Right now I was just planning to fix the missing dataCast1 from Bag, and
the rest from
Data.Data (see http://hackage.haskell.org/trac/ghc/ticket/7256). I think
those are just
a bug, unrelated to the abstraction story, no?


Cheers,
Pedro

On Thu, Sep 20, 2012 at 12:19 PM, Edward Kmett  wrote:

> Note: It was probably built with an eye towards how Data.Map and the like
> performed abstraction. However, This isn't necessary to protect the
> invariants of a bag.
>
> The constructors exposed via Data do not have to be the actual
> constructors of the data type. With this you can quotient out the portions
> of the structure you don't want the user to be able to inspect.
>
> See the libraries@ proposal that I put in 3-4 weeks ago (which will have
> just passed) to fix all the broken Data instances for containers by using
> virtual constructors such as 'fromList', (which incidentally led to Milan
> finding huge space and time improvements in fromList).
>
> Effectively allowing the user to use the 'listToBag' as a "constructor"
> loses no information violates no invariants, and prevents code written for
> uniplate, SYB, etc. from having to crash, panic or give up upon the sight
> of a mkNoRepType.
>
> My reaction for years to the sight of a mkNoRepType and undefined gunfold
> has been to hang my head. Now I just fix them.
>
> -Edward
>
> On Wed, Aug 29, 2012 at 7:11 AM, José Pedro Magalhães wrote:
>
>> Hi Philip,
>>
>> On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies <
>> p...@st-andrews.ac.uk> wrote:
>>
>>> Dear GHCers,
>>>
>>> I'm performing traversals over GHC-API results (HsSyn et al). For this
>>> purpose, I'm using SYB generics.
>>>
>>> I found that I couldn't use "ext1Q" for a function with type "Data x =>
>>> Bag x -> String", i.e. that this function was never applied. The source of
>>> Bag's instance of the Data class seems to explain why:
>>>
>>>
>>> instance Data a => Data (Bag a) where
>>>   gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type
>>> abstractly
>>>   toConstr _   = abstractConstr $ "Bag("++show (typeOf
>>> (undefined::a))++")"
>>>   gunfold _ _  = error "gunfold"
>>>   dataTypeOf _ = mkNoRepType "Bag"
>>>
>>>
>>> Is there a rationale to not allow gunfolds and to keep toConstr abstract?
>>
>>
>> As far as I understand, this is to keep `Bag` itself abstract, preventing
>> users from inspecting its internals.
>>
>>
>>> More to the point for my needs, is there a reason to not allow dataCast1
>>> casting of Bags?
>>>
>>
>> That is a separate issue; I believe this instance is just missing a
>> `dataCast1 = gcast1` line.
>> All datatypes of kind `* -> *` should have such a definition.
>>
>> (Having a look at Data.Data, I guess the same applies to `Ptr a` and
>> `ForeignPtr a`.
>> And `Array a b` seems to be missing the `dataCast2` method. I propose
>> fixing all of these.)
>>
>>
>> Cheers,
>> Pedro
>>
>>
>>>
>>> Regards,
>>> Philip
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why is Bag's Data instance "broken"?

[José Pedro Magalhães]

I've now added a dataCast1 method to this instance in HEAD; casting should
now work as expected.


Cheers,
Pedro

On Thu, Sep 20, 2012 at 11:12 AM, Philip Holzenspies
wrote:

>  On 20 Sep 2012, at 09:40, José Pedro Magalhães wrote:
>
>   instance Data a => Data (Bag a) where
>>   gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type
>> abstractly
>>   toConstr _   = abstractConstr $ "Bag("++show (typeOf
>> (undefined::a))++")"
>>   gunfold _ _  = error "gunfold"
>>   dataTypeOf _ = mkNoRepType "Bag"
>>
>
> Btw, where is this instance defined?
>
>
> GHCROOT/compiler/utils/Bag.lhs, lines 266-270 (current git-repo HEAD and
> many versions previously).
>
>  Ph.
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Proposal: EPHEMERAL pragma

[José Pedro Magalhães]

Hi all,

Following up on a chat with Simon Peyton Jones at ICFP, I would like to
discuss the
possible introduction of a EPHEMERAL pragma. For example:

{-# EPHEMERAL Rep #-}
> data Rep = ...
>

This pragma would indicate that the programmer intends the Rep datatype not
to
be present in the final generated core code. Its proposed semantics are the
following:

1. Make the compiler very keen to inline any functions that produce or
consume Rep.

2. If Rep is exported, make all functions that operate on Rep INLINABLE
(that is, make
their code available for inlining in other modules).

3. Emit a warning if the generated core code still contains uses of Rep.

My main use case for such a pragma is in the generic representation of
datatypes in
GHC.Generics. It's clear that we don't want sums and products lying around
in user
code, and in most cases we can get rid of them by inlining aggressively.
Hopefully
such a pragma can simplify or entirely replace the use of INLINE/INLINABLE
pragmas
in some cases.

However, I'm not sure how well this can work in practice. Regarding (3),
for instance,
it's clear that functions that operate on Rep will be around in the final
core code;
perhaps only functions which do not directly produce or consume Rep, yet
end up
having values of Rep within them, should trigger a warning.

(1) is hard to do well, in general. In particular when there are rewriting
rules involving
values of Rep, or functions that produce/consume Rep, the order in which
they are
inlined might affect the elimination of Rep values.

In any case, I thought I'd share this with this list, in the hope to get
feedback regarding
how to improve the inliner (and the feedback programmers get regarding
inlining).


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Problems translating Conor McBride's talk into Haskell + DataKind + KindPoly

[José Pedro Magalhães]

Hi,

Please use GHC 7.6 for experimenting with PolyKinds/DataKinds; the
implementation in 7.4 was not fully complete. Your code compiles fine in
7.6.


Cheers,
Pedro

On Fri, Oct 26, 2012 at 3:10 AM, Ahn, Ki Yung  wrote:

> Promotion works for user defined lists such as
>
> data List a = Nil | Cons a (List a)
>
> And, if I use (List Bool) instead of [Bool] everything works out.
> It's only the Haskell list type constructor [] is being a problem.
>
> In the "Giving Haskell a promotion" paper, it says that Haskell lists are
> "natively promoted". I believe this means that it is treated specially
> somehow. I don't know how it is implemented but what GHC 7.4.1 does
> specially for Haskell lists has some problems. So, it's clearly not a
> limitation of DataKind and PolyKind extension, but that special routine for
> [] is the issue.
>
> I might have to write bug report.
>
>
> On 2012년 10월 25일 18:07, Ahn, Ki Yung wrote:
>
>> Most part of Conor's talk at ICFP, until just before the last stage
>> where he heavily uses true value dependency for compiler correctness all
>> the code seemed to be able to translate into Haskell with the new hot
>> DataKinds and PolyKinds extension.
>>
>> I tried it in GHC 7.4.1 and it was possible to do it, but I got stuck
>> and I had to make the generic list structure mono-kinded with kind
>> signatures rather not use the PolyKinds extension.
>>
>> I wonder if this is just a but of GHC 7.4.1's implementation of
>> PolyKinds, or a limitation of the DataKind design.
>>
>> I attached a literate Haskell script with this message that illustrates
>> this problem.
>>
>> Thanks in advance for any comments including whether it runs in later
>> versions or still has problems, and discussions about the DataKinds and
>> PolyKinds extension.
>>
>> Ki Yung
>>
>>
>> __**_
>> Haskell-Cafe mailing list
>> haskell-c...@haskell.org
>> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>>
>
>
>
> __**_
> Haskell-Cafe mailing list
> haskell-c...@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Using GHC.TypeLits and singletons

[José Pedro Magalhães]

Hi Iavor and Richard (CC ghc-users),

If I recall correctly, Richard designed his singletons package in such a
way that it would interact nicely
with Iavor's type-level literals. Now I find myself in a situation where I
need to use both type-level literals
and singletons (basically because I'm reflecting at the value level both
naturals, strings, and more
complicated datatypes). But I see that the declarations of entities such as
Sing, SingI, etc., are
duplicated in the singletons package (seeing that they are already in GHC
7.6 within GHC.TypeLits).
My question is: how can I use these two together?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Kind refinement in type families with PolyKinds

[José Pedro Magalhães]

Hi all,

I'm wondering why the following does not work:

{-# LANGUAGE DataKinds  #-}
> {-# LANGUAGE PolyKinds  #-}
> {-# LANGUAGE KindSignatures #-}
> {-# LANGUAGE TypeFamilies   #-}
> {-# LANGUAGE GADTs  #-}
> {-# LANGUAGE TypeOperators  #-}
>
> module Bug where
>
> -- Type equality
> data a :=: b where Refl :: a :=: a
>
> -- Applying a type to a list of arguments
> type family Apply (t :: k) (ts :: [*]) :: *
> type instance Apply t '[]   = t
> type instance Apply (f :: * -> *) (t ': ts) = f t
>
> -- Stripping a type from all its arguments
> type family Strip (t :: *) :: k
> type instance Strip (Maybe a) = Maybe
>
> -- Reapplying a stripped type is the identity
> x :: Apply (Strip (Maybe a)) (a ': '[]) :=: Maybe a
> x = Refl
>

If I ask GHCi for the kind of `Strip (Maybe Int)`, I get `k`, whereas I
would expect `* -> *`.
That explains why the `Apply` type family is not reduced further.

I understand that this might be related to GADTs not being allowed to
refine kinds;
the following datatype fails to compile with the error "`D1' cannot be
GADT-like
in its *kind* arguments":

data DStrip :: k -> * where
>   D1 :: DStrip Maybe
>

But then, shouldn't the type instance for `Strip` above trigger the same
error?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Generating random type-level naturals

[José Pedro Magalhães]

Hi Eric,

I'm not sure I fully understand what you want to do, so let me ask a basic
question:
have you considered just using an Arbitrary instance of HsExpr? How would
that
compare to what you are trying to achieve?


Cheers,
Pedro


On Mon, Nov 5, 2012 at 11:23 PM, Eric M. Pashman wrote:

> I've been playing around with the idea of writing a genetic programming
> implementation based on the ideas behind HList. Using type-level
> programming, it's fairly straighforward to put together a program
> representation that's strongly typed, that supports polymorphism, and that
> permits only well-typed programs by construction. This has obvious
> advantages over vanilla GP implementations. But it's impossible to generate
> arbitrary programs in such a representation using standard Haskell.
>
> Imagine that you have an HList-style heterogenous list of arbitrarily
> typed Haskell values. It would be nice to be able to pull values from this
> collection at random and use them to build up random programs. But that's
> not possible because one can't write a function that outputs a value of
> arbitrary type. (Or, more or less equivalently, one can't write dependently
> typed functions, and trying to fake it at the type-level leads to the
> original problem.)
>
> One can, however, write a bit of Template Haskell to construct a random
> HNat. Something like,
>
> hNat 0 = [| hZero |]
> hNat n = [| hSucc $(hNat (n - 1)) |]
>
> Call that with a random positive integer inside a splice and Template
> Haskell will give you a random HNat that you can use to index an HList.
> There's your arbitrary Haskell value.
>
> But this technique is of little practical value since it only works at
> compile-time. I've fiddled around with the hint library, trying to
> interpret the Template Haskell to get random HNats at run-time. This works,
> sort of, but there's no way to "liberate" the generated HNat because hint's
> `interpret` function requires a type witness. A look-alike string from the
> `eval` function is as close as you can get.
>
> Is there some dirty trick provided by the GHC API that would allow me to
> bind the generated HNat to a name and pass it around in a way similar to
> what GHCi seems to do? I realize that I probably have a grossly optimistic
> idea of what magic GHCi is performing when it interprets user input in a
> way that seems to allow this sort of thing.
>
> To summarize, I'm basically trying to wrap up the following process
> programmatically:
>
> ghci> n <- randomInt   -- A random Int
> ghci> :load SomeModule.hs  -- Contains `hNat` as above
> ghci> let hn = $(hNat n)   -- Voila, a random HNat
> ghci> ...  -- Do stuff with `hn`, then repeat
>
> Is something along the lines of what I'm imagining possible? If not, can I
> get close enough for my purposes?
>
> General insights and commentary are welcome as well.
>
> Regards,
>
> Eric
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Promoted types accepted without language extensions

[José Pedro Magalhães]

Hi Sean,

On Mon, Nov 19, 2012 at 2:18 PM, Sean Leather  wrote:

> We discovered that GHC and GHCi (7.4.1) accept promoted types without
> specifying language extensions (and even when specifying -XHaskell98).
>
> For example, promoted lists are accepted:
>
> Prelude> type T = [Int,Char]
> Prelude> :i T
> type T = (:) * Int ((:) * Char ([] *))
>   -- Defined at :2:6
>

This is rejected in 7.6.1:

:2:10:
Illegal type: '[Int, Char] Perhaps you intended to use -XDataKinds


>
> Also, promoted datatypes:
>
> > data N = Z
> > type T = 'Z
>

This isn't rejected, but I guess it should, indeed.


Thanks,
Pedro


>
> I'm guessing you can't use these types anywhere (since they are not kind
> *), so they won't be very useful, but it seems like this should be
> disallowed.
>
> Regards,
> Sean
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter

[José Pedro Magalhães]

I have the same opinion as Ian; I'm happy with the current setup, but if
things
change I'll just subscribe to everything anyway.


Cheers,
Pedro

On Thu, Dec 6, 2012 at 4:55 PM, Ian Lynagh  wrote:

> On Thu, Dec 06, 2012 at 06:25:49PM +0200, Roman Cheplyaka wrote:
> >
> > +1. I'd like to follow GHC development discussions, but getting all the
> > commits is too much.
>
> I'm surprised by this, FWIW. I think skimming the commits is a good way
> to get an idea of what's going on, while discussions between developers
> tend to be focussed on particular obscure points (e.g. discussing
> correctness of a murky corner in the intersection between 2 new type
> system extensions, or discussing the way PIC is handled on OSX/PowerPC)
> which I wouldn't have thought were of much interest to any party not
> involved in the discussion and familiar with the details.
>
> Anyway, I'm not really too fussed about what mailing lists we have. I'll
> just subscribe to them all anyway  :-)
>
>
> Thanks
> Ian
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

time submodule not accepting patches

[José Pedro Magalhães]

Hi,

I cannot push any patch to the time submodule of the GHC repo. For
instance, creating
a new branch succeeds locally, and succeeds in pushing, but the branch is
never created
on the remote. Also, no commit email is generated. Could this be fixed?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: data kinds

[José Pedro Magalhães]

See http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData


Cheers,
Pedro

On Fri, Jan 25, 2013 at 3:19 PM, Ross Paterson  wrote:

> GHC implements data kinds by promoting data declarations of a certain
> restricted form, but I wonder if it would be better to have a special
> syntax for kind definitions, say
>
>   data kind Nat = Zero | Succ Nat
>
> At the moment, things get promoted whether you need them or not, and
> if you've made some mistake that makes your definition non-promotable
> you don't find out until you try to use it.
>
> More importantly, a separate form for kinds would allow one to use
> existing kinds, i.e. *, in definitions of new kinds.
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[José Pedro Magalhães]

For the record, if we decide for a release soon, I'll make sure the
new-typeable branch gets merged asap.


Cheers,
Pedro

On Thu, Feb 7, 2013 at 8:25 AM, Simon Peyton-Jones wrote:

>  Dear GHC users,  
>
> *
> *
>
> *Carter*: Will this RTS update make it into ghc 7.8 update thats coming
> up in the next monthish?
>
> *Andreas*: We are almost there - we are now trying to sort out a problem
> on mac os x. It would be helpful to know if there is a cutoff date for
> getting things into 7.8. 
>
> ** **
>
> Simon, Ian, and I have just been discussing 7.8, and would be interested
> in what you guys think.  
>
>
> At ICFP we speculated that we’d make a release of GHC soon after Christmas
> to embody tons of stuff that has been included since 7.6, specifically:***
> *
>
> **· **major improvements in DPH (vectorisation avoidance, new
> vectoriser)
>
> **· **type holes
>
> **· **rebindable list syntax
>
> **· **major changes to the type inference engine
>
> **· **type level natural numbers
>
> **· **overlapping type families
>
> **· **the new code generator
>
> **· **support for vector (SSE/AVX) instructions
>
> ** **
>
> Whenever it comes it would definitely be great to include Andreas &
> friends’ work:
>
> **· **Scheduler changes to the RTS to improve latency
>
> ** **
>
> The original major reason for proposing a post-Xmas release was to get DPH
> in a working state out into the wild.  However, making a proper release
> imposes costs on everyone else.  Library authors have to scurry around to
> make their libraries work, etc.   Some of the new stuff hasn’t been in HEAD
> for that long, and hence has not been very thoroughly tested.   (But of
> course making a release unleashes a huge wave of testing that doesn’t
> happen otherwise.)
>
> ** **
>
> So another alternative is to leave it all as HEAD, and wait another few
> months before making a release.  You can still use all the new stuff by
> compiling HEAD, or grabbing a snapshot distribution.  And it makes it hard
> for the Haskell platform if GHC moves too fast. Many people are still on
> 7.4.
>
> ** **
>
> There seem to be pros and cons each way.  I don’t have a strong opinion.
> If you have a view, let us know.
>
> ** **
>
> Simon
>
> ** **
>
> --
> You received this message because you are subscribed to the Google Groups
> "parallel-haskell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to parallel-haskell+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[José Pedro Magalhães]

On Fri, Feb 8, 2013 at 2:28 PM, Simon Marlow  wrote:

>
> Does this strike a chord with anyone, or have I got the wrong impression
> and everyone is happy with the pace?
>

I am happy with the pace; I like the "release early, release often"
approach. The HP is not forced to use the
latest GHC, and the GHC download page already clearly directs users to the
HP. Slowing down GHC releases
will slow down adoption of new features, because while installing GHC might
be "harder" than installing the HP,
installing GHC HEAD is harder. My experience is that almost no one, apart
from GHC devs, has HEAD, and
they aren't willing to install it just to play with one new feature. Once a
new compiler version is out, however,
many people are happy to try it, even if it has no accompanying HP.


Cheers,
Pedro


>
> Cheers,
> Simon
>
>
> On 07/02/13 18:15, Simon Peyton-Jones wrote:
>
>  It’s fairly simple in my mind. There are two “channels” (if I understand
> Mark’s terminology right):
>
> ** **
>
> · Haskell Platform:
>
> o   A stable development environment, lots of libraries known to work
>
> o   Newcomers, and people who value stability, should use the Haskell
> Platform
>
> o   HP comes with a particular version of GHC, probably not the hottest
> new one, but that doesn’t matter.  It works.
>
> ** **
>
> · GHC home page downloads:
>
> o   More features but not so stable
>
> o   Libraries not guaranteed to work
>
> o   Worth releasing, though, as a forcing function to fix bugs, and as a
> checkpoint for people to test, so that by the time the HP adopts a
> particular version it is reasonably solid.
>
> ** **
>
> So we already have the two channels Mark asks for, don’t we?  One is
> called the Haskell Platform and one is called the GHC home page.  
>
>
> That leaves a PR issue: we really *don’t* want newcomers or Joe Users
> wanting the “new shiny”. They want the Haskell Platform, and as Mark says
> those users should not pay the slightest attention until it appears in the
> Haskell Platform.
>
> ** **
>
> So perhaps we principally need a way to point people away from GHC and
> towards HP?  eg We could prominently say at every download point “Stop!
> Are you sure you want this?  You might be better off with the Haskell
> Platform!  Here’s why...”.
>
> ** **
>
> Have I understood aright?  If so, how could we achieve the right social
> dynamics?  
>
> ** **
>
> Our goal is to let people who value stability get stability, while the
> hot-shots race along in a different channel and pay the price of flat tires
> etc.
>
> ** **
>
> PS: absolutely right to use 7.6.2 for the next HP.  Don’t even think about
> 7.8.
>
> ** **
>
> Simon
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Mark Lentczner 
> [mailto:mark.lentcz...@gmail.com]
>
> *Sent:* 07 February 2013 17:43
> *To:* Simon Peyton-Jones
> *Cc:* andreas.voel...@gmail.com; Carter Schonwald; GHC users; Simon
> Marlow; parallel-haskell; kosti...@gmail.com; Edsko de Vries;
> ghc-d...@haskell.org
> *Subject:* Re: GHC 7.8 release?
>
> ** **
>
> I'd say the window for 7.8 in the platform is about closed. If 7.8 were to
> be release in the next two weeks that would be just about the least amount
> of time I'd want to see for libraries in the platform to get all stable
> with the GHC version. And we'd also be counting on the GHC team to be
> quickly responding to bugs so that there could be a point release of 7.8
> mid-April. Historically, none of that seems likely.
>
> ** **
>
> So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2.
>
> ** **
>
> Since 7.8 will seems like it will be released before May, we will be faced
> again with the bad public relations issue: Everyone will want the new shiny
> and be confused as to why the platform is such a laggard. We'll see four
> reactions:
>
>- New comers who are starting out and figure they should use the
>latest... Many will try to use 7.8, half the libraries on hackage won't
>work, things will be wonky, and they'll have a poor experience.
>- People doing production / project work will stay on 7.6 and ignore
>7.8 for a few months.
>- The small group of people exploring the frontiers will know how to
>get things set up and be happy.
>- Eventually library authors will get around to making sure their
>stuff will work with it.
>
> I wish GHC would radically change it's release process. Things like 7.8
> shouldn't be release as "7.8". That sounds major and stable. The web site
> will have 7.8 at the top. The warning to use the platform will fall flat
> because it makes the platform look out of date. Really, "7.8" should be in
> a different release channel, not on the front page. It should bake in that
> channel for six months - where only the third group of people will use it,
> until it is getting close to merge into main, at which point the fourth
> group will start to use it, so that the 

Re: GHC 7.8 release?

[José Pedro Magalhães]

(sorry for re-post, but the first one got rejected from some lists due to
too many recipients)

On Fri, Feb 8, 2013 at 2:28 PM, Simon Marlow  wrote:

>  Does this strike a chord with anyone, or have I got the wrong impression
> and everyone is happy with the pace?
>

I am happy with the pace; I like the "release early, release often"
approach. The HP is not forced to use the
latest GHC, and the GHC download page already clearly directs users to the
HP. Slowing down GHC releases
will slow down adoption of new features, because while installing GHC might
be "harder" than installing the HP,
installing GHC HEAD is harder. My experience is that almost no one, apart
from GHC devs, has HEAD, and
they aren't willing to install it just to play with one new feature. Once a
new compiler version is out, however,
many people are happy to try it, even if it has no accompanying HP.


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default roles

[José Pedro Magalhães]

Hi,

On Tue, Oct 8, 2013 at 3:21 AM, Richard Eisenberg  wrote:

> We considered this for a while, but it led to a strange design -- to do it
> right, you would have to import all constructors for all datatypes
> *recursively* out to the leaves, starting at the datatypes mentioned in the
> class for which you wanted to use GND. This would mean potentially a whole
> lot of imports for symbols not actually used in the text of a program.
>

I'm not sure I understand why constructors are involved in this. Wouldn't
something like
the following potentially be useful?

data Role = Nominal | Representational | Phantom | Fun Role Role

type family HasRole (t :: k) :: Role

data MyData a b = MyData a
data MyGADT a b where MyGADT :: MyGADT a Int

type instance HasRole MyData  = Fun Representational Phantom
type instance HasRole MyGADT  = Fun Representational Nominal
type instance HasRole Traversable = Nominal

HasRole instances would be automatically given by GHC.


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Functional dependencies can "return" kinds, type families cannot

[José Pedro Magalhães]

Hello,

Maybe this is well known already (or maybe it's a bug), but lately I've
again found that functional
dependencies are more versatile than type families. In particular, they can
be used to compute
kinds from types, whereas type families cannot. Consider the code below,
which implements a
class for generic (working for types other than lists) map:

{-# LANGUAGE DataKinds  #-}
{-# LANGUAGE PolyKinds  #-}
{-# LANGUAGE TypeFamilies   #-}
{-# LANGUAGE GADTs  #-}
{-# LANGUAGE FlexibleInstances  #-}
{-# LANGUAGE ScopedTypeVariables#-}
{-# LANGUAGE TypeOperators  #-}
{-# LANGUAGE MultiParamTypeClasses  #-}
{-# LANGUAGE FunctionalDependencies #-}

module MapN where

-- (Type-level) Peano naturals
data Nat = Ze | Su Nat

-- Proxy
data Proxy t = Proxy

-- Singleton type for promoted lists
data SList (l :: [*]) where
  SNil  :: SList '[]
  SCons :: h -> SList t -> SList (h ': t)

-- Apply a type to a list of variables
type family AppVars (t :: k) (vs :: [*]) :: *
type instance AppVars t '[]   = t
type instance AppVars t (v ': vs) = AppVars (t v) vs

-- Domains of a list of functions
type family Doms (funs :: [*]) :: [*]
type instance Doms '[]  = '[]
type instance Doms ((a -> b) ': ts) = a ': Doms ts

-- Codomains of a list of functions
type family CoDoms (funs :: [*]) :: [*]
type instance CoDoms '[]  = '[]
type instance CoDoms ((a -> b) ': ts) = b ': CoDoms ts

-- Generalised map
-- How can I get rid of the FD below? I know how to do so by using a proxy
-- argument of type |Proxy t|, but I don't want an extra argument. The usual
-- trick of replacing the FD by a TF doesn't work here because the TF would
have
-- to return a *kind*, not a type.
class GMap (t :: k) (fs :: [*]) | fs -> k where
  gmap :: SList fs -> AppVars t (Doms fs) -> AppVars t (CoDoms fs)

-- List instance
instance GMap [] '[a -> b] where
  gmap _ []= []
  -- The line below does not typecheck without the above FD
  gmap fs@(SCons f SNil) (h:t) = f h : (gmap fs t)

The most interesting part here is the functional dependency fs -> k,
where kis a kind variable!
If this is not a bug (and it does seem to work as I expect it to), then
could we have type families
return kinds too?...


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base-3 vs base-4 (Was: Breakage with 6.10)

[José Pedro Magalhães]

Hello,

On Sat, Oct 11, 2008 at 03:52, Niklas Broberg <[EMAIL PROTECTED]>wrote:
>
>
> Though obviously this would only work if the module
> Data.Generics.Instances was preserved under that name somewhere else.
> If it was renamed or changed (which I suspect), then the hassle of
> keeping up to date with older versions will probably be too much, and
> I will want to update to the new agenda as soon as 6.10 is released
> for real. So what happened to this module? (Is there a migration
> quicksheet somewhere?)


The new syb package has basically all the Data.Generics.* modules.

In base4, no Data.Generics.* modules were kept. Instead, a new module,
Data.Data, contains all that was in Data.Generics.Basics and most of
Data.Generics.Instances.

Therefore, in the syb package, Data.Generics.Basics only re-exports module
Data.Data from base4, and Data.Generics.Instances defines the instances
missing from Data.Data and re-exports the instances from Data.Data.


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

[José Pedro Magalhães]

Hello,

On Sat, Oct 11, 2008 at 12:16, Claus Reinke <[EMAIL PROTECTED]> wrote:

>
> Pedro: it might be helpful if the haddock pages for the old and new syb
> modules were to point to a syb wiki page (which could then link
> to the relevant threads on libraries@)? Or is that information already in
> the documentation patch for the latest builds?
>

That's a good idea. I will set that up and push patches to the haddock
documentation of both base and syb to link there.


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: base-3 vs base-4 (Was: Breakage with 6.10)

[José Pedro Magalhães]

On Sat, Oct 11, 2008 at 18:41, David Menendez <[EMAIL PROTECTED]> wrote:

> 2008/10/11 José Pedro Magalhães <[EMAIL PROTECTED]>:
> > In base4, no Data.Generics.* modules were kept. Instead, a new module,
> > Data.Data, contains all that was in Data.Generics.Basics and most of
> > Data.Generics.Instances.
>
> Data.Data? Surely we can come up with something better than that.
>

Please do. That's the only name that came up in [1]. I think I'd still like
Generics.SYB, but that might be too big of a change...


Thanks,
Pedro

[1]
http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929/focus=9947
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

[José Pedro Magalhães]

Hello Ian,

I'm attaching patches that add a link to the new wiki from the haddock of
syb (and change the maintainer to [EMAIL PROTECTED]).


Thanks,
Pedro

On Mon, Oct 13, 2008 at 11:39, José Pedro Magalhães <[EMAIL PROTECTED]> wrote:

> Hello,
>
> I created a new wiki page for SYB which also contains some more detailed
> information on the changes for 6.10:
> http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB
>
>
> Thanks,
> Pedro
>


outputPatchBase4
Description: Binary data


outputPatchSyb
Description: Binary data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: syb changes (Re: base-3 vs base-4 (Was: Breakage with 6.10))

[José Pedro Magalhães]

Hello,

I created a new wiki page for SYB which also contains some more detailed
information on the changes for 6.10:
http://www.cs.uu.nl/wiki/bin/view/GenericProgramming/SYB


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Type checker loops with type families, overlapping and undecidable instances

[José Pedro Magalhães]

Hello all,

Please consider the following code:

{-# OPTIONS -Wall #-}
> {-# LANGUAGE FlexibleContexts #-}
> {-# LANGUAGE FlexibleInstances#-}
> {-# LANGUAGE TypeOperators#-}
> {-# LANGUAGE TypeFamilies #-}
> {-# LANGUAGE OverlappingInstances #-}
> {-# LANGUAGE UndecidableInstances #-}
>
> module Test where
>
> -- Some view
> class Viewable a where
>   type View a
>   to   :: a -> View a
>
> -- Structural representations
> data Unit= Unit
> data a :+: b = L a | R b
>
> instance Viewable Unit where
>   type View Unit = Unit
>   to = id
>
> instance (Viewable a, Viewable b) => Viewable (a :+: b) where
>   type View (a :+: b) = a :+: b
>   to = id
>
> -- Worker class
> class F' a where
>   f' :: a -> ()
>
> instance F' Unit where
>   f' Unit = ()
>
> instance (F a, F b) => F' (a :+: b) where
>   f' (L x) = f x
>   f' (R x) = f x
>
>
> -- Dispatcher class
> class (Viewable a, F' (View a)) => F a where
>   f :: a -> ()
>   f = f' . to
>
> instance F Unit where
>   f = f'
>
> instance (F a, F b) => F (a :+: b) where
>   f = f'
>
> -- All generic instances
> instance (Viewable a, F' (View a)) => F a
>
>
> -- A recursive datatype
> data Nat = Zero | Succ Nat
>
> -- Instance of Viewable
> instance Viewable Nat where
>   type View Nat = Unit :+: Nat
>   to = undefined
>
> -- Uncommenting the line below causes the typechecker to loop (GHC 6.10.1,
> Windows)
> --test = f Zero
>


Is this expected behavior or a bug?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker loops with type families, overlapping and undecidable instances

[José Pedro Magalhães]

Hello Lennart,

Yes, but according to the manual (
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances),
"Termination is ensured by having a fixed-depth recursion stack". So I would
expect at least termination, which I'm not getting (but I guess that can be
due to the type families).


Thanks,
Pedro

On Thu, Dec 4, 2008 at 15:10, Lennart Augustsson <[EMAIL PROTECTED]>wrote:

> Turning on UndecidableInstances is the same as saying: OK typechcker,
> you can loop if I make a mistake.
> I've not looked closely at your code, but if you turn on that flag,
> looping is probably not a bug.
>
>  -- Lennart
>
> 2008/12/4 José Pedro Magalhães <[EMAIL PROTECTED]>:
> > Hello all,
> >
> > Please consider the following code:
> >
> >> {-# OPTIONS -Wall #-}
> >> {-# LANGUAGE FlexibleContexts #-}
> >> {-# LANGUAGE FlexibleInstances#-}
> >> {-# LANGUAGE TypeOperators#-}
> >> {-# LANGUAGE TypeFamilies #-}
> >> {-# LANGUAGE OverlappingInstances #-}
> >> {-# LANGUAGE UndecidableInstances #-}
> >>
> >> module Test where
> >>
> >> -- Some view
> >> class Viewable a where
> >>   type View a
> >>   to   :: a -> View a
> >>
> >> -- Structural representations
> >> data Unit= Unit
> >> data a :+: b = L a | R b
> >>
> >> instance Viewable Unit where
> >>   type View Unit = Unit
> >>   to = id
> >>
> >> instance (Viewable a, Viewable b) => Viewable (a :+: b) where
> >>   type View (a :+: b) = a :+: b
> >>   to = id
> >>
> >> -- Worker class
> >> class F' a where
> >>   f' :: a -> ()
> >>
> >> instance F' Unit where
> >>   f' Unit = ()
> >>
> >> instance (F a, F b) => F' (a :+: b) where
> >>   f' (L x) = f x
> >>   f' (R x) = f x
> >>
> >>
> >> -- Dispatcher class
> >> class (Viewable a, F' (View a)) => F a where
> >>   f :: a -> ()
> >>   f = f' . to
> >>
> >> instance F Unit where
> >>   f = f'
> >>
> >> instance (F a, F b) => F (a :+: b) where
> >>   f = f'
> >>
> >> -- All generic instances
> >> instance (Viewable a, F' (View a)) => F a
> >>
> >>
> >> -- A recursive datatype
> >> data Nat = Zero | Succ Nat
> >>
> >> -- Instance of Viewable
> >> instance Viewable Nat where
> >>   type View Nat = Unit :+: Nat
> >>   to = undefined
> >>
> >> -- Uncommenting the line below causes the typechecker to loop (GHC
> 6.10.1,
> >> Windows)
> >> --test = f Zero
> >
> >
> > Is this expected behavior or a bug?
> >
> >
> > Thanks,
> > Pedro
> >
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Temporarily overriding Data.Generic

[José Pedro Magalhães]

Hi Deniz,

On Thu, Feb 5, 2009 at 00:11, Deniz Dogan  wrote:

> Sorry for those who receive this who have already gotten it from
> haskell-cafe.
>
> ---
>
> Hi
>
> I'm currently working on "hacking" Data.Generics for my master thesis.
> I'm basically trying to find out whether it can be made any faster
> using e.g. rewrite rules.


Great! Please let us know of the results when you have them :-)


> The problem I'm having is that I need an
> easy way to import my own modified version of Data.Generics (currently
> located in the same directory as my testing program) without
> unregistering or hiding syb-0.1.0.0 as base seems to depend on it.
>
> I've read the GHC user manual trying to find nice ways to do this
> using a bunch of different parameters to ghc, but I can't figure it
> out. Does anyone here know?


I've had my own problems while developing a successor version of the syb
package. For starters, cabal fails to install the package:

>cabal install
Resolving dependencies...
cabal: dependencies conflict: base-3.0.3.0 requires syb ==0.1.0.0 however
syb-0.1.0.0 was excluded because syb-0.2.0.0 was selected instead
syb-0.1.0.0 was excluded because of the top level dependency syb ==0.2.0.0

Note that this package explicitly requires base >= 4.0. Anyway, runghc
Setup.hs install does it, though. However, after having it installed I can't
use it, getting this when any module imports Data.Generics:

Bad interface file: C:\Program Files
(x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi
Something is amiss; requested module  syb:Data.Generics differs from
name found in the interface file syb-0.2.0.0:Data.Generics
Failed, modules loaded: none.

I talked about this on IRC before and remember this might have had something
to do with syb having been unversioned in the release of GHC 6.10.1. But I
hope someone can clarify this better...


Cheers,
Pedro


>
>
> Any help appreciated,
> Deniz
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug in deriving Data Typeable?

[José Pedro Magalhães]

Hi Bernd,

I guess this might be the same issue reported some time ago (
http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54): the
derived instances of Data do not define dataCast1. If you define your own
instance of Data for MyMaybe and add the definition of dataCast1 you will
get the expected behavior.


Cheers,
Pedro

On Thu, Mar 12, 2009 at 14:05, Bernd Brassel wrote:

> Hi folks,
>
> I have been surprised by the derived instances of Data/Typeable when
> using the combinator ext1Q. First look at the following definition:
>
> > useExt1 :: Data a => a -> ()
> > useExt1 = undefined `ext1Q` (\ (Just _) -> ())
>
> > testExt1 :: ()
> > testExt1 = useExt1 (Just ())
>
> As I expected, testExt1 yields ()
>
> But when I define my own version of Maybe and derive the Data/Typeable
> instances
>
> > data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable)
>
> the corresponding test
>
> > useExt1' :: Data a => a -> ()
> > useExt1' = undefined `ext1Q` (\ (MyJust _) -> ())
>
> > testExt1' :: ()
> > testExt1' = useExt1' (MyJust ())
>
> yields *** Exception: Prelude.undefined
>
> All of this happens with both ghc 6.10.1 and 6.8.2.
>
> Is this a bug in the derived instances, e.g., in dataCast1? If so is
> there a concise tutorial telling me how to write correct instances for
> the data type I'm interested in (which is not MyMaybe)?
>
> Thanks for your time!
> Bernd
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Bug in deriving Data Typeable?

[José Pedro Magalhães]

Hello,

On Thu, Mar 12, 2009 at 17:02, Bernd Brassel wrote:

> José Pedro Magalhães wrote:
> > Hi Bernd,
> >
> > I guess this might be the same issue reported some time ago (
> > http://thread.gmane.org/gmane.comp.lang.haskell.generics/53/focus=54):
> the
> > derived instances of Data do not define dataCast1. If you define your own
> > instance of Data for MyMaybe and add the definition of dataCast1 you will
> > get the expected behavior.
>
> Your link pointed me in the right direction to fix the bug for my
> application. Many thanks! Did you submit a bug report?
>
>
Now I did: http://hackage.haskell.org/trac/ghc/ticket/3087


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Problem with a second installed version of the syb package

[José Pedro Magalhães]

Hello all,

I mentioned this problem before on IRC and remember this might have had
something to do with syb having been unversioned in the release of GHC
6.10.1. However, I've tested this under 6.10.2-rc1 and the problem is still
there. Concretely, the problem is: I've developed a sucessor package to
syb-0.1.0.0. I can install it with runghc Setup.hs install. However, after
having installed it I can't use it, getting this error when loading any
module that imports Data.Generics:

Bad interface file: C:\Program Files
(x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi
Something is amiss; requested module  syb:Data.Generics differs from
name found in the interface file syb-0.2.0.0:Data.Generics
Failed, modules loaded: none.

What is the problem here?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Problem with a second installed version of the syb package

[José Pedro Magalhães]

Hello Ian,

2009/3/21 Ian Lynagh 

> On Fri, Mar 20, 2009 at 09:33:07AM +0100, José Pedro Magalhães wrote:
> >
> > Bad interface file: C:\Program Files
> > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi
> > Something is amiss; requested module  syb:Data.Generics differs
> from
> > name found in the interface file syb-0.2.0.0:Data.Generics
> > Failed, modules loaded: none.
> >
> > What is the problem here?
>
> What does
>
> ghc --show-iface "C:\Program Files
> (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1\Data\Generics.hi"
>
> say?


I'm sorry, I reported the error as ran from ghc-6.10.1. Running it with
ghc-6.10.2-rc1 I get the error

Bad interface file: C:\Program Files
(x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi
Something is amiss; requested module  syb:Data.Generics differs from
name found in the interface file syb-0.2.0.0:Data.Generics
Failed, modules loaded: none.

ghc --show-iface "C:\Program Files
(x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi" says:

Magic: Wanted 129742,
   got129742
Version: Wanted [6, 1, 0, 1, 2, 0, 0, 9, 0, 3, 1, 4],
 got[6, 1, 0, 1, 2, 0, 0, 9, 0, 3, 1, 4]
Way: Wanted [],
 got[]
interface syb-0.2.0.0:Data.Generics 610120090314
  interface hash: 2f252bc190bffcb63bc93af0a7864f85
  ABI hash: a2784ce2c50f029ab89be2567641765b
  export-list hash: 9f48270b3bb91438449202f71d1f8386
  orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e
  where
export syb-0.2.0.0:Data.Generics.Aliases Generic Generic'|{Generic' Generic'
unG
eneric'} GenericB GenericM GenericM'|{GM GenericM' unGM} GenericQ
GenericQ'|{GQ
GenericQ' unGQ} GenericR GenericT GenericT'|{GT GenericT' unGT} choiceMp
choiceQ
 ext0 ext1M ext1Q ext1R ext1T extB extM extMp extQ extR extT mkM mkMp mkQ
mkR mk
T orElse recoverMp recoverQ
export syb-0.2.0.0:Data.Generics.Schemes everything everywhere everywhere'
every
whereBut everywhereM gcount gdepth gfindtype glength gnodecount gsize
gtypecount
 listify something somewhere synthesize
export syb-0.2.0.0:Data.Generics.Text gread gshow
export syb-0.2.0.0:Data.Generics.Twins geq gfoldlAccum gmapAccumM gmapAccumQ
gma
pAccumQl gmapAccumQr gmapAccumT gzip gzipWithM gzipWithQ gzipWithT
export ghc-prim:GHC.Generics :*:|{:*: :*:} :+:{Inl Inr} Unit|{Unit Unit}
export base:Data.Data ConIndex Constr ConstrRep|{AlgConstr ConstrRep
FloatConstr
 IntConstr StringConstr} Data{dataCast1 dataCast2 dataTypeOf gfoldl gmapM
gmapMo
 gmapMp gmapQ gmapQi gmapQl gmapQr gmapT gunfold toConstr} DataRep|{AlgRep
DataR
ep FloatRep IntRep NoRep StringRep} DataType Fixity{Infix Prefix}
constrFields c
onstrFixity constrIndex constrRep constrType dataTypeConstrs dataTypeName
dataTy
peRep fromConstr fromConstrB fromConstrM indexConstr isAlgType isNorepType
maxCo
nstrIndex mkConstr mkDataType mkFloatConstr mkFloatType mkIntConstr
mkIntType mk
NorepType mkStringConstr mkStringType readConstr repConstr showConstr
tyconModul
e tyconUQname
export base:Data.Typeable TyCon TypeRep Typeable{typeOf} Typeable1{typeOf1}
Type
able2{typeOf2} Typeable3{typeOf3} Typeable4{typeOf4} Typeable5{typeOf5}
Typeable
6{typeOf6} Typeable7{typeOf7} cast funResultTy gcast gcast1 gcast2 mkAppTy
mkFun
Ty mkTyCon mkTyConApp showsTypeRep splitTyConApp tyConString typeOf1Default
type
Of2Default typeOf3Default typeOf4Default typeOf5Default typeOf6Default
typeOfDef
ault typeRepArgs typeRepKey typeRepTyCon
module dependencies: Data.Generics.Aliases Data.Generics.Instances
 Data.Generics.Schemes Data.Generics.Text
Data.Generics.Twin
s
package dependencies: ghc-prim integer base
orphans: base:Control.Exception.Base
 syb-0.2.0.0:Data.Generics.Instances base:Data.Tuple base:GHC.Base
 base:GHC.Float base:GHC.Num
family instance modules:
import base:Data.Data 2cfe9f6e828ce97d6906225849a7a8df
import base:Data.Typeable 00f181e6f8bb32e13d28aad58cee1bf9
import base:GHC.Base 6bdeebb11d04df398eb46d76fd9fedc8
import base:Prelude eac9ca3c0ae6d00a0fc0f1832a247e5e
import Data.Generics.Aliases a418fc77a8afb8f63b1349e7e70aae1f
  exports: 8a3a8813709e82f89b2cbe434cbbeb32
  Generic a3d985935013f874e5dce91cd67fc755
  Generic' 88e63b7215ef3e70992766168a404331
  GenericB b1b3a4bb9264b0843b0aed33984ed6e2
  GenericM f1cb29fbd7771577b3ce27762a0176ad
  GenericM' 270d4c132681a10609808f680f30d2a1
  GenericQ acd36022e368af6f81df3e2c9d0655b3
  GenericQ' 4fdb300d3293b22b2d81445caaf7f70b
  GenericR c34610525f7b7b1c9f9866ea45e5f488
  GenericT aeab09799011076dc8f091fc77329bb7
  GenericT' dfd635d65ef1b252ebb551bd573e2fa4
  choiceMp e2a24be4873fbf0985c117f95ef6
  choiceQ 402677c976faf710fa20d0dbfaed4338
  ext0 188b47185552ece2b9563d279b9f6b11
  ext1M 55c90f3b7aa3b30a09235074ccdd8474
  ext1Q 0fdb24f93014e9134d27059cab8791f5
  ext1R a85ebb59fcd8c1a276968370a82d4696
  ext1T bab0e7a30776525b1b9e8e170

Re: Problem with a second installed version of the syb package

[José Pedro Magalhães]

Hello Ian,

2009/3/25 Ian Lynagh 

> On Mon, Mar 23, 2009 at 10:53:19AM +0100, José Pedro Magalhães wrote:
> >
> > Bad interface file: C:\Program Files
> > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi
> > Something is amiss; requested module  syb:Data.Generics differs
> from
> > name found in the interface file syb-0.2.0.0:Data.Generics
> > Failed, modules loaded: none.
> >
> > ghc --show-iface "C:\Program Files
> > (x86)\Haskell\syb-0.2.0.0\ghc-6.10.1.20090314\Data\Generics.hi" says:
> >
> > interface syb-0.2.0.0:Data.Generics 610120090314
>
> It looks like this was built with -package-name syb-0.2.0.0, but it
> should be built with -package-name syb. There should be
>ghc-options: -package-name syb
> in the .cabal file to make this happen.


Yes, that works, thanks. I thought this problem was caused by having the syb
package unversioned in the GHC repo, and I also thought that that had
changed, but now I see that the flag -package-name syb is still there. Would
you know if this necessary for some reason?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Libraries in the repo

[José Pedro Magalhães]

Hello,

On Wed, Aug 26, 2009 at 18:15, Simon Marlow  wrote:

>
>  * Boot libraries are of several kinds:
>   - INDEPENDENT: Independently maintained (e.g. time, haskeline)
>   - COUPLED: Tightly coupled to GHC, but used by others (base)
>   - SPECIFIC: Totally specific to GHC (e.g. template-haskell, DPH)


Does syb fall under INDEPENDENT or COUPLED?

In any case, as the syb maintainer, I'd favor (1) too.


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC core plugins

[José Pedro Magalhães]

Hello all,

What's the current status of GHC plugins [1] in HEAD? Can I use them? If
not, what's the easiest way to add another core-to-core pass to the
compiler?


Thanks,
Pedro

[1] http://hackage.haskell.org/trac/ghc/wiki/Plugins
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC core plugins

[José Pedro Magalhães]

Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843

In any case, for now I am willing to hard-code a new core-to-core pass on
the compiler. Any pointers for where I have to look at?


Thanks,
Pedro

2010/1/27 Simon Peyton-Jones 

> Yes, I apologise for being slow about this.  A good idea would be to create
> a Trac ticket, so that people can register interest in having the patch by
> adding themselves to the cc list.  The more people that want it, the higher
> up my priority list...
>
> Better still if everyone adds a comment to the ticket to explain what their
> pass is like, and why they want the plugin feature.
>
> Simon
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
> | users-boun...@haskell.org] On Behalf Of Max Bolingbroke
> | Sent: 26 January 2010 18:38
> | To: José Pedro Magalhães
> | Cc: GHC users
> | Subject: Re: GHC core plugins
> |
> | Hi José,
> |
> | The patch implementing GHC plugins is with Simon PJ and awaiting merge
> | into GHC (and has been for some time - he's a busy guy and its a big
> | patch). However, even once it's merged some more work will need to be
> | done to make sure that it plays nicely with the shared library support
> | (now that has been implemented on all major platforms).
> |
> | In short, the easiest way to add a pass to the compiler right now is
> | to download GHC and build it yourself
> | (http://hackage.haskell.org/trac/ghc/wiki/Building). Sorry!
> |
> | All the best,
> | Max
> |
> | 2010/1/26 José Pedro Magalhães :
> | > Hello all,
> | >
> | > What's the current status of GHC plugins [1] in HEAD? Can I use them?
> If
> | > not, what's the easiest way to add another core-to-core pass to the
> | > compiler?
> | >
> | >
> | > Thanks,
> | > Pedro
> | >
> | > [1] http://hackage.haskell.org/trac/ghc/wiki/Plugins
> | >
> | > ___
> | > Glasgow-haskell-users mailing list
> | > Glasgow-haskell-users@haskell.org
> | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> | >
> | >
> | ___
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC core plugins

[José Pedro Magalhães]

Hi Max,

2010/1/27 Max Bolingbroke 

> 2010/1/27 José Pedro Magalhães :
> > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843
> >
> > In any case, for now I am willing to hard-code a new core-to-core pass on
> > the compiler. Any pointers for where I have to look at?
>
> I recommend you look at compiler/simplCore/CSE.lhs. It is a simple
> example of a core-to-core pass.
>
> However, in short you'll need to:
> 1) Create a function which implements your core to core pass, of a
> type such as [CoreBind] -> [CoreBind]
>  *) If that function lives in a new module, edit ghc.cabal.in to tell
> the build system about the module
> 2) Add a constructor to the CoreToDo data type in
> compiler/simplCore/CoreMonad.lhs
> 3) Add a case for it to the coreDumpFlag and Outputable instance
> 4) Add that pass to the list returned by getCoreToDo in CoreMonad. The
> order of the list is the order the passes will be run in.
>  *) If you want the pass to be under the control of a new flag, you'll
> need to add a new dynflag - add a constructor to the DOpt data type in
> compiler/main/DynFlags.lhs, and add something to build that
> constructor to one of the lists that get fed to the command line
> handling code in the same module. It should be fairly obvious how to
> do this.
> 5) Add a handler for the new constructor to
> compiler/simplCore/SimplCore.lhs, in the doCorePass function which
> calls into the core pass function you wrote
>
> Hope that helps,
> Max
>

Yes, that helped quite a lot. One last thing: currently it takes me about 6
minutes to rebuild the compiler after I change the core pass. Are there any
tricks of the build system I can use to speed this up? I'm already using a
fast build without optimizations and docs...


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC core plugins

[José Pedro Magalhães]

Hi,

2010/1/28 Max Bolingbroke 

> 2010/1/28 José Pedro Magalhães :
> > Yes, that helped quite a lot. One last thing: currently it takes me about
> 6
> > minutes to rebuild the compiler after I change the core pass. Are there
> any
> > tricks of the build system I can use to speed this up? I'm already using
> a
> > fast build without optimizations and docs...
>
> Hmm. Some things that help with this for me are to:
> 1) Compile with -j12 (or lower, depending on your hardware spec)
> 2) Compile with "cd compiler && make stage=2" to only build the stage
> 2 compiler (if this isn't already happening). Make sure the stage 1
> compiler is built with optimisations! (I use the stage2devel
> configuration, which already does this)
>
> This reduces compile times to a few minutes for me. Still tedious, but
> not too bad.
>

Thanks. Doing this reduces compilation time to about 30s, but unfortunately
my pass is not updated (even though it is compiled). I have to do 'make
stage=2' at the root directory, not inside compiler. This brings compilation
time to 1m10s (which is still better than what I was doing), but I really
don't know what would need building outside the compiler directory...

As an aside, is there any hope of using SYB in the core pass? As a generic
programmer I quickly get tired of traversing the entire AST when I want just
a few changes in specific places...


Thanks,
Pedro


>
> Hope that helps,
> Max
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Installing syb(-0.1.03) package in head version of Haskell

[José Pedro Magalhães]

I'm guessing that is indeed the problem, though I cannot reproduce the error
(but I'm using Cabal-1.8.0.2).

Assuming this is the cause of the problem, what is the best correction?
Encoding the cabal file as UTF-8 or removing the accent? Do earlier versions
of cabal deal well with UTF-8?...


Cheers,
Pedro

On Tue, Feb 23, 2010 at 16:05, Bayley, Alistair  wrote:

> Just a wild guess, but the package description has this non-ascii text:
>
> author: Ralf Lämmel, Simon Peyton Jones
>
> It could well be Latin-1 encoded, rather than UTF8.
>
> Try editing the author field to this:
>
> author: Ralf Laemmel, Simon Peyton Jones
>
> and rebuilding/installing.
>
> > -Original Message-
> > From: glasgow-haskell-users-boun...@haskell.org
> > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf
> > Of Simon Peyton-Jones
> > Sent: 23 February 2010 14:32
> > To: GHC users
> > Cc: cvs-...@haskell.org
> > Subject: FW: Installing syb(-0.1.03) package in head version
> > of Haskell
> >
> > Friends
> >
> >
> >
> > Can anyone help Kathleen out?  She has a cabal-install issue.
> >  I think she's on a Mac.
> >
> >
> >
> > Many thanks
> >
> >
> > Simon
> >
> >
> >
> > From: Kathleen Fisher [mailto:kathleen.fis...@gmail.com]
> > Sent: 16 February 2010 22:54
> > To: Simon Peyton-Jones
> > Subject: Fwd: Installing syb(-0.1.03) package in head version
> > of Haskell
> >
> >
> >
> > Hi Simon,
> >
> >
> >
> > I'm trying to get the PADS file we were working on compiling
> > under the HEAD version of Haskell, but I'm having trouble
> > getting the Data.Generics module to install. I sent the
> > question below to the librar...@haskell.org last week, but I
> > haven't seen any replies.  Is that the right address?  Or is
> > there a different place to ask such questions?
> >
> >
> >
> > Thanks for any pointers!
> >
> >
> >
> > Kathleen
> >
> >
> >
> > Begin forwarded message:
> >
> >
> >
> >
> >
> > From: Kathleen Fisher 
> >
> > Date: February 11, 2010 2:28:20 PM PST
> >
> > To: librar...@haskell.org
> >
> > Subject: Installing syb(-0.1.03) package in head version of Haskell
> >
> >
> >
> > Hi all,
> >
> > I'm trying to get a program that uses the Data.Generics
> > module to compile under the head version of GHC, but I am
> > having trouble getting the syb package installed.
> >
> > I believe I am using the most recent version of cabal:
> >
> >
> >
> >
> > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/
> > .cabal/bin/cabal --version
> >
> >   cabal-install version 0.8.0
> >
> >   using version 1.8.0.1 of the Cabal library
> >
> >
> > When I ask cabal to install the syb package, I get the
> > following error:
> >
> >
> >
> >
> > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/
> > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc
> >
> >   Resolving dependencies...
> >
> >   Downloading mtl-1.1.0.2...
> >
> >   Configuring mtl-1.1.0.2...
> >
> >   Preprocessing library mtl-1.1.0.2...
> >
> >   ...
> >
> >   Registering syb-0.1.0.3...
> >
> >   cabal: ghc-pkg: : hGetContents: invalid argument
> > (invalid UTF-8 byte
> >
> >   sequence)
> >
> >   cabal: Error: some packages failed to install:
> >
> >   language-c-quote-0.1 depends on syb-0.1.0.3 which
> > failed to install.
> >
> >   syb-0.1.0.3 failed during the building phase. The exception was:
> >
> >   exit: ExitFailure 1
> >
> >
> >
> > The full trace is included below.
> >
> > Here's the version information for the ghc I am running.
> >
> >
> >
> >
> > Kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/
> > sw/ghc-head/bin/ghc --version
> >
> >   The Glorious Glasgow Haskell Compilation System,
> > version 6.13.20100210
> >
> >
> > The cabal website suggests sending questions to this list...
> >
> > Any suggestions for how to fix this problem?
> >
> > Kathleen
> >
> >
> >
> >
> >
> > kfisher-laptop:/Users/kfisher/pads/dirpads/language-c-quote>~/
> > .cabal/bin/cabal install -w ~/sw/ghc-head/bin/ghc
> >
> >   Resolving dependencies...
> >
> >   Downloading mtl-1.1.0.2...
> >
> >   Configuring mtl-1.1.0.2...
> >
> >   Preprocessing library mtl-1.1.0.2...
> >
> >   Building mtl-1.1.0.2...
> >
> >
> >
> >   ...stuff deleted...
> >
> >
> >
> >   src/Data/Generics.hs:40:1:
> >
> >  Warning: The import of `Prelude' is redundant
> >
> > except perhaps to import instances from `Prelude'
> >
> >   To import instances alone, use: import Prelude()
> >
> >   Registering syb-0.1.0.3...
> >
> >   cabal: ghc-pkg: : hGetContents: invalid argument
> > (invalid UTF-8 byte
> >
> >   sequence)
> >
> >   cabal: Error: some packages failed to install:
> >
> >   language-c-quote-0.1 depends on syb-0.1.0.3 which
> > failed to install.
> >
> >   syb-0.1.0.3 failed during the building phase. The exception was:
> >
> >   exit: ExitFailure 1
> >
> >
> >
> >
> ***

Re: interaction of GADTs and data families: a bug?

[José Pedro Magalhães]

Hi Sebastian,

Is this perhaps another instance of #3851?
http://hackage.haskell.org/trac/ghc/ticket/3851


Cheers,
Pedro

On Thu, Apr 15, 2010 at 14:10, Sebastian Fischer <
s...@informatik.uni-kiel.de> wrote:

> Dear GHC experts,
>
> Certain behaviour when using
>
>{-# LANGUAGE GADTs, TypeFamilies #-}
>
> surprises me. The following is accepted by GHC 6.12.1:
>
>data GADT a where
>  BoolGADT :: GADT Bool
>
>foo :: GADT a -> a -> Int
>foo BoolGADT True = 42
>
> But the following is not:
>
>data family DataFam a
>data instance DataFam Bool where
>  BoolDataFam :: DataFam Bool
>
>fff :: DataFam a -> a -> Int
>fff BoolDataFam True = 42
>
> GHC 6.12.1 throws the following error (GHC 6.10.4 panics):
>
> Couldn't match expected type `a' against inferred type `Bool'
>   `a' is a rigid type variable bound by
>   the type signature for `fff' at gadtDataFam.hs:13:19
> In the pattern: BoolDataFam
> In the definition of `fff': fff BoolDataFam True = 42
>
> I expect that `fff` should be accepted just like `foo`. Do I expect too
> much?
>
> Cheers,
> Sebastian
>
> --
> Underestimating the novelty of the future is a time-honored tradition.
> (D.G.)
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: interaction of GADTs and data families: a bug?

[José Pedro Magalhães]

Hi Sebastian,

On Thu, Apr 15, 2010 at 15:08, Sebastian Fischer <
s...@informatik.uni-kiel.de> wrote:

> Is this perhaps another instance of #3851?
> http://hackage.haskell.org/trac/ghc/ticket/3851
>
>
> Honestly: I don't know.
>
> My example is different from the one shown in #3851 in that it also does
> not work in GHC 6.10 (which even panics instead of giving the error 6.12
> gives) and in that it uses a data family, not a type family.
>

The example in the ticket uses type families, but later in the comments I
show an example with data families which fails on both 6.10.4 and 6.12.1.


Cheers,
Pedro


>
> Whether or not it is the same "awkward interaction" that causes this
> behaviour is beyond my expertise.
>
> Cheers,
> Sebastian
>
>   --
> Underestimating the novelty of the future is a time-honored tradition.
> (D.G.)
>
>
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

SpecConstr number of specializations (-fspec-constr-count)

[José Pedro Magalhães]

Hi all,

When compiling some program with -O2 using ghc-7.0.1, I got warnings like

> SpecConstr
> Function `$j_s7Xo{v} [lid]'
>   has three call patterns, but the limit is 1
> Use -fspec-constr-count=n to set the bound
> Use -dppr-debug to see specialisations
> SpecConstr
> Function `$j_s7YI{v} [lid]' has 7 call patterns, but the limit is 3
> Use -fspec-constr-count=n to set the bound
> Use -dppr-debug to see specialisations
>

I proceeded to compile with -fspec-constr-count=10, but I still got

> SpecConstr
> Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 1
> Use -fspec-constr-count=n to set the bound
> Use -dppr-debug to see specialisations
>

With -fspec-constr-count=55, I got

> SpecConstr
> Function `$j_s7Xo{v} [lid]' has 7 call patterns, but the limit is 6
> Use -fspec-constr-count=n to set the bound
> Use -dppr-debug to see specialisations
>

Finally, with -fspec-constr-count=56, the warnings disappear.
Is this a bug, or is the value of spec-constr-count being manipulated in
some way for certain passes?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: SpecConstr number of specializations (-fspec-constr-count)

[José Pedro Magalhães]

Hi,

2010/11/25 Roman Leshchinskiy 

> On 25/11/2010, at 10:33, José Pedro Magalhães wrote:
>
> > Is this a bug, or is the value of spec-constr-count being manipulated in
> some way for certain passes?
>
> spec-constr-count decreases for nested specialisations. For instance, if
> spec-constr-count is 6 and SpecConstr generates 2 specialisations for a
> function foo, then spec-constr-count will be 3 for all functions nested in
> foo. You can turn it off completely with -fno-spec-constr-count.
>

Ok, thanks!


Pedro


>
> Roman
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Behavior of the inliner on imported class methods

[José Pedro Magalhães]

Hello all,

I fail to understand the behavior of the inliner in the following example:

module M1 where
>
> class MyEnum a where myEnum :: [a]
>
> instance MyEnum () where myEnum = [()]
>


> module M2 where
>
> import M1
>
> f1 = map (\() -> 'p') [()]
> f2 = map (\() -> 'q') myEnum
>

The generated core code for M2 with ghc-7.0.1 -O is:

M2.f22 :: GHC.Types.Char
> [GblId,
>  Caf=NoCafRefs,
>  Str=DmdType m,
>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>  ConLike=True, Cheap=True, Expandable=True,
>  Guidance=IF_ARGS [] 1 2}]
> M2.f22 = GHC.Types.C# 'q'
>
> M2.f11 :: GHC.Types.Char
> [GblId,
>  Caf=NoCafRefs,
>  Str=DmdType m,
>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>  ConLike=True, Cheap=True, Expandable=True,
>  Guidance=IF_ARGS [] 1 2}]
> M2.f11 = GHC.Types.C# 'p'
>
> M2.f21 :: () -> GHC.Types.Char
> [GblId,
>  Arity=1,
>  Caf=NoCafRefs,
>  Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True,
>  ConLike=True, Cheap=True, Expandable=True,
>  Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}]
> M2.f21 =
>   \ (ds_dch :: ()) -> case ds_dch of _ { () -> M2.f22 }
>
> M2.f2 :: [GHC.Types.Char]
> [GblId,
>  Str=DmdType,
>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False,
>  ConLike=False, Cheap=False, Expandable=False,
>  Guidance=IF_ARGS [] 3 0}]
> M2.f2 =
>   GHC.Base.map
> @ () @ GHC.Types.Char M2.f21 M1.$fMyEnum()_$cmyEnum
>
> M2.f1 :: [GHC.Types.Char]
> [GblId,
>  Caf=NoCafRefs,
>  Str=DmdType,
>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>  ConLike=True, Cheap=True, Expandable=True,
>  Guidance=IF_ARGS [] 1 3}]
> M2.f1 =
>   GHC.Types.:
> @ GHC.Types.Char M2.f11 (GHC.Types.[] @ GHC.Types.Char)
>

So, why does the inliner fail to get rid of the map in f2, while correctly
ditching it in f1? Note that using two modules is essential here: if the
instance is in M2 (and thus becoming orphan), the inliner works "correctly".
Adding INLINE/INLINABLE pragmas to myEnum doesn't improve things either. Is
this a bug, or is there a reason for this behavior?


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Behavior of the inliner on imported class methods

[José Pedro Magalhães]

Hi Roman,

Thanks for the suggestion, but that doesn't seem to change things.


Cheers,
Pedro

2011/1/19 Roman Leshchinskiy 

> Have you tried adding another (dummy) method to the class? GHC used to have
> problems with optimising single-method classes in the past.
>
> Roman
>
>
> On 18 Jan 2011, at 10:33, José Pedro Magalhães  wrote:
>
> Hello all,
>
> I fail to understand the behavior of the inliner in the following example:
>
> module M1 where
>>
>> class MyEnum a where myEnum :: [a]
>>
>> instance MyEnum () where myEnum = [()]
>>
>
>
>> module M2 where
>>
>> import M1
>>
>> f1 = map (\() -> 'p') [()]
>> f2 = map (\() -> 'q') myEnum
>>
>
> The generated core code for M2 with ghc-7.0.1 -O is:
>
> M2.f22 :: GHC.Types.Char
>> [GblId,
>>  Caf=NoCafRefs,
>>  Str=DmdType m,
>>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>>  ConLike=True, Cheap=True, Expandable=True,
>>  Guidance=IF_ARGS [] 1 2}]
>> M2.f22 = GHC.Types.C# 'q'
>>
>> M2.f11 :: GHC.Types.Char
>> [GblId,
>>  Caf=NoCafRefs,
>>  Str=DmdType m,
>>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>>  ConLike=True, Cheap=True, Expandable=True,
>>  Guidance=IF_ARGS [] 1 2}]
>> M2.f11 = GHC.Types.C# 'p'
>>
>> M2.f21 :: () -> GHC.Types.Char
>> [GblId,
>>  Arity=1,
>>  Caf=NoCafRefs,
>>  Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True,
>>  ConLike=True, Cheap=True, Expandable=True,
>>  Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}]
>> M2.f21 =
>>   \ (ds_dch :: ()) -> case ds_dch of _ { () -> M2.f22 }
>>
>> M2.f2 :: [GHC.Types.Char]
>> [GblId,
>>  Str=DmdType,
>>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False,
>>  ConLike=False, Cheap=False, Expandable=False,
>>  Guidance=IF_ARGS [] 3 0}]
>> M2.f2 =
>>   GHC.Base.map
>> @ () @ GHC.Types.Char M2.f21 M1.$fMyEnum()_$cmyEnum
>>
>> M2.f1 :: [GHC.Types.Char]
>> [GblId,
>>  Caf=NoCafRefs,
>>  Str=DmdType,
>>  Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
>>  ConLike=True, Cheap=True, Expandable=True,
>>  Guidance=IF_ARGS [] 1 3}]
>> M2.f1 =
>>   GHC.Types.:
>> @ GHC.Types.Char M2.f11 (GHC.Types.[] @ GHC.Types.Char)
>>
>
> So, why does the inliner fail to get rid of the map in f2, while correctly
> ditching it in f1? Note that using two modules is essential here: if the
> instance is in M2 (and thus becoming orphan), the inliner works "correctly".
> Adding INLINE/INLINABLE pragmas to myEnum doesn't improve things either. Is
> this a bug, or is there a reason for this behavior?
>
>
> Thanks,
> Pedro
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Deriviable type classes

[José Pedro Magalhães]

Hi,

2011/2/9 Simon Peyton-Jones 

> Friends
>
> Just a heads-up.  Pedro is working on implementing "Generic Defaults", as
> described in his Haskell Symposium 2010 paper
> www.dreixel.net/research/pdf/gdmh_nocolor.pdf
>
> It will replace (and improve on) the "Derivable type classes" stuff in GHC
> at the moment, which was originally presented in a paper of that title that
> Ralf and I wrote in the 2000 Haskell workshop
> http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm.
>
> The "Derivable type class" extension is barely used, I believe, and isn't
> even documented in the manual.


Isn't it this?:
http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes.html

But anyway, I can't remember seeing any use of it.


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Deriviable type classes

[José Pedro Magalhães]

Hi,

2011/2/10 Yitzchak Gale 

> Simon Peyton-Jones wrote:
> > "Generic Defaults"... will replace... the "Derivable type classes"
> > stuff... in GHC 7.2 or 7.4...
> > Please yell if you are a secret user of derivable type classes,
> > so this change would discombobulate you.
>
> Could you give us a preview of the parts of the syntax
> spectrum that will be gobbled up by this? That is a way
> that the change could affect even people who are not using
> the current generics.
>

As far as I understand, only the keyword "generic" will be taken. A new
GHC.Generics module will define many new types with common names like `C`
and `D`; these are used for the generic representation of datatypes in any
module that enables -XGenerics, but there are no clashes unless the
programmer explicitly imports GHC.Generics, so that should be ok.


>
> For example, the old generics knocked a very nice bracket
> out of consideration for TH syntax. It also blessed the names
> of certain magical constructors, which can be good to know
> about even if the magic doesn't leak out of the generics world.
>

I remember there was some strange behavior with a type constructor `1` which
was supposedly caused by the old generics (or was it syb?). Hopefully there
will be nothing like that in the new mechanism.


Cheers,
Pedro


>
> Thanks,
> Yitz
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Recompile with -fPIC (was "building a patched ghc")

[José Pedro Magalhães]

Hi all,

I'm getting the same error as Alexy below in some 64bit linux system. What
can I do? Adding -fPIC and also -dynamic does not seem to solve the problem.
Also, this only happens with a perf build; devel1 works fine.


Thanks,
Pedro

On Sat, Jun 26, 2010 at 05:56, braver  wrote:

> An attempt to build the trunk gets me this:
>
> /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-
> pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation
> R_X86_64_PC32 against symbol `StgRun' can not be used when making a
> shared object; recompile with -fPIC
>
> -- I use prefix portage on a CentOS box, admittedly a non-standard
> setup.  Its gcc is found first and it wants -fPIC...  Should I just
> add it to CFLAGS or what?
>
> -- Alexy
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Recompile with -fPIC (was "building a patched ghc")

[José Pedro Magalhães]

Thanks for the tip. I cannot easily update binutils. I am with version
2.17.50.0.6-14.el5 20061020. On another machine (32bit) it works fine...


Cheers,
Pedro

2011/2/18 Wolfram Kahl 

> I am not certain, but this may be the same problem that I once had,
> and that was solved by updating to binutils-2.20.
>
>  ld --version
> GNU ld (GNU Binutils) 2.20.1.20100303
>
>
> Wolfram
>
>
> On Fri, Feb 18, 2011 at 11:34:03AM +0100, José Pedro Magalhães wrote:
> > Hi all,
> >
> > I'm getting the same error as Alexy below in some 64bit linux system.
> What
> > can I do? Adding -fPIC and also -dynamic does not seem to solve the
> problem.
> > Also, this only happens with a perf build; devel1 works fine.
> >
> >
> > Thanks,
> > Pedro
> >
> > On Sat, Jun 26, 2010 at 05:56, braver  wrote:
> >
> > > An attempt to build the trunk gets me this:
> > >
> > > /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-
> > > pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation
> > > R_X86_64_PC32 against symbol `StgRun' can not be used when making a
> > > shared object; recompile with -fPIC
> > >
> > > -- I use prefix portage on a CentOS box, admittedly a non-standard
> > > setup.  Its gcc is found first and it wants -fPIC...  Should I just
> > > add it to CFLAGS or what?
> > >
> > > -- Alexy
> > > ___
> > > Haskell-Cafe mailing list
> > > haskell-c...@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> >
> >
> > !DSPAM:4d5e4b2789541804284693!
>
> > ___
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
> > !DSPAM:4d5e4b2789541804284693!
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

SMP parallelism gains inferior than expected

[José Pedro Magalhães]

Hi,

I have a program that computes a matrix of Floats of m rows by n columns.
Computing each Float is relatively expensive. Each line is completely
independent of the others, so I thought I'd try some simple SMP parallelism
on this code:

myFun :: FilePath -> IO ()
myFun fp =
  do fs <- readDataDir fp
 let process f = readFile' f >>= parse
 printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) ""
 runDiff l = [ [ diff x y | y <- l ]
 | (x,i) <- zip l (map getId fs), myFilter i ]
 ps <- mapM process fs
 sequence_ [ printLine x | x <- runDiff ps *`using` parList rdeepseq* ]

So, I'm using parList to evaluate the rows in parallel, and fully evaluating
each row. Here are the timings on a Dual Quad Core AMD 2378 @2.4 GHz,
ghc-6.12.3, parallel-2.2.0.1:

-N  time (ms)
none1m50
2   1m33
3   1m35
4   1m22
5   1m11
6   1m06
7   1m45

The increase at 7 is justified by the fact that there were two other
processes running. I don't know how to justify the small increase at N3,
though, but that doesn't matter too much. The problem is that I am not
getting the gains I expected (halving at N2, a third at N3, etc.). Is this
the best one can achieve with this implicit parallelism, or am I doing
something wrong? In particular, is the way I'm printing the results at the
end destroying potential parallel gains?

Any insights on this are appreciated.


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

SMP parallelism gains inferior than expected

[José Pedro Magalhães]

(Forwarding to haskell-cafe)

Hi,

I have a program that computes a matrix of Floats of m rows by n columns.
Computing each Float is relatively expensive. Each line is completely
independent of the others, so I thought I'd try some simple SMP parallelism
on this code:

myFun :: FilePath -> IO ()
myFun fp =
  do fs <- readDataDir fp
 let process f = readFile' f >>= parse
 printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) ""
 runDiff l = [ [ diff x y | y <- l ]
 | (x,i) <- zip l (map getId fs), myFilter i ]
 ps <- mapM process fs
 sequence_ [ printLine x | x <- runDiff ps *`using` parList rdeepseq* ]

So, I'm using parList to evaluate the rows in parallel, and fully evaluating
each row. Here are the timings on a Dual Quad Core AMD 2378 @2.4 GHz,
ghc-6.12.3, parallel-2.2.0.1:

-N  time (ms)
none1m50
2   1m33
3   1m35
4   1m22
5   1m11
6   1m06
7   1m45

The increase at 7 is justified by the fact that there were two other
processes running. I don't know how to justify the small increase at N3,
though, but that doesn't matter too much. The problem is that I am not
getting the gains I expected (halving at N2, a third at N3, etc.). Is this
the best one can achieve with this implicit parallelism, or am I doing
something wrong? In particular, is the way I'm printing the results at the
end destroying potential parallel gains?

Any insights on this are appreciated.


Thanks,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] Polymorphic types in RHS of type instances

[José Pedro Magalhães]

Hi,

[Moving to glasgow-haskell-users@haskell.org]

I would also like to know the answer to this question. While I can imagine
it has something to do with type checking/inference, it is not immediately
clear to me where the problem lies.


Thanks,
Pedro

On Sat, Feb 5, 2011 at 12:25, Steven Keuchel wrote:

> Hi list,
>
> I was wondering why GHC doesn't allow usage of polymorphic types in
> the right-hand side of type instance declarations for type families.
> The GHC user guide states: "The right-hand side of a type instance
> must be a monotype (i.e., it may not include foralls) [...]", but it
> doesn't state the reason.
>
> I stumbled upon this limitation when I was trying to generically
> calculate Johann's and Ghani's interpreter (transformers) for nested
> data types from their "Initial Algebra Semantics is Enough!" paper.
>
> Cheers,
> Steven
>
> ___
> Haskell mailing list
> hask...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] Polymorphic types in RHS of type instances

[José Pedro Magalhães]

Hi Simon,

For instance:

data Su n
> data Fin n where FSu :: Fin n -> Fin (Su n)
> -- equivalent to data Fin n = forall m. n ~ Su m => FSu (Fin m)
>
> data a :=: b where Refl :: a :=: a
>
> type instance Rep (Fin n) = forall m. (n :=: Su m, Fin m)
>

But I think I found the answer in the meantime: this would quickly leave GHC
trying to prove things such as (forall m. ... ~ forall m1. ...), which I
guess is undecidable in general.


Cheers,
Pedro

2011/4/4 Simon Peyton-Jones 

>  Can you give an example of what you’d like to write, but can’t?
>
> Simon
>
>
>
> *From:* glasgow-haskell-users-boun...@haskell.org [mailto:
> glasgow-haskell-users-boun...@haskell.org] *On Behalf Of *José Pedro
> Magalhães
> *Sent:* 04 April 2011 10:53
> *To:* GHC users
> *Cc:* Steven Keuchel
> *Subject:* Re: [Haskell] Polymorphic types in RHS of type instances
>
>
>
> Hi,
>
> [Moving to glasgow-haskell-users@haskell.org]
>
> I would also like to know the answer to this question. While I can imagine
> it has something to do with type checking/inference, it is not immediately
> clear to me where the problem lies.
>
>
> Thanks,
> Pedro
>
> On Sat, Feb 5, 2011 at 12:25, Steven Keuchel 
> wrote:
>
> Hi list,
>
> I was wondering why GHC doesn't allow usage of polymorphic types in
> the right-hand side of type instance declarations for type families.
> The GHC user guide states: "The right-hand side of a type instance
> must be a monotype (i.e., it may not include foralls) [...]", but it
> doesn't state the reason.
>
> I stumbled upon this limitation when I was trying to generically
> calculate Johann's and Ghani's interpreter (transformers) for nested
> data types from their "Initial Algebra Semantics is Enough!" paper.
>
> Cheers,
> Steven
>
> ___
> Haskell mailing list
> hask...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Panic when using syb with GHC API

[José Pedro Magalhães]

Hi,

On Fri, Aug 26, 2011 at 10:22, Simon Peyton-Jones wrote:

> Feel free to propose better solutions.
>

I see the problem, but it's indeed not clear how to improve the current
situation.

Adding one more possible solution: SYB, as it is, will traverse the entire
data structure, even if it is clear (from the types) that there will be
nothing to transform inside a certain term.

A while ago, Claus Reinke developed a different form of traversals for SYB,
which avoid entering subterms when it is clear that there is nothing to
transform there. You can see the code in a branch of the current repo:
https://github.com/dreixel/syb/blob/gps/src/Data/Generics/GPS.hs

Maybe using this could help, since then SYB would not traverse everything.
In general, however, this is still not a complete solution, because you
might have written a traversal which does intend to operate inside these
undefined values: you just don't expect them to be undefined.

In any case, maybe Simon Hengel can try using this. If it seems like this
avoids the problem, I'd be happy to release a new version of SYB containing
these type-guided traversals. (Also, for traversing these kind of big
structures, using Claus's traversals might improve performance
considerably.)


Cheers,
Pedro


>
> The underlying issue is that before type checking GHC (obviously) doesn't
> know the types of things, while afterwards it does.  The whole HsSyn tree is
> parameterised over the types of identifiers:
>
>  Parsed:   HsExpr RdrNames
>  Renamed:  HsExpr Name
>  Typechecked:  HsExpr Id
>
> One alternative would be to parameterise the tree over the type of
> type-decorations, so instead of 'PostTcType' you'd have 'ty' (a variable)
> instead.  So we'd have
>
>  Renamed: HsExpr Name ()
>  Typechecked: HsExpr Id   Type
>
> To me this seems like a bit of a sledgehammer to crack a nut; and I think
> there are a couple of other similar things (like SyntaxExpr).  But it might
> be possible.
>
> Another possibility would be for those PostTcTypes to be (Maybe Type),
> which would be less convenient when you know they are there.
>
> Simon
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org [mailto:
> glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Ranjit Jhala
> | Sent: 25 August 2011 22:47
> | To: Thomas Schilling
> | Cc: glasgow-haskell-users@haskell.org
> | Subject: Re: Panic when using syb with GHC API
> |
> | Hi,
> |
> | I ran into a similar issue earlier -- you might also look at this
> |
> |   http://mistuke.wordpress.com/category/vsx/
> |
> | (also linked from http://haskell.org/haskellwiki/GHC/As_a_library#Links)
> |
> | Hope to elaborate the text there one of these days...
> |
> | Ranjit.
> |
> |
> | On Aug 25, 2011, at 2:22 AM, Thomas Schilling wrote:
> |
> | > GHC's parse tree contains lots of placeholders.  You are not supposed
> | > to look at them until a specific phase has been run.  For example,
> | > anything of type "SyntaxExpr" is an error thunk until the renamer has
> | > been run.  Unfortunately, SyntaxExpr is just a type synonym, so
> | > there's no way to distinguish them via SYB.
> | >
> | > The simplest workaround is to adapt the default traversal code for the
> | > nodes which may contain such error thunks.  A better solution would be
> | > to change the GHC AST to wrap such possibly undefined nodes with
> | > newtypes, but that would only take effect once the next version of GHC
> | > is released.
> | >
> | > On 24 August 2011 23:11, Simon Hengel 
> wrote:
> | >> Hello,
> | >> I'm trying to query a type-checked module with syb, this works for a
> | >> plain binding.  But as soon as I add a type signature for that
> binding,
> | >> I get an "panic!"
> | >>
> | >> I experienced similar problems with a renamed module.
> | >>
> | >> Are those data structures meant to be used with syb?  And if yes, what
> | >> did I miss?
> | >>
> | >> Bellow is some code to reproduce my issue.  Any help is very much
> | >> appreciated.
> | >>
> | >>-- A.hs
> | >>module Main where
> | >>
> | >>import GHC
> | >>import Outputable
> | >>import Data.Generics
> | >>import GHC.Paths (libdir)
> | >>
> | >>import Bag
> | >>
> | >>main :: IO ()
> | >>main = do
> | >>  m <- parse
> | >>  putStrLn $ showSDoc $ ppr $ m
> | >>  putStrLn "\n---\n"
> | >>  putStrLn $ showSDoc $ ppr $ selectAbsBinds m
> | >>
> | >>parse = runGhc (Just libdir) $ do
> | >>  _ <- getSessionDynFlags >>= setSessionDynFlags
> | >>  target <- guessTarget "B.hs" Nothing
> | >>  setTargets [target]
> | >>  Succeeded <- load LoadAllTargets
> | >>  modSum <- getModSummary $ mkModuleName "B"
> | >>  m <- parseModule modSum >>= typecheckModule
> | >>  return $ typecheckedSource m
> | >>
> | >>selectAbsBinds :: GenericQ [HsBindLR Id Id]
> | >>selectAbsBinds = everything (++) ([] `mkQ` f)
> | >>  where
> | >>f x@(AbsBinds _ _ _ _ _) = [x]
> | >>

Re: Associativity of the generic representation of sum types

[José Pedro Magalhães]

Hi Bas,

On Thu, Sep 22, 2011 at 03:55, Bas van Dijk  wrote:

> Hello,
>
> I just used the new GHC generics together with the DefaultSignatures
> extension to provide a default generic implementation for toJSON and
> parseJSON in the aeson package:
>
> https://github.com/mailrank/aeson/pull/26
>
> It appears that the generic representation of a sum type has a tree shape
> as in:
>
> (a :+: b) :+: (c :+: d)
>

That is correct.


>
> In my case this tree-shaped representation is problematic when parsing
> a JSON value to this type. My overloaded parsing function is
> parameterized with a key which specifies which of the a, b, c or d
> constructors to parse. When it encounters a constructor it checks if
> it matches the key, if so it is parsed, if not parsing will fail.
> Because of the tree-shaped representation of sum types I have to
> recursively parse the left and right branch and join them using <|>:
>
>
> https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3fbb899/Data/Aeson/Types/Internal.hs#L1003
>
> I don't know for sure but I suspect that this can cause memory leaks
> since the <|> has to keep the right value in memory when it is parsing
> the left.
>

It is not immediately clear to me why this would cause memory leaks...


>
> Ideally the generic representation of sum types is right associative as in:
>
> a :+: (b :+: (c :+: d))
>
> This way I only have to check if 'a' matches, if it does the right
> branch can be forgotten.
>
> Is there a good reason for not having it right associative?
>

The reason is performance. In particular for large datatypes with many
constructors, a balanced sum-of-products performs better than a right-nested
one. Also, it makes things like writing generic space-efficient
encoders/decoders easier.

But I would be very interested in understanding if/how the balanced view
leads to a space leak, so please let me know if you can provide some more
information.


Thanks,
Pedro


>
> Regards,
>
> Bas
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Associativity of the generic representation of sum types

[José Pedro Magalhães]

Hi Bas,

Thanks for all the effort you put into this. Let's move the discussion to
trac, then.


Cheers,
Pedro

2011/9/22 Bas van Dijk 

> 2011/9/22 Bas van Dijk :
> > I will make an official ticket for this.
>
> Done: http://hackage.haskell.org/trac/ghc/ticket/5499
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Why no multiple default method implementations?

[José Pedro Magalhães]

Hi Bas,

On Thu, Nov 24, 2011 at 09:23, Bas van Dijk  wrote:

> Hello,
>
> Now that we have DefaultSignatures, why is it not allowed to have
> multiple default method implementations, as in:
>
> {-# LANGUAGE DefaultSignatures #-}
>
> class Foo a where
>foo :: a
>foo = error "foo"
>
>default foo :: Num a => a
>foo = 1
>
> GHC complains: "Conflicting definitions for `foo'"
>
> The following use of multiple default signatures also gives the same error:
>
> class Foo a where
>foo :: a
>
>default foo :: Fractional a => a
>foo = 0.5
>
>default foo :: Num a => a
>foo = 1
>
> Couldn't GHC always pick the most specific default method, just as it
> does with instances when OverlappingInstances is enabled?
>

As far as I understand, GHC never looks at the context to decide which
instance is applicable:
http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/type-class-extensions.html#instance-overlap
 Your instances above are duplicates.


Cheers,
Pedro


> Regards,
>
> Bas
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1

[José Pedro Magalhães]

Hi Bas,

On Wed, Dec 21, 2011 at 23:02, Bas van Dijk  wrote:

> On 21 December 2011 19:29, Ian Lynagh  wrote:
> >  * There is a new feature constraint kinds (-XConstraintKinds):
> >
> http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
>
> I'm trying to run the ConstraintKinds example from the documentation:
>
> {-# LANGUAGE ConstraintKinds, TypeFamilies #-}
> type family Typ a b :: Constraint
> type instance Typ Int  b = Show b
> type instance Typ Bool b = Num b
>
> But GHC complains:
>Not in scope: type constructor or class `Constraint'
>
> Do I have to import some GHC module for this?
>

Yes: GHC.Prim.

(Which reminds me, Simon, we had agreed to re-export Constraint from
GHC.Exts, but it wasn't clear to me how to do this, since Constraint is a
kind, not a type, so it can't just go on the export list of the module...)


Cheers,
Pedro


>
> Cheers,
>
> Bas
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1

[José Pedro Magalhães]

Hi Wolfgang,

On Wed, Dec 28, 2011 at 13:51, Wolfgang Jeltsch
wrote:

> Am Mittwoch, den 28.12.2011, 12:48 + schrieb Simon Peyton-Jones:
> > | By the way, is there a reason behind the fact that “Constraint” uses
> the
> > | ordinary case, while “BOX” has all three letters capitalized? Wouldn’t
> > | it be more sensible if it were “Box” instead of “BOX”?
> >
> > Only that BOX is a sort (currently the one and only sort), whereas
> > Constraint is a kind.  I'm not sure that BOX should ever be displayed
> > to users.
>
> Okay, this makes sense then. However, note that the GHC User’s manual
> mixes the terminology (“kind” vs. “sort”) at one point:
>
>Note that List, for instance, does not get kind BOX -> BOX, because
>we do not further classify kinds; all kinds have sort BOX.
>
><
> http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/kind-polymorphism-and-promotion.html
> >
>
> I think, it should say “sort BOX -> BOX”.
>

Yes, it should indeed say "sort", not "kind". If you know of any other
places in the documentation with this type/kind/sort of inconsistency,
please let me know :-)


Cheers,
Pedro


>
> Best wishes,
> Wolfgang
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DefaultSignatures and MultiParamTypeClasses

[José Pedro Magalhães]

Hello Reiner,

On Mon, Jan 16, 2012 at 06:32, Reiner Pope  wrote:

> Hi all,
>
> I just tried, and it appears that the new DefaultSignatures extension
> doesn't work with multi parameter type classes.
>
> Is there a reason for this restriction, or is it merely an accident?
>

I don't think the original design explicitly excluded MPTCs; I don't think
there were any use cases for it either, though. I think Simon introduced
this restriction, so he might have a good reason for it.


Cheers,
Pedro


>
> Cheers,
> Reiner
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Posting etiquette, was Re: Records in Haskell

[José Pedro Magalhães]

Hi,

One could also argue that a good email client should automatically hide
long quotes. In fact, I guess many people are not even aware of the problem
because their client does this.


Cheers,
Pedro

On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace wrote:

> Sorry to pick on your post in particular Matthew, but I have been seeing a
> lot of this on the Haskell lists lately.
>
> I find it completely unreasonable for a reply to a very long post to quote
> the entire text, only to add a single line at the bottom (or worse,
> embedded in the middle somewhere).  In this case, there are 7 pages of
> quotation before your one-sentence contribution.  (That is on my laptop.  I
> dread to think how many pages it represents on a smartphone screen...)
>  Usually, if I need to scroll even to the second page-worth of quotation
> and have still not found any new text, I now just delete the post without
> reading it.
>
> It is a failure to communicate well, on the part of the writer who values
> their own time more highly than that of their intended readers.  Even the
> much-maligned top-posting style, as forced upon Outlook users (and as I am
> doing right here), is preferable to the failure to trim, or to get to the
> point quickly.  My inbox has >1600 unread messages in it, and life is just
> too short.  So I offer this plea as a constructive social suggestion - if
> you want your ideas to reach their intended audience, don't annoy them
> before they have even seen what you want to say.
>
> Regards,
>Malcolm
>
>
> On 15 Jan 2012, at 20:33, Matthew Farkas-Dyck wrote:
>
> > On 13/01/2012, Simon Peyton-Jones  wrote:
> >> Thanks to Greg for leading the records debate.  I apologise that I
> >> don't have enough bandwidth to make more than an occasional
> >> contribution.  Greg's new wiki page, and the discussion so far has
> >> clarified my thinking, and this message tries to express that new
> >> clarity.  I put a conclusion at the end.
> >>
> >> Simon
> >>
> >> Overview
> >> 
> >> It has become clear that there are two elements to pretty much all the
> >> proposals we have on the table.  Suppose we have two types, 'S' and 'T',
> >> both with a field 'f', and you want to select field 'f' from a record
> 'r'.
> >> Somehow you have to disambiguate which 'f' you mean.
> >>
> >> (Plan A) Disambiguate using qualified names.  To select field f, say
> >>(S.f r) or (T.f r) respectively.
> >>
> >> (Plan B) Disambiguate using types. This approach usually implies
> >> dot-notation.
> >> If  (r::S), then (r.f) uses the 'f' from 'S', and similarly if
> >> (r::T).
> >>
> >> Note that
> >>
> >> * The Frege-derived records proposal (FDR), uses both (A) and (B)
> >>  http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
> >>
> >> * The Simple Overloaded Record Fields (SORF) proposal uses only (B)
> >>
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
> >>
> >> * The Type Directed Name Resolution proposal (TDNR) uses only (B)
> >>
> >>
> http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution
> >>
> >> I know of no proposal that advocates only (A).  It seems that we are
> agreed
> >> that we must make use of types to disambigute common cases.
> >>
> >> Complexities of (Plan B)
> >> 
> >> Proposal (Plan B) sounds innocent enough.  But I promise you, it isn't.
> >> There has ben some mention of the "left-to-right" bias of Frege type
> >> inference engine; indeed the wohle explanation of which programs are
> >> accepted and which are rejected, inherently involves an understanding
> >> of the type inference algorithm.  This is a Very Bad Thing when the
> >> type inference algorithm gets complicated, and GHC's is certainly
> >> complicated.
> >>
> >> Here's an example:
> >>
> >>   type family F a b
> >>   data instance F Int [a] = Mk { f :: Int }
> >>
> >>   g :: F Int b  -> ()
> >>   h :: F a [Bool] -> ()
> >>
> >>   k x = (g x, x.f, h x)
> >>
> >> Consider type inference on k.  Initially we know nothing about the
> >> type of x.
> >> * From the application (g x) we learn that x's type has
> >>   shape (F Int ).
> >> * From the application (h x) we learn that x's type has
> >>   shape (F  [Bool])
> >> * Hence x's type must be (F Int [Bool])
> >> * And hence, using the data family we can see which field
> >>   f is intended.
> >>
> >> Notice that
> >> a) Neither left to right nor right to left would suffice
> >> b) There is significant interaction with type/data families
> >>(and I can give you more examples with classes and GADTs)
> >> c) In passing we note that it is totally unclear how (Plan A)
> >>would deal with data families
> >>
> >> This looks like a swamp.  In a simple Hindley-Milner typed language
> >> you might get away with some informal heuristics, but Haskell is far
> >> too complicated.
> >>
> >> Fortunately we know exactly what to do; it is described in some detail
> >> in our paper "Modular type inference with local a

Inlining and generic programming

[José Pedro Magalhães]

Hello all,

First of all, I'm sorry that this email is so absurdly long. But it's not
easy to explain the problem at hand, so I took a step-by-step approach. The
executive summary is: GHC can do a *great *job with inlining, but often it
doesn't, and I don't understand why. So I have some questions, which are
highlighted in the text below. In general, any insights regarding inlining
or improving the performance of generics are welcome. My final goal is to
be able to state that generic functions (in particular using GHC.Generics)
will have no runtime overhead whatsoever when compared to a handwritten
type-specific version.


The setting

Generic programming is based on representing datatypes in a uniform way
using a small set of representation types. Functions defined on those
representation types can then be applied to all datatypes, because we can
convert between datatypes and their representations.
However, generic functions tend to be slower than their specialised
counterparts, because they have to deal with the conversions. But clever
inlining (together with other compiler optimisations) can completely remove
this overhead. The problem I'm tackling is how to tell GHC exactly what it
should in the particular case of optimisation of generic code.


Simplified example

I'll focus on the problem of optimising a non-trivial function for generic
enumeration of terms. My experience shows that GHC does quite good at
optimising simple functions, especially consumers (like generic equality).
But producers are trickier.

First, we'll need some auxiliary functions:

-- | Interleave elements from two lists. Similar to (++), but swap left and
> -- right arguments on every recursive application.
> --
> -- From Mark Jones' talk at AFP2008
> {-# NOINLINE (|||) #-}
> (|||) :: [a] -> [a] -> [a]
> [] ||| ys = ys
> (x:xs) ||| ys = x : ys ||| xs
>
>
> -- | Diagonalization of nested lists. Ensure that some elements from every
> -- sublist will be included. Handles infinite sublists.
> --
> -- From Mark Jones' talk at AFP2008
> {-# NOINLINE diag #-}
> diag :: [[a]] -> [a]
> diag = concat . foldr skew [] . map (map (\x -> [x]))
>
> skew :: [[a]] -> [[a]] -> [[a]]
> skew [] ys = ys
> skew (x:xs) ys = x : combine (++) xs ys
>
> combine :: (a -> a -> a) -> [a] -> [a] -> [a]
> combine _ xs [] = xs
> combine _ [] ys = ys
> combine f (x:xs) (y:ys) = f x y : combine f xs ys
>

The particular implementation of these functions doesn't really matter.
What's important is that we have a way to interleave lists (|||) and a way
to diagonalise a matrix into a list (diag). We mark these functions as
NOINLINE because inlining them will only make the core code more
complicated (and may prevent rules from firing).

Suppose we have a type of Peano natural numbers:

data Nat = Ze | Su Nat deriving Eq
>

Implementing enumeration on this type is simple:

enumNat :: [Nat]
> enumNat = [Ze] ||| map Su enumNat
>

Now, a generic representation of Nat in terms of sums and products could
look something like this:

type RepNat = Either () Nat
>

That is, either a singleton (for the Ze case) or a Nat (for the Su case).
Note that I am building a shallow representation, since at the leaves we
have Nat, and not RepNat. This mimics the situation with current generic
programming libraries (in particular GHC.Generics).

We'll need a way to convert between RepNat and Nat:

toNat :: RepNat -> Nat
> toNat (Left ()) = Ze
> toNat (Right n) = Su n
>
> fromNat :: Nat -> RepNat
> fromNat Ze = Left ()
> fromNat (Su n) = Right n
>

(In fact, since we're only dealing with a generic producer we won't need
the fromNat function.)

To get an enumeration for RepNat, we first need to know how to enumerate
units and sums:

enumU :: [()]
> enumU = [()]
>
> enumEither :: [a] -> [b] -> [Either a b]
> enumEither ea eb = map Left ea ||| map Right eb
>

Now we can define an enumeration for RepNat:

enumRepNat :: [RepNat]
> enumRepNat = enumEither enumU enumNatFromRep
>

With the conversion function toNat, we can use enumRepNat to get an
enumeration for Nat directly:

enumNatFromRep :: [Nat]
> enumNatFromRep = map toNat enumRepNat
>

First, convince yourself that enumNatFromRep and enumNat are equivalent
functions:

take 100 enumNat == take 100 enumNatFromRep
>

Now, what I want is that enumNatFromRep generates the same core code as
enumNat. That should be possible; here are the necessary steps:

  map toNat enumRepNat
>
> == { inline enumRepNat }
>
>   map toNat (enumEither enumU enumNatFromRep)
>
> == { inline enumEither }
>
>   map toNat (map Left enumU ||| map Right enumNatFromRep)
>
> == { inline enumU }
>
>   map toNat (map Left [()] ||| map Right enumNatFromRep)
>
> == { inline map }
>
>   map toNat ([Left ()] ||| map Right enumNatFromRep)
>
> == { free theorem (|||): forall f a b. map f (a ||| b) = map f a ||| map f
> b }
>
>   map toNat [Left ()] ||| map toNat (map Right enumNatFromRep)
>
> == { inline map }
>
>   [toNat (Left ())] ||| map toNat (map Right 

Re: Inlining and generic programming

[José Pedro Magalhães]

Simon,

Thanks a lot for looking into this. One question regarding maps that I
still don't understand: can you explain me if it is indeed to be expected
that GHC won't fuse `map f . map g` into `map (f . g)` by default? Also,
same for `map f [x]` ~> `[f x]`?

Regarding your reply:

2012/3/9 Simon Peyton-Jones 

> You wondered why it made a difference whether you said
>
>   instance GEnum Nat where
> genum = map to genum'
> or
>   instance GEnum Nat-- Fill in from default method
>
> Well, it turns out that the difference is largely accidental.


I understand your explanation for why this can result in different
behaviour. But I think we should try to find a way to address this. We came
up with DefaultSignatures to simplify instantiating generic functions, but
now it turns out that using them can make the code slower! This is rather
unexpected. Could we perhaps have a way to let users specify rewrite rules
involving `cast`?


Cheers,
Pedro
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: update to Template Haskell for rich kinds

[José Pedro Magalhães]

Hi Richard,

Thanks for taking this up! One question: won't we need syntax for arbitrary
promoted constructors (other than lists and tuples) in TH's Type datatype?

Also, is the Constraint kind already in TH? If not, this might be a good
time to add it too.


Cheers,
Pedro

On Mon, Mar 19, 2012 at 03:09, Richard Eisenberg  wrote:

> Hi all,
>
> I'm working on bringing Template Haskell up to speed with the new
> extensions for polymorphic kinds and promoted data kinds. This requires a
> few small, non-breaking changes to TH datatypes. I've made a (short) wiki
> page at http://hackage.haskell.org/**trac/ghc/wiki/**
> TemplateHaskellRichKindsand
>  the official Trac feature request is
> hackage.haskell.org/trac/ghc/**ticket/5612
>
> Does anyone have any suggestions to what I've written? Any other comments?
>
> Thanks!
> Richard
>
> __**_
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.**org 
> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: update to Template Haskell for rich kinds

[José Pedro Magalhães]

Hi Richard,

I've had a look at the updated proposal page; it looks fine to me. I don't
really have a preference between the "standard" and "alternative"
implementations right now.

You do mention parse errors with kinds and promoted constructors (which is
related to http://hackage.haskell.org/trac/ghc/ticket/5682) but I think we
want those things to be synonyms; the current behavior is just a bug.


Cheers,
Pedro

2012/3/20 Richard Eisenberg 

> Yes, we will, but this is already support through the use of ConT.
> The namespaces of defined types and of promoted types are also already
> kept distinct. The one update we would want here is an extension to the
> name quoting syntax. I've updated the Wiki page with my thoughts and
> plans here:
> http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds
>
> In my continued experiments with this, I've realized that we will need
> even more constructors to make all the different kinds expressible. The
> Wiki page is updated for this also, and I've listed two alternative
> implementations. Comments very much appreciated!
>
> Thanks,
> Richard
>
> PS: I added ConstraintK as well.
>
> On 03/20/2012 03:43 AM, José Pedro Magalhães wrote:
> > Hi Richard,
> >
> > Thanks for taking this up! One question: won't we need syntax for
> > arbitrary promoted constructors (other than lists and tuples) in TH's
> > Type datatype?
> >
> > Also, is the Constraint kind already in TH? If not, this might be a good
> > time to add it too.
> >
> >
> > Cheers,
> > Pedro
> >
> > On Mon, Mar 19, 2012 at 03:09, Richard Eisenberg  > <mailto:e...@seas.upenn.edu>> wrote:
> >
> > Hi all,
> >
> > I'm working on bringing Template Haskell up to speed with the new
> > extensions for polymorphic kinds and promoted data kinds. This
> > requires a few small, non-breaking changes to TH datatypes. I've
> > made a (short) wiki page at
> >
> http://hackage.haskell.org/__trac/ghc/wiki/__TemplateHaskellRichKinds <
> http://hackage.haskell.org/trac/ghc/wiki/TemplateHaskellRichKinds>
> > and the official Trac feature request is
> > hackage.haskell.org/trac/ghc/__ticket/5612
> > <http://hackage.haskell.org/trac/ghc/ticket/5612>
> >
> > Does anyone have any suggestions to what I've written? Any other
> > comments?
> >
> > Thanks!
> > Richard
> >
> > _
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users@haskell.__org
> > <mailto:Glasgow-haskell-users@haskell.org>
> > http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users
> > <http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
> >
> >
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users