Questron

If I'm as busy as OP (claims to be), then no way.

EDIT: Think about marathon runners: they drink water and electrolytes. I'm pretty sure I can handle a workday fully concentrated without eating every three hours.

It's: "Look! I'm busy! I'm important! I eat special food!"

Yes, but three times in 8 hours? I think it's more of an unhealthy habit to constantly eat. That's how you get diabetes.

Weird. You need food during an eight hour shift?

You can create closures in CBM BASIC V2 by referencing arrays or creating thunks as an extension. But that's beside the original point. Implementing is not a lot of work but since my mega-deriver already solves the problem (derivation) elegantly and efficiently (most likely more efficiently than the original m68k lisp program), I really don't see any reason to use closures here. Do you?

Not really in machine language or even BASIC (see below).

Yes, pointers to pointers etc. are difficult to grasp, but then again, so is passing functions as arguments. Also, information wasn't as readily available then as it is now.

Anyways, to make a long story short, here's "mega-deriver" numerical calculus package I just whipped up in COMMODORE BASIC 2.0: http://imgur.com/94eNuSX

It should run (unmodified?) on all MS BASIC dialects of the time (including Apple II and VIC-20). Note the higher precision of floating-point numbers than the puny m86k lisp the OP linked to. This one's probably faster, too ;)

Probably hadn't thought of passing a subroutine address to a routine in z80 machine language he was familiar with?

Only the condition code was removed. Otherwise the parent is right and there really is an enormous amount of instructions. Fortunately less than intel, but still a lot.

All the different instructions are listed in intel's instruction reference manuals. What is not very wise about this article is that he's using AT&T syntax. It adds one pointless level between the actual assembly and the programmer, and it has these syntax differences compared to reference manuals, which makes it frustrating to use (both read and write).

There's also something else: Try shifting unsigned char x to right. >> 1 through 3 produce correct results, 4 changes the shift to some optimization too early, and the >> 5 the correctly optimized version. It's definitely not a very good compiler.