World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
Gabriele 14-Mar-2006 [914] | this behavior is the one intended by Carl. so, it's so by design, and not a bug. but, you may try to convince Carl that you don't like it. ;) |
Oldes 14-Mar-2006 [915x5] | I still think it's a bug - I cannot see the diference between parse and parse/all in this example. If Carl don't want to fix it, no problem for me, I used more complicated rule to do the same thing, just still think, it's a bug and it will confuse more people in the future as well. |
but the true is, that in CSV is logical to have: parse {,d ,d} {,} == ["" "d" "d"] | |
and parse {,"a b, d" ,d} {,} == ["" "a b, d" "d"] (so probably Carl has true;-) | |
But it should be in documentation, that the quotes are very special characters for such a type of parsing! | |
There is also bug in doc: http://www.rebol.com/docs/core23/rebolcore-15.html (section 2 - Simple Splitting) -> there is sentence: "To avoid that action, you can use the /any refinement." where shoud be /all as there is no /any refinement in parse! | |
Graham 14-Mar-2006 [920] | oldes, rambo the documentation problem. |
Oldes 14-Mar-2006 [921] | done |
Thør 4-Apr-2006 [922] | . |
Oldes 28-Apr-2006 [923] | I think it would be good to have some standard place for common parsing rules and charsets used in parse rules, like 'digits, 'spaces' and other, what do you thing? |
Anton 28-Apr-2006 [924] | I like the idea in theory, but what are standard parse rules ? There's an argument already - look, I'm arguing ! :) I would prefer to call the "digit" rule "digits". Also, for this example, it's faster to define and be clear with it: digit: charset "0123456789" than being abstract: (even though it would become well known): digit: system/parse/rules/digit |
JaimeVargas 28-Apr-2006 [925] | Oldes a regex context will be a good addition. Where regex are the basic rules for numbers, white space, *words* and their negations. |
Oldes 28-Apr-2006 [926x5] | anton: I think, that any parse rule which don have to be global variable, but you can still the name used in parse block. But probably it would be a security issue |
regex would be very nice | |
the problem with the idea is, that we are mixing code and parse rules | |
but at least spaces and digits could be used - it means charsets - which could be available during parse without need to define it all the time | |
(but it was just the idea how to improve the 'parse function) | |
Anton 28-Apr-2006 [931] | Hmmm...... |
Gregg 28-Apr-2006 [932x4] | I've thought about that as well. There are some base charsets we could probably standardize on, and that would be good (IMO). Beyond a few basics, though, consensus gets tough. |
The singular/plural argument seems easy, but isn't (IMO); DIGITS could be done as SOME DIGIT, and you could argue that things like 2 DIGITS reads better, though 1 DIGITS does not. You could double-define it, but that gets ugly too. So, what about DIG? That doesn't imply any singularity, though it's a bit terse, and not a full word (or, rather, the wrong full word). | |
I'm all for proposing some basics though. Worst case, you can override them, which is no more work than we do today. | |
space/spc whitespace/wsp alpha digit(s) alpha-num ; should digit be num? ctl/control non-US-ASCII/high-ASCII quoted-string escaped-char ; what is the escape though; REBOL ^, C \, etc.? What other standard sets would we want? | |
Sunanda 28-Apr-2006 [936] | II was sure I'd posted this just after Oldes' message.....But it ain't there now.....Maybe it's in the wrong group) Andrew has a nice starter set: http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=common-parse-values.r And I know he has extended that list extensively to include things like email address and URL |
Gregg 28-Apr-2006 [937x2] | It would be great (again, IMO), if we had parse rules for REBOL datatypes. For those that want the power of block parsing, with the ability to load strings that aren't valid REBOL, it would be very handy. |
Good starter set! I forgot about that. Thanks Sunanda. | |
Graham 28-Apr-2006 [939x2] | the problem I find with block parsing is the rigid interpretation of datatypes. |
So, if Rebol gets the datatype wrong ( and real word data is dirty ), you're screwed. | |
Gregg 28-Apr-2006 [941] | That's the tradeoff. :\ |
Graham 28-Apr-2006 [942x3] | real world data is dirty .. |
Maybe there should be no invalid datatypes .... everything can be converted to a datatype | |
if the parser thinks a datatype is invalid, well, let's call it an invalid! datatype!! | |
Gregg 28-Apr-2006 [945] | I think that's where string parsing comes in, and where having rules for REBOL datatypes would ease the pain. |
Graham 28-Apr-2006 [946x3] | I do screen validation by datatypes ( for data input ). If the user enters an invalid datatype ... .. |
anyway, I think rebol should recognise all data .. | |
have a catchall for stuff it thinks is wrong | |
Oldes 30-Apr-2006 [949x2] | I agree with you Graham, I was mentioning this many times, that there could be something to handle datatype exceptions |
About the spaces charset - most people do not know that we have one more space char - non braking space: >> to-char 160 << | |
Volker 1-May-2006 [951x2] | How about another way: integrate datatypes in string-parser. Basically a load/next and check for type. Then we can write (note i parse a string): parse "1 a , #2" [ integer! word! "," issue! ] |
'invalite! has a problem: its easy to recognize where the wrong part starts, but harder to recognize where the wrong part ends. | |
Oldes 1-May-2006 [953x2] | Is there any RTF (Rich Text Format) parser for Rebol? |
hm, maybe this one: http://www.codeconscious.com/rebol/scripts/rtf-tools.r :-) | |
Ashley 24-May-2006 [955] | Quick question for the parse experts. If I have a parse rule that looks like this: parse spec [ any [ set arg string! (...) | set arg tuple! (...) | ... ] ] How would I add a rule like: set arg paren! (reduce arg) that always occurred prior to the any rule and evaluated parenthesized expressions (i.e. I want parenthesized expressions to be reduced to a REBOL value that can be handled by the remainder of the parse rule). |
Tomc 25-May-2006 [956] | I only parse strings not blocks so this may be compleatly off but I would try parse spec [ any[ opt [here: set arg paren! (change :here reduce arg) :here] [ set arg string! (...) | set arg tuple! (...) | ... ] ] ] |
Anton 25-May-2006 [957] | (here/1: do arg) |
Ashley 25-May-2006 [958] | Thanks both, works a treat. |
Graham 27-Jun-2006 [959] | My brain is still asleep. How to go thru a document and add <strong> </strong> around every word that is in capitals and is more than a few characters long? |
Pekr 27-Jun-2006 [960x3] | hmm, quite a challenge ... |
somehow to look-up words, mark: before, find its end (another space), check for if first is capital or not, change at position, :mark at end ... | |
but don't ask me for code, it would last few hours to get somewhere, if even :-) | |
Graham 27-Jun-2006 [963] | pattern search on capitals, mark, copy to space, mark, count length of copy, if long, insert at mark2, and then at mark1, continue ?? |
older newer | first last |