freenode/#lisp - IRC Chatlog
Search
18:25:44
verisimilitude
Oh, a one-pass language; Lisp doesn't require you declare things before using them in every case, as one difference.
18:26:43
verisimilitude
English is the language of programming; your English is decent already; what's your first language?
20:28:54
ioa
hi, does anyone know, whether there will be an ELS-banquet during the ELS days, or just the Programming banquet on Wednesday?
20:48:33
no-defun-allowed
hopefully there'll be, else I have to socialise with non-Lisp programmers, eugh
20:49:06
no-defun-allowed
[wait! no-defun-allowed! you're not going, so you don't have to socialise with anyone!] well, you hopefully won't have to either
20:52:38
moldybits
not sure if this is the place for slime questions? say i've modified bits and pieces all across a buffer and want to re-evaluate everything, how can i do that without excepting on defconstants?
20:53:47
asarch
One stupid question: In this Emacs GNU Emacs 26.1 (build 1, x86_64-unknown-openbsd, GTK+ Version 3.22.30) M-x package-refresh-contents works perfectly. However, in this one GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21) from Xubuntu, it doesn't
20:55:20
asarch
Contacting host: elpa.gnu.org:80, Failed to download ‘gnu’ archive., 5Contacting host: melpa.org:443 [2 times]
21:47:21
jgkamat
I don't think there's a mirror, but you can build the packages from source pretty trivially
21:49:29
asarch
Since Xubuntu is based on Ubuntu which is based on Debian, I think the Linux kernel from Debian has a serious problem
22:52:46
akater
moldybits: I wrap defconstants in handler-bind's (for sbcl, at least). Not sure if this is good style.
0:20:05
luis
fiddlerwoaroof: 99% of sb-unicode seems to be portable CL, so it'd be nice to extract this into a library. Not sure if that's what you meant by "trivial-Unicode". Probably not, because sb-unicode is definitely not trivial.
0:27:51
luis
There's plenty of overlap with cl-unicode, so maybe both porting bits of sb-unicode into cl-unicode would be the way to go.
2:59:40
pjb
akater: it's silly to wrap defconstant in a handler-bind (or any other form that doesn't preserve top-levelness). Constants variables are useful only to the compiler, to be inlined in the generated code. If you put a defconstant in a handler-bind, then it's not a toplevel form anymore, so the compiler won't know it. It will generate unknown variable warning if you use them in the code, and the constant will be available only a
3:01:23
pjb
moldybits: if your constant variables are not constant, then you shouldn't use defconstant. The only thing that can be really constant, are numbers, characters and symbols, because they're "interned": reading them always return the same object. Other 'literal' objects are instanciated anew when read again, so they're not constant.
3:01:41
pjb
moldybits: there are macros to deal with that, but it's implier to just use defparameter.
3:09:13
aeth
Alternatively, if you have to have a constant and don't need it to be global, you can generate the resulting form (e.g. the resulting defun) via a macro to essentially be the same thing as what a constant is.
3:10:22
aeth
yes, you would essentially be writing a macro that uses symbol-macrolet internally to produce a "constant"
3:17:26
aeth
pjb: I disagree with what you said about literals, though. A literal (well, a literal sequence like "foo" or #(1 2 3) or '(1 2 3)) is a de facto constant, and can be detected as such within function scope with some compilers, such as SBCL. So you can use a literal created within a macro or created by '#. (preferably the macro route, it's cleaner) and it's de facto constant as long as it doesn't leave the function.
3:17:49
aeth
pjb: And it might have all of the optimizations that a constant has, but you have to make sure that it doesn't leave the function, since out of the function the information that it's a literal is lost.
3:19:34
aeth
(The macro or '#. to portably create one is only necessary when it's more complicated than what ", '(, and #( can give, of course)
3:21:02
aeth
e.g. (defun foo () (let ((s "foo")) (setf (aref s 0) #\a) s)) ; SBCL complains, and if your CL compiler doesn't, complain to your compiler's authors.
3:21:33
pjb
aeth: (values (eql (read-from-string "42") (read-from-string "42")) (eql (read-from-string "\"42\"") (read-from-string "\"42\""))) #| --> t ; nil |#
3:22:22
aeth
pjb: "SBCL complains, and if your CL compiler doesn't, complain to your compiler's authors."
3:23:47
pjb
To be precise, (let ((foo #(1 2 3))) (setf (aref foo 0) 0) foo) is implementation dependent. But the point is that #(1 2 3) may be not immutable.
3:24:24
aeth
pjb: That's funny that you said that SBCL diverges from CL because it cites the spec in its warning, so I'm sure they've heard that criticism before.
3:26:28
aeth
pjb: Anyway, my point is that #(1 2 3) can be treated as a constant as long as it's in limited scope (usually function scope, but your LET at a top level is also detected by SBCL). Once it's passed around to some random functions doing whatever, the information is lost because it's not tagged as such. Of course, mutating can still cause issues, you're just going to get unexpected bugs on some implementations.
3:28:04
aeth
Mutating literals in SBCL, which you can do once you pass it around enough to make the compiler lose track, is a bad thing and that's how e.g. you get objects with some point-vector #(0 0 0) starting at a different spot every run instead of starting at the point (0, 0, 0)
3:29:17
moldybits
pjb: well, i want to communicate that it won't be changed, which is why i used defconstant originally.
3:29:33
loke
aeth: But mutating #(1 2 3) is undefined beahviour according to spec. SBCL could very well throw an _error_ instead of just a warning.
3:31:18
moldybits
what does +foo+ signify that's incompatible with (defparameter +foo+ 42) (or symbol-macro)?
3:31:26
loke
pjb: wouldn't that give you all sorts of problems if you try to do, say: (flet ((foo () ...)) ...)
3:33:53
aeth
(alexandria:define-constant +foo+ "foo") (setf (aref +foo+ 0) #\a) ; well, SBCL warns here, too, but it still goes ahead and turns it into "aoo", just like the function
3:37:42
aeth
define-constant is probably the best way to do it. Someone setting an element of +foo+ is doing something visually quite wrong to any informed reader, just by the +s in the name of the constant.
3:38:20
moldybits
(defparameter +magic+ "FOO") ; i'm using ++ to say +magic+ won't be bound to anything else. "FOO" won't be modified either but i don't care to communicate that.
3:44:50
aeth
moldybits: I think it's safe to use (alexandria:define-constant +magic+ "FOO" :test 'string=) for that because any non-trivial project is going to have alexandria and uiop loaded into the image already, so they're effectively free dependencies.
3:46:35
pjb
moldybits: +foo+ means that you cannot rebind it. (setf +foo+ …) and (let ((+foo+ …)) …) will fail.
3:46:57
pjb
moldybits: but with symbol macros, you cannot (setf foo …) but you can (let ((foo …)) …).
4:08:39
aeth
loke: Afaik it isn't if the symbol macro is "foo"... but it's still not ideal because you can still set elements of it with aref
4:12:59
loke
aeth: well, you wouldn't be if you defined it with DEFCONST anyway. Wasn't the point that you'd be replacing DEFCONST with D-S-M?
4:23:53
drmeister
I can get a monolithic fasl to build but it has problems loading - I'm looking for insight.
5:12:07
akater
pjb: constantp returns t for my constant. Does it still mean defconstant is useless? I also don't see any warnings even though it seems to be used in code.
5:16:06
loke
Here is a place I'm using it: https://github.com/lokedhs/maxima-client/blob/master/infoparser/infoparser.lisp#L35