On 2/19/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> I've improved the Scheme sweet-expression implementation and test suite
> further;
> here's a summary. It's working well overall. However, in the process of
> adding lots of tests
> I've identified a subtle bug in the Scheme implementation THAT isn't in the
> ANTLR implementation.
> If anyone wants to help identify the problem or solution for that bug (see
> below) that'd be great.
>
> Anyway...
>
> The Scheme implementation now accepts #!+space as a SRFI-22 comment to EOL,
> #!/ ... !# and #!. ... !# as non-nesting multi-line comments, and
> #!directives
> (#!directives must begin with a letter). These were mentioned in SRFI-105,
> and are documented as SHOULDs in the draft SRFI-sweet specification.
> In the Scheme implementation a #!directive currently just reads up to a
> whitespace (or EOF) and throws away the text; that is obviously
> imperfect, but it is better than what we had before and gives us something
> better
> to work with. So finally #!sweet isn't an error :-).
>
> The Scheme implementation also now accepts #u8(...) syntax.
>
> I've added a large slew of tests for the Scheme implementation, and in the
> process
> also fixed a small bug combining <*...*> and improper lists
> (now <* a . b *> works as expected).
>
>
> As I mentioned above, there *is* one bug I know of. It appears to involve
> an interaction
> between <*...*> and multiple sublists when "*>" is after other things.
> Again, if someone would help me track this problem
> down (at least its cause) that'd be great. It's in "tests/sweet-testsuite",
> search for FIXME;
> it is currently commented out since it's known to fail. The test case is:
>
> let <* x $ cos $ f c *>
> ! dostuff x
>
>
> That SHOULD produce (as the ANTLR implementation does):
> (let ((x (cos (f c))))
> (dostuff x))
>
> However, the Scheme implementation incorrectly returns:
> (let (x (cos ((f c))))
> (dostuff x))
>
>
> Interestingly, the Scheme implementation works just fine with:
> let <* x $ cos $ f c
> *>
> ! dostuff x
>
>
> I don't have time to track down that bug for now. If someone wants to start
> (and at least
> post some hints, doing that many eyes thing) that'd be awesome.
Going only from your previous source descriptions (I don't have access
to my hack machine right now), it feels like the problem is with
propagating upwards the monadic fail operation ("failed due to *>")
from the lower level SUBLIST handling.
I assume that your top-level t_expr correctly handles the *> case and
correctly passes it upwards; I think it's the lower levels which fail
to correctly handle *>. That's why *> on a line by itself is
correctly handled (SUBLIST handler sees EOL-SAME, so it closes its
list correctly, and then t_expr sees the *> and acts as if it found an
EOF and propagates the failure upward).
For the *>-at-eol case, I suspect your SUBLIST handler handles it too
greedily and fails to propagate the *> upward.
$0.02
(yeah, I just gotta insert "monad" somewhere when discussing parsers)
Sincerely,
AmkG
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
