- From: <bugzilla@jessica.w3.org>
- Date: Fri, 02 May 2014 02:30:03 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24959 Nils Barth <nbarth+w3bugzilla@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nbarth+w3bugzilla@google.co | |m --- Comment #1 from Nils Barth <nbarth+w3bugzilla@google.com> --- I believe that the issue is that extended attribute phrase grammar is *context-sensitive*, specifically due to collision of , as a extended attribute separator (*between* extended attributes) and as an identifier separator (*within* an extended attribute). Cameron, is this intended? This makes parsing extended attributes *much* more difficult, because we need to do it during semantic analysis, not during parsing. Consider supporting both [Exposed=Window,Worker] and [Global] (grammar-wise: these are both valid interface extended attributes). Writing this as: [Exposed=Window,Worker,Global] ...is ambiguous, and requires complex semantic analysis just to *parse*. Writing this as: [Exposed=Window,Worker, Global] ...seems to disambiguate, but requires white space to be significant. Using a different separator fixes this: [Exposed=Window;Worker,Global] In Blink we've been using | for extended attribute value separators, so we'd write this as: [Exposed=Window|Worker,Global] ...or actually (style-wise): [ Exposed=Window|Worker, Global, ] interface Foo { ... }; Specifically, the problem is with the production rule ExtendedAttributeIdentList, which allows one to write [Exposed=Window,Worker] http://heycam.github.io/webidl/#prod-ExtendedAttributeIdentList It's currently used for 3 extended attributes: [Exposed], [Global], and [PrimaryGlobal] The underlying issue is that the extended attribute phrase grammar is *context-sensitive*, and thus needs to be parsed during semantic analysis. This is stated at: http://heycam.github.io/webidl/#idl-extended-attributes """ Any extended attribute encountered in an IDL fragment is matched against the following six grammar symbols to determine which form (or forms) it is in: ExtendedAttributeNoArgs ExtendedAttributeArgList ExtendedAttributeNamedArgList ExtendedAttributeIdent ExtendedAttributeIdentList ExtendedAttributeTypePair ... Each extended attribute definition will state which of the above six forms are allowed. """ I.e., the phrase grammar depends on the ExtendedAttribute (the value of the key). This is *not* a serious issue for argument lists, like [Constructor(foo x, bar y)], since the () delimiters set this off, allowing context-free parsing. However, for bare identifier lists, this causes parsing problems. Could we change this? -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 2 May 2014 02:30:05 UTC