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

[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] When it is not available, we can choose to a) omit it omed: [2345 "Joe Doaks"] b) mark it with a special word medo: [3456 "Jane Doe" none] 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