BTW, I'm creating a new subject line - the module interface is important, and we may want to go back to this discussion later.
My previous post outlined why I thought one module would be better (esp. for porting), as well as a discussion about the interfaces and names. I think there's an additional functionality we want: the ability to *easily* check a file to determine if its semantics change under the new semantics. E.G.: curly-infix-diffs(filename-or-filelist) modern-diffs(filename-or-list) sweet-diffs(filename-or-list) Would return the *differences* in the interpretation of the files (or file lists) between the respective readers and the "old" reader, or #f if there are no differences. Those differences could be because of bugs in our reader, a capability our reader doesn't support that their reader does, or because the file includes constructs that make them different. I think that people would feel more comfortable switching to these notations if they could easily check if a given file had differences in interpretation. --- David A. Wheeler >----- Start Original Message ----- >Sent: Fri, 20 Jul 2012 14:26:42 +0800 >From: Alan Manuel Gloria <almkg...@gmail.com> >Subject: Re: [Readable-discuss] Bundle of git changes > I think I want to reorganize them module's interfaces. > > And I think I want to put them in a readable-discuss subdirectory so > that module names are something like (readable-discuss sugar) or some > such. That will help making them easier to fob around in various > Scheme's package systems I think; certainly Guile would appreciate it > that way. > > So, let me consider first the module structure: > > define-module > ; contains the implementations. > (readable-discuss impl) > :export > \\ > ; basic reader that support curly infix > curly-infix-reader ; :: Reader > ; > ; creates a modern-expr reader based on the given input reader > make-modern-expr-reader ; :: Reader -> Reader > ; > ; creates a sugar-expr reader based on the given input reader > make-sugar-expr-reader ; :: Reader -> Reader > ; > ; replaces the current reader with the specified reader > ; in the best known way for the particular Scheme impl > ; you have > replace-reader ; :: Reader -> void > ... implementation elided... > > define-module > ; contains an implementation of modern-expr + curly-infix > (readable-discuss modern-tier) > :export > \\ > modern-reader ; :: Reader > use-modules > readable-discuss impl > define modern-reader make-modern-expr-reader(curly-infix-reader) > > define-module > ; contains an implementation of sugar-expr + modern-expr + curly-infix > (readable-discuss sweet-tier) > :export > \\ > sweet-reader ; :: Reader > use-modules > readable-discuss impl > readable-discuss modern-tier > define sweet-reader make-sugar-expr-reader(modern-reader) > > define-module > ; automatically enables modern-expr on future loaded files > (readable-discuss modern) > :export > \\ > modern-reader ; :: Reader -- re-export > use-modules > readable-discuss modern-tier > ; might need eval-when on Guile 2.0 or something > replace-reader modern-reader > > define-module > (readable-discuss sweet) > :export > \\ > sweet-reader ; :: Reader -- re-export > use-modules > readable-discuss sweet-tier > replace-reader sweet-reader > > ;;--- and so on.... > > > ------ > > > 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 > ; 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 > > --- > > 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. > > Sincerely, > AmkG > ----- End Original Message ----- ------------------------------------------------------------------------------ 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
