freenode/#clasp - IRC Chatlog
Search
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?
12:05:13
beach
MichaelRaskin hinted that his code walker can deal with this situation, but he utterly failed to explain to me how.
12:05:49
makomo
yeah, i heard that as well, but i also didn't quite understand what he was trying to say. some trickery and heuristics is what i remember
12:06:46
beach
You could replace the host functions get-setf-expansion and macroexpand-1 by a function that first checks if it is a cleavir environment and if so, calls a cleavir-specific version, and if not, calls the old function.
12:10:16
makomo
hm yeah, and that should be portable across implementations right (aside from the fact that it's already UB since you're modifiying the COMMON-LISP package)?
12:19:39
beach
Wow, I am *so* pleased I made progress on MAKE-METHOD and CALL-METHOD. Now I can clean up the rest of the code and continue with my bootstrapping effort.
12:31:43
drmeister
The problem with trivial-garbage is this test: (deftest pointers.1 (weak-pointer-p (make-weak-pointer 42)) t)
12:40:03
Shinmera
Surely you can put fixnums on the heap, so why can't you make a weak pointer to one?
12:43:10
beach
The point of weak pointers is that when all other references to an object go away, then the weak reference will no long refer to the object, so it can be garbage collected.
12:45:11
pfdietz
makomo: to answer your question of yesterday: the information in the macro environment is used when expanding other macros. Think of this as happening at compile time.
12:52:08
Shinmera
The implementation can just allocate a word on the heap, put the immediate there and give you the pointer to it.
12:52:55
Shinmera
I agree that I don't see why one would want a weak pointer to an immediate, but I also fail to see the problem with implementing it