…extensions to Modf without altering the source. No external interface yet.
…y) and normal CL macro expansions. This is the right thing to do because often Modf needs to do something completely different (in fact the complete opposite) of what a Lisp form would normally do. So, rewrite rules now also allow for a way to prevent normal macro expansion.
…. It appears that structures that include other structures are not handled well with Modf. It seems like either a very ubiquitous CL bug (happens in every Lisp I test against) or more likely some odd feature of the standard I still don't get.
implementation for all Lisps except ECL.
…ed and test the case where the library is loaded from previously compiled FASL files.
…sively use MODF.
…nt number of the container. Why is this necessary? We want people to be able to recursively define Modf expansion functions and methods. This means that within the body of a Modf expansion function/method, the macroexpander will need to know how to invert the accessor you are currently defining how to invert. Luckily, it only needs to know which argument it is operating on. This is important with we were defining an inversion for NTH or GETHASH if those inversion functions were recursive (which might be the case with NTH). Since, as was pointed out, we need this this side effect to happen whether this is a file was loaded or compiled then loaded into a fresh Lisp image, and we need the side effect as we compile (in case it is recursive), the side effects are wrapped in an EVAL-WHEN with all three cases specified. If we have mutually recursive Modf functions, well that is still an open problem. Lastly, just to reduce the number of surprises, I have added the same side effect explicitly at macroexpand time. This means that things will work even if definition forms don't happen in top-level forms. See the test suite for an example of this (in fact, this was initially motivated because it is difficult to write a test of this recursive stuff that can be called more than once and actually test this setup).
…as we need to know this in case there is a MODF form inside a MODF expansion (especially if the Modf expander/inverter is recursive).
from fasl files than after initial compile and load. This was fixed for DEFINE-MODF-FUNCTION and DEFINE-MODF-METHOD.
… look up the proper CLOS slot via the accessor and object.
… or the name of a class.
…od is only used by ECL. Every other Lisp I test with behaves like SBCL (i.e. only direct-slot-descriptors know their readers, not effective-slot-descriptors)
1. Modf will assume that the data container is in position 1 of the expression list (adjusting for applys) if it doesn't know the function. This is what you want most of the time, but not all the time. 2. MODF-EXPAND is much simpler now. It takes three arguments: NEW-VAL EXPR and ENCLOSED-OBJ-SYM. NEW-VAL is what you want EXPR to evaluate to with the new data structure. ENCLOSED-OBJ-SYM is the symbol that we assumed (in the previous call) would hold the value we are working with. It is part of the current recursion level's job to ensure that that value is set to the proper data (i.e. object that we are accessing at this level). 3. I introduced LATE-INVERT which is a function that will be placed in the expansion if we have no idea what to do. This shows up if we have functions that we have not defined Modf expansions for. This is common for class methods not defined using our DEFCLASS or grovelled out of the def form, and ditto for structures. It uses some smarts to make guesses as to whether an Method/Function is a slot accessor or not. I actually just realized that I messed up the case where we have a reader and writer with different names. Have to fix that later. All in all, it kind of works.
…instance. Gone full circle on that one.
…ized and the mop is powerful enough, we should be able to find the proper (SETF SLOT-VALUE) form for any given slot reader. In order for this to work, we are treating this as the default case. If a Modf function/method is not defined, we assume we are dealing with a class accessor. This might break the previous work I did making modf accept recursive builder functions. I also have to treat the default container argument as 1. This is not always true... Still doesn't work as it produces actual function objects in the expansion. This means that several prominent Lisps can't compile files with Modf expressions anymore. This will have to be fixed.
…ies the object and sets the symbol to the new value (thus leaving old instances intact).
…, but not in a necessarily good way.
…ted that change. What this means, however, is that you might get no meaningful error at all if you try modf with something without a defined expansion.
…e but it is fixed now. I need to expand the test suite to test for modf-eval cases. Changed the way modf expands. Now we try rewrites, then expansions, then functions/methods. A big difference is that it no longer checks to see if there is a function/method defined and the expansions of the definer macros have the side effect of setting what argument position to check next. These two changes allow functions to be recursive. However, Instead of getting an error stating, "I don't know how to deal with blah", you get "value NO-NTH-ARG" isn't a real.