On Wed, Aug 29, 2012 at 9:49 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote:
>> Please let us know what youd need to have it implemented within Guile,
>> or, even better, send a patch. ;-)
>
> Okay! Since we already have it implemented on *top* of guile, I have hopes
> that it'll be relatively easy to implement *in* guile.
>
>> I think Nala Ginrut once posted a patch that would allow read to
>> optionally recognize braces as delimiters. I guess thats a starting
>> point?
>
> Yes, { and } as delimiters makes the rest much easier.
Heya Ludo',
Regarding sweet-expressions, #-handling in Guile becomes
an issue.
Specifically, in our existing code on top of Guile, we had to
reimplement # handling to properly handle #| |#, #! !# and
#; comments.
Since indentation is significant in sweet-expressions, it
is necessary to ensure that a reader that finds a hash-based
comment does not consume any whitespace after the
comment, and should instead somehow signal the
discovery of the comment.
In our current code, the hash-handler returns an empty
list if it found a #||# #!!# #; comment, or returns a
singleton list with the item it found.
If Guile's hash-handling in its reader has a similar protocol,
then it can be adapted for use with the sweet-expression
reader.
Otherwise, if the hash-handling effectively tail-calls back
to the top-level read after finding a comment, then the
routine needs to be changed so that the sweet-expression
reader can use it (as otherwise there will be two
implementations of hash-handling).
Other than that, for now I don't know of what else is
needed on top of { }-as-delimiter and an alternative
entry point for handling hash objects on the reader.
Sincerely,
AmkG
