Hola Hernán,
Primero unas respuestas breves a tus preguntas, luego
unos comentarios, que, espero sean de interés general.

>¿quien o en donde se evalúa el código mismo del Parser,
> Scanner, etc.

En todas las implementaciones (que son un ambiente),
Compiler esta implementado en el mismo ambiente
(es contra natura que no lo sea así);
En algunas hay mas de un "compiler" e incluso
podes subclasificarlos (Prolog/V en Smalltalk/V
es un muy buen ejemplo de la conveniencia de subclasificar
el compilador Smalltalk).

Todos los compiladores del ambiente generan
métodos y por lo general comparten el generador
de bytecodes.
La respuesta (rápida y mas correcta) a tu pregunta
sobre "dónde se evalúa el código mismo?"
es en la VM (la VM evalúa los bytecodes);
esto es consecuencia de la implementación ACTUAL
de los smalltalks de hoy y (espero que) alguna vez
cambiará.
Es consecuencia de la implementación del soporte de metaarquitectura de los
ambientes smalltalks, en dónde la arquitectura de comportamiento esta
modelada con objetos (métodos).
Esto es tan objetable como que las especies sean modeladas como clases; y
espero que ese camino no siga siendo desarrollado en Smalltalk, pues es
inocente (e indicaría una vuelta atrás).

> si yo modificara o quisiera generar los bytecodes mismos
> de esas clases?

Te referís a los bytecodes de los métodos de las clases del compilador
(etc)?
Son clases como cualquier otra...
Son tan factibles de una ingeniería inversa como cualquier clase.
Es un buen ejercicio agarrar un inspector y meterle mano; si el proveedor
quiso ocultar esos métodos. Es una buena ejercitación si lo complementás con
la lectura de los compiladores de otros smalltalks (con los fuentes).

> Por lo general en otros lenguajes se usan generadores de parsers,

Bueno.. Smalltalk no es un lenguaje.
Un lenguaje no "hace" nada...
Smalltalk hace; por ejemplo: compila.
Se entiende?

Esta definición de Smalltalk, mas allá de un lenguaje
es la que permite que "el" compilador sea hecho
por un ambiente Smalltalk.
De hecho hay varios casos en al práctica dónde se han usado (hemos usado) un
ambiente para generar métodos de otro ambiente, etc.
Ejemplos hay muchos en la historia de Smalltalk.
Una referencia mas:
http://www.alereimondo.com.ar/ImageGestation

Decías...
> Por lo general en otros lenguajes se usan generadores de parsers,
> que dada una gramática, generan un parser, pero aún usando
> SmaCC
> (¿SmaCC puede generar un parser en Smalltalk a partir
> de una gramática Smalltalk por ej en EBNF?)

Cualquier objeto puede generar CompiledMethods...
Si queres podes llamarlo compilador.
El SmaCC puede generar un compilador para
cualquier lenguaje... el condicionante está en que deberás
definir un lenguaje; y esto no es de tanta utilidad como lo parece,
si usas objetos.

>y confiar en el ciegamente y asegurar que nunca lo voy
> a recompilar, me quedaría el problema de recorrer el
> camino de la generación de tokens, lexemas, etc. del
> mismo parser/lexer hasta llegar a los primeros
> bytecodes.

Creo que estas pensando en que hay un comienzo...
un génesis.
Esto es innecesario (e irrelevante) si usas Smalltalk,
pues estarías volviendo +30años atrás :-)
Podes usar casi cualquier Smalltalk como host de
tu nuevo ambiente; y crear un espacio muy distinto
de que partís, parasitando en el ambiente original
y luego generar una imagen muy diferente (esto
se ha usado durante años en Smalltalk para permitir
cambios importantes -y no tan importantes- en
un ambiente)

>Mi sospecha es que la VM tiene que tener al menos
> un mini-verificador o algo así.

No.
Que "debería" hacer la VM si encuentra algo "incorrecto
ante su diseño" ?
Matar todos los objetos? (destruir el mundo por tropezar
con una piedrita)
Ignorarlo?
Detenerse? (parar el mundo es imposible y tan inútil
como destruirlo)
[no intentes responder estas preguntas;
son incorrectas]

> Bueno ¿se entiende la pregunta?

Espero se entiendan estas respuestas y te motiven
a seguir adelante en estos cuestionamientos.

En la formula de ambiente de objetos, esta garantizado
que el enviar un mensaje a un objeto implica la recepción
de ese mensaje por su parte.
El pensar en "que hace el objeto", esta fuera del planteo
original; y está viciado de una OO el pensar que
el "comportamiento" esUn objeto.

"Que hace un objeto?"
Es incorrecto de formular pues se asume que los efectos
son encapsulables y que son un objeto.
A este error de base, no escapan las formulas actuales de
ambientes (es decir, no escapa ningún Smalltalk actual)
pues en todos se formula que "todo es un objeto"
como si esto fuera cierto y conveniente (mas allá de ser
una frase muy útil en la enseñanza de los principios
de la OO, el método y diseño OO).

En ese esquema reductivo, uno solo puede ambicionar
un buen modelo de arquitectura (metamodelo)
y un buen modelo de comportamiento;
para que pueda ser interpretado por una máquina
(esquema de input-output, añejo, morlokiano y "seguro")
y por ultimo un esquema de transparencia entre
la recepción de un mensaje y la ejecución de esos
objetos "comportamiento" (especificado por byteCodes
+ literales).
Fijate que la transparencia es deseable justamente DESPUES
de impactar el mensaje en el receptor (es decir,
no se incluye lo que se denomina el operador de lookup).

Básicamente se identifican dos operadores:
1.- el lookup
2.- el evaluate

La transparencia en 1 ha sido una constante en los smalltalks
de hasta hace 10 años; y hoy en día es públicamente objetada,
con implementaciones mas o menos inocentes para subsanar
la problemática de implementar diferentes alternativas de lookup
en un mismo ambiente.

La transparencia en 2 aun no es objetada públicamente en la
comunidad de Smalltalk y solo tímidamente se han hecho ensayos
en ese sentido (por ejemplo, hace aprox. 5 a 7 años he publicado
unos ensayos denominado non-compiled methods para squeak,
que permitían experimentar en este área).

Dentro de 3 se detallan en muy pocos lugares arquitecturas
generales apropiadas para objetos y por lo general son diseños
muy rígidos y viciados del soporte actual disponible para la
implementación de VMs; en ningún caso he visto abordajes
dignos de mencionar en dónde se busque resolver dentro
del ambiente problemáticas de ejecución de bytecodes
o compilación nativa (en un momento quisimos arrancar
en Smalltalking un proyecto de esta naturaleza, lo recuerdan?
el "Smalltalk de Smalltalking"; pero fue demasiado...)

Solo es visto, en el mejor de los casos,
que los proveedores hagan públicos algunos parámetros
de control general de ejecución de los optimizadores
de código nativo.

hasta pronto,
Ale.




----- Original Message -----
From: "Hernan" <henrykgorecki@...>
To: <smalltalking@...>
Sent: Friday, February 10, 2006 9:59 PM
Subject: [objetos] Parser de Smalltalk


> Quizás sea un poco pavo este planteo, espero que se entienda al menos.
> En varios Smalltalk el Scanner, Lexer y Parser está expuesto como clase
al programador, y hasta donde tengo entendido, cada stream de caracteres
que se evalúa por primera vez es pasado por el Lexer, Parser, verificador
semántico, etc.
> Mi pregunta es, ¿quien o en donde se evalúa el código mismo del Parser,
Scanner, etc. si yo modificara o quisiera generar los bytecodes mismos de
esas clases?
>
> Por lo general en otros lenguajes se usan generadores de parsers, que
dada una gramática, generan un parser, pero aún usando SmaCC (¿SmaCC puede
generar un parser en Smalltalk a partir de una gramática Smalltalk por ej
en EBNF?) y confiar en el ciegamente y asegurar que nunca lo voy a
recompilar, me quedaría el problema de recorrer el camino de la generación
de tokens, lexemas, etc. del mismo parser/lexer hasta llegar a los primeros
bytecodes. Mi sospecha es que la VM tiene que tener al menos un
mini-verificador o algo así.
> Bueno ¿se entiende la pregunta?
>
> Saludos
>
> Hernán
>
>
>
> ---------------------------------
> 1GB gratis, Antivirus y Antispam
> Correo Yahoo!, el mejor correo web del mundo
> Abrí tu cuenta aquí