freenode/#lisp - IRC Chatlog
Search
5:56:11
holycow
docs updated. okay not tedious at all. i just need a tip on how to think about solving the problem and what to google for
5:59:37
holycow
i have a text file with a list of music files, one per line. i want to load the list of music files and i guess basically sort by 'i like it' 'i don't like it'. the interface part isnt too much of an issue. so uiop:read-file-lines works fine, but i am wondering how to 'store' the list of files in lisp ... maybe an array? I keep on reading about tokens as well. basically i will create a loop that will
5:59:43
holycow
loop over the list, ask me a question, record the answer and move on to the next one.
6:01:21
moon-child
can make a structure with a slot for the name of the file and a slot for whether you like it
6:03:30
beach
I would make a list of standard objects, one object per file, and have a like/don't like slot in it. I would not necessarily sort it right away. But then, I would hide the list behind a protocol (interface) that does not mention the representation.
6:05:16
ldbeth
for LOOP macro, how should I write (loop for j <<if (oddp j) then from 0 to x else from x down to 0 >> do ...)?
6:07:42
beach
There is no simple way. You may use FOR ... THEN instead of TO/DOWNTO, but it is not necessarily going to be prettier than two loops.
6:19:12
Nilby
charles`: It's kind of a meme that Lispers think everything is trivial, even when it's not, or at least not in other languages. Although it's true that many such packages are very simple portability wrappers around what is provided by an implementation.
6:41:33
fiddlerwoaroof
I always just assumed that it was because those libraries are intended _not_ to do anything particularly interesting
7:02:21
logand```
Alfr_: if call-arguments-limit is an issue: (reduce (lambda (l r) (let ((rr (length r))) (when (= l rr) rr))) '("hi" "th") :initial-value 2)
7:07:48
pyc
(uiop:delete-directory-tree "/path/to/dir") gives me this error: UIOP/FILESYSTEM:DELETE-DIRECTORY-TREE was asked to delete "/path/to/dir" but it is not a physical non-wildcard directory pathname. I think the pathname is expected in a different format. How can I fix this call?
7:10:53
pyc
carkh: same error. I think it needs a "physical directory pathname", not a string. I don't know what that means.
7:13:02
pyc
moon-child: yes, #p, trailing slash and :validate t worked. why is :validate t required?
7:17:19
moon-child
pyc: https://privet-kitty.github.io/etc/uiop.html#index-delete_002ddirectory_002dtree
7:18:03
pyc
moon-child: the docstring cautions using `:validate t` with care? what if I did not want to use `:validate t` but do it the right way by making ensure-function happy? What is ensure-function?
7:19:56
moon-child
pyc: :validate t is the 'right thing' if that's what you want to do. :validate t is like rm -rf. Passing in a function there is like rm -i
7:22:10
moon-child
I agree that that's convenient. It would also be convenient if (eql 'a 'a) => 'a. This indicates that a more general solution, which can support the latter case as well, is in order
7:24:23
pyc
moon-child: does the pathname #p"/path/to/dir" in the call to uiop:delete-directory-tree always have to be an absolute path? Can I not use relative path there?
7:32:51
Nilby
Consider that the reasons for = returning a boolean have like 50 years of practical experience and argument and papers written about the reasoning behind equality predicates. Thankfully you can make your own equality function and use it and see which one you like best and what the problems could be.
7:34:32
logand```
moon-child: but that only shows that trying to apply it to eql is not a good idea, not that (= 3 3) => 3 is a bad idea
7:37:00
moon-child
logand```: my claim is that, once you know two things are equal, it's generally useful to know what one of them was, and that this doesn't just apply to numbers. I think there should be a more general solution to the problem, one that allows you to test (eql nil nil), know that the comparison was successful, and know that the object being compared was nil
7:37:28
moon-child
(incidentally, eql is a _better_ target for this than =, since it doesn't suffer from the problem Nilby points out where 3 and 3.0 are = and yet distinct)
7:39:23
Nilby
logand```: Sorry. I'm bad at explaining but many people might be able to explain better than me.
7:42:19
Nilby
This has some disussion of equality predicates, although not about non-boolean equality. http://www.nhplace.com/kent/PS/EQUAL.html
7:43:52
pyc
Why does https://privet-kitty.github.io/etc/uiop.html#index-delete_002ddirectory_002dtree not specify the return value of uiop:delete-directory-tree?
7:49:54
Nilby
Another example, if I say (defun == (a b) (if (= a b) b nil)), then consider the performance/storage/gc differences between (= (expt 2 10000000) (expt 2 10000000)) and (== (expt 2 10000000) (expt 2 10000000))
7:52:08
Nilby
One returns an object with a lot of storage requirements, the other can be stored in one bit.
7:53:30
moon-child
you already needed to compute both numbers, though; waiting a little longer before freeing one doesn't matter much. Maybe you're done with the object before the next gc cycle anyway. And it's a trivial compiler optimization to avoid keeping around the object if you treat it as a boolean
7:57:30
Nilby
Maybe, maybe not. Maybe your compiler is smart enough to not even create the number in the = case. Maybe you're storing the results of the == case in a loop. = as it is, just has far less potential problems, and it's very easy to make == if you want it.
8:12:08
logand```
moon-child: those are not distinct by the = definition. it doesnt make sense to talk about = equality and mix in eql equality
8:14:42
moon-child
logand```: yes but there are other definitions by which they are distinct, so it matters which you return
8:18:45
logand```
moon-child: i don't think storing for longer issue is an issue. even if it was an issue, returning the last argument would practically eliminate that issue
8:20:18
logand```
actually even returning the first one should not be an issue unless lisp can somehow gc function arguments before the function returns
8:21:14
Nilby
The equality operators in CL make people wonder, but there's a lot of deep and practical reasoning behind them.
8:26:52
logand```
same probably applies to < e.g. what if (< 1 2 3) returned 3? although this might be more controversial
8:28:49
Nilby
Interestingly you can make your own set of comparison operators and test out the performance.
8:32:52
logand```
Nilby: of course you can make your own, for example if you write a calculator which needs to deal with not-yet-entered input, math operations that accept nil and return nil in nil case are useful. this brings the question, why does + not accept nil and insist on throwing error? is that more useful behaviour? scheme distinguishes #f nil and throws error, is that more useful behaviour? (i don't think so)
8:32:52
carkh
now going with this = returns its parameter thing to it ultimate conclusion, you get the c language
8:39:37
Nilby
I think when designing a language you have to consider not only utility, and advanced usage, but performance, and simplicity and how confusing something might be, and potential programming pitfalls. I feel like CL makes pretty good choices about these. I particularly like that it tries to not sacrifice efficiency while still allowing for flexibility.
8:46:55
jdz
I may be missing the beginning of this discussion, but why would (+ 1 nil 3) return nil?
8:52:47
Nilby
I'd be interested to see the design of a computer where it doesn't have an efficiency impact if a return type is (or null number) vs number.
8:54:16
jdz
Nilby: It seems to me that IEEE floats cover this (NaN being the null part, a specially encoded number).
8:56:45
jdz
I seem to remember there is quite huge unused value space in floats, so they might be used for value tagging, so all we really need is floats. Somebody should code up a CL which uses floats for everything.
8:59:45
moon-child
jdz: compared with the fixnum-boxing employed by most cl implementations, unboxing a float is a somewhat expensive operation. It makes sense for lua and js only because there are no integers
9:03:37
pyc
In my SBCL, when I try to use uiop, I get: Package UIOP does not exist. What could be the issue? I don't have quicklisp at this time. Is quicklisp mandatory to use uiop?
9:05:54
pyc
Then I will always (require :asdf) in my programs to keep them portable, so that they run on any implementation regardless of whether quicklisp is installed or not.
9:09:44
pyc
beach: logand```: I normally use quicklisp, so quicklisp adds some code to .sbclrc which loads asdf by default anyway. I was more concerned about the user experience, someone who has plain sbcl but may not have .sbclrc or quicklisp. for them I will (require :asdf) in my programs itself to keep it more portable.
9:11:16
logand```
.sbclrc is a bad idea if not using sbcl, .sbclrc is a bad idea if sharing that code with somebody else, .sbclrc is a bad idea if you want to save time in the future
9:21:17
specbot
Standard Macro Characters: http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
9:31:09
jdz
logand```: I have ~/.common.lisp, which is loaded from ~/.sbclrc, ~/.ccl-init.lisp, ~/.eclrc, etc.
9:32:59
jdz
Might as well create a single file with reader conditionals, and link the implementation-specific rcfiles...
10:43:54
pyc
If I have a variable x with "hell" in it, how can I append the character literal #\o to x, so that I get "hello"?
10:45:25
beach
pyc: Either the string has a fill pointer and you can do it by modifying the value itself, or else you need to change the value.
10:46:37
pyc
beach: I mean I have (defvar x "hell"). I can always do something like (concatenate 'string a "o") to get "hello" but what if I want to supply #\o instead of "o"?
11:22:04
_death
funny, I just had some email exchange with someone who knows a little Lisp about such operations.. actually it was about bombs, and not in English, but here's a translation of a message: https://gist.github.com/death/68ddf9eb12ed9f133364fc71200d6511
11:35:49
beach
The fact that Xach brought up chapter 31 of the SICL specification http://metamodular.com/SICL/sicl-specification.pdf yesterday made me realize that there was (and still is) more important stuff to include.
11:35:50
beach
So I wrote sections on documentation strings (now 31.3), use of the most specific construct (31.11) using packages (31.12), and I expanded the section on commenting (31.4). After my lunch break, I'll write the section on names of slot accessors (31.13) which is still empty.
11:37:00
beach
Comments are welcome, except the ones in the categories "I disagree", "But *I* prefer...", etc. Because I already know the arguments.
11:47:02
_death
maybe summarize the normative with Dos and Don'ts, like 31.2 Don't write lines that are too long
11:49:12
_death
for example I'm reminded of https://root.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_3.html
12:16:53
_death
also, "the last line of the file should not be blank" is unclear to me.. it is a common convention to have text files end with a newline, so in a sense the last line is always blank
12:17:44
loke`
A text file is usually defined as ending with a newline, and with that definition Beach's working is correct.
12:19:18
jmercouris
in what case would code be correct/incorrect based on the presence of such a line
12:27:09
_death
if you don't think it matters, modify your current tools to not add a newline (because they likely all do it) and see what happens
12:37:28
_death
good.. that's the value of conventions, that people follow them even if they're not perfect
12:40:57
_death
logand: more often it's in the other direction.. and this is why the software world looks like what it looks like nowadys ;)
12:42:13
_death
new conventions are constantly created without looking into how previous conventions went off and came about
12:43:41
jmercouris
the problem is many conventions were created by inertia, or no longer technically relevant problems
12:43:51
jmercouris
reminds me of the famous paradigm of the bananas and the monkeys getting squirted
12:44:08
_death
existing conventions are deemed imperfect, and some take this to mean they are worthless and create new conventions that have the exact same issue but without the advantage of status quo
12:48:47
jmercouris
that's a really cool story ldbeth` , however, I don't see how that is relevant to my argument
12:50:03
_death
I'm guessing it's all veering into offtopicness or, by channel convention, lispcafeness (lispnescafe?)
12:52:01
_death
jmercouris: such opinions on OO always remind me of this post and its surrounding discussion: https://groups.google.com/forum/message/raw?msg=comp.lang.lisp/-uoDKZeKBr4/qGgFy-M3mvoJ
12:54:45
_death
also, this is Lisp, OO is too narrow.. we had semantic networks and frame systems, dammit
12:59:15
carkh
hum naming question, if numbers between 3 and 5 is a "range", how do you call the numbers over 3 ?
13:00:59
jmercouris
how so? a domain is as narrow or as wide as it needs to be based on how you define it
13:08:09
carkh
ohwell i think i'll go with range, and specify it's actually a half-range in the docstring =)
13:09:41
Alfr_
Problem is that range already has a definition in this context, as max(I)-min(I) when I i bounded.
13:37:21
beach
I mostly agree with _death. Most conventions don't exist because of some reason of technical superiority but as Pinker puts it because some "tacit agreement". Their main advantage is to exist. So abandoning them in favor of others, that are not agreed upon, is very unfortunate.
13:38:56
beach
But I often see evidence here of the common idea that we should do whatever we please because conventions are crap and we know better than all those silly old people who came before use.
13:50:52
beach
For instance, there is absolutely no technical reason to use `argc' and `argv' as names of the parameters of `main' in C. And there is no technical reason to prefer `i', `j', `k' as loop variables for indices of arrays. Mathematicians use `x', `y', `z' for numbers, but there is no technical reason for that either.
13:50:53
beach
It is just, like I wrote in that chapter, and arbitrary convention that evolved over time, often for unknown reasons. And that is exactly why we should continue using it.
13:52:45
jackdaniel
if there is a good reason to break a convention I'd say that one should do that. otherwise conventions would not evolve over time. I don't consider "not liking it" being a good reason for breaking the convention though.
13:53:36
beach
I totally agree, and I deliberately try to break some conventions myself. Like the one of prefixing a slot accessor with a class name, rather than using the package system.
13:55:37
jackdaniel
I often get confused when there are too many packages in the codebase I'm reading
13:55:50
beach
But, I wrote that chapter as a guide for inexperienced people who might not even recognize the existence of conventions, because they probably have little experience from reading other people's code. So the emphasis is on following conventions rather than breaking them.