Am 22.11.2013 04:45, schrieb David A. Wheeler:
> On Thu, 21 Nov 2013 12:29:58 +0100, "Jörg F. Wittenberger"
> <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
