Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm not convinced that ignoring certain features for the sake of error messages would be helpful.</p> <p>For one thing, are the errors encountered by beginners really <em>that</em> different from anyone else? Just because I know how to interpret a "no Num instance for this absurd thing which is clearly not a numeric type" error doesn't mean I wouldn't appreciate GHC more clearly pointing out what bone-headed thing I've done to provoke such a message.</p> <p>I would suggest that the circumstances in which a beginner or an expert would be writing instances, or any other kind of "advanced" code, differ very little. The beginner, however, will be coding under those circumstances far less often, with an inclusive lower bound of "never".</p> <p>If one wishes to insulate beginners from arcane corners of the language, then make sure they don't encounter them at all. For instance (ha, ha), there's an argument to be made for avoiding type classes entirely when first introducing the language.</p> <p>I can't think of any cases where a more beginner-friendly error message, so long as it doesn't throw away information, would not also be more pleasant for everyone else as well.</p> <blockquote> <p>Suppose we were to make the local assumption that the programmer will declare <em>no new instances.</em></p> </blockquote> <p>Suppose we instead make the assumption that the programmer will declare no <em>orphan</em> instances where the class and/or type are defined by the Haskell Report. This assumption is most assuredly realistic for beginners and, in fact, seems reasonable as a general rule.</p> <p>Adding such an instance because of a compiler error at all is plausible in very few situations. With the glaring and galling exception of the anonymous writer monad (unless that has been remedied since I last checked) orphan instances for a standard class <em>and</em> type seems exceedingly unlikely, and one or the other should only arise when a library has unexpectedly overlooked a few instances, or is old and dusty enough to predate the prevalence of stuff like <code>Applicative</code> or <code>Foldable</code>. In any case, anyone who <em>does</em> want such an instance can be safely assumed to know what they're doing well enough to interpret GHC's error message, whatever it may be.</p> <p>But enough about that particular example.</p> <blockquote> <p>Are there other opportunities to reframe error messages on the basis of realistic simplifying assumptions?</p> </blockquote> <p>Very likely, but we're also very far from exhausting the space of realistic complicating assumptions!</p> <p>The point of the above digression on instances is that by using information already available to the compiler and heuristics that examine a larger context (e.g., where certain things are defined, to distinguish the above example from non-orphan instances) error messages could be improved in general.</p> <blockquote> <p>A follow-up thought: does the text of the existing error messages contain enough information to support such transformations, assuming a "configuration file" modelling the student?</p> </blockquote> <p>I really can't see this working very well except in the simplest and most egregious cases, the example you gave being a notable example. It could rephrase existing flavors of error, but beginners would benefit most from having more detailed/explicit information that the existing message may not contain. </p> <p>Consider two other error messages that are chronically vexing to beginners: complaints about matching "rigid type variables", and complaints about "infinite types". Rephrasing might improve those somewhat, but short of including a tutorial on polymorphism in each error message it's not going to much help a beginner fix their code, unless you can interpret the relevant expression and type well enough to be specific about the cause.</p> <p>Together with inspecting the source code a "translator" might have some legs, but I suspect modifying GHC directly will quickly become the easiest route. Generating error messages would be an interesting extensibility point, but I don't think this can be done with GHC's existing plugin infrastructure.</p> <hr> <p>The greatest obstacle to any of this, I expect, is not implementation. Rather, it's the decision of which heuristics would improve error messages rather than accomplishing the opposite. Without a base of objective data, this is something of an error-prone (ha, ha) guessing game. It would be very interesting to assemble a large survey of errors encountered by (primarily intermediate or novice) Haskell programmers and, most importantly, what actual <em>change</em> they made to resolve the issue.</p>
    singulars
    1. This table or related slice is empty.
    1. POWould error messages improve if we could disable features?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USC. A. McCann
    1. USC. A. McCann
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COInteresting points: thanks for taking the trouble to think about it. I'm given to believe that the Helium people have a large corpus of beginner errors. I think there is room to consider modelling "what the programmer is probably trying to do" when constructing an error message. Such models might be informed by things like specimen solutions, as well as by an estimate of student experience.
      singulars
      1. PO
      1. USpigworker
    2. CO@pigworker: Interesting; I've never used Helium and wasn't aware they might have such a thing. Stack Overflow itself is a not-inconsiderable source of data as well--amusingly, the "Related" links it chooses for this question already provide an excellent overview of such stumbling blocks. Perhaps examining such data would indicate places where filtering things for beginners would make sense, but I'm skeptical of the benefit until then.
      singulars
      1. PO
      1. USC. A. McCann
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload