libera/#commonlisp - IRC Chatlog
Search
16:01:50
beach
2. Keep "bound" to mean "has a value", but introduce a new term for what we now call a "binding".
16:08:39
beach
The glossary does not mention "having a value" in association with "bind", "bound", "binding", so that suggests solution 1.
16:08:59
Nilby
How about accepting that natural language is imprecise and adding a denotational semantics definition like scheme?
16:11:27
Nilby
beach: I know. It makes my head swim to to think of it for all of CL. Even the scheme version is challenging.
16:11:37
beach
MichaelRaskin: There is no glossary entry for "bindings". Do you mean for "binding"? For lexical variables, they are the same.
16:11:45
MichaelRaskin
I have an impression that mentioning the remaining variables being bound (which is against the glossary definition, which asks these names to denote something, which they don't withing dynamic extent) is just so that «bindings are undone» covers them
16:12:24
MichaelRaskin
beach: I mean entry for «binding» that gives examples of different kinds of bindings
16:13:49
MichaelRaskin
The spec for progv says «The bindings of the dynamic variables are undone on exit from progv.»
16:13:59
Nilby
Also it's not clear how useful denotational semantics is to anybody, since I and many others wrote a scheme without looking too much at it.
16:14:55
MichaelRaskin
This seems to cover the variables that are deprived of their values for the dynamic extent of progv
16:16:01
MichaelRaskin
I am not yet suggesting, I am trying to understand why the phrase «bound and then made to have no value» was written
16:16:21
Nilby
I agree there's more to it than just being bound and unbound which it would be nice to have a precise term for.
16:17:22
beach
If it has no value, then makunbound did not undo the binding introduced by the inner LET.
16:18:57
beach
_death: Exactly, so the PROGV page says *x* is still bound, but BOUNDP returns false.
16:19:56
MichaelRaskin
Technically speaking. doesn't «then made to have no value» have power to also make the variable unbound there?
16:20:00
beach
_death: If that is what you think, you have to invent a new term for what (let ((*x* 234)) does
16:22:09
_death
beach: why? it binds *x* to 234.. I am saying that you're right there's a distinction missing.. the progv form creates a binding with the value being a marker
16:22:15
beach
MichaelRaskin: Only if you accept that "to be unbound" does not mean "has no binding".
16:23:17
MichaelRaskin
[in the current extent and scope]» meaning «has no binding [accessible in the current extent and scope]»
16:23:55
beach
MichaelRaskin: But the binding is accessible. You can do (setq *x* 234), and it affects that very binding.
16:25:13
Nilby
LET just doesn't allow the trick that progv does, but one could imagine or make a LET that allowed you to make something locally unbound.
16:25:13
MichaelRaskin
In practice makunbound doesn't seem to do anything to the lexical binding. Which might be a bigger question than whether progv specification is too sloppily worded
16:26:37
pjb
Perhaps the problems comes from the difference between variables and slots, and the fact that dynamic variables use the symbol-value slot (or at least, the symbol-value operator).
16:27:58
pjb
Yesterday I described varname : [*]--> value saying that the symbol varname named the variable [ ] (a slot) and the binding is the arrow *--> between the variable (or slot) and the value.
16:29:17
MichaelRaskin
Just LET. I am not sure if by the letter of the standard it should work. In practice it does.
16:29:20
pjb
I think the spec of PROGV uses "bound" incorrectly in "the remaining symbols are bound and then made to have no value." they mean that the variables named by those symbols are created, and made unbound.
16:30:52
beach
pjb: But that is unfortunate, because then (let ((*x*)) does not "create a binding" but it "creates a variable".
16:31:13
MichaelRaskin
Specification of MAKUNBOUND is vague enough that I am not sure how to deduce from it that it only affect special variables
16:31:50
beach
MichaelRaskin: That is entirely possible, but I can guarantee you that that is what is meant, since the name of the variable is evaluated.
16:33:21
pjb
Notably any unbound slot or variable, still exists. There's some place designated by the slot accessor or the variable name, that can be assigned a value, ie. bound to it.
16:34:17
pjb
For me, the binding is the *--> arrow, not the : association between varname (or slot place form) and [ ] the actual box where the reference to the value is stored.
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