Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!wuarchive!uunet!midway!tank!stephen From: stephen@estragon.uchicago.edu (Stephen P Spackman) Newsgroups: comp.lang.misc Subject: Re: How to make a language downward-extensible? Message-ID: Date: 1 Oct 90 03:54:02 GMT References: <1990Sep24.160705.21113@newcastle.ac.uk> <9363:Sep2521:41:1290@kramden.acf.nyu.edu> <7935@scolex.sco.COM> <29047:Sep2816:51:1290@kramden.acf.nyu.edu> <7950@scolex.sco.COM> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago CILS Lines: 22 In-Reply-To: seanf@sco.COM's message of 30 Sep 90 08:42:43 GMT IMHO, the best way of making a language "downward-extensible" is not to touvch the language at all. Instead, you add to the compiler's transformation-strategy library (we're talking about a fairly radical compiler here) a note to the effect that this piece of code you want to go fast is equivalent to this other piece of code - if you're being careful you also provide a formal proof, and if not you just give your initials and the date :-). Then the compiler can, if the optimisation level is low, compile just what you wrote; if the optimisation level is high, it compiles both options in parallel until it has reached a point where one clearly dominates the other under the current regime (space/time/resource availability and so forth). We already trust the compiler to do much of our optimisation. Making that compiler smarter, possibly interactively, is what we want to do next. Maybe we can even give up on our source languages being a priori implementable by now - ditching everything but the specs. stephen p spackman stephen@estragon.uchicago.edu 312.702.3982