🚀 go-pugleaf

In article <18718:Oct120:03:0090@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> 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?

Each vendor can supply new and useful language/library extensions -
definitions of new functions, datatypes, etc. - in a namespace (e.g.,
a package in Common Lisp) distinct from the "common" one (the one
containing all those symbols already standardized).  A programmer who
wishes to use such definitions can refer to them in their original
package (e.g., as VENDOR:FUNC), or for convenience import them into
her/his own "working" package.  The programmer must of course supply
her/his own definition of the symbol when porting code to a less
capable platform.  Eventually, if enough programmers find the
definition useful, most of the leading vendors will incorporate it
into their systems.  At this point, the definition may be added to the
language/library standard.

The specific example of counting the number of 1-bits in an integer is
standardized as LOGCOUNT in Common Lisp.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.