On 26 August 2016 at 10:31, Colin Fleming
wrote:
> I agree that tidied up the error messages are much more understandable.
> Replacing things like "path" with a description of what it means goes a
> long way. My main issue with the original error which persists in your
> version is that the faili
I agree that tidied up the error messages are much more understandable.
Replacing things like "path" with a description of what it means goes a
long way. My main issue with the original error which persists in your
version is that the failing predicate really doesn't help much identifying
the probl
On 26 August 2016 at 03:11, Colin Fleming
wrote:
> Hi Rick,
>
> That looks really excellent, and is a huge improvement. Particularly in
> combination with Leon's proposed change which more precisely identifies the
> likely failing part of the grammar, this looks like a big win for not much
> extr
I'm not sure about that - I suspect it would still be useful even just for
surface forms, although it's probably not ideal to have two different modes
for when you have the data or not. I had assumed that, assuming that most
macro forms are spec'ed, most syntax problems would be encountered by the
On Thursday, August 25, 2016 at 9:11:39 PM UTC-5, Colin Fleming wrote:
>
>
> One thing that I think would help a lot would be if it were possible to
> show the actual text from the failing expression rather than pretty
> printing a seq representation of it. This would mean modifying the reader
>
Hi Rick,
That looks really excellent, and is a huge improvement. Particularly in
combination with Leon's proposed change which more precisely identifies the
likely failing part of the grammar, this looks like a big win for not much
extra effort.
One thing that I think would help a lot would be if
Thanks, Adrian. I'm unsure about the disrespectful part - as I mentioned,
discussions around community problems are always difficult, but they are
important. As with all internet conversations, of course, tone is
everything.
But since this is very well-trodden ground, and for whatever reason it's
On Thursday, August 25, 2016 at 8:00:37 PM UTC-5, Rick Moynihan wrote:
>
> I think one obvious area that specs error messages could be improved is
> with some basic formatting and cosmetic changes. If spec presented errors
> not as a wall of text and syntax but with some simple formatting it wo
I think one obvious area that specs error messages could be improved is
with some basic formatting and cosmetic changes. If spec presented errors
not as a wall of text and syntax but with some simple formatting it would
make a big difference to legibility.
As a starter for 10, why could we not ren
Colin,
FWIW, I think you're doing a great job of articulating your points (which I
largely agree with) and are providing great feedback for the core team and
community to think about. This conversation is supposed to happen as the
alpha versions are being iterated on.
But I think continually
>
> I really don't understand how you expect anyone to take your criticism
> seriously if you keep implying you're happily abandoning the language for
> greener pastures.
> Why would anyone developing Clojure look at anything you have to say at
> this point as anything less than trolling?
Because
Hi Gary,
Re the documentation: A lot of people have worked to make clojure.org
better, including changing the contribution model to be both easier and
more familiar.
That said, I don't doubt that is could be a lot better. In particular, the
guides section could expand to cover a lot of the "conv
After further consideration, I would like to back off the word:
"abomination". I have strong opinions about code, and strong opinions about
technical aspects of Midje, but I chose the wrong word in my original
statement. The technical definitions of words do not matter as much as the
connotations t
>> I also note that my library, Midje, is typically insulted on this
mailing list whenever a newbie brings it up. One of the contributors to
this thread has called it “an abomination”. There was no similar concern
about *his* tone. Because, I suspect, he's on the inside, punching out.
Yes, that wa
Over the years I've kind of started agreeing with what Brian's saying.
Much as I love/know clojure and the philosophy that bears its fruit, I
think spec's sideband error-handling is a great low-risk opportunity to
build in some 'easy'.
My team is moving from rails towards elixir after having serio
On Thursday, August 25, 2016 at 10:46:14 AM UTC-5,
adrian.med...@mail.yu.edu wrote:
>
> I really don't understand how you expect anyone to take your criticism
> seriously if you keep implying you're happily abandoning the language for
> greener pastures.
>
> Why would anyone developing Clojure
Brian, your concerns have been heard. Please keep in mind this is a work in
progress and that there is ongoing work that is not yet visible.
While I don't expect that the final endpoint of this work will be exactly
what you would design (or what you might see in other languages as our
goals and
I really don't understand how you expect anyone to take your criticism
seriously if you keep implying you're happily abandoning the language for
greener pastures.
Why would anyone developing Clojure look at anything you have to say at
this point as anything less than trolling?
Back on topic,
> On Aug 24, 2016, at 9:28 PM, adrian.med...@mail.yu.edu wrote:
>
> I do not think your tone and lack of constructive feedback to Alex's (and
> others) thoughtful responses is helping your case.
Probably not(*), though I would characterize the responses differently. They
are polite, and they
Hi Brian,
Not crazy at all! Spec errors are maps at the bottom, and IMO these maps
should flow anywhere we are making exceptions. This is already true for
the exceptions coming from spec.test, and we should make it true for the
macroexpand exceptions as well. (I actually prefer reading the map f
Brian,
The tone of your previous post is not constructive. Let's keep the
discussion about ideas, not people.
Thanks,
Stu
On Wed, Aug 24, 2016 at 8:46 PM, Brian Marick
wrote:
>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway
> wrote:
>
> 3. "Follow the inverted pyramid so people see what is m
I do not think your tone and lack of constructive feedback to Alex's (and
others) thoughtful responses is helping your case.
On Wednesday, August 24, 2016 at 8:46:47 PM UTC-4, Brian Marick wrote:
>
>
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway > wrote:
>
> 3. "Follow the inverted pyramid so
> On Aug 24, 2016, at 7:46 PM, Brian Marick wrote:
> So why not do it in the bottom layer? Is there some deep reason why only an
> unserious programmer would want information in anything other than the
> current clojure.spec order? (We’re talking here about reordering a list.)
An even crazier
> On Aug 24, 2016, at 8:39 AM, Stuart Halloway
> wrote:
>
> 3. "Follow the inverted pyramid so people see what is most important." This
> kind of thing is easily done in a layer above spec, e.g. a custom REPL
> printer for spec macro errors. Worth working on but not critical to getting
> sp
This is almost exactly the intuition behind the standard error reporting
heuristic for grammars involving alternations. It is a heuristic, but it
has to be since on a failure it's impossible to entirely accurately
determine the user's intention. But intuitively, generally the rule that
has managed
Hi Alex, I could track down why explain stops
early. http://dev.clojure.org/jira/browse/CLJ-2013
On Wednesday, August 24, 2016 at 11:33:43 PM UTC+2, Leon Grapenthin wrote:
>
>
> On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>>
>> predicate: (cat :args (* :clojure.core.specs
On Tuesday, August 23, 2016 at 3:27:28 AM UTC+2, Alex Miller wrote:
>
> 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
Hi Beau,
Yes. Nevermind and everyone should learn to read spec. :-)
That said, such customizations allow people to experiment and flesh out a
bunch different ideas in parallel.
Best,
Stu
On Wed, Aug 24, 2016 at 1:17 PM, Beau Fabry wrote:
> Just specifically on a custom REPL printer, wouldn't
Just specifically on a custom REPL printer, wouldn't that negate the
benefits Alex sees in people becoming accustomed to reading spec error
messages? If every error report from each different environment potentially
looks different? Also, from the position of a community maintainer Brian is
mos
A suggestion for making all errors better would be to give not only the
precise file and line _of the beginning of the top level form containing
the problem_, but a more precise line and column of _the part of the form
that spec is complaining about_. Multi-line forms are the biggest and
hardest t
Brian originally raised 5 points that were concrete & specific, and
therefore potentially actionable. That is usefully-shaped feedback, thanks
Brian! My take on those points, which I will recast in my own words:
1. "Loosen rules about ns form to match what people have actually done."
This is pre
Sure, at the end of the day I don't really care about thre require/:require
issue, it just seems a little incongruent with previous decisions which
have promoted backwards compatibility. I generally prefer increased
strictness, so I'm fine with the change. I do care about the error
messages, though
I agree Colin, this feels more like the beatings shall continue until
morale improves ;-)
More seriously, I understand the point of the musical instruments analogy
to be a reminder to programmers that learning a language and understanding
it in depth will increase your power and expressivity wi
I'm not anywhere near as deep into spec as would be needed to fully
understand this thread, but I will say that I agree with those who object
to the guitar analogy. That argument would work just as well as a response
to someone who complained about the difficulty of C++, or assembler, or
APL.
>
> But creating error messages that are optimal for a user with no knowledge
> or Clojure or spec is just not the goal.
This is a totally false dichotomy. No-one in this thread is asking for
that. This thread has several examples of expert Clojure users for whom the
error messages are incomprehe
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
The path is the series of tags you've traversed through the spec (when
there are parts in :or :alt :cat etc).
We will have more documentation on it but we've held off because it was
changing pretty regularly in early alphas.
A spec for the current explain-data is something like this (I'm just t
On Tue, Aug 23, 2016 at 7:45 AM, Alex Miller wrote:
> We expect Clojure users to become familiar with spec and its output as it
> is (now) an essential part of the language. You will see specs in error
> messages.
>
Is there any documentation to help users understand how to interpret the
error m
>> 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 Tu
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 wrote:
> So personally, I don't want ex
On 8/23/16, 7:45 AM, "Alex Miller" wrote:
> I'm absolutely not talking about making something hard on purpose
> and I'm not saying that making things easy to learn is bad. I'm
> stating an ordering of priorities.
…and this is why I think it’s more important that Clojure is as “simple” and
consis
As some other people have stated:
Its way, way premature to start worrying about the exact format of error
messages.
Given the facilities spec provides, its clear as day that vastly better
messages can be built on top. Or even forget messages: syntax highlighting
or source-code presentation can e
I do not have an idea of what the final end point will look like exactly. I
don't get the feeling that there is any answer that you will find
satisfying, so I'm not sure what else I can do for you. We expect Clojure
users to become familiar with spec and its output as it is (now) an
essential p
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 sw
> On Aug 22, 2016, at 7:50 PM, Alex Miller 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. […
On Tuesday, August 23, 2016 at 2:58:42 AM UTC-5, Andy Fingerhut wrote:
>
> 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?
>
No, although the exception itself from macroexpansion will have the
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 m
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 st
>
> The big syntax macro cases like ns or let are way past the "average" spec.
> ... I don't think it's fair to judge the general performance of spec's
> errors on just those use cases.
It might be true that these macros are larger than usual, but they're also
the cases that everyone will encount
On Monday, August 22, 2016 at 7:43:53 PM UTC-5, Colin Fleming wrote:
>
> I agree that the ability to get a machine-readable parse failure is very
> important for tooling. However I feel very strongly that the error messages
> that are printed by default on macro validation failures should be eas
On Monday, August 22, 2016 at 6:45:16 PM UTC-5, Oliver George wrote:
>
>
> I'm interested to see any discussion regarding this point. No doubt
> translating spec data into more friendly formats has been discussed.
>
> Getting the data right is clojure's problem. That's the concrete
> foundati
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 er
I agree that the ability to get a machine-readable parse failure is very
important for tooling. However I feel very strongly that the error messages
that are printed by default on macro validation failures should be easily
understandable, and the current ones are not. If we completely punt to
tooli
I'm interested to see any discussion regarding this point. No doubt
translating spec data into more friendly formats has been discussed.
Getting the data right is clojure's problem. That's the concrete
foundation and building blocks required for tooling. Seems like Rich has
done spectacular
> On Aug 22, 2016, at 11:23 AM, Leon Grapenthin
> 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 receive
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.
Stil
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 dis
That emacs joke gets my week started with some abdominal pain 😂😂
I support strictness 😬
Luc P.
--
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
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.ty
On Sunday, August 21, 2016 at 5:25:03 PM UTC-5, Brian Marick wrote:
>
> As an update. I’ve fixed the `ns` oopsie in Suchwow (one file), and the
> coincident `ns` oopsie in Midje (one file). But this happens when running
> Midje’s self-tests against Clojure 1.9alpha11:
>
> > Exception in thread
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.
> On Aug 21, 2016, a
As an update. I’ve fixed the `ns` oopsie in Suchwow (one file), and the
coincident `ns` oopsie in Midje (one file). But this happens when running
Midje’s self-tests against Clojure 1.9alpha11:
> Exception in thread "main" java.lang.IllegalArgumentException: Call to
> clojure.core/fn did not con
The documentation now includes the spec, which would explicilly mention the
symbol, so this would not be tacitly hidden as you suggest. David is already
working on porting these specs to ClojureScript so that issue is one we will
imminently face.
So again I will state: while the current spec do
I couldn't help myself...
https://xkcd.com/1172/
--
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.
I'd prefer getting rid of the symbol option. Some kind of deprecation
warning for a version or two might be an idea though.
On Sat, Aug 20, 2016, 10:51 PM Sean Corfield wrote:
> Or keep the stricter compiler and:
>
> 1. People who want to port to clojurescript will incur exactly the same
> cost
Or keep the stricter compiler and:
1. People who want to port to clojurescript will incur exactly the same cost as
they do now.
**2. People who don’t want to port to clojurescript and don’t want to move to
Clojure 1.9 will incur no additional cost.
3. Clojurescript maintainers will incur no a
On 8/20/16, 7:13 PM, "Colin Fleming" wrote:
> in this case it seems like the change breaks a lot of existing code
I disagree. Compared to the vast amount of Clojure code out there, I would
contend that this breaks very little code – and that code is arguably wrong in
the first place. Most of th
What about a compromise where you could opt-in or opt-out of checking macro
specs at compile time (via a compiler option)? It seems worth preserving
the correctness of the spec, without forcing all of the breakage.
Andrew Oberstar
On Sat, Aug 20, 2016 at 9:13 PM Colin Fleming
wrote:
> With resp
I think there's considerable scope to produce better error messages
automatically than what spec produces, and I hope that can happen for 1.9.
The error message produced by the code I demoed at the conj last year would
be:
Unexpected symbol 'require' at while parsing
namespace clauses. Expected :
With respect to preserving undocumented behaviour, while in general I'm in
favour of making compilers stricter, in this case it seems like the change
breaks a lot of existing code in ways that are impossible for library
consumers to fix themselves - they have to wait for an update to the
library, o
> On Aug 20, 2016, at 6:30 PM, Timothy Baldridge wrote:
>
> Brian, let's make it more concrete then...why should the Clojure compiler
> continue to support undocumented features that make code unportable?
Because:
1. People who want to port to clojurescript will incur exactly the same cost
Brian, let's make it more concrete then...why should the Clojure compiler
continue to support undocumented features that make code unportable?
On Sat, Aug 20, 2016 at 4:48 PM, Brian Marick
wrote:
>
> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote:
>
> I disagree (strongly) with your posi
> On Aug 20, 2016, at 5:26 PM, s...@corfield.org wrote:
>
> I disagree (strongly) with your position here Brian. I’ll try to explain
> clearly why but first a little background…
I too have felt the pain of having to maintain backward compatibility. However,
I’m reminded, in this case, of Mark
I
> wouldn’t wish that on any sane developer.
>
>
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>
>
> *From: *Brian Marick
> *Sent: *Saturday, August 20, 2016 7:58 AM
> *To: *clojure@googlegroups.com
> *Subject: *Re:
I disagree (strongly) with your position here Brian. I’ll try to explain
clearly why but first a little background…
At World Singles, we’ve always done multi-version testing against the stable
version of Clojure that we plan to use in production and also against the very
latest master SNAPSHOT.
On Saturday, August 20, 2016 at 9:58:14 AM UTC-5, Brian Marick wrote:
>
>
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> We discussed this before releasing the specs and decided to start on the
> strict side. That said, this is still an alpha and there is plenty of time
> to change our
On Saturday, August 20, 2016 at 9:40:21 AM UTC-5, Brian Marick wrote:
>
>
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> You left out this next important line too since it points you to exactly
> the file and line where the error occurs:
>
> , compiling:(such/sequences.clj:1:1)
>
>
> Th
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> We discussed this before releasing the specs and decided to start on the
> strict side. That said, this is still an alpha and there is plenty of time to
> change our minds prior to official release of 1.9 if that ends up being a
> catastro
> On Aug 20, 2016, at 9:03 AM, Alex Miller wrote:
>
> You left out this next important line too since it points you to exactly the
> file and line where the error occurs:
>
> , compiling:(such/sequences.clj:1:1)
This is interesting. Here’s why I missed it. I attach the error message I saw
f
On Saturday, August 20, 2016 at 5:17:59 AM UTC-5, Brian Marick wrote:
>
> Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out
> to have been a use of `ns …(require…` instead of `(ns …(:require`. Not in
> Suchwow, but in Midje. Unfortunately, the Suchwow file the bug report
Yesterday, a bug was filed against Suchwow under 1.9alpha11. It turns out to
have been a use of `ns …(require…` instead of `(ns …(:require`. Not in Suchwow,
but in Midje. Unfortunately, the Suchwow file the bug report pointed at *also*
had that typo - apparently I am prone to it - so adding the
81 matches
Mail list logo
