[cltl3-devel] RFC: CLtL3 Charter

[Drew Crampsie]

2009/9/6 John Fremlin <john at fremlin.org>:
> 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.

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.
>>
>> 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?)

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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cltl3-devel
>