libera/#sicl - IRC Chatlog

8:42:41 beach The ctype library calls CLASS-NAME, but it's the wrong CLASS-NAME in terms of SICL bootstrapping. It should call CLASS-NAME in the previous environment. Of course, ctype was not designed for SICL bootstrapping, so I have to make it work as it was designed. Plus, this issue will happen with other libraries as well.

8:42:57 beach Perhaps what I need to do is to somehow associate the function cell for CLASS-NAME in Ei-1 with the name CLASS-NAME in Ei, temporarily for loading ctype. But we do not have that functionality in Clostrum.

8:43:17 beach Such functionality will be required later on anyway, because we would want to share function cells between several Clostrum environments.

8:43:28 beach For example, imagine a Clostrum environment E1 meant to hold the code for some library that implements some function F that is used in other environments E2, E3, etc. We don't want to install the function object in a separate cell in E2, E3, etc., because then if the library is reloaded into E1, the old definition of F will still be in E2, E3, etc.

8:43:29 beach We would want the function cell holding F in E1 to be the same cell that holds F in E2, E3, etc.

8:48:07 beach With a properly defined Clostrum protocol for this issue, I think I could get rid of the rather ugly naming kludge I currently have to do, like calling a function F-1 in environment Ei when F should be called instead, and then defining F-1 in E to be F in Ei-1.

8:50:59 beach I need to think about this a lot more, but it seems that ENSURE-OPERATOR-CELL should create a cell and then call an even lower-level function like INSTALL-OPERATOR-CELL, the latter being part of the new protocol.

8:52:52 beach There would also have to be an UNINSTALL-OPERATOR-CELL and probably some macro like WITH-OPERATOR-CELL that saves the old cell, installs a new one, executes some code, then re-installs the old cell.

12:48:24 beach Or should the sharing be at the operator-entry level?

12:51:18 bike i've been working towards making ctype generics client-based again. i could put in something to let you specialize class-name to do whatever.

12:51:35 bike of course that won't help you with other libraries, like you said

13:01:24 beach Thanks, but you probably shouldn't bother. I need to solve this problem more generally. And it will make the code less obvious to understand.

13:02:31 beach Now that I think about it, the sharing should probably not be at the operator-entry level, because the function could be inline in one place and not in another place. And it could have a compiler macro in one place and not the other. Etc.

13:03:41 beach So if the sharing is at the cell level, then step one would be to make the CELL slot have a slot accessor rather than just a slot reader.

13:23:53 beach bike: Any opinions about this sharing idea?

13:38:26 bike sharing cells i can understand... but you also need to temporarily change cells? i've been thinking of cells as kind of constant - i mean their contents change, but an environment only ever has one cell for any binding

13:39:19 beach Here is the use case in more detail:...

13:41:22 beach Environment Ei contains the slot reader CLASS-NAME. Since it is in Ei, it takes as an argument a class "in Ei+1". But ctype and other libraries don't make that distinction. So when I load ctype, I need for it to find the cell that is related to CLASS-NAME in Ei-1. But that's just temporary, because other functions use CLASS-NAME of Ei to take a class in Ei+1.

13:41:55 beach There is no way to make everything mean just one thing.

13:42:43 beach Otherwise, I could make CLASS-NAME in Ei take a class in Ei, but the MOP is completely mixed up this way, so a decision has to be made that doesn't work for every use case.

13:44:41 beach So I need for CLASS-NAME in Ei to be associated with a cell in Ei-1 only during the loading of ctype and other similar libraries.

13:45:53 beach A good example of how "mixed up" things are is the issue with the slot-based functions I mentioned the other day.

13:51:29 bike do you need to actually share cells, or could you accomplish this just by temporarily redefining class-name in whatever environment to be the same function?

13:51:42 bike i mean ctype isn't going to setf fdefinition on class-name, or anything

13:52:44 beach I think I need the cell, because the function is not called when ctype is loaded; only when it is executed. So if I change the contents of the cell back to what it originally was after ctype is loaded, I still get the wrong function.

13:55:47 bike i see... that's very tricky.

13:56:24 beach Indeed. And the main problem with SICL bootstrapping is about managing tons of those situations.

13:58:31 beach That's how I ended up defining the concept of "refinement" and how I made the decision that operators of refinement R operate on objects of refinement R+1. As much as the MOP will allow, that is.

14:29:38 beach bike: So, given this additional information, do you have any more opinions?

14:30:34 beach I am asking because you often see things that I miss.

14:53:51 bike I suppose the other thing I'm wondering is if you couldn't interpose a child environment for the compiler instead of mutating one environment. Like say you have environment E that is mostly correct but has the wrong cell/definition for class-name. Maybe you could make a child E' that just has the right class-name cell but otherwise defers to the parent.

14:54:12 bike You'd still need a cell sharing mechanism, but you could keep the invariant that an environment only ever has at most one cell for a binding.

14:54:39 beach That's an interesting idea. I will contemplate that. Thank you.

14:55:47 bike sure thing

19:07:04 edgar-rft_ ** NICK edgar-rft