libera/#commonlisp - IRC Chatlog
Search
14:11:36
nick3000
Does lisp have anything like C++ const variables? I'd like to declare a global constant object that would cause an error if an attempt was made to modify it.
14:11:51
nick3000
I find if I use defconstant I can still modify the object using incf/decf for example.
14:12:40
nick3000
That's an example, MACHINE-WORD is a sequence of bytes in a VM, I'd like to not be able to incf/decf.
14:13:49
Bike
there's no operator that makes it an actual error. since in lisp we don't have everything compiled at once like in C, there would have to be a runtime tag of some kind on constant objects, and every modifying operation would have to check it
14:14:44
beach
I have always wondered how static languages do things like that. Do they put the object in read-only memory?
14:15:54
beach
Maybe I should do something like that in SICL. There is nothing preventing me from having a separate read-only global heap.
14:16:08
Bike
the C and C++ standards mandate the compiler output a diagnostic message if you have code that could modify a constant. i don't know if t here's any requirement on the runtime
14:16:40
Bike
oh yeah, here we go. "Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior. "
14:17:35
Bike
yes. i don't know about C. i don't think C has anything like const_cast, so it may be impossible to construct code that modifies a const object unless you do other standard violating things like out of bounds pointer arithmetic
14:19:36
Bike
it says undefined behavior, at least according to cppreference, which is usually alright
14:19:38
nick3000
But I have many many times done stuff like that in C/C++ and you will get a segfault.
14:19:46
_death
Bike: you shouldn't modify const objects in either case.. there is a distinction between const objects and const references/pointers
14:19:50
Bike
i suppose the difference is that I think the C++ standard mandates a warning of some kind
14:21:16
_death
Bike: so if you have a const reference to a nonconst object, you can use const_cast in C++ and an ordinary cast in C
14:24:58
jcowan
same story in C, it just doesn't use "const_cast". If x is a cnst int, then (int)x is a version that has cast away constness, and if you mutate it, boom, dragons out your nose.
14:27:58
_death
jcowan: in C, the following has well defined behavior: int foo = 42; const int *bar = &foo; *(int *)bar = 24; /* now foo == 24 */
14:29:33
jcowan
Yes, if the const int is underlyingly an int, you're fine. I was talking about the case where you have a "native" const int and you cast it to be an int.
14:34:17
_death
if you had const int foo = 42; then int *nonconst_bar = (int *)bar; is still OK, but *nonconst_bar = 24; gives way to the demons
14:36:32
_death
nick3000: in Lisp, defconstant is basically for simple objects like symbols and numbers.. what it says is that the binding should not be changed
14:37:19
nick3000
Right, I was just hoping for something like in C/C++ where _much_ of the time, if you modify it, somehow, things come crashing to a halt, mostly as just an additional stupid-check.
14:38:22
pjb
defconstant is a compiler hack. It says that the compiler may use the value literally, as immediate value in the generated code.
14:38:28
_death
nick3000: if we want to prevent modification, we use documentation to tell the user not to do that.. if we want to go further (prevent accidental modification) we can simply hide the object and provide a controlled interface to it, that allows only read
14:38:50
pjb
Since most lisp values are references, it doesn't make sense to put them as immediate values in the generated code (an address?!).
14:39:25
pjb
So it applies only to numbers and symbols, and even, most numbers cannot be stored as immediate value (no processor I know support complexes or bignums as immediate value in the code!)
14:40:24
pjb
So I'd say that for the programmer, defconstant is not very useful. The only feature that could perhaps be used, is that you cannot bind (locally) a constant variable. But I find it more a bother than an advantage.
14:40:54
pjb
For example, I define the ASCII control codes as constants. So now I cannot do (let ((ht (make-hash-table))) …) anymore :-/
14:41:47
jcowan
But I'm happy with (defconstant table = '((us . "United States) (de . "Germany") ...))
14:41:51
pjb
define-symbol-macro is more interesting. You can do lexical global variables with them, and all kind of magic, and you can shadow them in a local lexical binding.
14:42:21
pjb
jcowan: until there's a new country, or some country doesn't use it's standard abbreviation.
14:43:10
pjb
jcowan: for example, I noticed that Mongolia doesn't use its iso3166 cod in sports, but another abreviation…
14:43:27
pjb
jcowan: so if you write an application is some domain, you may want to patch this database!
14:43:47
jcowan
Throwing away the image and starting over is always an option for Maclisp descendants.
14:44:39
_death
surely there are machine readable databases of such information that are publicly available and can just be read at runtime
14:48:27
jcowan
But they are typically available as text files (or, Ghu help us, SQL Server databases you can download).
15:59:41
Colleen
Clhs: accessor symbol-value http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm
16:03:54
beach
That depends on your definition of "correctly". With my definition, you need a code walker.
16:05:02
beach
jmercouris: The standard doesn't cover everything you need, but every implementation obviously has what it takes.
16:05:48
beach
jmercouris: That's why yitzi suggests a "compatibility library" that abstracts out what each implementation does.
16:06:25
yitzi
I do some it myself it here without trivial-cltl2 https://github.com/yitzchak/common-lisp-jupyter/blob/master/src/cl-jupyter/utils.lisp
16:10:09
beach
That's why we plan to use Eclector's capability of producing CSTs (which contain source information).
16:10:31
yitzi
I don't syntax highlighting in common-lisp-jupyter, but I do use eclector for symbol completion and inspection.
16:12:19
beach
My plan was to use Cleavir for that, but it looks like scymtym is going to do some work, and I don't know his plans.
16:13:47
beach
Then if you use a code walker, you may get errors from it with respect to special forms.
16:14:25
beach
And if someone writes cl::hello, you may want to prevent the symbol from being created in the Common Lisp package.
16:15:34
beach
So the plan is to configure Eclector to not intern symbols in the normal host packages, and to have Eclector recover from various reader errors.
16:16:53
beach
Plus, a paper we wrote documents the use of the reader incrementally, so that you don't have to re-read the entire buffer after each keystroke.
16:19:57
beach
jmercouris: I did start using Nyxt today. Not yet exclusively, though. Still learning.
16:21:55
scymtym
here is a prototype with some of the properties beach mentioned (using Eclector for the character-level syntax, not interning anything, code-walking for semantic highlighting): https://techfak.de/~jmoringe/semantic-highlighting-1.png https://techfak.de/~jmoringe/semantic-highlighting-2.png
16:22:26
blihp
beach: are you able to use it from your default setup (I assume lisp/slime)? It was giving me all kinds of problems until I just started a sbcl instance just for it from the command line
16:29:13
scymtym
beach: mostly just the expression syntax library. combined with code to track the current package and other state in a chain of environment objects
16:29:20
Josh_2
beach: https://plaster.tymoon.eu/view/2483#2483 thats the code, taken from aartaka and modified ofcourse, for future reference :P
16:32:48
beach
Solving the problem requires an implementation of the reader algorithm that allows client code to configure what happens when a token is about to be processed. And that's what Eclector is.
16:38:29
beach
jmercouris: You should watch that movie to get an idea of the complexity of the problem. :)
16:46:27
scymtym
beach: thanks. i have a plan at least. i ultimately want to combine the incremental parsing of Second Climacs with the s-expression parsing and environment stuff
17:04:21
jmercouris
beach: nice! That’s cool! Hopefully you won’t cringe too hard when you look at our code :-D
17:24:56
jcowan
I once saw code in which a 100 element array was initialized to 0 with 100 assignment statements. Written by a consultant.
17:35:27
yitzi
Did you ask him where he learned how to do that? I would just die if said he copy-pasted it.
17:50:30
pjb
jcowan: /* (dotimes (i 10) (insert (format "a%d = 0; " i))) */ a0 = 0; a1 = 0; a2 = 0; a3 = 0; a4 = 0; a5 = 0; a6 = 0; a7 = 0; a8 = 0; a9 = 0;
19:05:50
knusbaum
Hi, everyone. I'm playing with implementing a very simple swank server, but I'm having trouble finding good documentation about the various RPC calls.
19:06:10
knusbaum
My current issue is that SLIME seems to call swank:autodoc with a bunch of previous buffer contents including prompts. I'm not sure how to tell emacs that the previous buffer contents should be ignored.
19:07:32
knusbaum
No, Emacs/SLIME is issuing an RPC call I consider "weird", and I assume that's because I'm doing something wrong on the server side.
19:09:54
knusbaum
That could be. From (swank:connection-info) I return :modules ("SWANK-ARGLISTS" "SWANK-REPL" "SWANK-PRESENTATIONS")
19:10:45
phoe
still, regarding all the various rpc calls, I don't know of any good documentation that isn't "ask a person knowledgeable in the topic"
19:10:48
knusbaum
That's why I'm wondering if I need to be sending other requests to the client like (:clear-prompt) or something.
19:11:13
phoe
and the latter would be, I guess, asking luis and/or Joao who is knowledgeable in the ways of slynk/sly
19:13:48
phoe
I guess that, as a last resort, you could try to make a forum post at https://github.com/joaotavora/sly/discussions
19:14:35
phoe
(since that's where joao asked me to point people to if they have any kind of sly questions, and I guess that questions about the rpc protocol are borderline on-topic there)