Edit ``proposed extensions to ANSI''

This page is for proposed incremental changes and extensions to the language that go beyond what would be appropriate for _(Proposed ANSI Revisions and Clarifications), but not as radical as changes in _(Lisp - Next Generation):
<ul>
<li>Changes to _(ANSI) that are technically extensions, but address long-absent functionality which makes it difficult to portably do simple things.
<li>Extensions that cannot be reasonably implemented as libraries. (Note: this makes FFI technically in scope, but unless a high-quality spec materializes there's no need to mention it...)
<li>Extensions that can be implemented as libraries, but are very much standard folklore, like <tt>with-gensyms</tt>.
</ul>

_(CDR) is one process for publishing proposed extensions.

For user-space extensions, go and write a _(Library).

<ul>
<li>_(Gray streams) user-extensible streams

<li><a href="http://www.franz.com/support/documentation/6.2/doc/streams.htm">simple-streams</a> from Franz, which avoid some <a href="http://www.franz.com/support/documentation/6.2/doc/streams.htm#gray-stream-problems-2">problems</a> in _(Gray streams)

<li>User-extensible sequences. See _(Christophe Rhodes)' presentation from ILC 2007: <a href="http://www.doc.gold.ac.uk/~mas01cr/talks/2007-04-03%20Cambridge/ilc-talk.pdf">http://www.doc.gold.ac.uk/~mas01cr/talks/2007-04-03%20Cambridge/ilc-talk.pdf</a>

<li>Case-sensitive symbols. _(ACL) and _(CLISP) both have extensions to provide this (see <a href="http://www.franz.com/support/documentation/8.2/doc/case.htm">http://www.franz.com/support/documentation/8.2/doc/case.htm</a> and <a href="http://clisp.cons.org/impnotes/package-case.html">http://clisp.cons.org/impnotes/package-case.html</a>)

<li>Add conformal displacement (array slices) for multidimensional arrays. The other side of the argument is to get rid of displaced arrays altogether, since they are rarely used and prevent certain optimizations. --_(Vladimir Sedach)

<li>Extend :(CLHS ARRAY), :(CLHS VECTOR), :(CLHS STRING), and related type specifiers so that other array attributes can be specified (that the object is/is not displaced, adjustable, or (for vectors) it does/does not have a fill pointer.)

<li>Add weak-key hashtables for example by standardizing on the extensions of <a href="http://www.franz.com/support/documentation/6.2/doc/implementation.htm#cl-make-hash-table-2">Franz</a> 
or <a href="http://www.lispworks.com/reference/lw43/LWRM/html/lwref-57.htm#pgfId-946343">Lispworks</a>. _(trivial-garbage) is a _(library) that attempts to provide a portable interface to various implementations' weak hashtables. Weak-value hashtables and weak references should also be included. Finalizers are a very important feature. The extension should specify whether the finalizer can have access to the about-to-be-collected object to be able to "resurrect" it (currently some GCs run finalizers post-collection; the pros and cons of either approach should be examined). See _(Bruno Haible)'s <a href="http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-writeup.html">writeup on weak references</a> which examines the issues and state of various implementations as of 2005.

<li>Have a way to weakly intern symbols in a package. The effect is that if nothing else refers to the symbol, the symbol can be gc-ed and removed from the package.

<li>Make WITH-GENSYMS or _(WITH-UNIQUE-NAMES) macro part of the standard, since it is very widely re-implemented in libraries.

<li>Specify, for lisps purporting to conform to :IEEE-FLOATING-POINT, the mechanism for enabling traps and clearing accrued exceptions, and for setting the rounding mode (and precision, where applicable), and how this interacts with standard CL functions such as :(CLHS "FFLOOR") and :(CLHS "FCEILING").

<li>Improve the support for floating-point and complex arithmetic as outlined in section C.9 of <a href="http://www.open-std.org/JTC1/SC22/WG11/docs/n462.pdf">the draft version of ISO/IEC 10967-2</a> and section C.7 of <a href="http://www.open-std.org/JTC1/SC22/WG11/docs/n481.pdf">the draft version of ISO/IEC CD 10967-3</a>. (There may be other standards from <a href="http://www.open-std.org/JTC1/SC22/WG11/">ISO/IEC JTC1/SC22/WG11</a> that could be made normative.)

<li>Add an ARGLIST function that, given a function designator, returns the argument list of the function. Suggested alternative name: FUNCTION-LAMBDA-LIST.

<li>Define a way for macros to wrap a :(CLHS LOOP) around the body without affecting :(CLHS LOOP-FINISH) forms within it. This could be done by defining a new :(CLHS LOOP) keyword FINISH-NAME. Then, (loop ... do (loop finish-name foo ... do (loop-finish))) would finish the outer loop directly. To finish just the inner loop, you'd have to use (loop-finish foo). Macros would use gensyms.
Other possible syntaxes include (loop using (loop-finish foo) ...), which puns on <a href="http://www.lisp.org/HyperSpec/Body/sec_6-1-2-1-6.html">for-as-hash</a>; (loop unfinishable ...), which would be entirely invisible to LOOP-FINISH; and (loop fully named foo ...), which would require both (:(CLHS return-from) foo ...) and (loop-finish foo).
Would extending :(CLHS LOOP-FINISH) to take the loop name as an argument be sufficient (exit from the innermost loop with the given name)? --Nikodemus
 Not quite. Users of macros would often omit the argument of :(CLHS LOOP-FINISH), for the sake of clarity or compatibility with current CL. Implementors of macros would not be able to handle such cases transparently. If :(CLHS LOOP) is extended too, then only macro implementors need be careful, like they already are with names of variables; users can ignore the whole issue. -_(Kalle Olavi Niemitalo)
I don't understand the need for this. However, :(CLHS LOOP) already has a NAMED clause that could be used for :(CLHS LOOP-FINISH). It would overload its meaning, but it would reduce the number of changes needed. - _(Marco Antoniotti)>
<li>
(backquote ...) standard macro (like Scheme quasiquote) to allow for easier and scheme-like programmatic use of ` in constructs. I forget any arguments as to why it standardising it would not be good idea, but no doubt there are some. Constraining implementations seems unlikely as far as I can see. Morality-police discouraging its use, maybe, but I don't like that.

If the semantics are going to match Scheme, then the name should too. Also, one cannot implement extensions such as `#C(,x ,y) if the ` reader macro is required to just read a form and put (backquote ...) around it. -_(Kalle Olavi Niemitalo)

Is that really so?  I would think that changing #C to translate #C(,x ,y) to (unquote (complex x y)) would do the trick. -_(Dirk Gerrits)

This is a really, really bad idea; totally contrary to the meaning of backquote. Backquoted material should be handled by the reader (as in most CL implementations now). Turning it into a form is so bad, I'd seriously consider abandoning Lisp if it happened, I feel so strongly about that. -- AC

No, it's a good idea. While most of the times it doesn't matter whether backquote is handled in the reader or not, there are times when it'd be really nice to know what the sexpression representation of '`(foo ,bar) is. Currently it's implementation defined which means that macro-writing macros can't take backquoted templates as input which they can then frob. A specific example: recently I was writing a mini-language and wanted to write two functions, one that compiled my intermediate representation for use in a macro and another that interpreted it. The compiler and interpreter were essentially identical except one generated code while the other executed it. If backquote templates were read into a specified sexpression form then I could have written a macro that took a list of backquoted templates and generated both functions. Instead I had to essentially implement my own backquote syntax that I could then take apart and put back together. -- _(Peter Seibel)

I don't claim to have thought this through, but requiring tighter binding of backquote/comma to the reader might let constructions such as #C`(,a ,b) fall
out without extra per-read-macro specifications. --nikodemus
</li>
<li>
Extend :(CLHS MAKE-HASH-TABLE) to take any function as an equality predicate, and open it up so users can write their own hash functions. These will put CLOS objects on an equal footing with built-in objects.

I'd rather see (DEFINE-HASH-TABLE-TEST test-function-name hash-function-designator), and making :(CLHS MAKE-HASH-TABLE) accept any defined test in addition to #'eq.*. This way libraries can provide new hash-table types, and users of those libraries don't need to muck about with extra arguments to M-H-T. --Nikodemus

I like <a href="http://clisp.cons.org/impnotes/defhash.html">DEFINE-HASH-TABLE-TES</a> too. --sds
</li>
<li>
Extend the guaranteed behavior of :(CLHS SUBTYPEP), so that it must succeed in determining subtype relationships in more situations. In particular:
<ul>
<li>If :(CLHS SUBTYPEP) can determine that A is (or is not) a subtype of B, then
it should determine that (NOT B) is (is not) a subtype of (NOT A).</li>
<li>(NOT (NOT A)) should have the same behavior as A.</li>
<li>If :(CLHS SUBTYPEP) can determine that A is a subtype of B, and A is a subtype of C,
then it should be able to determine that A is a subtype of (AND B C).</li>
<li>If :(CLHS SUBTYPEP) can determine that A is a subtype of C, and B is a subtype of C,
then it should be able to determine that (OR A B) is a subtype of C.</li>
</ul>
</li>

<li>Make more builtins be readably printable in some standard way. Alternately, allow users to define :(CLHS PRINT-OBJECT) methods for builtin types on which the implementation does not provide a method.</li>

<li>Add an _(ELASTIC-NEWLINE) function.</li>

<li>Franz's <a href="http://www.franz.com/support/documentation/7.0/doc/environments.htm">first-class environments</a> proposal.

<li>Eliminate holes in standardized exceptional situations (where the standard says something is undefined for certain arguments, etc.). The goal should be that safe code does not have undefined behaviors on erroneous arguments, since any such is a potential security hole.

<li>A function to expand user-defined types into primitives. Does this mean a function that takes a <a href="http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_t.htm#type_specifier">type specifier</a> and returns something implementation-specific? Or something else? I don't understand this or why it's needed. --_(Vladimir Sedach)

<li>Ability to efficiently list all specified readtable characters/dispatch-characters.

<li>Custom CLOS specializers without rewriting that much of standard-class. How would this work? --_(Vladimir Sedach)

<li>Reader syntax for hash tables.

<li>Turn COERCE into a generic function.

<li>Add readers RESTART-TEST-FUNCTION, RESTART-INTERACTIVE-FUNCTION, RESTART-REPORT-FUNCTION, which will act analogous to RESTART-NAME. This will make the existing condition system introspection facilities (COMPUTE-RESTARTS and FIND-RESTART) more useful.

<li>Add an analogue of PROGV for RESTART-CASE. That is, make it possible to use the result of FIND-RESTART or COMPUTE-RESTARTS to introduce restart handlers in the current dynamic environment. Right now this is possible by constructing a RESTART-CASE expression based on examining restarts, and applying EVAL to that expression. This would extend the introspection facilities of the condition system.

<li>Provide access to SAFETY OPTIMIZE declarations during macroexpansion time ala the <a href="http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html">Environments chapter of CLtL2</a>. This will make it more convenient to write <a href="http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/262f0bbbb6b72bbc/18a2e45dd4b4b8a7">optimized code with optional type checks/assertions</a>.

</ul>

<hr>
*(standards)

Please supply your name and a summary of changes for the Recent Changes page. If you are making a minor alteration to a page you recently edited, you can avoid making another Recent Changes entry by leaving the Summary box blank
Summary of changes:
Captcha (enter the word "lisp" here):
Your name:
Check this box to fill in your name automatically next time (uses a cookie)

Please note: other readers will see your changes immediately, but external search engines will continue to see the old version for another 24 hours. Spamming this site to improve your PageRank is therefore a particularly fruitless activity.

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively