I've already mentioned most of this above, but I'll try again. In short, I'd say yes (that's why we are still in alphas), but in adherence with the general goals we have of capturing and returning comprehensive data about the error and building those error messages generically.
- Getting the error data (specifically the explain-data output) to be both sufficient and generically useful is the first priority. I think at this point that's pretty close and unlikely to change significantly. This is the key data that can be used to drive everything else. form/describe are also tools leveraged by explain-data and there are a bunch of (known) problems still in those areas that will be cleaned up. - The explain error message strings are currently pretty good on simpler specs. The big syntax macro cases like ns or let are way past the "average" spec. They are difficult in several dimensions - fan-out, recursion, large input forms, etc. All of those make creating generic error messages a lot harder so I don't think it's fair to judge the general performance of spec's errors on just those use cases. There are some general known problem areas where there are things that can be done. I talked about some of those in relation to s/cat in prior post, but there are others as well. - It's unlikely that we will add any kind of "custom error strings" - the focus will be on automatic message generation. - There are issues orthogonal to spec around compiler error reporting and stack trace display that can and should be improved. - You've complained in other channels about the "learning to read" error messages part and I think you've taken it entirely the wrong way or maybe I just disagree. There are benefits from reporting errors in a generic, consistent way. That way may mean acquiring familiarity with something new, just like learning any programming language. I'm not disagreeing that the messages we're looking at are harder to understand than a hand-written custom error message for a particular specific situation, but we have bigger goals of automatically producing good errors for a large class of specs. Keep in mind that while we're focusing here on one or two specific problems, these specs also are detecting a large number of other errors and generically producing error messages for all of them, while simultaneously being available to conform/destructure the input in ways that can potentially improve the implementations too. All of this post is of course just my thoughts from someone in the room but not making the final decisions, so everything here is subject to being over-ruled tomorrow. :) On Monday, August 22, 2016 at 5:11:27 PM UTC-5, Brian Marick wrote: > > > On Aug 22, 2016, at 11:23 AM, Leon Grapenthin <grapenthinl...@gmail.com> > wrote: > > Still the error messages are simply far from good enough and that is what > appears to me as the main problem OP has. > > > This is important. Will the new, stricter error messages be improved > before 1.9 is finalized? > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
