Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp Machine Manual (1984)

hanshuebner.github.io

Post reply on HN
Print view View original

151–160 of 165 posts

Re: Lisp Machine Manual (1984)

#151

Post by AnimalMuppet »

sedachv wrote: post #149
AnimalMuppet wrote: post #146

Earlier quoted context omitted.

> Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling. Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said. My understanding is, 1, that every newly-created cons pai…

> Which, of those statements, do you consider to be wrong, and why? Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation. I am go…

Hold on there, cowboy. You're still assuming the worst about me, with no evidence, and that gets annoying by the second or third time.

> You do not understand the difference between what the program code does and what the programming language implementation does

False.

> I am going to assume you need a stdlib.h refresher

False, and even if I did, that wasn't much of one.

> How do you think free works?

I've seen an implementation.

> How would you write a linked list implementation in C?

I've had the pleasure (?) of doing so.

On to the meat of your reply: I was not aware of any non-garbage-collected Lisps. Still, isn't it fair to say that such Lisps are by far the exception?

I was under the impression that immutable was the normal way to write Lisp. ("Normal" here not meaning "the one right way" or "the way the language tries to make you write" - Lisp doesn't do that - but more "the way the majority of people write it".)

And even if you're going to not write it that way, if you really want to avoid allocations, don't you have to also be careful what library functions you call, since many of them cons?

Re: Lisp Machine Manual (1984)

#152

Post by kazinator »

sedachv wrote: post #149
AnimalMuppet wrote: post #146

Earlier quoted context omitted.

> Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling. Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said. My understanding is, 1, that every newly-created cons pai…

> Which, of those statements, do you consider to be wrong, and why? Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation. I am go…

Hash consing will break if conses have to be mutated, or if their identity has to be attributed with data specific to the circumstances of their creation (such as attributing expressions read from files with file and line number information).

AnimalMuppet is basically right. Normal, everyday Lisp code does quite casually allocate memory: more or less of it depending on circumstances.

Implicit dynamic memory allocation occurs in places where in the analogous circumstances in C it wouldn't occur.

The abstract semantics of Lisp (such as ANSI CL) call for dynamic allocation of all lexical variable bindings, because in the abstract semantics, these have indefinite extent.

Each time a lexical scope with variables is entered, dynamic allocation takes place to create the fresh bindings, which enables continued access to these bindings after that scope's evaluation terminates.

Such allocation is only avoided as a matter of optimization: the Lisp compiler analyzes the scope to determine that no escaping closures are created in it and then the bindings can be allocated stackwise (dynamic extent) similarly to C's automatic storage.

Nothing in ANSI CL guarantees to you that (let (x)) will not allocate a piece of memory for x which endures after the form terminates, and has to be reclaimed.

Re: Lisp Machine Manual (1984)

#153

Post by fusiongyro »

PuercoPop wrote: post #150
fusiongyro wrote: post #145

Earlier quoted context omitted.

I agree, but just because I'm curious, what did Appel say? Different dialects of Lisp have had different scoping rules, but beyond that I don't know what is true or false. I believe earlier ones were dynamically scoped, because I vaguely recollect that lexical scoping was an important change in Common Lisp and Scheme. Of course Common Lisp has a special way to ask for dynamic scope.

Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC) Here is another one I found looking for the quote I was remembering. > "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haske…

Wow. Well, at one time, maybe Lisp did not have that? It certainly did by the time this book was written though.

Re: Lisp Machine Manual (1984)

#154

Post by kazinator »

fusiongyro wrote: post #153
PuercoPop wrote: post #150

Earlier quoted context omitted.

Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC) Here is another one I found looking for the quote I was remembering. > "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haske…

Wow. Well, at one time, maybe Lisp did not have that? It certainly did by the time this book was written though.

"Lisp" still hasn't; it is a family which comprises various dialects, many of which have lexical scoping, but some of which don't, like Emacs Lisp (which only had dynamic binding until recently and now supports lexical scoping, but not by default).

Re: Lisp Machine Manual (1984)

#155

Post by fusiongyro »

kazinator wrote: post #154
fusiongyro wrote: post #153

Earlier quoted context omitted.

Wow. Well, at one time, maybe Lisp did not have that? It certainly did by the time this book was written though.

"Lisp" still hasn't; it is a family which comprises various dialects, many of which have lexical scoping, but some of which don't, like Emacs Lisp (which only had dynamic binding until recently and now supports lexical scoping, but not by default).

My comment was directed at the quote about higher-order functions, which is a more legitimately surprising thing than something about scope. And of course we're talking about whatever would have been considered "Lisp" by Appel in 1992, even though you and I might know better and be more precise today.

Re: Lisp Machine Manual (1984)

#156

Post by pjmlp »

fusiongyro wrote: post #147
pjmlp wrote: post #143

Earlier quoted context omitted.

That was part of the reason, yes. On MS-DOS, Turbo Pascal and Turbo C had equal code quality and for the use cases where bound checking or integer overflow checking could be a performance issue, it was possible to disable it. In both cases you would end up using Assembly anyway, because on those days compilers were pretty bad generating code.

That erodes part of my argument. Why did C overtake Pascal? If it wasn't performance or availability, was it just preferences? Or portability from other existing codebases?

Short answer, UNIX and politics.

Long answer is a bit more complex.

UNIX was the only OS where C was relevant, and AT&T was forbidden to sell it, so they made the source code available to universities and companies for a nominal price.

That was already a big difference, instead of paying a sum of several thousands for closed source OS stuck to a specific mainframe, companies and universities could get something with source code for about $70 (if I remember correctly).

Thus UNIX eventually became the foundation of 80's startups like Sun and SGI.

Home computers firmware was basically Assembly, where C (actually K&R C dialects) was yet another language among all the available ones.

When the 16 bit revolution happened, there were several 16 bit computers systems done in a mix of Pascal and Assembly. The most notable ones Apple Lisa, Mac OS, MicroEngine and Corvus Concept.

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

https://en.wikipedia.org/wiki/Pascal_MicroEngine

https://en.wikipedia.org/wiki/Corvus_Systems

As a notable example, Photoshop started as an Object Pascal application, which was later on ported to C++.

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

So you had UNIX variants gaining a foothold on university campus and companies, with people wanting to write applications on their tiny (cheaper) computers at home, which like JavaScript and the Browser nowadays, C eventually escaped UNIX.

Apple eventually gave in to market pressure and rewrote their Object Pascal based SDK into C++ and C. And even tried their first stint at UNIX with A/UX.

http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

Corvus Systems tried to pivot their computers into Concept Unix workstation.

The Amiga OS was written in a mix of Assembly and BCPL, and eventually got its UNIX port.

https://en.wikipedia.org/wiki/Amiga_Unix

C by virtue of being UNIX's system language meant that its tooling was free with the OS, while any other programming language had to be bough separately and still you would need to write FFI to C at some level.

As side note, eventually C compilers stopped being available for free when Sun started the trend of selling the SDK, which made the largely ignored gcc to start getting contributions.

While this was happening, Brian Kernighan decided to push for C, with articles like

"Why Pascal is Not My Favorite Programming Language"

http://www.lysator.liu.se/c/bwk-on-pascal.html

Which ignored the fact that the majority of Pascal dialects had features that covered his complaints, specially the second ISO revision, Extended Pascal. And that outside of UNIX most C compilers were actually dialects, which is one of the causes for UB.

There were other bash articles flying around like "Real Programmers Don't Use PASCAL".

http://www.ee.ryerson.ca/~elf/hack/realmen.html

On the PC world, OS/2 and Windows were being written in C, but the majority of application developers were actually already jumping with C++ wit C Set++ for OS/2, OWL, VCL and MFC on Windows.

Another nascent PC OS, BeOS, was also being written in C++.

It was the rise of FOSS UNIX software, with C as its systems language, that shifted the balance towards C. To stress it again, just like JavaScript on the browser.

If you look at the history of systems programming languages, the ones that lasted longer were always the ones that were the way to write software for a specific OS.

Regarding Pascal, the majority of vendors started to consider Turbo Pascal as the pseudo-official standard, which when Borland decided to ignore small developers and focus on the enterprise, just kind of killed the Pascal market. Specially since Turbo Pascal was only focused on PC.

There is probably a bit more to rant about, but I guess you get the idea.

Re: Lisp Machine Manual (1984)

#157

Post by sedachv »

AnimalMuppet wrote: post #151
sedachv wrote: post #149

Earlier quoted context omitted.

> Which, of those statements, do you consider to be wrong, and why? Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation. I am go…

Hold on there, cowboy. You're still assuming the worst about me, with no evidence, and that gets annoying by the second or third time. > You do not understand the difference between what the program code does and what the programming language implementation does False. > I am going to assume you need a stdlib.h refresher False, and even if I did, that wasn't much of one. > How do you think free works? I've seen an im…

> Hold on there, cowboy. You're still assuming the worst about me, with no evidence, and that gets annoying by the second or third time.

The evidence is that you insist on posting a bunch of "I was under the impression" bullshit instead of spending a few minutes using a search engine. That is what is really annoying. Why do you think that your basic thesis that programs written under the assumption that there is garbage collection will not work well when there is no garbage collection is a novel or insightful contribution to the discussion about the original post?

Re: Lisp Machine Manual (1984)

#158

Post by rjsw »

lispm wrote: post #144
rjsw wrote: post #136

Earlier quoted context omitted.

Computer Architecture is not defined by what a Lisp developer normally would do. What hardware features of the CADR do you feel provide support for GC and tagged words ? I have built the CADR microcode from the same source to use both 24 and 25 bit pointers, it is just software.

Computer architecture on the user level is defined by the data format and instruction set the CPU offers. How it is implemented is another level. I don't know how some Intel i7 is implemented, but it probably has writable microcode and some very different architecture inside. That Intel hides the microcode and the CADR didn't is just another detail.

You still haven't identified what hardware features you think can be emulated in software on a CADR but couldn't be emulated in software on a 68020.

Re: Lisp Machine Manual (1984)

#159

Post by AnimalMuppet »

pjmlp wrote: post #156
fusiongyro wrote: post #147

Earlier quoted context omitted.

That erodes part of my argument. Why did C overtake Pascal? If it wasn't performance or availability, was it just preferences? Or portability from other existing codebases?

Short answer, UNIX and politics. Long answer is a bit more complex. UNIX was the only OS where C was relevant, and AT&T was forbidden to sell it, so they made the source code available to universities and companies for a nominal price. That was already a big difference, instead of paying a sum of several thousands for closed source OS stuck to a specific mainframe, companies and universities could get something with…

One nit: "Why Pascal is Not My Favorite Programming Language" explicitly states that it is not a comparison of Pascal and C. "Real Programmers Don't Use PASCAL" was not a "bash" article; it was satire. It didn't advocate use of C, even in satire - it advocated Fortran and assembler.

I think blaming either of those articles is mistaken.

Re: Lisp Machine Manual (1984)

#160

Post by pjmlp »

AnimalMuppet wrote: post #159
pjmlp wrote: post #156

Earlier quoted context omitted.

Short answer, UNIX and politics. Long answer is a bit more complex. UNIX was the only OS where C was relevant, and AT&T was forbidden to sell it, so they made the source code available to universities and companies for a nominal price. That was already a big difference, instead of paying a sum of several thousands for closed source OS stuck to a specific mainframe, companies and universities could get something with…

One nit: "Why Pascal is Not My Favorite Programming Language" explicitly states that it is not a comparison of Pascal and C. "Real Programmers Don't Use PASCAL" was not a "bash" article; it was satire. It didn't advocate use of C, even in satire - it advocated Fortran and assembler. I think blaming either of those articles is mistaken.

BBS and Usenet discussions back in the day had another point of view, even if that wasn't part of the respective author's intentions.
Post reply on HN