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.
In Lisp, should lists be replaced with trees?
11–20 of 43 posts
Re: In Lisp, should lists be replaced with trees?
#12Re: 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…
The purest definition of a tree graph is "a graph with no cycles".
Re: In Lisp, should lists be replaced with trees?
#14It'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…
What's your rationale vbehind everything being a function?
Re: In Lisp, should lists be replaced with trees?
#15He 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? "
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.
Re: In Lisp, should lists be replaced with trees?
#17So what's the point of "replacing" them (even if such a thing were possible without "replacing" Lisp)?
Re: In Lisp, should lists be replaced with trees?
#18It'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?
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?
#19Re: In Lisp, should lists be replaced with trees?
#20It'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?
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. :)