2009/9/6 John Fremlin john@fremlin.org:
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.
CLtL3 will make every effort to avoid breaking compatibility with ANSI. While a non-compatible change may be worth looking at, it likely will not be a part of this spec unless there is an extremely good reason and little chance of breaking ANSI CL code.
[...]
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
It would make things significantly more complex to implement (read: impossible in many cases to determine the effective method), and with little gain.. one can easily hack something up with typecase and a hash table if one wants to dispatch on CL types.
How would it make things less complicated to explain? AMOP is fairly simple (or it at leasts builds on simple concepts).. adding types to the GF dispatch would complicate things significantly.
The goals of CLtL3 are not to make CL 'simpler', 'more understandable' or 'easy for newbies'.
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.
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.
[...]
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.
Out of scope as well.
[...]
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?
Environments are worth looking into, yes.
[...]
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.
Conduits, and hierarchal packages, are something we'll have to look at further, I can see uses within CLtL3 itself.
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.
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?
[...]
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?)
Extensible hash tables are covered by a CDR, and so are on the list of things we will consider.
[...]
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.
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).
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.
Trivial-backtrace exists, so there is some need for this. It's covered under 'Editing and Introspection' in the charter.
Cheers,
drewc
[...]
cltl3-devel mailing list cltl3-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel