Additionally, Another way to include line number information and to improve readability of the degugging code is to add "verify" as an "assert" with flipped parameters so we can write:
let x= head xs `verify` (not $ null xs) So the assertions appear on the right , separated from the rest of the code. instead of let x= assert (not $ null xs) xs 2013/2/26 Gershom Bazerman <gersh...@gmail.com> > On 2/25/13 9:42 AM, Simon Peyton-Jones wrote: > > I’m afraid the rewrite-rule idea won’t work. RULES are applied during > optimisation, when tons of inlining has happened and the program has been > shaken around a lot. No reliable source location information is available > there.**** > > ** ** > > See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and > please edit it.**** > > ** ** > > One idea I had, which that page does not yet describe, is to have an > implicit parameter, > something like ?loc::Location, with**** > > errLoc :: ?loc:Location => String -> a**** > > errLoc s = error (“At “ ++ ?loc ++ “\n” ++ s)**** > > ** ** > > This behave exactly like an ordinary implicit parameter, EXCEPT that if > there is no binding for ?loc::Location, then the current location is used. > Thus > > > I like the general approach of this proposal quite a bit. I'd very much > like Location to be not just a string, but a record type. Ideally we could > recover not just module name, line and character, but also the name of the > function that takes the location. This would eliminate an entire swath of > use-cases for Template Haskell. For example, I've worked out a > template-haskell-free version of the Cloud Haskell closure API, which > hopefully is getting merged in at some point. The major drawback it has is > that the user is required to provide a globally-unique identifier for each > closure, ideally stable across compilations. The current TH code solves > this by grabbing the function and module name. If we could get direct > access to these things without requiring template haskell, that would be > quite nice. Other types of RPC libraries I've worked on could similarly > benefit from this. > > Cheers, > Gershom > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alberto.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
