This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] Parameter protocols in CL


On Wed, Jul 18 2012, Charles Turner wrote:

> Thanks for the explanations Helmut.
>
> On 18 July 2012 21:29, Helmut Eller <eller.helmut@gmail.com> wrote:
>> One idea is to rewrite
>>
>> (lambda (&optional (var init-form supplied-p))
>>   body)
>>
>> to
>>
>> (lambda (#!optional (tmp-var <unbound-marker>))
>>   (let ((var (if (eq tmp-var <unbound-marker)
>>                  init-form
>>                  tmp-var)))
>>     body))
>>
>> where <unbound-marker> is some special value that the user can usually
>> not create, e.g. some of those in gnu.expr.Special.
>
> Why not to:
>
> (lambda (#!optional (tmp-var <unbound-marker>))
>    (let* ((supplied-p (if (eq tmp-var <unbound-marker>) nil t))
>              (var (if supplied-p tmp-var init-form)))
>      body))
>
> It seems like your translation ignores the supplied-p parameter.

Ah yes. 

>
>> You mean SBCL's DESTRUCTURING-BIND generates
>> something like ((lambda (&optional (a 2) &rest x) (list a x))) ?
>
> Sorry, I mean't it uses that as part of it's destructuring implementation:
>
> (defun parse-defmacro (lambda-list whole-var body name context
>                        &key
>                        (anonymousp nil)
>                        (doc-string-allowed t)
>                        ((:environment env-arg-name))        ; can't I
> just pick another name for now?
>                        ((:default-default *default-default*))
>                        (error-fun 'error)
>                        (wrap-block t))

Yes, renaming the arguments seems like a simple solution.

>> Without some small test case it's pretty hard to say what is going on.
>
> Anything involving DEFUN's seems to cause it. As nobody has a copy of
> my code, it's going to remain hard to see what's going on. I'm fairly
> sure it's bootstrapping. I've got an unwiedly boot procedure for now
> as editing make files pretty much guarantees I'll have nasty merge
> conflicts when I svn update (aclocal && automake produces quite a lot
> of diff I find).

Having an extra branch in the SVN repo for this work would not be the
worst idea.

Helmut


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]