Re: peek/poke
Brian Broker wrote:
>On Mon, 27 Mar 2000 17:54:29 -0500, Everett Williams wrote:
>
>>Since we both know that sequences are essentially infinite in structure and
>>length, what does happen when you poke s where s ={"xxx","yyy","zzz"}.
>>Yes I know it can be checked, but it is anything but clear from the manual
>>what would happen in this situation, much less more complicated ones.
>>The examples carefully shy away from anything complex, and the definition
>>does not rule them out. I'll pull out one of Knuth's most famous quotes
>>about a piece of code that he had sent to another person. "I've only
>>proven that it is correct, not tested it." Yes, we do have to try things,
>>but it would be nice if the manual gave us a few clues ahead of time.
>
>Personally, I prefer documentation that tells me what a routine CAN/WILL
>do, not a slew of info about what it CAN'T do (because, quite frankly, it
>would either confuse me or bore me). In the particular case of your
>example, I would assume that we should get an error (the procedure can be
>passed a sequence, not a sequence of sequences, or nested sequence, or
>whatever else you want to throw at it). The documentation 'shys away from
>anything complex' because it's not supposed to be complex. Would you
>rather see a list of examples that would be considered ERRORS? I know I
>wouldn't for the reason's mentioned above. I suppose that the documentation
>could be a bit more specific in this case:
>
>instead of just:
>If x is a sequence, write a sequence of byte values to consecutive memory
>locations starting at location a.
>
>add the following note:
>NOTE: Sequence to be poked must only contain atoms.
>
>(Which happens to be the error message you get if you try your example.)
>
>Simply put, in this case, it wouldn't even occur to me that I might be able
>to do what you suggested; it just doesn't make sense in the context of the
>procedure definition. Of course, people who want to think outside of the
>box will receive an error that points to the faulty line of code and a
>clear description of the problem with that code.
>
>...poketest.exw:14
>sequence to be poked must only contain atoms
>--> see ex.err
>
>where line 14 is:
>poke( a, {"xxx", "yyy", "zzz" } )
>
I knew how to test it, and my statement was that I should not have to,
to learn the basic limits of the procedure. You may note that the original
question about non-atom sequences was Kat's, not mine. I was
attempting to answer her question by perusing the manual. Sometimes
a definition is more easily closed by inclusion, sometimes easier by
exclusion. Whichever way is simplest, is sufficient. Your solution was
by inclusion for this procedure and it appeared to be complete. Others
might need different techniques. The error routine suggestion was not mine,
but ripped from dozens of manuals that I have seen that use that technique.
As for an example of a poke of the form that you say makes no sense,
what if I wanted to poke a series of lines from an editor contained as
subsequences within a sequence. List items are another possibility.
Since poke only takes one byte from each atom, it readily fits with the
model for expression of strings in memory. Seems logical to me. Maybe
you don't do things like that.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
