freenode/#sicl - IRC Chatlog
Search
19:07:17
Bike
i think rather than RECOVER i'd rather have a SUBSTITUTE-CST restart. CONVERT would always establish it so you always know it's there. unlike RECOVER it would have one argument - a CST built by the implementation from information in whatever error was signaled
19:10:45
Bike
but it might be nice to have RECOVER as a first line attempt - like with compiler macro functions it could be used properly for any kind of error, or for CONSIDER-SPECIAL - and then more specific restarts if there's no specific RECOVER
19:18:27
Bike
though for compiler macro and regular macro function errors, maybe we should just wrap them - we can add in a source location that way
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