Re: Type families in kind signatures with TypeInType

[David Menendez]

On Fri, Sep 23, 2016 at 3:00 PM, Simon Peyton Jones 
wrote:

> Interesting. Is this case also an example, or is it a non-feature?
>
>
>
> class C t where
>
> type K t :: Type
>
> type T t :: K t -> Type
>
>
>
> m :: t -> T t a
>
>
>
>
>
> Ah, that’s quite different!  We should do strongly-connected-component
> analysis of the associated-type declarations within a single class
> declaration…. but we don’t currently do that.   No difficulty in principle,
> I think.
>
>
>
> You could open a ticket.   (Do include a link to this email thread and to
> #12088)
>

I’ve opened ticket #12612 .

Assuming GHC accepted this definition, would the Template Haskell trick (or
whatever replaces it) allow defining instances of C?

-- 
Dave Menendez 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Type families in kind signatures with TypeInType

[David Menendez]

On Fri, Sep 23, 2016 at 3:19 AM, Simon Peyton Jones 
wrote:

> This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088.
>

Interesting. Is this case also an example, or is it a non-feature?

class C t where
type K t :: Type
type T t :: K t -> Type

m :: t -> T t a

min.hs:21:17: error:
• Type constructor ‘K’ cannot be used here
(it is defined and used in the same recursive group)
• In the kind ‘K t -> Type’
Failed, modules loaded: none.

GHC accepts this if K t is moved outside of C.


> The “type instance T List” declaration actually depends on the “type
> instance K List” declaration; the latter must be typechecked before the
> former.  But this dependency is absolutely unclear.  There’s a long
> discussion on the thread.  Bottom line: we don’t know a solid automated way
> to spot this kind of problem, so  I think we are going to ask for
> programmer assistance.  In this case, we’d put a “separator” after the
> “type instance K List” decl, to explain that it must be done first:
>
>
>
> type instance K List = Type
>
> ===
>
> type instance T List = []
>
>
>
> Currently you have to write $(return []) to get the separator, but I think
> we’ll add a special separator.
>
>
Yes, this works. Thanks.

It would be disappointing if this is the best we can do, but I guess other
dependent languages don’t need to deal with open type families and
everything being potentially mutually recursive.

-- 
Dave Menendez 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: default roles

[David Menendez]

On Thu, Oct 10, 2013 at 10:09 PM, Edward Kmett ekm...@gmail.com wrote:

 Wait, that sounds like it induces bad semantics.

 Can't we use that as yet another way to attack the sanctity of Set?

 class Ord a = Foo a where
   badInsert :: a - Set a - Set a

 instance Foo Int where
   badInsert = insert

 newtype Bar = Bar Int deriving (Eq,Foo)

 instance Ord Bar where
   compare (Bar x) (Bar y) = compare y x

 Now you can badInsert into a Set.

 If that is still in play then even with all the roles machinery then GND
 doesn't pass the restrictions of SafeHaskell. =(


It seems like doing GND for an instance is okay as long as it's done for
all the superclasses as well.

Alternately, what about keeping non-specialized versions of the instance
code around? Like, if we have (in pseudocode):

ordint :: OrdInstance Int
fooint :: FooInstance Int
ordbar :: OrdInstance Bar

instead of saying foobar = coerce fooint, we could use

fooint_ordint :: OrdInstance Int - FooInstance Int

and set foobar = coerce (foointordint (coerce ordbar)

That seems like it would be correct, albeit less efficient. We can still
use coerce fooint for newtype of Int that also use GND for the Ord instance.

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default roles

[David Menendez]

On Wed, Oct 9, 2013 at 3:21 PM, Richard Eisenberg e...@cis.upenn.edu wrote:

 Now I think we're on the same page, and I *am* a little worried about the
 sky falling because of this. (That's not a euphemism -- I'm only a little
 worried.)

 Well, maybe I should be more worried.

 The whole idea of roles is to protect against type-unsoundness. They are
 doing a great job of that here -- no problem that we've discussed in this
 thread is a threat against type safety.

 The issue immediately at hand is about coherence (or perhaps you call it
 confluence) of instances. Roles do not address the issue of coherence at
 all, and thus they fail to protect against coherence attacks. It would take
 More Thought to reformulate roles (or devise something else) to handle
 coherence.

 It's worth pointing out that this isn't a new problem, exactly. Bug #8338
 shows a way to produce incoherence using only the GADTs extension. (It does
 need 4 modules, though.) I conjecture that incoherence is also possible
 through GeneralizedNewtypeDeriving, both as it existed in GHC 7.6.3 and in
 7.8, so it's not an issue with Coercible, exactly. It's just that Coercible
 allows you to get incoherence with so much less fuss than before!

 Wait! I have an idea!
 The way I've been describing GND all along has been an abbreviation. GHC
 does not coerce a dictionary from, say, Ord Int to Ord Age. Instead, GHC
 mints a fresh dictionary for Ord Age where all the methods are implemented
 as coerced versions of the methods for Ord Int. (I'm not sure why it's
 implemented this way, which is why I've elided this detail in just about
 every conversation on the topic.) With this in mind, I have a proposal:

 1) All parameters of all classes have nominal role.
 2) Classes also store one extra bit per parameter, saying whether all uses
 of that parameter are representational. Essentially, this bit says whether
 that parameter is suitable for GND. (Currently, we could just store for the
 last parameter, but we can imagine extensions to the GND mechanism for
 other parameters.)

 Because GND is implemented using coercions on each piece instead of
 wholesale, the nominal roles on classes won't get in the way of proper use
 of GND. An experiment (see below for details) also confirms that even
 superclasses work well with this idea -- the superclasses aren't coerced.

 Under this proposal, dictionaries can never be coerced, but GND would
 still seem to work.

 Thoughts?

 Richard

 Experiment:

 newtype Age = MkAge Int

 instance Eq Age where
   _ == _ = False

 deriving instance Ord Age

 useOrdInstance :: Ord a = a - Bool
 useOrdInstance x = (x == x)


 What does `useOrdInstance (MkAge 5)` yield? It yields `False` (in HEAD).
 This means that the existing GND mechanism (I didn't change anything around
 this part of the code) uses superclass instances for the *newtype*, not for
 the *base type*. So, even with superclasses, class dictionaries don't need
 to be coerced.


Does GND make sense in cases where the superclasses aren't also derived? If
I had a type T whose Ord instance made use of the Eq instance for some
reason, and then I made a newtype T' with a new Eq instance and a GND Ord
instance, the calls to (==) in the Ord instance will refer to the T
implementation, right?

That seems like what'd we'd expect GND to do, but is it ever something you
would want to do?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default roles

[David Menendez]

On Thu, Oct 10, 2013 at 12:11 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:

  Does GND make sense in cases where the superclasses aren't also derived?
 If I had a type T whose Ord instance made use of the Eq instance for some
 reason, and then I made a newtype T' with a new Eq instance and a GND Ord
 instance, the calls to (==) in the Ord instance will refer to the T
 implementation, right?

 ** **

 Yes, absolutely. 

   class Show a = C a where

 op :: a - a

 ** **

 You might want to use GND for the (C Age) instance, but NOT use GND for
 the Show instance.


Sure, but if op uses show internally, we get Int's show, not Age's, right?
That seems correct, in that it's doing what GND is supposed to do, but I'll
bet it will surprise people.

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

[David Menendez]

On Thu, Jun 7, 2012 at 2:37 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 Kind polymorphism and promoted kinds is *not* an advertised feature of 7.4.1. 
  Much code is there, but it doesn't work when you push it.  The HEAD does 
 work.  If you are using kind polymorphism or promoted kinds, use HEAD (or a 
 development snapshot).

I'll keep that in mind if I do anything serious. For now, I've been
able to work around the oddity by using my own pairs and lists. If
anything, it works better than I expected.

 Indeed not_okay compiles fine with HEAD

Glad to hear it.

 | -Original Message-
 | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
 | users-boun...@haskell.org] On Behalf Of David Menendez
 | Sent: 06 June 2012 23:50
 | To: José Pedro Magalhães
 | Cc: glasgow-haskell-users@haskell.org Mailing List
 | Subject: Re: Known problems with promoted tuples and lists in GHC 7.4.1?
 |
 | No, I'm just running 7.4.1.
 |
 | Here's a very stripped-down example of what I'm seeing:
 |
 | {-# LANGUAGE PolyKinds, DataKinds #-}
 |
 | data Pair a b = P a b
 | data Nat = Z | S Nat
 |
 | data Phantom i = Phantom
 |
 | okay :: Phantom ('P Int Int)
 | okay = Phantom
 |
 | -- not_okay :: Phantom '(Int, Int)
 | -- not_okay = Phantom
 |
 | Uncommenting that last bit results in this error,
 |
 |     Couldn't match kind `BOX' against `*'
 |     Kind incompatibility when matching types:
 |       k0 :: BOX
 |       (*, *) :: *
 |     In the expression: Phantom
 |     In an equation for `not_okay': not_okay = Phantom
 |
 | Something seems to have gone wrong internally.
 |
 |
 | On Wed, Jun 6, 2012 at 5:43 PM, José Pedro Magalhães j...@cs.uu.nl
 | wrote:
 |  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 d...@zednenem.com
 | 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 d...@zednenem.com
 |  http://www.eyrie.org/~zednenem/
 | 
 |  ___
 |  Glasgow-haskell-users mailing list
 |  Glasgow-haskell-users@haskell.org
 |  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 | 
 | 
 |
 |
 |
 | --
 | Dave Menendez d...@zednenem.com
 | http://www.eyrie.org/~zednenem/
 |
 | ___
 | Glasgow-haskell-users mailing list
 | Glasgow-haskell-users@haskell.org
 | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/

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

Known problems with promoted tuples and lists in GHC 7.4.1?

[David Menendez]

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 d...@zednenem.com
http://www.eyrie.org/~zednenem/

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

Re: Unit unboxed tuples

[David Menendez]

On Sat, Dec 24, 2011 at 7:15 AM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
 On 23 December 2011 20:09, Stefan Holdermans ste...@vectorfabrics.com wrote:
 Here are the kinds of the type constructors:

                 (,,) :: * - * - * - *
                 (,) :: * - * - *
                 () :: *

                 (# ,, #) :: * - * - * - #
                 (# , #) :: *  - * - #
 BUT
                 (#  #) :: * - #

 Just of out curiosity, what would be a compelling use case for singleton and 
 unit unboxed tuples?

 For singleton unboxed tuples, any situation where you want to return a
 single value but not force its evaluation. This occurs for example
 with some low level functions in the implementation of ordinary lazy
 arrays.

How is that different from returning a normal value?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/

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

Re: Implicit 'forall' in data declarations

[David Menendez]

On Mon, Oct 25, 2010 at 3:16 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 | On a related note, these are also apparently allowed (in 6.10.4):
 |     f :: forall a. (Eq a = a - a) - a - a
 |    -- the Eq context prevents the function from ever being called.

 That's not true.  E.g.
        f ((==) True) True
 works fine.

What I meant is that f cannot call its argument. That is,

  f :: forall a. (Eq a = a - a) - a - a
  f g x = g x

is ill-typed.


 |    g :: forall a. Ord a = (Eq a = a - a) - a - a
 |    -- the Eq context is effectively ignored

 That's a bit more true, because Ord a implies Eq a, but still not really.  It 
 still says
 that you must pass evidence for equality to g's argument.

Is that different from forall a. Ord a = (a - a) - a - a?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Implicit 'forall' in data declarations

[David Menendez]

On Fri, Oct 22, 2010 at 4:20 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
 Does anyone listening to this thread have an opinion?  Just to summarise, 
 Sebastian's
 proposal is that Haskell's implicit quantification (adding foralls) would 
 occur *only* right
 at the top of a  type signature.

Before this discussion, I thought things already worked the way you
describe in your proposal.

On a related note, these are also apparently allowed (in 6.10.4):
f :: forall a. (Eq a = a - a) - a - a
   -- the Eq context prevents the function from ever being called.

   g :: forall a. Ord a = (Eq a = a - a) - a - a
   -- the Eq context is effectively ignored

Up until now, I thought contexts were only allowed after a forall
(explicit or implicit), and I can't really think of a reason to have
one anywhere else.

My suggestion would be either
(1) forbid contexts, except after foralls, and only implicitly add
foralls at the top of the type
(2) add implicit foralls before any context, even if the variables are
already in scope

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Inliner behaviour - tiny changes lead to huge performance differences

[David Menendez]

On Fri, Nov 13, 2009 at 2:04 AM, Bryan O'Sullivan b...@serpentine.com wrote:

 And the lengthI function is defined more generally, in the hope that I could
 use it for both Int and Int64 lengths:

 lengthI :: Integral a = Stream Char - a
 lengthI (Stream next s0 _len) = loop_length 0 s0
     where
       loop_length !z s  = case next s of
                            Done       - z
                            Skip    s' - loop_length z s'
                            Yield _ s' - loop_length (z + 1) s'
 {-# INLINE[0] lengthI #-}

Would it help to SPECIALIZE lengthI for Int and Int64?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: inferred type doesn't type-check (using type families)

[David Menendez]

On Tue, Nov 3, 2009 at 3:20 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
 2009/11/3 Daniel Fischer daniel.is.fisc...@web.de:
 Am Dienstag 03 November 2009 19:28:55 schrieb Roland Zumkeller:
 Hi,

 Compiling

  class WithT a where
    type T a
 
  f :: T a - a - T a
  f = undefined
 
  g x = f x 42

 with -XTypeFamilies -fwarn-missing-signatures gives:

              Inferred type: g :: forall a. (Num a) = T a - T a

 Adding

  g :: Num a = T a - T a

 results in:

     Couldn't match expected type `T a' against inferred type `T a1'
     In the first argument of `f', namely `x'

 Is the inferred type not the right one? Is g typeable?

 The type function T isn't injective (or, it isn't guaranteed to be), so 
 there's no way to
 determine which type a to use for 42.

 I think (untested) that in this particular case you can get around the
 problem using scoped type variables:

 g :: forall a. Num a = T a - T a
 g x = f x (42 :: a)

GHC accepts this, but arguably shouldn't as there's no way to call g.
Neither the argument to g nor the context of g has enough information
to specify a, so there's no way to know what's intended.

 In fact, this seems to be the general pattern for fixing problems like
 this with type families: add extra witness arguments which GHC can
 use to unify type variables that are hidden inside type family
 applications.

This is true. You can use a dummy argument to force the choice of a,
and if the dummy isn't used it gets removed in optimization.

data Proxy a  -- no values, so should always be removable during optimization

g :: forall a. Num a = Proxy a - T a - T a
g _ x = f x (42 :: a)   -- works fine

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker's expected and inferred types (reformatted)

[David Menendez]

On Sun, Oct 25, 2009 at 1:37 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
 David Menendez wrote:

 The expected type is what the context wants (it's *ex*ternal). The
 inferred type is what the expression itself has (it's *in*ternal).

 So inferring the type Maybe () for bar seems wrong.

 well, maybe GHC just gets it wrong enough of the time, that I got confused.

 Or maybe ... When there are bound variables interacting, on the inside and
 outside, it gets confusing.


 ghci:
 Prelude \x - (3+x) + (length x)

 interactive:1:15:
    Couldn't match expected type `[a]' against inferred type `Int'
    In the second argument of `(+)', namely `(length x)'
    In the expression: (3 + x) + (length x)
    In the expression: \ x - (3 + x) + (length x)

 Your explanation of expected and inferred could make sense to me if the
 error message followed the Couldn't match line with, instead,
    In the first argument of `length', namely `x'
 because 'length' gives the context of expected list-type, but we've found
 out from elsewhere (a vague word) that 'x' needs to have type Int.

This had me confused for a while, but I think I've worked out what's
happening. (+) is polymorphic, and GHC is giving it the type [a] -
[a] - [a]. So the context is expecting [a], but we infer length x ::
Int from the definition of length.

In the alternate case, \x - length x + (3+x), GHC gives the outer (+)
the type Int - Int - Int, and the inner (+) the type [a] - [a] -
[a], which is why we get the type mismatch complaint for 3+x instead
of x.

Note what happens if we use a monomorphic operator:

Prelude let () = undefined :: Int - Int - Int
Prelude \x - (3+x)  length x

interactive:1:22:
Couldn't match expected type `[a]' against inferred type `Int'
In the first argument of `length', namely `x'
In the second argument of `()', namely `length x'
In the expression: (3 + x)  length x
Prelude \x - (3+x) + length x

Here, GHC has concluded that x must be an Int, and thus can't be
passed to length.

Prelude \x - length x  (3+x)

interactive:1:19:
Couldn't match expected type `Int' against inferred type `[a]'
In the second argument of `()', namely `(3 + x)'
In the expression: length x  (3 + x)
In the expression: \ x - length x  (3 + x)

Here, GHC has concluded that x must be [a], and thus 3+x must be [a],
which can't be used with .

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker's expected and inferred types (reformatted)

[David Menendez]

On Fri, Oct 23, 2009 at 9:46 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org wrote:
 C Rodrigues wrote:

 fun1 produces the error message:
 Couldn't match expected type `Maybe a' against inferred type `IO ()'
 In the first argument of `(=)', namely `bar'


 fun2 produces the error message:
 Couldn't match expected type `IO ()' against inferred type `Maybe ()'
 In a stmt of a 'do' expression: bar


 It's confusing because 'bar' is inferred to have type Maybe (), even
 though it's explicitly declared to be an IO ().

 Which message do you prefer? I couldn't tell which it was.

 For myself, I never understood the difference between expected and
 inferred: it works better for me to just think there were at least two
 different ways that determined the 'type' of this expression, and the
 results contradicted each other, and here are two of those results.  Now,
 dear user, go and look at your code to intuit *what* those ways of
 determining the type might have been (or sometimes it's easier just to look
 for mistakes, ignoring the particular details of the error)

The expected type is what the context wants (it's *ex*ternal). The
inferred type is what the expression itself has (it's *in*ternal).

So inferring the type Maybe () for bar seems wrong. I'm guessing it's
a bug in the way do-expressions are handled. Note that this doesn't
happen if the bar is last.

Prelude :t let fooThen m = foo  m in fooThen (do undefined; bar)

interactive:1:51:
Couldn't match expected type `Maybe b'
   against inferred type `IO ()'
In the expression: bar
In the first argument of `fooThen', namely
`(do undefined
 bar)'
In the expression:
fooThen
  (do undefined
  bar)

Prelude :t do foo; bar

interactive:1:8:
Couldn't match expected type `Maybe b'
   against inferred type `IO ()'
In the expression: bar
In the expression:
do foo
   bar
Prelude :t do foo; bar; foo

interactive:1:8:
Couldn't match expected type `IO ()'
   against inferred type `Maybe ()'
In a stmt of a 'do' expression: bar
In the expression:
do foo
   bar
   foo

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC on Snow Leopard: best practices?

[David Menendez]

Is there any consensus about what needs to be done to get a working
ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS
X wiki page[1] currently links to a blog post[2] that recommends
manually patching /usr/bin/ghc, but I have also seen recommendations
that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also
recommended? If so, there should probably be an updated how-to on the
wiki.

I expect most Haskell users are capable of patching the scripts
themselves, given instructions, but it's hardly convenient. Would it
be practical to repackage the current ghc installer with updated
scripts for Snow Leopard? If not, will there be updated scripts
available for the forthcoming releases of GHC or the Haskell Platform?


[1] http://www.haskell.org/haskellwiki/Mac_OS_X
[2] 
http://obvioushints.blogspot.com/2009/09/running-haskell-ghc-on-snow-leopard.html
-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Could not deduce (MArray (STUArray s) Int (ST s)) from context () when applying runST

[David Menendez]

On Tue, Jul 21, 2009 at 5:30 PM, Christian Klauserch27...@gmail.com wrote:
 Hi, I'm in the process of learning haskell and came across this problem:

 Using `Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2
 booted by GHC version 6.10.1`

 Common beginning of the file
 
    {-# LANGUAGE FlexibleContexts #-}

    module UPSO where

    import Control.Monad(forM,forM_)
    import Control.Monad.ST.Lazy (ST,runST)

This works if I replace Control.Monad.ST.Strict instead of
Control.Monad.ST.Lazy.

The problem is that the MArray instances are declared for the strict
ST monad; there appear to be no corresponding instances for the lazy
ST monad.

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Re: FlexibleContexts and FlexibleInstances

[David Menendez]

On Thu, Jun 11, 2009 at 4:16 AM, Claus Reinkeclaus.rei...@talk21.com wrote:
 |What you describe is exactly how I would *want* things to work. It's
 |nice to hear my wishes echoed from a user perspective. :-)

 actually, I was describing how things seem to work right now.

 | Only MultiParamTypeClasses does (and neither extension is needed in the
 | module defining 'f', if 'T' is imported, which suggests that
 | MultiParamTypeClasses is propagated to importers - this isn't true for
 | most other extensions). The documentation still points to -fglasgow-exts,
 so
 | it doesn't seem to answer these questions..
 |
 |Right you are - which seems very strange to me. GHC accepts the module
 |defining 'f' with no flags at all, even though it is clearly not
 |Haskell 98. I'd go so far as to say that's a bug (as opposed to just
 |unwanted/unexpected behavior).

 It is not that strange, really (it ought to be documented, but the fan-
 out from glasgow-exts/hugs mode to more detailed extensions has
 been fairly recent, compared to the lifetime of these features):

 if module 'A' exports multiparameter type classes, importers of those
 classes have to have MultiParamTypeClasses on - there are no legal
 uses of those imports otherwise (while FlexibleInstances/Contexts can
 just affect a subset of use sites).

It's more complicated than that. If you have two modules A and B,
defined like so:

{-# LANGUAGE MultiParamTypeClasses #-}

module A where

class Foo a b where
foo :: a - b

instance Foo Bool Int where
foo True = 1
foo False = 0

--

module B where

import A

bar :: (Foo a b) = [a] - [b]
bar = map foo

I can load B.hs into GHCi and call bar without problems. So the import
of Foo is fine. But you still get an error if you try to declare an
instance of Foo in B.hs.

instance Foo Bool Integer where
foo True = 1
foo False = 0

B.hs:8:0:
Illegal instance declaration for `Foo Bool Integer'
(Only one type can be given in an instance head.
 Use -XMultiParamTypeClasses if you want to allow more.)
In the instance declaration for `Foo Bool Integer'
Failed, modules loaded: A.


-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Fwd: OSX installer -- first draft]

[David Menendez]

On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
 OSX users,

 please could you try out Gregory's Haskell Platform package below and
 send commentary to the platform list, or file tickets in the platform
 trac, that'd be great.
 http://trac.haskell.org/haskell-platform/newticket?component=OSX%20installer

Is this a universal binary, or Intel-only?

 The plan is that for ghc-6.12 and onwards, that this will be the primary
 way that end-users get their Haskell goodness on OSX, so it's important
 that you provide feedback now so that we can get the thing working
 nicely and try to make everyone happy.

Will there be some integration with the existing distribution schemes
for Mac OS X (fink and macports), or are end users expected to use
cabal install?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC

[David Menendez]

On Mon, Feb 2, 2009 at 9:58 AM, Gregory Wright gwri...@comcast.net wrote:
 On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote:

 David Menendez wrote:

 I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4
 running OS X 10.5.5. From what I can tell, I'm getting a segmentation
 fault from cabal-bin.

 On PPC leopard you need to update to XCode 3.1
 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX
 http://hackage.haskell.org/trac/ghc/ticket/2887

 HTH Christian


 It would be very helpful to know if this solves the problem for you.  I've
 had reports
 of similar failures on 10.4, but have not been able to reproduce them on a
 ppc/10.4 machine
 or a ppc/10.5 machine.

 Even with Xcode 3.0, it seems as if not everyone gets tagged by the error.

This took care of the problem for me. Thanks.

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC

[David Menendez]

I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4
running OS X 10.5.5. From what I can tell, I'm getting a segmentation
fault from cabal-bin.

This is possibly related to http://trac.macports.org/ticket/15142
and http://hackage.haskell.org/trac/ghc/ticket/2380.


cd extensible-exceptions 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf
configure --distpref=dist-bootstrapping
--with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
--with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg
--package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp
/bin/sh: line 1: 19203 Segmentation fault
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf
configure --distpref=dist-bootstrapping
--with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
--with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg
--package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp
make[1]: *** [bootstrapping.conf] Error 139
make: *** [stage1] Error 2



-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Changes in scoped type variable behavior?

[David Menendez]

2009/1/23 Austin Seipp mad@gmail.com:

 The code is attached to this message; the problem is in the normalize
 function:

 normalize :: (Modular s a, Integral a) = a - M s a
 normalize a = M (mod a (modulus (u :: s)))

s isn't scoped over the definition of normalize in this
definition. You need an explicit forall.

normalize :: forall s a. (Modular s a, Integral a) = a - M s a
normalize a = M (mod a (modulus (u::s)))

See section 8.8.6 of the GHC manual.

http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped-type-variables


-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Differences in pattern matching syntax?

[David Menendez]

On Fri, Jan 16, 2009 at 11:07 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:

 So, clearly not a bug in GHC; but it would be more felicitous if it gave you 
 a warning about the instance declaration for Eq RuleType.  The difficulty is 
 that it's not clear when to warn; it's ok to use default methods, but you 
 must define *either* (==) *or* (/=).

Why is (/=) a member of Eq in the first place? Is there any code that
defines (/=) and uses the default for (==)?

-- 
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Unicode's greek lambda

[David Menendez]

On Wed, Nov 19, 2008 at 5:24 PM, Duncan Coutts
[EMAIL PROTECTED] wrote:
 On Wed, 2008-11-19 at 15:01 +, Tony Finch wrote:
 On Wed, 19 Nov 2008, Simon Marlow wrote:
 
  Tue Jan 16 16:11:00 GMT 2007  Simon Marlow [EMAIL PROTECTED]
* Remove special lambda unicode character, it didn't work anyway
Since lambda is a lower-case letter, it's debatable whether we want to
steal it to mean lambda in Haskell source.  However if we did, then we
would probably want to make it a special symbol, not just a reserved
symbol, otherwise writing \x-... (using unicode characters of course)
wouldn't work, because \x would be treated as a single identifier,
you'd need a space.

 There are a number of mathematical lambdas in Unicode (distinct from teh
 Greek lambdas), but they are not in the basic multilingual plane and they
 are presumably not very easy to type :-)

 Do you know what they are? I couldn't find any other than the greek
 lambda λ and the latin lambda with stroke ƛ.

They're listed under Mathematical Alphanumeric Symbols.
http://www.unicode.org/charts/PDF/U1D400.pdf

e.g., 1D6CC mathematical bold small lambda


-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Lazy minimum

[David Menendez]

On Wed, Nov 19, 2008 at 8:06 PM, Dave Bayer [EMAIL PROTECTED] wrote:

 What I'm wondering, however, is if there is a way to code minimum
 efficiently in general,

 minimum :: Ord a = [a] - a


 where one knows absolutely nothing further about the type a, but one
 believes that lazy evaluation will run afoul of the above issue.

 It would seem that this would require compiler support, allowing code to
 access approximations to lazy data generalizing the head of a lazy list. I'm
 reminded of working with power series by working mod x^n for various n.
 Here, I'd like a bounded version of compare, that returned EQ for data
 that agreed to a specified lazy evaluation depth.

 Did I miss that class? Is there a construct in GHC that would allow me to
 write minimum efficiently for lazy data?

One possibility would be to add minimum and maximum to Ord with the
appropriate default definitions, similar to Monoid's mconcat.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Lazy minimum

[David Menendez]

On Thu, Nov 20, 2008 at 12:18 AM, Dan Doel [EMAIL PROTECTED] wrote:
 On Wednesday 19 November 2008 11:38:07 pm David Menendez wrote:
 One possibility would be to add minimum and maximum to Ord with the
 appropriate default definitions, similar to Monoid's mconcat.

 This is probably the most sensible way.

Now that I've thought about it more, the problem is that min and max
are insufficiently lazy for lists. Here's a list clone that has the
desired properties:

data List a = Nil | a : List a deriving (Show, Eq)

instance Ord a = Ord (List a) where
compare Nil Nil = EQ
compare Nil _ = LT
compare _ Nil = GT
compare (a : as) (b : bs) =
case compare a b of
LT - LT
EQ - compare as bs
GT - GT

min (a : as) (b : bs) =
case compare a b of
LT - a : as
EQ - a : min as bs
GT - b : bs
min _ _ = Nil

head' (a : as) = a
head' _ = error head': empty List

Thus,

*Main head' $ min (2 : undefined) (2 : undefined)
2
*Main minimum [2 : undefined, 2 : undefined, 1 : Nil]
1 : Nil

The tricky part is that derived instances of Ord do not make min (and
max) lazy in this way, so you have to write your own. There are also
possible space issues, since min a b will end up re-creating much of
a or b if they share a large common prefix.

snip
 This also has the issue of not really solving the problem all the
 way down. For instance, I think:

let a = replicate (2^20) 2
 in minimum [[[a]], [[a]], [[1]]]

 still shows bad behavior. So you need an algorithm more clever than the one
 I've come up with. :)

Yeah, my solution falls down there, too.

*Main minimum [(2 : undefined) : Nil, (2 : undefined) : Nil, (1
: Nil) : Nil]
*** Exception: Prelude.undefined

I don't know if there's a good, general solution here.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Control.Exception

[David Menendez]

On Mon, Nov 3, 2008 at 12:53 PM, Duncan Coutts
[EMAIL PROTECTED] wrote:
 On Mon, 2008-11-03 at 09:26 -0800, Sigbjorn Finne wrote:
 One way to do this now is to use Control.Exception.catches:

  catches :: IO a - [Handler a] - IO a
  data Handler a where
 Handler :: forall a e. (Exception e) = (e - IO a) - Handler a

 ie:

 action
  `catches`
[ \(e :: ExitCode) - ...
, \(e :: PatternMatchFail) - ...
]

 or just by using multiple catch clauses:

 action
  `catch` (\(e :: ExitCode) - ...)
  `catch` (\(e :: PatternMatchFail) - ...)

I don't think those are equivalent. In the second case, the
PatternMatchFail handler scopes over the ExitCode handler.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: No atomic read on MVar?

[David Menendez]

On Mon, Nov 3, 2008 at 6:29 AM, Philip K.F. Hölzenspies
[EMAIL PROTECTED] wrote:

 I have now implemented my variable as a pair of MVars, one of which serves as
 a lock on the other. Both for performance reasons and for deadlock analysis,
 I would really like an atomic read on MVars, though. Does it exist? If not,
 why not?

Have you considered using STM? All the operations on TMVars are atomic.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Control.Exception

[David Menendez]

On Mon, Nov 3, 2008 at 7:27 PM, shelarcy [EMAIL PROTECTED] wrote:
 On Tue, 04 Nov 2008 07:40:50 +0900, David Menendez [EMAIL PROTECTED] wrote:
 ie:

 action
  `catches`
[ \(e :: ExitCode) - ...
, \(e :: PatternMatchFail) - ...
]

 or just by using multiple catch clauses:

 action
  `catch` (\(e :: ExitCode) - ...)
  `catch` (\(e :: PatternMatchFail) - ...)

 I don't think those are equivalent. In the second case, the
 PatternMatchFail handler scopes over the ExitCode handler.

 I think Duncan forgot to write parens. According to Ian's example,
 here is an equivalent code.

 (action
  `catch` (\(e :: ExitCode) - ...))
  `catch` (\(e :: PatternMatchFail) - ...)

 http://www.haskell.org/pipermail/libraries/2008-July/010095.html

That's equivalent to the code without the parentheses, but it isn't
equivalent to the code using catches.

Assume we have exitCodeHandler :: ExitCode - IO () and
pattternMatchHandler :: PatternMatchFail - IO (),

1. action `catches` [ Handler exitCodeHandler, Handler patternMatchHandler ]
2. (action `catch` exitCodeHandler) `catch` patternMatchHandler

Let's further assume that action throws an ExitCode exception and
exitCodeHandler throws a PatternMatchFail exception. In example 1,
the PatternMatchFail exception thrown by exitCodeHandler is not
caught by patternMatchHandler, but it in example 2 it is caught.

In other words, patternMatchHandler is active during the evaluation of
exitCodeHandler in example 2, but not in example 1.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
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)

[David Menendez]

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.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)

[David Menendez]

On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg
[EMAIL PROTECTED] wrote:
 src\HSX\XMLGenerator.hs:71:0
Illegal type synonym family application in instance: XML m
In the instance declaration for `EmbedAsChild m (XML m)´
 ---

 Could someone help me point out the problem here? The relevant code is:

 instance XMLGen m = EmbedAsChild m (XML m) where
  asChild = return . return . xmlToChild

 class XMLGen m = EmbedAsChild m c where
  asChild :: c - GenChildList m

 class Monad m = XMLGen m where
  type XML m
  

 This works fine with 6.8.3, so what's new in 6.10, and what would I do
 to solve it?

I'm guessing there was a bug in 6.8.3 that allowed this. (The
implementation of type families is present but not supported in 6.8,
presumably because of problems like this.)

I don't have 6.10, so I can't test anything, but you might try
rewriting the EmbedAsChild instances like so:

instance (XMLGen m, XML m ~ x) = EmbedAsChild m x where ...

Alternatively, you can make separate instances for every type in the
range of XML.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADTs and functional dependencies

[David Menendez]

On Tue, Sep 23, 2008 at 1:44 PM, Chris Kuklewicz
[EMAIL PROTECTED] wrote:
 You cannot create a normal function fun.  You can make a type class
 function

 fun :: Class a b = GADT a - b

 data GADT a where
 GADT :: GADT ()
 GADT2 :: GADT String

 -- fun1 :: GADT () - () -- infers type
 fun1 g = case g of
   (GADT :: GADT ()) - ()

 -- fun2 :: GADT String - Bool -- infers type
 fun2 g = case g of
   (GADT2 :: GADT String) - True

 -- fun cannot type check.  The type of 'g' cannot be both GADT () and
 GADT String
 -- This is because fun is not a member of type class.
 {- fun g = case g of
   (GADT :: GADT ()) - ()
   (GADT2 :: GADT String) - True
 -}

It may be that fun cannot type check, but surely it isn't for the
reason you've given.

data Rep a where
Unit :: Rep ()
Int :: Rep Int

zero :: Rep a - a
zero r = case r of
Unit - ()
Int - 0

The type of r is both Rep () and Rep Int. No type class needed.

If I had to guess, I'd say the original problem is that any
specialization triggered by the functional dependency happens before
the specialization triggered by pattern matching on the GADT. If I
recall correctly, it is known that GADTs and fundeps don't always work
nicely together.

The example does seem to work if translated to use type families.

type family Fam t :: *
type instance Fam () = ()

data GADT a where
GADT :: GADT ()

fun :: GADT a - Fam a
fun GADT = ()

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Arrow without `'

[David Menendez]

On Jan 23, 2008 12:20 PM, Valery V. Vorotyntsev [EMAIL PROTECTED] wrote:

 I've built GHC from darcs, and...
 Could anybody tell me, what's the purpose of Arrow[1] not having `'
 method?


It's derived from the Category superclass.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] class default method proposal

[David Menendez]

On Dec 11, 2007 9:20 AM, Duncan Coutts [EMAIL PROTECTED] wrote:

 So my suggestion is that we let classes declare default implementations
 of methods from super-classes.

snip.

 Does this proposal have any unintended consequences? I'm not sure.
 Please discuss :-)


It creates ambiguity if two classes declare defaults for a common
superclass.

My standard example involves Functor, Monad, and Comonad. Both Monad and
Comonad could provide a default implementation for fmap. But let's say I
have a type which is both a Monad and a Comonad: which default
implementation gets used?

I'm disappointed to see this objection isn't listed on the wiki.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] class default method proposal

[David Menendez]

On Dec 11, 2007 1:29 PM, apfelmus [EMAIL PROTECTED] wrote:

 Without the automatic search, this is already possible

 class Functor f where
 fmap :: (a - b) - f a - f b

 class Functor m = Monad m where
 return :: a - m a
 (=)  :: m a - (a - m b) - m b

-- aka liftM
 fmapDefault :: Monad m = (a - b) - m a - m b
 fmapDefault f m = m = (return . f)

 instance Monad [] where
 return x = [x]
 (=)= flip concatMap

 instance Functor [] where
 fmap = fmapDefault

  fmap  is already written for you, the instance declaration is only
 boilerplate. I first saw this in  Data.Traversable .


This is pretty much how I define Functor and Applicative instances for my
monads. It is admittedly irritating to have to write out the boilerplate,
but  it doesn't seem irritating enough to require a language extension to
eliminate.

-- 
Dave Menendez [EMAIL PROTECTED]
http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: forall a (Ord a = a- a) - Int is an illegal type???

[David Menendez]

Brian Hulley writes:

 I've been puzzling over section 7.4.9.3 of the ghc users manual for
 the past few months (!) and still can't understand why the following
 is an illegal type:
 
 forall a. ((Ord a = a- a) - Int)
 
 whereas
 
 (forall a. Ord a = a-a) - Int
 
 is legal. I can understand why the second one *is* legal but I can't
 seem to understand why the first syntax is not just exactly the same
 thing even though the parse tree is different.

I see you already clarified this, but I'd like to point out that

forall a. (a - a) - Int

and

(forall a. a - a) - Int

are very different. The first essentially takes two arguments, a type
|a| and a value of type |a - a|. The second takes a single argument of
type |forall a. a - a|.
 
There are some type systems (like JHC core, IIRC) which treat forall
and - as special cases of the dependent product. That is, T - U is
short for Pi _:T. U and forall a. T is short for Pi a:*. T. Using
that syntax, the types above become:

Pi a:*. Pi _:(Pi _:a. a). Int

and

Pi _:(Pi a:*. Pi _:a. a). Int
-- 
David Menendez [EMAIL PROTECTED] | In this house, we obey the laws
http://www.eyrie.org/~zednenem  |of thermodynamics!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: forall a (Ord a = a- a) - Int is an illegal type???

[David Menendez]

Ben Rudiak-Gould writes:

| Also, the rule would not be quite as simple as you make it out to be,
| since
| 
|  forall a. (forall b. Foo a b = a - b) - Int
| 
| is a legal type, for example.

Is it? GHCi gives me an error if I try typing a function like that.

 {-# OPTIONS -fglasgow-exts #-}
 class Foo a b
 
 f :: forall a. (forall b. Foo a b = a - b) - Int
 f = undefined

No instance for (Foo a b)
  arising from instantiating a type signature at x.hs:5:4-12
Probable fix: add (Foo a b) to the type signature(s) for `f'
  Expected type: (forall b1. (Foo a b1) = a - b1) - Int
  Inferred type: (a - b) - Int
In the definition of `f': f = undefined

I think there would need to be a top-level constraint on |a| to
guarantee that an instance of |Foo a b| exists, like

forall a. (exists c. Foo a c) =
(forall b. Foo a b = a - b) - Int
-- 
David Menendez [EMAIL PROTECTED] | In this house, we obey the laws
http://www.eyrie.org/~zednenem  |of thermodynamics!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Simple GADTs Question

[David Menendez]

J. Garrett Morris writes:

 Hello,
 
 I'm attempting to use GADTs for the first time, and I'm running into
 an (I think) odd error.  My file includes:
 
 data DFExpr :: * - *
 where Deriv :: (Num t) = t - Deriv Int (DFExpr t) (DFExpr t)

I think you want something like this:

Deriv :: Int - DFExpr t - DFExpr t - DFExpr t

Ignorning the other clauses, it's equivalent to

data DFExpr t = Deriv Int (DFExpr t) (DFExpr t)
-- 
David Menendez [EMAIL PROTECTED] | In this house, we obey the laws
http://www.eyrie.org/~zednenem  |of thermodynamics!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Automatically derived instances

[David Menendez]

Juan Carlos Arevalo Baeza writes:

(BCC'ing the GHC bugs list)
 
It seems like there's something very funky going on with GHC (6.4) 
 and automatically deriving instances. Consider this code:
 
 ---8--
 1: class MyClass a
 2:
 3:instance MyClass a = Show a
 4:
 5:newtype Type1 = Type1 { unType1 :: Int } deriving (Show)
 6:
 7:main = putStrLn $ show $ Type1 4
 ---8--

Your problem is the instance in line 3. The way Haskell type classes
work, the overlap is determined without looking at the context, so Show
a will overlap with every possible instance for Show, including Show
Int, which is predefined.

I'm not sure what the official justification for that is, but reason is
to avoid situations like this:

class A t where a :: t
class B t where b :: t
class C t where c :: t

instance A t = C t where c = a
instance B t = C t where c = b

instance A Char where a = 'a'
instance B Char where b = 'b'

What should c :: Char evaluate to?
-- 
David Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Error building GHC from darwin ports

[David Menendez]

I currently have GHC installed using darwin ports, and I've been trying
to upgrade from 6.4_0 to 6.4_8, but I keep hitting a file-not-found
error. Looking at the paths in question, I'm guessing the problem has to
do with the path segment
/var/db/dports/build/file._opt_local_var_db_dports_sources_rsync.rsync.
opendarwin.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/ appearing
twice.

Unfortunately, I don't understand the makefiles well enough to track
down where this is happening. I'm running Mac OS X 10.4 with XCode 2.0
and darwinports 1.001.


Here are the relevant errors:
-

/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -M -optdep-f
-optdep.depend  -osuf o-H16m -O -I/usr/include -I/opt/local/include
-L/usr/lib -L/opt/local/lib -cpp -fglasgow-exts -O AbsSyn.lhs First.lhs
GenUtils.lhs GetOpt.lhs Grammar.lhs Info.lhs LALR.lhs Lexer.lhs Main.lhs
ParseMonad.lhs Parser.hs ProduceCode.lhs ProduceGLRCode.lhs Set.lhs
Target.lhs Version.hs

/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5:
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/file
._opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4: No
such file or directory

/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: exec:
/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/file
._opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4:
cannot execute: No such file or directory

gmake[2]: *** [depend] Error 126
gmake[1]: *** [boot] Error 1
gmake[1]: Leaving directory
`/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy'
gmake: ***
[/opt/local/var/db/dports/build/file.
_opt_local_var_db_dports_sources_rsync.rsync.opendarwin.
org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy/src/happy-inplace] Error
2

Warning: the following items did not execute (for ghc):
com.apple.destroot com.apple.build
Error: Unable to upgrade port: 1
-- 
David Menendez [EMAIL PROTECTED] | In this house, we obey the laws
http://www.eyrie.org/~zednenem  |of thermodynamics!
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users