A Common Lisp Interpreter Built in Cobol

(github.com)

88 points | by abrax3141 1868 days ago

7 comments

  • mrighele 1868 days ago
    > 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 1868 days ago
      > 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 1868 days ago
        PERFORM was in the original 1960 COBOL spec -- but attempting to use it recursively was (and may remain) undefined behavior.
        • zerr 1867 days ago
          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 1867 days ago
            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.)
        • flyinghamster 1867 days ago
          Ah, that makes sense, then. The last time I wrote anything in COBOL was in a class about 35 years ago. ;)
      • drbw 1867 days ago
        Yeah, but there's no local variables or dynamic memory allocation (from what I remember of COBOL85 on Tandems, anyway)
    • dan-robertson 1868 days ago
      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

      • mrighele 1868 days ago
        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.
    • agumonkey 1868 days ago

          define callcc { cp ./stack ./stack.old ; }
    • ww520 1868 days ago
      They can definitely implement garbage collection with copying. Just copy all the live objects to another directory and then "rm -fr old-heap."
  • hprotagonist 1868 days ago
    This is so delightfully insane. I love it.
    • simonblack 1868 days ago
      That's how felt about my 8080 disassembler written in COBOL back in the 80s.

      <grin>

      • chris_wot 1867 days ago
        How the hell did you do that?!?
        • simonblack 1867 days ago
          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 1867 days ago
            Seriously, put this on github.
            • simonblack 1866 days ago
              <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 1868 days ago
    For no good reason, this comes to mind...

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

  • tombert 1868 days ago
    Serious question; outside of purposefully eccentric stuff, does anyone use COBOL for anything new?
    • mhd 1867 days ago
      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.
    • TomMarius 1868 days ago
      Depends on your definition of new. New business logic certainly is still being written in Cobol.
      • protomyth 1867 days ago
        Often because of legislation such as new tax codes or new contracts
    • EamonnMR 1868 days ago
      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.
      • pjmlp 1868 days ago
        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.

  • bluefox 1867 days ago
    More like a very primitive Toy Lisp interpreter.
    • bjoli 1867 days ago
      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 1867 days ago
        >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.

        • lispm 1867 days ago
          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%...

        • stevelosh 1867 days ago
          > 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 1867 days ago
            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".
        • bjoli 1866 days ago
          Common Lisp is "batteries included", and the dev really claimed to have made a common lisp.
  • ngcc_hk 1868 days ago
    Shock, amazed. Anyway 2 years ago.
  • nopacience 1868 days ago
    Great you have done in cobol!

    Please now do it in "brain fuck language"