On 7/20/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> On Fri, 20 Jul 2012 00:37:57 +0800, from Alan Manuel Gloria:
>> bundle bundle!
>
> Awesome.  Reviewed, accepted, pushed.
>
> More tests == more goodness, and I am *REALLY* glad to be rid of the ugly
> function clean().  I'm sure more code cleanups would help, but that's a big
> step forward.
>
> And speaking of code reorganization...
>
> Currently the Scheme implementation is three files (modern.scm  sugar.scm
> sweet.scm).  I think it might be better to merge it all into a single file
> (module), where you can then "enable" or "disable" curly-infix,
> modern-expressions, or sweet-expressions.  Then separate files can auto-load
> & enable them.  It'd be easier to work with - in particular, easier to shim
> in a portability layer - and it'd help it get ready for an eventual SRFI
> submission.
>
> What do you think?
>

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

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