Alan Manuel Gloria: > > About the portability layer, I have planned the following set of API > > between the portability layer and the rest of (readable-discuss impl): > > > > ; the portability implements its own port objects. On R5RS we > > ; need to add 1 more lookahead character (current implementation > > ; requires 2 lookahead characters). In addition, we need to keep > > ; track of our own source information using our Port on Racket > > ; and possibly other Scheme's. > > my-peek-char :: Port -> Char > > my-read-char :: Port -> Char > > my-unread-char :: Char -> Port -> void
Okay so far. > > ; Port keeps track of current source location, as wrapped > > ; by make-reader below. In Racket we must keep track of > > ; source information ourselves, possibly on other Schemes. > > get-sourceinfo :: Port -> SourceInfo > > ; SourceInfo may be attachable to some objects, depending > > ; on Scheme implementation. Implement as weak-key-tables on > > ; Racket and Schemes that support both SourceInfo and weak-key > > ; tables. That's how Guile does it internally, BTW, and is the reason > > ; why symbols can't have source information. > > attach-sourceinfo :: SourceInfo -> Object -> Object > > ; construct an implementation-compatible reader from a basic function that > > ; accepts a port and returns a basic object. On Guile, the identity > > function. > > ; On R5RS wraps the port with an additional 1-character lookahead buffer. > > ; On Racket, return a function that either (1) gets 1 argument and returns > > ; the object, or (2) gets 2 arguments and returns a syntax-object, as > > specced > > ; in the Racket specs. The Racket version will need to attach the > > ; associated source info to each weak-keyed object in its table > > ; when building the syntax-object, for example. > > make-reader :: (Port -> Object) -> Reader > > ; invoke a given implementation-compatible reader, using the port as > > ; implemented by the portability layer. Probably needs to be really careful > > ; about the 2-character lookahead thing, hmm. > > invoke-reader :: Reader -> Port -> Object Hmm. I haven't delved into how implementation track the source information. This *seems* reasonable enough. But I think a lot of this should be internal to the implementation and *not* visible outside the module. Otherwise the interface can become complex, and I think that'd expose too much to the outside. I think it's really important that we have an implementation that does NOT require knowing the innards of source location tracking. That will make it easier to port to other implementations, as well as to create a SRFI proposal. There may be a better way, but this approach seems to do that. > > Actually, I'm not sure if the make-modern-expr-parser function exports > > are actually *feasible*. The current implementation of the constraint > > on indentation as whitespace requires 2 character lookahead; it can be > > eliminated only if we change the interface of modern-expr when called > > from sugar-expr. Again, if we have a richer internal function and make this all one module, we can easily do that - just have a private interface for modern-expr. But I think all modern-expr needs is the ability to read the unread char; that's straightforward enough. --- 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
