The main detail I'm not sure about (because I haven't looked at that part of GHC) is how to discharge these constraints: presumably GHC has some sort of environment that keeps track of the definitions of implicit parameters that are in scope, so in the solver we can just lookup what "instances" are in scope, and generate the required evidence?
Great! Look in TcSMonad for 'data InertCans". I think we'll be able to eliminate the inert_ips field, because the same info will now be in inert_dicts. Similarly in the type 'Type.PredTree' I think we'll eliminate the IPPred constructor. Simon From: Iavor Diatchki [mailto:[email protected]] Sent: 14 May 2012 17:41 To: Simon Peyton-Jones Cc: [email protected]; Stephanie Weirich; Dimitrios Vytiniotis; Richard Eisenberg ([email protected]); José Pedro Magalhães Subject: Re: Implicit parameters Hello, this seems reasonable and I'd be happy to have a go at implementing it. The main detail I'm not sure about (because I haven't looked at that part of GHC) is how to discharge these constraints: presumably GHC has some sort of environment that keeps track of the definitions of implicit parameters that are in scope, so in the solver we can just lookup what "instances" are in scope, and generate the required evidence? -Iavor On 05/14/2012 04:12 AM, Simon Peyton-Jones wrote: I propose the following clean-up to the handling of implicit parameters. Currently they are special in all sorts of ways, notably by having their own name-cache. See IfaceEnv.allocateIPName, and TysWiredIn.mkIPName. This is pretty messy. But consider: this gets very close class IP (name :: Symbol) ty | name -> ty where value :: ty Instead of the constraint (?x::Int) we'd have (IP "x" Int). I'm not actually suggesting changing the surface syntax, only the internal representation. This would, at a stroke, get rid of much of the special handling of implicit parameters. There are still some special rules about generalisation that we might want to preserve, but by and large everything would be handled with much less code for implicit parameters. Any comments? Iavor, you're an expert on implicit parameters, and you implemented the Symbol stuff that the idea depends on. Might you even like to implement the above plan? Simon
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
