Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.lang.misc Subject: Re: How to make a language downward-extensible? Message-ID: <29047:Sep2816:51:1290@kramden.acf.nyu.edu> Date: 28 Sep 90 16:51:12 GMT References: <1990Sep24.160705.21113@newcastle.ac.uk> <9363:Sep2521:41:1290@kramden.acf.nyu.edu> <7935@scolex.sco.COM> Organization: IR Lines: 36 In article <7935@scolex.sco.COM> seanf (Sean Fagan) writes: > In article <9363:Sep2521:41:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > quickpick > > fast(define builtin_bitcount 0) > > count = bitcounts[j & 65535] + bitcounts[(j >> 16) % 65535]; > > fast(define builtin_bitcount 1) > > unsigned long i; > > for(i = j;i;i >>= 1) count += (i & 1); > > endquickpick > Ugh. Are you then going to standardize *everything*? What are you talking about? The only thing added to the language is the quickpick control structure. All I'm doing is letting the programmer give the compiler a much better chance to optimize a section of code. > The Elxsi has an instruction for passing a message (up to 836 bytes, I > think) to a "port", which is usually another process (yet need not be). Are > you going to straddle your "language" with the semantics of this > instruction, simply because someone may find it useful? Of course not! What would be the point of that? The compiler should be able to use the instruction if at all possible, but nothing in the language changes. What we're trying to do here is let a language be downward-extensible without losing portability at all. > Now, all that said: C has the #ifdef route, which is close to what you > want. No, it isn't, for the several reasons I explained in the first article of this thread. ifdefs are clumsy to define, and they guarantee that your program will run poorly when the hardware changes under your nose. They require that someone who wants to install the software on a new machine figure out each one of your ridiculously many ifdefs. That is not the portable downward extensibility that we want. ---Dan