libera/#commonlisp - IRC Chatlog
Search
14:10:30
edgar-rft
the more interesting thing is that when I evaluate (let ((gong 42)) (defparameter gong 50) gong) for the first time, when no special var gong exists, it returns 42, while from the second time on it returns 50
14:13:27
edgar-rft
but shouldn't gong be declared special already after (defparameter gong 50) in the first evaluation, I mean the return value, not in the let binding
14:14:00
phoe
edgar-rft: the proclamation happens after the compiler infers that GONG refers to a lexical variable
14:14:25
phoe
the second time this code is compiled, the compiler knows that GONG is globally special
14:14:45
phoe
the confusion happens because there are actually two variables in play here: a lexical one named GONG and a dynamic one named GONG
14:16:15
edgar-rft
but in (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong) the declaration also happens *after* the let binding and it returns 50 at the first try
14:19:39
edgar-rft
so (declare ...) is considered at an earlier time than (defparameter ...) in the compiler?
14:20:21
edgar-rft
phoe: I'm talking about (let ((gong 42)) (declare (special gong)) (defparameter gong 50) gong)
14:21:22
_death
edgar-rft: the defparameter form is not a top-level form, so the compiler may not recognize it
14:22:36
edgar-rft
but I have to read the spec to make sure I understand what I am talking about :-)
14:24:05
Guest63
"Constructs that use lexical scope effectively generate a new name for each established entity on each execution. Therefore dynamic shadowing cannot occur (though lexical shadowing may). This is of particular importance when dynamic extent is involved."
14:24:29
_death
there was discussion about top-level bindings yesterday.. recently I looked at the chinual (for a reddit comment) and also noticed there was a LET-GLOBALLY operator
14:25:27
_death
which may be similar to what people nowadays call LETF.. but maybe had some difference with regards to this specific case
14:32:42
scymtym
we worked a little bit on the process for creating WSCL (which beach mentioned above). in case anyone wants propose a clarification regarding non-toplevel DEF{VAR,PARAMETER}, a pull-request that fleshes out https://github.com/s-expressionists/wscl/blob/main/wscl-issues/proposed/DEFPARAMETER-NON-TOPLEVEL-SEMANTICS would be welcome
14:38:19
scymtym
_death: yes that's wrong. the file is meant as a starting point which illustrates the format. to be honest, i didn't follow the discussion closely since i'm focusing on the infrastructure. it's just that having such as discussion without writing down any insights seems like a waste
14:52:42
_death
scymtym: well, I'd expect the first form to return (3 1) .. don't see how it could return (2 2) since there's no lexical binding there
14:57:46
scymtym
i think i wanted to write (2 3) but i rushed it a lot to have an example ready. the point is, why not write down different possible behaviors and the respective pros and cons as well as the behavior of existing implementations
15:42:17
_death
I don't think I ever used non-toplevel defparameter/defvar.. are there any known uses in the wild
15:46:09
jackdaniel
_death: LETF (at least in mcclim codebase) is a "let for places" - that of course breaks for multi-processing code, but it is ~ (let ,remember-old-vals (unwind-protect (progn (setf ,@store-new-vals) ,@body) ,@restore-old-vals)
15:51:34
_death
jackdaniel: right.. unlike letf, it was unaware of places.. but it did set variables.. re-reading its description, I guess it had more to do with stack groups
15:53:13
jackdaniel
funny break scenario for climi::letf is trying to bind the unbound slot (something that could be worked around if really necessary)
15:58:57
_death
there are other funny facts with LML.. e.g., it had defvar but its defparameter-like was called defconst.. the case-like operator used to be called selectq (the q meant the keys were not evaluated) and there was an evaluating case called select (and also selector, which let the programmer specify the comparison function).. sometimes it looks like CL has simplified operators that were gnarly in LML
16:01:33
_death
well, an alias, but it existed for "maclisp compatibility", though it was different from maclisp's :)
16:19:38
Bike
i'd just write it yourself and if it turns out to be in a utility library all the better
16:41:49
jackdaniel
otoh doing it that way may invoke unnecessary protocols (because it always modifies the place) - the same problem would apply to reverse-orf I think
16:46:05
_death
a reverse-orf thing (there must be some proper word to describe the operation :) could also avoid evaluating parts of the place if the value is nil
16:49:00
_death
maybe less surprising if the order of evaluations is reversed, like in PUSH.. (stamp value place)
22:06:30
jmercouris
anyone know of any attempts to create a 'visual' programming interface for lisp?
22:07:08
jmercouris
of course it would be a new language, but borrowing as many concepts from lisp as possible
22:10:59
jmercouris
this looks really intense, I think I could tone it down and provide some of the same concepts more approachable for beginners
22:44:02
hendursaga
jmercouris: blockly is pretty good, although you'd want to wrap it some, it's pretty old JS
22:47:18
luis
There's one such library where you can switch between text and blocks seamlessly. I forget its name