search

thephoeron / let-over-lambda

Doug Hoyte's "Production" version of macros from Let Over Lambda, ready for ASDF and Quicklisp.
Other
134 stars 25 forks source link

Split files, add dependencies and remove copied/duplicate code #6

Closed EuAndreh closed 9 years ago

EuAndreh commented 9 years ago

This was a bigger refactor of the code. Changes:

  1. Removed defmacro! related code: imported code from defmacro-enhance, which took the code from the book, and made a more portable version of the code-walking. It is actively maintained and used by many projects. There's a difference in usage (as described in the defmacro-enhance's README): g!symbols becomes g!-symbols, and o!symbols don't map to g!symbols: o!symbols becomes o!-symbols and map to o!-symbols;
  2. Code from Paul Graham's On Lisp (like symb or flatten) was removed and imported from the source;
  3. Removed the #> reader-macro: changed to cl-heredoc (as described in the errata);
  4. Kept the named-readtables support;
  5. Added the file readtable.lisp, with all the read-macro related stuff, with a package called let-over-lambda.readtable (with a nickname of lol.rt);
  6. Added the line (cl-reexport:reexport-from :lol.rt) at the end of the package.lisp file: it uses the cl-reexport package and reexports from the lol package all symbols from lol.rt. That way, one can (:import-from :let-over-lambda ...) without having to know if the symbol is in the lol package or in the lol.rt package;
  7. Improved the #~ reader-macro: added support for Perl-like balanced regex delimiters. Ex: (#~m<abc> ...). Matching delimiters inserted are in matching-delimiters;
  8. Changed the frunction called from the #~m reader-macro: instead of ppcre:scan, now it call ppcre:scan-to-strings as it was found to be more practical in daily usage;
  9. Changed if-macro: it allow nesting and binds $n local variables accordingly.

TODO:

  1. Wait for the on-lisp package to become available in Quicklisp (I already created an issue, and hope that @DalekBaldwin will agree);
  2. Add some tests and check implementation independence (I can do it). Maybe add some examples from the book and put many corner cases to check compatibility with the code from the book (it can be done easily with Travis CI);
  3. Update the README, explaining the API and adding links to the code in the site (I can do it too =p );
  4. Add docstrings to functions and macros (And this too =p );
  5. Test the if-match macro (I can try it)
EuAndreh commented 9 years ago

I'd also add some functions and macros from the book that didn't make in the production version of the code, but that I found out to be very useful in daily usage:

...and, arguably

And remove: