freenode/#lisp - IRC Chatlog
Search
22:15:39
jmercouris
bexx: you could use structs or something to represent nodes, or you could do what pjb says and just treat the list of of lists as a tree
22:15:42
pjb
bexx: but the trick is that there are an infinite numbers of ways to represent trees with lists.
22:16:19
jmercouris
bexx: here is a very short chapter in PCL about treating lists as trees: http://www.gigamonkeys.com/book/beyond-lists-other-uses-for-cons-cells.html
22:16:54
pjb
bexx: so it's a good idea to introduce functional abstration over your representation to clearly manipulate the tree. The function deepth does that. My function flatten-before-deepest doesn't abstract the notion of tree, it's a little magical for this.
22:19:42
grewal
pjb: Why do you keep using the word 'deepth'? Is it a technical term I'm unaware of?
22:23:41
pjb
grewal: (a (b) c) is a tree of deepth 2, with 3 childrens, two leaves a and c, and the subtree of deepth 1 (b).
22:24:39
pjb
bexx: so the magic, is that we don't explicitely say that the list is a representation of a label-less tree node, giving the list of children of the node.
22:25:50
jmercouris
and probably should, because it is unlikely a new user will understand fully/deeply a solution of that nature
22:25:52
grewal
pjb: My question really was 'why use "deepth" instead of "depth"'? And your answer basically is deepth is (1+ depth)?
22:26:18
pjb
grewal: bexx: without the explicit functional abstraction, the magic trick is that I don't show that I've recognized that it was a problem on trees, and given a solution that manipulates implicitely a tree.
22:27:26
jmercouris
bexx: perhaps you'd better spend your time implementing a tree abstraction instead
22:27:59
jmercouris
and part of the exercise is probably for you to understand that nested lists are trees
22:28:26
jmercouris
probably I imagine the nexts lessons will be on homiconicity or something and manipulation of ASTs
22:29:27
grewal
pjb: You usually don't make such mistakes. It's sometimes hard to tell what's an accident and what's intentional
22:32:03
pjb
so in terms of the tree-methods indicated in that usenet post, your trees would be abstracted as: https://pastebin.com/uESF4B2s
22:34:57
sukaeto
Godel[m]: if I were in a snarky mood, my response would be "Has Racket ever been used for anything outside of teaching undergrads how to program?"
22:36:03
pjb
bexx: if you wanted to consider the whole tree, you would have to write it differently.
22:56:38
pjb
bexx: notice that you can easily change the representation of the trees, without changing any of your code. You just need to substitute the set of tree methods in *default-tree-interpretation*
22:57:18
pjb
For example, you could add labels to your tree nodes, or use a representation with CLOS objects for the nodes, etc.
22:59:56
pjb
bexx: notice also that you could just use CLOS and generic methods, but since we are dealing here with interpretations of the same class, namely the CONS class, we would have to wrap our lists in CLOS abstractions. Ie. define different CLOS classes for the different interpretations of our lists. tree-make-tree would return then CLOS instances instead of our lists.
23:32:13
pjb
bexx: yes, it seems good. Only it doesn't abstract away. So it works only specifically on this list representation of your tree.
5:38:50
GoldRin
Bah, simple question, just having trouble with syntax. How would I apply an initial expression to an arugment within an flet in common lisp.
5:40:52
GoldRin
Basically just this: (let dup ([i 0]) ... I just don't know how I would translate from scheme to CL.
5:41:53
loke
I thought Scheme used the same syntax for LET as Common Lisp, but that's not a notation I'm familiar with.
5:42:33
GoldRin
local binding for a function named "dup" with the argument i which is initialised to 0 and local to "dup"
5:44:20
GoldRin
(I suck at IRC, so I hope this works) loke: I've found that scheme and CL have slightly different ordering of parenthesis and it just has been throwing me off.
5:45:46
d4ryus
GoldRin: if you want to call dup from within dup, you have to use labels. labels/flet is like let*/let respectively
5:51:18
GoldRin
Alright, I think I need to do some more reading and research then. This isn't anything really important at least.
5:51:50
pjb
(let dup ((d '()) (e l)) (if (null? e) d (dup (cons (car e) (cons (car e) d)) (cdr e)))) would be written: (loop :named dup :for x :in e :collect x :collect x)
5:52:37
beach
GoldRin: The Common Lisp standard does not require tail-call optimization, so you can't rely on that. Plus, tail-recursive functions are often less readable form of iteration.
5:53:49
loke
GoldRin: Also remembe rthat you really shouldn't do looping with recursion in Common Lisp. Instead, CL has a very strng LOOP construct that should be used.
5:55:22
beach
loke: You are right when it comes to linear structures. But it is common for tree-like structures.
5:58:09
beach
GoldRin: Scheme and Common Lisp are very different languages, especially when it comes to what is considered idiomatic code. It is preferable not to have a "Scheme accent" when you "speak Common Lisp".
6:01:33
beach
I am willing to bet that object-oriented programming is used a lot more in Common Lisp than in Scheme. I may be wrong about that, of course.
6:02:22
GoldRin
Well I'm not highly familiar with either, just I had studied scheme for a bit before studying common lisp. Thanks for all the info btw
6:04:48
loke
GoldRin: Common Lisp is a multiparadigm language, while Scheme is more of a "true" functional language (if there is such a thing)
6:05:20
pjb
beach: of course, 1- CL has a standard object system. 2- CL has the best object system of the world. :-)
6:08:51
GoldRin
I hadn't been using CLOS specifically, but when I reached the functional programming part of the CL book I'm going through, I guess I just assumed that scheme ideas would just translate over.
6:11:17
pjb
GoldRin: the only thing that doesn't translates well in CL from scheme, are generalized continuations. Delimited continuations are ok.
6:12:16
GoldRin
Yeah, I've heard about that. I never really got too far with continuations when I was studying scheme, but I'll probably go back once I've finished this book.