freenode/#lisp - IRC Chatlog
Search
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
8:49:41
flip214
drmeister: I heard that (at least SBCL) allows to just "cat" FASLs together -- that would give one monolithic file, too.
9:07:37
splittist
shka__: see also the *-bundle-op ASDF operations (and relatives) e.g. monolithic-compile-bundle-op
9:41:11
schweers
(swank:create-server) returns immediately, does anyone have an idea why? This is regardless of whether I specify :dont-close or not. I have a shellscript which calls sbcl like this, which works:
9:41:11
schweers
sbcl --dynamic-space-size ${HEAPSIZE} --eval '(asdf:load-system "swank")' --eval "(swank:create-server :dont-close t :port ${PORT})"
9:42:09
pjb
schweers: swank server may run in the background, depending on swank:*communication-style*
9:55:26
schweers
How that I’ve loaded swank via asdf, the dumped executable seems to no longer work on another machine. I’m probably missing something really obvious, can anyone point me in the right direction?