A Common Lisp Interpreter Built in Cobol | Hacker News Reader

A Common Lisp Interpreter Built in Cobol

github.com

88 pointsabrax314134 comments

> Due to COBOL's lack of functions and recursion, the recursion required for Lisp is built from the ground up using file processing.

Does this mean that they are storing the stack as records on a file ? Hopefully they will implement tail recursion as soon as possible :-)

Drives are large so there’s less reason for tail recursion if you stack lives on disk anyway.

Also Common Lisp does not require tail recursion and the traditional style doesn’t really use it either

I was thinking more about performance than space. If you hit the disk for every recursive call (not sure if it is the case, I can't read COBOL) the performance is probably going to be terrible even if the files are memory mapped. Optimized tail recursion would avoid most of that.

    define callcc { cp ./stack ./stack.old ; }

They can definitely implement garbage collection with copying. Just copy all the live objects to another directory and then "rm -fr old-heap."

> Due to COBOL's lack of functions and recursion

Wait, what? Someone forgot about the PERFORM verb. Or, are they writing this in an old enough version of COBOL for that not to be present?

PERFORM was in the original 1960 COBOL spec -- but attempting to use it recursively was (and may remain) undefined behavior.

Can't the recursion be implemented explicitly with Stack data structure? (if it's possible to have/implement the stack in COBOL, not sure).

COBOL, and other PLs of that day, were heavily integrated with the ISAM file structure. ISAM a precursor of SQL, and was basically a hash table implemented very efficiently in a file. If you have hash tables, you can do pretty much anything. (Actually, it was better than a hash table. Once you had indexed (I) into the file, you could sequentially read forward (S). The AM is Access Method.)

Ah, that makes sense, then. The last time I wrote anything in COBOL was in a class about 35 years ago. ;)

Yeah, but there's no local variables or dynamic memory allocation (from what I remember of COBOL85 on Tandems, anyway)

This is so delightfully insane. I love it.

That's how felt about my 8080 disassembler written in COBOL back in the 80s.

<grin>

How the hell did you do that?!?

If you like I'll post the code. <grin>

Only 35 years ago.

A few lines from the beginning ....

000010* This program is written in NEVADA COBOL .

000020

000030 IDENTIFICATION DIVISION. 000040

000050 PROGRAM-ID. JACKS-DISASSEMBLER.

000080* Version Number 1.0

000100

000110* AUTHOR. simonblack.

000120

000130* INSTALLATION. Giacomo Software, P.O. Box 584, Hamilton, 3300

000140

000150 DATE-WRITTEN. 29 MARCH 1984.

000160

000170*

000180* THIS PROGRAM PREPARES *

000190* AND DISASSEMBLES INTERMEDIATE PSEUDO-CODE FILES *

000200* INTO 8080 ASSEMBLY LANGUAGE. *

000210* *

000220*

000230

000240 ENVIRONMENT DIVISION.

000250

000260 CONFIGURATION SECTION.

000270 SOURCE-COMPUTER.

000280 CPZ-48000-SBC.

> wc /a/comp/development-jvs/cobol-150623/crak80.cbl

  293  1121 10002 /a/comp/development-jvs/cobol-150623/crak80.cbl

 >

Seriously, put this on github.

<grin>

Nobody bothers about the 8080 these days. If it had been a disassembler for the Z80, it might be a different matter. But there's dozens of those around, and written in C to boot.

For no good reason, this comes to mind...

https://m.youtube.com/watch?v=wx8CEy0yMSY

Serious question; outside of purposefully eccentric stuff, does anyone use COBOL for anything new?

The answer has been "no" for a long time. Once people got excited about Algol they started basing languages on the idea of inline math/expressions. FORTRAN survived by changing; COBOL was mostly abandoned.

On the contrary, modern COBOL supports OOP and there are even compilers for .NET and Java.

Naturally no one is writing greenfields applications, rather incrementally refactoring existing codebases.

Depends on your definition of new. New business logic certainly is still being written in Cobol.

Often because of legislation such as new tax codes or new contracts

New parts of old systems, mostly. There are some huge COBOL application spaces out there, and quite often writing new modules for that with a more modern COBOL mind- and featureset is still easier than writing it with a different technology and then taking the trouble of connecting that to the existing part using eg CORBA.

More like a very primitive Toy Lisp interpreter.

I thought so as well. Nobody would call a python-like language "a python". I understand that the balkanisation of lisp is responsible for the fact that anything s-expr based is called a lisp. But, common lisp and scheme are actual, specified languages.

>Nobody would call a python-like language "a python"

Unlike Python, Lisp is not "batteries included". The original and standard definition of Lisp is the handful of special forms in McCarthy's paper.

Dev didn't say they made a Common Lisp -- just a Lisp.

> Dev didn't say they made a Common Lisp -- just a Lisp.

The first line in the README after the title is:

> A Common Lisp Interpreter Built in COBOL.

True that, though Common Lisp interpreter is not full Common Lisp e.g. "Common Lisp + its tons of standard libs" -- just "interpreter able to parse Common Lisp".

See 'language subsets' in the Common Lisp standard.

http://www.lispworks.com/documentation/lw50/CLHS/Body/01_g.h...

Roughly: A language would be a subset of Common Lisp, when all programs in that language are valid standard Common Lisp programs.

He's a fair cop.

McCarthy and his team published a lot of stuff. As for Python, Lisp was defined together with a reference implementation.

See the Lisp 1 programmer's manual from 1960:

http://history.siam.org/sup/Fox_1960_LISP.pdf

This was then expanded into Lisp 1.5:

http://www.softwarepreservation.org/projects/LISP/book/LISP%...

Common Lisp is "batteries included", and the dev really claimed to have made a common lisp.

Shock, amazed. Anyway 2 years ago.

Reply on news.ycombinator.com