[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"...
Yeah...
> >
> > > 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.