[cltl3-devel] RFC: CLtL3 Charter

[John Fremlin]

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!