typhon.html

   1 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   2 <BASE HREF="http://wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage"><table border=1 width=100%><tr><td><table border=1 bgcolor=#ffffff cellpadding=10 cellspacing=0 width=100% color=#ffffff><tr><td><font face=arial,sans-serif color=black size=-1>Ésta es la versión <b><font color=#0039b6>G</font> <font color=#c41200>o</font> <font color=#f3c518>o</font> <font color=#0039b6>g</font> <font color=#30a72f>l</font> <font color=#c41200>e</font></b> <a href="http://www.google.com/intl/es/help/features.html#cached"><font color=blue>guardada en el caché</font></a> de la <A HREF="http://wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage"><font color=blue>http://wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage</font></a> obtenida el 28 Ago 2005 07:43:43 GMT.<br>
   3 La caché de <b><font color=#0039b6>G</font> <font color=#c41200>o</font> <font color=#f3c518>o</font> <font color=#0039b6>g</font> <font color=#30a72f>l</font> <font color=#c41200>e</font></b> es la instantánea de la página que tomamos cuando exploramos la Web en forma automática.<br>
   4 Es posible que la página haya cambiado desde entonces. Haga clic aquí para ver la <A HREF="http://wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage"><font color=blue>página actual</font></a> sin resaltar.<br>
   5 Esta página guardada en el caché puede hacer referencia a imágenes que ya no están disponibles. Haga clic aquí para obtener únicamente el <A HREF="http://66.102.7.104/search?q=cache:UudIjxQfm7IJ:wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage+typhonlanguage&hl=es&lr=&strip=1"><font color=blue>texto guardado en el caché</font></a>.<br>Para vincularse a esta página o para marcarla, utilice el siguiente url:  <code>http://www.google.com/search?q=cache:UudIjxQfm7IJ:wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage+typhonlanguage&amp;hl=es</code></font><br><br><center><font size=-2><i>Google no tiene relación con los autores de esta página ni es responsable de su contenido.</i></font></center></td></tr>
   6 <tr><td>
   7 <table border=0 cellpadding=0 cellspacing=0><tr><td><font face=arial,sans-serif color=black size=-1>Se han resaltado estos términos de búsqueda:&nbsp;</font></td><td bgcolor=#ffff66><B><font face=arial,sans-serif color=black size=-1>typhonlanguage&nbsp;</font></B></td></tr></table>
   8 </td></tr></table></td></tr></table>
   9 <hr>
  10 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  11 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es-ar" lang="es-ar">
  12 <head>
  13  <title>  TyphonLanguage &lt; Main &lt; TWiki</title>
  14  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />  %HTTP_EQUIV_ON_VIEW%
  15  <base href="http://wiki.lugmen.org.ar/twiki/view/Main/TyphonLanguage" />
  16
  17 </head>
  18 <body bgcolor="#ffffff">
  19 <a name="PageTop"></a>
  20 <form name="main" action="/twiki/view/Main/TyphonLanguage"> %BROADCASTMESSAGE%
  21 <table width="100%" border="0" cellpadding="3" cellspacing="0">
  22  <tr>
  23   <td bgcolor="#FFFFC0" rowspan="2" valign="top" width="1%">
  24     <a href="%WIKILOGOURL%"><img src="%WIKILOGOIMG%" border="0" alt="%WIKILOGOALT%" /></a>
  25    </td><td>
  26    <a href="http://wiki.lugmen.org.ar/twiki/view/Main/WebHome">TWiki</a>
  27    &gt; <a href="http://wiki.lugmen.org.ar/twiki/view/Main/WebHome">Main</a>
  28    &gt;
  29    <font size="+1"><b><B style="color:black;background-color:#ffff66">TyphonLanguage</B></b>   </font>
  30   </td><td align="right">
  31    <font size="-2">TWiki webs: <br />
  32    %WIKIWEBLIST% </font>
  33   </td>
  34  </tr>
  35  <tr bgcolor="#FFFFC0">
  36   <td colspan="2">
  37  Main . {  <a class="twikiLink" href="/twiki/view/Main/TWikiUsers">Integrantes</a> %SEPB% <a class="twikiLink" href="/twiki/view/Main/ProyectosLugmen">Proyectos</a> %SEPB% <a class="twikiLink" href="/twiki/view/Main/EventosLugmen">Eventos</a> %SEPB% <a class="twikiLink" href="/twiki/view/Main/AsoCSFDL">ACSFDL</a> %SEPB% <a class="twikiLink" href="/twiki/view/Main/WebIndex">Índice</a> %SEPB% <a class="twikiLink" href="/twiki/view/Main/WebChanges">Cambios</a>  }
  38   </td>
  39  </tr>
  40 </table>
  41 </form>
  42 <h1><a name="Contenidos"> </a> Contenidos </h1>
  43 <p />
  44 <div class="twikiToc">
  45 <ul>
  46 <li> <a href="#Contenidos">Contenidos</a>
  47 </li>
  48 <li> <a href="#Qué_es_Typhon">Qué es Typhon?</a>
  49 <ul>
  50 <li> <a href="#Por_qué_C">Por qué C++?</a>
  51 </li>
  52 <li> <a href="#Por_qué_Python">Por qué Python?</a>
  53 </li>
  54 </ul>
  55 </li>
  56 <li> <a href="#Qué_significa_Typhon">Qué significa Typhon</a>
  57 </li>
  58 <li> <a href="#Alcance_del_Lenguaje">Alcance del Lenguaje</a>
  59 <ul>
  60 <li> <a href="#Sintaxis">Sintaxis</a>
  61 </li>
  62 <li> <a href="#Definiciones">Definiciones</a>
  63 </li>
  64 <li> <a href="#Características_aún_no_definidas">Características aún no definidas</a>
  65 <ul>
  66 <li> <a href="#Modo_de_iterar_una_secuencia">Modo de iterar una secuencia</a>
  67 </li>
  68 <li> <a href="#Uso_de_typeof">Uso de typeof</a>
  69 </li>
  70 <li> <a href="#Literales_de_strings">Literales de strings</a>
  71 </li>
  72 <li> <a href="#Palabra_reservada_block">Palabra reservada block</a>
  73 </li>
  74 <li> <a href="#Comentarios">Comentarios</a>
  75 </li>
  76 <li> <a href="#Compilación_condicional">Compilación condicional</a>
  77 </li>
  78 <li> <a href="#class_vs_struct">class vs. struct</a>
  79 </li>
  80 </ul>
  81 </li>
  82 </ul>
  83 </li>
  84 <li> <a href="#Ejemplos">Ejemplos</a>
  85 </li>
  86 <li> <a href="#Links">Links</a>
  87 </li>
  88 </ul>
  89 </div>
  90 <p />
  91 <h1><a name="Qué_es_Typhon"> </a><a name="Qué_es_Typhon_"> </a> Qué es Typhon? </h1>
  92 Typhon es (o será) un lenguaje de programación basado en C++ y Python.
  93 Typhon tendrá sintaxis al estilo Python y será traducido a C++ de forma lo
  94 más directa posible.
  95 <p />
  96 <h2><a name="Por_qué_C"> </a><a name="Por_qué_C_"> </a> Por qué C++? </h2>
  97 Porque es un lenguaje compilado eficiente y estándar, que provee una biblioteca
  98 lo suficientemente completa como para no necesitar mucho más para escribir
  99 cualquier programa. Porque dicha biblioteca estándar define ''interfaces'' que,
 100 a pesar de no tener soporte en el lenguaje (por eso surge Typhon también), hace
 101 que puedan usarse de forma consistente. Porque es extremadamente flexible y
 102 poderoso, porque es compatible con C, con todo lo que eso significa (que no es
 103 para nada poco).
 104 <p />
 105 Bueno, de más está decir que hacer un lenguaje compilado nuevo (sin traducirlo a
 106 alguno existente) no sólo es un trabajo excesivamente monstruoso y para el cual,
 107 al menos yo (luca) no estoy capacitado, sino que sería un reinventar un poco la
 108 rueda.
 109 <p />
 110 <h2><a name="Por_qué_Python"> </a><a name="Por_qué_Python_"> </a> Por qué Python? </h2>
 111 Python es uno de los mejores lenguajes de alto nivel y su sintaxis simple
 112 y clara es una de las principales razones. Python se puede leer de una forma
 113 muy natural y aún así, no es para nada tedioso de escribir, de hecho es uno
 114 de los lenguajes que más rápido puede tipearse. Python además obliga a
 115 producir código legible, al hacer checheo de identación, otra característica
 116 bastante deseable.
 117 <p />
 118 Por último, Python y C++ son parecidos en cuanto a las características que ofrecen,
 119 al menos son los únicos 2 lenguajes que conozco que soportan herencia múltiple,
 120 por ejemplo.
 121 <p />
 122 <h1><a name="Qué_significa_Typhon"> </a> Qué significa Typhon </h1>
 123 Luca un día se despertó cruzado (creo que después de alguna discusión sobre Mono
 124 con gazer :) y se preguntó por qué catso no hay ningún lenguaje compilado de
 125 relativo alto nivel. Entre otras cosas estuvo jugando con Pyrex (un lenguaje
 126 <em>python-like</em> para hacer <em>wrappers</em> de C para Python); entre idas y venidas, se
 127 pensó en hacer que Python se traduzca a una serie de clases predefinidas y usar
 128 conteo de referencias para el manejo de memoria, etc; todo como para poder compilar
 129 Python casi igual a como lo conocemos ahora traduciéndolo a C++. Entre esas ideas,
 130 en algún momento alberto dijo "Python con tipos" y de ahí pensé en Typed Python y
 131 vi la T y la Y muy cerca y pensé que empezando con Ty (de Typed) podría armar un
 132 anagrama de Python. Lo obvio resultó <strong>Typhon</strong>.
 133 <p />
 134 Luego investigando el nombre, Typhon resulta ser una criatura de la
 135 <a href="http://www.classicsunveiled.com/mythnet/html/creature.html" target="_top">mitología griega</a>
 136 (un hombre/dragon con mil cabezas) al igual que Python (una especie de serpiente
 137 gigante); pero hay más aún.
 138 <p />
 139 Tanto Typhon como Python fueron <em>monstruos</em> creados por los viejos dioses para
 140 evitar que los dioes del Olimpo tomaran control del <em>bajomundo</em>.
 141 <p />
 142 Así que nombre más acertado para este lenguaje, difícilmente exista ;)
 143 <p />
 144 <h1><a name="Alcance_del_Lenguaje"> </a> Alcance del Lenguaje </h1>
 145 El lengueaje pretende dar acceso a un <em>subset</em> de C++ a través de sintaxis Python.
 146 Es decir, la traducción a C++ será lo más directa posible evitando así cualquier
 147 tipo de necesidad de traducción (<em>bindings</em>) para usar bibliotecas escritas tanto
 148 en C como en C++. Sólo se asumen cosas en cuanto a <em>interfaces</em> provistas por la
 149 <a href="http://www.sgi.com/tech/stl/" target="_top">STL</a>, como
 150 <a href="http://www.sgi.com/tech/stl/ForwardContainer.html" target="_top">Forward Containers</a>,
 151 <a href="http://www.sgi.com/tech/stl/Iterators.html" target="_top">Iterators</a>, etc. Para sacar
 152 todo el jugo a Typhon los tipos de datos más complejos deben estar escritos
 153 siguiendo el estilo de la STL (cosa que ya está pasando actualmente, las mejores
 154 bibliotecas en C++ como <a href="http://www.gtkmm.org/" target="_top">gtkmm</a>,
 155 <a href="http://libxmlplusplus.sourceforge.net/" target="_top">libxml2++</a>,
 156 <a href="http://www.gnu.org/software/cgicc/cgicc.html" target="_top">cgicc</a>, etc interaccionan bien
 157 con la STL y proveen interfaces similares).
 158 <p />
 159 <h2><a name="Sintaxis"> </a> Sintaxis </h2>
 160 En <span class="twikiNewLink" style='background : #FFFFCE;'><font color="#0000FF">TyphonSyntax</font><a href="/twiki/edit/Main/TyphonSyntax?topicparent=Main.TyphonLanguage"><sup>?</sup></a></span> está especificada la sintaxis del lenguaje, en notación
 161 <a href="http://www.garshol.priv.no/download/text/bnf.html" target="_top">EBNF</a> (o algo parecido,
 162 está basado en la especificación de Python).
 163 <p />
 164 <h2><a name="Definiciones"> </a> Definiciones </h2>
 165 Acá vamos a ir agregando cosas que definamos en cuanto al lenguaje:
 166 <ul>
 167 <li> Va a ser un subset de C++, que provea básicamente lo mismo que provee
 168      Python. Cualquier cosa más allá de eso tendrá que hacerse en C++.
 169 </li>
 170 <li> Puede verse de la forma inversa, también va a ser un subset de python si lo
 171      miramos desde el otro punto de vista (hay cosas como <code>yield</code> o formas
 172      <code>lambda</code> que no van a estar).
 173 </li>
 174 <li> No va a <em>hardcodear</em> tipos de datos. Sin embargo <strong>sí</strong> se va a asumir una
 175      <em>interfaz</em> tipo STL. Es decir el <em>foreach</em> se traducirá a iteradores del
 176      estilo de la STL. Para hacer un <em>foreach</em> sobre cualquier tipo, este tipo
 177      va a tener que cumplir el modelo de
 178      <a href="http://www.sgi.com/tech/stl/ForwardContainer.html" target="_top">Forward Container</a>
 179      en el sentido definido por la STL.
 180 </li>
 181 <li> Se va a <em>optimizar para el caso general</em> (2004 (c) Alberto Bertogli :D).
 182      Es decir, las cosas que se hacen más frecuentemente deberían ser la que mejor
 183      soporte del lenguaje tengan.
 184 </li>
 185 </ul>
 186 <p />
 187 <h2><a name="Características_aún_no_definidas"> </a> Características aún no definidas </h2>
 188 <h3><a name="Modo_de_iterar_una_secuencia"> </a> Modo de iterar una secuencia </h3>
 189 <strong>Prioridad:</strong> Alta
 190 <p />
 191 En C++ tendríamos 2 formas básicas de traducir:
 192 <hr />
 193 <pre>
 194 for item_t i in seq_t seq:
 195 </pre>
 196 <hr />
 197 por copia y por referencia. A su vez, cada una de estas formas puede ser
 198 constante o no, lo que nos da 4 posibilidades:
 199 <ol>
 200 <li> Que <code>i</code> sea una copia al ítem en <code>seq</code>
 201 </li>
 202 <li> Que <code>i</code> sea una copia constante al ítem de <code>seq</code>
 203 </li>
 204 <li> Que <code>i</code> sea una referencia al ítem de <code>seq</code>
 205 </li>
 206 <li> Que <code>i</code> sea una referencia constante al ítem de <code>seq</code>
 207 </li>
 208 </ol>
 209 Hacer una copia sería costoso en varios casos (de hecho en todo tipo de dato
 210 que ocupe más de lo que ocupa un puntero) y una copia constante sería demasiado
 211 raro que tenga alguna utilidad práctica. Por lo que nos queda decidir entre
 212 referencia o const referencia.
 213 <p />
 214 Probablemente lo más intuitivo (aunque <strong>no</strong> lo más seguro) sea tener una
 215 referencia modificable, y es esto lo que debería usarse por omisión según la
 216 premisa <em>optimizar para el caso general</em> . A esto se suma que iterar con una
 217 referencia constante sería bastante claro con una construcción como:
 218 <hr />
 219 <pre>
 220 for const item_t i in seq_t seq:
 221 </pre>
 222 <hr />
 223 En el caso inverso no hay ninguna palabra reservada lo suficientemente clara y
 224 realmente sería menos intuitivo (aunque menos suceptible a errores, al menos yo
 225 tengo la teoría de que todo debería ser constante a menos que se pueda demostrar
 226 que <strong>necesita</strong> ser variable :).
 227 <p />
 228 En caso de necesitarse una copia (querer modificar <code>i</code> dentro del cuerpo del
 229 <code><b>for</b></code> sin que los cambios se reflejen en los ítems de <code>seq</code>), siempre se puede
 230 hacer una copia explícita:
 231 <hr />
 232 <pre>
 233 for item_t i in seq_t seq:
 234     item_t copia = i
 235     copia += 2 * seq.size()
 236     # etc.
 237 </pre>
 238 <hr />
 239 <p />
 240 <h4><a name="Implementación"> </a> Implementación </h4>
 241 <hr />
 242 <pre>
 243 for item_t i in seq_t seq:
 244 </pre>
 245 <hr />
 246 se traduciría:
 247 <hr />
 248 <pre>
 249 for (seq_t::iterator ___i = seq.begin(); ___i != seq.end(); ++___i)
 250 {
 251     item_t&amp; i = *___i; // Referencia
 252     // ...
 253 }
 254 </pre>
 255 <hr />
 256 Mientras que:
 257 <hr />
 258 <pre>
 259 for const item_t i in seq_t seq:
 260 </pre>
 261 <hr />
 262 se traduciría:
 263 <hr />
 264 <pre>
 265 for (seq_t::const_iterator ___i = seq.begin(); ___i != seq.end(); ++___i)
 266 {
 267     const item_t&amp; i = *___i; // Referencia constante
 268     // ...
 269 }
 270 </pre>
 271 <hr />
 272 <p />
 273 <h3><a name="Uso_de_typeof"> </a> Uso de typeof </h3>
 274 <strong>Prioridad:</strong> Media
 275 <p />
 276 <a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Typeof.html#Typeof" target="_top">typeof()</a>
 277 es una extensión de GNU para C/C++, para obtener el tipo de una expresión en
 278 tiempo de compilación. El uso de esta extensión simplificaría considerablemente
 279 la implementación de la deducción de tipos para el <code><b>for</b></code> y otras construcciones,
 280 pudiéndose llegar a hacer prácticamente cualquier declaración de una variable con
 281 tipo implícito (siempre y cuando se la inicialice en la declaración). Manteniendo
 282 una tabla de símbolos y <em>forward declarations</em> podría evitarse el uso de
 283 <code><b>typeof</b></code>, pero los <em>forward declarations</em> pueden convertirse en algo muy tedioso
 284 e inecesario. Como siempre, se puede llegar a un balance. La deducción de tipos
 285 siempre será opcional (para poder tener mayor control de las variables), por lo
 286 que puede agregarse algún tipo de opción al <em>compilador</em> (me refiero al traductor
 287 de Typhon a C++) para hacer uso o no de <code><b>typeof</b></code>. Si no se usa <code><b>typeof</b></code> el
 288 código tendrá que ser inevitablemente más redundante (tendrán que especificarse
 289 los tipos de más variables explícitamente y usar <em>forward declarations</em>) pero
 290 permitirá generar código ISO C++ que es una alta prioridad en Typhon.
 291 <p />
 292 <h4><a name="Implementación"> </a> Implementación </h4>
 293 El principal uso sería en un bloque <code><b>for</b></code>:
 294 <hr />
 295 <pre>
 296 for i in seq:
 297 </pre>
 298 <hr />
 299 se puede traducir a:
 300 <hr />
 301 <pre>
 302 for (typeof(seq.begin()) ___i = seq.begin(); ___i != seq.end(); ++___i)
 303 {
 304     typeof(*___i)&amp; i = *___i;
 305     // ...
 306 }
 307 </pre>
 308 <hr />
 309 Sin tener absolutamente ninguna información sobre <code>seq</code>, ni sobre el tipo de elemento
 310 que contiene.
 311 <p />
 312 Esto podría llevarse más lejos y usar <em>tipos implícitos</em>:
 313 <hr />
 314 <pre>
 315 int f(): return 5
 316 int main():
 317     n = f() # n es una declaración implícita, con el tipo de f(), en este caso int
 318     return 0
 319 </pre>
 320 <hr />
 321 esto se traduciría a:
 322 <hr />
 323 <pre>
 324 int f()
 325 {
 326     return 5;
 327 }
 328 int main()
 329 {
 330     typeof(f()) n = f(); // n tiene el tipo devuelto por f(), gracias al uso de typeof
 331     return 0;
 332 }
 333 </pre>
 334 <hr />
 335 De nuevo, a pesar de que pueda ser conveniente, me parece muy suceptible
 336 a errores, ya que cualquier asignación se convertiría en una declaración
 337 implícita, haciendo que un <em>typo</em> en el nombre de una variable sea un <em>bug</em>
 338 muy difícil de encontrar (problema actual de la mayoría de los lenguajes
 339 interpretados).
 340 <p />
 341 <h4><a name="Palabra_reservada_auto"> </a> Palabra reservada auto </h4>
 342 Una posible solución a esto, que mantendría un buen equilibrio entre
 343 conveniencia y seguridad, sería agregar una palabra reservada como <code><b>auto</b></code>
 344 para <strong>declarar</strong> una variable con tipo implícito (de hecho se propuso en
 345 comp.lang.c++). El ejemplo anterior en Typhon sería:
 346 <hr />
 347 <pre>
 348 int f(): return 5
 349 int main():
 350     auto n = f() # n es declarada con tipo implícito, obtenido de f(), en este caso int
 351     return 0
 352 </pre>
 353 <hr />
 354 De esta manera se puede distinguir claramente una declaración, pero dejamos
 355 en manos del <em>compilador</em> la deducción del tipo. De manera que si alguien
 356 tipea mal una variable en una asignación, no se crearía un símbolo nuevo y se
 357 convertiría en un error de compilación.
 358 <p />
 359 Un ejemplo con más sentido sería el caso en que se queira iterar un contenedor
 360 obteniendo una copia de cada ítem:
 361 <hr />
 362 <pre>
 363 for i in seq:
 364     auto copia = i
 365     copia += 2 * seq.size()
 366     # etc.
 367 </pre>
 368 <hr />
 369 Por supuesto la declaración de una variable de tipo implícito deberá estar
 370 acompañada siempre de su inicialización, de otra manera no se puede deducir
 371 el tipo. Por lo tanto la expresión <code>auto mi_var</code> (sin una asignación) es un
 372 error de compilación.
 373 <p />
 374 <h3><a name="Literales_de_strings"> </a> Literales de strings </h3>
 375 <strong>Prioridad:</strong> Media/Alta
 376 <p />
 377 Aún no sabemos que vamos a hacer con los <em>strings largos</em> y <em>strings cortos</em>
 378 de Python.
 379 <p />
 380 <h4><a name="Shortstrings"> </a> <em>Shortstrings</em> </h4>
 381 <strong>Prioridad:</strong> Alta
 382 <p />
 383 En principio los strings cortos deberían poder escribirse sólo con <code>"</code>
 384 (comillas dobles) porque las <code>'</code> (comillas simples) deberían usarse para
 385 expresar literales <code><b>char</b></code> como en C/C++.
 386 <p />
 387 <h4><a name="Longstrings"> </a> <em>Longstrings</em> </h4>
 388 <strong>Prioridad:</strong> Media
 389 <p />
 390 Con respecto a los <em>string largos</em> no sé si valga la pena traducirlos de
 391 alguna forma o directamente no soportarlo, aunque creo que soportarlos no
 392 traería grandes complicaciones y en ciertas circunstancias pueden ser
 393 convenientes.
 394 <p />
 395 <h4><a name="Prefijos"> </a> Prefijos </h4>
 396 <strong>Prioridad:</strong> Media/Alta
 397 <p />
 398 También hay que definir si se soportan los prefijos (como <code>r</code> para strings
 399 <em>raw</em>, <code>u</code> para <em>unicode</em>, etc). Tener en cuenta que traducirlos podría
 400 romper la compatibilidad en ciertos ámbitos.
 401 <p />
 402 <h5><a name="Strings_traducibles"> </a> Strings traducibles </h5>
 403 <strong>Prioridad:</strong> Media
 404 <p />
 405 También podría incluirse el prefijo <code>_</code> introducido por D para marcars
 406 strings traducibles. Esto podría integrarse con gettext u otros sistemas
 407 de internacionalización. Lo bueno es que la forma de trabajar quedaría en
 408 manos del lenguaje y en caso de cambiar de implementación, sólo habría que
 409 cambiar el <em>compilador</em>. De hecho podría tener soporte para varios sistemas
 410 de internacionalización.
 411 <p />
 412 Por otro lado, siguien la hipótesis de <em>optimizar para el caso general</em>,
 413 podría tomarse por omisión a todos los strings como traducibles, excepto a
 414 los que lleven el prefijo <code>_</code>, ya que por lo general, la mayor parte de los
 415 strings en un programa son traducibles.
 416 <p />
 417 Todo esto podría manejarse con opciones de línea de comandos a la hora de
 418 <em>compilar</em>, por lo que sin ningún problema, y de forma transparente, podría
 419 generase código sin ningún tipo de dependencia de un sistema de
 420 internacionalización incluso cuando el código esté escrito para ser
 421 internacionalizable.
 422 <p />
 423 <h3><a name="Palabra_reservada_block"> </a> Palabra reservada block </h3>
 424 <strong>Prioridad:</strong> Baja
 425 <p />
 426 Serviría para hacer un bloque de código arbitrario. Es útil para técnicas
 427 de programación como <em>sentries</em>.
 428 <p />
 429 <h4><a name="Ejemplo"> </a><a name="Ejemplo_"> </a> Ejemplo: </h4>
 430 <hr />
 431 <pre>
 432 include ifstream, string
 433 import ifstream, string, getline from std
 434 void f():
 435     # Hago cosas ...
 436     # Quiero obtener en una variable el contenido de un archivo
 437     string contenido
 438     block:
 439         ifstream f("archivo")
 440         string buffer
 441         while getline(f, buffer):
 442             contenido += buffer
 443     # Listo, acá se destruye tanto f (se cierra el archivo) como buffer
 444     # Usamos el contenido como más nos guste
 445 </pre>
 446 <hr />
 447 <p />
 448 <h4><a name="Workarround"> </a> Workarround </h4>
 449 Esto podría emularse con:
 450 <hr />
 451 <pre>
 452 if 1:
 453     # código del bloque acá
 454 </pre>
 455 <hr />
 456 <p />
 457 <h3><a name="Comentarios"> </a> Comentarios </h3>
 458 <strong>Prioridad:</strong> Media
 459 <p />
 460 <h4><a name="Comentarios_multilínea"> </a> Comentarios multilínea </h4>
 461 <strong>Prioridad:</strong> Media
 462 <p />
 463 A Python le falta comentarios multilínea, cosa que me resulta bastante
 464 molesto.
 465 <p />
 466 <h4><a name="Comentarios_multilínea_anidados"> </a> Comentarios multilínea anidados </h4>
 467 <strong>Prioridad:</strong> Media
 468 <p />
 469 D tiene comentarios anidados, cosa muy conveniente para <em>comentar</em> un
 470 bloque de código grande que a su vez pueda tener comentarios adentro.
 471 Me parecería piola que Typhon tenga algo similar.
 472 <p />
 473 <h3><a name="Compilación_condicional"> </a> Compilación condicional </h3>
 474 <strong>Prioridad:</strong> Media
 475 <p />
 476 Meter cosas del precompilador en Typhon me parece poco conveniente,
 477 pero hay cosas necesarias como la compilación condicional. D lo
 478 soluciona con palabras clave <code>version</code>, que es básicamente lo mismo
 479 que un <code>#ifdef ... #endif</code> del precompilador. Creo que Typhon podría
 480 proveer algo similar. Por ejemplo:
 481 <hr />
 482 <pre>
 483 version DEBUG:
 484     void debug(string msg):
 485         cerr &lt;&lt; "debug: " &lt;&lt; msg &lt;&lt; "\n"
 486
 487 int main():
 488     version DEBUG:
 489         debug("entrando al main\n");
 490     # Mas cosas
 491     version LINUX:
 492          # algo específico de Linux.
 493 </pre>
 494 <hr />
 495 Luego para <em>compilar</em> podría haber un flag:
 496 <verbatim> tyc -V DEBUG archivo.ty <verbatim>
 497 <p />
 498 Podrían definirse versiones <em>estándar</em> como en D, como <code>LINUX</code>, <code>WIN32</code>,
 499 <code>MACOS</code>, etc que se activen automáticamente dependiendo de la plataforma
 500 en la que corra el <em>compilador</em>.
 501 <p />
 502 Todo esto puede traducirse de forma bastante inmediata y sin mayores
 503 inconvenientes a directivas del precompilador.
 504 <p />
 505 <h3><a name="class_vs_struct"> </a> class vs. struct </h3>
 506 <strong>Prioridad:</strong> Alta
 507 <p />
 508 En C++ una clase y una estructura son exactamente igual, sólo que la clase
 509 tiene visibilidad privada por omisión y el struct pública. Ninguna de las
 510 dos hace virtuales sus métodos a menos que sea especificado explícitamente.
 511 <p />
 512 Las clases en la mayoría de los lenguajes de alto nivel son completamente
 513 virtuales, sin posibilidad siquiera de que sea de otra forma. Incluso en
 514 C++ el struct suele utilizarse para tipos de datos más simples y
 515 concretos, que muy difícilmente tengan algún método virtual (aunque no hay
 516 ninguna razón técnica que lo impida).
 517 <p />
 518 Siguendo esta línea y la premisa de <em>optimizar para el caso general</em>
 519 probablemente sea una buena idea que las clases tengan todos sus métodos
 520 virtuales por omisión y las estructuras no.
 521 <p />
 522 El problema de esto es que debería haber alguna palabra clave para hacer un
 523 método no virtual, para tener una mayor flexibilidad y no tener que caer en
 524 un struct con muchos métodos virtuales declarados explícitamente porque se
 525 necesita que un método particular no sea virtual.
 526 <p />
 527 <h4><a name="Visibilidad"> </a> Visibilidad </h4>
 528 Con respecto a la visibilidad por omisión, creo que es indiscutible que las
 529 estructuras deben tener visibilidad pública, pero con las clases no es tan
 530 claro. En los lenguajes interpretados, las clases suelen tener visibilidad
 531 pública por omisión y los lenguajes más <em>serios</em> suelen tener visibilidad
 532 privada. Que tenga visibilidad privada no tiene muchas más ventajas que dejar
 533 contento a los abanderados de la orientación a objetos estricta (al menos
 534 para mí :), por lo que probablemente lo más conveniente es que tanto las
 535 clases como estructuras tengan visibilidad pública por omisión.
 536 <p />
 537 Lo mismo para la visibilidad en la herencia, en este caso creo que es mucho
 538 más claro que lo más natural es que la herencia sea pública por omisión.
 539 <p />
 540 <h4><a name="Herencia_virtual"> </a> Herencia virtual </h4>
 541 Es un caso muy poco frecuente y no creo que haya una mejor manera de
 542 manejarlo que la de C++, así que creo que debería mantenerse la herencia
 543 como no virtual por omisión pero permitir que lo sea si se lo especifica
 544 explícitamente.
 545 <p />
 546 <h4><a name="Ejemplo"> </a> Ejemplo </h4>
 547 <hr />
 548 <pre>
 549 class C:
 550     C(): cout &lt;&lt; "Constructor de C\n"
 551     int hacer_algo(double i) const: return i/2
 552     ~C(): cout &lt;&lt; "Destructor de C\n"
 553 </pre>
 554 <hr />
 555 Se traduciría como:
 556 <hr />
 557 <pre>
 558 struct C
 559 {
 560     C();
 561     virtual int hacer_algo(double i) const;
 562     virtual ~C();
 563 };
 564 C::C()
 565 {
 566     cout &lt;&lt; "Constructor de C\n";
 567 }
 568 int C::hacer_algo(double i) const
 569 {
 570     return i/2;
 571 }
 572 C::~C()
 573 {
 574     cout &lt;&lt; "Destructor de C\n";
 575 }
 576 </pre>
 577 <hr />
 578 Mientras que:
 579 <hr />
 580 <pre>
 581 struct C:
 582     C(): cout &lt;&lt; "Constructor de C\n"
 583     int hacer_algo(double i) const: return i/2
 584     ~C(): cout &lt;&lt; "Destructor de C\n"
 585 </pre>
 586 <hr />
 587 Se traduciría como:
 588 <hr />
 589 <pre>
 590 struct C
 591 {
 592     C();
 593     int hacer_algo(double i) const;
 594     ~C();
 595 };
 596 // ídem anterior
 597 </pre>
 598 <hr />
 599 <strong><em>Nota:</em></strong> La declaración de C++ estaría en un <code>.h</code> y la definición en un <code>.cpp</code>.
 600 <p />
 601 <h1><a name="Ejemplos"> </a> Ejemplos </h1>
 602 Los ejemplos se mudaron a <a class="twikiLink" href="/twiki/view/Main/TyphonExamples">TyphonExamples</a> porque eran demasiado extensos.
 603 <p />
 604 <h1><a name="Links"> </a> Links </h1>
 605 <ul>
 606 <li> <a href="http://www.research.att.com/~bs/3rd.html" target="_top">The C++ Programming Language</a> -
 607      Lenguaje de programación compilado al cual se traducirá Typhon.
 608 </li>
 609 <li> <a href="http://www.python.org/" target="_top">Python</a> - Lenguaje interpretado en el cual
 610      Typhon va a basar su sintaxis.
 611 </li>
 612 <li> <a href="http://www.sgi.com/tech/stl/" target="_top">Standard Template Library</a> -
 613      Biblioteca estándar de C++, Typhon va a usar sus características e
 614      interfaces para traducir secuencias y cosas similares.
 615 </li>
 616 <li> <a href="http://www.digitalmars.com/d/" target="_top">The D Programming Language</a> -
 617      Lenguaje compilado parecido a C++ pero con algunas caracteristicas de más
 618      alto nivel y otras cosas muy interesantes, de las cuales tal vez podrían
 619      agregarse un par a Typhon.
 620 </li>
 621 <li> <a href="http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/" target="_top">Pyrex</a> - Un
 622      lenguaje que es prácticamente una extensión a python para mezclarlo con C,
 623      diseñado específicamente para hacer bindings de C para Python. Fue una de
 624      las fuentes de inspiración para Typhon.
 625 </li>
 626 </ul>
 627 <p />
 628 <p />
 629 <br clear="all" />
 630 <table width="100%" border="0" cellpadding="3" cellspacing="0">
 631  <tr bgcolor="#FFFFC0">
 632   <td valign="top">
 633    Topic <b><B style="color:black;background-color:#ffff66">TyphonLanguage</B></b> . {   <a href="/twiki/edit/Main/TyphonLanguage?t=1125215253"><b>Edit</b></a>
 634    |  <a href="/twiki/attach/Main/TyphonLanguage">Attach</a>
 635    |  <a href="/twiki/search/Main/SearchResult?scope=text&amp;regex=on&amp;excludetopic=TyphonLanguage&amp;search=Typhon%20*Language%5B%5EA-Za-z0-9%5D">Ref-By</a>
 636    |  <a href="/twiki/view/Main/TyphonLanguage?skin=print">Printable</a>
 637    |  <a href="/twiki/rdiff/Main/TyphonLanguage">Diffs</a>  | r1.2 | <a href="/twiki/rdiff/Main/TyphonLanguage?rev1=1.2&amp;rev2=1.1">&gt;</a> | <a href="/twiki/view/Main/TyphonLanguage?rev=1.1">r1.1</a>
 638    |  <a href="/twiki/oops/Main/TyphonLanguage?template=oopsmore&amp;param1=1.2&amp;param2=1.2">More</a>
 639    }
 640   </td>
 641  </tr>
 642 </table>
 643 <table width="100%" border="0" cellpadding="3" cellspacing="0">
 644  <tr>
 645   <td>
 646 <div class="TWikiFooterNote">
 647    Revision r1.2 - 08 Oct 2004 - 02:33 - <a class="twikiLink" href="/twiki/view/Main/LeandroLucarella">LeandroLucarella</a>
 648 <p />
 649  </div>
 650 <p />
 651   </td>
 652   <td width="50%">
 653     <div class="TWikiCopyright">
 654 <font size="-2">%WEBCOPYRIGHT%</font>
 655 </div>
 656   </td>
 657  </tr>
 658 </table>
 659 <a name="PageBottom"></a>
 660 </body>
 661 </html>