23 Oct
2006
23 Oct
'06
5:28 a.m.
One can do things in an interpreted enviroment like LISP with self modifiable code
and the (eval) statement that can not be easily done in a compiled enviroment.
A learning tree can be built and self updating process lists can be constructed and
evaluated based on changing input in LISP. This would break many rules in a conventional
compiled programming enviroment.
Not to mention the problems with using recursion in a compiled enviroment to identify
and learn from unformatted input based on previous experiences often with limited
or better yet without any human intervention in the learning process.
To do these things in a compiled enviroment requires writing an embedded evaluator or
interpreter
that can me called into action to parse and evaluate changes in the input stream.
The other Bob
On Sun, 22 Oct 2006 21:52:23 -0400 (EDT), der Mouse wrote:
> The only time I can see an interpreter having a
clear advantage is
> when it knows something about the runtime environment that the
> compiler and [its] runtime can't know.
I'm having trouble thinking of an example of such a
"something". Can
you cite one? It'd help me understand.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B