header file question

[Dan Pop]

Well, at least when you leave off a quote in C, the compiler is sure
to be upset - "Line 666: Unterminated string constant", and lo, on
line 666 will be an unterminated string. In Javascript, however, do
the same thing and you're likely to see something like "Line
123456789: Unterminated string constant" which, coincidentally, has
nothing to do with the *real* unterminated string constant on line
666. No, I don't get frustrated easily

This is not an interpreted vs compiled issue, but rather a string literal
definition issue. If Javascript used C's conventions for string literals
it could diagnose the unterminated string literal on the very line it
occurred.

Leave a C comment unterminated or generate a brace mismatch and the C
compiler's behaviour is no better than the Javascript interpreter's.

Dan

 

[Richard Heathfield]

In <[email protected]> Richard Heathfield


Are you sure it was not an incremental compiler?

Yes.

 

[karl malbrain]

Make your program run as fast as possible ;-) Genuine interpreters really
suck in terms of program execution speed. That's why code generation on
the fly is a technique more and more popular with interpreters. You
should be familiar with just-in-time Java bytecode "interpreters".

Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.

karl m

 

[Gordon Burditt]

Hmm, there are several things that can be done in an interpreter that

can't be done in a compiler. I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?

If you don't insist that it be efficient, a compiler could compile
the code on the fly (adding a skeleton wrapper around it, if necessary),
then run it. Support for dynamic linking makes this considerably
easier.

Are there any things compilers can do that interpreters can't? I'm

I don't think so, unless you put qualifiers on efficiency.
If a compiler is written in C and can do it, then an interpreter
running the compiler written in C can also do it.

If you have an interpreter that can interpretively execute the
binary of the compiler and the run-time environment, then,
efficiency considerations aside, the interpreter should be able
to do exactly what the compiler does.

fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?
Should I ask at comp.programming?

Gordon L. Burditt

 

[Dan Pop]

Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.

If you think that this is a counterargument to my statement, you're
a genuine idiot.

Dan

 

[Sheldon Simms]

Complete nonsense. Our tax preparation program is implemented
completely in an interpreted language and is the fastest in the
business. It's also the smallest.

It might even be the most useless.

 

[Joona I Palaste]

If you think that this is a counterargument to my statement, you're
a genuine idiot.

Dan, you're calling Karl Malbrain a genuine idiot? That's like calling
the Earth round, or the sky blue, or the grass green. There's no need
to state the obvious.

 

[karl malbrain]

If you think that this is a counterargument to my statement, you're
a genuine idiot.

Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."

Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m

 

[glen herrmannsfeldt]

Joona I Palaste wrote:

(snip)

Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. I have experience of writing interpreters
slightly above "trivial" level, but I have never written a full
compiler. One of my interpreters allowed interpreting the contents of
a string variable as if it were program code. I don't think that's quite
possible in compilers?
Are there any things compilers can do that interpreters can't?

(snip)

It is pretty rare to find a pure interpreter or pure compiler. At least
some people consider calling library routines means it is not a pure
compiler.

Most interpreters compile to an intermediate code that is at least
slightly easier to interpret than the original text. Keywords are
identified, for instance. Many will do syntax checking on the whole
program to avoid errors at run time that could easily be detected,
normally a compiler feature. I have seen interpreters that let you
modify the source while the program is running.

With sufficiently strict definition of interpreter, compilers can
generate cross reference listings, storage maps, and optimizations that
require analysis of the whole program unit. I know one Fortran 66
compiler where the optimizer can deduce the nesting structure that a
structured programming language would make explicit. With this level of
optimization, it can print a source listing with the appropriate
indentation to match the nesting levels.

Some of these one might say that an interpreter could do, but in that
case I would say that it is not an interpreter anymore. The name
incremental compiler is sometimes used for processors with some features
of both interpreter and compiler.

-- glen

 

[Dan Pop]

Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."

Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m

Yeah, it seems that Joona was right about you...

Dan

 

[Dan Pop]

It is pretty rare to find a pure interpreter or pure compiler.

Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.

At least
some people consider calling library routines means it is not a pure
compiler.

That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?

Dan

 

[ozbear]

Agreed for modern interpreters, designed for platforms with plenty of
resources.

Many old BASIC interpreters were quite pure (you made a typo on
line 1000 and the program would happily run until getting there).
And so are most C compilers, regardless of platform.


That's sheer nonsense. If the processor does not support floating point
in hardware (or microcode), should the compiler generate tons of inline
code for each floating point operation in order to be considered a "pure"
compiler?

Perhaps what Glen was referring to, or a better example, is printf and

friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.

Oz

 

[Dave Thompson]

On 18 Nov 2003 18:38:09 GMT, Joona I Palaste <[email protected]>
wrote:

Hmm, there are several things that can be done in an interpreter that
can't be done in a compiler. <snip>
Are there any things compilers can do that interpreters can't? I'm
fairly sure there are things compilers can do *easier* than
interpreters, but is there any that compilers can do and interpreters
can't do *at all*?

Actually I would say any given functionality that can be implemented
both places is easier, or at least simpler, in an interpreter, since
it has strictly more information available about the program(s).

Compiled code almost always runs faster than interpreted, usually much
faster; this is a difference of degree rather than kind, although it
may have a qualitative effect -- classic number-crunching example: if
it takes 1.5 days to run a 1-day weather prediction it's useless, but
0.5 days becomes valuable. More generally, the interpreter also has
some overhead for things like file opens and buffers, etc., so at the
margins on a given machine compiled code can run problems/inputs
slightly larger by various measures than interpreted. OTOH on most
architectures compiled code is larger than source, so an interpreter
can probably load (at all, or with less swapping) a larger program.
(Although I guess you could claim conversely that compiled code
exercises VM/swapping mechanisms more extensively. <G>)

A compiler can in most cases, unless deliberately restricted by
licensing or configuration, produce a program that runs on another
machine or many other machines (without special software installed)
and for a cross-compiler even on a different type of machine. Compiled
code can be distributed without source, which except for obfuscated or
just really awful source makes it significantly harder though not
impossible to read and/or understand.

You can usually combine object code compiled from multiple languages
into a single executable, while it is at least very hard for two or
more interpreters to work together so closely; a single interpreter
can usually(?) call (pre)compiled code from other languages, but it is
often(?) more difficult to provide an interpreted entry or callback
that can be called *from* other-language code.

Should I ask at comp.programming?

Don't know.

- David.Thompson1 at worldnet.att.net

 

[Mark Gordon]

On 20 Nov 2003 12:16:14 -0800

(e-mail address removed) (Dan Pop) wrote in message


Well, let's see. "Genuine interpreters really suck in terms of ..."
and "Our tax preparation program is ... interpreted and is the
fastest..."

Walking completely sucks in terms of speed (you can't even go 30MPH).
However, it is still fast enough for a lot of things.

Does that connect any dots for you? Your statement is FALSE by
counterexample. karl m

That just proves that there is nothing better not that yours is any
good.

 

[glen herrmannsfeldt]

Some that I know of wouldn't even let you enter an invalid statement.
Others would tokenize the statement, though it might not have made any
sense as a BASIC statement. Then there was one that would let you enter
expressions, even using variables, for the BASIC INPUT statement. That
is a pretty wide range.

Command interpreters such as unix shells or DOS COMMAND.COM running
batch files are about as pure as I can think of. I don't think I ever
completely understood it, but once I modified a csh script while it was
running a loop, and the new change took effect immediately, without
crashing the loop.

That is what CS people would tell me. It took me a while to believe it,
but after a while it seems to make sense.

Perhaps what Glen was referring to, or a better example, is printf and
friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.

This is a more obvious example. I am always surprised when compilers
issue warnings from printf format strings. I expect it to be
interpreted only at run time, and if a variable is supplied it must be.

I agree that the floating point case is questionable, but I think it is
even true in that case.

I did once know of people who built a microcoded machine to execute
S/370 code. They "compiled" the S/370 code into microcode, instead of
interpreting it in microcode as is usually done. Most likely it
generated "tons of microcode" for floating point operations, though it
might be that they didn't need so many floating point operations.

So maybe I would call the compiled code that generates calls for
floating point 99% compiled and 1% interpreted. That doesn't seem so
bad to me.

Consider, though, what some have done in the past for floating point,
which is to either insert interrupt instructions or process the trap for
a non existent instruction, and then interpret that floating point
operation.

-- glen

 

[Dan Pop]

Perhaps what Glen was referring to, or a better example, is printf and

friends or scanf and friends where those librry routines have to run
a "mini-interpreter" to deal with the format string and attempt to
make sense of the rest of the arguments, especially when the format
string is apssed via a variable rather than supplied as a literal.

Glen was talking about *compilers*, while this is a language library
issue.

Dan

 

[karl malbrain]

On 20 Nov 2003 12:16:14 -0800


Walking completely sucks in terms of speed (you can't even go 30MPH).
However, it is still fast enough for a lot of things.

No it doesn't suck. It depends on the conditions: how and where it is
specified. It's still best in most transport applications.

That just proves that there is nothing better not that yours is any
good.

Yeah, I guess I should have spelled it out: the other packages being
compared are all compiled C and C++ applications. It's the
ORGANIZATION of the code and its function compositions, not whether
it's compiled or intrepreted, that determines whether it "sucks" or
not. karl m

 

[glen herrmannsfeldt]

(snip)

Glen was talking about *compilers*, while this is a language library
issue.

Well, it is close enough. There have been discussions here before about
the separation, or lack thereof, between the language and the library.

You could consider the Fortran formatted READ and WRITE statements which
are not written as function calls, but are always (that I know of)
implemented as function calls. The Fortran exponentiation operator is
also usually implemented as a function call. Fortran Complex
arithmetic operators, even on machines that do have floating point
hardware, are sometimes function calls. (Do any machines implement
complex arithmetic in hardware?)

It did take me a while to be convinced, and I agree that floating point
is one of the least obvious examples.

-- glen