[REBOL] Re: parse question
From: joel:neely:fedex at: 27-Jun-2001 2:55
Brett Handley wrote:
> 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.
>
Ooops! Sorry! I intended it as a part of my "thinking
out loud" about "" vs. NONE! and not as an attempt to
describe your views.
> 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.
>
Hmmm. I gotta stop writing emails late at night! ;-)
By analogy, -1 is a legitimate integer, but one would likely
have problems trying to use it to PICK data from a series.
However, most uses one makes of string data accept "" without
complaint. That was the sense I intended.
> 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.
>
Agreed. And my view is that the second point you made has
a much higher priority than the first. It addresses both
consistency and learnability. (Not that you've ever heard
anything from me on those topics before... ;-)
Especially since PARSE really does know how to extract strings
of zero length in other settings:
>> addr2: "Joe Doaks/321 Hilltop Ln//Green Mtn/MA/02187"
== "Joe Doaks/321 Hilltop Ln//Green Mtn/MA/02187"
>> parse/all addr2 "/"
== ["Joe Doaks" "321 Hilltop Ln" "" "Green Mtn" "MA" "02187"]
> It needs to be said now, that this is only relevent to parsing
> string! values...
>
It seems that parse needs to be *able* to supply NONE! values
when appropriate, but I'm not sure I completely understand what
the phrase "when appropriate" might mean. Given that phone
data may or may not be available for all people, we could design
several possible representations of a data structure which
allows for the data-not-available case. For example:
When phone data is available (the easy case)
demo: [1234 "Ferd Burfel" #901-555-1212 127.0.0.1]
When it is not available, we can choose to
a) omit it
omed: [2345 "Joe Doaks" 127.255.255.255]
b) mark it with a special word
medo: [3456 "Jane Doe" none 255.255.255.255]
c) or mark it with a specific not-available value
odem: reduce medo
Assuming we're handling the simple case in the obvious way:
parse demo [
copy xID integer!
copy xName string!
copy xPhone issue!
copy xIP tuple!
]
... each of the not-available choices implies a different
strategy for block parsing.
parse omed [
copy xID integer!
copy xName string!
copy xPhone [issue! | none]
copy xIP tuple!
]
parse medo [
copy xID integer!
copy xName string!
copy xPhone [issue! | word!]
copy xIP tuple!
]
parse odem [
copy xID integer!
copy xName string!
copy xPhone [issue! | none!]
copy xIP tuple!
]
The programmer can choose which representation/parsing strategy
to use, because the block is probably a constructed artifact.
I think we're agreeing here; I'm just thinking out loud to
confirm that fact...
> 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.
>
Agreed. Especially if the change would help make the language
more attractive/understandable/usable to a larger audience.
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
