"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.:
pathify (now + 150) weekday
My gut feeling is to say +1 to paren paths, but I would love to hear others weigh in with any issues they think might arise because of it.
Ladislav
I did not write #2094 to just pick paren paths and ignore Rebol syntax design. For example, if we do not take it seriously that space is significant not just when preceding some alpha character or a digit, we lose many opportunities to add new syntax to Rebol after going out of alpha stage. For example, we will not be able to introduce syntax like
my-heredoc{}my-heredoc
later, because somebody will state he wants to be able to omit space at his whim meaning
my-heredoc {} my-heredoc
, i.e., wanting to get two words and an "old-fashioned" string when writing
my-heredoc{}my-heredoc
That certainly is legitimate. If you really want that, please be so kind and say so now at least as an information for me to be able to take that into account
Also, I do not need, e.g. ()/() to be supported immediately, I just wanted what #2094 stated, i.e., make sure that ()/() shall be treated as a different syntax than () / ().
What is the meaning of the syntax can be decided later, now it is necessary to make sure there may be some "later"
I see this as an opportunity to amend Rebol syntax with the future in mind, that is why I wrote the ticket
needs space between MY-SPEC and MY-BODY since they are two distinct arguments of FUNC. Also, space preceding the [ charater is significant as can be proven comparing
#[]
and
# []
, which actually differ only in space preceding the [ character. There are much more serious changes already in R3 than the change proposed in #2094
Gregg
{i.e., wanting to get two words and an "old-fashioned" string when writing my-heredoc{}my-heredoc That certainly is legitimate. If you really want that, please be so kind and say so now}
I thought I did say so. Yes, that is what I want.
Ladislav
For example, #2094 may be used to find a very reasonable syntax for matrices, arrays,and some values that may be needed int the future
Also, there already is a demand for the
my-heredoc{}my-heredoc
syntax as you might have noticed
Do you really want to flush all these opportunities down the sink?
Gregg
Right now, yes. You haven't convinced me that the changes proposed in #2094 will make REBOL a better language.
Ladislav
Notice that there is no "right now". Once out of alpha it will not be possible any more.
Gregg
When I say "right now", I mean "based on my curreny body of knowledge". Mine is only one vote.
Ladislav
Yes, I understand what it means. I did try actually quite hard writing a lot in the ticket, discussing the things here and presenting many useful case already like:
For me these reasons are convincing. I do not think I can be much more persuasive than this.
I, of course, mentioned, that virtually every case ignoring space significance is provably a bug in either MOLD or LOAD. I mentioned correctness, reflexivity, expressivity, consistence. I think that I am done with convincing.