r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

Steeve
11-Nov-2008
[3148x4]
yeah i agree AND is not the best word for that job.
i prefer [IF] it means what it does...
But it's not a problem for me to keep AND
for example: [IF block! INTO rule]
it's just a scam, all rules are optionnal within parse... (so IF 
or something else...)
if we take in acount his defintion: none consumming rule.
Then something like REPLAY or REWIND is more adapted.
BrianH
11-Nov-2008
[3152x4]
AND comes from the use of & in the PEG syntax papers, but it could 
also be seen as being like the AND operator in REBOL, prefixed.
Nonetheless, I agree that the names of AND and OF don't make much 
sense. The concept behind AND is sound though.
I have finally adapted Gabriele's DO proposal. Aside from naming 
issues, examples in need of explanation and any nagging questions 
we might be done here, with the exception of feedback from Carl about 
his proposals and any other issues. Anything else?
Added Chris's suggestion for AND to be named AT, and explained the 
advanced AND example (good luck!). If there aren't any more suggestions, 
I think this is ready to go to Carl.
Steeve
11-Nov-2008
[3156x2]
nothing about my ALL ?
sob...
BrianH
11-Nov-2008
[3158]
I need to talk to Carl - it's a variant of his OF proposal, which 
probably isn't done yet. I'll bring it up :)
Steeve
11-Nov-2008
[3159]
ok, good luck
BrianH
11-Nov-2008
[3160]
I edited the OF proposal to provide a syntax description similar 
to the other proposals and added your suggestion, Steeve.
Steeve
11-Nov-2008
[3161]
thanks
Pekr
11-Nov-2008
[3162]
the parse doc is becoming scary precise :-) I hope Carl is not scared 
by the amount of requests :-) Can't wait to do similar job to low 
level View. Maybe we could start :-)
BrianH
12-Nov-2008
[3163]
Maybe we're already working on low-level View :)
Pekr
12-Nov-2008
[3164x4]
ah, can't believe that :-) But - Cyphre would be involved, no? And 
AFAIK he is not :-)
Well then - transparent top window would be fine, but I think that 
more importantly - proper Unicode display should be a priority, and 
maybe looking at R3 alpha demo called button colors - it scrolls 
like molasses - there is either bug and there is more being redrawn 
than what is needed, or we have to think about other optimisations 
(e.g. I remember some 2 years ago Carl stating, that View might still 
render unnecessary things ...)
uh, wrong group, sorry ...
... another option I remember was to switch to compound rasterizer 
of AGG. And - REBOL timers are still substandard of what can be achieved 
imo ... But, as Carl said - those parts are going to be host part, 
hence open-source. We just need Carl to release sources. Hopefully 
it happens till I retire :-) (eventual replies to REBOL3 group, just 
wanted my comments to be at one channel)
BrianH
12-Nov-2008
[3168]
Cyphre is a member of the development world for the new GUI.
[unknown: 5]
12-Nov-2008
[3169]
How many are working on REBOL3?
Pekr
12-Nov-2008
[3170]
1 - Carl ....
[unknown: 5]
12-Nov-2008
[3171]
;-)
Pekr
12-Nov-2008
[3172x3]
In the past, there were Gabriele and Cyphre. Gab did initial VID3, 
http protocol and maybe other things. Cyphre did View kernel things 
- e.g. whole compositing engine was replaced by the better one - 
AGG based ...
nowadays Henrik and BrianH are helping with VID 3.4.
uh, once again, I thought that I am in REBOL3 group ...
[unknown: 5]
12-Nov-2008
[3175]
heh.  We can move this there.
BrianH
12-Nov-2008
[3176x2]
Peta seems to have agreed with you, Chris, and changed the name of 
AND to AT. Things have settled down to grammar fixes.
Carl has been notified that the proposals seem to have solidified.
Steeve
13-Nov-2008
[3178x3]
what doest it mean Brian ? (to have solidified)
ah ok, you notified Carl, not he notified you
i hope he will keep some ideas...
BrianH
13-Nov-2008
[3181]
That would be nice. Check out the example at the end: No explicit 
failing, no position setting, no errors :)
Steeve
13-Nov-2008
[3182x6]
Brian, it seems that when a file is parsed instead of a sub-directory, 
then your script duplicate the previous sub-directory
except if change acts only when the nexrt rule is fullfilled (forget 
my remark)
it's a little be tricky to handle all the possible combinations, 
but the new commands seem really powerfull
i wonder if some CHANGE syntax combinations can be removed.
expecially those one with the post-rule modifier.

AT command should be enought to specify where the change must apply.

AT rule change value  ; to modify the index before the rule 
rule change value ;  to modify the index after the rule
and in your example, to return back even after the change.
at rule at change value
so that the CHANGE syntax could be simplified
BrianH
14-Nov-2008
[3188x2]
The AT is a separate operation that says "recognize this rule AT 
the current position but don't advance". AT doesn't specify a position.
The CHANGE syntax already has been simplified :)
Steeve
14-Nov-2008
[3190]
what do u mean ? I never said that AT need or specify a position.

My remark stay valid: change command syntax can be simplified but 
if you say that's already done. It's Ok.
BrianH
14-Nov-2008
[3191x5]
CHANGE basically needs the same information that the CHANGE REBOL 
function needs:
- A start series/position
- An end position or length
- A value to replace with
- Some options, if you need them

The CHANGE proposal has all those, and there isn't much more we can 
simplify it :)
The rule matching is a bonus :)
Kind of a necessary bonus though, since it lets you specify what 
you want to change. You need to have the change operation before 
the rule so you know where the rule starts and where it ends.
I mean that you have to have the change keyword physically before 
the rule is affects because all of the PARSE operations are prefix.
is -> it
This isn't my day :(
Chris
15-Nov-2008
[3196x2]
If I'm getting this right, OF is designed to do this:

	blk: [1 two 3.0]
	parse blk [of [integer! word! decimal!]]
	== true
	parse blk [of [number! word!]]
	== false (only accounts for one number)
	parse blk [of [word! decimal! string! issue! integer!]
	== true (can be none if a given type is missing)


I have another scenario to which the word 'of would apply.  There 
are situations where I want to match one item from a block of options. 
 Currently, those options need to be pipe-separated, requiring preprocessing 
if those options come from a data source (see languages: in my emit-rss 
script for an example).   This appears in both string and block parsing. 
 An example (using IN as the hypothetical operator):

	m28: ["Feb"]
	m30: join m28 ["Apr" "Jun" "Sep" "Nov"]
	m31: join m30 ["Jan" "Mar" "May" "Jul" "Aug" "Oct" "Dec"]
	b28: repeat x 28 [append [] 29 - x]
	b30: repeat x 30 [append [] 31 - x]
	b31: repeat x 31 [append [] 32 - x]
	parse date-str [
		in b28 "-" in m28
		| in b30 "-" in m30
		| in b31 "-" in m31
	]

This would be true for "1-Jan" "30-Sep" and false for "31-Feb".
Also, the way 'of works is a little like my 'match syntax (in QM, 
also designed for dialects), the difference being a resultant object 
instead of a block:

	match ["Click Here" #"h" http://click.here/][
		href: file! | url! | path!
		title: string!
		id: opt issue!
		class: any refinement!
		accesskey: opt char!
	]