World: r3wp

date has many variations, its probably the more complex one left

yep

actually,  path! also has a few quirks, like allowing parens and 
the use of a  get-set-word at the end

but path! needs all the other dataypes to be finished first

no, afaik,  just paren!, word and its own additional format quirks. 
    as the global block definition expacts, so too will parens, and 
thus the path.

expacts... expands

So, path! is not complex in that regard (values separated by '/')

yeah, just have to find the values which are valid in a path (not 
all types are valid, at least in R2)

Agreed

tag! yes, string! no.   for example:

>> block: [55 "abc" [test] <tag> [test]]
== [55 "abc" [test] <tag> [test2]]
>> block/"abc"
** Syntax Error: Invalid path -- block/
** Near: (line 1) block/"abc"
>> block/("abc")
== [test]
>> block/<tag>
== [test2]

I bet you didn't know tags where usable directly  ?  not many think 
about it, but since tags are strings, they make a lot of sense for 
representing XML tree structures... and indeed, I used them when 
I had namespaced tags.

Sorry, I knew ;-)

hehe.  but it may adds another complexity to the  <  parsing rule 
maybe some precedende in the rule will be required to make sure the 
this/<tag> isn't short-circuited by another simpler rule.

maybe some precedende in the rule == .  Maybe some precedende manipulations 
in the rules

Ok, I will go first with time! because date! needs it

remember that there are two different time formats.

Say ?

[ ##:##:## opt [decimal]] |  ##:## ]

actually... strike that... I just discovered how twisted the loader 
is .

Oh, there are more weird forms than that ;-)

I just discovered that this is valid:
>> 3:3.4
== 0:03:03.4
a dangerous gotcha since:
>> 3:3
== 3:03

:0
0:+
-1:0

uhuh

lol
>> :111111
== 1851:51

maybe we can note to this effect within the comments, to indicate 
how the time shifts when two or three number values are in the time.
hehe I can see a noob scratching his head  ;-)

3:03     == 3:03:00  
3.03.4  == 0:03:03.4

fast division by 60

wow this one is vile:
0:+

its ironic that the above will load but that a single comma with 
kill the loader   :-)

I can't use the time! rule inside date!, the allowed forms are different.
Youpiiiiiiiiii

Trolololol :)))))

time-syntax: [
[
	and [#":" digit]		; :##  
	| sign			; +:, -:
	| opt sign some digit   : +-##:
]
1 2 [
	#":" not #"." [
		opt #"+" any digit #"." any digit not #":"	; :+##.##
		| #"-." any digit not #":"				; :-.##:
		| opt #"+" some digit				; :+##:
		| #"+"						; :+:
		| #"-" any #"0"					; :-00:,  :-:
	]
] termination
]

simple enough   ;-)

Only if it works

not tested on R2 though

All that complication because 'minus' is allowed where it makes no 
sense

Missed one case already...

time-syntax: [
[
	and [#":" digit]		; :##  
	| sign				; +:, -:
	| opt sign some digit   : +-##:
]
1 2 [
	#":" not #"." [
		opt #"+" any digit #"." any digit not #":"	; :+##.##
		| #"-" any #"0" #"." any digit not #":"		; :-00.##:
		| opt #"+" some digit				; :+##:
		| #"+"							; :+:
		| #"-" any #"0"					; :-00:,  :-:
	]
] termination
]

Committed, did not check it, though.

About short Date syntax .
A valid month is taken from system/locale/months:
== ["January" "February" "March" "April" "May" "June"
    "July" "August" "September" "October" "November" "December"
]

The month must be 3 letters a least, but longer sub-strings are valid 
forms as well:

eg. 1-Jan-2000, 1-Janu-2000, 1-Janua-2000,1-Januar-2000,1-January-2000.


One can do a simple rebol function to pick-up a valid month from 
system/locale/months.

Doing this only with plain formal static parse rules would be painfull 
because it should include all the valid sub-strings.
eg. ["Jan" | "Janu" | "Janua" | ...]

What do you think ?

I try to resume my thought.
Is it valid to run some code in the rules using (...) ?

Hmm, that is what we wanted to not use...

No () please, but you can of course use code to generate the static 
rule in the first place :)

[
    "Jan" | "Janu" | "Janua" | "Januar" | "January" |

    "Feb" | "Febr" | "Febru" | "Februa" | "Februar" | "February" |
    "Mar" | "Marc" | "March" |
    "Apr" | "Apri" | "April" |
    "May" |
    "Jun" | "June" |
    "Jul" | "July" |
    "Aug" | "Augu" | "Augus" | "August" |

    "Sep" | "Sept" | "Septe" | "Septem" | "Septemb" | "Septembe" | "September" 
    |
    "Oct" | "Octo" | "Octob" | "Octobe" | "October" |

    "Nov" | "Nove" | "Novem" | "Novemb" | "Novembe" | "November" |
    "Dec" | "Dece" | "Decem" | "Decemb" | "Decembe" | "December"
]

Even something like that ?


months: {-January-February-March-April-May-June-July-August-September-October-November-December}
check-month: use [sav *month][
	[copy *month [#"-" 3 20 letters] sav: :months to *month :sav]
]

probe parse "1-Marc-2000" [1 2 digits check-month #"-" 1 4 digits]

Yes, strictly no code blocks in the rules.

Just use the generated block :)

(Ah, and no "advanced" parse constructs. Trying to stay PEG compatible.)

The order of subwords in the above "exhaustive rule" shall be reversed, 
though.

month-names rule committed

(Ahem, yes of course. Thanks for fixing that, Ladislav.)

However, the example Steeve posted does not contain "code blocks"