Opened 10 years ago

Closed 4 years ago

Last modified 4 years ago

#3699 closed feature request (fixed)

Wildcards in type functions

Reported by: MartijnVanSteenbergen Owned by: msosn
Priority: low Milestone: 8.0.1
Component: Compiler (Type checker) Version: 6.10.4
Keywords: newcomer Cc: eir@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1092
Wiki Page:

Description

I would like to be able to use wildcards in type synonym family instances, so that I can write:

type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a

Change History (27)

comment:1 Changed 10 years ago by simonpj

Milestone: 6.14 branch

Very reasonable idea. I've added it to our list of type-function feature requests at http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus

Simon

comment:2 Changed 10 years ago by MartijnVanSteenbergen

Continuing this line of thought, instances for this family go hand in hand with instances for this type class:

class MkErrorAlgebra f where
  mkErrorAlgebra :: ErrorAlg f e a -> ErrorAlgPF f e a

Would it then also make sense to write:

instance MkErrorAlgebra f => MkErrorAlgebra (f :>: _) where
  mkErrorAlgebra alg         (Tag f)           = mkErrorAlgebra alg f

?

Just a wild idea which I'm not sure yet I like or dislike. It does fit in with the idea of not making up names if you don't have to. For that reason I also prefer writing data D :: <kind> where for GADTs rather than making up arbitrary names for the type arguments. Going even further, this idea can be extended to e.g. data Const a _ = Const a for normal ADTs.

Okay, enough wild ideas for now. :-)

comment:3 Changed 9 years ago by igloo

Milestone: 6.14 branch6.14.1

comment:4 Changed 9 years ago by igloo

Milestone: 7.0.17.0.2

comment:5 Changed 9 years ago by igloo

Milestone: 7.0.27.2.1

comment:6 Changed 8 years ago by igloo

Milestone: 7.2.17.4.1

comment:7 Changed 8 years ago by igloo

Milestone: 7.4.17.6.1
Priority: normallow

comment:8 Changed 7 years ago by goldfire

Cc: eir@… added

comment:9 Changed 7 years ago by igloo

Milestone: 7.6.17.6.2

comment:10 Changed 5 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:11 Changed 5 years ago by thomie

Component: CompilerCompiler (Type checker)
difficulty: Unknown

comment:12 Changed 5 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:13 Changed 5 years ago by jstolarek

Keywords: newcomer added

comment:14 Changed 4 years ago by dalaing

How would we resolve things like

  type instance Testing (f :>: _) = MyType f
  type instance Testing (_ :>: g) = MyType g

and other such collisions?

I'm pretty new to GHC - is there an existing resolution order from elsewhere that could be borrowed for this?

comment:15 Changed 4 years ago by jstolarek

I always imagined that _ will be instantiated internally to a fresh type variable. This means that this feature would mostly affect the parser and renamer and by the time you reach the point when your example collision is checked (FamInst.checkForConflicts, called from FamInst.checkFamInstConsistency) the example code will look like:

  type instance Testing (f :>: a_1234) = MyType f
  type instance Testing (a_5678 :>: g) = MyType g

where a_1234 and a_5678 are fresh type variables.

comment:16 Changed 4 years ago by dalaing

I thought about this a little last night and realised that the resolution should be the same as for unused type variables. Your comment confirms that and gives a few hints on where to get started - so thanks heaps!

comment:17 Changed 4 years ago by dalaing

Owner: set to dalaing

comment:18 Changed 4 years ago by jstolarek

dalaing, what is the status of your work? I ask because I have a student who would be interested in implementing this ticket but if you are actively working on this ticket we will look for something else.

comment:19 Changed 4 years ago by dalaing

Owner: dalaing deleted

comment:20 Changed 4 years ago by dalaing

jstolarek - sorry I missed you comment - I've been stalled on this for a while as various other things have moved to the front of the queue, so I've unassigned myself for now.

comment:21 Changed 4 years ago by msosn

Owner: set to msosn

comment:22 Changed 4 years ago by thomasw

Differential Rev(s): Phab:D1092

comment:23 Changed 4 years ago by thomasw

Fixing #10586 led me to add support for wild cards in type/data family instance declarations, see Phab:D1092.

@msosn: Sorry for stealing this. As I implemented partial type signatures in the first place, this was less than an hour's worth of work for me.

comment:24 Changed 4 years ago by Ben Gamari <ben@…>

In d9d2102e/ghc:

Support wild cards in data/type family instances

Handle anonymous wild cards in type or data family instance
declarations like
unnamed type variables. For instance (pun intented):

    type family F (a :: *) (b :: *) :: *
    type instance F Int _ = Int

Is now the same as:

    type family F (a :: *) (b :: *) :: *
    type instance F Int x = Int

Note that unlike wild cards in partial type signatures, no errors (or
warnings
with -XPartialTypeSignatures) are generated for these wild cards, as
there is
nothing interesting to report to the user, i.e. the inferred kind.

Only anonymous wild cards are supported here, named and
extra-constraints wild
card are not.

Test Plan: pass new tests

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: goldfire, thomie

Differential Revision: https://phabricator.haskell.org/D1092

GHC Trac Issues: #3699, #10586

comment:25 Changed 4 years ago by bgamari

Resolution: fixed
Status: newclosed

comment:26 Changed 4 years ago by MartijnVanSteenbergen

You are amazing! Thanks for building this. :-)

comment:27 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

Note: See TracTickets for help on using tickets.