freenode/#sicl - IRC Chatlog
Search
4:36:24
beach
I just thought of something related to what I just mentioned to drmeister in #clasp. For Second Climacs, I want to implement "incremental" first-class global environments, i.e. I want an environment to be implemented as a list of deltas applied to some big base environment.
4:37:06
beach
That organization will allow us to define each top-level form in a consistent environment, and the possible modifications that the processing of such a form can cause will be kept in a delta.
4:37:53
beach
So, when there is a modification to the editor buffer, we can "back up" to get the same environment as before for processing the modified top-level form and the ones that follow.
4:40:22
beach
Just the way we separate function cells from symbols in first-class global environments, couldn't we extract the "slots" of a readtable and put them in the first-class global environment?
4:40:51
beach
I am currently going through the various functions applicable to readtables to see whether that would be possible.
4:43:49
beach
I mean, it is certainly possible to do it. But I need to think of an implementation that will make it fast enough.
4:48:08
beach
Let's go through each feature related to readtables as indicated here: http://www.lispworks.com/documentation/HyperSpec/Body/02_aa.htm
4:49:41
beach
There are sufficiently few of them that they don't create a problem, even when the readtable is copied. Plus copying a readtable is not a common operation.
4:52:59
beach
What I do for environment functions like FDEFINITION is that this function just trampolines to a generic function that takes the current environment as a required argument.
4:53:51
beach
And then I implement them by side-effecting the environment instead of the readtable object.
4:54:51
beach
So if the environment has a list of deltas in it, a modification to the current readtable will be implemented as a side effect to a small delta environment. And it can be backed out by removing the first delta on the list.
7:13:29
jackdaniel
shka__: how do you imagine library working on a very specific environment implementation to work as a "general library"?
7:43:51
shka__
jackdaniel: i was under the impression that the second climacs is portable, and therefore it would not be "very specific environment implementation"
8:01:39
jackdaniel
beach: do you mean that climacs will maintain its own environment implementation alongside the implementation it runs on, or that climacs will depend on a specific env representation provided by the underlying implementation?
8:07:57
scymtym
the general theme is having portable, reusable modules for the reader, for environments, maybe for symbols and the package system and using those everywhere: in editors, in static analyzers, in SICL
8:09:21
scymtym
beach: i'm doing something similar for tracking (some of the) state that is relevant to the reader such as the current package
8:52:48
beach
shka__: I would have to turn the SICL first-class global environments into a separate library first.
8:57:04
splittist
Which is what the mainstream of editors / IDEs are incorporating (again) these days
8:58:48
splittist
shka__: I think you are correct that the api for using all this functionality is going to be very different, and it will probably take quite some time to work out the best way to present it to extension-writers, as it were
8:59:48
shka__
splittist: further more, you would be able (I think?) to make you program work in a separate env, fork this env, modify the env, rollback the env
9:08:28
beach
I don't think we will realize all the possibilities until we have something to play with.
13:04:47
Bike
RECOVER could probably just be CONTINUE, which is the standard "keep going in a default way" restart
13:04:47
Colleen
Bike: drmeister said 24 minutes, 33 seconds ago: Currently llvm loses a lot of information about local variables at -O3. I thought if at high debug we mark all loads and stores in a function as 'volatile' that this would keep the variable in memory even at high optimization and I would have a hope of pulling it out of the dwarf debug info. There would be a runtime penalty of course. Then when/if llvm's ability to track variables improves we drop volatile.