On 1/23/13, David A. Wheeler <dwhee...@dwheeler.com> wrote: >> However there's no error signalled explicitly at this stage, and >> although ANTLR might handle this correctly, I'm not so certain that a >> naive Scheme translation would. > > ANTLR does indeed handle this correctly; since no production would match > this, it'll detect the problem, whine, and try to auto-resync. > > I actually had this as an explicitly-documented error case earlier, but it's > not strictly necessary, so to simplify things I removed it. > > If you think we should specifically document this as an error case, I can > re-add it, no problem. I don't want to try to list "all ways to have an > error", but identifying a few important ones is useful (we just have to > decide which ones need doing).
Hmm, dunno. We'd need to pretty much fix the sweet.g spec by then, and then try hand-converting it to Scheme and seeing the parts which need special attention in inserting error checks. Or we could just list all ways to have an error just in case LOL. 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. 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. 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. 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". -- Also: maybe we should initiate SRFI process "soon". Possibly, we can try making an automated ANTLR Java -> ANTLR Scheme program that can process the few actual Java bits that are used, run it on the current ANTLR code, and then initiate 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. >> You know, after a bit of thinking, I guess it's because INDENT and >> DEDENT are tokens in this case, and my initial understanding was that >> t_expr would be entered only when the port is at the start of a line. >> Is this correct or have I become horribly confused? > > You're correct. 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 "". Hmm. Looks like a complete rewrite of the code (^.^)v Sincerely, AmkG ------------------------------------------------------------------------------ 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
