On 7/24/12, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Alan Manuel Gloria: >> Is it bundle time again?? >> Yes it is!! > > Excellent! > > This makes me think we need to rename some things. In particular: > readable sweet-impl > seems weird. That module implements not just sweet, but all the notations. > > How about naming "sweet-impl" to "kernel", so we can say: > readable kernel > I was going to use "base" (but it's not a number base) or "core" (but "core" > risks being deleted as a "core file"). Other name suggestions welcome.
Okay, give me a name when you've decided. I've decided that all name issues are color of the bikeshed issues and will not object, as long as they're not some kind of obvious profanity. > > Also, "restore-scheme-read" can't be right; they're all readers for Scheme. > How about: > restore-traditional-read > or some such? Fine by me. > > >> commit 5605bde7241b6601f4c16576ca96112f83b8cd39 >> Author: Alan Manuel K. Gloria <almkg...@gmail.com> >> Date: Tue Jul 24 06:10:42 2012 +0800 >> Use restore-scheme-read() to restore the Scheme reader. > > Hm, this means that merely *running* the sweetener will require the > "readable" library to be available, even if it's first translated into > traditional s-expressions. Well, you could make the sweeten.sscm into a proper Guile module, export an interface function, and then we can do the restore-traditional-read() in the invoking script. In fact, if eventually our reader supports Guile-style multiline comments #! !# we can just put something like this at the start of sweeten.sscm and rename it directly to sweeten; it has the advantage that the module itself won't require (readable color-of-the-bikeshed-issue): #! /bin/sh MYDIR = `dirname $0` exec env GUILE_LOAD_PATH=$MYDIR guile -q -c "(begin (use-modules (readable color-of-the-bikeshed-issue)) (replace-read sweet-read) (use-modules (sweeten)) (restore-traditional-read) (iformat-filter))" !# define-module (sweeten) :export \\ (iformat-filter) ... > > This means that, until our neoteric-reader (modern-reader) supports the #' > in guile, we will not be able to enable the guile debugger to trace the > sweetener. It also may complicate the later implementation of > Scheme-in-web-browser sweeteners. > > I guess supporting #' would be a good idea anyway, so that should be > short-lived. Maybe I can talk you into adding support for #' so that we can > do: > (use-modules (ice-9 debugging traps) (ice-9 debugging trace)) You can't talk me into doing that. What you can talk me into doing would be to add another hook into the portability layer so that process-sharp can have a readtable of sorts, with the portability layer providing that readtable or some such. *Then* maybe I'll implement #' in Guile's portability layer. (^^) --- You know, I think the internal interface from sweet-read to modern-read/curly-infix-read should be modified again. The problem is handling of multiline comments: either SRFI-30 #| #|nested|# comments|# or Guile's interpretation of #!, depending on the Scheme implementation's preference. (IIRC some other Schemes treat #! as a line comment, not a multiline comment) But practically all multiline comment systems in all Schemes use # - there's even a common #; extension that comments out the next term. And currently process-sharp can indicate an object, *but it can't indicate the **absence** of an object*. Perhaps, internally, modern-read, when invoked by the internal function available only to sweet-read, can return either '() or singleton list containing the read-in object. Let's call this modern-try-read. Then modern-read-func simply invokes modern-try-read repeatedly until it gets a non-null list, and extracts its contents. This internal change in interface will propagate all the way down from process-sharp up to readitem I think, though. readblock would need to be more careful - if readitem returns null, it must act as if it found a whitespace. 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
