October 2004 - Glasgow-haskell-users

RE: Template Haskell...
by MR K P SCHUPKE 21 Oct '04

21 Oct '04

Thanks for the URL... I have realised I jumped the gun saying the derivation can be done in template-haskell... there is one small problem: $(derive [t| SomeConstructor a b |]) passes the constructor to derive... is there any way to get the type information for some type? You can do $(derive [d| data X a b = X1 a b |]) Is there any way to get the same information from something like: $(derive2 [T| X a b |]) Keean.

2 1

RE: deriving...
by Simon Peyton-Jones 20 Oct '04

20 Oct '04

Thanks to those who responded to this thread about 'deriving'. My current thoughts are: * I'd be happy to add the ability to separate a 'deriving' clause from its data type declaration, if we can agree syntax (see below). It's fairly easy to do; it makes the language more orthogonal; it's useful. But in fact I think only Martin Sjögren has explicitly said that the feature would be useful.... and every feature has a cost. * I'm not at all keen on making '..deriving( Foo )' mean $(derive 'Foo) or something like that. Just make the TH call yourself! * No one is arguing hard for instance declarations in hi-boot files, so let's leave that for now. Re syntax, the obvious possibility (A) is to add derive( pred1, .., predn ) as a new top-level declaration. E.g. derive( Typeable (T a) ) But that means adding 'derive' as a keyword. Other possibilities: deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration. Any other ideas? Simon

6 5

RE: ghc from CVS HEAD doesn't work with "-O -threaded"
by Simon Marlow 20 Oct '04

20 Oct '04

On 19 October 2004 17:08, Peter Simons wrote: > The following reproducibly fails: > > $ darcs get http://cryp.to/hsdns [*] > $ cd hsdns/ > $ hsc2hs ADNS.hsc > $ ghc -threaded -Wall -O --make test.hs -o test -ladns > | Chasing modules from: test.hs > | Compiling ADNS ( ./ADNS.hs, ./ADNS.o ) > | /tmp/ghc2613.hc:9:23: ADNS_stub.h: No such file or directory > | /tmp/ghc2613.hc: In function `s8Xa_ret': > | /tmp/ghc2613.hc:6340: error: `ADNS_d7eN' undeclared (...) > > If you build the program without optimization, > > $ ghc -threaded --make test -ladns > > it works just fine. This seems to happen only when the > threaded RTS in involved, -O without -threaded works. Should be fixed now. Sorry for the delay in getting around to this. Cheers, Simon

2 1

RE: Template Haskell...
by Simon Peyton-Jones 20 Oct '04

20 Oct '04

newName http://research.microsoft.com/~simonpj/tmp/notes2.ps (sorry for the poor url) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of MR K P SCHUPKE | Sent: 20 October 2004 15:44 | To: glasgow-haskell-users(a)haskell.org | Subject: Template Haskell... | | | What replaces 'gensym' in GHC 6.3? | | Keean. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Template Haskell...
by MR K P SCHUPKE 20 Oct '04

20 Oct '04

What replaces 'gensym' in GHC 6.3? Keean.

1 0

Re: deriving...
by MR K P SCHUPKE 20 Oct '04

20 Oct '04

As posted on this list, there is template-haskell code to do: >$(derive [| data Foo = Foo |]) You can also get the type of Foo in TH by doing: dummy :: Foo dummy = undefined $(derive2 "dummy") and the code for derive2 reify's the argument, which then gives the reflected type... so the example code given for the first form can be adapted to the second use. As you can already do this in TH, why introduce another extension? Keean.

1 0

Top level mutable data structures problem
by Adrian Hey 20 Oct '04

20 Oct '04

Hello, [Excuse me for moving this discussion to the ghc mailing list, but it seems the appropriate place, seeing as ghc is where any solution will happen first in all probability.] I've noticed that the neither of the two Simons has expressed an opinion re. the discussions on this issue that occurred on the Haskell mailing list over the weekend. So I'd like to ask what's happening (or likely to happen) about this, if anything? Regards -- Adrian Hey

1 0

RE: deriving...
by Simon Peyton-Jones 20 Oct '04

20 Oct '04

| Why not even simply | | instance Typeable (T a) | | In other words, derivable classes define default | implementations for all their methods. But that has an existing meaning! It means "use the default methods for all methods of the class". Which is not the same as "derive all methods". It'd have to be instance Typeable (T a) deriving or derive instance Typeable (T a) Something to clearly signal the magic. The trouble is, as you mention, that instance decls usually have a context. I'd be quite happy to require a context in these derived instances too, so you have to write derive instance Typeable a => Typeable (T a) Then it looks more like a regular instance decl. Claus asks: | still, will non-variable parameters be permitted, and do we know | what that means? I was thinking of using exactly the same rules as now; type variables only. Simon

2 1

Re: deriving...
by MR K P SCHUPKE 20 Oct '04

20 Oct '04

>instance Typeable (T a) Forgive my stupid question, but why? What will deriving instances do? Questions that spring to mind are: 1) How will the deriviation of instances be defined... If instances are the same for all types then this is just the current default method. If not then this will need reflection to decompose the type and construct the method? 2) How will validity be checked... Lets say I have a class called Set, and I make a type an instance of this class, how will it show that the properties of a 'set' are valid on the particular instance? (for example I try and make an 'Int' an instance of 'Set'. Keean.

2 1

RE: deriving...
by MR K P SCHUPKE 20 Oct '04

20 Oct '04

> * I'm not at all keen on making '..deriving( Foo )' mean > $(derive 'Foo) or something like that. Just make the TH > call yourself! The current situation is that the code that generates the derived instances is hard coded into the compiler (TcDeriv.hs) is it not better to allow the derived instances to be specified in Haskell - using template-haskell seems to be the easiest (least new features/least effort/max results) method of doing this. What I am suggesting is that the current derivations for Typeable (etc) are replaced by more readable template-haskell code, that can be user extended... Surely it is better to have the deriving method exposed rather than hidden away in the compiler. Keean.

2 1