Switch slot options from symbols to keywords.

[Ambrevar]

This saves us from exporting unbound symbols, which is poor and confusing practice.

Fixes #14.

[Ambrevar]

@aartaka @aadcg OK to merge? Then I'll release 2.0.0.

[aadcg]

All good from my side!

[aartaka]

Now that I look at it in the light of https://github.com/atlas-engineer/nfiles/issues/14#issuecomment-1431310848, I'm in doubt of whether we should limit ourselves with keywords. Here's what we can do instead, preserving backwards-compatibility and allowing for more extensibility:

• Retain the symbols, while binding them to the respective restart-invoking functions.
• Change the type of those restart slots to symbol.
• And explicitly mention in the documentation that one can set these to their own restart names if those are present in the error environment.

So the use of the library could then be:

• One defines a subclass of nfiles:file.
• They set an on-external-modification or on-deserialization-error to 'foo.
• In their code, using Nfiles, they add a restart-case with foo restart, doing something that we didn't anticipate initially.
• This use fits just fine with Nfiles and allows adding more logic to complex conditions with files.

I mean, no one forbids doing this with keywords too, but that looks quite weird to name restarts with keywords...

[Ambrevar]

Yes, this is better, + no need for a 2.0.0.

• Change the type of those restart slots to symbol.

No need I believe. If the user extends the class and the slot, then they can redefine the type to (member NEW-RESTART OLD-RESTART).

[Ambrevar]

See #20.

[aartaka]

• Change the type of those restart slots to symbol.

No need I believe. If the user extends the class and the slot, then they can redefine the type to (member NEW-RESTART OLD-RESTART).

This should work per standard, yes. But then, SBCL is extremely cautious about slot types at (safety 3), so it won't allow to redefine the type to be looser than the previous one. So we'd better account for these cases in advance and use symbol by default. Yes, it's quite vague, but at least it's vague enough to not create type mismatches in the compiler.

[Ambrevar]

Good point!