- From: ☻Mike Samuel <msamuel@google.com>
- Date: Tue, 22 Nov 2011 19:20:28 -0500
- To: "Mark S. Miller" <erights@google.com>
- Cc: Alex Russell <slightlyoff@google.com>, Dominic Cooney <dominicc@chromium.org>, Brendan Eich <brendan@mozilla.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Anne van Kesteren <annevk@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Rafael Weinstein <rafaelw@google.com>, Adam Klein <adamk@google.com>, Erik Aarvidson <arv@google.com>
On Tue, Nov 22, 2011 at 18:54, Mark S. Miller <erights@google.com> wrote:
> On Tue, Nov 22, 2011 at 7:43 AM, ☻Mike Samuel <msamuel@google.com> wrote:
>>
>> On Tue, Nov 22, 2011 at 10:37, Alex Russell <slightlyoff@google.com>
>> wrote:
>> > On Sun, Oct 23, 2011 at 5:22 AM, Dominic Cooney <dominicc@chromium.org>
>> > wrote:
>> >> Quasis don’t provide a means for accurate error reporting, ie line and
>> >> column numbers. (Since quasis seem designed for embedding DSLs, this
>> >> seems
>> >> like a shortcoming?)
>>
>> This is true right now, but if the quasi were changed to include the
>> file, line number and char offset of the open quote and the number of
>> lines and length of last line for each substitution, then position
>> info is recoverable with the exception of tab columns introduced
>> inside substitutions.
>
> I like the idea of enhancing the quasis proposal so that source+line+column
> can be recovered. However, I don't understand the tab column notion, and
> (perhaps related?) I don't see how the needed extra info can be this simple.
> If indeed we need more info, and if we had a standard composable source map
> format as deeply freezable JSON data[1], then I would like to see such a map
> included in the literal data object.
The tab column issue is probably of no importance for error reporting.
Just, there's no way to distinguish:
eval(" `${ x}` ")
from
eval(" `${\tx}` ")
Received on Wednesday, 23 November 2011 00:20:57 UTC