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.
Let's also make sure that the spec explicitly includes type signatures. That
is, the above transformation is carried out, and then the individual bindings
for the xi are compared with their individual type signatures.
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Serge D. Mechveliani
| Sent: 22 April 2008 13:33
| To: [EMAIL PROTECTED]
| 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?
|
| In Haskell-98, the exported instances cannot be named explicitly in the
| export list.
| Right?
| But for easier understanding of a program, it is desirable to allow to
| name (in a short form) instances in the export list.
| For this reason, I add comments, and write the export like this:
|
| module Poly
| (WithHead(..), WithTail(..), -- classes
|Mon(..), Polynomial(..),
|lc, polMons
|-- , instances
|-- for Mon: WithHead, List;
|-- for Polynomial: WithHead, Cast Polynomial Mon
| )
| The comment of kind -- , instances ...
| helps to recall which instances are exported, without inspecting all
| the (lengthy) module source.
|
| But when the programmer changes the source, one often forgets to
| add/remove the needed comments about instances.
| I often forget them (maybe, lazy to recall) when I move pieces of code
| between modules.
|
| So, I suggest the following feature for GHC.
|
| 1. To allow the export declarations of kind instance {type}
|(maybe to suggest this for Haskell ?)
| 2. If the module under compilation has the word `instance' in its
|export list,
|then ghc finds the difference set diff for the exported instance
|kinds eKinds and the instance kinds nKinds named in the export
|list. If not $ null diff, it issues the message:
|Warning: the exported instance kinds and the instance kinds named
| in the export differ in the following items:
|
| Seeing such a message, the user corrects the export list in the source
| according to diff.
|
| For the export list and for their messages, it is probably better to
| use a short denotation: the instance kind rather than full instance
| declaration. In the instance kind, the part of (...) = is skipped.
|
| What people think of this suggestion?
|
| Thank you in advance for your notes and help,
|
| -
| Serge Mechveliani
| [EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
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⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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? Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
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 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. Oh, the reason to allow superclasses of class aliases is so methods of the superclass can be used in the default instance methods for your alias. In addition, it allows full emulation of any explicit class you can currently declare. You do not want 'instance 'Num a'' to declare an instance for Eq as that is very different behavior from the old Num class. Yet the default instances for 'Num' may require use of methods from its superclass. it actually would make more sense to call them the context of the class alias rather than the superclass, since they don't declare a super/sub class relationship between the two. Incidentally, you say that your proposal is just syntactic sugar: if so, can you give the desugaring translation? 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 = ... 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), one is just a different way to express the other, just like type synonyms. An alias just expands to the union of the classes it is an alias for as well as its class constraints (superclasses). now for instance declarations instance A a where f2 = bf2 expands to instance (S a) = C1 a where f1 = nd1 instance (S a) = C2 a where f2 = bf2 f3 = d3 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... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
