Go Programming talk [OT]

[Andrei Alexandrescu]

On 06/07/2010 09:02 AM, Kagamin wrote:
> Andrei Alexandrescu Wrote:
>
>> You get  to choose  at design  time  whether you use~OOP for  a
>> particular  type, in which  case you  use \kidx{class}; otherwise,
>> you go with @struct@ and forgo the particular~OOP amenities that go
>> hand in hand with reference semantics.
>>
> Good, but this is about user's decision. I meant decisions that were
> made by the language designer, so if you want a feature, you're
> forced to choose between languages. Well, I'm not sure whether such
> book can be "about just D".

The book includes honest discussions of language design decisions, 
including merits of approaches D decided to diverge from. Example:

====================
Now what  happens when  the compiler sees  the improved  definition of
@find@?   The  compiler faces  a  tougher  challenge  compared to  the
@int[]@ case because  now\sbs @T@ is not known  yet---it could be just
about any  type.  And different  types are stored  differently, passed
around differently, and  sport different definitions of~@==@.  Dealing
with this  challenge is important because type  parameters really open
up possibilities and  multiply reusability of code.  When  it comes to
generating code for type  parameterization, two schools of thought are
prevalent today~\cite{pizza}:

\begin{itemize*}
\item\emph{Homogeneous  translation:}  Bring  all  data  to  a  common
   format, which allows compiling only  one version of @find@ that will
   work for everybody.
\item\emph{Heterogeneous  translation:} Invoking  @find@  with various
   type arguments (e.g., @int@ versus @double@ versus @string@) prompts
   the compiler to generate as many specialized versions of @find at .
\end{itemize*}

In homogeneous  translation, the language must offer  a uniform access
interface  to data  as  a  prerequisite to  presenting  it to  @find at .
Heterogeneous translation  is pretty much  as if you had  an assistant
writing one special @find@ for each  data format you may come up with,
all  built  from the  same  mold.   Clearly  the two  approaches  have
relative advantages and disadvantages,  which are often the subject of
passionate  debates in  various  languages' communities.   Homogeneous
translation favors uniformity, simplicity, and compact generated code.
For example, traditional functional languages favor putting everything
in list  format, and many traditional  object-oriented languages favor
making everything an object offering a uniform access to its features.
However,  the  disadvantages of  homogeneous  translation may  include
rigidity, lack  of expressive  power, and inefficiency.   In contrast,
heterogeneous translation favors specialization, expressive power, and
speed of generated code.  The  costs may include bloating of generated
code,  increases in  language complexity,  and an  awkward compilation
model (a frequently aired argument against heterogeneous approaches is
that they're glorified macros [gasp]; and ever since~C gave such a bad
reputation  to macros,  the  label evokes  quite  a powerful  negative
connotation).

A  detail worth  noting  is an  inclusion relationship:  heterogeneous
translation  includes homogeneous  translation for  the  simple reason
that   ``many   formats''   includes   ``one  format,''   and   ``many
implementations'' includes ``one implementation.'' Therefore it can be
argued (all other issues left aside) that heterogeneous translation is
more powerful than homogeneous translation.  If you have heterogeneous
translation  means at  your disposal,  at least  in  principle there's
nothing stopping  you from  choosing one unified  data format  and one
unified function when  you so wish. The converse  option is simply not
available  under  a  homogeneous   approach.   However,  it  would  be
oversimplifying   to  conclude   that  heterogeneous   approaches  are
``better'' because aside from expressive power there are, again, other
arguments that need to be taken into consideration.

\dee~uses heterogeneous translation  with (warning, incoming technical
terms flak) statically scoped symbol lookup and deferred typechecking.
This  means  that  when  the~\dee  compiler sees  the  generic  @find@
definition, it parses and saves the body, remembers where the function
was defined, and does nothing  else until @find@ gets called.  At that
point,  the  compiler fetches  the  parsed  definition  of @find@  and
attempts to  compile it with  the type that  the caller chose  in lieu
of\sbs @T at .  When the function uses symbols, they are looked up in the
context in which the function was defined.
====================


Andrei