In Lisp, should lists be replaced with trees?
31–40 of 43 posts
Re: In Lisp, should lists be replaced with trees?
#32Earlier quoted context omitted.
I think the answer is we should have it, but it's just a library.
OK. Then I suppose the question is: why should it be library not built-in? The main thing not addressed in the article is: what are the language implementation implications? What are the pros and cons there?
For me, the language implications are nil. I would not change a single thing in Fexl to support name-value "trees" versus lists. It's all programmable using the system as it is. The S, C, Y, I, L, R combinators are what they are, forever and ever, world without end. :) And I'm quite sure the same thing is true of Lisp (i.e. just use defun or maybe defmacro). You'll notice that even in the original article the author didn't propose any new syntax. It's all just more functions.
I mean, even in Perl for goodness sake all you have to do is this:
# A map is a list of branches. Each branch is pair(key,data). The data is
# pair(val,map). No two keys in a map have any prefix in common. A key cannot
# be null. If you put a null val at a key, it deletes that key from the map.
sub map_put
{
my $map = shift;
my $key = shift;
my $val = shift;
die if !defined $key || ref($key) ne "" || $key eq "";
die if !defined $val;
if (is_atom($map))
{
return $map if is_null($val);
return pair(pair(atom($key),pair($val,null())), $map);
}
my $branch = left($map);
my $old_key = name(left($branch));
my $cmp = $key cmp $old_key;
if ($cmp == 0)
{
my $sub_map = right(right($branch));
if (is_null($val))
{
return right($map) if is_atom($sub_map);
if (is_atom(right($sub_map)))
{
# Combine singleton map upstairs.
my $top_key = name(left($branch));
my $next_key = name(left(left($sub_map)));
my $new_branch = pair(atom($top_key.$next_key),
right(left($sub_map)));
return pair($new_branch,right($map));
}
}
my $new_branch = pair(left($branch), pair($val,$sub_map));
return pair($new_branch,right($map));
}
if (substr($key,0,1) eq substr($old_key,0,1))
{
my $len_common = len_common_prefix($key,$old_key);
my $key_suffix = substr($key,$len_common);
my $old_key_suffix = substr($old_key,$len_common);
my $common_prefix = substr($key,0,$len_common);
if ($key_suffix eq "")
{
return $map if is_null($val);
my $sub_map =
pair(pair(atom($old_key_suffix),right($branch)),null());
my $new_branch = pair(atom($common_prefix),pair($val,$sub_map));
return pair($new_branch,right($map));
}
if ($old_key_suffix eq "")
{
my $old_sub_map = right(right($branch));
my $new_sub_map = map_put($old_sub_map,$key_suffix,$val);
my $old_val_atom = left(right($branch));
if (name($old_val_atom) eq "")
{
return right($map) if is_atom($new_sub_map);
if (is_atom(right($new_sub_map)))
{
# Combine singleton map upstairs.
# TODO hey wait! This is the same code as above. Unify this.
my $top_key = name(left($branch));
my $next_key = name(left(left($new_sub_map)));
my $new_branch = pair(atom($top_key.$next_key),
right(left($new_sub_map)));
return pair($new_branch,right($map));
}
}
my $new_branch = pair(left($branch),
pair($old_val_atom,$new_sub_map));
return pair($new_branch,right($map));
}
return $map if is_null($val);
my $old_branch = pair(atom($old_key_suffix),right($branch));
my $sub_map = map_put(pair($old_branch,null()),$key_suffix,$val);
my $new_branch = pair(atom($common_prefix),pair(null(),$sub_map));
return pair($new_branch,right($map));
}
if ($cmp
That would be a lot cleaner in Fexl or Lisp, but it's totally do-able in any language.Re: In Lisp, should lists be replaced with trees?
#33"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?
#34A list structure is already a 'dictionary tree', except it has lousy performance in access. (only really visible on large data sets). * (second (assoc 5 '((1 2) (3 4) (5 6)))) > 6 The lousy performance doesn't matter, most of the time, because you have other data-structures for data, and your compiler generally is only interested in sequential access (constructing a parse tree out of it). The lisp code already being…
Re: In Lisp, should lists be replaced with trees?
#35not directly lisp related, but the team working on Fortress has some interesting work on using "conc lists" (pairs, and trees as a combination of pairs) as a basic unit of work for parallel processing[1], the analysis quite naturally considers its relation with lisp ad cons lists in other languages. [1] http://labs.oracle.com/projects/plrg/Publications/ICFPAugust...
Re: In Lisp, should lists be replaced with trees?
#36http://en.wikipedia.org/wiki/Abstract_syntax_tree http://en.wikipedia.org/wiki/Graph_reduction
:)
Re: In Lisp, should lists be replaced with trees?
#37not directly lisp related, but the team working on Fortress has some interesting work on using "conc lists" (pairs, and trees as a combination of pairs) as a basic unit of work for parallel processing[1], the analysis quite naturally considers its relation with lisp ad cons lists in other languages. [1] http://labs.oracle.com/projects/plrg/Publications/ICFPAugust...
Re: In Lisp, should lists be replaced with trees?
#38Earlier quoted context omitted.
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?
#39 http://common-lisp.net/project/fset/
Unlike what the OP is suggesting, FSet doesn't expose the internal structure of its trees. Instead it wraps them in a rich set-theoretic interface.