RE: The monomorphism restriction and monomorphic pattern bindings

| Ok.  So I counter-propose that we deal with pattern bindings like this:
|
|    The static semantics of a pattern binding are given by the following
|    translation.  A binding 'p = e' has the same meaning as the set of
|    bindings
|
|      z = e
|      x1 = case z of { p -> x1 }
|      ...
|      xn = case z of { p -> xn }
|
|    where z is fresh, and x1..xn are the variables of the pattern p.
|
| For bang patterns, I think it suffices to say that a bang at the top
| level of p is carried to the binding for z, and then separately define
| what banged variable bindings mean (i.e. add appropriate seqs).

Fair enough.  Although there will still be quite a bit of System F plumbing generated, I do agree that answers
my questions about the static semantics of pattern bindings (*provided* we lift the MR).  And I agree that
it gives a simple, consistent, and explicable story to the programmer.

The result may or may not do what you want though:
        (f, g) = ( (+), (+) )
will generate

        f :: (Num a, Num b) => a -> a -> a

which is ambiguous.  In general, pattern bindings for overloaded things are probably useless.  Perhaps
worth pointing this out in the report.

RE: instance export decls

Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists

module Foo(
        data T (f :: * -> *),
        instance Functor f => Eq (T f),
        g :: T f -> T f
  )

The first step is to evolve a well-worked-out design. I think that'd be a very valuable thing for someone to
do.  Indeed, I'd really like to see it in Haskell', but it doesn't meet the "tried and tested" criterion.

I'm a bit reluctant to invest effort in half-way-house solutions, though.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org
[mailto:glasgow-haskell-users-bounces <at> haskell.org] On
| Behalf Of Serge D. Mechveliani
| Sent: 22 April 2008 13:33
| To: glasgow-haskell-users <at> haskell.org
| Subject: instance export decls
|
| Dear GHC developers, people,
|
| Do you agree that there exists such a problem for a programmer as
| recalling exported instances?
| Have Haskell and/or GHC some constructs and tools to help the programmer
| to recall the exported instances for a module?
| Could GHC support the instance export messages for each module?

RE: Haskell' - class aliases

| Yeah, I disagree here, mainly because I don't want to conflate
| superclasses with class aliases. I feel they have different uses, even
| though they can sometimes achieve the same thing.

Fair enough.  But the strange syntax

class alias Num a = Eq a => (Additive a, Multiplicative a)

*does* seem so say that the (Eq a) behaves in a superclass way, and (Additive a, Multiplicative a) behave in a
class-alias way, as it were.  That seems inconsistent with the design goal you describe above.

Perhaps I can put it like this: if you want the "(Eq a) =>" part of the above decl, then you should also allow
method definitions in the same decl.


Once this point settles down, would you like to refine your specification in the light of my
misunderstandings?  The more precise it is, the easier it is to implement.

Concerning Twan's idea, my brain is too small to accommodate the similarities and differences (today at
any rate).  But from an implementer's point of view, it'd be nice to have one proposal on the table rather
than two competing ones....

Simon

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell' - class aliases

On Thu, May 01, 2008 at 03:42:53PM +0100, Simon Peyton-Jones wrote:
> | Yeah, I disagree here, mainly because I don't want to conflate
> | superclasses with class aliases. I feel they have different uses, even
> | though they can sometimes achieve the same thing.
> 
> Fair enough.  But the strange syntax
> 
> class alias Num a = Eq a => (Additive a, Multiplicative a)
> 
> *does* seem so say that the (Eq a) behaves in a superclass way, and
> (Additive a, Multiplicative a) behave in a class-alias way, as it
> were.  That seems inconsistent with the design goal you describe
> above.

Wolfgang suggested the alternate syntax

class alias Eq a => Num a = (Additive a, Multiplicative a) where ....

The correct reading being:

if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a)

I think I am coming around to his point of view, do you think this makes
it clearer?

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈

RE: Haskell' - class aliases

| > Fair enough.  But the strange syntax
| >
| > class alias Num a = Eq a => (Additive a, Multiplicative a)
| >
| > *does* seem so say that the (Eq a) behaves in a superclass way, and
| > (Additive a, Multiplicative a) behave in a class-alias way, as it
| > were.  That seems inconsistent with the design goal you describe
| > above.
|
| Wolfgang suggested the alternate syntax
|
| class alias Eq a => Num a = (Additive a, Multiplicative a) where ....
|
| The correct reading being:
|
| if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a)
|
| I think I am coming around to his point of view, do you think this makes
| it clearer?

I am not arguing about syntax!

You say "class aliases are orthogonal to superclasses", but then you allow this "Eq a" thing in the above
alias, which is very like a superclass.  I think that if you allow the "Eq a =>" part, you should also allow new
methods to be declared in the alias (as I originally thought you did).  And if not, then you shouldn't allow
superclasses.  It's precisely that you allow superclasses (Eq a =>) that makes your feature
non-orthogonal to ordinary superclasses.  Maybe you can't make them orthogonal, but it quite hard to
explain this definition to me.

Incidentally, you say that your proposal is just syntactic sugar: if so, can you give the desugaring translation?

Re: Haskell' - class aliases

On Thu, May 01, 2008 at 11:57:14PM +0100, Simon Peyton-Jones wrote:
> | > Fair enough.  But the strange syntax
> | >
> | > class alias Num a = Eq a => (Additive a, Multiplicative a)
> | >
> | > *does* seem so say that the (Eq a) behaves in a superclass way, and
> | > (Additive a, Multiplicative a) behave in a class-alias way, as it
> | > were.  That seems inconsistent with the design goal you describe
> | > above.
> |
> | Wolfgang suggested the alternate syntax
> |
> | class alias Eq a => Num a = (Additive a, Multiplicative a) where ....
> |
> | The correct reading being:
> |
> | if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a)
> |
> | I think I am coming around to his point of view, do you think this makes
> | it clearer?
>
> I am not arguing about syntax!

oh, I just meant that this syntax is actually a different way of
thinking about it for me and it helped me clarify some stuff in my mind
so thought it might be clearer for others as well.

>
> You say "class aliases are orthogonal to superclasses", but then you
> allow this "Eq a" thing in the above alias, which is very like a

Re: Haskell' - class aliases

> Hmm.. okay, here is a rough draft that covers all the important cases I
> think.
>
> assume the following declarations:
>
>> class C1 a where
>>         f1 :: t1
>>         f1 = d1
>
>> class C2 a where
>>         f2 :: t2
>>         f2 = d2
>>         f3 :: t3
>>         f3 = d3
>
>
>
>> class alias S a => A a = (C1 a, C2 a) where
>>         f1 = nd1
>
>
>
> okay, the desugaring is as follows:
>
> there are two different desugaring rules, one for instances, one for the
> alias appearing anywhere other than an instance declaration:
>
>> g :: A a => a -> b
>> g = ...
>

RE: Haskell' - class aliases

John

This is good stuff, but I fear that in 3 months time it'll be buried in our email archives. In contrast, your
original web page is alive and well, and we were able to start our discussion based on it

So can I suggest that you transfer your web page to the Haskell' wiki (simply a convenient, editable place to
develop it), or to the haskell.org wiki (likewise).  And that, as the design gets fleshed out, you try to
reflect the current state of play there? I don't want this work to be lost!


Ok, on to your email:

=============== Desugaring the class alias decl =================
| there are two different desugaring rules, one for instances, one for the
| alias appearing anywhere other than an instance declaration:
|
| > g :: A a => a -> b
| > g = ...
|
| translates to
|
| > g :: (S a, C1 a, C2 a) => a -> b
| > g = ...
|
| the triplet of (S a, C1 a, C2 a) is completely equivalent to (A a) in
| all ways and all places (other than instance heads)

Notice that this part *is* exactly true of a superclass with no methods

        class (S a, C1 a, C2 a) => A a where {}

Re: Haskell' - class aliases

On Fri, May 02, 2008 at 08:30:59AM +0200, Tom Schrijvers wrote:
>> Note that when declaring an instance of a concrete type, like Int, the
>> constraint (S Int) will be trivially satisfied or not at compile time.
>> (bf2 is free to use methods of 'S' of course).
>>
>> this translation is also a bijection, declaring those two instances
>> manually as above is indistinguishable from declaring instances via the
>> alias in all ways.
>>
>> Hopefully the generalization to arbitrary numbers of classes is clear...
>
> What about multiple parameters? Can A have more parameters than the Ci? 
> Should they be in the same order? Should they overlap?
>
> What about instance contexts, like:
>
> 	instance I a => A a where ...

Ah, I originally had instance contexts in my example, but left them out
for clarity of the main points. instance contexts are just copied
verbatim into each expanded instance.

> (What about functional dependencies?)

I am leaving out MPTCs and hence fundeps for now, I do not believe they
will present an issue, as nothing about the expansion depends on the
number of arguments, but I want to make sure we have a clear
understanding of what class aliases imply for haskell 98 one constructor
type classes first. 

Re: Haskell' - class aliases

This isn't really a response to your email, but I have been mulling the
last few hours away from a computer and wanted to get this stream of
conciousness out when it is fresh in my mind.

The more I think about it, I think 'superclass' is just the wrong
terminology for dealing with class aliases. Superclass implies a strict
partial order on classes, which just isn't the case for class aliases,
for instance

> class alias Foo a => Foo a = Bar a where ...

Has a defined (if not very useful) meaning with class aliases, but is
really odd if you consider 'Foo a' a "superclass". So, I think the
following terminology should be used:

   Context of --+
   alias        |     The alias -+    +--- The expansion of the alias
                |                |    |
                v                v    v
> class alias (S1 a .. Sn a) => A a = (C1 a ... Cn a) where
>      fd1 = ....
>      ....
>      fdn = ....
            ^
            +----  The defaults of the alias

given this, the expansion of 'A a' in any context other than an instance
head is

> A a --> reduce(S1 a .. Sn a, C1 a ... Cn a)