4 ms·

It happened (for a while) with Dylan on early, unshipped versions of the Apple Newton. Dylan was an object-oriented variant of Scheme, and there was an OS that

by kabdib 9y ago

It happened (for a while) with Dylan on early, unshipped versions of the Apple Newton. Dylan was an object-oriented variant of Scheme, and there was an OS that was implemented nearly all the way to the metal in it. At least that's what I heard; I was working on the C++ based Newton OS, and sat next to the Dylan guys for a while, until they were told to stop work on their stuff. So I could have the level of "metalness" wrong.

pvg 9y ago
The Newton didn't have hardware designed to facilitate running Dylan, though, so it seems a somewhat lesser level of metalness.
- kabdib 9y ago
  The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put there specifically to improve the garbage collection behavior of the system. (The sub-page protections allowed better than 4K granularity of physical page sharing, which helped a lot, since RAM on the newt was always precious). The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.
  - mikelevins 9y ago
    I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.
  - pvg 9y ago
    Yes perhaps I should have said something stronger than merely 'facilitate' but 'MMU parameters were better for GC' is a long way from the Lisp machine hardware/software mindmeld. It's still, as far as I can tell, pretty much just a MMU, right?
    - lispm 9y ago
      I think the main point was to have a more interactivity friendly GC than otherwise possible. Having the user notice GC pauses on an interactive computer - a tablet - would have been a problem. MCL provided an ephemeral GC using the MMU of the 68020 (external) or 68030/40 (integrated). It dealt with short-lived objects in main memory, avoiding virtual memory activity. A similar level of responsiveness probably was the goal.
    - kabdib 9y ago
      On the other hand, the newt (Senior, anyway) was running Dylan on bare metal; you don't need to have fancy-pants LISP-accelerating hardware to do that. You just need to have the intestinal fortitude to write an OS and runtime in something not C :-)
dreamcompiler 9y ago
> Dylan was an object-oriented variant of Scheme Not really. Dylan was a stripped-down version of Common Lisp (which has an object system built in) with some of the fringier bits (like :before, :after, and :around methods) and the parentheses stripped off.
- mikelevins 9y ago
  Nah, it was Scheme plus (a stripped-down) CLOS. A possible point of confusion was that the development environment, including the CPS Scheme compoiler, was written in Common Lisp. Also, all values were instances of (mini-CLOS) classes.
  - dreamcompiler 9y ago
    Wow. Did it have call/cc? No special variables? I would have sworn it was based on CL when I played with it back when I was a customer while you guys were building it in MCL. But I was mostly using the object system.
    - mikelevins 9y ago
      The Dylan team consciously chose not to provide call/cc. It had a restricted form of call/cc called "bind-exit" that supported only upward continuations. It didn't have special variables, but it did have module variables, which were lexically accessible from anywhere inside the module where they were defined, or in any module that imported them. THey were more like entries in Smalltalk dictionaries than special variables (a possibly-overlooked point is that the initial design discussions at Apple included several Smalltalk enthusiasts from ATG). The object system would definitely have looked like Common Lisp. It was CLOS minus some of the bells and whistles, as you observed. Also, like Scheme and unlike Common Lisp, Dylan was a Lisp-1, not a Lisp-2. For those unfamiliar with that jargon, it refers to how namespaces are organized in Lisps. In Dylan, as in Scheme, there was a single namespace for variables, functions, types, and so on. For example, <collection> was the abstract superclass of all collections, but the name "<collection>" was just a read-only module variable that happened to refer to the (anonymous) class. By contrast, in Common Lisp there are separate namespaces for variables, functions, classes, and some other things. Thus, in Common Lisp (but not in a Lisp-1), you can have a function named "address", a class named "address", and a lexical variable named "address", and they don't collide or shadow one another.

by kabdib 9y ago

pvg 9y ago

The Newton didn't have hardware designed to facilitate running Dylan, though, so it seems a somewhat lesser level of metalness.

kabdib 9y ago
The MMU on the ARM 610 had features intended for Dylan, that were designed by one of my ex-cow-orkers; the sub-page protection system (1K granularity) was put there specifically to improve the garbage collection behavior of the system. (The sub-page protections allowed better than 4K granularity of physical page sharing, which helped a lot, since RAM on the newt was always precious). The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.
- mikelevins 9y ago
  I worked on bauhaus, the second Dylan-based Newton OS--that is, the one developed in parallel with the C++/Newtonscript one. It used the C++ microkernel and it used the 7 low-level bottleneck functions from C QuickDraw. Everything else was written in Dylan. I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype. It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features. So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.
- pvg 9y ago
  Yes perhaps I should have said something stronger than merely 'facilitate' but 'MMU parameters were better for GC' is a long way from the Lisp machine hardware/software mindmeld. It's still, as far as I can tell, pretty much just a MMU, right?
  - lispm 9y ago
    I think the main point was to have a more interactivity friendly GC than otherwise possible. Having the user notice GC pauses on an interactive computer - a tablet - would have been a problem. MCL provided an ephemeral GC using the MMU of the 68020 (external) or 68030/40 (integrated). It dealt with short-lived objects in main memory, avoiding virtual memory activity. A similar level of responsiveness probably was the goal.
  - kabdib 9y ago
    On the other hand, the newt (Senior, anyway) was running Dylan on bare metal; you don't need to have fancy-pants LISP-accelerating hardware to do that. You just need to have the intestinal fortitude to write an OS and runtime in something not C :-)

dreamcompiler 9y ago

> Dylan was an object-oriented variant of Scheme Not really. Dylan was a stripped-down version of Common Lisp (which has an object system built in) with some of the fringier bits (like :before, :after, and :around methods) and the parentheses stripped off.

mikelevins 9y ago
Nah, it was Scheme plus (a stripped-down) CLOS. A possible point of confusion was that the development environment, including the CPS Scheme compoiler, was written in Common Lisp. Also, all values were instances of (mini-CLOS) classes.
- dreamcompiler 9y ago
  Wow. Did it have call/cc? No special variables? I would have sworn it was based on CL when I played with it back when I was a customer while you guys were building it in MCL. But I was mostly using the object system.
  - mikelevins 9y ago
    The Dylan team consciously chose not to provide call/cc. It had a restricted form of call/cc called "bind-exit" that supported only upward continuations. It didn't have special variables, but it did have module variables, which were lexically accessible from anywhere inside the module where they were defined, or in any module that imported them. THey were more like entries in Smalltalk dictionaries than special variables (a possibly-overlooked point is that the initial design discussions at Apple included several Smalltalk enthusiasts from ATG). The object system would definitely have looked like Common Lisp. It was CLOS minus some of the bells and whistles, as you observed. Also, like Scheme and unlike Common Lisp, Dylan was a Lisp-1, not a Lisp-2. For those unfamiliar with that jargon, it refers to how namespaces are organized in Lisps. In Dylan, as in Scheme, there was a single namespace for variables, functions, types, and so on. For example, <collection> was the abstract superclass of all collections, but the name "<collection>" was just a read-only module variable that happened to refer to the (anonymous) class. By contrast, in Common Lisp there are separate namespaces for variables, functions, classes, and some other things. Thus, in Common Lisp (but not in a Lisp-1), you can have a function named "address", a class named "address", and a lexical variable named "address", and they don't collide or shadow one another.