I said: > > How about naming "sweet-impl" to "kernel", so we can say: > > readable kernel
Alan Manuel Gloria said: > 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. Fair enough. I'll delay a little while to see if anyone proposes a better one (including me). > > 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. Okay, I've already changed it & pushed the change. > 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. Good point. I've been thinking about sweeten.sscm as an application, not as a library. But I guess that use would increase if people had easy access to a generator. So I think this would be the (readable sweeten) module. The fact that it's written in sweet-expressions presents a fun bootstrapping issue :-). > 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.... Cool. > > 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. (^^) Sounds good. > 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. Hmm. Once we invoke neoteric-read (nee modern-read), and it sees a nested comment, couldn't it just gobble it up & recurse until it *does* find something that's not whitespace? If we need to do this, we could certainly create a special internal function. We could cons up another unique object & return that as a "nothing read" symbol. But I hate to do that if we don't need to. --- 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
