I don't think that TR should provide the majority of the optimizations
in its current form because it has to run before inlining, and this
limits what it can do.
Here is an example program:
#lang typed/racket
(: my-sequence-map
(All (A B)
(case->
((A -> B) (Vectorof A) -> (Vectorof B))
((A -> B) (Listof A) -> (Listof B)))))
(define (my-sequence-map f s)
(if (vector? s)
(vector-map f s)
(map f s)))
(my-sequence-map add1 (vector 1 2 3))
(my-sequence-map add1 (list 1 2 3))
I would like this to be optimized to:
(vector-map add1 (vector 1 2 3))
(map add1 (list 1 2 3))
I think this case of code will be very common if we move to a world
where we work over generic sequences/datastructures, and specializing
the call sites will be a big win.
TR cannot do this optimization because it requires inlining. And the
current version of racket cannot optimize this either because it
becomes
(let ((s (vector 1 2 3)))
(if (vector? s)
(vector-map add1 s)
(map add1 s)))
Which isn't optimized because when we see (vector? s) we don't know
that s is a vector as Mathew's change only works if the constructor is
inline (i.e. of the form (vector? (vector 1 2 3))). Cases like this
make me think that we need something stronger than context free
rewrite rules over the ast/bytecode.
On Wed, May 28, 2014 at 6:36 PM, Matthias Felleisen
<matth...@ccs.neu.edu> wrote:
>
> Perhaps the right answer is to organize the optimizer
> as a rewriting engine to which other devs can add rules
> as they discover them (and their absence in the existing
> rule set). -- Indeed, one could then even have programmers
> extend the rule set for a specific program (though then
> we have to worry about soundness). With syntax-* we should
> have no problem formulating the mostly context-free rules
> and we could figure out in addition how to keep track of
> contexts. (This is the other half of what we used to call
> the 'open compiler' idea at Rice.)
>
> -- Matthias
>
>
>
>
> On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote:
>
>> On Thu, May 29, 2014 at 4:26 AM, <mfl...@racket-lang.org> wrote:
>>>
>>> | optimizer: ad hoc optimization of predicates applied to constructions
>>> |
>>> | This is probably more of a job for Typed Racket, but maybe it's
>>> | useful to detect some obviously unnecessary allocations of lists, etc.
>>
>> I think this is a useful discussion to have. I think there are two
>> questions to answer:
>>
>> 1. Do we want people to need to use a particular language for greater
>> optimization, whether that's Typed Racket or some other optimizer?
>>
>> 2. How should we optimize the code that Typed Racket depends on?
>> Since this is a finite amount, we could manually do this, but we might
>> not want to.
>>
>> Of course, in the absence of other constraints, it would be great to
>> have infinite optimizations at every level. But in our actual setting,
>> I don't know what I think the answer to either of these questions is.
>>
>> Sam
>> _________________________
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
>
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
