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: <18718:Oct120:03:0090@kramden.acf.nyu.edu> Date: 1 Oct 90 20:03:00 GMT References: <7935@scolex.sco.COM> <29047:Sep2816:51:1290@kramden.acf.nyu.edu> <7950@scolex.sco.COM> Organization: IR Lines: 76 In article <7950@scolex.sco.COM> seanf (Sean Fagan) writes: > In article <29047:Sep2816:51:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >> 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. > Uhm... where are you going to define the names that are used? What names are you talking about? The language is not extended by the compiler. > Or is the > compiler supposed to go through your "worst-case" one, analyze it, and see > which instruction matches it most closely? If it could do that already, you > wouldn't need to bother with your "quickpick" thingy. Huh? The compiler already converts any given sequence of code into machine instructions as well as it knows how. quickpick just lets the programmer give the compiler several alternatives. There's no way to do this currently. > If the "names" are going to be "standardized" (which is what I was referring > to), you're going to have a real mess on your hands, which is why I went > into the example about the elxsi et al. Agreed, that would be a real mess, like the current ifdef situation. See my first quickpick example. > >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. > So will your method. You would have to recompile. Yes, I'm aware of that; programs are almost always recompiled for new hardware. The point is that you don't need the original programmer slobbering over each new chip to figure out whether it's faster with algorithm X or algorithm Y. You let the compiler do the job for you. > If you do something like: > #ifdef BIT_COUNT_IN_HARDWARE > __builtin_bitcount (whatever); > #else > whatever > #endif > what is the difference between *that*, and your method? Other than niggling > little details? Namespace problems! Lack of portability! Decentralized language extensions! The difficulty of defining every single ifdef on every single machine! Don't you realize that this is a problem? > >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. > Your method requires lots of things, too. Generally, though, the person who > builds the compiler would figure them out, not necessarily the installer. > For example, in (or something like , I guess), with the > correct defines for the machine. No more difficult than installing a libc. > For most people, that is. Maybe not you. At the risk of being overrepetitively redundantly redundant: Think about managing the namespace. How do you plan to tell all the compiler writers around the world what symbols they should define? Do you plan to fix a single set and let this form of optimization stagnate? Do you want namespace anarchy? Will you hold an annual seance to resolve these problems? What will you do when the number of symbols balloons? Do you seriously believe that each vendor is going to define a thousand other symbols saying ``no, I don't support that other vendor's optimizations'' when only ten or twenty optimizations are relevant locally? The current C situation makes it annoyingly difficult to write portable, efficient code. For most people, that is. Maybe not you. Maybe you think that it's reasonable for each package to define a new set of symbols for the installer to suffer through. I don't. ---Dan