Mercurial > hg > xemacs-beta
view src/README.kkcc @ 5566:4654c01af32b
Improve the implementation, documentation of #'labels, #'flet.
lisp/ChangeLog addition:
2011-09-07 Aidan Kehoe <kehoea@parhasard.net>
* bytecomp.el:
* bytecomp.el (for-effect): Move this earlier in the file, it's
referenced in byte-compile-initial-macro-environment.
* bytecomp.el (byte-compile-initial-macro-environment):
In the byte-compile-macro-environment definition for #'labels, put
off the compiling the lambda bodies until the point where the rest
of the form is being compiled, allowing the lambda bodies to
access appropriate values for byte-compile-bound-variables, and
reducing excessive warning about free variables.
Add a byte-compile-macro-environment definition for #'flet. This
modifies byte-compile-function-environment appropriately, and
warns about bindings of functions that have macro definitions in
the current environment, about functions that have byte codes, and
about functions that have byte-compile methods (which may not do
what the user wants at runtime).
* bytecomp.el (byte-compile-funcall):
If FUNCTION is constant, call #'byte-compile-callargs-warn if
that's appropriate, giving warnings about problems with calling
functions bound with #'labels.
* cl-macs.el:
* cl-macs.el (flet):
Mention the main difference from Common Lisp, that the bindings
are dynamic, not lexical. Counsel the use of #'labels, not #'flet,
for this and other reasons. Explain the limited single use case for
#'flet. Cross-reference to bytecomp.el in a comment.
* cl-macs.el (labels):
Go into detail on which functions may be called from
where. Explain how to access the function definition of a label
within FORM. Add a comment cross-referencing to bytecomp.el.
man/ChangeLog addition:
2011-09-07 Aidan Kehoe <kehoea@parhasard.net>
* cl.texi (Function Bindings):
Move #'labels first, describe it in more detail, explaining that
it is to be preferred over #'flet, and explaining why.
Explain that dynamic bindings with #'flet will also not work when
functions are accessed through their bytecodes.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Wed, 07 Sep 2011 16:26:45 +0100 |
| parents | 3889ef128488 |
| children |
line wrap: on
line source
2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de> Markus Kaltenbach <makalten@informatik.uni-tuebingen.de> Mike Sperber <mike@xemacs.org> updated 2003-07-29 New KKCC-GC mark algorithm: configure flag : --use-kkcc For better understanding, first a few words about the mark algorithm up to now: Every Lisp_Object has its own mark method, which calls mark_object with the stuff to be marked. Also, many Lisp_Objects have pdump descriptions memory_descriptions, which are used by the portable dumper. The dumper gets all the information it needs about the Lisp_Object from the descriptions. Also the garbage collector can use the information in the pdump descriptions, so we can get rid of the mark methods. That is what we have been doing. DUMPABLE FLAG ------------- First we added a dumpable flag to lrecord_implementation. It shows, if the object is dumpable and should be processed by the dumper. The dumpable flag is the third argument of a lrecord_implementation definition (DEFINE_LRECORD_IMPLEMENTATION). If it is set to 1, the dumper processes the descriptions and dumps the Object, if it is set to 0, the dumper does not care about it. KKCC MARKING ------------ All Lisp_Objects have memory_descriptions now, so we could get rid of the mark_object calls. The KKCC algorithm manages its own stack. Instead of calling mark_object, all the alive Lisp_Objects are pushed on the kkcc_gc_stack. Then these elements on the stack are processed according to their descriptions. TODO ---- - For weakness use weak datatypes instead of XD_FLAG_NO_KKCC. XD_FLAG_NO_KKCC occurs in: * elhash.c: htentry * extents.c: lispobject_gap_array, extent_list, extent_info * marker.c: marker Not everything has to be rewritten. See Ben's comment in lrecord.h. - Clean up special case marking (weak_hash_tables, weak_lists, ephemerons). - Stack optimization (have one stack during runtime instead of malloc/free it for every garbage collect) There are a few Lisp_Objects, where there occurred differences and inexactness between the mark-method and the pdump description. All these Lisp_Objects get dumped (except image instances), so their descriptions have been written, before we started our work: * alloc.c: string description: size_, data_, and plist is described mark: only plist is marked, but flush_cached_extent_info is called. flush_cached_extent_info -> free_soe -> free_extent_list -> free_gap_array -> gap_array_delete_all_markers -> Add gap_array to the gap_array_marker_freelist * glyphs.c: image_instance description: device is not set to nil mark: mark method sets device to nil if dead See comment above the description.