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

Reply via email to