freenode/#sicl - IRC Chatlog
Search
3:15:29
beach
Bike: I haven't given restarts enough thought. The current situation is certainly not optimal, but better than nothing. For one thing, there is always a bunch of nested restarts available which looks kind of confusing.
3:16:34
Bike
i think usually the user ought not to see them, though, like they should just be used by higher level logic.
3:17:01
Bike
do i remember right that you want RECOVER so that non-compiler uses of cst-to-ast can get an AST without too much fuss?
3:17:24
Bike
it's okay. the main thing is that you can't really subclass RESTART like acclimation does with CONDITION.
3:19:47
Bike
and if you have multiple restarts with the same name, find-restart and invoke-restart use the most recent, so no problem there
3:25:57
Bike
i kind of want to clean up the use of conditions first, though. i think a good first thing to do would be wrapping (compiler)-macroexpander conditions. we can have an encapsulated condition class with the original condition, plus source info.
3:26:19
Bike
we can define what kind of conditions cleavir is supposed to signal - like, for invalid code input - and then everything else is a bug
3:28:35
Bike
there is kind of a confusing thing... for unknown variables and functions, cleavir signals an error. the client is expected to intercept the error and signal a warning instead.
3:33:01
Bike
i guess with an unbound variable you could hypothetically substitute something else. there's a restart for it.
3:34:10
Bike
well, with what i've been doing in clasp i suspect any cleavir client that wants to do compilation units nicely will have to do a lot of condition handling regardless.
3:39:17
Bike
i think if a compiler macro function signals an error the sequence will go like: cleavir handles the error by signaling a new error of a cleavir class encapsulating the original error. the client handles that error by invoking a cleavir restart. the restart signals a warning (style-warning?) which is also a cleavir class encapsulating the original condition.
3:41:13
Bike
the alternative i was debating was cleavir only signaling a warning to begin with, but i guess the client could hypothetically want to do something else (like compile in an error form)
3:42:44
beach
Yes, in general I think Cleavir should signal errors. If that is not terribly convenient, maybe we can provide some default wrappers that convert them to something nicer while still allowing the full flexibility for client code.
3:43:26
Bike
in this particular case it's going to be kind of inconvenient regardless, what with the encapsulation, so an error should be fine
3:44:47
Bike
(as for the lisp semantics, i think having a compiler macro function signal an error would be undefined behavior so it should be a WARNING, but also they're fundamentally optional so i don't think it should be that severe)
3:46:58
beach
It would be reasonable behavior to just use the original form, which is supposed to always work.
3:49:52
Bike
hm, i think if we want only one RECOVER restart to be visible at a time, we could do it with a tricky restart :test
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.