Drew Crampsie wrote:
What I was talking about before was (1) a facility for macros to inspect the declared or derived types in the lexical environment,
Something like this may make it as part of the environments module. But, we won't _require_ any compile-time type inference.
Fair enough.
auto-sealing generic function system built on this. Namely, if the type is known and matches a defined method then that method may be inlined at the compiler's discretion; if it is later redefined (defsealedmethod) or a more specific method is defined then that may not affect compiled code (in the same vein as inline functions at the moment).
Something like this is _way_ out of scope. I'd like to offer the tools to enable someone to build it portably, but it's not going into the description.
Well, if the tools were there that would be an important start. I think that at least supporting this sort of extension should be considered.
I'd need to see some code for this, it's a neat idea, but the implementation is likely hairy. Can you point to an existing implementation?
No :-)
This is already possible to some extend using symbol shadowing. I would not want to allow "operator overloading" like in C++ (shudder)
Why not?
Because it's crap, and we have SHADOW.
Well, that's not an argument; I like it. I think it's great. How does this essentially differ from the generalized sequences proposal? If you called it generalized numbers would you be happier?
Possibly kill the many bizarrely named or strangely parameterised and hardly used functions like `get'.
Not going to happen.. ever. I used GET just yesterday, and we will not be 'killing' anything. If you don't like it, don't use it, but removing functionality and CL compatibility is not worth it, and not a goal of CLtL3.
"Kill" gets to far - this would break ANSI CL compatibility. We could deprecate their use and don't import them in the CLtL3 package(s) - so one could use CL:GET if one wants to. ,
We will also _not_ be deprecating things from CL because they are bizarrely name or parameterized . If anything i'd like to un-deprecate a few things ANSI sent down (*-if-not, i',m looking at you).
I meant that using the CLTL3 package should not mean that the more unfortunate functions from CL be automatically imported. You cannot bind (flet ((get (...))) for example, and while I have indeed used get (unfortunately, more than a week ago so not on a par with your mastery of it), I think it is unfortunate that a specific functionality managed to grab a generic three letter name.
I guess we will have to wait for Attila Lendvai to complete his redesign of the Lisp namespace and CLTL3 will be for other things ;-)
Backtraces are badly implemented by many projects and would be used by more if they weren't so tricky.
Trivial-backtrace exists, so there is some need for this. It's covered under 'Editing and Introspection' in the charter.
Trivial backtrace and the portable backtrace functionality in it is just a start. Backtraces are (badly) implemented in many server projects.
I didn't understand that you'd gone so far to fixing on your charter. Sorry for butting in; have fun!