Alan Manuel Gloria:
> >> 2. Convert sweet.g's actions from Java to Scheme (or better, provide
> >> some sort of automated conversion from sweet.g's actions to Scheme, we
> >> don't need a complete conversion, I assume your list() etc. functions
> >> just need to be converted to s-exprs
...
> I mean auto-converting just the actions, like so:
Oh, I see! That's easy. I think I can whip up a perl script to do a
reasonable job, I specifically wrote it to be as similar-as-possible to Scheme.
> Calling convention also needs the inputs to the procedures (indent
> level for head, rest, etc.), and the why-stopped needs to be specified
> precisely too.
Once the spec settles down, I plan to start doing that. I expect it to be
really easy for the most part. And we need to make clear that these are just
one way to implement them; as long as it's implemented correctly, we don't care
what their internal calling convention is.
> Also: signalling success and failure to parse?
That one is admittedly trickier. The "reason to stop" could allow 'error
everywhere, and then the top-level could just consume to a blank line and try
again. I don't think we want to *specify* a particular recovery mechanism.
> SRFI allows:
>
> "5. An outline of how it might be implemented. This should be
> considered a last resort, and in this case the rationale for the
> feature must be stronger. "
>
> sweet.g is already an outline of how it might be implemented; we just
> need a stronger rationale (^^).
>
> I suspect it can be argued that we're using reasonably well-studied
> parsing tech here, and that the translation from a parser spec to
> working Scheme code can be done mechanically (except the productions
> will probably get shifted all over the place if done mechanically), so
> that "the spec is the implementation", and that after the spec itself
> is reasonably stable we can start writing a sample implementation that
> can work.
I think we need to not COMPLETE the SRFI until we have a full implementation,
but I suppose we could start the SRFI process & then complete the
implementation.
> >> Ara ara, so I guess that means we might need to change t-expr calling
> >> convention in order to properly receive a current indent, and just
> >> wrap it with a default current indent of "".
> >
> > Why? The only time t-expr is called is when the current indent is "".
>
> Hmm. Okay, now I'm really confused. There's a "comment_eol
> restart=t_expr" bit here:
>
> > | (GROUP_SPLICE | scomment) hspace* /* Initial; Interpet as group */
> > (group_i=it_expr {$v = $group_i.v;} /* Ignore initial GROUP/scomment */
> > | comment_eol
> > (indent g_body=body {$v = $g_body.v;} /* Normal GROUP use */
> > | same ( g_i=it_expr {$v = $g_i.v;} /* Plausible separator */
> > /* Handle #!sweet EOL EOL t_expr */
> > | comment_eol restart=t_expr {$v = $restart.v;} )
> > | dedent error ))
>
> So, this pattern should trigger it:
>
> foo
> ! \\ ; comment_eol
> ! ; comment_eol
> bar
No, in that case the ;-only line is skipped, and the next line would insert a
DEDENT before bar.
That pattern would become:
n-expr(foo) comment_eol
INDENT GROUP_SPLICE comment_eol
(skipped line)
DEDENT n-expr(bar) comment_eol
The DEDENT would hit the explicit "dedent error" case, not the comment_eol case.
The only way you can have "comment_eol same comment_eol" is when you start on
the left edge; anywhere else you'd have DEDENTs generated between the EOLs.
> But I don't understand what exactly gets returned here. Why does it
> recurse to t_expr at this point?
The issue is, what if a user decides to put "#!sweet" or "#!/usr/bin/guile" or
similar at the top of the file, followed by 2+ newlines?
The user doesn't expect that "#!sweet" (or similar) are going to disable
sweet-expression capabilities such as initial indents.
> Or am I completely misunderstanding it_expr??
No, this is the weird special case I posted about earlier. It's pretty cleanly
handled though (in my opinion).
> >> Looks like a complete rewrite of the code (^.^)v
> >
> > That's good. Have you SEEN that code? :-) :-) :-).
>
> I deny ever seeing it! (~.~);;;;;;
:-).
> > In all seriousness, it's actually a rewrite of just a few procedures, and
> > we can reuse lots of pieces (I used the original Scheme code to help
> > develop the BNF). The result will be MUCH cleaner; the current code hacks
> > around several situations that the new code handles cleanly. No more
> > "readblock-clean" and "readblock-clean-rotated", whose purpose was NEVER
> > obvious from the BNF. It'll just be a relatively short list of procedures
> > whose names and functions obviously map to the BNF.
It might be better to just implement it in Scheme, or at least start to do so,
before starting the SRFI process. If there are problems implementing in
Scheme, we'd want to know NOW, and it is *supposed* to be easy. And since I
plan to make the Scheme code essentially a 1-to-1 match to the BNF, if the BNF
does change, it should be easy to change the code to match. The advantage of
using ANTLR is that ANTLR can do lots of checks and visualizations, helping us
to produce a really clean final result.
--- David A. Wheeler
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
