Alan Manuel Gloria: > 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.
Moving them to a subdirectory is fine. We need to have *REALLY GOOD NAMES* for the public interface. Good names make all the difference for ease-of-use. For example, don't use the name "readable-discuss" - that's the mailing list name, not the group name, and it's long anyway. But "readable" as a module name might work. Anyone have a better idea? Where practical, the new structure should strive to ease porting. We also want it to be trivial to install (eventually I want to get it into the guile distro itself, for example). And I want to submit this as an SRFI eventually. > So, let me consider first the module structure: > > define-module > ; contains the implementations. > (readable-discuss impl) s/readable-discuss/readable/. > :export > \\ > ; basic reader that support curly infix > curly-infix-reader ; :: Reader I presume this is just a "read one datum" function, right? If so, I don't like this name. If something is similar to an existing function, we should include that existing function's name. If this is just a "read" using curly-infix, its name should include "read" not "reader". In R6RS they've moved "read" to "Simple I/O", and have a new alternative name get-datum. We could also use the phrase get-datum, I guess, though I like "read" better (it's short and simple). I like the convention of putting the tier name in the function name. You've shown them prefixed; they could be suffixed, but I think they read better prefixed (since in English the adjective starts first), so I think that is sensible too. > ; creates a modern-expr reader based on the given input reader > make-modern-expr-reader ; :: Reader -> Reader This kind of "composition of readers" sounds overly complex, and not very likely to be really used. I would expect people to just select one of these three, and do: 1. "Read one datum" (which can be used to build up other things). E.G.: curly-infix-read, modern-read, sweet-read. 2. "Load a file with this notation" (easily built from #1, but let's make that easy). curly-infix-load, modern-load, sweet-load. 3. A way to "Switch my 'read' to this notation", e.g., for interactive use or for loading files. For the latter (loading files), it'd be nice to have a simple thing to say at the top to force the switch (if it hasn't already) so that the rest of the file could be interpreted that way. > ; creates a sugar-expr reader based on the given input reader > make-sugar-expr-reader ; :: Reader -> Reader Not so excited about this. I kept the "sugar" system separate because I thought we were just going to use SRFI-49 as-is, possibly with some bug fixes. Obviously that is NOT the case. While we *could* keep the "sweet" system separate and able to build on other things, I think it's not worth it. We already have a case (period-space indents) where it would be *useful* to have a special interface between the indentation processor and underlying modern-expression reader. So I think we shouldn't expose a separate indentation processor like "sugar". Instead, just expose the "sweet" reader, call it "sweet-read", and then users can easily use it. > ; > ; 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... Okay. Given the text above, to replace the reader I'd say: (replace-reader sweet-read) E.G., at the command line or at the top of the file. I think that "replace-read" would be a better than "replace-reader", since you are replacing the "read" function not the "reader" function. I'd document that this function would *also* replace the get-datum function, if there is one. I think there needs to be a public interface that retrieves the "old" read function, e.g., "old-read". That way, you can say: (replace-reader old-read) to get your old reader back. > define-module > ; contains an implementation of modern-expr + curly-infix > (readable-discuss modern-tier) This creates a lot of modules. I think we do NOT want a lot of modules, in fact, ideally we only want one. Modules are notoriously painful to port, they're not the same between Schemes (unless they implement R6RS modules). And we don't really need multiple modules; the names can easily include prefixes to determine which is which, and there's some interconnection between them anyway. > About the portability layer, I have planned the following set of API > between the portability layer and the rest of (readable-discuss impl): I'll need to respond to this part later...! > 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. If we make it one module, we can create private interfaces that resolve this. We don't need to create an indentation processor for anything other than modern-expressions; by definition, sweet-expressions include modern-expressions. --- 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
