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
