10:34:16makomobut 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:54:57beachmakomo: 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:47beachSo that must contain the AST for the function because that is what is returned by CONVERT-SPECIAL.

11:03:31beachmakomo: 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:12:45beachBut 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:13:06beachBut looking at the resulting AST, you can't tell the difference.

11:19:03makomoi 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:29makomoi can't retrieve it during that same macroexpansion/compiler invocation, because i can't rely on the order of macroexpansions

11:20:09makomoso 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:33:08beachIt is not very likely that those will be called in a lexical environment, but it can happen, yes.

11:33:34beachThe 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:59beachBike: 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:00beachThat 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:37beachSince it very likely won't be a bestseller, perhaps turning it into a collaborative project would be the way to go.

12:05:13beachMichaelRaskin hinted that his code walker can deal with this situation, but he utterly failed to explain to me how.

12:05:49makomoyeah, 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:46beachYou 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.

13:48:40Bikebeach: as far as i know, the identity of variable and function infos is only used for lexical infos that cleavir makes itself. identities for global infos, which are created by the client, are unused

13:49:44stassatspfdietz: perhaps you read about something like mips with cheneygc

13:50:11scymtympfdietz: there is a thread-local allocation region data structure consisting of a fill-pointer-like value that is incremented and an end-pointer against which the fill-pointer is checked for overflow. overflow of the allocation region triggers an out-of-line handler

13:52:48pfdietzAnyway: if clasp is looking for optimization opportunities, speed of CONS is one of them. (loop repeat n collect 1) is about 6x faster in SBCL.

13:55:26Bikethere is unfortunately arithmetic timing involved there as well

14:14:12Colleenkpoeck: drmeister said 16 hours, 8 minutes ago: I'd like to incorporate the tests you have developed into the CI framework that I'm developing. I have clasp and cando building using 'buildbot'. What do you think?

15:04:38makomopfdietz: here's the relevant code http://plaster.tymoon.eu/view/921#921. perhaps another layer of macro indirection can fix it? wouldn't that be relying on the order of macroexpansion though?

15:04:53pfdietzThe "sorts" of pattern variables were declared in a surrounding form

15:09:45pfdietzPassing information upwards would involve a different mechanism: the surround macro would have to fully expand <body>, then walk over the expansion to pull out things the lower macros had stashed there.

15:18:33makomopfdietz: why does the outer macro have to walk the body's expansion? can't the local macros within body communicate information via some global state (as i'm doing with hash tables)?

15:23:44pfdietzBecause in normal macroexpansion, the outer macro is expanded before the inner ones. The outer macro's function is going to have to "manually" cause its parts to be expanded "early" if it wants to get any results of those expansions before it is done expanding itself.

15:29:39makomopfdietz: the walking i was thinking of was the one you said happens *after* the manual macroexpansion. once i expand the body, why do i have to walk the body? is that just one of the alternatives (and the other is using global state)?

15:30:20makomoyou said "(...) the surround macro would have to fully expand <body>, then walk over the expansion (...)"

15:30:40drmeisterIt's easy to add non-AWS workers, save build products, chain builds and add tests. I'm interested in discussing what we should do with these new CI capabilities.

15:32:21pfdietzThe macro expansion function for the outer macro needs to get some results computed by macros inside its body. Those results are not yet computed. The outer macro's function needs to explicitly cause those inner macros to be expanded if it wants those results. This will be done by walking DURING expansion of the other macro: that outer macro function will explicitly call a code walker to expand the macros in its body. There

15:32:22pfdietzwill be another pass over that code afterwards, by the normal expansion process, but by that time all the macros will already have been expanded so that will be a no-op.

15:33:28pfdietzThis is not clasp related, so perhaps it should be moved to #lisp