Alan Manuel Gloria <almkg...@gmail.com>

> Okay, here's the public interface:

Overall that looks pretty nice.  Comments below.

> define-module
>   readable sweet-impl
>   :export
>   \\
>   . ; tier readers
>   . curly-infix-read ; :: Port -> Object
>   . modern-read ; :: Port -> Object
>   . sweet-read ; :: Port -> Object

Okay.  Presumably each of these reads one datum from Port, and returns the read 
object.

I think the Ports should be optional, just like read.  Or more accurately, 
there's a default Port of current-input-port().  Not sure how to notate that, 
maybe [Port] -> Object?


>   . ; replacement
>   . replace-read ; :: (Port -> Object) -> void -- replace the 
> implementation's reader

Okay.  This is an interesting generality, I had originally thought of 3 
reader-replacers, but I think your proposed interface is much better (it's much 
more general).

I think this needs to replace not just read(), but get-datum().

In short, people will do:
 (replace-read sweet-read)
interactively and life will be wonderful.

Would this also be placed at the top of files that use these notations?  It 
seems like we'd want a slightly different situation, since someone might want 
to load a file, THAT file would use some notation, but we'd want to restore the 
"old" one.  I'm not sure how to handle that cleanly. Maybe the best way is to 
have different file extensions (e.g., ".cscm", ",mscm", and ".sscm" and teach 
the loader to automatically handle the various cases).  Other ideas welcome.

>   . restore-default-read ; void -- restore the implementation's default reader

Okay.

I still think we need a function that invokes the old (saved) reader just once, 
so that people can briefly invoke it to read a few datums without trying to 
switch back & forth.  Perhaps saved-read or similar will return the old reader. 
Of course, with that you could just (replace-read saved-read) to restore the 
default reader.


I guess people can determine the current reader (if it's one of ours) by doing 
an "eq? read ..." 3 times, once with each of the readers.  Not sure that's a 
great way to do it; I sure feel weird doing eq? on procedures.  Maybe we need a 
simplified interface that can return 'curly-infix or 'modern or 'sweet or 
'other.

I think we need a variant of "load" that takes, as an argument, a reader.  
Obviously that's not hard to create yourself, but I want to be able to 
*trivially* read in a file with a given named notation. Maybe:

. load-using ; :: (Port -> Object) -> String -> unspecified 


>   . ; testing
>   . ; (compare-read-file foo-read "filename")
>   . ; open the file named "filename", and read each expression
>   . ; in the file using the implementation's default reader and the given 
> reader
>   . ; Returns three (values ...): The first it #t if the file is the same for
>   . ; both built-in and the given reader, the 2nd and 3rd are the top-level
>   . ; expression that failed to match, as read by the built-in (2nd) and
>   . ; as read by the given (3rd) reader.  On success the 2nd and 3rd
>   . ; values are just '()
>   . compare-read-file ; :: (Port -> Object) -> String -> (Bool, Maybe
> Object, Maybe Object)

>   . ; like the above, but just the given string
>   . compare-read-string ; :: (Port -> Object) -> String -> (Bool,
> Maybe Object, Maybe Object)

I'm not sure how important this one is, but okay.

> As for the internal portability API, I think I also need to provide a
> portable way to replace the reader - witness the hackery that goes on
> to "seamlessly" replace Guile's reader on 1.6, 1.8 AND 2.0.

Magic!

Thanks for working on this, it's very promising.

--- David A. Wheeler

------------------------------------------------------------------------------
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

Reply via email to