Jochen Schmidt js@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.
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.
[...]