freenode/#lisp - IRC Chatlog
Search
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.
14:07:47
_death
sometimes defining a scope for a convention is useful.. for example in this file/library/organization they use class-foo names, so I'll add class-bar.. but in this library they use foo names, so I'll add bar.. in this way different conventions can coexist while maintaining some level of sanity
14:14:48
_death
throughout the lifetime of a programmer it makes sense "try on" different conventions.. sometimes you settle on the ones you like, and sometimes they are more dependent on context.. so some of my projects are written in one style, and others are written in a very different style.. sometimes it's the result of an "accident", i.e. "trying on", and other times it's on purpose..
14:16:10
Xach
One problem comes from people who disagree so strongly they refuse to participate unless everyone else agrees to their demands.
14:16:21
beach
_death: Do you mean different choices of existing conventions, or establishing conventions for situations where none exist?
14:16:56
_death
and the inexperienced can indeed benefit from trying to follow guides that lead coherent styles
14:18:31
_death
beach: and throughout the relatively long evolution of Lisp, there have been different ways of doing some things :)
14:19:40
beach
_death: I find that these conventions evolve over time, more like a progression from conventions that did not work out so well to more solid ones.
14:20:02
Xach
beach: I very much like the section on the Dunkers in Franklin's autobiography on the topic
14:21:22
_death
beach: I guess some of them do, yeah.. because we as a (CL) community tend to appreciate Lisp tradition and learn the history
14:24:05
_death
beach: unfortunately as communities grow larger, it's almost inevitable to regress or diverge
14:25:11
beach
_death: That's part of the reason that I am always a bit queasy about the desire to enlarge the use of Common Lisp at all cost.
14:26:05
_death
beach: but that's where your style guide or other writings or help on irc for example may help ;)
14:27:01
beach
That's why I am trying to finish this text before Common Lisp become hugely popular. :)
14:42:37
shka_
i sometimes think that re-branded Common Lisp would had a better shot at becoming popular
14:45:51
beach
I think shka_ is suggesting a different name, so that people who associate "Lisp" with slow, interpreted code with lots of parentheses would not immediately reject it.
14:46:49
beach
And that might work for young inexperienced programmers who don't care to learn about computing history, but I think "Lisp" is an indication of a heritage we should be proud of.
14:49:06
Nilby
I don't care if everyone calls it PowerLang™ DynamicScript™, I'm still gonna program in Lisp.
14:49:07
beach
I for one do not particularly want to attract people with uninformed opinions like that to Common Lisp. We would spend the rest of our lives giving them newbie advice here.
14:52:11
beach
semz: In some groups, very likely. Like Python programmers, for instance. But I bet that many C++ programmers still think their code is faster than what we could produce with Common Lisp. And that might be true for some truly unmaintainable C++ code, but not for modular C++ code, as I often point out.
14:54:28
loke`
semz: I'd hope so. People keep using Python these days which is the slowest language I've ever had the misfortune to lay eyes upon.
14:54:57
fitzsim
I skimmed OpenDylan recently and didn't see many references to Common Lisp in the code though
14:54:59
Nilby
and yet Dylan, which is seems like one of the most easily readable language ever, didn't seem to become popular. so I think language popularity has more to do with external factors.
14:55:02
loke`
The speed argument was only popular when all the cool kids were using C, which has pretty much only a single thing going for it: I can be fast (at least on the computers at the time)
14:55:36
fitzsim
I guess Dylan was bootstrapped from Common Lisp but then later by itself or something?
14:56:16
beach
Nilby: Oh, definitely. The people who think that changing the syntax of Common Lisp will magically make it more popular are definitely wrong.
14:57:23
fitzsim
I was hoping that OpenDylan would sit on top of Common Lisp, and offer an alternative syntax; that's why I wanted to try it
15:02:30
epony
the fun part is.. that Lisp people always try to compare themselves on speed with a failure of some sort in programming design application
15:05:13
contrapunctus
shka_: I liked CL21, but stylewarning's comment on the matter resonated with me - https://reddit.com/comments/kylep5/comment/gjhzpe6?context=3 (I'd said the first half myself in ##lisp once)
15:07:27
contrapunctus
Speaking of misconceptions, I've heard time and again that "you can't make GUIs in Lisp" 🤦
15:11:38
contrapunctus
I liked * the idea of CL21 ("modernizing" the language while leveraging existing CL implementations)
15:13:41
shka_
if anything, I still think that porting some of the C++ <algorithm> (preserving semantics where it would make sense) wouldn't be a terrible idea for a project
15:16:17
shka_
but yeah, i think that stylewarning comment is on point, you need tested, de facto standard tools
15:18:35
semz
The STL does have some nice ideas. It's a shame that a lot of the related material (Stepanov's generic programming stuff too) is buried under mountains of C++ arcana and other obscurantism.
15:19:34
shka_
yes, i think that all things considered it is a well designed library (in most of the areas)
15:27:43
beach
contrapunctus: Hah, one of my engineering students laughed very hard when I hinted that sockets could be used by a Common Lisp program.
15:31:35
beach
My student was convinced that Common Lisp was a toy that could not be used for real programming. Or so he wanted to believe so as to avoid the cognitive dissonance that would otherwise be inevitable.
15:33:02
warweasle
Xach: Yes. But I didn't know. And microsoft kept telling me to learn C++, MFC and COM.
15:41:01
Nilby
warweasle: you might know that beach's current "assignment" is writing our next super CL compiler :)
15:41:28
pyc
Is there a quick way to surround the current sexp with parentheses in Emacs or Paredit?
15:44:46
contrapunctus
pyc: if you use Boon, you can `a p ;` to surround the expression after point with parens and `a p j` to do it for the expression before point; Evil probably has an extension for it too; and amartparens definitely does it.
15:46:11
pyc
contrapunctus: I use Emacs4CL which is just plain Emacs + sbcl + slime + paredit. So M-( works great for me.
15:46:49
attila_lendvai
warweasle, it's been dead, and in the past year it became a one-bus project... :)
15:47:30
warweasle
attila_lendvai: There was so much I didn't understand but it's intriguing. A mix of machine code and lisp?
15:48:03
pyc
Xach: did you mean ( C-<right-arrow>. That slurps forward. I don't see what M-<right-arrow> is supposed to do.
15:48:44
attila_lendvai
warweasle, the code wasn't very accommodating to newcomers, but i think it got much better in that regard.
15:49:34
attila_lendvai
warweasle, and i wrote some docs in the docs/ dir! if you have read them, then i welcome any questions that remained foggy afterwards!
15:49:53
warweasle
Now that I know who to ask, I might look back into it. But first I need to get my current project working.
15:50:27
warweasle
attila_lendvai: It's been a while, so I'll need to read them again. I'm pretty sure I'm running a stack based OS in my head.
15:53:46
slyrus
Has anyone taken a stab at better pretty printing facilities in the last, oh, 30 years? The built in pretty printer is showing its age, IMO.
15:58:31
slyrus
part of it may be my lack of understanding but it is a pain to use and harder to get things to look right. Also, it very much seems designed around printing lisp forms. If you're data isn't a list, the built in capabilities seem very limited.
16:02:05
Xach
slyrus: i'm curious if there are other systems you like from which good ideas might be stolen...
16:16:22
beach
New section 31.14 in http://metamodular.com/SICL/sicl-specification.pdf concerning the use of DEFGENERIC.
16:19:28
gabc
Hi, I'm on windows and I'm trying to find out a good way to do lisp (on linux/mac I use sbcl+emacs and it's great) but I haven't have been able to figure something nice on windows
16:20:26
pyc
What is a good coding style? require statement at the top of a .lisp file? or just before where I need to use the package?
16:20:27
epony
well, who makes the comparisons and false claims, elaborates.. since they are defending their claims ;-) I have nothing to say on that topic.. it was all outlined in several obvious facts from all systems that pick C for systems programming regardless of what other language users think about their own favourites
16:21:50
beach
epony: Can you give an example of "Lisp people always try to compare themselves on speed with a failure of some sort in programming design application". I can't even parse the phrase.
16:21:53
pyc
gabc: SBCL + Emacs should work fine on Windows too. I use https://github.com/susam/emacs4cl Much simpler alternative to Portacle. you can use your own Emacs with this config.
16:22:03
Nilby
I'm pretty sure I just installed the whatever current versions at the time. The tricky part is making sure you have a libffi for sbcl, which I had to do with cygwin.
16:22:40
epony
well, you can parse it of course.. since people compare Lisp as speed with things that are slow and failing
16:22:42
slyrus
beach: no, this one's above my pay grade. But I probably could spend some time formalizing my gripes.
16:22:55
pyc
Xach: I need (require :asdf) because I am using uiop. what would be the way to load it without (require)? sorry, I haven't learnt systems yet
16:23:37
pyc
gabc: did you set up Emacs + SBCL on linux and macos yourslf? what else do you use? do you have SLIME? do you use paredit?
16:24:18
slyrus
beach: I can't be the first person to have complained and/or thought about how to make things better in the last 3 decades.
16:24:23
Nilby
gabc but I didn't use slime since I was working on stuff that ran in a windows console
16:24:43
gabc
pyc: I use lispy mostly that part of the config I have quite down, I just never used Windows to do lisp
16:24:54
Xach
pyc: hmm, i would try looking at some existing projects and libraries, and look at the .asd files
16:25:27
Nilby
slyrus: I've been thinking about it too, and if you check the irc logs death found some good papers.
16:25:32
Xach
pyc: at their simplest, a system file defines a system with a name, a list of zero or more prerequisite systems, and a list of source files to compile and load.
16:25:51
Xach
pyc: so if you see an overwhelming system definition, know that it doesn't have to be that complex
16:26:58
Nilby
gabc: For emacs, I just clicked on it, but for sbcl I was working on my own repl in a console window.
16:28:19
slyrus
beach: yes, with the pretty printer. sometimes even small-seeming details around the margins make things much more useful. The analogous example for me is the with-readtable stuff. makes readtables much more usable, IMO.
16:29:12
gabc
Nilby: I have it working but I came here to see if people use something else I remember running into problems (that I forgot it's been a moment) I'll try out more and if I get into something specific I'll ask again
16:30:40
Nilby
slyrus: I've been trying to use the pretty printer to do indenting in my editor, but so far the results aren't so good. But I haven't tried much tweaking yet. I have to read/re-read some papers.
17:01:33
minion
logand: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
17:19:48
beach
logand I am usually present between 5am and 6-7pm (UTC+1 at the moment) with some breaks. But there are people in several other time zones that can answer questions in case you have any.
17:21:19
logand
beach: i need to think about questions first but if i find something to say, i will:-)
17:33:21
beach
Yes, Dan Barlow came up with it during LSM/RMLL, perhaps 2000 or 2001 or something like that.
17:35:37
beach
That's also where gilberth created the basis for McCLIM. And where we came up with how SBCL should represent special variables in the presence of threads.
17:39:05
beach
Poor Krystof had to translate the speech of the adjunct mayor from French to English in real time.
17:40:19
beach
It appears that mayors of France have, as part of their job description, the obligation to organize a (free) cocktail party for visiting conferences, so we were invited to the splendid city hall for one of those.
17:43:44
Nilby
Apparently the mayoral duties in Bordeaux included the mayor (or assistant) said I looked like a sheep, but might have a black heart.
17:48:08
warweasle
I forget how international the lisp community is. I'm just dumb american. Hopefully I'll get to travel some day.
17:55:33
warweasle
Anyone here know more about the NAVSEA programming language study. Lisp was one of the languages used and I'd love to get some context.
17:57:27
warweasle
Namely, they held things against lisp like "not being understandable" and "the developer showed up late".
18:26:29
warweasle
contrapunctus: I can't find the paper right now, but they were really leaning into Haskell.
18:59:43
beach
Hudak is one of the creators of Haskell, and that paper was specifically about Haskell, so it is not surprising that they favored it.
19:01:23
beach
I used that paper in my teaching, and I have an industry talk based on it. But not because of Haskell or Lisp, but because of the factor 20 difference in productivity reported, between different experts using the respective language that they master.
19:08:17
albusp_
Would anyone know why I can't load cl-freetype2 to lispworks7.1? Error is No applicable methods for make-instance with args ft-outline-funcs
19:22:26
holycow
if i have a string in the form of /dir/dir/dir/dir/filename.txt, i would like to find the last / char and then extract rest from that line. i have looked at strings, pattern matching and regex on clcookbook but i'm not finding how to find the last / char. any tips on what to google?
19:22:42
pyc
If I place the cursor on (+ 1 1) and type C-c C-c, it compiles it but does not show the result. What do I do to see the result?
19:24:42
Bike
holycow: you can just use cl:position for that, if i understand your problem correctly
19:25:51
Bike
(position #\/ "foo/bar/baz/x.txt" :from-end t) => 11, and then (subseq "foo/bar/baz/x.txt" (1+ 11)) => "x.txt"
19:26:33
pyc
Bike: C-x C-e is very different from C-c C-c. With C-c C-c I can place the cursor anywhere within an expression and it always compiles the top-level form. But C-x C-e only evaluates the last expression before the cursor.
19:31:00
mdevos
Is there a formal set of guidelines for what to talk about here, or should I just rely on what I think is reasonable?
19:32:41
mdevos
does someone know a Scheme <-> Common Lisp compatibility layer? I want to use a Common Lisp library in Guile Scheme
19:34:07
Bike
i think they are different enough languages that a "compatibility layer" would have to be very extensive.
19:35:49
mdevos
I don't mind fudging many details (e.g. I don't put defun and defvar definitions in separate namespaces even though they should be in common lisp IIUC)
19:38:12
mdevos
Bike: probably (-:. Though I can save myself some typing by defining the "defvar" and "defun" syntaxes in terms of Scheme's define, and maybe likewise for other things
19:38:56
Bike
some things are going to be more involved. i don't think scheme has anything like CLOS, for example