How does this help? The problem is that a compiler plugin (which is effectively a GHC API client) might see two different versions of binary and would have to choose the one bundled with GHC.
2008/10/14 Don Stewart <[EMAIL PROTECTED]>: > omega.theta: >> 2008/10/14 Ian Lynagh <[EMAIL PROTECTED]>: >> > On Mon, Oct 13, 2008 at 06:06:03PM +0100, Max Bolingbroke wrote: >> >> >> >> (http://hackage.haskell.org/trac/ghc/wiki/Annotations). >> > >> > When you say >> > {-# ANN f id 1 #-} >> > this means you are attaching (id 1) to f, right? >> > >> > I think that that syntax is very confusing. I'm not sure what I'd prefer >> > though. Maybe parentheses, analogous to those in >> > instance C (Maybe a) >> >> That's a fair point: I also don't feel entirely happy with this aspect >> of the syntax. On a syntax-related note, Tristan proposed that we use >> this syntax instead for a slightly terser annotation: >> >> {-@ f id 1 @-} >> >> (The @ is meant to be evocative of the Java syntax for annotations). >> This might be a nice addition if we envisage annotations becoming very >> common. Furthermore, at the moment I don't think we can write: >> >> --# INLINE foo >> >> Is there any reason why not? It would be quite handy to be able to say: >> >> --@ foo MyAnnotationConstructor >> >> >> binary-package dependency issue I outline briefly above? >> > >> > I think GHC depending on packages like binary, utf8-string etc, rather >> > than reinventing or copying wheels, would be a good thing. >> >> Agreed. It's annoying that GHC cannot simply reuse ostensibly-reusable >> packages like "binary" for it's own purposes because of this >> versioning issue. I'm not sure we have a good way of dealing with this >> (hard) problem at the moment, however. > > GHC needs to just keep copies in-tree. Make sure it doesn't expose them > or register them, and then it can do what it likes. > > _______________________________________________ > Cvs-ghc mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
