Re: RFC: rewrite-with-location proposal
Eric Seidel <eric <at> seidel.io>
2015-02-05 00:39:32 GMT
Evan Laforge <qdunkan <at> gmail.com> writes:
> 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
That's correct, though I regrettably forgot to update the Phabricator
summary with the rename from Location to CallStack (the actual docs do
properly talk about CallStacks).
A constraint (?x :: CallStack) will always be solved for the source
location that gave rise to it, when it comes from a function signature
(as opposed to a use of the implicit param) you'll get the immediate
call-site. Furthermore, if that call-site has a CallStack implicit param
in scope, the stacks will be appended (this appending of call-stacks is
the bit that I'm not sure will see much use). Does that make sense?
> 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? Enable TH globally? Those
> all seem impractical if you have or are expecting thousands of
> 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!
You're quite right, there are plenty of reasons to want this
functionality beyond error reporting, though I'd personally like to use
this for `error`, `undefined`, and `assert` as well!