Live data from Hacker News

In Lisp, should lists be replaced with trees?

hxa.name

11–20 of 43 posts

Re: In Lisp, should lists be replaced with trees?

#11
It's easy to implement both lists and name-value associations in terms of pairs, so I'm not sure why they need to be built in.

In Fexl (http://fexl.com/code), the only built in concept is the function, and all data is structured out of functions. I won't go into all the details here, but concepts like pair, list, key-value assoc, branch, and everything else are readily expressed as pure functions. So-called "circular" structures are created with the Y combinator, so they really are not circular in memory, only in concept.

Re: In Lisp, should lists be replaced with trees?

#13

"Branchs/trees are a superset of pairs/lists" No, they aren't. A tree is acyclic by definition. Cons cells allow circular structures.

To take a familiar example, the Web is not a tree. While you might argue that each page has unique children (outlinks), there is no unique parent -- a page can have an arbitrarily large number of incoming links, and the page can link back to those pages in turn, producing cyclic structures of immense complexity. For some interesting discussion on the limits of tree structures with respect to urban planning see A City…

All good, just a nitpick: You don't need a unique parent to have a tree. You don't even need directed edges. :)

The purest definition of a tree graph is "a graph with no cycles".

Re: In Lisp, should lists be replaced with trees?

#14
post #11

It's easy to implement both lists and name-value associations in terms of pairs, so I'm not sure why they need to be built in. In Fexl ( http://fexl.com/code ), the only built in concept is the function , and all data is structured out of functions. I won't go into all the details here, but concepts like pair, list, key-value assoc, branch, and everything else are readily expressed as pure functions. So-called "circu…

There's an interesting write up about the idea of "everything is a function" in Haskell at http://conal.net/blog/posts/everything-is-a-function-in-hask....

What's your rationale vbehind everything being a function?

Re: In Lisp, should lists be replaced with trees?

#15
post #4

He seems to have heard of Lua but that didn't stop him from raising the question. Next article: " Should airplanes be fitted with big rotor on top to allow for vertical take off and hovering? .. like helicopters? "

not that jets need a big rotor on top to do vertical takeoff and hovering

http://en.wikipedia.org/wiki/Harrier_Jump_Jet :)

Re: In Lisp, should lists be replaced with trees?

#16

"Branchs/trees are a superset of pairs/lists" No, they aren't. A tree is acyclic by definition. Cons cells allow circular structures.

The structures described are called trees in the post, but are actually just sets of named objects, which can be used to describe cyclic structures in the same way conses can.

Re: In Lisp, should lists be replaced with trees?

#18
post #11

It's easy to implement both lists and name-value associations in terms of pairs, so I'm not sure why they need to be built in. In Fexl ( http://fexl.com/code ), the only built in concept is the function , and all data is structured out of functions. I won't go into all the details here, but concepts like pair, list, key-value assoc, branch, and everything else are readily expressed as pure functions. So-called "circu…

There's an interesting write up about the idea of "everything is a function" in Haskell at http://conal.net/blog/posts/everything-is-a-function-in-hask... . What's your rationale vbehind everything being a function?

The seed was planted back in 1989 when I read a paper by Jørgen Steensgaard-Madsen in Communications of the ACM titled "Typed Representation of Objects by Functions" (CACM, January 1989, Volume 11 Number 1). I found it brilliant and I never could shake the idea after that.

Even something as lowly as a bit (Boolean value true or false) can be represented as a function. In Fexl, the functions for T and F are expressed as:

  \T = (\T\F T)
  \F = (\T\F F)
In short, the T function returns its first argument, and the F function returns its second argument. So you can do things like this:

  eq x 4 (print "Yes, it's 4") (print "No, it's not 4")
You don't even need an "if" function. Or, if you like the way "if" looks, you can define it as the identity function:

  \if = (\x x)
Then you can say:

   if (eq x 4) (print "Yes, it's 4") (print "No, it's not 4")
You can also define "lists" as functions. There are two cases, "null" and "cons":

  \null = (           \null\cons null)
  \cons = (\head\tail \null\cons cons head tail)
Now if you have a list called "groceries", you can do this:

  groceries
    (print "You don't need anything at the moment")
    \head\tail
      print "You need "; print head;
      print "and possibly some other things."
If you aren't comfortable "calling" a list object as a function, you can define the more familiar "observer" functions:

  \empty = (\list list T \_\_ F)
  \head = (\list list undef \head\_ head)
  \tail = (\list list undef \_\tail tail)
Then you could say:

  if (empty groceries)
    (print "You don't need anything at the moment")
    (print "You need "; print (head groceries);
      print " and possibly some other things.")
If you want an ordered pair, here you go:

  \pair = (\x\y \pair pair x y)
Now you can say:

  \the_pair = (pair 2.6 3.8)
  ...

  the_pair \x\y
    print "left is ";  print x;
    print "right is "; print y;
So, to sum it all up, I am just irresistibly attracted to the utter profundity of this concept. I like how the components of a piece of data simply "present themselves" to the handler function(s) applied to it. Also, you can name your data constructors anything you like -- there are no ultimately predefined names for anything, except any primitive combinators built into the C code, but even these can be shadowed or hidden. So if you want to use "item" and "end" instead of "cons" and "null", you can. (I do.) And if you want to use "first" and "rest" instead of "head" and "tail", you can.

If you like, you can download the code at http://fexl.com/code . One of these days I should put a sandboxed demo interpreter up on the site.

Re: In Lisp, should lists be replaced with trees?

#20
post #11

It's easy to implement both lists and name-value associations in terms of pairs, so I'm not sure why they need to be built in. In Fexl ( http://fexl.com/code ), the only built in concept is the function , and all data is structured out of functions. I won't go into all the details here, but concepts like pair, list, key-value assoc, branch, and everything else are readily expressed as pure functions. So-called "circu…

There's an interesting write up about the idea of "everything is a function" in Haskell at http://conal.net/blog/posts/everything-is-a-function-in-hask... . What's your rationale vbehind everything being a function?

Although I keep hearing “everything is a function” (and 3 is a nullary or constant function), I don’t hear people say “everything is a list”, and 3 is really the singleton list [3].

Well, in musings around Arc, pg did mention defining everything as a list, including 3 as [[] [] []], I believe. So, it's not that no one says it. :)

Post reply on HN