libera/#commonlisp - IRC Chatlog
Search
16:34:33
beach
The way I see things is that special variables come with a stack of "things", where each entry in the stack has a value or a marker indicating that there is no value there.
16:35:12
beach
The glossary suggests "binding", but that is inconsistent with MAKUNBOUND and BOUNDP.
16:36:05
beach
But then we have a problem that a "special variable" is a not a variable, but a stack of variables.
16:36:48
pjb
(and it's multiple stacks, one for each thread, unless the thread access a global stack).
16:37:34
beach
Nilby: An environment is way more than a single association between a single symbol and a single value/no-value-marker.
16:38:11
pjb
I think "variable" can recover both a single slot, or a stack of them or more complex storage forms.
16:38:51
pjb
Also, temporary dynamic bindings can be implemented using the same slot, but saving and restoring the value on the execution stack.
16:39:25
pjb
I think we'd need a formal specification of CL. Terminology can be deduced from the formal notions.
16:42:05
beach
So then we must accept that (setq *x* 234) does not alter the current binding of *x*)
16:42:45
beach
Because if it was preceded by (makunbound '*x*) then it doesn't HAVE a binding to be altered.
16:45:01
_death
I would say that special variables always have a binding.. makunbound merely sets the value to a marker
16:45:54
edgar-rft
here's howto export a binding -> https://res.cloudinary.com/ratebeer/image/upload/w_250,c_limit/beer_8237.jpg
16:48:03
_death
and boundp tests for (i) does it have a binding (ii) if it does, is the value this marker
17:11:26
_death
the question is, I guess, from this implementational model, how do we abstract to create good wording for the language specification
17:13:01
_death
in ordinary CL conversation we say that (defvar *x*), without prior reference to *x*, marks *x* as a special variable, and that this special variable is unbound
17:39:14
White_Flame
looking at the disassembly, it's only checking the low byte tags for #x09. I wonder what the rest of the word implies
17:41:08
White_Flame
(and obviously the #x50100109 is not a "value" in the lisp sense, but rather a specific machine word encoding here)
17:46:28
Nilby
Yes. Not very important to know, but at least now I can see that unbound things might look like dark red when I scroll through memory as pixels.
20:36:07
Michal
Does anybody have any recommendations for machine learning libraries in Common Lisp?
20:44:03
Qwnavery
It's a hard one because I'm unaware of any ML projects that have GPU accellerated support
20:46:28
Michal
I thought it was much faster than Python, but I heard Python had an optimised library via numphy
20:46:55
Michal
What's CUDA? I'm very new to all of this. I just finished Andrew Ngs course and wanted to try stuff out
20:53:00
Qwnavery
Michal: cool, to get started with CUDA you'll need the Proprietary Nvidia CUDA drivers https://developer.nvidia.com/cuda-downloads
2:34:43
sukaeto
late to the conversations, but I (think I) understand what beach is saying re: binding
2:36:03
sukaeto
they sometimes use it the way a compiler writer would - as in "this variable is bound to this value"
2:36:28
sukaeto
they also use it in the logical sense - as in "this variable is not free in this form. It is bound."
2:39:20
sukaeto
in the second sense, you're saying the variable is bound by the *context*. (progv '(*x*) () (boundp '*x*)) <- *x* is bound in the sense that it won't be susceptible to variable capture, no matter where that progv is put