Hacker News Reader

Comment by larrykwg | Hacker News Reader

reading old C like this, I always wonder how could people code like this back then but apparently it was transpiled from fortran. So I'd assume the original code looked better. I dug around and found it, for comparison here is the original rooms.f vs. rooms.c:

https://paste.ubuntu.com/25458063/

https://github.com/mgius/zork/blob/master/rooms.c

Here is the full fortran code: http://gunkies.org/wiki/Zork#Source_code

View on HN

The original MDL source code is beautiful to read:

https://github.com/itafroma/zork-mdl

thanks I hope thats the end of that rabbithole, that MDL almost looks like XML

neat: https://github.com/itafroma/zork-mdl/blob/master/rooms.mud#L...

Would be interesting to make a React port of this for the web, might look similar to MDL

It looks exactly like Lisp to me, just with angle brackets rather than parens.

That's because both LISP, XML (and React) are just trees.

Honest question as someone who never got comfortable with Lisp languages. Is the code in parser.mud easy to read. One of those 100 line functions, could you jump to the middle of it and start understanding the meaning as someone familiar with C like languages? Even though I can figure out the syntax it looks like line noise to me but perhaps it is because i've not done much Lisp coding.

I wouldn't call that code easy to read, and that's coming as someone who has actually at some point learned enough MDL to actually know the syntax rather than have to reverse engineer it on the spot. There's a couple of reasons why that code is rough to read today:

- It's doing very complicated operations that operate on mutable global data, and structuring it as huge and deeply nested functions rather than splitting the operations up to smaller chunks with meaningful names. But you'd see exactly the same kind of thing in non-Lisp source code of that era; it's just different sensibilities.

- The code is incredibly heavy on conditionals. Which makes sense given the problem domain: parsing a pseudo-natural language. But MDL is a language where the conditionals kind of suck. COND is basically unreadable in any Lisp, you'd very rarely see people use it today. In CL you'd have more readable options like IF, WHEN and UNLESS. In MDL the only option is misusing short-circuiting AND/OR as a poor man's IF. Which they do in places, which doesn't help readability either.

- The use of angle brackets makes everything look like a sea of less-/greater -than comparisons. At least I just can't help it. It's especially bad when combined with the array indexing syntax.

> COND is basically unreadable in any Lisp, you'd very rarely see people use it today. In CL you'd have more readable options like IF, WHEN and UNLESS.

I wouldn't say "very rarely"; COND is still used for multi-way conditionals. Virtually everyone I know would write:

    (cond ((minusp x) 'negative)
          ((plusp  x) 'positive)
          (t          'zero))

Rather than:

    (if (minusp x)
        'negative
        (if (plusp x)
            'positive
            'zero))

IF, WHEN, and UNLESS are generally preferred where they fit nowadays, but I wouldn't call writing them with COND "basically unreadable", either, ie:

    (cond (pred then)
          (t    else))
    (cond (pred then))
    (cond ((not pred) then))

Compared to:

    (if pred then else)
    (when pred then)
    (unless pred then)

Indeed, I always thought COND was a construct sorely missing from other languages. Pattern matching is becoming popular for similar uses. I honestly feel it can go over board in many of the same ways though.

As someone very comfortable with Lisp languages: it is hard to read. Initially, the angle brackets do throw me off a bit.

Beyond that, I'd have to read the language manual to make sense of notations like ,foo and .bar.

The code makes a lot of references to non-local names. Someone reading the code would benefit from being familiar with the semantics of what those denote.

What's going on in those functions isn't "rocket science" though.

Notice that MDL is almost Common Lisp:

    <DEFINE WAIT ("OPTIONAL" (NUM 3))
        #DECL ((NUM) FIX)
        <TELL "Time passes...">
        <REPEAT ((N .NUM))
            #DECL ((N) FIX)
            <COND (<OR <L? <SET N <- .N 1>> 0>
                       <CLOCK-DEMON ,CLOCKER>
                       <FIGHTING ,FIGHT-DEMON>>
                   <RETURN>)>>>


    (defun wait (&optional (num 3))         ; same arglist
      (declare (fixnum num))                ; similar declaration
      (tell "Time passes...")               ; some call
      (repeat ((n num))                     ; some loop macro, see below
        (declare (fixnum n))                ; declaration
        (cond ((or (< (setq n (- n 1)) 0)   ; old-style COND, OR, <, SETQ, -
                   (clock-demon clocker)    ; some call
                   (fighting fight-demon))  ; some call
               (return)))))                 ; return from loop

Where REPEAT would be implemented as:

    (defmacro repeat (vars decl &body body)
      `(let ,vars
         ,decl
         (loop (progn ,@body))))

Common Lisp basically got type declarations, rich argument lists, ... from MDL.

I read parts of the MDL manual. It supported hacks whereby it could shift to using parentheses, as well as evaluation/quoting conventions that are more like Lisp.

Indeed... as soon as I saw this, I skimmed the (smug towards Lispers!) MDL primer [0] and wrote a few (broken) esrap rules to parse some MDL into Lisp. For example yours gives:

    DEMUDDLE> (parse 'expr *lispm-expr*)
    (DEFINE 'WAIT ("OPTIONAL" (NUM 3)) (TYPED DECL ((NUM) FIX))
     (TELL "Time passes...")
     (REPEAT ((N (LVAR NUM))) (TYPED DECL ((N) FIX))
      (COND
       ((OR (L? (SET 'N (- (LVAR N) 1)) 0) (CLOCK-DEMON (GVAR CLOCKER))
            (FIGHTING (GVAR FIGHT-DEMON)))
        (RETURN)))))

Someone more determined could write a small MDL->CL translator and produce a CL port of Zork (chock full of special declarations, since MDL uses dyamic scoping).

I also found the following interesting remark in the primer: "One of the implementors of Zork has been heard to say that Zork is a huge conditional".

[0] http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-29...

Pretty sure the fortran was itself a port. My apocryphal memory is that the original is for some custom system, which wikipedia tells me was "MDL". The fortran was the result of it being carried to more common systems.

Yes. The Infocom games were written in MDL, which was a LISP derivative.

And developed on a PDP-11 almost too the end of the company...

Weren't they using a 10? I don't remember but it'd at least be surprising not to while they were still at MIT.

Ah yes, my bad. And it is not even that long since i read the history on Filfre. Guess i have been reading so much about the 11 i got the two mixed...

The 11 had such a pretty instruction set, though it was kinda small for developing a program like Zork.

I think they eventually had a TOPS-20.

One of the gnarliest code bases I ever worked in was a very large C project where the inner core had been run through a f2c transpiler. Over the subsequent decade the surrounding code was a hodgepodge of people taking their own interpretations of autogenerated C code because folks didn't question why the code looked the way it did and thus they did their best to maintain the same look and feel. Oh and no one really knew how that original inner core worked, there were no docs, no oral tradition, and it was over 20 years old.

While I was still working there we accumulated enough major change requests to the application that finally got the go ahead to throw the original code base out and start from scratch.

The download links at http://gunkies.org/wiki/Zork#Source_code are all broken.

atleast this one worked: http://simh.trailing-edge.com/games/dungeon.zip (Bob's port to Fortran)

What version of c used integer and logical as type decls?

Reply on news.ycombinator.com