Re: RFC: rewrite-with-location proposal
Simon Hengel <sol <at> typeful.net>
2015-03-30 04:04:35 GMT
On Wed, Feb 04, 2015 at 04:10:56PM -0800, Evan Laforge wrote:
> On Wed, Feb 4, 2015 at 3:51 PM, Eric Seidel <eric <at> seidel.io> wrote:
> > Yep, my original motivation was getting access to source locations
> > within embedded DSLs. The call-stack is a nice and easy extension, but
> > I'm not sure how useful it will be in practice, as the first function
> > that doesn't request a CallStack parameter will cut off the stack. This
> > means that the generated stacks will often be quite short, I imagine.
> Well, as I said, all I really care about is the direct caller. From
> the example in the commit, it looks like the function with the (?x ::
> Location) annotation can get its immediate caller, even if that caller
> doesn't have the annotation. If that's true, that's all that is
I completely agree with you. Logging and failing test cases where my
main motivation when I looked at the problem domain (even though I still
think the situation with error/undefined is unfortunate too).
> And from my point of view, it's not just "maybe useful in practice",
> but absolutely required, to the point where I wrote a custom
> preprocessor for it. I've been using it for 6 or 7 years and I sort
> of forgot that other people don't have it. I actually have no idea
> how other people do logging... just hope the message is unique and
> grep -n all the time? And for tests, manually give every single
> assertion a unique name and grep -n again?
hspec-discover adds heuristic source locations by now (without really
parsing any Haskell code, so it's pretty robust, worst case is you don't
get a source location). This is on a spec item (== test case)
granularity. I still want proper source locations, so that we can
attach them to individual expectations/assertions.
> Enable TH globally?
For logging-facade I added a TH version, but I don't really like it.
And again, I'm super eager to use proper source locations here, once the
patch got merged!
> I don't think it needs to be used at all in the standard libraries,
> since logging and testing are not part of base. I can understand if
> the merge window for 7.10 is closed, but trying to come up with a use
> in base shouldn't hold it up!
As you argued in a later mail, I would be in favor of using it for all
partial functions in base, too (but we may want to spend some time
looking at how list fusion may be affected).
But I think it makes sense to treat this as two separate discussions.
Hopefully we get this patch merged ASAP, then we can still discuss to
what extend we want to use it in base.