Having downloaded a LISP demo compiler and tried out some *very* basic
LISP things I wonder if anyone has suggestions on web-resources that's
good for guys like me who do quite a lot of programming (mostly in
Fortran 95) but never have tried Lisp. To start with, I just want to
learn enough to get a feeling of whether or not our research group can
use LISP for anything.
I also wonder a bit about the portability of LISP. I've checked out
Digitools LISP compiler for Macintosh and there I understood that it
should be pretty portable. On the other hand, I saw in a communication
concerning the Igor software from Notehead (they used Digitools on MacOS
and Xanalys on Windows) that one must be careful when programming. In my
Fortran 95 heavy-duty calculation programs (no fancy GUI stuff) I'm used
to porting being a question only of changing the path-delimiter (which I
define globally, i.e. using a module for those who know Fortran). Now
since LISP can do a lot of fancy GUI stuff (a reason why it may be
interesting for me) I suspect that porting may be a lot more pain than
that.
thankful for any help
Mattias
On Tue, 03 Jul 2001 17:24:39 +0200, Mattias Alveteg
<···············@chemeng.lth.se> wrote:
> LISP things I wonder if anyone has suggestions on web-resources that's
> good for guys like me who do quite a lot of programming (mostly in
Here are a few resources:
ALU - Association of Lisp Users (out of date but still useful)
http://www.alu.org
CLiki
http://ww.telent.net/cliki
Successful Lisp
http://psg.com/~dlamkins/sl/contents.html
Common Lisp: A Gentle Introduction to Symbolic Computation
http://www.cs.cmu.edu:80/afs/cs.cmu.edu/user/dst/www/LispBook/index.html
Basic Lisp Techniques
http://www.franz.com/resources/educational_resources/cooper.book.pdf
> learn enough to get a feeling of whether or not our research group can
> use LISP for anything.
May I ask what kind of research your group does?
> and Xanalys on Windows) that one must be careful when programming. In my
> Fortran 95 heavy-duty calculation programs (no fancy GUI stuff) I'm used
You may want to check the math section of the above mentioned CLiki.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso wrote:
>
> On Tue, 03 Jul 2001 17:24:39 +0200, Mattias Alveteg
>[snip]
> Here are a few resources:
Thank's, that ought to get me started. I remember seing Lisp back in the
early 80's and thought it was dead until I downloaded Igor (a beautiful
program) and learnt that it is programmed in Lisp.
>
> May I ask what kind of research your group does?
We're kind of into chemical engineering (hence the chemeng address) but
not the way one might expect. Our most developed models (PROFILE and
SAFE) deals with soil acidification and soil chemistry. They are used
mostly within the UN/ECE Convention on Long Range Transboundary Air
Pollution. To put it in mathematical terms we mainly solve a lot of
ordinary differential equations, often with loads of implicit functions
that needs to be iterated at each time-step. The calculations take
anything from a few seconds to several weeks (on the fastest computer we
can afford) depending on the model used, the number of sites in the
calculation and whether or not uncertainty is assessed.
Some of our models are available for anonymous download free of charge
(http://www2.chemeng.lth.se), but in their current state they require
pretty much of the user both in terms of expert knowledge (preferably in
a systems-thinking kind of way) concerning the system modelled and in
terms of hacking input files. I've experimented with GUIs in HyperCard,
MetaCard and Java to make it slightly easier for the user. The GUIs I
make are very simple. It's a matter of the user entering numbers in
various fields, the GUI exporting it to one or more ascii files and then
possibly wait for the calculation program to do the calculations so the
GUI can show the results afterwards. I deliberately keep the GUI and the
calculation program apart since the kind of problems they involve are
quite different.
MetaCard (http://www.metacard.com) is what I currently use (it can
compile for some 15 platforms including MacOS, Windows and various
UNIX-flavors). A downside with MetaCard is that it is pretty expensive
(environmentalists don't have much money:( ) and that I currently have
loads of strange problems with portability.
So what I'm thinking of is mainly if we could use Lisp to program some
GUIs and compile them for different platforms. (Then I'm also curious
and like to learn a little for my own amusement ;)
>
> > and Xanalys on Windows) that one must be careful when programming. In my
> > Fortran 95 heavy-duty calculation programs (no fancy GUI stuff) I'm used
>
> You may want to check the math section of the above mentioned CLiki.
The're many reasons why I won't change from Fortran to other languages
for our number-crunching, one of them is that dealing with matrices
(which we do a lot) is very similar to Matlab (e.g. doing A(:,1)=B(:)
for copying the B vector into the first column of the A matrix) and
Matlab is familiar to our students. So, teaching new PhD students
Fortran is pretty easy. If I changed from Fortran to something else for
the number-crunching I would have to take over the few things that I
managed to push to others and that would be seriously bad. The
GUI-programming I haven't managed to push to anyone else, so there it
doesn't matter that much. Another thing is that the GUI-programming
doesn't require that much inside knowledge of our models so there's a
possibility that we occasionally might hire an inexpensive
programming-student to solve some specific GUI tasks.
mattias
PS
Oops, my reply got a bit long...sorry for that
>>>>> "MA" == Mattias Alveteg <···············@chemeng.lth.se> writes:
[...]
MA> MetaCard (http://www.metacard.com) is what I currently use (it
MA> can compile for some 15 platforms including MacOS, Windows and
MA> various UNIX-flavors). A downside with MetaCard is that it is
MA> pretty expensive (environmentalists don't have much money:( )
MA> and that I currently have loads of strange problems with
MA> portability.
Would the GUI requirements fit into a web-based scheme? [I'll assume not]
MA> So what I'm thinking of is mainly if we could use Lisp to
MA> program some GUIs and compile them for different
MA> platforms. (Then I'm also curious and like to learn a little
MA> for my own amusement ;) [...]
AFAIK (please correct me), you cannot get a single Common Lisp + GUI
to run on Unix/Windows/MacOS. CLIM would, but that would require
you to get two commercial lisp systems (MCL for Mac's and Allegro or
LispWorks for Unix/Windows). Garnet runs on Unix and Mac's but not on
Windows. (insert more combination here...).
If you can bring up X servers on all clients, then your choices are
broader as the GUI+Lisp only need to run on Unix/X. Check the alu.org
site for options.
I believe PLT Scheme is portable with its GUI toolkit across all three
platforms, so if you want something lispy that might be another
alternative. Otherwise, I'm afraid your best bet will be something
like Tk/Tcl which IMHO isn't too bad for simple tasks.
cheers,
BM
Bulent Murtezaoglu wrote:
>
> >>>>> "MA" == Mattias Alveteg <···············@chemeng.lth.se> writes:
> [...]
>
>
> Would the GUI requirements fit into a web-based scheme? [I'll assume not]
We've discussed that and been thinking of letting people using our
server to do all their calculations. I've voted against it (and since I
so far do most of the programming...) since I don't think we have the
funds to provide others with the computer power needed. But, of course a
possible solution would be a local "web-based" solution using MSIE or
Netscape and forms to create the necessary input files. But, since I'm
thinking a graphic front to aid the model user in entering the 80+
different parameters needed to run a model I think such a solution would
be a bit messy, especially with all the help features I want to implement.
>
> MA> So what I'm thinking of is mainly if we could use Lisp to
> MA> program some GUIs and compile them for different
> MA> platforms. (Then I'm also curious and like to learn a little
> MA> for my own amusement ;) [...]
>
> AFAIK (please correct me), you cannot get a single Common Lisp + GUI
> to run on Unix/Windows/MacOS. CLIM would, but that would require
> you to get two commercial lisp systems (MCL for Mac's and Allegro or
> LispWorks for Unix/Windows). Garnet runs on Unix and Mac's but not on
> Windows. (insert more combination here...).
Yes, sorry for my confusion, I'm a bit new to the Lisp world. I probably
mean CLIM rather than Lisp, but if I remember correctly that's not too
expensive compared to MetaCard ($995 per platform and user). Since the
scientists we cooperate with mainly use MacOS or Windows (a few use
Linux) getting a graphical user interface to work on these two OS would
be the highest priority.
> I believe PLT Scheme is portable with its GUI toolkit across all three
> platforms, so if you want something lispy that might be another
> alternative. Otherwise, I'm afraid your best bet will be something
> like Tk/Tcl which IMHO isn't too bad for simple tasks.
Thanks for these hints! I even know less about these than I do of Lisp,
but judging from what I found on a simple internet search, this to
sounds interesting.
/mattias
>>>>> "MA" == Mattias Alveteg <···············@chemeng.lth.se> writes:
[...]
MA> Yes, sorry for my confusion, I'm a bit new to the Lisp
MA> world. I probably mean CLIM rather than Lisp,
CLIM stands for Common Lisp Interface Manager (or somesuch) so you
probably mean both. You will need a common lisp system + CLIM
if it's sold as an additional product. CLIM is not the only GUI
option that comes with commercial common lisps, but if you use
CLIM then you can remain portable across implementations (in theory
but I didn't hear anyone scream otherwise).
MA> but if I
MA> remember correctly that's not too expensive compared to
MA> MetaCard ($995 per platform and user).
PER USER? How many of those are there? Are you sure you're not
being overly modest when you call your interface work "simple"?
MA> Since the scientists we
MA> cooperate with mainly use MacOS or Windows (a few use Linux)
MA> getting a graphical user interface to work on these two OS
MA> would be the highest priority.
If I am understanding the numbers correctly, you can afford to get
systems from two vendors for three platforms (Windows Lisp vendors
also have Linux versions, but you'll have to go to DigiTool for a
Mac Common Lisp + CLIM).
Most vendors have evaluation systems that you can download. Lisp
vendors are usually nice enough to let you evaluate more than what's
in their downloadable version if you contact them and ask (CLIM might
not be bundled in all downloadable eval. versions for example).
cheers,
BM
> MA> remember correctly that's not too expensive compared to
> MA> MetaCard ($995 per platform and user).
>
> PER USER? How many of those are there? Are you sure you're not
> being overly modest when you call your interface work "simple"?
Don't think so, but the costume I bought is probably a bit big ;o). I
don't do any fancy graphics or anything, but I do use multiple windows
and "interactive" help features. I bought MetaCard since it could import
the old HyperCard things we had and since none of the guys I talked to
back then knew of any alternatives in creating cross-platform GUIs (at
our department most people by are more interested in publishing articles
than creating programs that others can use :(. I mess around with GUIs
partly because I find it fun). MetaCard can do pretty fancy stuff but I
use just the basics. So far I have one single license for MacOS and
compile for MacOS and Windows under MacOS and then try the Windows
version out using a PC.
Thanks for all your kind help
mattias
On Wed, 04 Jul 2001 22:36:42 +0200, Mattias Alveteg
<···············@chemeng.lth.se> wrote:
> funds to provide others with the computer power needed. But, of course a
> possible solution would be a local "web-based" solution using MSIE or
> Netscape and forms to create the necessary input files. But, since I'm
> thinking a graphic front to aid the model user in entering the 80+
> different parameters needed to run a model I think such a solution would
> be a bit messy, especially with all the help features I want to implement.
Here is a possibly relevant paper:
Adapting CLIM Applications for Use on the WWW
ftp://ftp.ai.sri.com/pub/papers/paley-luv95.ps.Z
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
On Wed, 04 Jul 2001 19:50:15 +0200, Mattias Alveteg
<···············@chemeng.lth.se> wrote:
> The're many reasons why I won't change from Fortran to other languages
> for our number-crunching, one of them is that dealing with matrices
No need to change: just use a Fortran to Lisp translator :)
I actually didn't suggest that you change to other languages. I mentioned
CLiki's math section because, as a Lisp novice, you may be interested in
learning how problems from a domain you are familiar with are solved in
Lisp.
Incidentally, such a Fortran to Lisp translator actually exists. It is
`f2cl', which is maintained as part of CLOCC (Common Lisp Open Code
Collection):
http://clocc.sourceforge.net/
You may also see the following papers:
"A FORTRAN->LISP Translator"
http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
Fast Floating Point Processing in Common Lisp
http://www.cs.berkeley.edu/~fateman/papers/lispfloat.ps
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso wrote:
>
>
> Incidentally, such a Fortran to Lisp translator actually exists. It is
> `f2cl', which is maintained as part of CLOCC (Common Lisp Open Code
> Collection):
>
> http://clocc.sourceforge.net/
>
> You may also see the following papers:
>
> "A FORTRAN->LISP Translator"
> http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
I can't seem to find anything downloadable, maybe I misunderstand
something here. The examples in the paper don't seem too promising
though. It seems like they mean FORTRAN 77 rather than Fortran 90/95. If
it that's true, it wouldn't surprise me. Other translators (like f2c)
usually also only work for FORTRAN 77 (Although, I should point out that
FORTRAN 77 is a subset of Fortran 90 so in rare cases where the
programmer haven't used the full potential of Fortran one might find a
.f90 file that can be translated)
Anyway, thanks for your help
mattias
Mattias Alveteg <···············@chemeng.lth.se> writes:
> Paolo Amoroso wrote:
> >
> >
> > Incidentally, such a Fortran to Lisp translator actually exists. It is
> > `f2cl', which is maintained as part of CLOCC (Common Lisp Open Code
> > Collection):
> >
> > http://clocc.sourceforge.net/
> >
> > You may also see the following papers:
> >
> > "A FORTRAN->LISP Translator"
> > http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
>
> I can't seem to find anything downloadable, maybe I misunderstand
> something here. The examples in the paper don't seem too promising
> though.
Promising, as in, making any such promises? It's just a paper on some
of the issues I confronted. I think it was the first conference paper
I ever wrote, so it probably wasn't "deep". It makes no promise of
being or offering code you can use.
There was a translator, but I wrote it for the MACSYMA group, at least
partially for pay, and it's part of the intellectual property suite which
is Macsyma.
[Incidentally, the translator took years to write, worked first time
it was deployed, and never had any translation bugs reported. I
tested it against the IMSL FORTRAN library and found only one
discrepancy, which after days of debugging turned out to be a bug in
the IMSL documentation, not in my translator. It's possible the
translator did have some subtle problems here and there--I certainly
never warrantied it as bug-free. But, all in all, I cite it
occasionally as a counterexample to the claim that big programs never
work fresh out of the box. (Of course, I tested most of the parts in
isolation as I was building it, but one always does that.)]
It was originally quite PDP10-specific, but George Carrette kept it
alive for a long time after it ordinarily would have expired, porting
it to various other platforms, I think. The overall architecture of the thing
was quite general/portable (and similar in nature to what Symbolics
Fortran did, though it could accomodate some type overlays that
I doubt Symbolics Fortran could), but I had just coded a few macros in
a way that required massaging that I never had time to make general to
other platforms, and George did. Also, I made it quite forgiving of all
kinds of variant syntaxes; it didn't just implement the standard. It
probably could have been adapted for later Fortran specs, I just didn't
have a time machine so couldn't do that.
I don't know where it is now. I have paper source listings that could
be scanned but no online copy. George may have it online somewhere.
> It seems like they mean FORTRAN 77 rather than Fortran 90/95.
The paper was written in 1978, so no, FORTRAN 77 per se was probably not
a consideration, and 90/95 would have been tough. ;-)
> If
> it that's true, it wouldn't surprise me. Other translators (like f2c)
> usually also only work for FORTRAN 77 (Although, I should point out that
> FORTRAN 77 is a subset of Fortran 90 so in rare cases where the
> programmer haven't used the full potential of Fortran one might find a
> .f90 file that can be translated)
>
> Anyway, thanks for your help
>
> mattias
On Thu, 05 Jul 2001 12:09:07 +0200, Mattias Alveteg
<···············@chemeng.lth.se> wrote:
> Paolo Amoroso wrote:
[...]
> > Incidentally, such a Fortran to Lisp translator actually exists. It is
> > `f2cl', which is maintained as part of CLOCC (Common Lisp Open Code
> > Collection):
> >
> > http://clocc.sourceforge.net/
[...]
> I can't seem to find anything downloadable, maybe I misunderstand
The f2cl code is in directory src/f2cl of the CLOCC source tree. Follow the
link to the CVS repository from the project page:
http://sourceforge.net/projects/clocc
There may also be a distribution archive in the Files section.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Forgive me Kent M Pitman if I sounded rude. What I meant was that for a
fortran to lisp translator to be of any use (=to sound promising) to me it
must understand modern Fortran. Now that I found the documentation (Thanks
Paolo Amoroso) I see that f2cl understands FORTRAN 77. So far I haven't
seen any code translators that does understand modern Fortran. It's not so
surprising. Fortran 90 was a MAJOR structural change in the language that
changed it from an old dinosaur into something really useful. As an
example, there was *no* hierarchy in FORTRAN 77 ! All subroutines and
functions were on the top level. Imagine the difficulty with conflicting
names (especially since variables names were limited to something like 8
characters) in large programming projects. There was no dynamic memory
management. There was no pointers, no complex numbers, no derived types, no
array arithmetics, recursive routines were not allowed!. In fact it was so
bad that loads of different extensions were introduced to ease the pain.
The extensions, however, made porting a nightmare. Not surprising that
FORTRAN got a bad reputation. Now Fortran is back on the track again with
strong standards (Fortran 90, 95 and eventually 2K) and easily portable
code.
If anyone wonders why I seem to SHOUT: by convention pre-Fortran 90 version
of the language are denoted in capitals (FORTRAN 77, FORTRAN IV etc.) while
Fortran 90 and newer versions are not. So I'm not shouting, I'm just
following a naming convention. By the way, if someone haven't understood it
yet: I really hated FORTRAN 77 for it's many shortcomings and the extreme
difficulty to write nice code, but I fell in love with Fortran 90 ;o)
For three reasons I doubt ;( that there will be any Fortran to anything
translators in the near future:
1) Fortran is structurally different from FORTRAN making it very difficult
to update old translators (I once made a program that understood the syntax
of FORTRAN, indented the code properly and warned if there was a serious
syntax error, like a missing "end if". I haven't updated it to understand
Fortran, it's just too much work and I don't need it that much nowadays)
2) Code written in Fortran is always relatively new code. It's often easier
to write new code in the language you want to work in than to start writing
in something and then translate it to something else. The new compilers
are also pretty efficient so I doubt it that you will increase the
execution speed with a translator.
3) You can interface Fortran with other languages. How to interface C/C++
with Fortran is a common question in the comp.lang.fortran newsgroup.
/mattias
PS
I get a bit carried away when I talk of languages (old FORTRAN) that I
don't like. I seriously don't mean to offend anyone, it's just that I got
so annoyed the years I was forced to program in FORTRAN.
Mattias Alveteg wrote:
> Paolo Amoroso wrote:
> >
> >
> > Incidentally, such a Fortran to Lisp translator actually exists. It is
> > `f2cl', which is maintained as part of CLOCC (Common Lisp Open Code
> > Collection):
> >
> > http://clocc.sourceforge.net/
> >
> > You may also see the following papers:
> >
> > "A FORTRAN->LISP Translator"
> > http://world.std.com/~pitman/Papers/Fortran-to-Lisp.html
>
> I can't seem to find anything downloadable, maybe I misunderstand
> something here. The examples in the paper don't seem too promising
> though. It seems like they mean FORTRAN 77 rather than Fortran 90/95. If
> it that's true, it wouldn't surprise me. Other translators (like f2c)
> usually also only work for FORTRAN 77 (Although, I should point out that
> FORTRAN 77 is a subset of Fortran 90 so in rare cases where the
> programmer haven't used the full potential of Fortran one might find a
> .f90 file that can be translated)
>
> Anyway, thanks for your help
>
> mattias
* Mattias Alveteg wrote:
> There was no pointers, no complex numbers, no derived types, no
> array arithmetics, recursive routines were not allowed!.
There certainly were complex numbers. FORTRAN 66 had complex numbers.
I think FORTRAN I did not, but they have been there a long time.
--tim
Mattias Alveteg <···············@chemeng.lth.se> wrote:
······················@chemeng.lth.se...
> Forgive me Kent M Pitman if I sounded rude. What I meant was that for a
> fortran to lisp translator to be of any use (=to sound promising) to me it
> must understand modern Fortran. Now that I found the documentation (Thanks
> Paolo Amoroso) I see that f2cl understands FORTRAN 77. So far I haven't
I think this is not true. Translators like f2cl are mainly used to
port/maintain OLD fortran code. It has no sense to write programs in F95
nowadays
just because you want to translate it to another language...
I am just porting such old fortran 77 program just now at work... (God!...
Why this is not an old *Lisp* program?...)
I've just Mattias's post carefully, and I can see "to be of any use (=to
sound promising) TO ME" - OK, I am sorry
:)
[..]
> management. There was no pointers, no complex numbers, no derived types,
no
There were complex numbers in F77 for sure.
Regards,
Piotr
my (probably) last contribution to this thread:
Yes you're both right, complex numbers were available in FORTRAN 77, my
mistake. I never used plain vanilla FORTRAN 77 (so I had loads of porting
problems;) so I sometimes get confused on what was included in the standard.
I feel sorry for Piotr having problems with the old FORTRAN 77 code: one can
make really really ugly code in FORTRAN 77 that are lightyears from portable.
Yuck!
signing off
Mattias
Mattias Alveteg <···············@chemeng.lth.se> writes:
> ... As an
> example, there was *no* hierarchy in FORTRAN 77 ! All subroutines and
> functions were on the top level. Imagine the difficulty with conflicting
> names (especially since variables names were limited to something like 8
> characters) in large programming projects. ...
Imagine it? I lived it. :-)
> There was no dynamic memory management.
My translator offered this. :-)
> There was no pointers,
I had this, too, sort of. You could mix Lisp and Fortran, getting Lisp
in its usual call-by-value style and Lisp in a call-by-reference style
using pointers into the Fortran virtual memory array.
> no complex numbers,
Uh, no, there were complexes. Most respectable programmers didn't use them
though. Too slow. Better to hand-code your own using 2d arrays. ;-)
> no derived types,
Well, you could probably have fashioned this in Fortran intermediate
pseudocode coming out of my translator. No one ever used that as a first
class programming language, I think, but they could have.
> no array arithmetics,
Alas, true.
> recursive routines were not allowed!
This worked in a lot of Fortrans of the time, just not in the
standard. I don't think it would have been that hard to make work in
mine, but I don't recall implementing it.
> In fact it was so
> bad that loads of different extensions were introduced to ease the pain.
You left out negative increments in loops, btw. I used to love watching
some compilers recognizing what you were trying to do and saying "the
standard doesn't let you use negative increments" instead of just letting
you do what it obviously knew you wanted.
> The extensions, however, made porting a nightmare. Not surprising that
> FORTRAN got a bad reputation.
It divided the community, but among its users, they would rarely settle for
anything else.
> Now Fortran is back on the track again with strong standards
> (Fortran 90, 95 and eventually 2K) and easily portable code.
Well, portable is of course a property of writing to a standard. But if
you mean some of the more powerful extensions became portable, yeah.
The original language was no less portable than the current one, I'll bet.
Just more restric tive.
> If anyone wonders why I seem to SHOUT: by convention pre-Fortran 90 version
> of the language are denoted in capitals (FORTRAN 77, FORTRAN IV etc.) while
> Fortran 90 and newer versions are not. So I'm not shouting, I'm just
> following a naming convention. By the way, if someone haven't understood it
> yet: I really hated FORTRAN 77 for it's many shortcomings and the extreme
> difficulty to write nice code, but I fell in love with Fortran 90 ;o)
We in the CL community canonicalize input to uppercase, so we're less
surprised than some might be.
> For three reasons I doubt ;( that there will be any Fortran to anything
> translators in the near future:
>
> 1) Fortran is structurally different from FORTRAN making it very difficult
> to update old translators (I once made a program that understood the syntax
> of FORTRAN, indented the code properly and warned if there was a serious
> syntax error, like a missing "end if". I haven't updated it to understand
> Fortran, it's just too much work and I don't need it that much nowadays)
>
> 2) Code written in Fortran is always relatively new code. It's often easier
> to write new code in the language you want to work in than to start writing
> in something and then translate it to something else. The new compilers
> are also pretty efficient so I doubt it that you will increase the
> execution speed with a translator.
>
> 3) You can interface Fortran with other languages. How to interface C/C++
> with Fortran is a common question in the comp.lang.fortran newsgroup.
Well, none of thse seem insurmountable, though 3 seems to suggest no one
should need it. If someone had a commercial need for a Fortran translator,
for which money were available to do it, I'm sure it could be done.
If no one wants one, of course, there's no reason to shed any tears.
Some changes into the future (like cross-calling capabilities)
are for the better.
>
> /mattias
>
> PS
> I get a bit carried away when I talk of languages (old FORTRAN) that I
> don't like. I seriously don't mean to offend anyone, it's just that I got
> so annoyed the years I was forced to program in FORTRAN.
Funny, while I didn't really have much to say to FORTRAN, not being a
numerical person, I always thought it kind of elegant for what it was
trying to do. Abstraction, dynamic memory mangement, etc. may have their
place and are probably good additions. But there was a certain definite
simplicity to early FORTRAN that I think, now that you're graduated from
it, you should try to look back and see.
It took me two years to implement my Fortran->Lisp translator, mostly because
it was my first big project in Lisp. Looking back on it, I don't see why
it took hardly any time at all, other than that Lisp didn't offer as much
help back then as CL does now, and neither did my young brain add much.
Yesterday I implemented an SMTP client for the first time. It was great fun
because they are so ridiculously easy to write because they don't try to
do more than a very few simple things. Old FORTRAN feels that way to me...
[Kent waves his pocketwatch in front of your eyes. It mesmerizes you.]
"It can no longer hurt you. Relax. You are seeing it from an adequate
distance through the safe lens of history. You can finally appreciate
it now..."
Many thanks to all that responded, I'm really overwhelmed by the response.
The Lisp community seems to be a very nice one. It will take a while before
I manage to digest all suggestions, so I will now decrease my activity in
this newsgroup.
Mattias