From: Jan M. <jmo...@te...> - 2015-06-14 05:39:18
|
On Fri, 2015-06-12 at 10:20 -0400, Douglas Katzman wrote: > > I have not thought this through very deeply, but I don't think "up > > front" checking is needed. > > Removal of the up-front checks would be a regression. [...] I didn't realize that without "up front" checking only TYPE-ERRORs without any context would be signaled. It would be nice to preserve the current "detailed" error reports (i.e. [1]). In my understanding "up front" vs. not-"up front" was only about whether "detailed" error reports were generated before any bindings and evaluation of defaults happened. I'm also not sure whether anymore some of the "up front" checks are actually in user code and not the DS-BIND expansion. Sorry for being dense, but can you explain the proposed alternatives again? > > ... DEFTRANSFORMs > I saw that, I find that to be somewhat over-designed. > [...] I didn't understand most of that paragraph beyond the fact that the described compile-time checks and optimizations do not make sense, sorry. Disregarding the optimization aspect, are you arguing that the compile -time detection of destructuring errors based on type information doesn't make sense? > > Rename BUILD-LAMBDA-LIST to UNPARSE-LAMBDA-LIST? > [...] > not actually the unparser for a "thing". Wdyt? Makes sense. I think the current solution (i.e. after the "Add destructuring lambda-list parser/unparser + tests." commit) is fine. > > Since some behavior changes, unit tests changes seem necessary > This patch went out of its way not to break anything! (Despite my > shock that we special-cased the outermost list not to signal the > general destructuring-mismatch condition.) Sorry if my wording was inappropriate. I mainly though of (but didn't clearly refer to) cases like the difference in behavior between SBCL and CLisp mentioned in the next bullet point. This "changed" from "SBCL does one thing and CLisp does a different thing" to "SBCL does the specified thing" (at least in my mind). I wanted to point out that our current tests (candidates seem to be destructure.impure.lisp and lambda -list.pure.lisp) do not check these aspects. Same for "up front" checking once we decided on one of the behaviors or policy-based selection among multiple behaviors. Consider this moot if these things are already tested somewhere and I just didn't see it. Kind regards, Jan [1] (destructuring-bind ((a b)) '((1)) (list a b)) => error while parsing arguments to DESTRUCTURING-BIND: invalid number of elements in (1) to satisfy lambda list (A B): exactly 2 expected, but 1 found |