Re: [PATCH] Add tree-il optimizations for equal? on char and number literals

[Linus Björnstam]

That is indeed a lot prettier!  I didn't know guile compared chars using eq? 
(The manual states that you should use eqv? For chars and numbers). 

On the latest master equal? was not reduced to eq? on chars in the repl for 
things like ,opt (define (a b) (equal? b #\b)). Was I using the new baseline 
compiler or should it always be triggered? I didn't have time to really check 
it out, and I have about a gazillion little computers that run guile. I do 
think I was sshing into the right one, though :)

Good to hear know that I can (match...) without fear in the future! Between 
this and the record unification I feel I have very little motivation to write 
my own extensible pattern matcher :) 
-- 
  Linus Björnstam

On Wed, 13 May 2020, at 15:55, Andy Wingo wrote:
> Hi :)
> 
> On Wed 13 May 2020 13:20, Linus Björnstam <address@hidden> writes:
> 
> > Hi there!
> >
> > Aleix and I noticed that equal? has a lot higher overhead than eqv? on
> > chars, which means using (ice-9 match) for chars was suboptimal. This
> > patch fixes that.
> 
> I think we can be a little more simple here.  Scheme doesn't specify
> what (eqv? #\a x) is, but in Guile it is equivalent to (eq? #\a x), and
> our compiler should be free to turn the portable eqv? invocation into
> eq?.  But as the comment on line 416 says, we should really do this in
> peval and not in the expander.  So.... you nerd-sniped me ;)  I just
> pushed a patch that did this.
> 
> While looking, I found this:
> 
> > +         (make-conditional src (make-primcall src prim (list a b))
> > +                           (make-primcall src prim (cons b rest))
> > +                           (make-const src #f))))))
> 
> This was in the original code but is wrong: if "b" has a side-effect, it
> will happen twice.  I have fixed it in git.
> 
> Thanks for the debugging and patch!
> 
> Andy
>