World: r3wp

I don't see to recognise the serialized version of the few datatypes 
which have it...
 #[true] #[false] #[none] [#function [][] ]  [#object [] ]

yep

image!

#[list![]]  #[hash![]]

Okkkkk, there is a huge list for the serialized ones ;-)

money!    1.00%

percent!

date! time!...

bitset!...

path! set-path! lit-path!

Well...

just write: ? datatype! in the console to get some list

I will focus on the annoying ones for now

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.