While I think the spec errors are pretty unfriendly, it's probably worth remembering that most of the times you'll get one you would have got an inscrutable ClassCastException or incorrect behaviour from a totally different place in the codebase prior to spec. It's definitely a huge improvement on that.
The :require issue was an unfortunate first encounter with a spec error because it caught a situation that wasn't actually causing a problem, I think most spec errors users see in the wild that won't be true for. On Tuesday, August 23, 2016 at 6:49:38 AM UTC-7, Brian Marick wrote: > > > On Aug 22, 2016, at 7:50 PM, Alex Miller <al...@puredanger.com > <javascript:>> wrote: > > > 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. […] > > > Do there exist examples of what is desired for error messages in > 1.9-final? Not promises, but a “this is what we’re shooting for”? What > would you all like the specific error messages complained about in this > thread to look like? > > Colin Fleming wrote: "The error message produced by the code I demoed at > the conj last year would be: > > Unexpected symbol 'require' at <exact error location> while parsing > namespace clauses. Expected :refer-clojure, :require, :use, :import, :load > or :gen-class.” > > Is that the goal? I fear that the goal is that it should be my job to > understand "(cat :attr-map (? map?) :clauses > :clojure.core.specs/ns-clauses)”. For what little it’s worth, I consider > that completely unacceptable. > > - 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. > > > My bias here is that I come from the learned-from-bitter-experience > tradition that believes it’s very risky to (1) get the infrastructure > right, and then (2) pop down the user-visible features on top of it. Very > often, the infrastructure turns out to be a poor match for the actual needs > of the features. But, since (1) is already done, the features - and > consequently the users - suffer. > > Please understand I’m not being insulting when I say that everyone has > weaknesses and blind spots, even undoubted geniuses. In Clojure, error > messages and documentation (especially doc strings) have long been glaring > weaknesses. So I am wishing to be helpful when I counsel *quickly* getting > to worked examples of output, especially output that novices are likely to > encounter. And exposing those messages to typical users, ones who are not > familiar with core.spec. > > That seems prudent. > > I believe strongly enough in good error messages that I would be willing > to do some of the scut work, if needed. > -- 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.
