David B. Serafini wrote:
> In my opinion, part of the solution to this dichotomy would be to have
> a F90 (or F or Elf90) interpreter. Then when you want to write quick
> and dirty programs you could do them from inside emacs and take advantage
> of the compactness of Fortran for math problems. And when you write
programs
> that will have a lifetime of more than a day, you would use the "safer"
> constructs.
>
> Sometimes I think the real competitor to F90 isn't C++ or Java, it's
> Matlab version 5.
I know several people that would agree with you on the Matlab.
> (For the compiler writers out there who are laughing they're guts out, I'm
> well aware of the difficulty of writing a F90 interpreter. But I still
> think it would be a great thing to _have_. I'd much rather have an
> interpreter than all the C++ features people are arguing about.)
Generally an interpreter is easier to implement than a compiler. While an
interpreter for the full Fortran language would be difficult to implement
(fixed source form would be ridiculous and there are some tricky aspects to
free source form), one for a reasonably large subset should be simpler to
implement than a regular compiler. It would not, of course, overlap well with
F or ELF. I would rather it had inferred rather than implicit typing, and
that it be strongly and statically typed, similar to SML, rather than
dynamically typed as with some of the languages I know. This would cause it
to not be a strict subset of Fortran, but a translator to strict Fortran
would be relatively easy to include as a mode of the interpreter.
One particularly sticky point would be libraries, particularly graphics
libraries. Most people use interpreters because they want fast turn around in
results. The best way to get a rapid understanding of data is by plots and
images, so that interpreted numerical languages almost always have extensive
built in graphics capabilities. Fortran does not have graphics capabilities
as part of the standard, so this capability requires an extension to the
language. The interpreter in translation mode could get around this by
including graphics procedures with the same syntax as a popular graphics
package, or by translating to wrapper procedures that call user selectable
procedures.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|