In the data representing fragments of the user's code returned with these
macro errors, does it include metadata with :line and :column keys in it?
Perhaps that would be one way to give errors localized to particular places
in the user's code.
It isn't always available, e.g. keyword cannot have metadata, but symbols,
lists, vectors, and maps can.
Andy
On Mon, Aug 22, 2016 at 6:27 PM, Alex Miller <a...@puredanger.com> wrote:
> Sorry, I missed this one in the thread somehow. This happens to be a case
> where you have *both* defn and destructuring specs in play, so it has even
> greater potential for confusion in generic errors.
>
>
> On Monday, August 22, 2016 at 11:23:33 AM UTC-5, Leon Grapenthin wrote:
>>
>> I welcome the strict checking over backwards compatibility for broken
>> syntax. E. g. allowing things like symbols in the ns decl would require
>> supporting that as a feature in future updates, analyzer code, other hosts
>> etc. The Clojure devs should not have to worry things with so little use.
>>
>> Still the error messages are simply far from good enough and that is what
>> appears to me as the main problem OP has. If the compiler had pointed him
>> to two fixes he could have done in a minute then he had not complained and
>> instead felt more happy with his new compiler.
>>
>> Here is my story when I loaded a large codebase today with 1.9-alpha11:
>>
>
> I'm going to reformat this a little (and formatting is certainly a thing
> that could change - since there are user values in here it's easy for the
> spacing to not be the best)...
>
> Call to clojure.core/defn did not conform to spec:
>
> You mentioned you knew exactly the location and the above gives you the
> form that is failing to match, so you've narrowed it down to a particular
> form in a particular file.
>
>
> In: [1 0]
> val: ({:keys [money/major money/minor money/currency], :or #:money{major
> 0, minor 0, currency :EUR}})
>
> here's the actual value that is failing - so this does include the part
> that's wrong (:or map with non-symbol keys)
>
>
> fails spec: :clojure.core.specs/arg-list
>
> here we name another spec - you can use this to (doc
> :clojure.core.specs/arg-list) to get more info (and so on). There will be
> probably be some kind of a way to do this in a "deep" way at some point.
>
>
> at: [:args :bs :arity-1 :args]
>
> the path through the specs - can be combined with the spec name above and
> the spec for defn to give you a lot more info - this is the kind of thing
> that a sideband tool in an IDE could do amazing things with.
>
>
> predicate: (cat :args (* :clojure.core.specs/binding-form) :varargs (?
> (cat :amp #{(quote &)} :form :clojure.core.specs/binding-form))),
>
> the predicate that is actually failing in the spec, probably not
> particularly helpful given the complexity (and recursiveness) of the
> destructuring specs
>
>
> Extra input
>
> this is the part of cat that I think could be made more explicit - could
> be saying here that the value it had (above) was expected to match the next
> part of the cat (binding-form). So that could say the equivalent of
> "Expected binding-form but had non-matching value ..." and could even find
> what parts of that value matched and maybe which didn't (the :or keys) such
> that you'd have a more precise description. There is some more stuff Rich
> and I have worked on around "hybrid maps" which is the case here with map
> destructuring - it's particularly challenging to get a good error out of
> that at the moment, but there's more that can be done.
>
>
> In: [1 0]
> val: {:keys [money/major money/minor money/currency], :or #:money{major 0,
> minor 0, currency :EUR}}
> fails spec: :clojure.core.specs/arg-list
> at: [:args :bs :arity-n :bodies :args]
> predicate: vector?
>
> This whole block is another (non-applicable) alternative that spec tried
> out (the multi-arity case). We know that's not what we were trying to do,
> but it's reported anyways. This is where fan-out kicks in and you can get a
> lot of noise that's not applicable. I think there's probably enough
> information to either be better about saying which case we thought you were
> matching or to hide some of them, etc.
>
>
> :clojure.spec/args (format-money [{:keys
> [money/major money/minor money/currency], :or #:money{major 0,
> minor 0, currency :EUR}}] (str major "," (if (zero? minor) "-"
> minor) " €"))
>
> And this is just reporting the actual passed args to the macro - I think
> this is confusing because it doesn't look like the call (because it's
> missing the macro name). As I said prior, I think this particular part of
> macro error reporting can do better as it knows more about what's going on
> - this should really be tied back up to the macro name at the top.
>
>
>
>
>>
>> I know where the problem is immediately because I looked at above error
>> and quickly jumped to the code that didn't work. Then I guessed it right
>> because I know what has been changed from Alex Release notes and because I
>> had recently inquired on this board about :or destructoring and probably
>> because I am a long time Clojure user. The problem is that :or in map
>> destructuring with namespaced keywords was not officially supported before
>> 1.9 (but sadly worked exactly opposite to how it is supported now)
>>
>
>> Compare that the more common story of someone who has not followed every
>> newspiece lately and just wants to upgrade from 1.8 to 1.9 - How could he
>> tell whats wrong from above error message? Following above error message by
>> looking up specs and following index paths like [1 0] is a manual process
>> that costs and feels like debugging a difficultly hidden bug. The
>> time/utility distance to a hand written macro assert like "Keys in :or
>> destructoring must be unqualified symbols" currently does not justify the
>> use of specs for such things. It's by far worse than the NPE Stacktraces
>> popping up from nowhere that one learns to value and utilize after a month
>> or so in Clojure.
>>
>> It seems that improving the error messages we can calculate from specs
>> data is something that more people should think about and improve for 1.9.
>> I'd be willing to invest time if needed / input is welcome. Alternatively a
>> way to integrate custom error messages into specs directly could also be
>> helpful.
>>
>> (But I still don't really see how above spec tells me that I shouldn't
>> use qualified symbols in :or destructoring - do you?)
>>
>> On Monday, August 22, 2016 at 5:08:57 PM UTC+2, Alex Miller wrote:
>>>
>>> I've added library related fixes related to core specs to an info page
>>> at:
>>>
>>> http://dev.clojure.org/display/design/Errors+found+with+core+specs
>>>
>>>
>>> On Sunday, August 21, 2016 at 8:24:20 PM UTC-5, Alex Miller wrote:
>>>>
>>>> On Sunday, August 21, 2016 at 5:28:57 PM UTC-5, lvh wrote:
>>>>>
>>>>> FYI, while I disagree with your conclusion (I think we should go fix
>>>>> libraries instead), I ran into the same issue just now for roughly the
>>>>> same
>>>>> reason, except the thing that pulled in an old version of core.unify was
>>>>> core.typed, which pulls in 0.5.3 through core.contracts.
>>>>>
>>>>
>>>> BTW, core.contracts was also updated to 0.0.6 last week to use the
>>>> latest core.unify.
>>>>
>>>> --
> 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.
>
--
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.
