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-hosted' language. If you mean languages where (most of) the runtime and the compiler itself are written in the language in question, like C and GHC's Haskell, then they aren't counter-examples. Neither compiled C programs nor GHC-compiled Haskell programs require the compiler to run. They require the runtime, which happened to be written in C/Haskell before being compiled, but that's a different matter. If you mean languages like Lisp, where the basic operation of the runtime requires the compiler, then these are exactly the languages I am calling 'interpreted'. The fact Lisp implementations can typically compile out to machine code is an implementation detail.

        I can write eval for C in C if I can make system calls, open shared libraries, and call functions from shared libraries

        No you can't; or, at least, you can't without effectively writing a C compiler (most debuggers, for instance, contain a compiler for a language not entirely unlike C). If C had had 'eval' (or, since it was always designed to compile to machine code, separate 'compile' and 'eval' like Lisp) from the beginning, it would have been a rather different language. For one thing, there would have been no need for CPP and configure scripts: just run a little C program that compiles the appropriate bits of code and writes the results out. Shared libraries (including dlopen and everything) would have been built in from the start, instead of being somewhat kludged-in later, as you'd always have needed to be able to link dynamically-generated code. FFI to C would be trivial, instead of requiring nasty assembler tricks to implement generally. And so on.

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

        While a compiled language can always be interpreted, the reverse is not necessarily true. Both Lisp and Perl, for instance, rely heavily on having access to the compiler (rather than some sort of dynamic linker) at runtime; this is part of what makes them so flexible.

        Maybe 'compiled' and 'interpreted' aren't quite the words I'm looking for. Maybe I want 'static' and 'dynamic', though I thought they usually implied more than that, such as static vs. dynamic typing (which is obviously orthogonal to this).

        • ... 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.