Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-03-03 Thread Alberto G. Corona
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 fr

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-26 Thread Gershom Bazerman
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.

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-26 Thread Michael Snoyman
l.com [mailto:michael.snoy...@gmail.com] *On > Behalf Of *Michael Snoyman > *Sent:* 25 February 2013 18:19 > *To:* Simon Peyton-Jones > *Cc:* Alexander Kjeldaas; Simon Hengel; Haskell Cafe > > *Subject:* Re: [Haskell-cafe] RFC: rewrite-with-location proposal > > ** *

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-26 Thread Simon Peyton-Jones
der Kjeldaas; Simon Hengel; Haskell Cafe Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones mailto:simo...@microsoft.com>> wrote: I'm afraid the rewrite-rule idea won't work. RULES are applied during optimisation, whe

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-26 Thread Daniel Trstenjak
Hi Michael, On Mon, Feb 25, 2013 at 02:41:19PM +0200, Michael Snoyman wrote: > At that point, we've now made two changes to REWRITE rules: > > 1. They can takes a new ALWAYS parameters. > 2. There's a new, special identifier currentLocation available. > > What would be the advantage is of that

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Michael Snoyman
f myErr in foo. > > ** ** > > Simon > > ** ** > > ** ** > > ** ** > > *From:* haskell-cafe-boun...@haskell.org [mailto: > haskell-cafe-boun...@haskell.org] *On Behalf Of *Alexander Kjeldaas > *Sent:* 25 February 2013 12:16 > *To:* Simon Hengel >

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Kim-Ee Yeoh
On Mon, Feb 25, 2013 at 9:42 PM, Simon Peyton-Jones wrote: > One idea I had, which that page does not yet describe, is to have an > implicit parameter, > something like ?loc::Location** > > +1 Implicit params has a bad rap in some circles because of counterintuitive behavior when manually binding

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Roman Cheplyaka
* Petr Pudlák [2013-02-25 14:02:28+0100] > 2013/2/25 Michael Snoyman > > > > > At that point, we've now made two changes to REWRITE rules: > > > > 1. They can takes a new ALWAYS parameters. > > 2. There's a new, special identifier currentLocation available. > > > > What would be the advantage is

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Simon Peyton-Jones
c:Location, and so the magic is that we use the location of the call of myErr in foo. Simon From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Alexander Kjeldaas Sent: 25 February 2013 12:16 To: Simon Hengel Cc: Haskell Cafe Subject: Re: [Haskell-cafe]

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Alexander Kjeldaas
My initial thought as I read the proposal was to represent currentLocation as a lexical bound variable, thus "error" is rewritten to the expression: let currentLocation = "someplace.hs:123" in errorLoc currentLocation there is no referntial transparency issue in that because there is no global fu

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Petr Pudlák
2013/2/25 Michael Snoyman > > At that point, we've now made two changes to REWRITE rules: > > 1. They can takes a new ALWAYS parameters. > 2. There's a new, special identifier currentLocation available. > > What would be the advantage is of that approach versus introducing a > single new REWRITE_

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Twan van Laarhoven
On 25/02/13 13:41, Michael Snoyman wrote: At that point, we've now made two changes to REWRITE rules: 1. They can takes a new ALWAYS parameters. 2. There's a new, special identifier currentLocation available. What would be the advantage is of that approach versus introducing a single new REWRI

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Michael Snoyman
On Mon, Feb 25, 2013 at 2:15 PM, Alexander Kjeldaas < alexander.kjeld...@gmail.com> wrote: > On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel wrote: > >> On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote: >> > I think there is no need to have a separate REWRITE_WITH_LOCATION >> > r

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Alexander Kjeldaas
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel wrote: > On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote: > > I think there is no need to have a separate REWRITE_WITH_LOCATION > > rule. What if the compiler instead rewrites 'currentLocation' to the > > current location? Then you

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Simon Hengel
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote: > I think there is no need to have a separate REWRITE_WITH_LOCATION > rule. What if the compiler instead rewrites 'currentLocation' to the > current location? Then you'd just define the rule: > > {-# REWRITE "errorLoc" error = erro

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Twan van Laarhoven
On 25/02/13 07:06, Michael Snoyman wrote: Quite a while back, Simon Hengel and I put together a proposal[1] for a new feature in GHC. The basic idea is pretty simple: provide a new pragma that could be used like so: error :: String -> a errorLoc :: IO Location -> String -> a {-# REWRITE_WITH_LOC

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Alexander Kjeldaas
Immediately, the alternative of introducing bound variables in the environment that is available to rewrite rules comes to mind as a more general way of doing this. So this example from the GHC docs: {-# RULES "map/map"forall f g xs. map f (map g xs) = map (f.g) xs "map/append" forall f x

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Joachim Breitner
Hi, Am Montag, den 25.02.2013, 10:13 +0100 schrieb Simon Hengel: > On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote: > > Hi, > > > > Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > > > Quite a while back, Simon Hengel and I put together a proposal[1] for > > > a

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Michael Snoyman
On Mon, Feb 25, 2013 at 11:13 AM, Simon Hengel wrote: > On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote: > > Hi, > > > > Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > > > Quite a while back, Simon Hengel and I put together a proposal[1] for > > > a new feature

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Simon Hengel
On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote: > Hi, > > Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > > Quite a while back, Simon Hengel and I put together a proposal[1] for > > a new feature in GHC. The basic idea is pretty simple: provide a new > > pragma

Re: [Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-25 Thread Joachim Breitner
Hi, Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > Quite a while back, Simon Hengel and I put together a proposal[1] for > a new feature in GHC. The basic idea is pretty simple: provide a new > pragma that could be used like so: > > error :: String -> a > errorLoc :: IO Locatio

[Haskell-cafe] RFC: rewrite-with-location proposal

2013-02-24 Thread Michael Snoyman
Quite a while back, Simon Hengel and I put together a proposal[1] for a new feature in GHC. The basic idea is pretty simple: provide a new pragma that could be used like so: error :: String -> a errorLoc :: IO Location -> String -> a {-# REWRITE_WITH_LOCATION error errorLoc #-} Then all usages of