f95 interpreter

Hi all,

I was wondering if there is a good reason why an f95 interpreter doesn't
exist (or at least I'm not aware of one).  I recently had to work on a
project using OCaml and was quite impressed with the fact that it has an
interpreter and can be compiled to pretty good native code (i.e. runs
reasonably fast).  I have gotten used to having either one or the other..
but not both.  The debug-devel time without the compile-debug cycle was
quite enjoyable and got me to thinking about this question.  Is it simply
because it is really hard to do or because nobody has taken the time/had
the inclination to do it?  Maybe I'm weird but a top level where you could
read in your f95 modules and subroutines and test as you go then when all
is running as desired fire up the compiler for a speedy executable...
nice!!

Cheers,
Jason

On Sat, 16 Oct 2004 22:20:48 GMT, Jason Nielsen <jdn@cs.sfu.ca> wrote:

>Hi all,
>
>I was wondering if there is a good reason why an f95 interpreter doesn't
>exist (or at least I'm not aware of one).

You may want to check out http://www.hicest.com/

Doug Cox

Jason Nielsen <jdn@cs.sfu.ca> writes:

> I was wondering if there is a good reason why an f95 interpreter
> doesn't exist (or at least I'm not aware of one)...

I hadn't been aware of the HiCest that Douglas Cox pointed out. A
quick skim of the web site shows that it is a very much a
subset and, while it might be a useful tool in its own right, it
doesn't look plausible as something to develop/debug standard Fortran
code in. (For just one example, no integer type - everything is real).

I vaguely recall something about an old f77 (or maybe prior)
interpreter.

> Is it simply because it is really hard to do or
> because nobody has taken the time/had the inclination to do it?

Well, that's sort of two sides of the same reason.  (If it were easy,
then it wouldn't take much time/inclination).  But I'd say that yes,
that's part of it.  It is clearly possible, at least with some modest
restrictions. The question is whether there is sufficient market for
such a thing.  (The same market concept applies to free software - even
when money isn't directly involved, it tends to take a substantial
number of interested people to motivate a free software effort; we might
as well call it a market).

As to why there isn't adequate market.  That's harder to say, but it
is pretty easy to observe that there isn't.  Occasionally people ask,
like you, but you don't hear a lot of people asking, or almost anyone
doing so very pointedly.

A big piece of the Fortran market is performance oriented.  That is
sometimes cited as a reason.  It might be a contributor, but I can't
see it as the whole reason, because there are clearly also other
segments of the market.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Jason Nielsen <jdn@cs.sfu.ca> wrote in message news:<Pine.LNX.4.60.0410161511130.2756@janus
>...
> Hi all,
>
> I was wondering if there is a good reason why an f95 interpreter doesn't
> exist (or at least I'm not aware of one).

Stuart Midgley has worked on an interpreted, Fortran-based language --
see http://smidgley.customer.netspace.net.au/fortran/ and
http://www.jiscmail.ac.uk/cgi-bin/w...36&I=
-1
.

Tastes differ, but I like the compile-debug cycle. It annoys me when
my Python program produces some output but then crashes with an error
that would be caught at compile time in Fortran. With F95, using
modules so that procedure calls are checked, I find that my programs
often produce sensible results the first time they compile cleanly.

(comp.compilers added)
Jason Nielsen wrote:

> I was wondering if there is a good reason why an f95 interpreter
> doesn't exist (or at least I'm not aware of one).  I recently had to
> work on a project using OCaml and was quite impressed with the fact
> that it has an interpreter and can be compiled to pretty good native
> code (i.e. runs reasonably fast).  I have gotten used to having
> either one or the other.. but not both.  The debug-devel time
> without the compile-debug cycle was quite enjoyable and got me to
> thinking about this question.

(snip)

There are very few true interpreters for programming languages.  (Not
counting command languages such as unix csh, sh, and DOS/Windows .BAT
files.)

Most are closer to incremental compilers, where at minimum each
statement is compiled to an intermediate form, converting language
tokens (keywords) to an internal form, and possibly user symbols
(variable names) also.  Most BASIC systems work like that, many
compiling each line when it is entered.  On the continuum between
compilers and interpreters, it is most of the way toward interpreters.

As for Fortran, there was WATFIV (successor to WATFOR) both very high
speed, in core compilers.  Compiled code is generated directly in
core, and not written out as an object file.  Fixing up branch targets
is easy, it can be done much faster than compilers that do write an
object file, but the code is really compiled.

An interpreter or incremental compiler usually requires a search for
branch targets (GOTO destination, or structured programing constructs)
which may search through much of the program searching for the target.
Compiled code will have the address already known.

-- glen
[Back in the early 1970s, IBM had two PL/I compilers, the X compiler
which generated optimized machine code and the CK (checkout) compiler
which generated bytecodes and interpreted them.  They used the same
front end and accepted the same input language.  The CK compiler
offered all of the nice debugging stuff you'd expect from an
intepreter, full range checks, bogus pointers, type mismatches, all
that.  You could even tell CK to generate code with call stubs so you
could run a mix of X and CK code if you wanted.  Of course, high
quality debugging support like that is now obsolete. -John]

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

[snip]

>There are very few true interpreters for programming languages.  (Not
>counting command languages such as unix csh, sh, and DOS/Windows .BAT
>files.)
>
>Most are closer to incremental compilers, where at minimum each
>statement is compiled to an intermediate form, converting language
>tokens (keywords) to an internal form, and possibly user symbols
>(variable names) also.  Most BASIC systems work like that, many
>compiling each line when it is entered.  On the continuum between

IME, no.  They simply convert it to a tokenised form.

>compilers and interpreters, it is most of the way toward interpreters.

[snip]

>[Back in the early 1970s, IBM had two PL/I compilers, the X compiler
>which generated optimized machine code and the CK (checkout) compiler
>which generated bytecodes and interpreted them.  They used the same
>front end and accepted the same input language.  The CK compiler
>offered all of the nice debugging stuff you'd expect from an
>intepreter, full range checks, bogus pointers, type mismatches, all
>that.  You could even tell CK to generate code with call stubs so you
>could run a mix of X and CK code if you wanted.  Of course, high
>quality debugging support like that is now obsolete. -John]

Grrr!

How fast do you want your wrong answers?

Sincerely,

Gene Wirchenko
[Do keep in mind that back in those days the fast computers ran at 1 MHz,
so the difference in code speed could make the difference between a
minute-long run and an all-night run.  But it is my impression that the
call stubs were mostly used to call code in precompiled libraries. -John]

Gene Wirchenko wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

(snip)
 

>      IME, no.  They simply convert it to a tokenised form.

Sorry, yes, that is what I meant.  That might include a
pointer to the symbol table entry and converting numeric
constants to their internal representation, though.
Some would do it as the line was entered, others only
with the RUN command.

There is also a story of one HP machine that converted
algebraic expressions to RPN on entry, and back again
to display them (as in the list command).
 

> [snip]
 
(snip)

I never use the checkout compiler.  I think it was too expensive
for many to buy. (I suppose rent is more accurate.)

> [Do keep in mind that back in those days the fast computers ran at 1 MHz,
> so the difference in code speed could make the difference between a
> minute-long run and an all-night run.  But it is my impression that the
> call stubs were mostly used to call code in precompiled libraries. -John]

I am not sure how small a machine those compilers would be
used on.  The 360/91 and 370/168 were closer to 16 MHz.

PL/I (F) was supposed to be able to run on a 360/40 with 64K
of core, 20K for the OS, 44K for the compiler.  I don't believe
that feature was kept for the newer compilers.

-- glen
[My assistant, Mr. Google, points out that an article in the IBM
Systems Journal published in 1973 about the checkout compiler is
available as http://www.research.ibm.com/journal.../ibmsj1203G.pdf
and another from the UK Computer Journal is at
[url]http://www3.oup.co.uk/computer_journal/hdb/Volume_15/Issue_02/150099.sgm.abs.html[
/url]
The former says the interpreter was about 250K but they used overlays
to fold it into 60K.  The latter says it ran reasonably fast on the
1MHz 360/65 in 100K. -John]