newtype deriving clause ceases to work in HEAD

Hi, The following code compiles with GHC 6.4.2, but does not typecheck with GHC HEAD pulled on Sunday. module CompilerMonad where import Control.Monad import Control.Monad.Reader import Control.Monad.Error newtype CompilerError = CE String deriving Error newtype CM r a = CM (ReaderT r

Re: newtype deriving clause ceases to work in HEAD

that I had written quite a bit of typechecked code on top of the erroneous CM monad declaration. Thanks for your help Simon, Mathieu | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Mathieu Boespflug | Sent: 29 November 2006 00

Re: Static values language extension proposal

[Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland

Re: Static values language extension proposal

from any of the modules that were linked at build time were missed, that is difficult. By avoiding a RemoteTable entirely, we avoid having to solve that difficult problem. :) Best, -- Mathieu Boespflug Founder at http://tweag.io. ___ Glasgow-haskell-users

Re: Static values language extension proposal

Hi Carter, On Tue, Jan 28, 2014 at 6:03 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Theres actually a missing piece of information in this thread: what are the example computations that are being sent? Quite simply, the same as those considered in the original Cloud Haskell paper,

Re: Static values language extension proposal

Hi Eric, On Wed, Jan 29, 2014 at 3:20 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Mathieu Boespflug wrote: thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library

Re: Static values language extension proposal

, a tool like patchelf[3] would help immensely for moving executables+their dependencies around in a 'bundle' style way. [3] http://nixos.org/patchelf.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Mathieu Boespflug Founder at http

Re: haskell xml parsing for larger files?

Hi Christian, as regards your question about sharing strings, there are a number of libraries on Hackage to achieve this, e.g. in the context of compiler symbols. To cite only a few: intern, stringtable-atom, simple-atom. I'm sure there are others. Best, -- Mathieu Boespflug Founder at http

Re: RFC: changes to -i flag for finding source files

principle, which I think is a good one. That is, I ought to be able to swap in a different implementation of a map for the standard one in the containers package without having to touch my code (especially if the exported API's happen to match). -- Mathieu Boespflug Founder at http://tweag.io

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

[Gah, wrong From: email address given the list subscriptions, sorry for the duplicates.] I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process.