
A Common Lisp Interpreter Built in Cobol - abrax3141
https://github.com/lauryndbrown/Cisp
======
mrighele
> 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 :-)

~~~
flyinghamster
> 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?

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

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

~~~
abrax3141
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.)

------
hprotagonist
This is so delightfully insane. I love it.

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

<grin>

~~~
chris_wot
How the hell did you do that?!?

~~~
simonblack
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
    
     >

~~~
chris_wot
Seriously, put this on github.

~~~
simonblack
<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.

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

[https://m.youtube.com/watch?v=wx8CEy0yMSY](https://m.youtube.com/watch?v=wx8CEy0yMSY)

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

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

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

------
bluefox
More like a very primitive Toy Lisp interpreter.

~~~
bjoli
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.

~~~
coldtea
> _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.

~~~
stevelosh
> 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.

~~~
coldtea
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".

~~~
lispm
See 'language subsets' in the Common Lisp standard.

[http://www.lispworks.com/documentation/lw50/CLHS/Body/01_g.h...](http://www.lispworks.com/documentation/lw50/CLHS/Body/01_g.htm)

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

~~~
coldtea
He's a fair cop.

------
ngcc_hk
Shock, amazed. Anyway 2 years ago.

