Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • While I don't think the script/program distinction is useful (uh, duh?), I think there is a useful distinction between 'compiled' or perhaps 'compilable' languages and 'interpreted' ones. A compilable language is one which can be translated into a form that doesn't depend on the compiler; or, an interpreted language is one with 'eval'. Perl is an interpreted language by this definition: this is one of the reasons why PAR is a much more successful way of turning a Perl program into an executable than B::C ev
    • A compilable language is one which can be translated into a form that doesn't depend on the compiler; or, an interpreted language is one with 'eval'.

      The first half of that may be true. It may not be; consider a self-hosted language. The latter half is likely not true, as I can write eval for C in C if I can make system calls, open shared libraries, and call functions from shared libraries.

      "Compiled" and "interpreted" are characteristics of execution models and are rarely intrinsic to the language.

      • The first half of that may be true. It may not be; consider a self-hosted language.

        I was proposing it as a definition, not a statement of fact :). The only thing that might not be true is that the two halves are equivalent; obviously, they aren't: the latter implies the former but not vice versa. Still, a language that required its compiler to run but didn't provide 'eval' would be rather odd, and probably could be implemented better, so I don't think that matters.

        I'm not sure what you mean by a 'self-hos

        • ... you can't without effectively writing a C compiler...

          I can write system( "/usr/bin/gcc -o mynew.so mynew.c" );. The same thing is possible in a Perl without eval. Neither of us said that portability affected the definition.

          Maybe 'compiled' and 'interpreted' aren't quite the words I'm looking for.

          As long as our general purpose computing devices use the Von Neumann architecture, any operation that allows you to modify the contents of memory as the program runs makes it possible to allow eval or

          • I can write system( "/usr/bin/gcc -o mynew.so mynew.c" );.

            ...at which point your program requires a compiler to run, and is written (by my definitions) in an interpreted language ('C-plus-the-assumption-that-/usr/bin/gcc-is-a-compiler'). I think that if you wrote any sizeable amount of code making use of that construction, or any other like it, you would find you were using a rather more powerful language than C.

            • ... at which point your program requires a compiler to run, and is written (by my definitions) in an interpreted language...

              Thus question of whether a language is compiled or interpreted depends on the specific program or script. Suppose instead of invoking an external compiler I used the JIT to generate new code instead of speeding up existing code. If the language itself does not provide eval and I don't invoke an external compiler through a system call, does the language suddenly become interpreted

              • This is why I think that declaring a language as interpreted or compiled is silly.
                Perhaps a more useful analysis would be how much or how often a particular language is generally used in an "interpreted" or a "compiled" mode of operation? Then it becomes a matter of choosing the appropriate metric and using some basic stats. I don't know if it would be very useful in absolute terms, but it would probably be more useful, at least.