On Wed, Jul 25, 2012 at 8:26 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> Alan Manuel Gloria:
>> So... no more unread-char? Do I remove the unread-char impl as well
>> as the 2nd char buffer on R5RS compatibility layer?
>
> Yes, please do. That would simplify things, and it was the reason we
> switched to "!" as the non-whitespace indent character.
>
> On a related note: I started to implement a # readtable. I used a
> guile-inspired interface:
> (readable-read-hash-extend chr proc). HOWEVER, the "proc" routine needs
> access to the my-read-char. I hate to export that as well, though we can if
> we must. Is there another way to do what's needed, now that we don't need
> unread-char?
Err, probably not the best way to do so IMO. I think it's best to
create a per-Scheme-implementation method of extending the reader, and
have that wrapper unwrap the port properly.
But you know, if {read eq? sweet-read), then a recursive call from a
readtable-function into read will result in a horribly confused
sweet-read parser, because sweet-read expects to be invoked on a fresh
line, but the readtable function will (probably) invoke it on the same
line that it was itself invoked on. So readtables need to be
rethought in a sweet-expression environment.
Anyway IMO...
Add something like this to the compatibility layer documentation/comments:
; (implementation-parse-hash top-read char fake-port)
; - A function that is invoked when an unrecognized (non-R5RS) hash-character
; combo is found in the input stream.
; - This function is passed a fake-port: use my-read-char and my-peek-char.
; - If your function needs to parse a datum, invoke top-read with the given
; fake-port. Do NOT use any other read function. The top-read function
; passed in expects a "fake port" as wrapped by your implementation
; compatibility layer.
; - The top-read function is either a version of curly-infix-read or a version
; of neoteric-read that accepts a fake port. It is never a version of
; sweet-read.
; - The # and the character after it have been read in on the given port
; by the time this function is called.
; - This function returns one of the following:
; #f - the character after # is invalid.
; () - the character indicates some kind of comment; the comment
; has been removed from the output stream.
; (a) - the read in datum is a.
Then the Guile portability layer would adapt this call to
read-hash-extend - it would unwrap the port.
------
If you prefer to use readable-read-hash-extend, then use (invoke-read
(lambda (real-port) (selected-hash-extend-function chr real-port))
port), where selected-hash-extend-function is the hash-extend function
you selected, chr is the character read in. invoke-read is supposed
to do the unwrapping of fake ports to interface with "real" readers.
But I think it's not the best way to do it. On Racket readers accept
0, 1, or 2, arguments. The 2-argument case is an argument of port and
an argument of the *current* source location - the intent is that the
Racket compatibility layer will wrap the port and source location into
a fake-port. invoke-read will then expect that the given reader can
accept 2 arguments: a real port and the source location at that point.
Anyway, I suggest passing hash-extensions via the compatibility layer
- extending the reader is outside the scope of R5RS, and I'm afraid of
getting too tied to a specific implementation.
Sincerely,
AmkG
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
