Comments on: PARSE: split the function?
As you know, parse has two modes:
- A major-mode: parse according to BNFish rules specified in layered blocks. Returns TRUE or FALSE.
- A mini-mode: split a string according to simple delimiting rules. Returns a block of results.
The second is a shortcut for very common types of string delimiting, such as CSV. In fact the first can implement the second.
It has been suggested that these two behaviors do not belong in the same function. An important point is that they return different types of results.
This change is not difficult, other than picking a new name. In fact, the new function could be a mezzanine, not a native.
I want to poll the userbase to determine the level of interest in this change.
I agree. It's a cryptic way to split a string. Besides we already have a SPLIT function in R3.|
Because I didn't know about split, I suggested lexify which seemed terminologically correct.
But split is less esoteric and looks like it does the same thing! Hm, why didn't I think of that word.
Will call out one thing I learned while making USCII, which was the control codes in ASCII for building hierarchical records. You can find them starting at 28:
There's "File Separator, Group Separator, Record Separator, and Unit Seperator". Pictorally, I went with comma for unit separator, and line feed for record separator (because that matched history). I'm open to suggestions on File/Group.
It seems that if you really wanted to do something special and interesting for strings that were delimited, you might want to offer structure. That could impress the pants off of some people.
But if such an exercise is beyond the scope of what you're interested in, I say drop the functionality on parse and stick with split. That's a nice abstraction.
+1 keep split, dump parse minimal.
all R2 scripts have to be rebuilt anyways... no point in trying to keep compatibility.
I've had to build my own CSV converters anyways cause the simple parse ... well ... mileage may vary.
By the way, one thing is that having a binary result means you have to jump through hoops to determine where the parse stopped if it failed. This makes it hard to give a meaningful error.
An easy fix to this would be to offer a /position refinement, which returned the position the parser was at when it was done. Then you could say:
pos: parse/position input rules
if pos == tail pos [
print rejoin ["Parse failed at: " mold pos]
(You'd have to compare to tail pos and not tail input if you allow series switching.)
I would drop the minimal parse mode in favor of better split function.
Also the Hostile's /position refinement looks useful, if it's possible.
BTW: in REBOL we have tail? action so we can write:
print either tail? pos [
["Parse failed at:" mold pos]
Thanks for the tip, Oldes. Always seems to be a shorter way to write things.
I do realize that returning a position contradicts the "always returns true or false" argument I made earlier for one of the reasons minimal parse seemed iffy. But somehow, having the refinement being the name of the return type helps it be more obvious.
Always returning a position could work too, but looks a little awkward in the average case:
print either tail? parse input rules [
So much of these decisions remind me of the "Quality" concept Robert Pirsig described in Zen and The Art of Motorcycle Maintenance.
I notice that the "split" functionality is still in PARSE, which is confusing now that /all is the default behavior for block-form rules. As an example of the misunderstandings, see RebolTutorial's StackOverflow question on the topic:
It's been a while since this was brought up and not too many comments. Still, does anyone see a reason why split functionality and the /all refinement shouldn't be dropped from parse entirely in Rebol 3?
"Still, does anyone see a reason why split functionality and the /all refinement shouldn't be dropped from parse entirely in Rebol 3?"
Because both are used a lot, still. Even in mezzanine code in R3. And if simple parse will do the job for you, it will do it much more quickly than the rule-based variant.
"Because both are used a lot, still. Even in mezzanine code in R3."
Above, the 4 Rebol programmers besides you and Carl have said the legacy isn't important enough to not redefine split. The question from Reboltutorial shows the liability of parse/all.
I can't imagine the mezzanine changes would take more than a moment of your time.
Post a Comment:
You can post a comment here. Keep it on-topic.