Clojurians Log v2

hey guys, just catchin up here

does anyone else fear the combinatorial explosion of “__ cannot be cast to __” errors?

might that class of errors be covered by the potential 1.9 release? (presuming it will check macro arg types)

@shaunlebron: Yeah, hopefully 1.9 will improve things a lot there.

It’s not clear what will actually be included though.

@cfleming: I was looking for a source on what exactly alex was working on in relation to errors, I couldn’t find anything

@shaunlebron: There’s basically no information. I’ve heard some rumours but nothing concrete. There’s a design page here which is more or less what I talked about in my conj talk: http://dev.clojure.org/display/design/Macro+Grammars

error-test there is the test repo I demoed which I sent to Alex.

link?

To error-test?

yeah, sorry

It’s not open, I was planning to tidy it up but have never had the time, and now there seems little point since it may or may not coincide with whatever they come up with.

sure

Actually, I’ll just open it up, one sec.

https://github.com/cursive-ide/error-test

I’m just going to update the README

for reference here, this is colin’s talk about improving error messages with grammars: https://www.youtube.com/watch?v=kt4haSH2xcs

thanks @cfleming

I’m not sure yet what the intersection between your macro grammars, elena’s error message work, alex’s 1.9 work, and this error cataloging effort

would be nice if someone had context in all those places

I just have a feeling that the problem trying to be solved by logging the myriad of causes for different exceptions may be solved by just working on an alternate clojure compiler with reader conditionals to perform runtime :pre and :post checks for functions and this other macro grammar stuff

Ok, readme updated.

I think to a certain extent they’re orthogonal.

The macro grammars solve a specific problem, but it’s a pervasive problem with horrible error messages.

Alex’s 1.9 work will probably be basically exactly that, with some other related things I’ve heard rumours about but don’t have any good information on.

This error cataloging effort, once the macro grammar stuff is in place, will be useful for figuring out which errors are problematic for people in practice, and will hopefully be a substitute for newbies for the intuition about what probably happened that experienced devs build up over time.

And also a place to discuss ways to improve those messages and perhaps catch those cases, either in tooling or Clojure itself.

Elena’s work is probably based on something like this catalog, and takes the errors identified in it and tries to improve their messages. In something like Cursive I could (and will) use that directly but can probably also add more functionality on top, i.e. perhaps identifying where exactly the error probably happened.

Note that macro grammars are good for more than just error handling, they hopefully also make writing macros much easier.

@shaunlebron: I was going to point you to issue 7 (prior art) but then I saw that you were the one who filed it 😉. That possible combinatorial explosion does suggest that we may want to consider some sort of regex-based solution the way that prior art did. The one thing that would argue against it is that sometimes there are common causes for particular flavors of that exception (eg I committed a page for "boolean cannot be cast to symbol," because new clojurians often hit that by forgetting the inner brackets around a require). But of course we could look for specific cases like that first & then fall back to the general " cannot be cast to ".