X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/dc2ae988be0f3455c4fabee6b43de41b0be6745c..869d3714190bbd53b65eee4e3e352f7035277a3e:/source/d.rst?ds=inline

diff --git a/source/d.rst b/source/d.rst
index 3fd0ce8..0dc123d 100644
--- a/source/d.rst
+++ b/source/d.rst
@@ -2,7 +2,7 @@
 .. 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
+   ESTADO: TERMINADO, CORREGIDO, REVISADO
 
 
 .. _d_lang:
@@ -56,15 +56,15 @@ y funciones *puras* [#dpure]_ (a mediados de 2007).
    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.
+introduciendo solo cambios que arreglen errores (*bug fixes*), agregando
+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
@@ -91,20 +91,20 @@ 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
+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).
+tiene dos 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 considerable 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
+fragmentada entre las dos 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
@@ -138,7 +138,7 @@ 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
+sintácticamente (*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:
@@ -190,7 +190,7 @@ Python_).
 D_ provee las siguientes herramientas para realizar programación genérica
 y meta-programación:
 
-``if`` estático (``static if``):
+``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).
@@ -202,9 +202,9 @@ y meta-programación:
 
    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``):
+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.
+   de su valor de inicialización.
 
    Ejemplo::
 
@@ -224,7 +224,7 @@ Inferencia de tipos básica implícita y explícita (mediante ``typeof``):
 
    Más información en http://www.digitalmars.com/d/1.0/declaration.html#typeof
 
-Iteración sobre colecciones (``foreach``):
+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``.
@@ -236,8 +236,8 @@ Iteración sobre colecciones (``foreach``):
       foreach (i; a)
          total += i;
 
-*Templates*:
-   clases y funciones pueden ser parametrizadas. Esto permite desarrollar
+*Templates*
+   clases y funciones pueden ser generalizadas. 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
@@ -249,11 +249,11 @@ Iteración sobre colecciones (``foreach``):
       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
+   Además se pueden definir bloques de declaraciones generalizadas (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.
+   clases). Un bloque generalizado puede verse como una especie de módulo.
 
    Ejemplo::
 
@@ -265,19 +265,19 @@ Iteración sobre colecciones (``foreach``):
       bloque!(int, float).x = 5;
       float f = bloque!(int, float).foo(7);
 
-   La utilidad más prominente de los bloques parametrizados se da al
+   La utilidad más prominente de los bloques generalizados se da al
    acompañarse de *mixins*.
 
-Instanciación implícita de funciones parametrizadas:
+Instanciación implícita de funciones generalizadas
    el lenguaje es capaz de deducir los parámetros siempre que no hayan
-   ambigüedades
+   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*:
+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
@@ -300,7 +300,7 @@ Especialización explícita y parcial de *templates*:
       float v = 5.0f, w = 6.0f;
       auto f = sumar(&v, &w); // f == 11.0f
 
-Tipos, valores (incluyendo *strings*) y *templates* como parámetros:
+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
@@ -310,15 +310,15 @@ Tipos, valores (incluyendo *strings*) y *templates* como parámetros:
 
       template hash(string s, uint so_far=0) {
          static if (s.length == 0)
-            const hash = sofar;
+            const hash = so_far;
          else
-            const hash = hash!(s[1 .. length], sofar * 11 + s[0]);
+            const hash = hash!(s[1 .. length], so_far * 11 + s[0]);
       }
       string s = hash!("hola"); // calculado en tiempo de compilación
 
-Cantidad de parámetros variables para *templates*:
+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.
+   tomar una cantidad variable de parámetros en tiempo de compilación.
 
    Ejemplo::
 
@@ -330,12 +330,12 @@ Cantidad de parámetros variables para *templates*:
       }
       double d = sumar(1, 2.0, 3.0f, 4l); // d == 10.0
 
-*CTFE* (*compile-time function execution*):
+*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
+   ejecución en ejecución al momento de compilar, mejorando el rendimiento
+   o permitiendo formas avanzadas de meta-programación. Esta característica se
    vuelve particularmente útil al combinarse con *string mixins*.
 
    Ejemplo::
@@ -351,7 +351,7 @@ Cantidad de parámetros variables para *templates*:
 
    Esta característica es vital para evitar la duplicación de código.
 
-*Mixins*, incluyendo *string mixins*:
+*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
@@ -393,7 +393,7 @@ Cantidad de parámetros variables para *templates*:
 
    Más información en http://www.digitalmars.com/d/1.0/mixin.html
 
-Expresiones ``is``:
+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
@@ -426,11 +426,11 @@ 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:
+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*:
+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.
 
@@ -439,10 +439,10 @@ Provee acceso a *assembly*:
    compiladores incluso cuando se utiliza *assembly* (mientras que no se
    cambie de arquitectura, por supuesto).
 
-``goto``:
+``goto``
    al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``.
 
-Compatibilidad con C:
+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)``.
@@ -455,16 +455,16 @@ Compatibilidad con C:
       extern (C) printf(const char* format, ...);
       printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C
 
-Manejo de memoria explícito:
-   permite alocar estructuras en el *stack* o en el *heap*, haciendo uso de
+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*:
+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 alocarse un arreglo dinámicamente usando ``malloc()``
+   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``
@@ -488,16 +488,16 @@ Objetos y arreglos *livianos*:
       timeval tv;
       gettimeofday(&tv, null);
 
-Rendimiento:
+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.
+   resuelve en tiempo de compilación y por lo tanto aumenta el rendimiento en
+   la ejecución.
 
-Número de punto flotante de 80 bits:
+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:
+Control de alineación de miembros de una estructura
    Mediante ``align`` se puede especificar la alineación a tener en una
    estructura.
 
@@ -517,23 +517,23 @@ Control de alineación de miembros de una estructura:
 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`.
+Programación de alto nivel se refiere a construcciones más avanzadas que una
+sentencia para iterar; expresiones con una semántica más ricas que proveen de
+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
+En general estas características tienen 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:
+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*.
+   también a través de un *recolector de basura*.
 
-Sistema de paquetes y módulos (similar a Java_ o Python_):
+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
@@ -562,7 +562,7 @@ Sistema de paquetes y módulos (similar a Java_ o Python_):
          b.f();
          f(); // ejecuta b.f()
 
-Funciones y delegados:
+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
@@ -592,7 +592,7 @@ Funciones y delegados:
 
       bool buscar(T[] arreglo, T item, bool delegate(T x, T y) igual) {
          foreach (t, arreglo)
-            if (igual(t, elemento))
+            if (igual(t, item))
                return true;
          return false;
       }
@@ -609,7 +609,7 @@ Funciones y delegados:
                                        }
                                  );
 
-Arreglos *dinámicos* y arreglos asociativos:
+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*
@@ -628,7 +628,7 @@ Arreglos *dinámicos* y arreglos asociativos:
       int[string] agenda;
       agenda["Pepe"] = 5555_1234;
 
-*Strings*:
+*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
@@ -645,7 +645,7 @@ Arreglos *dinámicos* y arreglos asociativos:
             s = "";
       }
 
-``typedef`` y ``alias``:
+``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
@@ -665,15 +665,15 @@ Arreglos *dinámicos* y arreglos asociativos:
       un_alias a = t;
       foo(a);
 
-Documentación embebida:
-   D_ provee un sistema de documentación embebida, análogo a lo que provee
+Documentación embebida
+   D_ provee un sistema de documentación embebida, análogo a lo que proveen
    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:
+Números complejos
    D_ soporta números complejos como ciudadanos de primera clase. Soporta
    forma literal de números imaginarios y complejos.
 
@@ -693,9 +693,9 @@ 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 *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,
+   a objetos. Estos objetos poseen una tabla virtual para despacho 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
@@ -735,7 +735,7 @@ Objetos *pesados*:
 
    Más información en http://www.digitalmars.com/d/1.0/function.html
 
-Interfaces:
+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
@@ -745,12 +745,12 @@ Interfaces:
    implementación o atributos en común a varias clases que implementan la
    misma interfaz.
 
-Sobrecarga de operadores:
+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:
+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.
@@ -785,7 +785,7 @@ Clases anidadas:
       }
 
 
-Propiedades (*properties*):
+Propiedades (*properties*)
    en D_ se refiere a funciones miembro que pueden ser tratadas
    sintácticamente como campos de esa clase/estructura.
 
@@ -803,21 +803,21 @@ Propiedades (*properties*):
    Además tipos nativos, clases, estructuras y expresiones tienen
    *properties* predefinidos, por ejemplo:
 
-   ``sizeof``:
+   ``sizeof``
       tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4).
 
-   ``init``:
+   ``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"``).
+   ``stringof``
+      representación textual del símbolo o expresión (ejemplo:
+      ``(1+2).stringof`` -> ``"1 + 2"``).
 
-   ``mangleof``:
+   ``mangleof``
       representación textual del tipo *mutilado* [#dmangle]_.
 
    .. [#dmangle] *Name mangling* es el nombre dado comunmente a una técnica
@@ -840,6 +840,8 @@ Propiedades (*properties*):
 
 
 
+.. _d_dbc:
+
 Programación confiable
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -848,12 +850,12 @@ 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:
+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``:
+``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.
@@ -869,7 +871,7 @@ Excepciones:
       File f = open("archivo");
       assert (f.ok());
 
-Diseño por contrato:
+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
@@ -877,9 +879,9 @@ Diseño por contrato:
 
    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):
+   sacrificar rendimiento cuando es necesario):
 
-   Pre y post condiciones:
+   Pre y post condiciones
       Ejemplo::
 
          double raiz_cuadrada(double x)
@@ -899,7 +901,7 @@ Diseño por contrato:
             // implementación
          }
 
-   Invariantes de representació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
@@ -919,7 +921,7 @@ Diseño por contrato:
 
    Más información en http://www.digitalmars.com/d/1.0/dbc.html
 
-Pruebas unitarias:
+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()``.
@@ -933,7 +935,7 @@ Pruebas unitarias:
          assert (fecha);
       }
 
-Orden de construcción estática:
+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
@@ -942,7 +944,7 @@ Orden de construcción estática:
    el orden de inicialización y es el mismo orden en que el usuario importa
    los módulos.
 
-Inicialización garantizada:
+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
@@ -951,13 +953,13 @@ Inicialización garantizada:
 
    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
+      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*):
+*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*,
@@ -983,7 +985,7 @@ Inicialización garantizada:
          // uso de archivo
       } // en este punto se llama al destructor de archivo
 
-Guardias de bloque (*scope guards*):
+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.
@@ -993,24 +995,24 @@ Guardias de bloque (*scope guards*):
       int f(Lock lock) {
          lock.lock();
          scope (exit)
-            lock.unlock();                  // ejecutado siempre que salga de f()
+            lock.unlock();              // ejecutado siempre que salga de f()
          auto trans = new Transaccion;
          scope (success)
-            trans.commit();                // ejecutado si sale con "return"
+            trans.commit();             // ejecutado si sale con "return"
          scope (failure)
-            trans.rollback();             // ejecutado si sale por una excepción
+            trans.rollback();           // ejecutado si sale por una excepción
          if (condicion)
-            throw Exception("error"); // ejecuta lock.unlock() y trans.rollback()
+            throw Exception("error");   // 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()
+            return 5;                   // lock.unlock() y trans.commit()
+         return 0;                      // 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:
+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
@@ -1067,17 +1069,26 @@ 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.
+LDC_ es lo opuesto; un compilador joven, nacido a mediados de 2007 como un
+proyecto personal y privado de Tomas Lindquist Olsen, que estuvo trabajando de
+forma privada en el proyecto hasta mediados de 2008, momento en que decide
+publicar el código mediante una licencia libre. Para ese entonces el
+compilador era todavía inestable y faltaban implementar varias cosas, pero el
+estado era lo suficientemente bueno como para captar varios colaboradores muy
+capaces, como `Christian Kamm`_ y Frits Van Bommel que rápidamente se
+convirtieron en parte fundamental del proyecto. El primer *release* (0.9) de
+una versión relativamente completa y estable fue a principios de 2009 que fue
+seguido por la versión 0.9.1 que como puntos más salientes agregó soporte para
+x86-64 y assembly embebido. El compilador tuvo y sigue teniendo 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_
+de `.NET`_, llamado DNet_. También hay un *front-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
@@ -1089,4 +1100,4 @@ terminó desarrollando el trabajo utilizando LDC_.
 
 .. include:: links.rst
 
-.. vim: set ts=3 sts=3 sw=3 et tw=78 :
+.. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :