Back

@screwtape

It's a pity I never wrote up my fortran to lisp translator as a thesis. I ended up not majoring in CS so didn't need to write a thesis even though I wrote the translator. I did write a paper on it, but not really on all the macrology it had going with it. There was an intermediate lispy notation for being able to "talk fortran" within Lisp (Maclisp, as it was at the time, not CL). I'm not sure if that code is still around. It wasn't pretty code, probably, because it was early in my coming-to-lisp experience, and it was for a very old version of Fortran, so it might not matter today anyway, but it did work decently well and addressed complex issues like call-by-reference parameters (at some cost in efficiency), equivalence statements, the need of some fortran subroutines for you to pass pointers to working memory where they do their work, and the not-then-much-talked-about issue of Fortran's need for a GC.

It requires more than just a LET if you really want to be correct to what Fortran promises, since Lisp is call-by-value. I effectively had to create a "fortran virtual machine" as a big array and then have functions pass indexes into that big array in order to get the sense of call by reference, but of course those indexes had to be decoded specially, too, so there were macros at every point.

What a lot of people who didn't have access to my translator did in the timeframe when I was developing things was just treat Fortran as if its precise semantics didn't matter and as if it was just another syntax for Lisp or any algebraic language. I'm particularly fond of Pratt parsers and as a consequence of having my mind warped by them I never got excited by YACC and its progeny. CGOL was created on this principle, and was effectively an infix syntax layer you could add to Lisp. Far less support overhead but not really Fortran.

People speak of wanting language support when often they just want syntax support, or are willing to take crude approximations.

But the environment I defined theoretically would have let people go back and forth, I just didn't see a lot of people in the Lisp world saying "aw, can't I please code in Fortran semantics?" :)

I haven't tracked any of this over the years so am curious if someone knows what the modern state of the art is on that whole range of things.

I think George Carrette may have taken my fortran to lisp translator and given in a new life in some other venue, but I've not tracked that either.

@kentpitman There is a Fortran for the LMI Lambda, with traces of GJC name on files. Which might be copies from you.

FWIW ...

@screwtape

@kentpitman "The Fortran Virtual Machine

A number of conventions are adhered to in all translations of Fortran
programs in order to assure that the proper effect of these routines is
carried through during the translation.

Data Storage

In the runtime environment of a translated Fortran routine, there will
exist a set of library routines for managing the data areas used by the
translation. Essentially, all memory references in the source Fortran will
"

@screwtape

@kentpitman @screwtape Alas this tape ate it self. So a few blocks in .. it is all garbage.

@amszmidt
Can you quickly describe these tapes you have to me
@kentpitman

@screwtape no :-) it is hundreds of tapes from RGs basment. @kentpitman

@amszmidt @screwtape

Mine might be in the ITS emulator code. Ill poke around. Maybe @larsbrinkhoff or Eric Swenson knows...

I'm uncertain how or whether it relates to any translator/emulator/compiler that the LMITI lispm might have had.

Symbolics had a set of such tools that I don't think overlapped. They were managed by zmacs editing modes. I think Dave Stryker's group, which did the the other language support, took a much lower level appruach than my translator to maclisp (on the pdp10, not a lispm) was operating. I think they were doing output to assembly level code, whereas I was doing source to source with macro and subroutine support. (For Prolog, for example, I think they had to build in primitive low-level support for logic variables, rather than emulate them.)

@amszmidt @screwtape @larsbrinkhoff

The only write-up I ever did was here:
https://nhplace.com/kent/Papers/Fortran-to-Lisp.html

Here's a reference to Pratt's CGOL:
https://dspace.mit.edu/bitstream/handle/1721.1/41951/AI_WP_121.pdf?sequence=1

It was based on the so-called Pratt parser, which Pratt called a top-down operator precedence parser. I've probably previously cited this tech, which I like a lot. I'm sure there are packaged versions of this with easier to read doc, but I like citing original sources.
https://dl.acm.org/doi/pdf/10.1145/512927.512931

@larsbrinkhoff @amszmidt
@screwtape

I can see how IMSL would be a problem, but really from the point of view of the translator and my thesis, that was more a 'proof of concept' than anything. It could have been used for other things.

So, for the translator itself, there's some part that the Macsyma group paid me to do, probably using government grants, and that should be solvable, like the other MIT software, and then there's whatever part I did on thesis (a privilege I paid for), which I've never asserted any restrictive claim over and have no plans to do.

There was no real marketplace/venue in which to sell anything I'd made. I could go on about that, but probably already have, and I have other things to be doing tonight. :)

Maybe the parenthetical "yet" means you have the sources. If you don't have them, it's slightly possible I have hardcopy somewhere we could scan. But I don't know if it's a latest version, so better if you have something believed to be latest.

Though, again, George Carrette kind of grabbed it and seemed to give it new life elsewhere I didn't track and he might have best versions. I sent him email about this conversation so maybe he'll have something to say.