Agregar Problemas y limitaciones del recolector actual

[z.facultad/75.00/informe.git] / source / d.rst

.. Introducción y breve reseña del lenguaje de programación D. También
   se presentan las necesidades particulares de D con respecto al
   recolector de basura y su estado actual.
   ESTADO: TERMINADO


.. _d_lang:

El lenguaje de programación D
============================================================================


Historia
----------------------------------------------------------------------------

D_ es un lenguaje de programación relativamente joven. Nació en 1999 y el
2 de enero de 2007 salió su `versión 1.0`__. Poco tiempo después se continúo
el desarrollo del lenguaje en la `versión 2.0`__, aún inestable y en la cual
se está experimentando principalmente sobre multi-procesamiento.

__ `D 1.0`_
__ `D 2.0`_

El lenguaje fue diseñado e implementado por `Walter Bright`_, desarrollador
principal de Zortech C++, uno de los primeros compilador de C++ que compilaba
a código nativo, y está fuertemente influenciado éste. Sin embargo toma muchos
conceptos de otros lenguajes de más alto nivel, como Java_ o incluso lenguajes
dinámicos como Perl_.

El origen del lenguaje está plasmado en su sitio web, en donde se cita:

   It seems to me that most of the "new" programming languages fall into one
   of two categories: Those from academia with radical new paradigms and those
   from large corporations with a focus on RAD and the web. Maybe it's time
   for a new language born out of practical experience implementing compilers.

Esto podría traducirse como:

   Parece que la mayoría de los lenguajes de programación "nuevos" caen en
   2 categorías: aquellos académicos con nuevos paradigmas radicales
   y aquellos de grandes corporaciones con el foco en el desarrollo rápido
   y web. Tal vez es hora de que nazca un nuevo lenguaje de la experiencia
   práctica implementando compiladores.

La versión 1.0 fue más bien una etiqueta arbitraria que un indicador real de
estar ante una versión estable y completa. Luego de liberarse se siguieron
agregando nuevas características al lenguaje hasta que se empezó el desarrollo
en paralelo de la versión 2.0 al introducirse el concepto de inmutabilidad
y funciones *puras* [#dpure]_ (a mediados de 2007).

.. [#dpure] Por funciones *puras* en D_ se entiende que no tienen efectos
   colaterales. Es decir, una función pura siempre que se llame con la misma
   entrada producirá el mismo resultado. Esto es análogo a como funcionan los
   lenguajes funcionales en general, abríendo la puerta a la programación de
   estilo funcional en D_.

A partir de este momento la versión 1.0 quedó *teóricamente* congelada,
introduciendo solo cambios que arreglen errores (*bug fixes*), introduciendo
todos las nuevas características solamente en la versión 2.0 del lenguaje. La
realidad es que se hicieron cambios incompatibles a la versión 1.0 del
lenguaje en reiteradas ocasiones, pero se fue tendiendo a cada vez introducir
menos cambios incompatibles. Sin embargo al día de hoy el compilador de
referencia sigue teniendo algunas características presentes en la
especificación del lenguaje sin implementar, por lo que todavía no hay una
implementación completa de la versión 1.0 del lenguaje, siendo esta etiqueta
todavía un poco arbitraria.

El lenguaje ha sido, hasta el desarrollo de la versión 2.0 al menos, un
esfuerzo unipersonal de `Walter Bright`_, dados sus problemas a la hora de
delegar o aceptar contribuciones. Esto motivó a la comunidad de usuarios de D_
a crear bibliotecas base alternativas a la estándar (llamada Phobos_) en las
cuales se pudiera trabajar sin las trabas impuestas por el autor del lenguaje.

En este contexto nacen primero Mango_ y luego Ares_. Mango_ fue creada por
Kris Macleod Bell a principios de 2004 como una biblioteca que provee
servicios básicos de entrada/salida (o *I/O* de *input/output* en inglés) de
alto rendimiento.   Siendo estos servicios algo básico lo más natural hubiera
sido que se encuentren en la biblioteca estándar de D_ pero por las
dificultades para contribuir a ésta, se desarrolla como una biblioteca
separada.   A mediados de 2004 Sean Kelly crea Ares_ , con las mismas
motivaciones pero con la intención de crear una biblioteca base (conocida en
inglés como *runtime*) que incluye los servicios básicos que necesita el
lenguaje (información de tipos, manejo de excepciones e hilos, creación
y manipulación de objetos, recolector de basura, etc.). Al poco tiempo de
liberarse Ares_, Mango_ empieza a utilizarla como biblioteca base.

Para comienzos de 2006, se empieza a trabajar en la combinación de ambas
bibliotecas para lograr una biblioteca estándar alternativa con un alto grado
de cohesión. Finalmente a principios de 2007, coincidiendo por casualidad con
la aparición de D_ 1.0, se anuncia el resultado de este combinación bajo el
nombre de Tango_, proveyendo una alternativa completa y madura a la biblioteca
estándar de D_ Phobos_.  A principios de 2008 los principales desarrolladores
de Tango_ (Kris Bell, Sean Kelly, Lars Ivar Igesund y Michael Parker publican
el libro llamado `Learn to Tango with D`_.

Esto por un lado fue un gran avance porque dio un impulso muy considerable al
lenguaje pero por otro un gran retroceso, porque todavía al día de hoy D_ 1.0
tiene 2 bibliotecas base, una estándar pero de peor calidad y menos mantenida
y una alternativa de mayor calidad y apertura a la comunidad (pero no
estándar). El peor problema es que ambas son **incompatibles**, por lo que un
programa hecho con Tango_ no funciona con Phobos_ y viceversa (a menos que el
programador haya invertido una cantidad de tiempo no trivial en asegurarse de
que funcione con ambas).

Esto hace que la compatibilidad de programas y bibliotecas esté muy
fragmentada entre las 2 bibliotecas base. Si bien no parece que vaya a haber
solución alguna a este problema para D 1.0, D 2.0 va en camino a solucionar
este problema ya que utiliza DRuntime_, un nuevo intento de Sean Kelly por
proveer una biblioteca *runtime* bien organizada y mantenida, que es una
adaptación de la biblioteca *runtime* de Tango_ a D 2.0. Si bien todavía
Tango_ no fue adaptada a D 2.0, se espera que cuando esto pase compartan la
misma biblioteca *runtime* permitiendo que bibliotecas y programas hechos para
Tango_ y Phobos_ 2.0 puedan coexistir sin problemas.


Descripción general
----------------------------------------------------------------------------

D_ es un lenguaje de programación con sintaxis tipo C, multi-paradigma,
compilado, con *tipado* fuerte y estático, buenas capacidades tanto de
programación de bajo nivel (*system programming*) como de alto nivel.   Es
compatible de forma binaria con C (se puede enlazar código objeto C con código
objeto D). Con estas características, D_ logra llenar un vacío importante que
hay entre lo lenguajes de alto bajo nivel y los de alto nivel [BKIP08]_. Si
bien tiene herramientas de muy bajo nivel, que por lo tanto son muy propensas
a errores, da una infinidad de mecanismos para evitar el uso de estas
herramientas a menos que sea realmente necesario.  Además pone mucho énfasis
en la programación confiable, para lo cual provee muchos mecanismos para
detectar errores en los programas de forma temprana.

Si puede pensarse en C++ como un "mejor C", podría decirse que D_ es un "mejor
C++", ya que el objetivo del lenguaje es muy similar a C++, pero implementa
muchas características que jamás pudieron entrar en el estándar de C++ y lo
hace de una forma mucho más limpia, ya que no debe lidiar con problemas de
compatibilidad hacia atrás, y cuenta con la experiencia del camino recorrido
por C++, pudiendo extraer de él los mejores conceptos pero evitando sus
mayores problemas también.

Otra gran diferencia con C++ es la facilidad para ser analizado
gramaticalmente (*parsing*), ya fue especialmente diseñado para ser sencillo
y a diferencia de C y C++ su gramática es independiente del contexto
(*context-free grammar*). Esto permite que D pueda ser compilado en pequeños
pasos bien separados:

1. Análisis léxico.
2. Análisis sintáctico.
3. Análisis semántico.
4. Optimizaciones.
5. Generación de código.

Esto favorece la creación de herramientas dada la facilidad de usar solamente
la cantidad de análisis necesario para cada herramienta (por ejemplo un editor
de textos puede tener hasta análisis sintáctico para proveer resaltado o un
entorno de desarrollo puede proveer herramientas de re-factorización de código
haciendo uso del análisis semántico).

Una de las características que nunca pudo entrar en el estándar de C++ es la
recolección de basura. D_ no comete el mismo error.


Características del lenguaje
----------------------------------------------------------------------------

A continuación se enumeran las principales características de D_, agrupadas
por unidades funcional o paradigmas que soporta:



.. _d_generic:

Programación genérica y meta-programación
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

La programación genérica se trata de la capacidad de poder desarrollar
algoritmos y estructuras independientes de los tipos que manipulan (pero de
forma segura o *type-safe*). Esto fue muy popularizado por C++ gracias a su
soporte de plantillas (*templates*) y luego otros lenguajes como Java_ y `C#`_
lo siguieron. Sin embargo otros lenguajes proveen formas más avanzadas de
programación genérica, gracias a sistemas de tipos más complejos (como
Haskell_).

La meta-programación se refiere en general a la capacidad de un lenguaje para
permitir generar código dentro del mismo programa de forma automática.  Esto
permite evitar duplicación de código y fue también muy popularizado por el
soporte de *templates* de C++, aunque muchos otros lenguajes tienen mejor
soporte de meta-programación, en especial los lenguajes dinámicos (como
Python_).

D_ provee las siguientes herramientas para realizar programación genérica
y meta-programación:

``if`` estático (``static if``):
   puede verse como similar a la directiva del preprocesador de C/C++ ``#if``,
   pero a diferencia de esto, en D_ el ``static if`` tiene acceso a todos los
   símbolos del compilador (constantes, tipos, variables, etc).

   Ejemplo::

      static if ((void*).sizeof == 4)
         pragma(msg, "32 bits");

   Más información en http://www.digitalmars.com/d/1.0/version.html#staticif

Inferencia de tipos básica implícita y explícita (mediante ``typeof``):
   si no se especifica un tipo al declarar una variable, se infiere del tipo
   de su inicializador.

   Ejemplo::

      static i = 5;      // i es int
      const d = 6.0;    // d es double
      auto s = "hola"; // s es string (que es un alias de char[])

   Más información en
   http://www.digitalmars.com/d/1.0/declaration.html#AutoDeclaration

   Mediante el uso de ``typeof`` se puede solicitar el tipo de una expresión
   arbitraria.

   Ejemplo::

      typeof(5 + 6.0) d; // d es double

   Más información en http://www.digitalmars.com/d/1.0/declaration.html#typeof

Iteración sobre colecciones (``foreach``):
   cualquier tipo de colección (arreglos estáticos y dinámicos, arreglos
   asociativos, clases, estructuras o delegados) puede ser iterada mediante la
   sentencia ``foreach``.

   Ejemplo::

      int[] a = [ 1, 2, 3 ];
      int total = 0;
      foreach (i; a)
         total += i;

*Templates*:
   clases y funciones pueden ser parametrizadas. Esto permite desarrollar
   algoritmos genéricos sin importar el tipo de los datos de entrada, siempre
   y cuando todos los tipos tengan una *interfaz* común.   Esto también es
   conocido como *polimorfismo en tiempo de compilación*, y es la forma más
   básica de programación genérica.

   Ejemplo::

      T sumar(T)(T x, T y) { return x + y; }
      auto i = sumar!(int)(5, 6);    // i == 11
      auto f = sumar!(float)(5, 6); // j == 11.0f

   Además se pueden definir bloques de declaraciones parametrizados (esto no
   es posible en C++), permitiendo instanciar dicho bloque con parámetros
   particulares. Esto sirve como un mecanismo para la reutilización de código,
   ya que puede incluirse un mismo bloque en distintos lugares (por ejemplo
   clases). Un bloque parametrizado puede verse como una especie de módulo.

   Ejemplo::

      template bloque(T, U) {
         T x;
         U foo(T y);
      }

      bloque!(int, float).x = 5;
      float f = bloque!(int, float).foo(7);

   La utilidad más prominente de los bloques parametrizados se da al
   acompañarse de *mixins*.

Instanciación implícita de funciones parametrizadas:
   el lenguaje es capaz de deducir los parámetros siempre que no hayan
   ambigüedades

   Ejemplo::

      auto i = sumar(5, 6);          // i == 11
      auto f = sumar(5.0f, 6.0f); // f == 11.0f

Especialización explícita y parcial de *templates*:
   la especialización de *templates* consiste, al igual que en C++, en proveer
   una implementación especializada para un tipo de dato (o valor) de los
   parámetros.   Especialización parcial se refiere a la capacidad de
   especializar un parámetro a través de un subtipo. Por ejemplo, se puede
   especializar un *template* para cualquier tipo de puntero, o para cualquier
   tipo de arreglo dinámico, sin necesidad de especificar el tipo al que
   apunta dicho puntero o el tipo almacenado por el arreglo.

   Ejemplo de especialización::

      T sumar(T: int)(T x, T y) { return x + y + 1; }
      auto i = sumar(5, 6);         // i == 12
      auto f = sumar(5.0f, 6.0f) // f == 11.0f

   Ejemplo de especialización parcial::

      T sumar(T: T*)(T x, T y) { return *x + *y; }
      int x = 5, y = 6;
      auto i = sumar(&x, &y); // i == 11
      float v = 5.0f, w = 6.0f;
      auto f = sumar(&v, &w); // f == 11.0f

Tipos, valores (incluyendo *strings*) y *templates* como parámetros:
   esto es otro bloque de construcción importantísimo para la programación
   genérica en D, ya que combinando *templates* que toman *strings* como
   parámetro en combinación con *string mixins* pueden hacerse toda clase de
   meta-programas.

   Ejemplo::

      template hash(string s, uint so_far=0) {
         static if (s.length == 0)
            const hash = sofar;
         else
            const hash = hash!(s[1 .. length], sofar * 11 + s[0]);
      }
      string s = hash!("hola"); // calculado en tiempo de compilación

Cantidad de parámetros variables para *templates*:
   Esto permite implementar tuplas u otros algoritmos que inherentemente deben
   tomar parámetros variables en tiempo de compilación.

   Ejemplo::

      double sumar(T...)(T t) {
         double res = 0.0;
         foreach (x; t)
            res += x;
         return res;
      }
      double d = sumar(1, 2.0, 3.0f, 4l); // d == 10.0

*CTFE* (*compile-time function execution*):
   si una función cumple ciertas reglas básicas (como por ejemplo no tener
   efectos colaterales) puede ser ejecutada en tiempo de compilación en vez de
   tiempo de ejecución. Esto permite hacer algunos cálculos que no cambian de
   ejecución en ejecución al momento de compilar, mejorando la performance
   o permitiendo formas avanzadas de metaprogramación. Esta característica se
   vuelve particularmente útil al combinarse con *string mixins*.

   Ejemplo::

      int factorial(int n) {
         if (n == 1)
            return 1;
         else
            return n * factorial(n - 1);
      }
      static int x = factorial(5); // calculado en tiempo de compilación
      int x = factorial(5); // calculado en tiempo de ejecución

   Esta característica es vital para evitar la duplicación de código.

*Mixins*, incluyendo *string mixins*:
   la palabra *mixin* tiene significados distintos en varios lenguajes de
   programación. En D_ *mixin* significa tomar una secuencia arbitraria de
   declaraciones e insertarla en el contexto (*scope*) actual. Esto puede
   realizarse a nivel global, en clases, estructuras o funciones. Esto sirve
   como un mecanismo para evitar duplicación de código que puede ser
   introducida por la falta de herencia múltiple.

   Ejemplo::

      class A {
         mixin bloque!(int, float);
      }
      A a = new A;
      a.x = 5;
      float f = a.foo(a.x);

      class B {
         mixin bloque!(long, double);
      }
      B b = new B;
      b.x = 5l;
      double d = a.foo(a.x);

   *String mixin* se refiere a la capacidad de *incrustar* un *string* que
   contenga un fragmento de código en un programa como si este fragmento
   hubiera sido escrito en el código fuente directamente por el programador.
   Esto permite hacer manipulaciones arbitrariamente complejas en combinación
   con funciones ejecutadas en tiempo de compilación.

   Ejemplo::

      string generar_sumar(string var_x, string var_y) {
         return "return " ~ var_x ~ " + " ~ var_y ~ ";";
      }

      int sumar(int a, int b) {
         mixin(generar_sumar!("a", b"));
      }

   Más información en http://www.digitalmars.com/d/1.0/mixin.html

Expresiones ``is``:
   las *expresiones ``is``* permiten la compilación condicional basada en las
   características de un tipo. Esto se realiza en favor a una técnica
   utilizada en C++ de realizar *pattern matching* sobre los parámetros de las
   plantillas.

   Ejemplo::

      T foo(T)(T x) {
         static if (is(T == class))
            return new T;
         else
            return T.init;
      }

   Esto provee además una forma simple de reflexión en tiempo de compilación.

   Más información en
   http://www.digitalmars.com/d/1.0/expression.html#IsExpression



.. _d_low_level:

Programación de bajo nivel (*system programming*)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Por programación de bajo nivel nos referimos a la capacidad de un lenguaje de
manipular el hardware directamente, o al menos la memoria. C es probablemente
el lenguaje de bajo nivel más popular, seguido por C++.

D_ presenta muchas características de bajo nivel:

Compila a código de máquina nativo:
   no es interpretado ni necesita una máquina virtual como otros lenguajes de
   más alto nivel como Java_, `C#`_, Python_, etc.

Provee acceso a *assembly*:
   por lo tanto, acceso directo al *hardware* y la posibilidad de utilizar
   cualquier característica de éste que no esté disponible en el lenguaje.

   Una ventaja sobre C y C++ es que el lenguaje *assembly* utilizado dentro de
   D_ está especificado, por lo que se puede mantener la portabilidad entre
   compiladores incluso cuando se utiliza *assembly* (mientras que no se
   cambie de arquitectura, por supuesto).

``goto``:
   al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``.

Compatibilidad con C:
   soporta todos los tipos de C y es ABI [#abi]_ compatible con éste. Esto
   permite enlazar archivos objeto estándar de C y D_ en un mismo programa.
   Además permite interoperar con C a través de ``extern (C)``.

   .. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
      Interface*).

   Ejemplo::

      extern (C) printf(const char* format, ...);
      printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C

Manejo de memoria explícito:
   permite asignar estructuras en el *stack* o en el *heap*, haciendo uso de
   los servicios del sistema operativo o la biblioteca estándar de C.

Objetos y arreglos *livianos*:
   por objetos *livianos* se entiende no-polimórficos. Es decir, un
   agrupamiento de variables análogo al ``struct`` de C, sin tabla virtual ni
   otro tipo de *overhead*. Los arreglos *livianos* son arreglos estáticos
   como en C, cuyo tamaño es fijo, también sin ningún tipo de *overhead* como
   C. Además puede asignarse un arreglo dinámicamente usando ``malloc()``
   y utilizar el operador ``[]`` para accederlo.

   Esto también permite interoperar con C, ya que pueden definirse ``structs``
   y arreglos que pueden ser intercambiados con dicho lenguaje sin problemas.

   Ejemplo::

      struct timeval {
         time_t         tv_sec;
         suseconds_t tv_usec;
      }
      extern (C) {
         void* malloc(size_t);
         size_t strlen(const char *);
         int gettimeofday(timeval *, void *);
      }
      char* s = cast(char*) malloc(2);
      s[0] = 'C';
      s[1] = '\0';
      size_t l = strlen(s); // l == 1
      timeval tv;
      gettimeofday(&tv, null);

Rendimiento:
   la :ref:`d_generic` permite realizar muchas optimizaciones ya que se
   resuelve en tiempo de compilación y por lo tanto aumentando la
   *performance* en la ejecución.

Número de punto flotante de 80 bits:
   El tipo ``real`` de D_ tiene precisión de 80 bits si la plataforma lo
   soporta (por ejemplo en i386).

Control de alineación de miembros de una estructura:
   Mediante ``align`` se puede especificar la alineación a tener en una
   estructura.

   Ejemplo::

      align (1)
      struct paquete_de_red {
         char   tipo;
         short valor;
      }
      // paquete_de_red.sizeof == 3



.. _d_high_level:

Programación de alto nivel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Programa de alto nivel se refiere a construcciones más avanzadas que un loop.
Expresiones semánticamente más ricas que permiten mayor expresividad al
programador o le permiten focalizarse de mejora manera en los algoritmos
independizándose del *hardware* o de como funciona una computadora. Es
exactamente el opuesto a :ref:`d_low_level`.

En general estas características tiene como efecto secundario una mejora de la
productividad de los programadores. D_ adopta herramientas de muchos lenguajes
de alto nivel, como Java_ y Python_, por ejemplo:

Manejo automático de memoria:
   al igual que C/C++ y prácticamente cualquier lenguaje imperativo maneja
   automáticamente el *stack*, pero a diferencia de la mayoría de los
   lenguajes de bajo nivel, D_ permite manejar el *heap* de manera automática
   también a través de un *recolección de basura*.

Sistema de paquetes y módulos (similar a Java_ o Python_):
   un módulo es una unidad que agrupa clases, funciones y cualquier otra
   construcción de lenguaje. Un paquete es una agrupación de módulos. D_
   asocia un módulo a un archivo fuente (y un archivo objeto cuando éste es
   compilado) y un paquete a un directorio. A diferencia de C/C++ no necesita
   de un preprocesador para incluir declaraciones de otros *módulos* (en C/C++
   no existe el concepto de módulo, solo de unidades de compilación).

   Ejemplo:

   ``a.d``::

      module a;
      void f() {}

   ``b.d``::

      module b;
      void f() {}

   ``c.d``::

         module c;
         import a;
         import b: f;
         a.f();
         b.f();
         f(); // ejecuta b.f()

Funciones y delegados:
   las funciones pueden ser sobrecargadas (funciones con el mismo nombre pero
   distinta cantidad o tipo de parámetros), pueden especificarse argumentos de
   entrada, salida o entrada/salida, argumentos por omisión o argumentos
   evaluados de forma perezosa (*lazy*). Además pueden tener una cantidad de
   argumentos variables pero manteniendo información de tipos (más seguro que
   C/C++).

   Los *delegados* son punteros a función con un contexto asociado. Este
   contexto puede ser un objeto (en cuyo caso la función es un método) o un
   *stack frame* (en cuyo caso la función es una función anidada).

   Además de esto los delegados son ciudadanos de primera clase
   [#1stclasscity]_, disponiendo de forma literal (delegado anónimo), lo que
   permite construcciones de alto nivel muy conveniente. Los argumentos
   evaluados de forma perezosa no son más que un delegado que se ejecuta solo
   cuando es necesario.

   .. [#1stclasscity] Por ciudadano de primera clase se entiende que se trata
      de un tipo soportado por completo por el lenguaje, disponiendo de
      expresiones literales anónimas, pudiendo ser almacenados en variables,
      estructuras de datos, teniendo una identidad intrínseca, más allá de un
      nombre dado, etc. En realidad los arreglos asociativos no pueden ser
      expresados como literales anónimos pero sí tienen una sintaxis especial
      soportada directamente por el lenguaje.

   Ejemplo::

      bool buscar(T[] arreglo, T item, bool delegate(T x, T y) igual) {
         foreach (t, arreglo)
            if (igual(t, elemento))
               return true;
         return false;
      }
      struct Persona {
         string nombre;
      }
      Persona[] personas;
      // llenas personas
      Persona p;
      p.nombre = "Carlos";
      bool encontrado = buscar(personas, p,
                                       (Persona x, Persona y) {
                                          return x.nombre == y.nombre;
                                       }
                                 );

Arreglos *dinámicos* y arreglos asociativos:
   los arreglos *dinámicos* son arreglos de longitud variable manejados
   automáticamente por el lenguaje (análogos al ``std::vector`` de C++).
   Soportan concatenación (a través del operador ``~``), rebanado o *slicing*
   (a través del operador ``[x..y]``) y chequeo de límites (*bound checking*).

   Los arreglos asociativos (también conocidos como *hashes* o diccionarios)
   también son provistos por el lenguaje.

   Ambos son ciudadanos de primera clase, disponiendo de forma literal.

   Ejemplo::

      int[] primos = [ 2, 3, 5, 7, 11, 13, 17, 19 ];
      primos ~= [ 23, 29 ];
      auto menores_que_10 = primos[0..4]; // [ 2, 3, 5, 7 ]
      int[string] agenda;
      agenda["Pepe"] = 5555_1234;

*Strings*:
   al igual que los delegados y arreglos dinámicos y asociativos, los
   *strings* son ciudadanos de primera clase, teniendo forma literal y siendo
   codificados en UTF-8/16/32. Son un caso particular de arreglo dinámico y es
   posible utilizarlos en sentencias ``switch``/``case``.

   Ejemplo::

      string s = "árbol";

      switch (s) {
         case "árbol":
            s = "tree";
         default:
            s = "";
      }

``typedef`` y ``alias``:
   el primero define un nuevo tipo basado en otro. A diferencia de C/C++ el
   tipo original no puede ser implícitamente convertido al tipo nuevo (excepto
   valores literales), pero la conversión es válida en el otro sentido
   (similar a los ``enum`` en C++). Por el contrario, ``alias`` es análogo al
   ``typedef`` de C/C++ y simplemente es una forma de referirse al mismo tipo
   con un nombre distinto.

   Ejemplo::

      typedef int tipo;
      int foo(tipo x) {}
      tipo t = 10;
      int i = 10;
      foo(t);
      foo(i); // error, no compila
      alias tipo un_alias;
      un_alias a = t;
      foo(a);

Documentación embebida:
   D_ provee un sistema de documentación embebida, análogo a lo que provee
   Java_ o Python_ en menor medida. Hay comentarios especiales del código que
   pueden ser utilizados para documentarlo de forma tal que luego el
   compilador pueda extraer esa información para generar un documento.

   Más información en http://www.digitalmars.com/d/1.0/ddoc.html

Números complejos:
   D_ soporta números complejos como ciudadanos de primera clase. Soporta
   forma literal de números imaginarios y complejos.

   Ejemplo::

      ifloat im = 5.0i;
      float   re = 1.0;
      cfloat c   = re + im; // c == 1.0 + 5.0i



Programación orientada a objetos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

La orientación a objetos es probablemente el paradigma más utilizado en la
actualidad a la hora de diseñar e implementar un programa. D_ provee muchas
herramientas para soportar este paradigma de forma confiable. Entre las
características más salientes se encuentran:

Objetos *pesados*:
   objetos polimórficos como los de cualquier lenguaje con orientación real
   a objetos. Estos objetos poseen una tabla virtual para *dispatch* dinámico,
   todos los métodos son virtuales a menos que se indique lo contrario
   y tienen semántica de referencia [#drefsem]_. Estos objetos tienen un
   *overhead* comparados a los objetos *livianos* pero aseguran una semántica
   segura para trabajar con orientación a objetos, evitando problemas con los
   que se enfrenta C++ (como *slicing* [#dslicing]_) debido a que permite
   semántica por valor [#dvalsem]_.

   .. [#drefsem] Semántica de referencia significa que el tipo es tratado como
      si fuera un puntero. Nunca se hacen copias del objeto, siempre se pasa
      por referencia.
   .. [#dslicing] Este problema se da en C++ cuando se pasa una clase derivada
      a una función que acepta una clase base por valor como parámetro. Al
      realizarse una copia de la clase con el constructor de copia de la clase
      base, se pierden (o *rebanan*) los atributos de la clase derivada, y la
      información de tipos en tiempo de ejecución (*RTTI*).
   .. [#dvalsem] Semántica de valor significa que el tipo es tratado como si
      fuera un valor concreto. En general se pasa por valor y se hacen copias
      a menos que se utilice explícitamente un puntero.

   D_ además soporta tipos de retorno covariantes para funciones virtuales.
   Esto significa que una función sobreescrita por una clase derivada puede
   retornar un tipo que sea derivado del tipo retornado por la función
   original sobreescrita.

   Ejemplo::

      class A { }
      class B : A { }

      class Foo {
         A test() { return null; }
      }

      class Bar : Foo {
         B test() { return null; } // sobreescribe y es covariante con Foo.test()
      }

   Más información en http://www.digitalmars.com/d/1.0/function.html

Interfaces:
   D_ no soporta herencia múltiple pero sí interfaces. Una interfaz es
   básicamente una tabla virtual, una definición de métodos virtuales que debe
   proveer una clase. Las interfaces no proveen una implementación de dichos
   métodos, ni pueden tener atributos. Esto simplifica mucho el lenguaje y no
   se pierde flexibilidad porque puede conseguirse el mismo efecto de tener
   herencia múltiple a través de interfaces y *mixins* para proveer una
   implementación o atributos en común a varias clases que implementan la
   misma interfaz.

Sobrecarga de operadores:
   la sobrecarga de operadores permite que un objeto tenga una sintaxis
   similar a un tipo de dato nativo. Esto es muy importante además para la
   programación genérica.

Clases anidadas:
   al igual que C (con respecto a ``struct``) y C++, pueden anidarse clases
   dentro de clases. D_ sin embargo provee la posibilidad de acceder
   a atributos de la instancia exterior desde la anidada.

   Ejemplo::

      class Exterior {
         int m;
         class Anidada {
            int foo() {
               return m; // ok, puede acceder a un miembro de Exterior
            }
         }
      }

   Esto tiene un pequeño *overhead* ya que la clase ``Anidada`` debe guardar
   un puntero a la clase ``Exterior``. Si no se necesita este comportamiento
   es posible evitar este *overhead* utilizando ``static``, en cuyo caso solo
   puede acceder a atributos estáticos de la clase ``Exterior``.

   Ejemplo::

      class Exterior {
         int m;
         static int n;
         static class Anidada {
            int foo() {
               //return m; // error, miembro de Exterior
               return n; // ok,   miembro estático de Exterior
            }
         }
      }


Propiedades (*properties*):
   en D_ se refiere a funciones miembro que pueden ser tratadas
   sintácticamente como campos de esa clase/estructura.

   Ejemplo::

      class Foo {
         int data() { return _data; } // propiedad de lectura
         int data(int value) { return _data = value; } // de escritura
         private int _data;
      }
      Foo f = new Foo;
      f.data = 1;       // llama a f.data(1)
      int i = f.data; // llama a f.data()

   Además tipos nativos, clases, estructuras y expresiones tienen
   *properties* predefinidos, por ejemplo:

   ``sizeof``:
      tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4).

   ``init``:
      valor de inicialización por omisión (ejemplo: ``float.init`` -> *NaN*
      [#dnan]_).

   .. [#dnan] Del inglés *Not A Number*, es un valor especial que indica que
      estamos ante un valor inválido.

   ``stringof``:
      representación textual del tipo (ejemplo: ``(1+2).stringof`` -> ``"1
      + 2"``).

   ``mangleof``:
      representación textual del tipo *mutilado* [#dmangle]_.

   .. [#dmangle] *Name mangling* es el nombre dado comunmente a una técnica
      necesaria para poder sobrecargar nombres de símbolos. Consiste en
      codificar los nombres de las funciones tomando como entrada el nombre de
      la función y la cantidad y tipo de parámetros, asegurando que dos
      funciones con el mismo nombre pero distintos parámetros (sobrecargada)
      tengan nombres distintos.

   ``alignof``
      alineación de una estructura o tipo.

   Estos son solo los *properties* predefinidos para todos los tipos, pero hay
   una cantidad considerable de *properties* extra para cada tipo.

   Más información sobre *properties* de clases en
   http://www.digitalmars.com/d/1.0/property.html#classproperties y sobre
   *properties* predefinidos en
   http://www.digitalmars.com/d/1.0/property.html



.. _d_dbc:

Programación confiable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Programación confiable se refiere a las capacidades o facilidades que provee
el lenguaje para evitar fallas de manera temprano (o la capacidad de evitar
que ciertas fallas puedan existir directamente). D_ presta particular atención
a esto y provee las siguientes herramientas:

Excepciones:
   D_ soporta excepciones de manera similar a Java_: provee ``try``, ``catch``
   y ``finally``. Esto permite que los errores difícilmente pasen
   silenciosamente sin ser detectados.

``assert``:
   es una condición que debe cumplirse siempre en un programa, como un chequeo
   de integridad. Esto es muy utilizado en C/C++, donde ``assert()`` es una
   *macro* que solo se compila cuando la *macro* ``NDEBUG`` no está definida.
   Esto permite eliminar los chequeos de integridad del programa, que pueden
   ser costosos, para versiones que se suponen estables.

   D_ lleva este concepto más allá y hace al ``assert`` parte del lenguaje.
   Si una verificación no se cumple, lanza una excepción. El ``assert`` no es
   compilado cuando se utiliza una opción del compilador.

   Ejemplo::

      File f = open("archivo");
      assert (f.ok());

Diseño por contrato:
   el diseño por contrato es un concepto introducido por el lenguaje Eiffel_
   a mediados/finales de los '80. Se trata de incorporar en el lenguaje las
   herramientas para poder aplicar verificaciones formales a las interfaces de
   los programas.

   D_ implementa las siguientes formas de diseño por contrato (todas se
   ejecutan siempre y cuando no se compile en modo *release*, de manera de no
   sacrificar *performance* cuando es necesario):

   Pre y post condiciones:
      Ejemplo::

         double raiz_cuadrada(double x)
         in { // pre-condiciones
            assert (x >= 0.0);
         }
         out (resultado) { // post-condiciones
            assert (resultado >= 0.0);
            if (x < 1.0)
               assert (resultado < x);
            else if (x > 1.0)
               assert (resultado > x);
            else
               assert (resultado == 1);
         }
         body {
            // implementación
         }

   Invariantes de representación:
      La invariante de representación es un método de una clase o estructura
      que es verificada cuando se completa su construcción, antes de la
      destrucción, antes y después de ejecutar cualquier función miembro
      pública y cuando se lo requiere de forma explícita utilizando
      ``assert``.

      Ejemplo::

         class Fecha {
               int dia;
               int hora;
               invariant() {
                  assert(1 <= dia && dia <= 31);
                  assert(0 <= hora && hora < 24);
               }
         }

   Más información en http://www.digitalmars.com/d/1.0/dbc.html

Pruebas unitarias:
   es posible incluir pequeñas pruebas unitarias en el lenguaje. Éstas son
   ejecutadas (cuando no se compila en modo *release*) al comenzar el
   programa, antes de que la función ``main()``.

   Ejemplo::

      unittest {
         Fecha fecha;
         fecha.dia = 5;
         assert (fecha.dia == 5);
         assert (fecha);
      }

Orden de construcción estática:
   a diferencia de C++, D_ garantiza el orden de inicialización de los
   módulos. Si bien en C++ no hay módulos si no unidades de compilación, es
   posible que se ejecute código antes del ``main()`` en C++, si hay, por
   ejemplo, instancias globales con un constructor definido. C++ no garantiza
   un orden de inicialización, lo que trae muchos problemas. En D_ se define
   el orden de inicialización y es el mismo orden en que el usuario importa
   los módulos.

Inicialización garantizada:
   todas las variables son inicializadas por el lenguaje (a menos que el
   usuario pida explícitamente que no lo sean). Siempre que sea posible se
   elijen valores de inicialización que permitan saber al programador que la
   variable no fue inicializada explícitamente, de manera de poder detectar
   errores de manera temprana.

   Ejemplo::

      double d;         // inicializado a NaN
      int x;             // inicializado a 0
      Fecha f;          // inicializado a null
      byte[5] a;       // inicializados todos los valores a 0
      long l = void; // NO inicializado (explícitamente)

*RAII* (*Resource Adquisition Is Initialization*):
   es una técnica muy utilizada en C++ que consiste en reservar recursos por
   medio de la construcción de un objeto y liberarlos cuando se libera éste.
   Al llamarse al destructor de manera automática cuando se sale del *scope*,
   se asegura que el recurso será liberado también.

   Esta técnica es la base para desarrollar código seguro en cuanto
   a excepciones (*exception-safe*) [SUTT99]_.

   En D_ no es tan común utilizar *RAII* dada la existencia del recolector de
   basura (en la mayoría de los casos el recurso a administrar es
   sencillamente memoria). Sin embargo en los casos en donde es necesario,
   puede utilizarse *RAII* mediante la utilización de la palabra reservada
   ``scope``, que limita la vida de un objeto un bloque de código.

   Ejemplo::

      class Archivo {
         this() { /* adquiere recurso */ }
         ~this() { /* libera recurso */ }
      }
      void f() {
         scope Archivo archivo = new Archivo;
         // uso de archivo
      } // en este punto se llama al destructor de archivo

Guardias de bloque (*scope guards*):
   además de poder limitar la vida de una instancia a un *scope*, es posible
   especificar un bloque de código arbitrario a ejecutar al abandonar un
   *scope*, ya sea cuando se sale del *scope* normalmente o por una falla.

   Ejemplo::

      int f(Lock lock) {
         lock.lock();
         scope (exit)
            lock.unlock();                  // ejecutado siempre que salga de f()
         auto trans = new Transaccion;
         scope (success)
            trans.commit();                // ejecutado si sale con "return"
         scope (failure)
            trans.rollback();             // ejecutado si sale por una excepción
         if (condicion)
            throw Exception("error"); // ejecuta lock.unlock() y trans.rollback()
         else if (otra_condicion)
            return 5;                         // ejecuta lock.unlock() y trans.commit()
         return 0;                            // ejecuta lock.unlock() y trans.commit()
      }

   Esta es una nueva forma de poder escribir código *exception-safe*, aunque
   el programador debe tener un poco más de cuidado de especificar las
   acciones a ejecutar al finalizar el *scope*.

Primitivas de sincronización de hilos:
   la programación multi-hilo está directamente soportada por el lenguaje,
   y se provee una primitiva de sincronización al igual que Java_. La palabra
   reservada ``synchronized`` puede aparecer como modificador de métodos (en
   cuyo caso se utiliza un *lock* por clase para sincronizar) o como una
   sentencia, en cuyo caso se crea un *lock* global por cada bloque
   ``synchronized`` a menos que se especifique sobre qué objeto realizar la
   sincronización. Por ejemplo::

      class Foo {
         synchronized void bar() { /* cuerpo */ }
      }

   Es equivalente a::

      class Foo {
         void bar() {
            synchronized (this) { /* cuerpo */ }
         }
      }


Compiladores
----------------------------------------------------------------------------

Hay, hasta el momento, 3 compiladores de D_ de buena calidad: DMD_, GDC_
y LDC_.

DMD_ es el compilador de referencia, escrito por `Walter Bright`_. El
*front-end* [#frontend]_ de este compilador ha sido liberado bajo licencia
Artistic_/GPL_ y es utilizado por los otros dos compiladores, por lo tanto en
realidad hay solo un compilador disponible con 3 *back-ends* [#backend]_
diferentes.

.. [#frontend] *Front-end* es la parte del compilador encargada de hacer el
   análisis léxico, sintáctico y semántico del código fuente, generando una
   representación intermedia que luego el *back-end* convierte a código de
   máquina.

.. [#backend] El *back-end* es la parte del compilador encargada de convertir
   la representación intermedia generada por el *front-end* a código de
   máquina.

Con `DMD 1.041`__ se publicó el código fuente completo del compilador, pero
con una licencia muy restrictiva para uso personal, por lo que el único efecto
logrado por esto es que la gente pueda mandar parches o correcciones del
compilador pero no lo convierte en `Software Libre`_, siendo el único de los
3 compiladores que no tiene esta característica.

__ http://www.digitalmars.com/d/1.0/changelog.html#new1_041

El compilador GDC_ es el *front-end* de DMD_ utilizando al compilador GCC_
como *back-end*. Fue un muy buen compilador pero en la actualidad está
abandonado. No hay un *release* desde agosto de 2007 y no hay actualizaciones
serias del código desde mediados de 2008, por lo que no parece haber muchas
probabilidades de que se siga manteniendo.

LDC_ es lo opuesto; un compilador joven, nacido a mediados de 2007 (aunque vio
la luz un año después aproximadamente), su primer *release* fue a principios
de 2009 y tuvo un crecimiento excepcional. En la actualidad inclusive pasa más
pruebas de estrés que el compilador de referencia DMD_.  Como *back-end*
utiliza LLVM_, otro proyecto joven y con una tasa de crecimiento muy alta.

Además de estos compiladores hay varios otros experimentales, pero ninguno de
ellos de calidad suficiente todavía. Por ejemplo hay un compilador
experimental que emite *CIL* (*Common Intermediate Language*), el *bytecode*
de `.NET`_, llamado DNet_. También hay un *fron-end* escrito en D_, llamado
Dil_

Originalmente, dado que GDC_ estaba siendo mantenido y que LDC_ no existía,
este trabajo iba a ser realizado utilizando GDC_ como compilador, dado que al
ser `Software Libre`_ podía ser modificado de ser necesario. Finalmente,
gracias a la excepcional tasa de crecimiento de LDC_ y al abandono de GDC_ se
terminó desarrollando el trabajo utilizando LDC_.



.. include:: links.rst

.. vim: set ts=3 sts=3 sw=3 et tw=78 :