Re: Command Languages Versus Programming Languages

In article <vebi0j$3nhvq$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

On Fri, 11 Oct 2024 15:45:01 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:

In article <vebffc$3n6jv$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:

Bart <bc@freeuk.com> writes:

Interpreter? Perl has some kind of compiler in it, right?

>
The Perl compiler turns Perl source code into a set of (that's a

>
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive
making it an even less attractive option these days.

>
That's a bad distinction.  There have been "Load and Go"
compilers in the past that have compiled and linked a program
directly into memory and executed it immediately after
compilation.  As I recall, the Waterloo FORTRAN compilers on the
IBM mainframe did, or could do, more or less this.

>
Irrelevant. Lot of interpreters do partial compilation and the JVM does it
on the fly. A proper compiler writes a standalone binary file to disk.

Not generally, no.  Most compilers these days generate object
code and then, as a separate step, a linker is invoked to
combine object files and library archives into an executable
binary.

By the way, when many people talk about a "standalone" binary,
they are referring to something directly executable on hardware,
without the benefit of an operating system.  The Unix kernel is
an example of such a "standalone binary."

Most executable binaries are not standalone.

Saving to some sort of object image is not a necessary function
of a compiler.

>
Yes it is.

So you say, but that's not the commonly accepted definition.
Sorry.

- Dan C.