Hola gente! Gerardo (creo que nos habremos cruzado en alguna reunión de Sugar en Buenos Aires, en 1997), gracias por el comentario. Hmmm, algunas aclaraciones:
- Mi pet project [1] es un interprete, otros lenguajes que mencione, implementan un compilador sobre .NET (emiten código, o se auxilian del DLR, Dynamic Language Runtime), o código Java (como Clojure, que es interprete en memoria, usando un patrón Interpreter, y luego visita cada nodo, y lo compila a Java si es necesario). - En mi proyecto, no implemento un patrón Interpreter (un objeto por cada, digamos operación, formando un árbol), sino que implemento Block, con bytecodes adentro, que luego, al resolver un mensaje y decidir el método a ejecutar, voy recorriendo ese arreglo de bytecodes y ejecutándolos en métodos .NET. - Manejo objetos nativos e implementaciones de IObject (lo que defini que tendrían que tener todos los objetos de esta VM). La opción hubiera sido hacer que todos fueran IObject o algo asi, pero yo quería utilizar directamente los Value Object primitivos de .NET (int32, int64, etc). - Los IObject tienen slots, definidos por su definición de clase, digamos, sus instance variables. Son object (o sea, pueden apuntar a object nativo de .NET (o de Java si reimplementara todo en Java), y - No uso FFI, simplemente llamo a librerías .NET cualesquiera (la gente de Clojure llama a Java cualesquiera, y no tuvo que implementar JNI Java Native Interface). Hay parva de código de Clojure que ha conseguido sinergia al montarse sobre librerías de Java ya existente. Clojure es un lenguaje Lisp, veo que Lisp por si solo nunca consiguió "momentum", y ahora con la estrategia de Clojure de acceder a todo Java VM, se esta "popularizando". EN mi caso, si alguien quiere llamar a algo mas básico, lo implementa en .NET - Solo algunas clases están definidas en el lenguaje de abajo, tengo que rever cuales si y cuales no, por ejemplo Class, Behavior, etc.. - En vez de implementar alguna forma de primitivas (como en otros Smalltalk que tienen alguna notación para llamar a una primitiva, o cargar nuevas primitivas al principio), tengo implementada una forma de crear objetos en .NET y llamar métodos nativos, directamente en notación Smalltalk. Podria implementar un Bag de Smalltalk, con todo el protocolo de métodos, teniendo por debajo una variable de instancia que podria ser System.Collections.Generics.List<object> o algo asi, y manejarla desde el código de los métodos de Bag. Ejemplo de la notación que hasta va triunfando: @System.IO.FileInfo new: ‘aFile.txt’ - Cuando hablo de .NET arriba, tranquilamente podria reimplementar todo en Java. - Ahora si, quisiera pasarlo a compilador, debería emitir código nativo (C# o IL (intermédiate language)) para cada bytecode que encontrara en cada método. Por ahora, no lo hago, prefiero avanzar en otras cosas. Si llego a ese punto, pienso que podria superar problemas de performance que aparezcan, como hicieron otros implementadores, como la gente de Clojure, o IronPython - Jeje... ya encuentro divertido hacer todo eso, y poder acceder a otras librerías. Quiero llegar a implementar objetos distribuidos, y agentes (algo habíamos hablado en una reunión de Sugar del siglo pasado), como hice en otro lenguaje interpretado [2]. [1] http://ajlopez.wordpress.com/category/ajtalk/ [2] http://ajlopez.wordpress.com/category/ajsharp/ Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ http://twitter.com/ajlopez -----Mensaje original----- De: [email protected] [mailto:[email protected]] En nombre de Gerardo Richarte Enviado el: lunes, 26 de julio de 2010 16:51 Para: [email protected] Asunto: Re: [clubSmalltalk] RV: DNG-Win32 Bit VM On 07/26/2010 03:25 PM, Angel "Java" Lopez wrote: > Hola gente! > > Gracias por el detalle, a Andres y a Gerardo. > > Con respecto a lo que plantea Andres, no se resuelve gran parte de eso > adoptando como lenguaje de implementación algo sobre Java o .NET? Cuanto se > resolvería asi? Yo, en mi pet Project, no tengo que preocuparme de GC o de > FFI, simplemente accedo a .NET (como podria acceder a Java, si reimplemento > todo en Java). > no entiendo bien. Estás diciendo que tu compilador Smalltalk escupe bytecode .NET o bytecode java? o que cuando haces new en Smalltalk eso va directamente a un new en Java o .NET, y que en la implementación de tu Smalltalk no manejas nada del formato de los objetos? incluso tenés también definidos las clases también en el lenguaje de abajo? de tal forma que un slot en Smalltalk sea un slot (con el mismo nombre?) en .NET y Java? Pero para ejecutar el código, implementaste un interprete de Smalltalk? y FFI? como lo implementas? también se lo pateas, via el interprete, al execution engine que está por debajo? Si estás compilando a bytecode de la VM de abajo está super, si no tenés el overhead (de performance) de estar dentro de 2 VMs. Y en los dos casos tenés la desgracia de no poder experimentar con cosas divertidas como el GC (memory management), method lookup y caches de métodos, y algunas otras cosas divertidas :-)... bueno, dependiendo de donde pogas la linea de corte, claro saludos! -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.441 / Virus Database: 271.1.1/3029 - Release Date: 07/26/10 06:36:00 -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
