Re: Closed Type Families: separate instance groups?

2015-06-04 Thread AntC
 Simon Peyton Jones simonpj at microsoft.com writes:
 
 I think it's pretty good as-is.
 
Thank you Simon, I'm agreeing with pretty good,
though possibly not with pretty ;-)

 ...
 * Use a closed family (with overlap and top-to-bottom matching)
to deal with that part of the space:
 
 Doing this was a HUGE improvement, ...

(I'm not quite getting improvement over what?
 This was and is the only way to do overlaps with Type Families?)

I'm not ever-so sure I'm seeing an improvement
over overlapping class instances with FunDeps.
I really really want type families to be an improvement
because type manipulation in a functional language
should be -- errm -- functional.

 |  It also BTW cuts us off from using Closed Families as Associated types
 |  separated into their Class instances.
 
 I don't understand this comment. ...

I'll answer Richard's strapline at
https://typesandkinds.wordpress.com/
Who needs terms, anyway?:
I need both types and terms.

Yes the compiler needs first a type-solving phase
before dealing with the terms.
Type Families cleanly separate that off.

And in a significant proportion of use cases,
the type-handling is the same across many class instances.
So it's more succinct to collapse the type instances
into a grouped type family ... where ...

There's other use cases for overlapping
where you can't collapse the type-handling.
So then I'm finding that my class instances
have heads that repeat the type instance heads.
And I would use Assoc types
but the type family instances
have to appear in the family, to sequence the top-to-bottom matching.

 Can you give an example that the current setup does not handle?
 
(This is about dealing with many instances,
 so difficult to give a succinct example.
 And the current setup does handle it OK.
 It's just that it seems verbose, with hard to read code,
 compared to FunDeps. I appreciate that's in the eye of the beholder.)

Take the standard example for partial overlaps.
Suppose I have a class:

class C a where f :: a - F a

instance C (Foo Int c) where
   -- I'd like to put
  type F (Foo Int b) = Int   -- but it overlaps
  f (Foo x _) = x

instance C (Foo b Char) where
  type F (Foo b Char) = Char -- non-confluent
  f (Foo _ y) = y

Imagine there's dozens of overlapping instances.
(And BTW there's no actual ambiguous usages.
 By construction (Foo Int b) means b /~ Char.
 But I have no way to declare that.)

I'm also getting (in more complex examples)
GHC complaining it can't infer the types
for the result of f.
So now I'm having to put type equality
constraints on the class instances,
to assure it that F comes up with 
the right type.
This just seems easier if I have the result type
as an extra param to the class,
with a FunDep in the classic style:

class C a b | a - b where
  f :: a - b

(I can supply those more complex examples if need be,
 but this post is already too long.)

AntC



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


RE: Closed Type Families: separate instance groups?

2015-06-04 Thread Simon Peyton Jones
I think it's pretty good as-is.

* Use an open family (with non-overlapping instances) to get yourself
  into part of the match space:
 type instance OpenF (Foo b c) = FFoo (Foo b c)

* Use a closed family (with overlap and top-to-bottom matching) to
  deal with that part of the space:
  type family FFoo a where
 FFoo (Foo Int c) = ...

Doing this was a HUGE improvement, allowing us to cleanly split the
issues of top-to-bottom matching from those of non-overlapping open
families. 

|  It also BTW cuts us off from using Closed Families as Associated types
|  separated into their Class instances.

I don't understand this comment. Can you give an example that the current setup 
does not handle?

Simon


|  -Original Message-
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  boun...@haskell.org] On Behalf Of AntC
|  Sent: 04 June 2015 01:54
|  To: glasgow-haskell-users@haskell.org
|  Subject: Re: Closed Type Families: separate instance groups?
|  
|   Richard Eisenberg eir at cis.upenn.edu writes:
|  
|   You can always define a helper closed type family and have an open
|   type family instance just call a closed type family.
|  
|  Thank you Richard, you mean like:
|  
|  type family OpenF a
|  
|  ...
|  
|  type instance OpenF (Foo b c) = FFoo (Foo b c)
|  type family FFoo a where
|FFoo (Foo Int c) = ...
|...
|  
|  OK. (Seems rather verbose.)
|  
|  
|   Having closed type families, as opposed to branched instances, just
|   seemed like a cleaner way to package the new functionality.
|   There really wasn't much to it other than aesthetics, if I recall
|  the
|   conversations correctly.
|  
|  I recall the conversation quite well.
|  (In fact I think it was me who suggested type family ... where ... ) I
|  think it was less to do with aesthetics, and more to do with reducing
|  verbosity in a common use case.
|  
|  It somehow doesn't seem as clean as old-fashioned overlapping
|  instances.
|  (I agree it does seem cleaner than overlaps with FunDeps.)
|  
|  It also BTW cuts us off from using Closed Families as Associated types
|  separated into their Class instances.
|  I think there's two use cases going on:
|  - one where we want to see all the instances together
| that fits well to type family ... where ...
|  - t'other where we want everything to do with a type constructor
|  together
| that fits better with the separate instances
|  
|  AntC
|  
|  
|  
|  ___
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users@haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


Re: Closed Type Families: separate instance groups?

2015-06-03 Thread Richard Eisenberg

On Jun 3, 2015, at 7:09 PM, AntC anthony_clay...@clear.net.nz wrote:

 Is this separate instance group idea still a gleam in someone's eye? 
 If not, is there some deep theoretical reason against?

Not to my knowledge (to both questions). But I don't believe we've lost any 
expressiveness over the earlier version. You can always define a helper closed 
type family and have an open type family instance just call a closed type 
family. Of course, it would be nice to have *local* type families (as if, say, 
there were a `where` clause allowed), but this should work for you. Or does 
this not work in your use case?

Having closed type families, as opposed to branched instances, just seemed like 
a cleaner way to package the new functionality. There really wasn't much to it 
other than aesthetics, if I recall the conversations correctly.

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


Re: Closed Type Families: separate instance groups?

2015-06-03 Thread AntC
 Richard Eisenberg eir at cis.upenn.edu writes:

 You can always define a helper closed type family
 and have an open type family instance just call a closed type family. 

Thank you Richard, you mean like:

type family OpenF a

...

type instance OpenF (Foo b c) = FFoo (Foo b c)
type family FFoo a where
  FFoo (Foo Int c) = ...
  ...

OK. (Seems rather verbose.)

 
 Having closed type families, as opposed to branched instances,
 just seemed like a cleaner way to package the new functionality.
 There really wasn't much to it other than aesthetics,
 if I recall the conversations correctly.

I recall the conversation quite well.
(In fact I think it was me who suggested type family ... where ... )
I think it was less to do with aesthetics,
and more to do with reducing verbosity in a common use case.

It somehow doesn't seem as clean as old-fashioned overlapping instances.
(I agree it does seem cleaner than overlaps with FunDeps.)

It also BTW cuts us off from using Closed Families as Associated types
separated into their Class instances.
I think there's two use cases going on:
- one where we want to see all the instances together
   that fits well to type family ... where ...
- t'other where we want everything to do with a type constructor together
   that fits better with the separate instances

AntC



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


Closed Type Families: separate instance groups?

2015-06-03 Thread AntC
Currently (GHC 7.8.3) the only form for Closed Type Families is:

type family F a where ...
  -- list your instances here

(This was considered a common use case
 -- for example in HList to put the type-matching instance
 with the non-matching, and that would be total coverage;
 rather than needing a type family decl and an instance decl
 with the instance head same as family.
 That was an optimisation over ...)

Way back the design was more like this:

type family F a

type instance F (Foo b c)  where
  F (Foo Int c) = ...
  F (Foo b Char) = ...

type instance F (Bar e f g) where
  F (Bar Int f g) = ...

The idea was that the separate instance groups must have non-overlapping heads.

This is handy if Foo, Bar, etc are declared in separate places/modules.
You can put the instances with the data decl. 
And quite possibly the family decl is in an imported/library module 
you don't want to touch.

Is this separate instance group idea still a gleam in someone's eye? 
If not, is there some deep theoretical reason against?

AntC

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