X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/13c8978d868a3949d3dbf47a2280e2625288f47a..7cbea236e3150a98f5a5d7e43637efe006a135a8:/source/d.rst diff --git a/source/d.rst b/source/d.rst index 35591d4..87acdcc 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, CORREGIDO + 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 @@ -270,7 +270,7 @@ Iteración sobre colecciones (``foreach``): 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:: @@ -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*: 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:: @@ -490,8 +490,8 @@ Objetos y arreglos *livianos*: Rendimiento: la :ref:`d_generic` permite realizar muchas optimizaciones ya que se - resuelve en tiempo de compilación y por lo tanto aumentando la - rendimiento 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: El tipo ``real`` de D_ tiene precisión de 80 bits si la plataforma lo @@ -518,12 +518,12 @@ Programación de alto nivel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 permiten +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: @@ -531,7 +531,7 @@ 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_): un módulo es una unidad que agrupa clases, funciones y cualquier otra @@ -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; } @@ -666,7 +666,7 @@ Arreglos *dinámicos* y arreglos asociativos: foo(a); Documentación embebida: - D_ provee un sistema de documentación embebida, análogo a lo que provee + 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. @@ -814,8 +814,8 @@ Propiedades (*properties*): estamos ante un valor inválido. ``stringof``: - representación textual del tipo (ejemplo: ``(1+2).stringof`` -> ``"1 - + 2"``). + representación textual del símbolo o expresión (ejemplo: + ``(1+2).stringof`` -> ``"1 + 2"``). ``mangleof``: representación textual del tipo *mutilado* [#dmangle]_. @@ -1069,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