upcoming patches

upcoming patches

[Andy Wingo]

My todo list, for the record:

  1) Finish case-lambda branch -- should be a day or two's work there

     This doesn't necessarily imply that all the new features
     (case-lambda, lambda*, ...) are fully baked, but the VM, debugging,
     and IL support for the features should be mergeable and documented.

  2) Make sure Mark's patch is in

     If Neil gets to this one first, that's fine :) But it needs to go
     in, so that

  3) Merge Daniel's work

     This will involve some updating for the case-lambda tree-il
     changes, but the ecmascript and brainfuck changes have not been
     difficult to make.

Then I will pop back to the case-lambda work, finishing GOOPS dispatch
in Scheme with case-lambda and predicates, and then see if I can merge
in subr-simplification, getting all dispatch into the VM.

OK, being dragged out the door. Talk to yall later!

A
-- 
http://wingolog.org/

Re: upcoming patches

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

>   2) Make sure Mark's patch is in
>
>      If Neil gets to this one first, that's fine :) But it needs to go
>      in, so that

Have I missed this?  I _think_ I'm still waiting for Mark's updated
patch...

Many apologies in advance if I have missed it!

Regards,
        Neil

Re: upcoming patches

[Andy Wingo]

On Sun 18 Oct 2009 23:43, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>>   2) Make sure Mark's patch is in
>>
>>      If Neil gets to this one first, that's fine :) But it needs to go
>>      in, so that
>
> Have I missed this?  I _think_ I'm still waiting for Mark's updated
> patch...
>
> Many apologies in advance if I have missed it!

Oh no, I haven't seen a new one either. I was just going to take a look
at the old one again and see how much work it needed -- because it's not
fair to Daniel to keep his work in limbo, IMO.

Cheers,

Andy
-- 
http://wingolog.org/

Re: upcoming patches

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Oh no, I haven't seen a new one either. I was just going to take a look
> at the old one again and see how much work it needed -- because it's not
> fair to Daniel to keep his work in limbo, IMO.

True - but I thought Mark's patch was an orthogonal optimisation, and
hence that Daniel's work shouldn't depend on it.  Is that wrong?

       Neil

Re: upcoming patches

[Andy Wingo]

On Mon 19 Oct 2009 23:08, Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> Oh no, I haven't seen a new one either. I was just going to take a look
>> at the old one again and see how much work it needed -- because it's not
>> fair to Daniel to keep his work in limbo, IMO.
>
> True - but I thought Mark's patch was an orthogonal optimisation, and
> hence that Daniel's work shouldn't depend on it.  Is that wrong?

You're probably right, I'll see about getting Daniel's work in
regardless.

Ciao,

Andy
-- 
http://wingolog.org/

Re: upcoming patches

[Mark H Weaver]

Andy wrote:
>   2) Make sure Mark's patch is in

Neil wrote:
> Have I missed this?  I _think_ I'm still waiting for Mark's updated
> patch...

Sorry for being so slow on this.  I had a lot of free time with I
first submitted the patch, but have been busier since then.  If
someone wants to make a new patch from my "cube of lisp booleans"
post, that would be fine with me.

The biggest block is that I'm intimidated by the prospect of looking
at every use of scm_is_{false,true,null} in the tree and deciding
which of the new predicates should be used.  I expect that the vast
majority could be left alone without introducing new bugs, but I can't
be sure without checking each one.

Also, since writing the first patch, I've had some second thoughts
about whether this approach to #nil is the correct one.  I'm primarily
concerned with the problem of equality predicates, which from the lisp
point of view should treat #nil as equal to both '() and #f.  How will
this interact with collections (e.g. hash tables and alists, or even
simple lists used as sets) which use lists as keys?  If lisp adds an
element to such a collection, scheme won't be able to find it, and
vice versa.  I see the potential for many subtle bugs to go unnoticed.

I think a case can be made that we need three new equality predicates
which treat #nil, '(), and #f as the same value, three new types of
hash tables, three new sets of association list functions, etc.

Although I'm sure the Emacs community would never agree, I'm tempted
to suggest that the best solution is for Emacs to meet us half way, by
making end-of-list and boolean false distinct values, although '()
would still be considered false by conditionals from within lisp.
Having different notions of "falseness" in the two languages does not
pose a serious problem, but I do not see a robust way of dealing with
lisp's failure to distinguish end-of-list and boolean false.

Apologies if these thoughts are half-baked.  Part of the problem is
that I've not had enough time to fully evaluate these issues, and I
feel paralyzed since I don't like any of the available options.

Thoughts?

     Mark

Re: upcoming patches

[Andy Wingo]

Hi,

On Tue 20 Oct 2009 18:47, Mark H Weaver <mhw@netris.org> writes:

> Andy wrote:
>>   2) Make sure Mark's patch is in
>
> Neil wrote:
>> Have I missed this?  I _think_ I'm still waiting for Mark's updated
>> patch...
>
> Sorry for being so slow on this.  I had a lot of free time with I
> first submitted the patch, but have been busier since then.

No prob, happens to all of us :)

> The biggest block is that I'm intimidated by the prospect of looking
> at every use of scm_is_{false,true,null} in the tree and deciding
> which of the new predicates should be used.

Why don't we just get the first version in with #define scm_is_false(x)
scm_is_false_and_not_nil(x), etc? Patches that do 1 thing only are best.

> I expect that the vast majority could be left alone without
> introducing new bugs, but I can't be sure without checking each one.

Sure, but we can help with that.

> Also, since writing the first patch, I've had some second thoughts
> about whether this approach to #nil is the correct one.  I'm primarily
> concerned with the problem of equality predicates, which from the lisp
> point of view should treat #nil as equal to both '() and #f.  How will
> this interact with collections (e.g. hash tables and alists, or even
> simple lists used as sets) which use lists as keys?  If lisp adds an
> element to such a collection, scheme won't be able to find it, and
> vice versa.  I see the potential for many subtle bugs to go unnoticed.

Well, there are many ways to think about this I guess. I'm of more of a
pragmatic than a practical bent; so it's clear to me is that whatever
goes in as a result of your patch will be pragmatically better than what
we have now.

What do you think about this:

  (eq? #f '()) => #f
  (eq? #f #nil) => #f
  (eq? '() #nil) => #f

  (eqv? #f '()) => #f
  (eqv? #f #nil) => #t
  (eqv? '() #nil) => #t

  (equal? #f '()) => #f
  (equal? #f #nil) => #t
  (equal? '() #nil) => #t

That handles delv, assoc, etc.

Hash is more difficult. Hashq of all are distinct; hashv and hash are
the same. But if (hash #f) == (hash #nil) and (hash #nil) == (hash '()),
then (hash '(a)) == (hash '(a . #f)), which would be bad -- and indeed
that's not possible.

So why don't we just say that (hash #nil) == (hash '()). It will be
documented that hash tables and lisp interaction are just this way.

> Although I'm sure the Emacs community would never agree, I'm tempted
> to suggest that the best solution is for Emacs to meet us half way

Only if we can show them some really awesome benefits would they do
this -- and even then I think it's a bad idea. There is 20 years of
elisp code out there that we can't presume to change.

> Apologies if these thoughts are half-baked.  Part of the problem is
> that I've not had enough time to fully evaluate these issues, and I
> feel paralyzed since I don't like any of the available options.

No prob! Thanks for mailing the list, I hadn't thought about the hash
issues before. What do you think about my dodgy "solutions"? :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: upcoming patches

[Daniel Kraft]

Hi Andy,

Andy Wingo wrote:
>   3) Merge Daniel's work
> 
>      This will involve some updating for the case-lambda tree-il
>      changes, but the ecmascript and brainfuck changes have not been
>      difficult to make.

I've not yet done so but plan to keep on working there with some stuff 
(as I already mentioned, like defalias) as soon as I find some time. 
Two questions:

* Do we want to freeze my branch for your work there, so I'll hold this off?

* Does the case-lambda stuff mean that the branch won't currently work 
when I pull from master?  So, I should not do this until you did the 
update?  Or can I when restarting work to be up-to-date?


Yours,
Daniel

Re: upcoming patches

[Andy Wingo]

On Mon 19 Oct 2009 14:34, Daniel Kraft <d@domob.eu> writes:

> Hi Andy,
>
> Andy Wingo wrote:
>>   3) Merge Daniel's work
>>
>>      This will involve some updating for the case-lambda tree-il
>>      changes, but the ecmascript and brainfuck changes have not been
>>      difficult to make.
>
> I've not yet done so but plan to keep on working there with some stuff
> (as I already mentioned, like defalias) as soon as I find some time. Two
> questions:
>
> * Do we want to freeze my branch for your work there, so I'll hold
> this off?

I would say, keep on trucking :) And keep the list informed of what
you're up to, please. If I'm able to merge something e.g. this weekend,
we'll just rebase any extra patches you have.

> * Does the case-lambda stuff mean that the branch won't currently work
> when I pull from master?  So, I should not do this until you did the
> update?  Or can I when restarting work to be up-to-date?

It won't work once wip-case-lambda gets merged. Some slight changes will
be necessary.

Andy
-- 
http://wingolog.org/

Re: upcoming patches

[Andy Wingo]

Hey,

On Sun 18 Oct 2009 12:38, Andy Wingo <wingo@pobox.com> writes:

> My todo list, for the record:
>
>   1) Finish case-lambda branch -- should be a day or two's work there
>
>      This doesn't necessarily imply that all the new features
>      (case-lambda, lambda*, ...) are fully baked, but the VM, debugging,
>      and IL support for the features should be mergeable and documented.

Well, that ended up being 3 or 4 days' work, but all the features are
there and documented.

>   2) Make sure Mark's patch is in

I'm going to do it! I will! :)

Mark, I realized that we can have (hashv '()) == (hashv #f). In a hashv
table the hashv selects the bucket, but within the bucket elements are
compared with eqv? -- and (eqv? '() #f) => #f. So I don't see any
problems there.

>   3) Merge Daniel's work

This is next!

> Then I will finish GOOPS dispatch in Scheme with case-lambda and
> predicates, and then see if I can merge in subr-simplification,
> getting all dispatch into the VM.

I hope to get this all in before the next release. We'll see!

Andy
-- 
http://wingolog.org/

Re: upcoming patches

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> I hope to get this all in before the next release. We'll see!

Wow, fantastic stuff!  Thanks for working on all these things!

      Neil