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