freenode/#lisp - IRC Chatlog
Search
21:34:55
aeth
jmercouris: The real issue is why are those programmers being paid to work on JS engines and not CL.
21:38:28
jmercouris
maybe we should be asking ourselves: "ask not what your programming language of choice can do for you, but what can you do for your programming language of choice"
21:52:24
bexx
i'm doing an assignment in which I need to download the atoms in the max depth of a list to the succesive upper level
21:55:17
no-defun-allowed
could you provide an example? i'm guessing something like ((a b c)) -> (a b c)?
21:58:10
jmercouris
well I would make a tree structure ffrom the list, and then use a depth first search
21:59:08
jmercouris
no-defun-allowed: I think the program needs to be able to accept a generalized input
21:59:59
jmercouris
the easiest way you'll solve this problem is by breaking it down in the way I suggested
22:00:48
jmercouris
performance is not really critical in this type of assignments, more so clarity in understanding what you are doing
22:01:45
jmercouris
bexx: at any rate you will have to traverse the whole structure to find the deepest list
22:02:56
jmercouris
bexx: I'm not really following you, but if you know how to do it now, best of luck!
22:04:41
grewal
jmercouris: My guess is that bexx has already written a flatten-one-level funtion and a get-deepest-leaves funtion. Most *good* teachers tend to walk you through difficult problems
22:05:18
pjb
bexx: deepth of an atom is 0, deepth of a list of atom is 1. deepth of a list of lists of atoms is 2. This is the before deeepest lists you want to process.
22:06:46
pjb
(I take flatten from a library such as com.informatimago.common-lisp.cesarum.list:flatten but you would have to write it for the exercice probably).
22:07:41
pjb
bexx: note that once you have a working solution, you may notice that it is very inefficient, and you might want to optimize it. This will make it more obscureā¦
22:12:06
jmercouris
the solution is very syntactically simple, but conceptually difficult, in my opinion
22:12:22
pjb
bexx: the thing is that you must write first a working solution. and only once you have a working solution, you should think about optimizing it.
22:13:47
jmercouris
because you will have to traverse the structure a few times, and conceptually it is simpler to traverse a tree
22:14:45
pjb
bexx: see: https://www.informatimago.com/articles/usenet.html#Forms--Lists--Trees--and-Data-Types notably http://groups.google.com/group/comp.lang.lisp/msg/0c66e597e08be90d
22:15:04
grewal
Also it's not so much *making* a tree as it is interpreting the structure as a tree,
22:15:05
jmercouris
bexx: turning a tree into a list and a list into a tree is a function you'd write
22:15:06
pjb
bexx: the problem is indeed not a problem on lists, but of tree. The notion of deepth is a tree notion.
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.