Open larsgw opened 2 weeks ago
Also, I think node prop /-foo = bar
is ambiguous, either a Node with a Value "prop"
or with a Property prop=bar
. Given that, we might need to change the grammar as well.
I think a good test for where /-
should go is whether we would also allow comments in there.
Would prop = /-foo bar
not make sense, but `prop = /foo/ bar would? Why? I feel like the latter is very sensible (and imo, so is the former)
The latter is definitely a bigger concern. I'm not sure what to do about that ambiguity: you definitely should be able to slashdash entire props...
Maybe a better test for where /-
should go, is whether the entity you're commenting out could occur there without being commented out. i.e. you already cannot put a slash-dashed Node between two Values, or between a Value and a Children block. So I would suggest no slash-dash before a =
in a prop, and after a =
only allow slash-dashed Values, not Properties. I would also prefer to remove the mandated whitespace between =
and /-
in the current grammar.
Does this work?
prop-value-space := plain-node-space* ('/-' plain-node-space* value plain-node-space+)*
prop := string plain-node-space* '=' prop-value-space value
Would
prop = /-foo bar
not make sense, butprop = /*foo*/ bar
would? Why? I feel like the latter is very sensible (and imo, so is the former)
I think prop=/-foo "bar"
would be confusing, but I thought prop=/-foo
was allowed (it's not, yet), and with spaces it looks okay (in KDL v1, spacing around =
was disallowed).
It makes sense that an entity next to /-
is parsed as it normally would be, but the /-
modifier then makes it fully "discarded", same as #_
works in edn (and clojure). This seems conceptually simple and also has no parsing ambiguities. I think it was similar in KDLv1 but later has been changed?
What would be the "entity next to /-
" though in the case of node prop /-foo = bar
? It could be either foo
or foo = bar
, at least in the current grammar.
I mean that it would be parsed as if /-
is not there, i.e. node prop foo = bar
, which can only be <node-name "node"> <value "prop"> <property "foo" "bar">
. Then the /-
modifier is applied to the property (say, in a semantic action) and this property is not added to the AST. (But the current grammar is ambiguous, yes.)
edit: That is, I view /-
just as an entity modifier in the grammar, which alters the semantics of the document.
Ah I see, that makes sense.
That explains why node prop=/-foo bar
does not make as much sense to me then. Without /-
it'd be <node><property "prop" "foo"><value "bar"></node>
, making the effect of /-
to be "remove the second part of <property>
and replace it with the subsequent <value>
".
So thinking about it, what we want is for slashdash to work in exactly three places:
Does that sound like what we want? It seems to be a pretty straightforward rule
That sounds good to me.
Are we okay with slashdashed children blocks in a non-final position? E.g. node foo /-{ node; } bar
is currently allowed, I believe.
idk. Personally, I'm willing to live with that, even though it's a bit weird.
If it was easy to block I'd prefer to not allow that, but I'm fine with allowing it if needed, yes.
The grammar for a property looks like this at the moment:
However, the text says:
Probably the latter needs to be reworded to allow whitespace, esclines, and slashdash comments.
(Sidenote, I'm a bit unsure if slashdash comments are good in this context. Firstly,
node prop= /-"foo" "bar"
would be equivalent tonode prop="bar"
which is not very obvious (it looks like"foo"
and especially"bar"
are just Values to me on first sight). Secondly,node prop=/-"foo" "bar"
is invalid which seems a bit inconsistent, I feel like that would be clearer. ~Thirdly, I thinknode prop /-="foo" ="bar"
is probably very annoying to parse, especially nowprop
is a valid Value.~)