Template haskell instance checking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Template haskell instance checking

heatsink
Is there a way, in template haskell, to find out what instance declarations
exist?  I'm not trying to accomplish anything specific right now, but I can
see two potential uses for this.  One is to emit compile-time error messages
from TH code which would be more informative than the typechecker's output.  
The other is to produce TH functions that conditionally generate code
depending on the instances satisfied by their arguments.

I offer the following as a motivational example.  Suppose you want to write
an extensible library to handle files for, e.g., image data:

class FileFormat a where
formatName :: a -> String
read :: Handle -> IO a
write :: Handle -> a -> IO ()

instance FileFormat TheStandardFormat where ....

class (FileFormat a, FileFormat b) => Convert a b where
convert :: a -> b

Now it would be nice to generate instances of (Convert a TheStandardFormat,
Convert TheStandardFormat b) => Convert a b _except_ where there is an
explicit definition for (Convert a b).  AFAIK, there's no way to do this at
present, but it seems like something that could be computed in TH.

--heatsink


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Template haskell instance checking

Simon Peyton Jones
Not at the moment, I'm afraid, but it's the kind of question that TH
ought to be able to answer.  I could offer guidance if someone wanted to
implement it.

Simon

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of
| heatsink
| Sent: 02 March 2006 00:55
| To: [hidden email]
| Subject: [Haskell-cafe] Template haskell instance checking
|
| Is there a way, in template haskell, to find out what instance
declarations
| exist?  I'm not trying to accomplish anything specific right now, but
I can
| see two potential uses for this.  One is to emit compile-time error
messages
| from TH code which would be more informative than the typechecker's
output.
| The other is to produce TH functions that conditionally generate code
| depending on the instances satisfied by their arguments.
|
| I offer the following as a motivational example.  Suppose you want to
write
| an extensible library to handle files for, e.g., image data:
|
| class FileFormat a where
| formatName :: a -> String
| read :: Handle -> IO a
| write :: Handle -> a -> IO ()
|
| instance FileFormat TheStandardFormat where ....
|
| class (FileFormat a, FileFormat b) => Convert a b where
| convert :: a -> b
|
| Now it would be nice to generate instances of (Convert a
TheStandardFormat,
| Convert TheStandardFormat b) => Convert a b _except_ where there is an
| explicit definition for (Convert a b).  AFAIK, there's no way to do
this at
| present, but it seems like something that could be computed in TH.
|
| --heatsink
|
|
| _______________________________________________
| Haskell-Cafe mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

conditional code, was: Template haskell instance checking

Christian Maeder
In reply to this post by heatsink
heatsink wrote:
> Is there a way, in template haskell, to find out what instance
> declarations exist?  I'm not trying to accomplish anything specific
> right now, but I can see two potential uses for this.  One is to emit
> compile-time error messages from TH code which would be more informative
> than the typechecker's output.  The other is to produce TH functions
> that conditionally generate code depending on the instances satisfied by
> their arguments.

Apologies for becoming off-topic now, I've got nothing against template
haskell (TH), on the contrary, it is a great device to increase genericity.

But I want to warn about conditional code, because this may become a
nightmare to maintain. I.e. we (at Bremen) have (few) bits in TH that
check if we run under windows or unix (but no one knows if the windows
part is still working). Furthermore we support a few older (still
recent) ghc versions with conditional code (like ghc itself can be
bootstrapped with different older version).

Plugging in various libraries using Cabal is a nice feature, but imagine
if you would start to program depending on the currently installed
packages (and visible instances)! (Fortunately, this would be hard to do
currently.)

So (despite cabal and the desire for a minimal kernel) I hope that ghc
will continue to supply a large number of more or less "standard"
packages or modules that can safely be expected to exist in (almost)
every installation. (Therefore I've suggested to keep Data.Set and
Data.Map in the base package, but another "standard" package may be
fine, too). Otherwise truly application specific 3rd party cabal
packages may all come with their own "Prelude extensions" rather than
reusing increasingly solidified Haskell basics (that are hopefully not
disputed too much by the design of Haskell-Prime).

If you agree with me, great, ignore this posting.

Respectfully Christian
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Template haskell instance checking

heatsink
In reply to this post by heatsink
>>Is there a way, in template haskell, to find out what instance
>>declarations
>>exist?
>Not at the moment, I'm afraid, but it's the kind of question that TH
>ought to be able to answer.  I could offer guidance if someone wanted to
>implement it.

I have a concern about how computed class memberships would work.  Class
membership is global, so creating a class instance is a globally visible
side effect of TH code.  Once you add the ability for TH code to inspect
instances, the side effects mean that the order in which different splices
get executed affects the compiler output.  This is probably a bad thing.  
I'm not sure how it could be designed to work nicely; the only approach I
can think of at the moment is to give splice evaluation a dataflow execution
semantics that causes splices to execute and possibly reexecute at the
"appropriate" times.  I'd like to hear if anyone else has ideas on how to
solve this problem.

.....tian: I think that's a good point in general about conditional code
generation.  I wasn't thinking about conditional generation based on
compile-time settings, but rather reusable TH library functions that inspect
the class memberships of their arguments.  Of course, this can be used for
good or evil :)

--heatsink


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe