Alan Manuel Gloria <almkg...@gmail.com>
> Hmm. Okay, I propose this:
>
> 1. We give a set amount of time to play around with sweet.g, kick its
> tires, drive it around, try smashing some brick houses with it.
+1.
> 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. You could probably use (set! v
> (cons restart-tail rr)). Or just drop "v" completely.). Mostly
> because we'll be targeting SRFI, and I am more confident of acceptance
> if the SRFI's spec at least has some Scheme code.
I think the work to auto-convert would be *much* larger than just
hand-converting it to Scheme. Hand-converting this stuff is easy.
I rigged the BNF to be especially easy to implement using a recursive descent
parser. It's just LL(1). Also, several areas basically "fall out" as trivial
in the code, but an automated translator wouldn't notice that. The ".v" stuff
is just syntax to make ANTLR happy, and would not appear in the Scheme code.
E.G., ANTLR:
{$v = append($head.v, $children.v);}
==>
(append $head $children)
We could even let the names keep "$" (I don't plan to do that, because I
suspect some Lisps don't like those as identifiers, but we *could*).
> 3. Plan out the pre-conditions and post-conditions of the different
> productions (as we would implement in the actual Scheme code). Also
> plan out the exact calling convention of productions-cum-procedures.
I intend for there to be a 1-to-1 mapping from the key BNF productions to
Scheme procedures, and for each procedure to return a list with 2 values: "why
stopped" and "result". The "why stopped" for it_expr would be the indent it
read that caused it to return; the "why stopped for head, rest, and several
others would be symbol like 'eol, 'sublist, 'group_splice, or ''restart_end.
> 4. Mark the places where the pre-conditions and post-conditions of
> the productions would be violated by the ANTLR code, but which are
> somehow "magically" fixed by putting "error".
Pre/post sure; not sure what you mean by magic.
> Also: maybe we should initiate SRFI process "soon".
Well, we need to redo this part of the Scheme implementation. I expect that to
be really easy. Once we do that, then yes, we need to start the SRFI process.
> That way, when someone on the SRFI list raises fuss about the
> sweet-expressions grammar, we haven't sunk time into figuring out how
> to translate the ANTLR Scheme by hand into actual Scheme code. We can
> then back-propagate any changes into ANTLR Java sweet.g, check things
> out, then re-convert back to ANTLR Scheme.
>
> Or something.
I don't think the SRFI process will go far until we have a "working" Scheme
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.
>
> Looks like a complete rewrite of the code (^.^)v
That's good. Have you SEEN that code? :-) :-) :-).
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.
--- 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
