Path! syntax and date! syntax clash

[Siskin-Bot]

Submitted by: Ladislav

In the example below there is a demonstration of a date! syntax and path! syntax "clash". The question is whether this is intended and whether it is optimal.

This is related to #2090.

I would like to be able to define a path containing a complete date value in some cases.

The last example is probably the worst since it is the hardest to amend.

>> to block! [6/Nov/2013/17:43]
== [6-Nov-2013/17:43]

>> to block! 'a/6/Nov/2013/17:43
== [a 6 Nov 2013 17:43]

>> to block! 'a/6-Nov-2013/17:43
== [a 6-Nov-2013 17:43]

>> type? load mold to path! [19 Nov 2013 21:01:51]
== date!

---

^{Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Syntax Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#2089}

Comments:

Rebolbot commented on Nov 17, 2013:

Submitted by: Gregg

If you are saying that you want the following to be equivalent

'a/6/Nov/2013/17:43
'a/6-Nov-2013/17:43

I'll say -1, because it could lead to unexpected results. i.e., how do I escape it if I happen to have path values that would unintentionally become a date?

---

Rebolbot commented on Nov 18, 2013:

Submitted by: Ladislav

"If you are saying that you want the following to be equivalent..." - I am not saying that. I am saying that there is a "syntax clash" that causes problems.

---

Rebolbot commented on Nov 18, 2013:

Submitted by: Gregg

Ah, I think I see what you're saying now. You would have to put the date in a paren or something today. Do you have an idea for a cleaner solution?

---

Rebolbot commented on Nov 19, 2013:

Submitted by: Ladislav

The ISO date format does not "clash" with path syntax. Supporting ISO 8601 we will be better off in this sense as well. See #2092. Also, it is possible to use paren in path is some cases, which may be a way to circumvent the problem.

---

Rebolbot commented on Nov 19, 2013:

Submitted by: Gregg

I like that the slash in a date makes the time a refinement of the date, but it does clash in paths. I hesitate to suggest it, but "@" might be an understandable delimiter. It is non-standard, but reads well as "at" in this context. I also just found that REBOL can load it, thinking it's an email. e.g. 19-Nov-2013@12:30. Not all date forms load that way, and I very much doubt if anyone is using that feature that would complain about their code breaking.

That said, I can live with ISO8601, as I think it would be good to be able to load it in any case. I don't like the T, but the benefits may outweigh my feelings. :-)

---

Rebolbot commented on Nov 19, 2013:

Submitted by: Ladislav

The benefits of ISO will be:

• standard compliance
• improved compatibility between date syntax and path syntax

---

Rebolbot commented on Nov 19, 2013:

Submitted by: Ladislav

Regarding "I like that the slash in a date makes the time a refinement of the date" - understood, but, actually, I do not like this "benefit":

>> type? load mold to path! [19 Nov 2013 21:01:51]
== date!

Also, this is not easy to amend. Any idea?

---

Rebolbot mentioned this issue on Jan 12, 2016:
Path! syntax and file! syntax clash

---

Rebolbot added the Type.wish on Jan 12, 2016

---

MarkEye commented on Mar 14, 2016:

My idea has three parts:
(1) use MOLD/ALL
(2) MOLD/ALL of paths that don't begin with a word should put out construction syntax
(3) LOAD should be able to accept construction syntax for paths that do not begin with words

---

Rebolbot mentioned this issue on Mar 14, 2016:
Support ISO 8601

---

Rebolbot mentioned this issue on Aug 5, 2018:
Give Issue and Refinement path types

---

Hostilefork added the Ren.important on Jun 15, 2018

---

Oldes added a commit to Oldes/Rebol3 that referenced this issue on Dec 17, 2018:
FEAT: enabling T as a delimiter between date and time and Z as a zero…

---

Oldes added a commit to Oldes/Rebol3 that referenced this issue on Dec 17, 2018:
FEAT: letting MOLD/ALL on datetime value to produce ISO8601 valid result

---

[Oldes]

It's now possible to use ISO8601 date version:

>> to-block 'a/2013-11-08T17:01
== [a 8-Nov-2013/17:01]