Torsten Bronger wrote:
> Hallöchen!
>
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>
>
>>Alexander Schmolck a écrit :
>>
>>
>>>Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>>[...]
>>>>
>>>>It's not a "scripting" language, and it's not interpreted.
>>>
>>>Of course it is. What do you think happens to the bytecode?
>>
>>Ok, then what do you think happens to 'machine' code ?
>>
>>"interpreted" usually means "no compilation, all parsing etc
>>redone at each execution", which is not the case with a
>>bytecode/vm based implementation.
>
>
> That sounds like an implementation feature rather than a language
> feature.
It is, of course. When we say that 'this language is
[interpreted|bytecompiled|compiled|runs on clay tablets|whatnot], we're
of course talking about the standard or reference implementation(s).
> Besides, it's not a very sensible distinction in my
> opinion. Much better is to think about the structure of the
> interpreting machine. I'm not a CS person (only a physicist) but if
> you *need* a bytecode interpreter on top of the CPU interpretation,
> it's an interpreted language to me.
So there are only interpreted languages nowadays.
> I've had such a discussion about TeX already, and my personal
> conclusion was that you can defend almost any opinion in that area.
> However, one should ensure that the definitions make a pragmatic and
> useful distinction.
The only pragmatic and useful distinction I can see here is between
languages that have to re-parse the whole source for each and every
executions ('interpreted') and languages that don't.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
