From: Martin A. <ma...@at...> - 2001-04-23 16:06:25
|
William Harold Newman wrote: > > Martin Atzmueller wrote: [...] > > Addendum: > > Well, it seems that arglist information is only saved for compiled > > functions, not for byte-compiled functions. > > That is not really nice, when using ILISP, which tries to give > > arglist information for functions, e.g. using ILISP's arglist > > facilities on a byte-compiled function gives nothing. > > (Currently ILISP uses some low-level hacks to get this information > > out of SBCL, maybe somewhat like the ILISP arglist-info functions > > should be included in the SB-EXT package ... ?) > > It seems reasonable to provide a standard stable interface for this, > but I'm not sure what it should look like. Perhaps the ILISP people > could put together a proposal for a simple reflection facility which > would provide what ILISP-like facilities need? If done well, this > could help not only ILISP but also Lisp implementors and implementors > of other vaguely ILISP-like packages which need simple reflection, > And it might even be something reasonable for a new ANSI spec. Such a proposal might not be necessary, because other implementations already seem to have such features available. Currently, AFAIK ILISP only uses "reflection" for getting: - the arglist of a function - the source-file, where the function was defined So, it should be very easy to add some of these "reflection" capabilities. I just browsed the ILISP sourcecode, and indeed, at least three other implementations provided a ARGLIST function in the extension package (ACL, Lispworks and CLISP), and at least two provided functions to locate the source-file, where a function was defined in (ACL, Lispworks). It would not be too complicated, to add something like that to SBCL, IMHO. > > So, I think it makes sense to byte-compile only 'internal' stuff, > > like internal functions and macros, in order to still provide > > arglist-info for the user-visible functions. > > Therefore, many functions in describe.lisp and inspect.lisp should > > not be byte-compiled (and the patch byte-compiled all functions > > in these files; but parts of the patch are still needed to _enable_ > > byte-compilation of (parts of) these files) > > I haven't gotten around to merging your original byte compilation > patch yet. Now that this issue has come up, do you think I shouldn't > merge that patch yet? I just think you shouldn't merge the whole patch. Only the portion of the patch concerning compiler/generic/vm-fndb is probably relevant now, but before you merge it, I'd ask you to review it. > I agree that the externally-visible stuff should have argument > list information available. And it's probably not worth trying > to generalize the byte compiler so that can provide that information, > so yes, those things should be native compiled. > > It won't be too much work to hunt those things down and change them, > but it'll probably be tedious to maintain correctly. If you do this, > you might want to use some automatic method to look at all the > external symbols of public packages and make sure that none of them > are fbound to byte-compiled code. And if you do that, it'd probably be > reasonable to make that check permanent, e.g. in a new > tests/interface.pure.lisp file, so that this doesn't silently break in > the future. Yes, that sounds good. I have another patch up my sleeve, but I think I'll look into the issue that you outlined above, anyway. At first thought it shouldn't be too complicated to put up such a test. -- Martin Atzmueller <ma...@at...> |