* Tim Bradshaw | It does? I can find no mention of a case where READ returns zero values in | the entry on it in the spec. Do you mean that the reader macro function | should return zero values?
Yes, that was what I meant. My bad. But sadly, this goes to show my main point, that the support for using `read´ in its own (re)implementation is insufficient. You need to get below the values returned by read to be able to capture the return value of reader macros.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Tim Bradshaw <t...@cley.com> writes: > * Erik Naggum wrote:
> > We have the following situation. After a token has been read, you > > are either looking at a terminating macro character or a > > non-constituent character such as whitespace. This is an > > invariant. Before you read a token, you skip any whitespace. > > This is an invariant. So you read the token. If that token is > > the consing dot, you read the next token and should now look at > > the closing paren. You interpret and add the last read token to > > your list in the appropriate manner and continue or return as > > appropriate.
> Ah, I think I see where we are talking at cross purposes. I think > that you are assuming that I'm doing this the proper way - namely by > reading tokens and looking at what they are. But I'm not, I'm trying > to glue something together out of READ and bits of string. In > particular I don't have a token reader, I just have READ. So I'm > improvising a token reader which will essentially *only* spot the > consing dot token, and if it does not spot that it will leave things > such that I can then just call READ to get whatever is actually there. > And it's in the implementation of this that I need to look for > whatever follows the possibly-consing dot and worry about whitespace.
Instead of digging into the details, try looking at what you are in fact trying to accomplish, which is to implement READ using READ. Now think about recursive algorithms and termination rules...
> I realise that this is not the right way to do what I'm trying to do, > but I wanted to see if I could do it without either implementing a > token reader from the spec, or finding the system's one.
But you _are_ using the system's one, since you are using READ.
Duane Rettig wrote: >>whatever follows the possibly-consing dot and worry about whitespace.
> Instead of digging into the details, try looking at what you are in > fact trying to accomplish, which is to implement READ using READ. > Now think about recursive algorithms and termination rules...
hint: the result in less than 10 lines of conforming code
>>I realise that this is not the right way to do what I'm trying to do, >>but I wanted to see if I could do it without either implementing a >>token reader from the spec, or finding the system's one.
> But you _are_ using the system's one, since you are using READ.
i think he meant finding the systems *token* reader.
ilias <at_n...@pontos.net> writes: > Duane Rettig wrote: > >>whatever follows the possibly-consing dot and worry about whitespace. > > Instead of digging into the details, try looking at what you are in
> > fact trying to accomplish, which is to implement READ using READ. > > Now think about recursive algorithms and termination rules...
> hint: the result in less than 10 lines of conforming code
Show us that result and we'll be happy to critique it for you.
> >>I realise that this is not the right way to do what I'm trying to do, > >>but I wanted to see if I could do it without either implementing a > >>token reader from the spec, or finding the system's one. > > But you _are_ using the system's one, since you are using READ.
> i think he meant finding the systems *token* reader.
Precisely what I said. READ _is_ the system's token reader.
>>>>whatever follows the possibly-consing dot and worry about whitespace.
>>>Instead of digging into the details, try looking at what you are in
>>>fact trying to accomplish, which is to implement READ using READ. >>>Now think about recursive algorithms and termination rules...
>>hint: the result in less than 10 lines of conforming code
> Show us that result and we'll be happy to critique it for you.
coming soon. i'm not ready to try. 10 lines: intuitive 'guess'.
>>>>I realise that this is not the right way to do what I'm trying to do, >>>>but I wanted to see if I could do it without either implementing a >>>>token reader from the spec, or finding the system's one.
>>>But you _are_ using the system's one, since you are using READ.
>>i think he meant finding the systems *token* reader.
> Precisely what I said. READ _is_ the system's token reader.
pseudocode:
function token-reader (argument: stream) returning token function object-creator(argument: token) returning object function read (argument: stream) returning object
* Erik Naggum wrote: > Yes, that was what I meant. My bad. But sadly, this goes to show my main > point, that the support for using `read´ in its own (re)implementation is > insufficient. You need to get below the values returned by read to be able > to capture the return value of reader macros.
Yes. I've spend some more time thinking about this and I think it is absolutely essential that you (not `you, Erik' but `you, someone who wants to do this') implement the actual reader algorithm to do this: there are no shortcuts. In particular you have to consider readmacros, but there are other things too. Fortunately there is a good description of the algorithm!
I have an implementation of RDF which I think almost works now, and it essentially does that, with some cheats. But it's very hairy, it doesn't work on at least one implementation (due I think to stream handling bugs in that implementation although I'm not sure), and it has at least one potential bug and one actual bug. The actual bug is that it doesn't handle the #n# and #n= macros, because it doesn't know how to set up the context for them - so it only works if it's called within an outer READ (which is actually oK). Almost all the hair and bugs are because you can't (in the standard language) get at the point just before a token is made into an object and look at what is there. (And no, I'm not going to post it, it's too embarrassing.)
So I'd really like it if implementations made READ-DELIMITED-LIST support dotted forms, probably with an extra option to do so so they remain compatible.
I'd also like the ability to intervene at the token->object stage, but I don't have any idea what a (sub)standard way of doing that would look like.
* Duane Rettig wrote: > Instead of digging into the details, try looking at what you are in > fact trying to accomplish, which is to implement READ using READ. > Now think about recursive algorithms and termination rules...
yes, I have termination. I don't (even in yesterday's version I didn't) *just* use READ, I do other things and then, perhaps, call READ.
> But you _are_ using the system's one, since you are using READ.
yes, but not directly - by the time READ has done its thing it's way too late. That's what the `other things' above do.
> Not confusing, just confused :-)
No, I don't think so. I *was* confused, but I realised before yesterday's article that you couldn't just do what I was originally trying to do and I was trying (in a confusing way, I agree) to explain one of the reasons why the naive technique can not work.
