7 ms·

Design of Lisp-Based Processors Or, LAMBDA: The Ultimate Opcode (1979) [pdf]

87 points by bootload 12y ago

deleted 12y ago
[deleted]
melloclello 12y ago
Imagine where we'd be today if this had taken off instead of x86...
- agumonkey 12y ago
  What's done is done, but, some ideas may resurface later on (like closures did)
  - thomasvarney723 12y ago
    What do you mean?
    - yourapostasy 12y ago
      Many of the concepts that the Lisp ecosystem pioneered/popularized are, over time, migrating into the mainstream. When you stay in the industry long enough, you will indeed see that this is not unique to Lisp: everything old eventually becomes new again. This happens as what used to be constraints in the past morph into different concerns in the present.
      - agumonkey 12y ago
        This is one of my favorite topic, it's very biological, I tend to call system features "genes" now.
        DonHopkins 12y ago
        Jonathan Rees's a la carte menu of the elements of "object oriented programming" is a great example of that. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html The Elements of Object Oriented Programming: Encapsulation, Protection, Ad Hoc Polymorphism, Parametric Polymorphism, Everything Is An Object, All You Can Do Is Send A Message, Specification Inheritance, Implementation inheritance/Reuse, Sum-Of-Product-Of-Function Pattern. These are the only ones of which the news has come to Harvard, and there may be many others, but they haven't been discarvered. ;) [Apologies to Tom Lehrer.] https://www.youtube.com/watch?v=AcS3NOQnsQM https://www.youtube.com/watch?v=AcS3NOQnsQM
- _delirium 12y ago
  With modern hardware, I think it's not entirely obvious that specialized Lisp hardware would be a significant win. It's possible it would be, but not in the classic CISC-style approach of just baking important Lisp primitives into the instruction set. Without more, that would in practice just be implemented the way x86 is, translating the CISC-style instructions to RISC-style micro-ops, with no huge change to the basic CPU architecture. A more interesting question is whether significant architecture change would better suit some language paradigms. There was an interesting series of posts on possibilities in that direction at Yosef K's blog: http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/high-level-cpu-follow-up.html http://yosefk.com/blog/high-level-cpu-follow-up.html
  - DonHopkins 12y ago
    There's a lot more to making Lisp run fast than implementing parenthesis in hardware. ;)
  - sklogic 12y ago
    The modern Lisp CPU may be almost the same as the modern OoO CPUs, with only a few additional bits (which would have been useful for things like JVM as well) - a hardware read and write barrier for the hardware-assisted GC, a tagged memory, a fully controllable cache prefetch and probably an additional scratchpad memory, and a smaller dedicated GC core. I'm currently working on such a design. ISA, besides the tagged memory, barriers and prefetching, does not matter much, can be a usual RISC thing.
- hga 12y ago
  There are serious resource issues that made that unlikely: About the time Sussman and company were getting back their first silicon, Intel was shipping the 8086 and 8088, which could, for example, address a whopping megabyte of memory. Sussman and company did one or two generations of silicon, but from what I've heard the microcode one or the latter was flawed and never really worked. They simply didn't have the resources to sufficiently simulate it before committing to silicon (I'm told there was a bit of arrogance involved as well, which I believe). Intel won and continues to win in part because of success reinforcing success, keeping their eyes on the ball, and massive investments. Process (fab lines), design, simulation, support for hardware developers (said to be a critical factor in many 808x design wins over the 68000), etc. etc. etc. I've thought of paths that might have allowed custom Lisp hardware to survive, but they're in part 20/20 hindsight (people really should have believed Moore's Law, and made a minimum gates RISC chip ASAP), in part require a quality of management that none of these MIT based efforts ever had, and almost certainly in part wishful thinking (non-recurring engineering (NRE) costs were a killer, especially combined with the need to make profits vs. that keeping the ecosystem small by shipping small numbers of units). Send me back in time with a zillion dollar budget and who knows? Short of that, as agumonkey says, what's done is done. Me, I want to see tagged architectures return (to enforce dynamic typing and make math fast by tagging each word in memory; also has potential for security, and of course helping GC).
  - jacquesm 12y ago
    I think part of the reason why generalized CPUs will win over specialized ones every time is that hardware that does one thing well is invariably worse at others and we're in a 'polyglot' environment these days. So if you specialize a CPU for language 'X' it will almost automatically be worse at all the others. So the mass market will almost always favor general purpose CPUs and there may be niches where you'll find more exotic engines suited for a particular kind of computation, maybe even high level languages in hardware (greenarrays Forth offerings for instance).
    - hga 12y ago
      The key detail is economics, especially back in those days when gates were dear. One of the big things that LMI's Lambda improved on over the CADR was adding a TRW 16 bit multiply chip.... As these designs moved onto custom silicon, gates were at an extreme premium, and things like supporting the tagged architecture consumed resources that a general purpose chip could use profitably. Now I don't think that matter much at all, if your CPU is a bit bigger you sacrifice a small fraction of caching. The lowRISC project suggests NRE costs are way down (collaboration helps a lot, as well as FPGAs for prototyping) and getting significant quantities of chips on competitive processes is not insane (don't know about mask fabrication costs, but they're evidently not a showstopper). Oh, and lowRISC is looking to do two bits of tags per word, primarily for safety kludges for current not so safe languages.
- pkaye 12y ago
  Can you elaborate of what you think would have changed? You can still run LISP on x86 hardware.
  - kyllo 12y ago
    Yes, you can still run LISP on x86 hardware, but why would you ever want to run C++ on LISP hardware?
    - lispm 12y ago
      Real running Lisp Machines provided a C compiler (not C++) for example to be able to run the X11 software on them.
- kryptiskt 12y ago
  It's not like Intel wanted that crude 8080-on-steroids to be the long-term future. They could dream about higher-level hardware too: http://en.wikipedia.org/wiki/Intel_iAPX_432 http://en.wikipedia.org/wiki/Intel_iAPX_432
  - hga 12y ago
    And their RISC designs: https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 and https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 And we shouldn't forget, although many would like to, their first 64 bit processor: https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium
    - lisper 12y ago
      The i960 was a beautiful processor. Lots of general purpose registers, nice orthogonal instruction set. It's a damn shame it didn't catch on.
juliangamble 12y ago
Lisp All the Way Down! https://twitter.com/thelittlelisper/status/550987547015262209 https://twitter.com/thelittlelisper/status/55098754701526220...
- sp332 12y ago
  https://xkcd.com/224/ https://xkcd.com/224/
gavinpc 12y ago
Here is Alan Kay from a talk that was just on HN today. https://www.youtube.com/watch?v=ubaX1Smg6pY&t=8m9s https://www.youtube.com/watch?v=ubaX1Smg6pY&t=8m9s The amount of complication can be hundreds of times more than the complexity, maybe thousands of times more. This is why appealing to personal computing is, I think, a good ploy in a talk like this because surely we don't think there's 120 million lines of code—of *content* in Microsoft's Windows — surely not — or in Microsoft Office. It's just incomprehensible. And just speaking from the perspective of Xerox Parc where we had to do this the first time with a much smaller group — and, it's true there's more stuff today — but back then, we were able to do the operating system, the programming language, the application, and the user interface in about ten thousand lines of code. Now, it's true that we were able to build our own computers. That makes a huge difference, because we didn't have to do the kind of optimization that people do today because we've got things back-asswards today. We let Intel make processors that may or may not be good for anything, and then the programmer's job is to make Intel look good by making code that will actually somehow run on it. And if you think about that, it couldn't be stupider. It's completely backwards. What you really want to do is to define your software system *first* — define it in the way that makes it the most runnable, most comprehensible — and then you want be able to build whatever hardware is needed, and build it in a timely fashion to run that software. And of course that's possible today with FPGA's; it was possible in the 70's at Xerox Parc with microcode. The problem in between is, when we were doing this stuff at Parc, we went to Intel and Motorola and pleading with them to put forms of microcode into the chips to allow customization and function for the different kinds of languages that were going to have to run on the chips, and they said, What do you mean? What are you talking about? Because it never occurred to them. It still hasn't. EDIT added last para.
DonHopkins 12y ago
I believe this is about the Lisp Microprocessor that Guy Steele created in Lynn Conway's groundbreaking 1978 MIT VLSI System Design Course: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.html http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.html My friend David Levitt is crouching down in this class photo so his big 1978 hair doesn't block Guy Steele's face: The class photo is in two parts, left and right: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class2s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class2s.jp... http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class3s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class3s.jp... Here are hires images of the two halves of the chip the class made: http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78chip%20photo-1%20L.jpg http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c... http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78chip%20photo-2%20L.jpg http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c... The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in. David's project is in the lower right corner of the first image, and you can see his name "LEVITT" if you zoom way in. Here is a photo of a chalkboard with status of the various projects: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Status%20Em.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Status%20E... The final sanity check before maskmaking: A wall-sized overall check plot made at Xerox PARC from Arpanet-transmitted design files, showing the student design projects merged into multiproject chip set. http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Checkplot%20s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Checkplot%... One of the wafers just off the HP fab line containing the MIT'78 VLSI design projects: Wafers were then diced into chips, and the chips packaged and wire bonded to specific projects, which were then tested back at M.I.T. http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Wafer%20s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Wafer%20s.... Design of a LISP-based microprocessor http://dl.acm.org/citation.cfm?id=359031 http://dl.acm.org/citation.cfm?id=359031 ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf Page 22 has a map of the processor layout: http://i.imgur.com/zwaJMQC.jpg http://i.imgur.com/zwaJMQC.jpg We present a design for a class of computers whose “instruction sets” are based on LISP. LISP, like traditional stored-program machine languages and unlike most high-level languages, conceptually stores programs and data in the same way and explicitly allows programs to be manipulated as data, and so is a suitable basis for a stored-program computer architecture. LISP differs from traditional machine languages in that the program/data storage is conceptually an unordered set of linked record structures of various sizes, rather than an ordered, indexable vector of integers or bit fields of fixed size. An instruction set can be designed for programs expressed as trees of record structures. A processor can interpret these program trees in a recursive fashion and provide automatic storage management for the record structures. We discuss a small-scale prototype VLSI microprocessor which has been designed and fabricated, containing a sufficiently complete instruction interpreter to execute small programs and a rudimentary storage allocator.
SrslyJosh 12y ago
Server seems a bit slow. Here's a Coral cache link: http://dspace.mit.edu.nyud.net/bitstream/handle/1721.1/5731/AIM-514.pdf http://dspace.mit.edu.nyud.net/bitstream/handle/1721.1/5731/... (Pretend you're on slashdot 10 years ago.)
typedef_struct 12y ago
Thanks for this--now I know where http://lambda-the-ultimate.org/ http://lambda-the-ultimate.org/ got its name
- hga 12y ago
  Indeed. This was one of the last in a series of papers by Steele or both: http://library.readscheme.org/page1.html http://library.readscheme.org/page1.html There's quite a bit of enlightenment to be found in them.

87 points by bootload 12y ago

deleted 12y ago

[deleted]

melloclello 12y ago

Imagine where we'd be today if this had taken off instead of x86...

agumonkey 12y ago
What's done is done, but, some ideas may resurface later on (like closures did)
- thomasvarney723 12y ago
  What do you mean?
  - yourapostasy 12y ago
    Many of the concepts that the Lisp ecosystem pioneered/popularized are, over time, migrating into the mainstream. When you stay in the industry long enough, you will indeed see that this is not unique to Lisp: everything old eventually becomes new again. This happens as what used to be constraints in the past morph into different concerns in the present.
    - agumonkey 12y ago
      This is one of my favorite topic, it's very biological, I tend to call system features "genes" now.
      - DonHopkins 12y ago
        Jonathan Rees's a la carte menu of the elements of "object oriented programming" is a great example of that. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html The Elements of Object Oriented Programming: Encapsulation, Protection, Ad Hoc Polymorphism, Parametric Polymorphism, Everything Is An Object, All You Can Do Is Send A Message, Specification Inheritance, Implementation inheritance/Reuse, Sum-Of-Product-Of-Function Pattern. These are the only ones of which the news has come to Harvard, and there may be many others, but they haven't been discarvered. ;) [Apologies to Tom Lehrer.] https://www.youtube.com/watch?v=AcS3NOQnsQM https://www.youtube.com/watch?v=AcS3NOQnsQM
_delirium 12y ago
With modern hardware, I think it's not entirely obvious that specialized Lisp hardware would be a significant win. It's possible it would be, but not in the classic CISC-style approach of just baking important Lisp primitives into the instruction set. Without more, that would in practice just be implemented the way x86 is, translating the CISC-style instructions to RISC-style micro-ops, with no huge change to the basic CPU architecture. A more interesting question is whether significant architecture change would better suit some language paradigms. There was an interesting series of posts on possibilities in that direction at Yosef K's blog: http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/high-level-cpu-follow-up.html http://yosefk.com/blog/high-level-cpu-follow-up.html
- DonHopkins 12y ago
  There's a lot more to making Lisp run fast than implementing parenthesis in hardware. ;)
- sklogic 12y ago
  The modern Lisp CPU may be almost the same as the modern OoO CPUs, with only a few additional bits (which would have been useful for things like JVM as well) - a hardware read and write barrier for the hardware-assisted GC, a tagged memory, a fully controllable cache prefetch and probably an additional scratchpad memory, and a smaller dedicated GC core. I'm currently working on such a design. ISA, besides the tagged memory, barriers and prefetching, does not matter much, can be a usual RISC thing.
hga 12y ago
There are serious resource issues that made that unlikely: About the time Sussman and company were getting back their first silicon, Intel was shipping the 8086 and 8088, which could, for example, address a whopping megabyte of memory. Sussman and company did one or two generations of silicon, but from what I've heard the microcode one or the latter was flawed and never really worked. They simply didn't have the resources to sufficiently simulate it before committing to silicon (I'm told there was a bit of arrogance involved as well, which I believe). Intel won and continues to win in part because of success reinforcing success, keeping their eyes on the ball, and massive investments. Process (fab lines), design, simulation, support for hardware developers (said to be a critical factor in many 808x design wins over the 68000), etc. etc. etc. I've thought of paths that might have allowed custom Lisp hardware to survive, but they're in part 20/20 hindsight (people really should have believed Moore's Law, and made a minimum gates RISC chip ASAP), in part require a quality of management that none of these MIT based efforts ever had, and almost certainly in part wishful thinking (non-recurring engineering (NRE) costs were a killer, especially combined with the need to make profits vs. that keeping the ecosystem small by shipping small numbers of units). Send me back in time with a zillion dollar budget and who knows? Short of that, as agumonkey says, what's done is done. Me, I want to see tagged architectures return (to enforce dynamic typing and make math fast by tagging each word in memory; also has potential for security, and of course helping GC).
- jacquesm 12y ago
  I think part of the reason why generalized CPUs will win over specialized ones every time is that hardware that does one thing well is invariably worse at others and we're in a 'polyglot' environment these days. So if you specialize a CPU for language 'X' it will almost automatically be worse at all the others. So the mass market will almost always favor general purpose CPUs and there may be niches where you'll find more exotic engines suited for a particular kind of computation, maybe even high level languages in hardware (greenarrays Forth offerings for instance).
  - hga 12y ago
    The key detail is economics, especially back in those days when gates were dear. One of the big things that LMI's Lambda improved on over the CADR was adding a TRW 16 bit multiply chip.... As these designs moved onto custom silicon, gates were at an extreme premium, and things like supporting the tagged architecture consumed resources that a general purpose chip could use profitably. Now I don't think that matter much at all, if your CPU is a bit bigger you sacrifice a small fraction of caching. The lowRISC project suggests NRE costs are way down (collaboration helps a lot, as well as FPGAs for prototyping) and getting significant quantities of chips on competitive processes is not insane (don't know about mask fabrication costs, but they're evidently not a showstopper). Oh, and lowRISC is looking to do two bits of tags per word, primarily for safety kludges for current not so safe languages.
pkaye 12y ago
Can you elaborate of what you think would have changed? You can still run LISP on x86 hardware.
- kyllo 12y ago
  Yes, you can still run LISP on x86 hardware, but why would you ever want to run C++ on LISP hardware?
  - lispm 12y ago
    Real running Lisp Machines provided a C compiler (not C++) for example to be able to run the X11 software on them.
kryptiskt 12y ago
It's not like Intel wanted that crude 8080-on-steroids to be the long-term future. They could dream about higher-level hardware too: http://en.wikipedia.org/wiki/Intel_iAPX_432 http://en.wikipedia.org/wiki/Intel_iAPX_432
- hga 12y ago
  And their RISC designs: https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 and https://en.wikipedia.org/wiki/Intel_i860 https://en.wikipedia.org/wiki/Intel_i860 And we shouldn't forget, although many would like to, their first 64 bit processor: https://en.wikipedia.org/wiki/Itanium https://en.wikipedia.org/wiki/Itanium
  - lisper 12y ago
    The i960 was a beautiful processor. Lots of general purpose registers, nice orthogonal instruction set. It's a damn shame it didn't catch on.

juliangamble 12y ago

Lisp All the Way Down! https://twitter.com/thelittlelisper/status/550987547015262209 https://twitter.com/thelittlelisper/status/55098754701526220...

sp332 12y ago
https://xkcd.com/224/ https://xkcd.com/224/

gavinpc 12y ago

Here is Alan Kay from a talk that was just on HN today. https://www.youtube.com/watch?v=ubaX1Smg6pY&t=8m9s https://www.youtube.com/watch?v=ubaX1Smg6pY&t=8m9s The amount of complication can be hundreds of times more than the complexity, maybe thousands of times more. This is why appealing to personal computing is, I think, a good ploy in a talk like this because surely we don't think there's 120 million lines of code—of *content* in Microsoft's Windows — surely not — or in Microsoft Office. It's just incomprehensible. And just speaking from the perspective of Xerox Parc where we had to do this the first time with a much smaller group — and, it's true there's more stuff today — but back then, we were able to do the operating system, the programming language, the application, and the user interface in about ten thousand lines of code. Now, it's true that we were able to build our own computers. That makes a huge difference, because we didn't have to do the kind of optimization that people do today because we've got things back-asswards today. We let Intel make processors that may or may not be good for anything, and then the programmer's job is to make Intel look good by making code that will actually somehow run on it. And if you think about that, it couldn't be stupider. It's completely backwards. What you really want to do is to define your software system *first* — define it in the way that makes it the most runnable, most comprehensible — and then you want be able to build whatever hardware is needed, and build it in a timely fashion to run that software. And of course that's possible today with FPGA's; it was possible in the 70's at Xerox Parc with microcode. The problem in between is, when we were doing this stuff at Parc, we went to Intel and Motorola and pleading with them to put forms of microcode into the chips to allow customization and function for the different kinds of languages that were going to have to run on the chips, and they said, What do you mean? What are you talking about? Because it never occurred to them. It still hasn't. EDIT added last para.

DonHopkins 12y ago

I believe this is about the Lisp Microprocessor that Guy Steele created in Lynn Conway's groundbreaking 1978 MIT VLSI System Design Course: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.html http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/MIT78.html My friend David Levitt is crouching down in this class photo so his big 1978 hair doesn't block Guy Steele's face: The class photo is in two parts, left and right: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class2s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class2s.jp... http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class3s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Class3s.jp... Here are hires images of the two halves of the chip the class made: http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78chip%20photo-1%20L.jpg http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c... http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78chip%20photo-2%20L.jpg http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c... The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in. David's project is in the lower right corner of the first image, and you can see his name "LEVITT" if you zoom way in. Here is a photo of a chalkboard with status of the various projects: http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Status%20Em.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Status%20E... The final sanity check before maskmaking: A wall-sized overall check plot made at Xerox PARC from Arpanet-transmitted design files, showing the student design projects merged into multiproject chip set. http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Checkplot%20s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Checkplot%... One of the wafers just off the HP fab line containing the MIT'78 VLSI design projects: Wafers were then diced into chips, and the chips packaged and wire bonded to specific projects, which were then tested back at M.I.T. http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Wafer%20s.jpg http://ai.eecs.umich.edu/people/conway/VLSI/MIT78/Wafer%20s.... Design of a LISP-based microprocessor http://dl.acm.org/citation.cfm?id=359031 http://dl.acm.org/citation.cfm?id=359031 ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-514.pdf Page 22 has a map of the processor layout: http://i.imgur.com/zwaJMQC.jpg http://i.imgur.com/zwaJMQC.jpg We present a design for a class of computers whose “instruction sets” are based on LISP. LISP, like traditional stored-program machine languages and unlike most high-level languages, conceptually stores programs and data in the same way and explicitly allows programs to be manipulated as data, and so is a suitable basis for a stored-program computer architecture. LISP differs from traditional machine languages in that the program/data storage is conceptually an unordered set of linked record structures of various sizes, rather than an ordered, indexable vector of integers or bit fields of fixed size. An instruction set can be designed for programs expressed as trees of record structures. A processor can interpret these program trees in a recursive fashion and provide automatic storage management for the record structures. We discuss a small-scale prototype VLSI microprocessor which has been designed and fabricated, containing a sufficiently complete instruction interpreter to execute small programs and a rudimentary storage allocator.

SrslyJosh 12y ago

Server seems a bit slow. Here's a Coral cache link: http://dspace.mit.edu.nyud.net/bitstream/handle/1721.1/5731/AIM-514.pdf http://dspace.mit.edu.nyud.net/bitstream/handle/1721.1/5731/... (Pretend you're on slashdot 10 years ago.)

typedef_struct 12y ago

Thanks for this--now I know where http://lambda-the-ultimate.org/ http://lambda-the-ultimate.org/ got its name

hga 12y ago
Indeed. This was one of the last in a series of papers by Steele or both: http://library.readscheme.org/page1.html http://library.readscheme.org/page1.html There's quite a bit of enlightenment to be found in them.