>> It certainly doesn't require a 200MB jar, more like 300 lines of code,
including the parser itself.
I completely agree, what I'm saying is, if you start supporting my laundry
list of phonetic, spelling, and structural suggestions, your codesize will
quickly get much larger than 300 lines.
On Tue, Aug 23, 2016 at 1:16 PM, Colin Fleming <colin.mailingl...@gmail.com>
wrote:
> The error message I posted earlier comes right out of the parser with very
> little infrastructure on top of it. It certainly doesn't require a 200MB
> jar, more like 300 lines of code, including the parser itself.
>
> On 24 August 2016 at 02:21, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
>> So personally, I don't want extremely accurate suggestions in the core of
>> Clojure. Why? Because I think they will never go far enough and I have a
>> ton of features I want to see that can't (shouldn't) be in the core of a
>> language.
>>
>> I'll never forget the first undefined symbol I got in Clang after
>> switching from GCC. When I say "undefined local 'val' did you mean
>> 'vals'?". I was floored, what was this magic?
>>
>> When I sit down and write a laundry list of things I would like to see in
>> error reporting for spec:
>> - Spelling suggestions: "did you mean :require instead of :requir?"
>> - Type suggestions: "you passed a symbol did you want a keyword?"
>> - Phonetic suggestions: "you passed :color, did you mean :colour?"
>> - Structural suggestions: "you passed [[42]] did you mean [42]?"
>>
>> Most (all) of these are way too broad for inclusion in the core of a
>> language (imo), not to mention the problems you'd hit with multi-lingual
>> support. So I say to all that, give me data and let 3rd parties write the
>> libraries. I'd much rather have a 200MB "error reporter" lib in my
>> {:profiles {:dev ...}} than included in the clojure.jar.
>>
>> Anyway, that's my 2cents. And if someone doesn't write that library for
>> me soon, I may have to :)
>>
>> Timothy
>>
>> On Tue, Aug 23, 2016 at 7:47 AM, Brian Marick <mar...@roundingpegs.com>
>> wrote:
>>
>>>
>>> On Aug 22, 2016, at 7:50 PM, Alex Miller <a...@puredanger.com> 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.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
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.
