August 2004 - template-haskell

FW: [Template-haskell] RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic
by Simon Peyton-Jones 05 Dec '04

05 Dec '04

Dear Template Haskell colleagues I sent three messages to the TH list a month ago. Here's one of them: the others concerned the conversions TH.Syntax <-> HsSyn; I'll fwd them in the next two messages I didn't get a single reply to any of the three. Either the TH mailing list is broken, or else you are all busy with other stuff. (After all, all three did ask for volunteers, in one form or another.) Does anyone care? I'm busy implementing GADTs at the moment, so TH has a somewhat back seat. It'll probably stay that way unless there are some signs of life in the TH ranks. Simon -----Original Message----- From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 20 July 2004 12:19 To: Duncan Coutts; Template Haskell List Subject: [Template-haskell] RE: calling fail in Q monad gives uninformativeerror message, anderror causes panic Tim and I want to tidy up the error-reporting interface in Template Haskell. The goal is that a TH user should be able to control the error messages that appear. Here's a proposal qReport :: Severity -> String -> Q () -- Report an error or warning -- ...but carry on; use 'fail' to stop fail :: String -> Q a -- Part of Monad class qRecover :: (String -> [(Severity,Loc,String)] -> Q a) -> Q a -> Q a -- Recover from the monadic 'fail' -- The first arg is the error handler -- The first String arg to the handler is what was passed to 'fail' qReports :: [(Severity,Loc,String)] -> Q () data Severity = Error | Warning qGetLoc :: Q Loc qGetModule :: Q ModuleName qWithLoc :: Loc -> Q a -> Q a data Loc = Loc FileName LineNumber CharPos The idea is that qReport dumps a message into the monad (but does not print it yet) with an indication of severity. qReport does not cause monadic failure... you can dump in as many error messages as you like. qReport adds location information from the monad to the message. fail causes monadic failure. qRecover recovers from monadic failure, giving to the recovery routine both the string passed to fail, and the accumulated messages from the enclosed computation. It can use qReports to dump all those messages back into the monad -- or it can just discard them if it wants. At a splice point, the typechecker runs the Q computation. If the result is monadic success, it continues with the returned results. If the result is monadic failure, the splice fails too. (That does not result in any panic -- the type checker is designed to fail, and recover at some outer point.) In both cases, the messages from the Q monad are dumped into the typechecker's message pile. One open question. If you say qReport Error "Bad thing" fail "wuggle" in the Q monad, do you get two type error messages ("Bad thing" and "wuggle") or just one? I can think of three possibilities a) fail s is treated as adding an error message with Severity = Error b) fail s adds no error messages c) fail s behaves like (b) if (null s) and like (a) otherwise. The advantage of (b) and (c) is that you can add a whole bunch of error messages, and then fail, without adding yet another. Comments? Once we have an interface agreed, it won't be hard to implement. Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs- | bounces(a)haskell.org] On Behalf Of Duncan Coutts | Sent: 23 June 2004 01:13 | To: glasgow-haskell-bugs(a)haskell.org | Subject: TH: calling fail in Q monad gives uninformative error message, anderror causes panic | | | ghc makes it's own type checker monad TcM an instance of the Quasi class | (which is rather cunning), however this means that if the user calls the | Monad function 'fail' then the internal TcM fail method gets called. | This monad (IOEnv) was never meant to fail (see | ghc/compiler/utils/IOEnv.hs/) so the error message is: | | Exception when trying to run compile-time code: | Code: genex_count | Exn: user error (IOEnv failure) | | Of course the user code should be using 'report', but if you're using | old code, or code that is generic in the monad it uses then people will | end up calling fail. | | Perhaps the thing to do is to wrap splices in an exception handler and | convert 'fail's into a 'report' instead. | | The same should probably be done for errors raised in pure code by | calling 'error'. At the moment it gives an overly panicky report | (although at least it passes the user's error message through): | | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | where clauses & gaurds not yet supprted in function definitions | | The error message there is generated by my code (hence the spelling | errors :-) ). | | Duncan | | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ template-haskell mailing list template-haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/template-haskell

3 3

Call for participation: GPCE'04 -- Generative Programming and Component Engineering
by Eelco Visser 25 Aug '04

25 Aug '04

CALL FOR PARTICIPATION ---------------------------------------------------------------------- Third International Conference on Generative Programming and Component Engineering (GPCE'04) Vancouver, October 24-28, 2004 co-located with OOPSLA 2004 and ISMM 2004 http://gpce04.gpce.org ---------------------------------------------------------------------- Online Registration http://www.regmaster.com/oopsla2004.html early registration with reduced rates closes September 16 ---------------------------------------------------------------------- Generative and component approaches have the potential to revolutionize software development in a similar way as automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write and maintain) are key technologies for automating program development. GPCE arose as a joint conference, merging the prior conference on Generative and Component-Based Software Engineering (GCSE) and the Workshop on Semantics, Applications, and Implementation of Program Generation (SAIG). The goal of GPCE is to provide a meeting place for researchers and practitioners interested in cutting edge approaches to software development. We aim to foster further cross-fertilization between the software engineering research community on the one hand, and the programming languages community on the other, in addition to supporting the original research goals of both the GCSE and the SAIG communities. We seek papers both in software engineering and in programming languages, and especially those that bridge the gap and are accessible to both communities at the same time. * Invited speakers * Keynote: Jack Greenfield on Software Factories * Peter Mosses on Modular Language Descriptions * Technical program * 25 papers * Aspect-orientation * Staged programming * Meta-programming * Model-driven approaches * Product lines * Domain-specific languages * Tutorials * Adaptive Object-Model Architecture: Dynamically Adapting to Changing Requirements * Multi-stage Programming in Meta-OCaml * Generative Software Development * Program Transformation Systems: Theory and Practice for Software Generation, Maintenance and Reengineering * Workshops * Software Transformation Systems Workshop * First MetaOCaml Workshop * Young Researchers Workshop * Workshop on Best Practices Model-Driven Software Development * Workshop on Managing Variabilities Consistently in Design and Code * Demonstrations * Implementation of DSLs using staged interpreters in MetaOCaml * MetaEdit+: Domain-Specific Modeling for Full Code Generation Demonstrated * Towards Domain-Driven Development: the SmartTools Software Factory * Xirc: Cross-Artifact Information Retrieval * C-SAW and GenAWeave: A Two-Level Aspect Weaving Toolsuite * The Concern Manipulation Environment * Program Transformations for Re-Engineering C++ Components

1 0

FW: [Template-haskell] FW: [ ghc-Bugs-992200 ] Template crash onconstructing existential datatype
by Simon Peyton-Jones 20 Aug '04

20 Aug '04

...and the third one... -----Original Message----- From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 19 July 2004 17:35 To: template-haskell(a)haskell.org Subject: [Template-haskell] FW: [ ghc-Bugs-992200 ] Template crash onconstructing existential datatype Dear Template Haskell folk This SourceForge bug is another example of the bad things that happen when: - a TH program constructs a syntactically invalid program - and then splices it in The trouble is that Convert.convertToHsExpr :: TH.Exp -> LHsExpr RdrName is a pure function, and fails "hard" with a panic, whereas it should really be in the TcM monad, and fail in the way any other type error fails. It's a user error, and should not show up as a panic. Would anyone like to fix hsSyn/Convert.lhs so that it lives in the Tc monad? The call (in TcSplice) is easily changed. It'd probably make sense to move it from hsSyn/ to typecheck/ I'm thinking about putting types in the syntax tree, so if others can help out with tidying up like this, it'd be great. Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of SourceForge.net Sent: 16 July 2004 10:11 To: noreply(a)sourceforge.net Subject: [ ghc-Bugs-992200 ] Template crash on constructing existential datatype Bugs item #992200, was opened at 2004-07-16 09:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992200&grou p_id=8032 Category: Compiler Group: 6.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Aizatsky (mm_aa) Assigned to: Nobody/Anonymous (nobody) Summary: Template crash on constructing existential data type Initial Comment: Windows XP D:\Tools\ghc>ghc-6.2.1\bin\ghc.exe -fglasgow-exts --make foo.hs Chasing modules from: foo.hs Compiling Any ( ./Any.hs, ./Any.o ) Compiling Foo ( foo.hs, foo.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): Malformed predicate module Any where import Language.Haskell.THSyntax genAny :: DecQ -> Q [Dec] genAny decl = do{ d <- decl ; case d of ClassD _ name _ decls -> sequenceQ [genAnyClass (name) decls] _ -> error "genAny can be applied to classes only" } genAnyClass :: String -> [Dec] -> DecQ genAnyClass name decls = do{ returnQ (DataD [forall] anyName [] [constructor] []) } where anyName = "Any" ++ name ++ "1111" constructor = NormalC anyName [(NotStrict, VarT "a")] forall = ForallT [] [] (VarT "a") module Foo where import Any class MyInterface a where foo :: a -> Int foo1 :: Int -> a -> Int $(genAny (reifyDecl MyInterface)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992200&grou p_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ template-haskell mailing list template-haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/template-haskell

1 0

FW: [Template-haskell] FW: [ ghc-Bugs-992199 ] Template crash onexistential types
by Simon Peyton-Jones 20 Aug '04

20 Aug '04

Second message referred to in my last post... -----Original Message----- From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 19 July 2004 17:51 To: template-haskell(a)haskell.org Subject: [Template-haskell] FW: [ ghc-Bugs-992199 ] Template crash onexistential types My previous message was about robust-ifying the conversion from: TH.Syntax -> HsSyn but the other direction has very similar problems. The functions in DsMeta convert: HsSyn -> TH.Syntax Unfortunately, of course TH does not implement all of GHC's extensions, so the desugaring can fall over badly. The right thing to do is presumably to make the desugarer monad support failure and errors, like the type checker monad does, and fail more gracefully. Again, is there anyone who'd be prepared to take this on? Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of SourceForge.net Sent: 16 July 2004 10:10 To: noreply(a)sourceforge.net Subject: [ ghc-Bugs-992199 ] Template crash on existential types Bugs item #992199, was opened at 2004-07-16 09:08 Message generated for change (Settings changed) made by mm_aa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992199&grou p_id=8032 Category: Compiler Group: 6.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Aizatsky (mm_aa) Assigned to: Nobody/Anonymous (nobody) >Summary: Template crash on existential types Initial Comment: Windows XP D:\Tools\ghc>ghc-6.2.1\bin\ghc.exe -fglasgow-exts foo.hs ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): deSugar/DsMeta.hs:286: Non-exhaustive patterns in function repC module Foo where import Language.Haskell.THSyntax class MyInterface a where foo :: a -> Int data AnyMyInterface = forall a. (MyInterface a) => AnyMyInterface a test = do{ d <- unQ(reifyDecl AnyMyInterface) ; print d } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=992199&grou p_id=8032 _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ template-haskell mailing list template-haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/template-haskell

1 0