Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Parse - Bug?

 [1/9] from: pwawood:mango:my at: 24-May-2005 9:50


When simply splitting a string including a "stand-alone" semi-colon, parse returned an empty block at the position of the semi-colon. It doesn't do this when it encounters a "stand-alone" tab or newline.
>> parse "this string includes a semi-colon ; <-there" none
== ["this" "string" "includes" "a" "semi-colon" "" "<-there"]
>> parse "this string includes a newline ^/ <-there" none
== ["this" "string" "includes" "a" "newline" "<-there"]
>> parse "this string includes a tab ^- <-there" none
== ["this" "string" "includes" "a" "tab" "<-there"] Is this a bug or a feature? Personally I would prefer it if "parse string none" left semi-colons untouched. Regards Peter

 [2/9] from: ammon::johnson::gmail::com at: 23-May-2005 19:18


Try... parse/all "string" none HTH!! ~~Ammon ;~> On 5/23/05, PeterWAWood <[pwawood--mango--net--my]> wrote:

 [3/9] from: pwawood::mango::net::my at: 24-May-2005 14:09


Ammon Thanks for the suggestion. I've worked out that if I use parse "string" " ^-^/" I get what I was expecting. The real issue with parse "string" none is the empty block that it returns when it finds " ; " in the string. It doesn't create and empty block for ^- or "^/". Regards Peter

 [4/9] from: SQLAB::gmx::net at: 24-May-2005 9:38


Hello Peter I think, this is a bug. If the semicolon is not a whitespace, then it should not create an empty element, but ";". If semicolon is treated like a whitespace, it should not create an additional element, but silently removed. AR PeterWAWood wrote:

 [5/9] from: pwawood::mango::net::my at: 27-May-2005 16:33


I submitted this to RT in Rambo (#3716) and it has been corrected in the latest View beta (114). Fast work!!! Regards Peter

 [6/9] from: SQLAB::gmx::net at: 27-May-2005 13:07


Hello Peter I don't think it is completely corrected See!
>> probe parse "this string includes more,,,,,,,,,,,,,,,, semi
white spaces ;;;;;;;;;;; " none ["this" "string" "includes" "more" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "semi" "white" "spaces" "" "" "" "" "" "" "" "" "" ""] AR PeterWAWood wrote:

 [7/9] from: pwawood::mango::net::my at: 30-May-2005 18:48


Hello Anton I submitted these problems to RAMBO. I don't know whether the fix will make View 1.3 though. Regards Peter On Friday, May 27, 2005, at 19:07 Asia/Kuala_Lumpur, SQLAB wrote:

 [8/9] from: gabriele::colellachiara::com at: 31-May-2005 12:15


Hi Peter, On Monday, May 30, 2005, 12:48:14 PM, you wrote: PWW> I submitted these problems to RAMBO. I don't know whether the fix will PWW> make View 1.3 though. Those are not bugs. The default behavior of PARSE string none (as stated in the manual) is to allow , and ; as default. It was designed to easily parse argument lists (like those passed in command lines) and CSV speadsheet files. -Carl Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [9/9] from: pwawood::mango::net::my at: 31-May-2005 19:07


Gabriele Many thanks for the explanation. It makes a great deal of sense in that context as it preserves the positions of "arguments/data":
>> a: parse "1;2;3;4;;;;;9;10" none
== ["1" "2" "3" "4" "" "" "" "" "9" "10"]
>> a/1
== "1"
>> a/9
== "9"
>> a/5
== "" I was parsing Rebol code, the empty block in the result was a nuisance. I solved my problem by not being so lazy and specifically "parsing" using space, tab and newline rather than none. I did check the user guide but didn't see any reference to the specific position preservation behaviour only : The parse function splits the input argument, string, into a block of multiple strings, breaking each string wherever it encounters a delimiter, such as a space, tab, newline, comma, or semicolon. The none argument indicates that no other delimiters other than these. User Guide 15.2 (Perhaps I was looking in the wrong place.) I also note that this behaviour seems restricted to commas and semi-colons:
>> parse "a^-^-^-" none
== ["a"]
>> parse "b^/^/^/^/" none
== ["b"]
>> parse "c,,,," none
== ["c" "" "" ""]
>> parse "d ;;;;" none
== ["d" "" "" "" ""] Regards Peter