Am 22.11.2013 04:45, schrieb David A. Wheeler: > On Thu, 21 Nov 2013 12:29:58 +0100, "Jörg F. Wittenberger" > <joerg.wittenber...@softeyes.net> wrote: > >> I tried for now to keep the compatibility layer before the actual >> module. But that might leak definitions (like the rudimentary guard >> implementation) outside, which would have to be avoided. For this to we >> would have to move the whole section into the body of >> `readable-kernel-module-contents`, right? > Correct. To the extent that we *can*, I think we need to move things inside > the macro that creates the module to minimize leakage. So if you would please > maximally move the macro definitions inside the module creation macro, > that'd be great.
Against which file version should I do the patch? Also: might take a moment. I'm a bit busy at the moment. > I really don't like how "translate-cl" was changed. I strongly prefer: > (define (translate-cl x) > over: > (define translate-cl ... (lambda (x) ... )) > because it's MUCH easier in the first format to determine that this is > a procedure that accepts exactly one parameter. Up, I just noticed that I forgot to add a type declaration here. But that should do the trick. Otherwise I understand that it might be a little harder to read. But I'd claim it's not much harder. And it might be worth the effort. See: First my definition for reference: (: translate-cl (* --> *)) (define translate-cl (let ((qq (string->symbol "+++CL-QUASIQUOTE-abbreviation+++")) (uq (string->symbol "+++CL-UNQUOTE-abbreviation+++")) (us (string->symbol "+++CL-UNQUOTE-SPLICING-abbreviation+++"))) (lambda (x) (if common-lisp (case x ((quasiquote) qq) ((unquote) uq) ((unquote-splicing) us) (else x)) x)))) > Also, the patched version will calculate 3 values on every entry; No, it does not compute any value upon entry. To the contrary, all those three bindings are computed just once at definition time. That's why I lifted them from the procedures body. > the case should compute and return ONLY what it needs to compute. > I presume that this isn't working: > '+++CL-QUASIQUOTE-abbreviation+++ > but you could replace *just* that with this format, yes?: > (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") Yes, I could. But THIS would be one computation for each invocation (of the matching case here). Now this is rather cheap: a hash table lookup per quasiquote/unquote/unquote-splicing which in turn are rare. > Why all the redefines from "body" to "read-body"? > We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the "semantic error" and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. > We could do that if it's important to port to rscheme, > I just want to know why before making the change. > I presume you had a reason; if so, we need to > document why this is an exception to the naming convention. > Basically, just add a comment at the definition of "read-body" > to explain why the naming convention is NOT being followed. > > Could you resend the patch, per those comments? > Overall this looks really promising. > As I said, busy by now. Maybe next week if things go well. Best Regards /Jörg ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss