[plt-scheme] New Match Implementation

On Tue, Apr 1, 2008 at 12:42 PM, Dimitris Vyzovitis <vyzo at media.mit.edu> wrote:
> On Tue> (compile '(let () z)), 1 Apr 2008, Sam THfŸ=y=z at Pž$"W^Áž##" wrote:
>
>  > On Tue, Apr 1, 2008 at 3:34 AM, Dimitris Vyzovitis <vyzo at media.mit.edu> wrote:
>  >
>  > >  It now (well, rev 9096) extracts useless elements from compounds for _
>  > >  patterns.
>  >
>
> > If you time these two examples, I think you'll find no measurable
>  > difference in performance.  I assume that the useless bindings are
>  > optimized away.  On this topic, see Kent Dybvig's talk on the
>  > macro-writers bill of rights, which I believe MzScheme supports all
>  > of.
>
>  Not quite.
>  You are asking the optimizer to drop an application (in a strict language)
>  because you don't use the result. This is not something you can do in
>  general, unless the the application is provably pure (and the compiler is
>  sufficiently smart to prove it).
>
>  This may be possible with primitives like car/cdr (but it is *not*
>  done), but in general it is hopeless for things like structs where the
>  accessors are generated by make-struct-type or things that may come from
>  different modules.

First, using `comp=?' is not sufficient here, because of the presence
of the JIT.  But if you have programs on which you can measure the
speed difference introduced by the extra bindings, I'd be interested.

>
>  See (using matthew's comp=?):
[snip]
>  >
>  > This is something that can, and hopefully will, be improved.  It's a
>  > fairly straightforward optimization, but not one that I've had time to
>  > implement yet.
>
>  If you get around doing that, can you generalize it for (app ...) patterns
>  and not just the built-in expanders?

I've committed a reordering pass which should alleviate some of the
redundant checking here.  But I'm not sure what you want me to
optimize about (app ...) patterns.  Can you explain?

Thanks,
-- 
sam th
samth at ccs.neu.edu