CDR is one process for publishing proposed extensions.
For user-space extensions, go and write a Library.
Other possible syntaxes include (loop using (loop-finish foo) ...), which puns on for-as-hash; (loop unfinishable ...), which would be entirely invisible to LOOP-FINISH; and (loop fully named foo ...), which would require both (RETURN-FROM foo ...) and (loop-finish foo).
Would extending 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 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 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, LOOP already has a NAMED clause that could be used for LOOP-FINISH. It would overload its meaning, but it would reduce the number of changes needed. - Marco Antoniotti>
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
I'd rather see (DEFINE-HASH-TABLE-TEST test-function-name hash-function-designator), and making 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 DEFINE-HASH-TABLE-TES too. --sds
This page is linked from: CDR document language extension Proposed ANSI Revisions and Clarifications
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively