libera/#commonlisp - IRC Chatlog
Search
8:43:38
pjb
(let ((r '(1 2 3 4 1 2 3)) (l '(3 4 5 6 4 5))) (values (intersection r l) (remove-if-not (lambda (l) (member l r)) l))) #| --> (3 4 3) ; (3 4 4) |#
8:44:56
pjb
What is missing is only (defun seq-equal (a b) (and (subsetp a b) (subsetp b a))) ; perhaps more efficiently.
8:44:58
gin
Need some advice with this code: https://plaster.tymoon.eu/view/2558 - I am comparing two approaches here. (1) ex-1: A single LET for all lexical variables. (2) ex-2: Multiple nested LETs for defining lexical variables only where they are needed.
8:45:39
pjb
a set-equal function would make it more concrete that there's a set type based on list, like subst and copy-tree make it clear there's a tree type based on lists.
8:47:07
gin
pjb: If I assume compiler can optimize things out, then I can stick with ex-1 where a single LET contains all lexical variables, couldn't I?
8:47:55
beach
gin: It is not a question of compiler optimizations. It is a matter of how much code the person reading your code has to consider for an occurrence of the variable.
8:47:57
gin
beach: thanks! I was thinking that too. But then does it bother anyone that it may lead to multiple nested-LETs making the code harder to parse with eyes? Or is that not a valid concern?
8:52:28
gin
beach: thanks! I have mentioned in comments at the top that I am making a contrived example to compare my LET-approaches. could not make a more sensible example. I understand that LOOP COLLECT is appropriate here and COUNT is not required.
8:54:04
_death
gin: the nested LETs make it easier to pull the forms out into their own function, for example.. they also make it easier for the reader to know the value of the bindings, considering the alternative is a variable that changes over time
8:54:26
beach
(loop for article in articles for newline-position = (position #\Newline article) collect (subseq article 0 newline-position)) with appropriate newlines inserted.
8:57:34
beach
gin: A general rule of programming is that a function should do one single thing. The computation of the length makes the function do two things, which is not good.
8:58:26
beach
gin: You might see that more easily if you consider this function as also computing the reverse of the list, the Fibonacci number of the length, etc.
9:05:08
beach
So you must already know those rules, i.e., minimize the scope to make life easier for the person reading your code, and make each function do one thing.
9:31:40
gin
thanks shka. Is that true in general too? does it take constant time for any proper sequence?
9:34:01
beach
gin: If you think about how lists are represented, you can see that it has to traverse every CONS cell as shka is saying, so there is no way it can be O(1).
9:36:39
beach
gin: And if you don't know how lists are represented, it is time to learn that part. Otherwise, may things will likely confuse you in the future.
9:38:06
beach
... like why (defun push-it (element list) (push element list)) won't "work" as expected.
9:40:04
beach
shka: Indeed. But a significant number of newbies here don't seem to find it useful to read about things like that.
16:05:47
lisp123
Any good resources to learn algorithms when working with trees and also searching / traversing across trees & nodes?
16:07:52
beach
Aho Hopcroft Ullman, "The Design and Analysis of Computer Algorithms" is the classic text.
16:08:57
beach
Apparently, they also wrote "Data Structures and Algorithms" later. I haven't read that one.
16:09:54
beach
Be careful with any old book on data structures and algorithms. I estimate around half of published books get a simple thing like binary search wrong.
16:11:27
beach
Publishing houses will print and sell anything you are willing to write, and they fired all the copy editors decades ago.
16:11:49
beach
Apress seems to be the exception. They recruit qualified editors to screen the material.
16:12:04
lisp123
Yeah, their business models are coming under fire a lot (especially for technical books)
16:12:27
jackdaniel
there is an interesting book that touches this topic in polish "przejęzyczenie" (misspell) - it is a set of interviews with well known translators
16:15:12
beach
Speaking of which, the reason "Lisp in Small Pieces" is better in its English version, is that the translator is also an experienced editor. The original publishing house doesn't have staff like that as far as I know.
16:17:05
beach
As far as I remember, it was just the original text. He later wrote a revised French version, but I don't know more about it.
16:17:44
beach
Though, the translation was made interactively, i.e., they met on a regular basis to discuss the material, so it is not a "blind" translation.
16:19:07
beach
But the translator had knowledge of Lisp, so was able to introduce improvements because of that as well.
16:22:13
jcowan
jackdaniel: I saw a list of Russian surnames somewhere that look scary even to Russians because they are of (remote) Polish origin:
16:23:27
jcowan
Not as clever as the English title, which shows how flexible (twisty) English actually is
16:24:00
beach
hendursaga: No, I am familiar with the French one because I used it in a course, and with the English one because I know the translator.
16:24:27
jcowan
jackdaniel: Here's a few of them: "Yastrzhembsky (the diplomat), Krzhizhanovsky (the writer), and even Przhevalsky (of the horse)."
16:27:11
jackdaniel
I think that Russian nicknames are written in cirillic :) that would be Jastrzębski (Hawk-ski), Chrzanowski (horserasish-ski) and Przewalski (bulldoze-ski); sorry for bringing offtopic :)
16:40:36
Bike
a little while back i wrote up this thing for a type-expand extension https://github.com/Bike/clhs-extension/tree/main/type-expand and i was thinking of filing a pull request to add it (i.e. type-expand(-1), not the other) to ECL, but i was wondering if anyone had opinions on typexpand versus type-expand versus typeexpand
16:43:32
jackdaniel
following convention used for macroexpand that would be typeexpand (and typeexpand-1)
16:44:02
hendursaga
beach: not sure how complete/accurate this is but.. https://github.com/ilammy/lisp
16:44:14
Bike
right, but the double e is weird so maybe it should be type-expand, and alternately maybe it should be typexpand to collapse the double e (this is what sbcl does)
16:53:40
jcowan
jackdaniel: Sure, I just can't type Cyrillic easily so I do Russian in romanization.
16:54:28
jcowan
Part of the trouble is the cyrillicization of "rzh" as such rather than using just zh (or sh)
16:55:11
jcowan
So if I happen to mention Przhewalski's horse (rare, but not unknown), I call it "Shevalski's horse" (with silent "p" as usual in English).
16:55:14
Bike
ecl actually builds on my home machine without the weird problems about floating point i had before, neat
16:57:30
Bike
i think this was probably more an issue with my build environment than ecl. plus i didn't try very hard to figure it out
16:59:13
Bike
i expect there are very few users of sbcl's typexpand to begin with, so renaming things shouldn't be too horrible if it comes to that
16:59:55
lisp123
A philosophical question: How do you choose to order your functions? Say you have A calling B calling C calling D. Do you write D at the top of your file, then C, then B, then A or the other way? Writing bottom up means you will progressively build up the functions so easier to follow (somewhat), whereas writing top down is easier to understand the purpose (since A will contain the main goal, and the remaining functions help it achieve it)
17:01:24
mfiano
I suppose it depends if any are proclaimed inline, and if they even belong next to each other (same file, same package, etc)
17:04:18
White_Flame
I have big demarcations between sections of the file, and keep tightly/privately correlated functions together. Ordering has more to do how commenting works best
17:04:22
lisp123
I started doing topdown (start with exported functions and then working one's way down), although I'm finding today if I write literate programs, bottom up is easier
17:04:59
White_Flame
any aesthetics of your source code files should be driven by documentation/readability, not the code specifically
17:06:13
lisp123
White_Flame: Although one could argue having certain conventions (regardless of the code), helps in consistency - if every file is top down for example, then one would come to expect that format, and vice versa
17:17:12
Bike
jackdaniel: if i want to add exported symbols to the EXT package, do i add them in symbols_list.h somewhere or is there a preferred procedure?
17:22:52
jackdaniel
yes, you add them to symbols_list.h; also you need to add the function to src/h/external.h with a C name declared in symbols_list.h (i.e cl_type_expand) and src/cmp/proclamations.lsp
17:24:04
jackdaniel
it doesn't, but if it is an exported interface it should (so C programmers may invoke it:)
17:24:32
jackdaniel
also you have a gain of direct call instead of dispatching the symbol (in compiled code)
17:25:47
jackdaniel
whatever you put in symbols_list as the C name that name will be used in transpiled code; symbols_list.h is arranged alphabetically afair
18:33:39
scymtym
Bike: would it make sense for TYPE-EXPAND and TYPE-EXPAND-1 to specify the exceptional situations that TYPE-SPECIFIER is not a valid type specifier and ENV is not an environment?
18:37:35
Bike
scymtym: maybe, but i mentally filed that under https://github.com/s-expressionists/wscl/blob/invalid-type-specifier/wscl-issues/proposed/invalid-type-specifier