restarts vs debugger command

73budden . budden73 at
Fri Jul 10 10:33:05 UTC 2015

>> I believe *current-component* is rather innocent
Design choices is a great topic for holywar :)  If variables are not
innocent for you, then you just not accept my patch. I'll continue to
use it for myself. Unfortunately, I have no time and desire to reshape
it, at least in the near future.

The other topic is finding definitions.
>> What do you think about
>> (keywordize (string-upcase (coerce-name name)))
>> ?
> Sounds good (at least assuming no one's using mlisp), but then issue
> an error if it doesn't convert back to the same name when you
> coerce-name it back.
This is not I who coerce it back. It does lisp reader. In standard
readtable no problem should occur IMO. In non-standard readtable all
source location handling must be reviewed. So I see no additional work
to be done. If I'm wrong, please give a counter-example. If this
suggestion can be accepted, tell me how I should reshape it.

And third topic is of-system. There are cases where relation between
file and system is essential. Sometimes there are several systems in
one directory (e.g. cl-ppcre). Sometimes code is located in several

(of-system :mysystem) declares that the file is in the system. I press
M-. on :mysystem and jump to its definition. This is convenient.

Runtime checking guarantees that declaration is always correct. I
can't forget changing it when I refactor my systems.

But there is other possibility: in latest projects I use EMACS
modeline variable instead of (of-system). I write -*- system
:my-system; -*- and I have lispworks command "find current system
definition" which takes system name from modeline and jumps to system
definition. Similar command can be written for SLIME/EMACS. This is
even more convenient than of-system, but requires more effort to port.
Asdf can even check correctness of modeline if it would open file,
parse its modeline and compare declared system with real prior to
compilation. Thus you can get rid of special variables. But this is
not extremely important.

More information about the asdf-devel mailing list