less scary error messages?

[jeisner]

Speaking of scary and unhelpful error messages like the ones from #30, I wonder if it could be made a little less scary? Words like FATAL and panic and illegal may trigger traumatic memories, and long hex strings have been known to trigger seizures.

DynaCompilerError:
FATAL: Encountered error in input program:
 Unable to plan initializers for rule(s):
   /home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:1-/home/jasoneis/.dyna/tmp/15766/f8207d93ff9ba46002ae41fd3e0d02c0840e84e5.dyna:1:14

Also, some planner failures say "This is almost assuredly not your fault" and others don't: see the examples on #30. How about saying this in both cases?

This rule is syntactically valid, but this version of the 
Dyna compiler doesn't yet know how to handle it, sorry.  
(Perhaps it's not what you meant to write anyway?)

[nwf]

The intent was that "this is almost assuredly not your fault" messages are due to internal invariant violations or assertion failures, while the rest are things we really expect to have happen on malformed input. I can try dressing it all up a bit, but the internals are only in so good a shape for reporting friendly errors.

[jeisner]

Yeah, I understood the intent, which is good. But the intent seems to be violated on the second error from #30, which says "this is almost assuredly not your fault" on a case that is not an internal error, but rather a planner failure:

DynaCompilerError:
Compiler panic!
This is almost assuredly not your fault!  Please contact a TA.
 Backchaining planner failed 

It's true that the incompleteness of the planner isn't the user's fault. But the above message seems to indicate an internal bug, which is misleading. I suggested specific language above for planner failures (I prefer it BTW to the language you used in the new commit referenced above).

[jeisner]

I've seen the "syntactically valid but ..." apology in cases where it doesn't apply. For example,

DynaCompilerError:
Encountered error in input program:
 Conflicting aggregators; rule <repl>
 uses '=' for a/0 but I had been lead to expect 'mean='.
Everything was syntactically valid, but we could not
see it through.

Conflicting aggregators is not syntactically valid. This one is the user's fault.

The message that I suggested on the first post was intended to be for mode failures only.