Trying to comprehensively disallow this is not a feasible option, I think.
R2: >> p: make path! 0 >> insert/only p [] >> insert/only p [] >> insert/only p [] >> p == []/[]/[]
Andreas
Re Ladislav's claim about the obviousness in the "/a/b" case: I don't think it's that obvious. It's a design choice.
However, in this particular case I can sympathise with arguing in favour of MOLD's behaviour. But I can similarly sympathise with arguing in favour of _neither_, for example preferring a design where LOAD gives a syntax error and MOLD produces construction syntax.
Ladislav
"I can similarly sympathise with arguing in favour of _neither_" - I am sorry, but you can't. The case was:
* MOLD stating that two syntaxes were not equivalent * LOAD stating that the two syntaxes were equivalent
logic does not allow you to say neither is true
Andreas
I'm sorry, but I can. If you re-read, you will discover that I was talking about preferred behaviour.
Ladislav
Yes, but that is unrelated to the question I was asking
Andreas
That may well be.
Ladislav
The question I was asking was whether
[/a/b]
and
[/a /b]
were equivalent syntaxes or not
Ladislav
In any case, the truth is (as Andreas correctly pointed out), that the question whether the syntaxes are equivalent or not has not been resolved correctly in R3 yet, since MOLD and LOAD give different answers to the question. I gave my reasons why I tend to agree with MOLD in this case.
Ladislav
It is not just about some logic, it is also about other reasons like reflexivity (Rebol is its own metalanguage, or it should be if it is not yet), expressivity (common values should be expressible in Rebol syntax) and correctness (LOAD and MOLD should give compatible answers to basic syntax questions).
Andreas
What I was saying is that it's perfectly valid to agree with MOLD in as far as these syntax examples should not be treated equivalently all the while not agreeing with MOLD about how to actually treat those different syntax examples.
Ladislav
Yes, agreed
However, I do not think it is problematic to state that
[/a /b]
should correspond to a block containing two refinements (this is probably the most common case and both MOLD and LOAD are in agreement in this case)
That does not mean I already stated how should
[/a/b]
be handled. I just think that there are sufficient reasons to handle it as a separate case distinct from the above.
I still think that it is possible to mark
[/a/b]
as unsupported syntax at present, if we prefer
Ladislav
"So what is [][]?" - I answered your question, but try to be more comprehensive in hope that it will make my answer understandable: For me [][] is a separate syntact distinct from [] []. For me, [][] isn't a counterpart of any specific Rebol value I know, so I propose to mark it as "unsupported syntax" at present, until we find a use for it.
Ladislav
Gregg{What if MOLD produced a serialized syntax for paths that start with a non-word?
#[path! [/a b]]}Gregg
There are many issues with the above:
* "serialized syntax" never made better sense than "syntactic syntax" or "serialized series" * HostileFork proposed a much better looking "construction syntax" name for this syntax * Carl accepted this change to the mainline three months ago, so it is now "official" * I think that it *is* possible to use the construction syntax #[path! [/a b]] in this specific case, since this path is rather uncommon , so I do not insist on using the (already available, shorter and used by MOLD) syntax /a/b * However, if using the construction syntax for the value, I still cannot agree to use the /a/b syntax for /a /b, because that is confusing, inconsistent, inconvenient and unneeded as HostileFork originally pointed out * More importantly, the syntax ()/() is too useful to just ignore it. For example, the expressions (now + 150)/weekday or (now)/second make sense and are missed by users. Rebol does not allow arbitrary spaces around parentheses anyway - both MOLD and LOAD "agree" that [a/(b)/(c)] is not equivalent to [a/(b) / (c)]. Thus, using (a)/(b) as a synonym for (a) / (b) is confusing, inconsistent, inconvenient and unneeded. Therefore, we shall have the syntax (now + 150)/weekday available and forcing users to #[path! [(now + 150) weekday]] contradicts the design philosophy of Rebol, since it uses syntax that is more complicated than necessary for a common expression.
Ladislav
Gregg{Is this correct?
>> mold to path! [/a/b] == "/a//b"}Gregg
That is yet another case where LOAD disagrees with MOLD:
>> load "a//b" ** Syntax error: invalid "path" -- "a/" ** Where: to case load ** Near: (line 1) a//b
In this case LOAD "states" that the syntax is unsupported (I do not like LOAD error messages, but that is unrelated to the discussion). It is easy to agree with LOAD, since the syntax is not supported, indeed (at least not supported well).
Gregg
[/a/b] and [#a/b]. I think they either need to be unsupported or treated as normal path! values. I can see arguments both ways, but making them paths would be more useful. Can't say what issues that might create in existing native code that deals with refinements, e.g., function handling.
"For me, [][] isn't a counterpart of any specific Rebol value I know, so I propose to mark it as "unsupported syntax" at present, until we find a use for it."
Thanks for clearing that up. I did not understand your intent before. This one I don't agree with.
Gregg
On paths with leading parens, they could be useful. I, myself, might even have missed having them a time or two, but not often enough to consider proposing the change you suggest. So, I don't agree that it's too useful to just ignore and, since we've never had it, I also can't say if it will be a common expression syntax. Meaning, just, that I don't place the same weight on its potential value that you do right now, but I agree it could be useful. And it would be small work to make it easy to use. e.g.: