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