[cltl3-devel] RFC: CLtL3 Charter

[John Fremlin]

Jochen Schmidt <js at crispylogics.com> writes:
[...]
> The fact that there exists an established standard (ANSI CL) will have
> a stake on what we can do with CLtL3. It doesn't make any sense to me,
> to break ANSI CL support; a future CLtL3 capable Common Lisp should
> also work with programs written for ANSI CL.

Possibly, but I hope you understand that the ANSI CL standard was not
perfect, is not implemented perfectly, and if a small change or
clarification is proposed then you agree that it should be judged on its
individual merits (as affecting existing programs or not, etc.) and not
summarily rejected.

[...]
> Generic functions do not dispatch on types, but on classes (and on EQL
> values).

Yes, I am painfully aware of this and find it very unfortunate that there
are three kinds of valid type in CL: types you can give to declare or
the, types you can give to typep, and classes.

[...]
> The consequence is, that you cannot dispatch on all types expressible
> in CL. Allowing dispatch on arbitrary types is probably not easy and
> perhaps not very efficient. Though: Extensions to the dispatch system
> are a very interesting topic for CLtL3. AFAIK Pascal Costanza is
> working on some ideas to realize predicate dispatch within CLOS.

To digress into this tangent, it might great if generic functions could
also dispatch on types. If it makes it inefficient for those cases which
use this functionality (e.g. satisfies), fair enough, but it would make
things less complicated to explain.


What I was talking about before was (1) a facility for macros to inspect
the declared or derived types in the lexical environment, (2) a new
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).

[...]
> Value semantics? I would like to here some more about why you think
> this is needed for CL and how it should work.

It would be nice if it were possible to get decent code out of a CL
compiler for things like bytemap or manardb, where the ability to pass
around small structures instead of horribly packing things into integers
would be great. For another example, an array of structures rather than
an array of pointers to structures has hugely different performance.


[...]

> defining access to environments - I would like to see something like
> that too.

To be clear one of the messiest areas of the CL standard is the business
of declarations; for example, the distinction between bound or unbound
declarations. How can a code-walker/transformer decide what a
declaration refers to if the declaration is not standard?

[...]

> Would be somewhat cool. More important to me would be compiling and
> loading code from a stream.

You can load code from a stream in ANSI (but not Allegro, which assumes
its a fasl or not depending on the element-type of the stream -- another
messy bug they are afraid to touch).


[...]
> Package-local aliases, nicknames for packages that are only valid
> within the package in which they are defined are quite possible.
> Perhaps ideas from Tim Bradshaws conduits package should be taken into
> account.

Or Ron Garret's ideas.


[...]
> the chosen package. A problem is though, that in ANSI CL there is this
> constraint were the symbol-name of a symbol is always the same -  
> regardless of the current package - this could lead to problems with
> ANSI CL programms.

You could munge the reader to have a local alias table that it consults,
it wouldn't affect anything that didn't touch this table.


Having package versioning so multiple versions of the same package could
be simultaneously loaded would make some of the dependency nuisances go
away, and allow for somewhat smoother live updates.

[...]

>> eq, eql, equal, equalp are not enough; nothing should restrict
>> itself to
>> these comparisons.
>
> http://www.nhplace.com/kent/PS/EQUAL.html

What's that got to do with it? I was complaining about the limitations
of the standard make-hash-table :test. (Is there another place where the
set of test functions is restricted?)

[...]

> This is already possible to some extend using symbol shadowing. I
> would not want to allow "operator overloading" like in C++ (shudder)

Why not?

>> This would allow (explicit) laziness!
>>
>> Possibly kill the many bizarrely named or strangely parameterised and
>> hardly used functions like `get'.
>
> "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.

Yes.

[...]

>> Stack frame inspection
>
> Usefulness is king.

?

Backtraces are badly implemented by many projects and would be used by
more if they weren't so tricky.

[...]