libera/#lisp - IRC Chatlog
Search
17:53:15
pjb
francogrex: with ccl, creating a hash-table with 1 million keys (integer 0 999999) --> took 714,570 microseconds (0.714570 seconds) to run. 57,414,112 bytes of memory allocated.
22:00:38
ayjay_t
so im getting undefined variable warnings on every single variable I defined with setq hmmm i feel like that's weird since i'm defining htem
22:01:57
moon-child
in common lisp, special variables may be defined with defvar or defparameter, and lexicals variables may be bound in a number of ways, but typically with let or a function definition
22:02:51
wasamasa
like, maybe you typo'd the name and ended up setting something unrelated, rather than the intended variable
22:07:05
muurkha
setq on an undefined variable is just a warning in SBCL; afterwards the variable is defined
22:09:39
muurkha
it would be nice in many cases to make it an error to define an already-existing variable (as opposed to setting it), though that's not really harmonious with image-based interaction styles
22:10:07
muurkha
in SBCL defvar instead silently ignores your new definition, treating it as a default. I'm not sure when *that's* useful
22:10:23
muurkha
in Guile (and I think most Schemes) it's actually an error to try to set! a variable that doesn't exist
22:11:28
muurkha
I guess having a defvar redefinition ignore your new initial value is sensible since you might have setqed the variable in the meantime
22:11:46
muurkha
and you'd like to be able to reload your Lisp definitions without losing your current program state
22:11:53
edgar-rft
defvar does nothing if the variable was already defined before, only defparameter sets a new value on existing variables
22:12:48
muurkha
in Scheme (define x 3) overwrites whatever x's previous value was, like defparameter
22:13:38
muurkha
but defparameter also makes the variable dynamically scoped, which might be undesirable in many cases
22:19:02
edgar-rft
lexical variables are removed by the compiler whenever possible, so it makes very little sense to have lexical global variables
22:21:14
muurkha
in C, Scheme, Python, etc., I can define a global variable called "word" and use it inside a subroutine, without worrying about whether that subroutine's caller might also have a local variable called "word" used for something totally different
23:24:52
moon-child
muurkha: the convention is to define specials with *earmuffs*, so you should not accidentally stomp on one
23:26:30
moon-child
muurkha: there is this hack: (let ((global-holder (list init-value))) (define-symbol-macro -the-global- `(car ',global-holder)))
23:27:36
moon-child
errr apparently symbol-macro expansion is not evaluated. So either eval the d-s-m form, or something like (defconstant +global-holder+ ...) (define-symbol-macro -the-global- (car +global-holder+))
23:31:33
muurkha
it's useful to evaluate the form (gensym) every time it occurs, even though it doesn't take any parameters, so why not other things?
23:39:49
muurkha
if you follow that sense of it being a bad idea very far, you end up at syntax-rules or syntax-case.
23:41:02
muurkha
hacking pointers to shared anonymous variables into your source code is not the only possible use for such a thing ;)
23:43:59
muurkha
your example above is an interesting one, but others might include expanding to something that depends on which package is being compiled (assuming your compiler has some way to find out), looking at the compilation environment to see whether you're inside of some kind of problematic context, implicitly capturing a lexically enclosing transaction context, and so on
23:44:54
muurkha
in Python (the CWI one) there's a super() whose semantics depend on which class it's being compiled lexically inside of
23:46:14
muurkha
as it happens in that particular case it does take (optional) parameters, so an ordinary macro would work fine
23:47:21
muurkha
basically it comes down to defining "variables" that extend the language semantics in some nontrivial way