On Fri, Jul 20, 2012 at 11:00 PM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > 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.
Yes, that is indeed the plan. But of course, the part inside the cond-expand needs to have some common interface across different cond-expand branches. So this API is completely internal to the module, but must still be documented so that porting efforts have something to focus on. > > 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. Yes, so the cond-expand gets a default branch that just makes dummy functions for get-sourceinfo and attach-sourceinfo. When not specifically ported, the implementation will still work but not provide source information. When specifically ported, then it *should* gain source information tracking, since that is expected to be the core of the porting effort. > >> > 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. Not if the indentation tracking finds a ".", then fails to see a tab or space after it. Then it's forced to have 2 characters overhead, which the modern-expr reader must read back to find the symbol or number that begins with "." 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
