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

They Called It LISP for a Reason: List Processing (2005)

gigamonkeys.com

Post reply on HN
Print view View original

51–60 of 125 posts

Re: They Called It LISP for a Reason: List Processing (2005)

#51

Post by dkarl »

dragontamer wrote: post #36

The real elegance of Lisp is that malloc() has been renamed to (cons) and everyone feels smarter about it. I jest a little bit, but that's really the fundamental thing about list-processing. For most code, you don't really care about runtime, and you really just need "a data structure that probably can solve the problem", and the (cons) based list of car and cdr solves it. List processing itself is an elegant techniq…

I think building everything out of conses held Lisp back. It was possible, and it was deemed to be elegant, so people went too far with it. YMMV since my adventures with Lisp were around twenty years ago, but reading code, you'd see somebody constructing a list with a bunch of nested lists inside it, or some other complicated structure with conses, and you'd have no idea what it was or how they intended to use it, and you'd just have to read the code until you figured it out. It's much easier to read code that uses named data structures.

Of course in Lisp your code can and should have clearly named functions that encapsulate your use of conses to build data structures, but casually violating that encapsulation, or better yet doing without encapsulation at all, just playing with conses, was the cool way to do it, the way you programmed if you had even a little bit of swagger. That was fun as long as feeling smart about the fact that I could do it outweighed feeling annoyed at everyone else doing it, but in the end, the feeling of smartness faded and the feeling of annoyance remained.

Re: They Called It LISP for a Reason: List Processing (2005)

#52

Post by pyinstallwoes »

terminalcommand wrote: post #48
pyinstallwoes wrote: post #46

Earlier quoted context omitted.

Forth solves this.

Forth is still interpreted. Forth's genius is that it's interpreter is so tiny that it fits as a runtime.

This is wrong.

Because of the way pointers are used, Forth is both compiled and not compiled.

> After the fetch and store operations are redefined for the code space, the compiler, assembler, etc. are recompiled using the new definitions of fetch and store. This effectively reuses all the code of the compiler and interpreter. Then, the Forth system's code is compiled, but this version is stored in the buffer. The buffer in memory is written to disk, and ways are provided to load it temporarily into memory for testing. When the new version appears to work, it is written over the previous version.

Re: They Called It LISP for a Reason: List Processing (2005)

#53

Post by terminalcommand »

pyinstallwoes wrote: post #52
terminalcommand wrote: post #48

Earlier quoted context omitted.

Forth is still interpreted. Forth's genius is that it's interpreter is so tiny that it fits as a runtime.

This is wrong. Because of the way pointers are used, Forth is both compiled and not compiled. > After the fetch and store operations are redefined for the code space, the compiler, assembler, etc. are recompiled using the new definitions of fetch and store. This effectively reuses all the code of the compiler and interpreter. Then, the Forth system's code is compiled, but this version is stored in the buffer. The buf…

What is the difference between a runtime and an interpreter? I still believe forth is interpreted. Forth uses a small set of functions in assembly as its runtime/interpeter.

Your quote looks like its about bootstrapping the Forth ecosystem. After writing fetch and store operations in native assembly, you can bootstrap the forth system that is logical. This is the way Chuck Moore first used Forth anyways. He had no interpreter/compiler back than, he wrote some functions to aid him circumvent assembly and make his code portable. It is genius, but I think it's still interpreted.

You can compile python to bytecode and run it in python's vm, does this mean your python code is compiled. IMHO no, it is compiled for the python vm and python vm interprets it. Same thing applies to Forth.

Forth is interpreted, even if you compile and package it in a standalone executable binary.

Re: They Called It LISP for a Reason: List Processing (2005)

#54

Post by math-dev »

sillysaurusx wrote: post #23
User23 wrote: post #20

Earlier quoted context omitted.

> Yes, but cdr(vector(1, 2, 3)) throws an error in almost all lisp implementations. Which means you can’t use the classic algorithms on them, like map. What? MAP[1] works just fine with vectors and other sequence types. Are you somehow surprised that MAPCAR doesn't? The name makes it pretty obvious I'd think. I'm starting to think you just lack familiarity with the language that you're criticizing. [1] http://clhs.li…

Suppose Lisp were forced to abandon cons cells and could only use vectors to represent code. What's the disadvantage? My retort to you would be "I'm starting to think you like complexity for the sake of it," but debates are much more fun when we're both genuinely interested in the other's perspective.

cons is a recursive data structure. it’s not discussed much here in the comments, but a lot of its useability comes from that fact - you can write elegant recursive algorithms with cons as your data structure

with vectors that doesn’t work UNLESS you add a bit of overhead (which most optimising programs may do since for many cases vectors can be more performant)

Re: They Called It LISP for a Reason: List Processing (2005)

#55

Post by terminalcommand »

dragontamer wrote: post #50
terminalcommand wrote: post #48

Earlier quoted context omitted.

Forth is still interpreted. Forth's genius is that it's interpreter is so tiny that it fits as a runtime.

There are many lisps that are not interpreted, but are instead compiled. The beauty of the lisp language is that it doesn't care about interpreted vs compiled vs whatever. Its just the true elegance of "everything is a (lisp) list" (which is probably the wrong word. The truth of the matter is that "everything is a graph" and lisp-lists are really just a universal building block that can represent arbitrary graphs). T…

That is true, but some sort of a runtime bordering on being an interpreter needs to exist doesn't it. Because my brain cannot comprehend how you can do metaprogramming with macros etc. with static code.

My opinion was that the compiled lisps precompile as much as possible (calculations etc.) into assembly and leave bits they can't compile intact, that's what make them fast.

Re: They Called It LISP for a Reason: List Processing (2005)

#56

Post by Jtsummers »

terminalcommand wrote: post #53
pyinstallwoes wrote: post #52

Earlier quoted context omitted.

This is wrong. Because of the way pointers are used, Forth is both compiled and not compiled. > After the fetch and store operations are redefined for the code space, the compiler, assembler, etc. are recompiled using the new definitions of fetch and store. This effectively reuses all the code of the compiler and interpreter. Then, the Forth system's code is compiled, but this version is stored in the buffer. The buf…

What is the difference between a runtime and an interpreter? I still believe forth is interpreted. Forth uses a small set of functions in assembly as its runtime/interpeter. Your quote looks like its about bootstrapping the Forth ecosystem. After writing fetch and store operations in native assembly, you can bootstrap the forth system that is logical. This is the way Chuck Moore first used Forth anyways. He had no in…

An interpreter interprets, typically either a byte code or textual representation version of a program or some other intermediate form (for instance, parsing to an AST and then evaluating/interpreting that versus line-by-line or token-by-token). A runtime could include an interpreter, but doesn't have to. Go includes its own runtime which handles things like scheduling goroutines and garbage collection, but it is not interpreted nor does it include an interpreter.

Re: They Called It LISP for a Reason: List Processing (2005)

#57

Post by abecedarius »

eduction wrote: post #41

>lists are an excellent data structure for representing any kind of heterogeneous and/or hierarchical data I found this a really curious statement. Linked lists made sense given the limitations in compute when LISP was invented (~1958) but how are vectors not a superior solution in every way, when available? Vectors give you fast random access and fast append plus the same first/next semantics and performance as list…

> fast append

If you're mutating it, yes. And CL/Scheme do offer that datatype.

Linked lists support a functional style building shared structures without having to worry about plan interference from the mutations. Clojure can do this with immutable arrays instead of lists, but the implementation is hairier than either linked lists or mutable arrays.

Re: They Called It LISP for a Reason: List Processing (2005)

#58

Post by terminalcommand »

Jtsummers wrote: post #56
terminalcommand wrote: post #53

Earlier quoted context omitted.

What is the difference between a runtime and an interpreter? I still believe forth is interpreted. Forth uses a small set of functions in assembly as its runtime/interpeter. Your quote looks like its about bootstrapping the Forth ecosystem. After writing fetch and store operations in native assembly, you can bootstrap the forth system that is logical. This is the way Chuck Moore first used Forth anyways. He had no in…

An interpreter interprets, typically either a byte code or textual representation version of a program or some other intermediate form (for instance, parsing to an AST and then evaluating/interpreting that versus line-by-line or token-by-token). A runtime could include an interpreter, but doesn't have to. Go includes its own runtime which handles things like scheduling goroutines and garbage collection, but it is not…

This is exactly what I'm talking about. Go is a statically typed C-like compiled language. It can convert the code much or less in its entirety to machine code. Lisp and forth on the other hand cannot, I think. They need some kind of interpretation at runtime to function so dynamically. If this is not the case, please prove me wrong. The distinction between compile time vs run time bugs me a lot.

I think it is easier to say forth is closer to compiled. I can kind of imagine each user defined word being translated into assembly. With lisp I am speechles.

Re: They Called It LISP for a Reason: List Processing (2005)

#59

Post by openfuture »

eduction wrote: post #41

>lists are an excellent data structure for representing any kind of heterogeneous and/or hierarchical data I found this a really curious statement. Linked lists made sense given the limitations in compute when LISP was invented (~1958) but how are vectors not a superior solution in every way, when available? Vectors give you fast random access and fast append plus the same first/next semantics and performance as list…

Just use canonical S-expressions, then you've got linked lists where the atoms are vectors, best of both worlds :)

Re: They Called It LISP for a Reason: List Processing (2005)

#60

Post by openfuture »

dragontamer wrote: post #47
eduction wrote: post #41

>lists are an excellent data structure for representing any kind of heterogeneous and/or hierarchical data I found this a really curious statement. Linked lists made sense given the limitations in compute when LISP was invented (~1958) but how are vectors not a superior solution in every way, when available? Vectors give you fast random access and fast append plus the same first/next semantics and performance as list…

Lisp lists aren't linked lists. Pointers to TWO pointers (first pointer is named car, and the 2nd pointer is named cdr). The realization that (cons) / Lisp-lists / car-and-cdr give is that you can represent arbitrary graphs (!!!) with car / cdr / cons, leading to a truly universal data-structure. Not necessarily an _efficient_ datastructure mind you, but a universal one. ------ So really, Lisp-lists are just the "try…

Universal in the sense of structure, but vectors are pretty faithful to the machine memory.. which also makes them universal but more in terms of content. Therefore we should use canonical S-expressions as a universal data interchange format. When you build metaprogramming on top of it then you can do some cool things I think (check out datalisp.is).
Post reply on HN