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

[REBOL] Re: parse question

From: brett:codeconscious at: 27-Jun-2001 16:20

Hi Joel,
> I must agree with Graham on this one. A zero-length string > is a completely legitimate value, but most definitely is *not* > the same thing as NONE!
You're phrasing runs the risk of implying I stated otherwise - which is not the case. Though now you've piqued my interest - what is value that is not completely legitamate - illegitmate or partially legitimate? Are they something like complex numbers - a real part and some other part? Just kidding.
> I think he meant "sets variables to string! values using > COPY" instead of "returns"...
> > > > > shouldn't > > > > > > parse {a=""} [ thru {a="} copy test to {"} ] > > > > > > 'test now be an empty string rather than type none! ? > > > > > > > I guess is depends on how you see it, either as "nothing to > > copy" (none!) or "copied a string of zero length" (empty). > > Also, I don't see that it makes a lot of difference - except > > for perhaps some more if statements in some circumstances. > > > > Any time you wish to build a new string from the parsed > substrings, or print their content, you have a problem with > NONE! instead of an empty string. For example, given: >
.. <snipped useful parse tutorial material> ..
> I've done a tremendous amount of text-flogging over the years, > converting address lists, reformatting data files among a > variety of representations, etc. In such applications, it's > very common to parse out the pieces of one format and > immediately construct a new string or write/print using some > combination of the just-parsed text fields. > > Yes, I know it's possible to follow the PARSE statement with > a list of "fix-the-empty-strings" statements, as in
<snipped more useful tutorial code>
> (or even to make a fix-up function and call it on all of > the fields), but all that bother hardly seems in keeping > with "make easy things easy and hard things possible" IMHO.
Well you've fleshed out the circumstances I referred to. I agree that if parse behaved the other way your example and similar code would be far simpler. It would be more elegant in the sense that when parsing strings one only would need to think of strings "containing" substrings and strings of zero length. So yes I guess it does make a difference, because currently parse sort of "implies" none! is part of the string being parsed - which is inconsistent with the knowledge that strings should only contain character values. It needs to be said now, that this is only relevent to parsing string! values. When parse is applied to a block! value an empty string is a completely legitimate value of a block. So are empty blocks. So parse still needs to set a variable to NONE! during a COPY when parsing a block otherwise we lose information. So how many scripts would such a change break? Maybe not many, but it would be a bit like y2k, you have to do a lot of hunting to determine the impact. Would I support the change? - yep. Brett.