freenode/#clasp - IRC Chatlog
Search
0:22:45
Bike
https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/CST-to-AST/convert-primop.lisp#L279-L280 like here for instance
0:25:02
makomo
i see, but why do those Cleavir instances need such an argument? to be able to use the instance with #'EQ somewhere, for example?
0:26:24
Bike
https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/CST-to-AST/convert-cst.lisp#L187-L188
0:31:51
makomo
i'm reading the cleavir pdf which says that, for LEXICAL-VARIABLE-INFO for example, the only property one has to guarantee about :identity is that it's (obviously) always the same object for a lexical variable of the same name
0:36:48
makomo
hm, so why not for example use that symbol as the identity? why does the user have to do it with a separate object?
0:38:31
Bike
cleavir doesn't deal with the identity at all, except for lexical variables where it put in the identity itself
0:42:58
makomo
beach: typo: p. 5, "Client code would then typically provide auxiliary methods or *overriding* primary methods (...)", http://metamodular.com/cleavir.pdf
0:43:29
makomo
beach: also note the above about the initarg being required -- old versions of the document?
8:58:38
Shinmera
drmeister: is usocket support for clasp not upstream yet or why do I get usocket:socket-listen is undefined
10:31:12
Shinmera
drmeister: https://github.com/trivial-garbage/trivial-garbage/pull/12#issuecomment-421313074
10:32:48
makomo
beach: did you see my question regarding the :identity initarg for the various *-INFO classes within Cleavir?
10:33:45
makomo
beach: i was wondering what the internal purpose of that initarg was. Bike told me that lexical variables for example use the lexical-ast as the identity
10:34:16
makomo
but i was just curious what internal purpose that serves. i was reading metamodular.com/cleavir.pdf and the only guarantee that the user has to make is that always the same object is passed as the :identity argument
10:34:41
makomo
Bike also said that Clasp never passes the :identity initarg, but cleavir.pdf says that it's a mandatory initarg
10:35:09
makomo
so the docs might be stale (or maybe the last version isn't the one that's on your site)
10:54:57
beach
makomo: It seems that if you have a local named function (with FLET or LABELS), then if you do #'<name-of-that-function> then the result of converting that form is the contents of the :IDENTITY slot.
10:56:47
beach
So that must contain the AST for the function because that is what is returned by CONVERT-SPECIAL.
11:03:31
beach
makomo: It contains the AST corresponding to the lexical variable naming the function. So when there is a #'<name> in the code, then it turns into an AST that accesses the corresponding variable.
11:08:47
makomo
i haven't seen that terminology used before though, i.e. calling NAME in that context a lexical variable
11:09:13
makomo
because, (flet ((hello () (print "hello"))) hello) will fail with the error that "the variable HELLO is unbound"
11:10:08
makomo
i've only seen "local function" until now (i guess you could also say "lexical function")
11:10:21
beach
makomo: Once the source code is translated to AST, there is no distinction between the variable namespace and the function namespace.
11:12:45
beach
But when the code is translated, the first form has F as a variable-environment and the second one has F as a function-environment. When #f is seen, Cleavir asks for a function-environment with f.
11:14:31
makomo
so, if my <- was a macro (which it will be), i couldn't code walk and look for occurences of <-, but whatever internal function that performs the signal assignment instead
11:15:28
makomo
instead i have to look for occurences to whatever internal function performs the signal assignment*
11:15:52
makomo
i phrased that badly. i can code walk, but i can't look for occurences of <-, since <- is a macro and it'll be gone
11:17:21
makomo
i guess that's ok. the DSL will just have "primitives" which are normal functions. the user of the DSL uses the macros, but my AST traverser looks for the primitive functions
11:19:03
makomo
i tried the macroexpansion solution, but i don't like it too much. once i store away the information during macroexpansion-time, i have to retrieve that information when the form is actually evaluated
11:19:29
makomo
i can't retrieve it during that same macroexpansion/compiler invocation, because i can't rely on the order of macroexpansions
11:20:09
makomo
so if i compile my DEFCOMPONENTS in one image, and try to load them in another, it'll fail. the hash tables that kept the state that was computed during macroexpansion are gone
11:22:26
makomo
e.g. DEFCOMPONENT --(expands into)--> (ensure-component-spec ... :body (lambda () <body with state-computing-macros>) ... :stuff <state-computed-by-the-macros>)
11:23:15
makomo
<state-computed-by-the-macros> will truly be available only once <body-with-state-computing-macros> is macroexpanded/compiled
11:25:03
makomo
i was reading about how Cleavir needs method definitions in order to operate on the environment
11:25:12
beach
You will need an object to represent the global environment. You can check what the Clasp people are doing for that.
11:25:21
makomo
i suppose Clasp uses Cleavir from the bottom-up and has the "leisure" of defining their own env object
11:25:55
beach
I think they must define functions on the environment that trampoline to ordinary Common Lisp functions.
11:26:14
makomo
all of the global function/macro definitions will be stored within SBCL's environment
11:26:45
drmeister
Shinmera: I added you to clasp-developers - if there are any systems that you want to access and push upstream but don't have access - just ask.
11:27:36
makomo
beach: oh hmm, that trampoline technique makes sense. what about lexical variables though?
11:28:13
drmeister
Shinmera: I pushed trivial-gray-streams upstream about three weeks ago - there is no reason to keep a fork of it now - right. It's actually counterproductive to keep a fork.
11:28:44
makomo
beach: the macroexpand-with-a-different-environment-object thing? i heard you discussing that with mraskin but i'm not sure whether i completely understood
11:28:58
beach
makomo: If you macroexpand a macro in a lexical environment and the expansion function calls MACROEXPAND, then the host MACROEXPAND will receive a Cleavir lexical environment.
11:29:27
Shinmera
drmeister: and yes, the fork will only grow outdated if the patches are already upstream
11:31:05
makomo
beach: does that concern only MACROEXPAND, or various other environment-taking functions as well? what about GET-SETF-EXPANSION for example?
11:32:29
makomo
so if GET-SETF-EXPANSION is problematic as well, this would wreck all of the place macros then?
11:33:08
beach
It is not very likely that those will be called in a lexical environment, but it can happen, yes.
11:33:34
beach
The absolute best solution would be to create a SICL first-class global environment that imports most things from the host, but that replaces those sensitive functions. I have wanted to do that for SBCL for some time.
11:45:59
beach
Bike: What if the result of expanding MAKE-METHOD were wrapped in LOAD-TIME-VALUE. Then it would be evaluated in the null lexical environment.
11:48:00
beach
That book "Common Lisp for language implementers" really has to be written. It would explain solutions like this. Not just assume that everyone knows what to do, as the Common Lisp HyperSpec does.
11:48:37
beach
Since it very likely won't be a bestseller, perhaps turning it into a collaborative project would be the way to go.
12:00:08
makomo
beach: i'm still thinking about what you said regarding that problem. so the core of the issue is that a local macro will receive a Cleavir environment as its &environment parameter?
12:03:42
makomo
SETF will use GET-SETF-EXPANSION and pass the environment and that would fail somewhere within the internals of GET-SETF-EXPANSION i suppose?