How about "contributions THEN structure them"?

I just edited the README with my own whiny newbie complaint about one of the earliest (and probably easiest-to-understand) error messages, a message that nevertheless stopped me cold in my tracks. Why was I stumped? Because I'm already a panicked deer in the on-rushing headlights of all I have to learn, as a newbie, about Haskell. I'm a month in, and I'm still doing copypasta examples. The dopamine surge of actually making something that feels at least slightly original still hasn't arrived. A month. That's never happened to me before, with any programming language. I still feel very little confidence about writing code rather than just copying it and changing it a little. Puzzling error messages aren't exactly helping.

So, let's not get bogged down in process design. How about instead putting a notice out everywhere that's conceivably relevant and seeing if anything comes in, just on the README? THEN get bogged down in process design. At least you'll be bogged down in designing for actual customers. I use the word "customers" advisedly. I can say from 20 years in business (and 20 years of mostly working in businesses) that nothing happens until you make the sale. In this case, "the sales pitch" has to be, "we're listening, you matter to us, please just complain about anything and everything. Don't hold back. Tell us what you really think." This, for lack of ability to actually deliver easier error messages until the GHC maintainers see enough critical mass to take the initiative seriously.

So, let's not get bogged down in process design. How about instead putting a notice out everywhere that's conceivably relevant and seeing if anything comes in, just on the README? THEN get bogged down in process design.

Thanks for your feedback.

I am doing my best to do exactly that, I'm also a bit busy and juggling (so slow-moving, deliberate, but a little slow). Other people in the ecosystem are too (we waited 3 - 4 weeks for a repo to be created).

I'm also a Haskell newb out in the big world like you, just trying to find my way, and don't like making stupid mistakes for efforts like this. So I don't disagree, but I am also going to do my best to take action after taking a moment to think it over, and check it out with others.

Probably also like you, I have work, a family, and a life to tend to. How busy you are fluctuates.

And I would guess also like you: I have passion for Haskell, and that propels me (I probably agree with you more than you realize).

That's why I'm also very welcome to review and help others make meaningful contributions to this effort (it's not blocked on me, it's taking it's shape).

My job here ATM, if I understand it correctly, is to understand the goals of the project, and to use that understanding in a way that helps to direct the efforts of many other people, creating specific types of change and action in the real-world, towards the fulfillment of those goal, so to that end, let's get going in that direction :)

We have a few things to get done:

define a way for haskellers (newbs/experienced/etc) to contribute notes/use-cases/code/feedback about specific error messages or problems they have run into.
create some useful documentation for newbs learning haskell, starting with the most painful or common blocking situations/messages.
define the suggested way of interacting with GHCHQ/devs, stuff we should do before engaging the devs, etc.
investigate what GHC already has for a test suite that exercises the various error messages.
make a list of all known/expected error messages
start a review of that list
- use that, to take note of what we should even review - defining some sort of evaluation criteria, and an overall rating (1-5 or something) for helping us navigate the full list
identify top 5 or 10 messages we'd like to see change (in GHC) on first, and define what needs to be done for those.
repeat and refine as we go

As someone who is frustrated by error messages:

would you like to share the info with us and split, or do you want to collaborate to some end on them?
if you have specific errors you want to collaborate on, I think the simplest and best place to start is an issue (one for each error), where we can discuss and understand the code/message/situation/use-case, and what to do about it.
At minimum, I'd like to see us form a searchable list of the most problematic errors for newbs, with some helpful info about them, with code examples of what the user may have and possible changes that are relevant, with links to other docs, so feel free to help me start and build that out in some form (even just defining the list you've run into as problematic is a great start).

Thanks @Yakushima, I look forward to working with you on this and improving other aspects of the Haskell ecosystem together.

The way I'd approach this, right now, is to just troll through various hacker fora searching on "Haskell" and maybe "error" and see what people have struggled with so far. And add links to those entries (with very brief summaries) to the README. How to sort things out is very much a function of having something to sort in the first place.

I suffer from the typical hacker temptation to go meta from the get-go, but that's "premature optimization" in almost all cases. When I catch myself in it, I think, "Better to invite ridicule by faceplanting out of the starting blocks -- but headed in the right direction -- than head in the wrong direction around the track because it looks like the fastest way to get to the distant goal." If people help you back up after sprawling, you're in the right community. If not, you're in the wrong one and you should just move on -- saving time in life.

And let me add: I was wikimanic for years. I've absorbed a lot of the ethos, but especially "Be Bold". Nobody should take Wikipedia too seriously anyway -- it's best seen as crowdsourced article writing with citations you should follow up on if you're really interested. So if you make a mistake, it's probably not going to kill anybody. Which isn't to say that some editors don't feel like killing each other sometimes. It can get quite Swiftian now and then.

"make a list of all known/expected error messages"

I'm just starting a wiki, which is suboptimal, but everything is, so ... the README.md PR is now cancelled, and what started on Discourse is now part of my permanent record, may God have mercy on my soul. I assume that wikis can be sent from a fork to the original repo . . . somehow.

Yea, "look for existing discussions, blog posts, rants, etc on error messages in haskell" is definitely a todo, I'll make it more explicit in our todos.

On the topic of structure and having something to structure, pre-optimization, etc. I don't disagree with you, though IDK if I am being clear: I am doing my best on it, what you see is what you get, I'm also just a bit slow moving. If you would like to take over the effort to do it as you see fit, I surely won't try to stop you. If you want to collaborate and split up the tasks, that would be super helpful. If you want to see what you can find in the community, for existing discussions, etc, that is very welcome and would be helpful.

All I ask is that for each specific error you would like to call out, please create a single issue/ticket in Github, clearly calling out that error. We can use labels to help with tags/filters. Ideally, the issue would include:

the full error in context,
the code used to produce the error,
discussion about what was confusing or unexpected about the error message
example code to resolve the issue, there may be several
discussion about the solution
review of documentation
possible improvements

Feel free to structure your initial tests/experiments/writings/etc as you wish, but do please help follow along and build out the minimal structures I'm doing my best to put in place.

Thanks for your efforts on this @Yakushima !

I'll copy your bulleted list to the root page of the wiki I've started on github, crediting you. (I'm very big on keeping a citation/link trail back to originators; a lot of my Wikipedia editing has been about rip-out/replace of plagiarism.) But I'll probably add this:

"Don't worry, be sloppy. We don't mean 'don't try'. But if time is short -- or you're just so terror-stricken by an error message that you don't know what to say -- it can be enough to just add the error message and maybe some code context. If you're so sloppy that we can't figure out what you're trying to figure out, we'll figure that out and delete your contribution, or substitute someone else's for the same error message. At least you'll have given us a clue that something needs to improve. And that's the most important thing here. This is a wiki. It's all about improvement, not perfection. The idea isn't to get it right the first time. The idea is to get something to improve. The great programmer Peter Deutsch once described programming as "debugging a blank sheet of paper." In every article about a problematic error message, there will be some "blank sheets of paper to debug." Be Bold. Be Great. Or, if you can't be so awesome. . . be incomplete, but at least offering something."

OK, done. Comments welcome, but I don't want to get too meta here. Expanding the list while improving the articles should take priority.

I'm a big fan of this work (that is: crowdsourcing ideas to improve error messages), but lack the time to be a leader here. I am very grateful that @ketzacoatl has stepped up to be steward, and thank you @Yakushima for also getting involved.

I've checked out @Yakushima's wiki, and I like the "Don't worry; be sloppy" ethos there -- along with the links at the bottom about specific error messages. So that these become more discoverable, what would you think about incorporating some of that ethos into the README and converting the pages about specific errors into Issues here on the main repo? I see the value in having a wiki page to e.g. collect examples of how errors might appear, but I think it's also valuable to have an Issue, as these can easily be subscribed to and can invite further commentary.

... lack the time to be a leader here.

The delay in replying should give you a sense of how my own time has become more sharply limited. My business is picking up to the point where my own Haskell coding project is #2 in priorities, and this leaves little enough time for anything else.

... converting the pages about specific errors into Issues here on the main repo?

Yes, this should be a goal: thread this effort into the more formal processes.

The error messages are impressively analytical. I'm wondering whether the GHC maintainers could be persuaded to add a flag that generates HTML links on vocabulary, leading newbies to concept-refreshers? The webified Try Haskell pages could then be adapted to show these these links, or even help bubbles on mouse-over (with yet more links as necessary.) A lot of my struggles with Haskell have been with error messages where my fuzziness on several Haskell concepts in error messages turns into a whole nebula of fuzz. To get to a capsule explanation in half a second per term could be a great confidence builder, and might even mean that the number of error messages requiring newbie-friendly revision ends up smaller.

With patience and persistence, we can make a big impact on these issues. Thank you for sharing your feedback.

I'm wondering whether the GHC maintainers could be persuaded to add a flag that generates HTML links on vocabulary, leading newbies to concept-refreshers?

I think we'd be happy to do this.... but it would take some significant changes within GHC to do correctly. It would also take a dedicated contributor to craft/maintain the pages. So it's not a matter of persuasion, but of reliable follow-through.

There is a good short-term checkpoint here: if there were a set of pages defining terms that appear in error messages, then we could encourage users to look up the term of befuddlement there. This approach lacks direct links from GHC messages, so it suffers in discoverability. But it would still be a help! Once established, GHC could perhaps give a link to a top-level index page somehow. I say "somehow", because I don't really want that link given to me every single time GHC produces an error. So some thinking about the UI may be helpful. I suppose there's no reason GHC couldn't store a little state (e.g. in ~/.ghc or local equivalent) saying whether or not the user has dismissed the hint.

Yes, follow-through. And I can't preach when I'm not practicing. It's not so much that I ran out of steam as that I had to duct more of my steam into my business.

There is a good short-term checkpoint here: if there were a set of pages defining terms that appear in error messages, then we could encourage users to look up the term of befuddlement there.

Well, there are various pages (mostly with anchor links) for keywords and the like. There is something that would help me as a newbie, but also for structure of something like a Wikidictionary for Haskell: a "Haskell conceptual dependency diagram." E.g., the users goes to a keyword or term of (Haskell) art, looks it up, and five words to the sentence, there's another befuddling term, but the user clicks on the link for that one and onward down to the core concepts if necessary. Ideally, there's also a very minimal, very clear, instructive example at each conceptual hop-point.

Hoogle isn't quite this. For example, you put "data" as a keyword into the search box, it vomits forth several pages. Typopedia is an inspiration but it's a lot more verbose than what I'm thinking of.

This

https://wiki.haskell.org/Keywords

isn't bad, but I'd have about four times as many links.

Since it seems that the code for the error messages is all in one place (as is the code written to test whether all error messages are generated), I think a sweeping change to GHC is unlikely -- though there might be some need to mark up the error messages and some preprocessing before they are emitted, if it's just a GHC compiler flag for whether to emit messages with links or not.

Ideally, this whole effort stays out of the hair of GHC maintainers as much as possible. Starting very decoupled then gradually tightening seems like the best strategy.

@Yakushima

Since it seems that the code for the error messages is all in one place (as is the code written to test whether all error messages are generated), I think a sweeping change to GHC is unlikely -- though there might be some need to mark up the error messages and some preprocessing before they are emitted, if it's just a GHC compiler flag for whether to emit messages with links or not.

GHC does not produce error messages all in one place, though we're inching closer to that goal. https://gitlab.haskell.org/ghc/ghc/-/issues/18516 is the master ticket, and a lot of work has already gone in. And, sadly, the GHC compiler flag idea is not so easy. How should the links be rendered? e.g.

Cannot match skolem (https://blahblah.org/blahblah) with expected
(https://blahblah.org/blahblah2) type ...

might barely be possible, though pretty-printing would be poor. On the other hand, the much nicer

Cannot match skolem [1] with expected [2] type

[1] https://blahblah.org/blahblah
[2] https://blahblah.org/blahblah2

is out of reach until we refactor the data structure we use to build error messages. This refactoring is in the plan, but it's not done yet.

Ideally, this whole effort stays out of the hair of GHC maintainers as much as possible. Starting very decoupled then gradually tightening seems like the best strategy.

Strongly agree here.

This is probably a good opportunity/moment to start a new issue (here in this project), specifically focused on including URLs in GHC error messages. That could then scope out what we would need or want to do to see that thru.

"Cannot match skolem (https://blahblah.org/blahblah) with expected (https://blahblah.org/blahblah2) type ... might barely be possible, though pretty-printing would be poor."

Why complicate it with trying to pretty-print URLs? The point of a flag for URLs is to pass error messages on to interfaces that make links in the text that a user can click on.

Compiler flag on:

"Cannot match skolem ...."

(Pretty-printing handled by HTML layout renderer)

Compiler flag off

"Cannot match skolem ...."

Or something. I don't know.

At this point, I'm suffering from a lot of Haskell Dread. Mostly because I'm trying to rewrite some Haskell code to be clear enough to understand, even though the authors thought "f" and "g" were perfectly good names for functions that actually do very specific (but still rather obscure) things. I guess they thought, "Hm, gonna need a function here. What's a typical name for a function. Ah, I know: 'g'."

Thanks guys.

I strongly believe that people who understand a subject well can explain it clearly.

https://www.youtube.com/watch?v=_f-qkGJBPts

If that was actually true, however, then the Haskell community must consist of a lot of people who either

(1) don't really understand Haskell as well as they pretend to understand it, or (2) could explain clearly but don't feel very motivated to be clear.

I'll assume it's #2.

I actually like explaining things clearly. And (as Feynman learned, and as he taught) being able to explain things clearly means you really understand those things. But if nobody wants to explain something clearly enough to me that I can explain it even more clearly to someone else, I'm not sure there's much point in getting more involved in the topic. A community that's more about "here's a more clever/elegant/abstract way to express it" rather than "here's a clearer way to express it" is . . . well, I just can't think of a clever, elegant or abstract way to express my reaction to that kind of community just now. And the only clear way to express it would also sound pretty insulting.

@Yakushima I would caution you against making assumptions about others, especially whole communities.

I don't usually engage in sweeping generalizations. In fact, I despise it when people do that. And try to catch myself at it. But the other day, I was saving a lot of tabs from reading about Haskell programming and managed to fill two pages of a spreadsheet with articles. And it occurred to me: I still can't write Haskell code with any fluency at all. Surely, by now, if there were writers who were really committed to making Haskell as simple and clear as possible, I'd have made more progress. Quite a few times, some treatment of some topic seemed like a great simplifying effort, but then I'd hit some example, with some term, and google on the term, and there'd be a definition with other terms, and no links on those terms, and . . . . oh, I see it: people are writing about what's become obvious to THEM. They are no longer capable of introspecting back to the mental state of the newbie. (Or, if they are, they don't consider helping newbies worth their time. Haskell was hard to learn, so it should be hard to learn!)

(Pretty-printing handled by HTML layout renderer)

Yes, exactly! We have no infrastructure to do so now, and it's not easy to add such infrastructure (but we're still planning on doing it). Right now, GHC communicates out by printing strings. Plain old strings. That's it. So, if it wants to label skolem with a URL, it has to do so by including the string of the URL in its output somewhere. A tool invoking GHC might then be able to render a link -- great. But the string still has to be in there somewhere, and so (for those users who don't use a tool to invoke GHC but just do so directly on the command line) there has to be a consideration of pretty-printing.

The new infrastructure I hinted at is described in a proposal, and it will allow us to output rich strings, with extra metadata attached to particular nodes. This would include URLs for links, as well as (for example) types for terms. Very worth the effort.

As for learning Haskell: yes, there are barriers here, and there is a variety of styles out there in the many tutorials, etc., on the internet. My suggestion to anyone learning a large, new technology (as opposed to picking up one new skill within that technology) is to use a book, not websites. (I've been an advocate for books in this way long before encountering Haskell.) No book is perfect, but if your goal is simplicity, then I recommend "Programming in Haskell" by Graham Hutton. It's relatively short, very well written, and explains the core of Haskell simply, giving you a structure around which to understand the language.

(Pretty-printing handled by HTML layout renderer)

, and so (for those users who don't use a tool to invoke GHC but just do so directly on the command line) there has to be a consideration of pretty-printing.

Only if you're a perfectionist. If somebody uses the proposed flag for GHC "links for error messages", on the command line, and the output looks like shit in their glass-tty interface well, then the problem isn't pretty printing. The problem is that they aren't using an interface that renders the error message as hypertext.

The perfect is the enemy of the good, and not least because it makes people myopic.

The new infrastructure I hinted at is described in a proposal, and it will allow us to output rich strings, with extra metadata attached to particular nodes. This would include URLs for links, as well as (for example) types for terms. Very worth the effort.

GHC doesn't even yet allow for printing error messages in languages other than English. How can GHC go back 30+ years and still be doing all error reporting in English? I find this baffling.

Why not start from a humbler position: Haskell isn't very nice to newbies, and it should be nicer, or else it's going to die? (If I see "a0" in an error message again, I'll scream.)

Thanks for the recommendation of Hutton's book, but, I have to say, in reading the Amazon intro to it, I see that "it requires no programming experience." This is actually something I hate about the way Haskell is usually presented. It's as if 99% of those coming to Haskell are NOT coming to it from another language -- often knowing several languages, in fact. It would be a lot easier to learn Haskell if the explanations were not offered in some conceptual vacuum, written out on some tabula rasa, but instead, more like this:

"the concept of blah is like foo in Javascript or bar in C++/Java, but with these differences . . ."

And explanations like "When we use the term 'instance', you're instantly confused, because you probably think of 'instance of a class of object, like in Java or C++', perhaps. But we don't mean anything that concrete. Sorry. No, really, we ARE sorry. We flew up our own asses for a long time there, and we're still making our way back down."

On the beginners list, I asked for a one- or two-page conceptual dependency chart for Haskell. I thought it would be handy for keeping my head straight about Haskell terminology.

Because of what's been called Male Answer Syndrome, however,

https://en.wiktionary.org/wiki/male_answer_syndrome

I got these two answers:

(1) Could you instead ask some specific question about a specific problem you're having? (2) Learn lambda calculus

I'm not making that up.

Why not start from a humbler position: Haskell isn't very nice to newbies, and it should be nicer, or else it's going to die? (If I see "a0" in an error message again, I'll scream.)

It isn't, you are right about that, and I'd agree whole-heartedly. It's also hard to do something about it, but it's still worth making an effort. The challenge is figuring out how and what you'll put your energy towards. Or don't, and that's fine too.

(1) Could you instead ask some specific question about a specific problem you're having?

I have seen that a fair bit as well, though I believe part of that comes as a result of haskell having an incredibly large swath of topics to cover (at least if you want to do anything real-world, and you are having a difficult time piecing it together). Mentors don't have all the time to explain everything, so they ask what you are having a problem with right now so they can help you make meaningful progress with what is immediately relevant. Over time, you will cover more and more of what you need to understand. Part of this just takes patience.

At the same time, better learning materials are sorely needed, but it's hard to do without a somewhat central authority backing it and pushing it, not just to completion, but marketing and keeping it useful/valuable/relevant over time. And not enough haskell people can agree on the cardinal directions for that to get anywhere, so here we are.

We can complain about it, ignore it, or do something about it, which again leads us back to the challenge of figuring out what is a meaningful use of our time.

Getting back on topic, and speaking for myself, as I write more haskell again, I'll have more to actively contribute to this project.

"Mentors don't have all the time to explain everything" -- But I was just asking for a diagram of concept dependencies!

Recently, what's called the Haskell "community" seems more like feudal social relations than anything else. To be accepted into the social order, you have to be taken under the wing of a friar at the monastery, or be inducted as an apprentice in the craft guild. Scholasticism, cottage industries -- there are reasons why these fell by the wayside. Now it's science, and capitalism. Science says something is better if it's truer. Capitalism says something is better if it's more profitable. Haskell is pretty obviously not very profitable. So, can someone prove to me, scientifically, that Haskell is at least "truer"? Better in some measurable way?

While I wish it were different, at least in my experience, (and WRT learning haskell) mentorship increased my odds of figuring out where I was stuck and what on. It helps me keep positive and focused and working in some sort of positive direction.

I don't disagree with your conclusions, and I agree it could/should be better, but I'm doing my best to share with you a solution-oriented perspective, so I suggest mentorship as a way to help you thru the initial struggles, and reduce some of the frustration you may experience.

An alternative is to scale back what you are trying to do, until more things are more clear and well-understood. For me, for example, that meant focusing on types, function definitions, imports, exports, modules, builds, cabal/stack, language pragmas, records and record field names, program structure, and the associated error messages with those. I have had to minimize what I do in haskell to fit my ability, and scale it up at a rate that was reasonable.

In practice, when you have only a little experience with python, you can still pound your way thru real-world problems (such as interacting with a web service api and manipulating some json to decide how to execute some other tool) and all at once, at least more so than when you have only a little experience with Haskell. Trying to solve too many problems all at once in Haskell can be overwhelming. At least for me, I need to breakdown what I want to do into smaller pieces, get them working individually, and then (separately) figure out how to connect those working pieces together to each other, and often one at a time. The error messages would be more managable along that path as opposed to when trying to solve 3 of those problems all at once.

At least for me, I continue to use Haskell because I'm seeing / experiencing a slow but steady improvement in my experience and delivery speed "getting things done", for when I need to reach towards a general programming language as a tool to get that thing done.

I'm not learning Haskell as a character-building experience. I found some code that parses something like natural language in what seems to be a way that's flexible enough FOR natural language.

http://web.cecs.pdx.edu/~mpj/pubs/aug.html

I'm trying to understand it. But I'm starting to think that the approach didn't take off because it got associated with Haskell, which is associated with this scholastic-priesthood/craft-guild community that tends to eke out its insights in mentor relationships.

In some ways, Haskell seems (if anything) distinctly sub-optimal as a language for this particular parsing purpose. For example, the algorithm depends on triangular-array data structure, but in Haskell you're forced to represent that as a list of lists. (And since each element is also a list, there's code for a list of lists of lists. Readability sucks. And this isn't helped when you have authors who think "g" is a good name for a function that does something or other that probably doesn't start with the letter "g".)

This representation of the data structure also means there are O(n) operations required in some cases where you'd have O(1) with more direct representation. Of course, the actual authors of the code are pathetic amateurs with no intellectual credentials whatsoever, and that's the only explanation, because . . . oh, except, oops, no: it's Paul Hudak and Mark Jones. So, exactly what WAS their excuse? Is it "We're supposed to avoid success at all costs"?

Under feudalism, if you could work your way up into a monastery or into the priesthood, or to journeyman at least in a craft guild, life wasn't so bad. You were up and out of subsistence agriculture. It was a way to feel better about yourself. But you were moving up in a social order that was pretty much "fuck everybody else down there, they aren't worthy."

Is there something like scientific proof that Haskell is actually a good programming language? If so, how is it better? By what measures that actually matter?

I'm not trying to learn Haskell to become someone who writes in Haskell, whoa, hey, look at me! I'm trying to learn Haskell to get something done.

@Yakushima you've been already asked not to make unsubstantiated assumptions about the whole community. The only thing your comparisons reveal is that you may wish to learn more about the subject.

GHC doesn't even yet allow for printing error messages in languages other than English. How can GHC go back 30+ years and still be doing all error reporting in English? I find this baffling.

Just curious, which languages do support translating error messages? I spend most of my life in non-English speaking countries and seen none.

Haskell is pretty obviously not very profitable.

Why? Many people (including myself) profit from writing Haskell.

I'm trying to understand it. But I'm starting to think that the approach didn't take off because it got associated with Haskell, which is associated with this scholastic-priesthood/craft-guild community that tends to eke out its insights in mentor relationships.

You are making too many deductions from a single 26-year-old bleeding-edge research paper. It was never meant to be a 101 engineering manual or a beginners' introduction to Haskell. No surprise you are struggling with it, but this will be pretty much the same with any research paper on unfamiliar subject.

And since each element is also a list, there's code for a list of lists of lists. Readability sucks.

Are arrays of arrays of arrays more readable to your taste? How so?

This representation of the data structure also means there are O(n) operations required in some cases where you'd have O(1) with more direct representation. Of course, the actual authors of the code are pathetic amateurs with no intellectual credentials whatsoever, and that's the only explanation, because . . . oh, except, oops, no: it's Paul Hudak and Mark Jones. So, exactly what WAS their excuse? Is it "We're supposed to avoid success at all costs"?

Did you read the paper in full? Are you sure that authors experience a performance hit because of the lack of arrays?

There is actually a simple pragmatic reason: the paper was written in 1995, long before arrays were standartized in Haskell Report 1998. As I said, an arbitrary old paper is not the best gateway to modern parsing techniques in Haskell.

Is there something like scientific proof that Haskell is actually a good programming language? If so, how is it better? By what measures that actually matter?

No.

Just curious, which languages do support translating error messages? I spend most of my life in non-English speaking countries and seen none.

No language supports it. Compilers support output of error messages in various languages. In fact, since I'm on Japanese Windows, and Microsoft downloaders make supposedly-convenient assumptions by reading OS environment variables, I've struggled to download versions of Microsoft compilers that don't give me syntax errors in Japanese. (But I read Japanese reasonably well, so in some cases I've given up.)

Gnu tools? They made localization a priority, it seems.

https://stackoverflow.com/questions/869309/selecting-message-language-in-gcc-and-g

Haskell is pretty obviously not very profitable.

Why? Many people (including myself) profit from writing Haskell.

You missed my "very"?

Also, "profit" isn't "making a living." Profit is a firm-level accounting number: revenue minus costs. Barclays makes a profit. You make a living, working for Barclays.

There's a Haskell wiki article about use of Haskell in the private sector. Lots of links. Most of them dead now. I don't think this is a wild coincidence.

And, having a PhD in number theory and interest in medieval archaeology is strangely consonant with this view I'm developing of the Haskell community as something more like a scholastic monk community and/or a medieval craft guild mentality. You're very expert in something that most people have a very hard time understanding, and you like it that way, when it gives you a comfortable, safe niche in a feudalistic hierarchy. Enjoy the comfort, while you craft what Warren Buffett warned were "weapons of mass financial destruction," and of course, we're all still living with the consequences of the last destruction.

You are making too many deductions from a single 26-year-old bleeding-edge research paper.

Earlier, I wrote that I recently collected all my Haskell links from tabs into a spreadsheet. There were dozens. I'm on some fora, and a mailing list for beginners. I'm not extrapolating from one slightly obsolescent paper.

It was never meant to be a 101 engineering manual or a beginners' introduction to Haskell. No surprise you are struggling with it, but this will be pretty much the same with any research paper on unfamiliar subject.

Computational linguistics is not "an unfamiliar subject" to me. I've been on it, off and on, for the better part of a decade.

What's unfamiliar to me is Haskell, despite all my efforts to learn, which have yielded far less fluency for the effort expended than for any of about a dozen programming languages I've learned, since starting programming in my teens (and I'm 65 now.)

And since each element is also a list, there's code for a list of lists of lists. Readability sucks.

Are arrays of arrays of arrays more readable to your taste? How so?

Yes, "A[i][j][k]" is for some strange reason more readable to me than probing into lists of lists of lists. Gosh, I wonder what's wrong with me? Oh, I know: I've been programming for most of my life, in languages where there are far more concessions to readability.

Did you read the paper in full? Are you sure that authors experience a performance hit because of the lack of arrays?

I have read the paper in full about five times, because it's the only source of clues about how the code actually works. The code seems to have been written by people who apparently thought their code was intuitively obvious, once you get their rough sketch of the main data structure.

Performance? In code that seems to waver back and forth between presenting the procedure in terms of data structure traversal and in terms of function results (giving me something more like double vision than parallax view), I see "transpose" and "reverse." From what I can tell, the "transpose" is effectively about changing the direction of traversal through the array, but why there's a list reversal in there too still baffles me. Even with lazy evaluation taken into account, you're going to be traversing lists, consing, and creating garbage that wouldn't happen with direct addressing of an array.

There is actually a simple pragmatic reason: the paper was written in 1995, long before arrays were standartized in Haskell Report 1998. As I said, an arbitrary old paper is not the best gateway to modern parsing techniques in Haskell.

Ah, thanks for that. Oh, hey, there's a Gentle Introduction to arrays in Haskell, and it starts SO gently:

"Ideally, arrays in a functional language would be regarded simply as functions from indices to values, but pragmatically, in order to assure efficient access to array elements, we need to be sure we can take advantage of the special properties of the domains of these functions, which are isomorphic to finite contiguous subsets of the integers."

Here, let me gently hit you over the head with my math hammer.

I'm not interested in modern parsing techniques in Haskell wherever they are oriented around creating more specialized languages for programming. The problem area here is parsing natural language (and ultimately, in the only way that's really possible: by digging into the semantics of words.) It's not the same problem. Programmers who think the differences must be superficial have only a superficial grasp of linguistics. Programmers who think it can be mathematicalized should go talk to Chomsky -- he finally gave up.

Is there something like scientific proof that Haskell is actually a good programming language? If so, how is it better? By what measures that actually matter?

No.

Well, there is one largely anecdotal but nevertheless overwhelming measure that people seem to agree on: Haskell is hard to learn. And as Haskell slowly drifts down the ranks in programming language popularity, it's safe to say it matters.

I think the community is part of the problem. Somebody who thinks it's "gentle" to introduce arrays by reference to array indices as "isomorphic to the finite contiguous subsets of the integers" is not part of the solution. They are part of the problem. If newbies look up to gurus who write this way, they are simply reproducing the problem -- but apparently at ever-lower reproductive rates.

From glancing onward in that "gentle" introduction, it seems Haskell has standardized on array indexing using association lists (vectors of index integers mapping to elements). This would probably be even more of performance hit compared to lists of lists for 2D arrays. So, while I did learn something -- Haskell sort of has arrays -- it was probably five minutes of my life I can't get back.

Abstract mathematical terms from the get-go, and an extraordinarily pompous writing style ("Two main approaches to functional arrays may be discerned...." -- oh yeah?)

How about this, for gentle:

"If you've gotten this far, you must already know that Haskell can be pretty idiosyncratic in how it expresses even some of the most basic structures in programming. We're sorry to report that arrays are no exception. But at least Haskell has them! For starters, they aren't really part of the language, even if you include Prelude as 'part of Haskell'. You have to import the Array module. Then there's indexing: you write "a!7", not "a[7]". One of these days we'll try to find out why '!' was chosen. For now, let's just limber up with a very simple example you can get up and running in under a minute."

There's a Haskell wiki article about use of Haskell in the private sector. Lots of links. Most of them dead now. I don't think this is a wild coincidence.

I assume you are talking about https://wiki.haskell.org/Haskell_in_industry This is basically an append-only log, ranging 15 years back. Most of the entries are outdated simply because most of the companies founded 15 years ago either disappeared or at least changed their website. This is true for any other language or technology as well.

And, having a PhD in number theory and interest in medieval archaeology is strangely consonant with this view I'm developing of the Haskell community as something more like a scholastic monk community and/or a medieval craft guild mentality. You're very expert in something that most people have a very hard time understanding, and you like it that way, when it gives you a comfortable, safe niche in a feudalistic hierarchy. Enjoy the comfort, while you craft what Warren Buffett warned were "weapons of mass financial destruction," and of course, we're all still living with the consequences of the last destruction.

I'm quite happy to discuss my personality, but I think it does not belong to this thread. FWIW you misread my character: I've been preaching (sic!) all my life that category theory, homotopic type theory, lambda calculus and other esoteric subjects are rather a distraction for a working Haskell developer.

Oh, hey, there's a Gentle Introduction to arrays in Haskell, and it starts SO gently:

You seem to be predetermined to pick up the most ancient manual possible :) I'm sorry for this experience, but this was written back in 1998 for an audience with a very different background to yours. It was important to explain to an academic reader why we decided to bother with arrays at all, when in theory this is a completely solved problem.

Could you possibly give a try to https://www.fpcomplete.com/haskell/library/vector/ ? I think it will be much more to your liking.

"If you've gotten this far, you must already know that Haskell can be pretty idiosyncratic in how it expresses even some of the most basic structures in programming.

Do Japanese grammars ever apologise to readers for using non-Latin characters to express even some most basic words? ;) Why you expect Haskell to be sorry?

@Yakushima,

I'm not trying to learn Haskell to become someone who writes in Haskell, whoa, hey, look at me! I'm trying to learn Haskell to get something done.

Me too, and I'm interested in making it better for people like us.

Can you let me know what practical next step I can help you with, or for which you would like to work together on?

I'm not sure I can keep going in this circle - I am simply looking to offer support and assistance in ways I can and which will meaningfully help you, but I'm starting to wonder if I'm just wasting my time.

It seems this thread has wandered away from anything about this particular repo and its goal of improving GHC's error messages.

Are there actionable items here, in regards to this repo? If not, we should close the ticket.

As for the debate above: you're welcome to continue it -- especially if it avoids broadly categorizing all Haskellers as uncaring pointy-headed theorists -- but I humbly ask that you don't continue it here, as it's much more about educational materials for Haskell than about error messages produced by GHC. Thanks.

Since @goldfirer has called to return to the topic more concretely, let me tell you what my revulsion about error messages is about today. After all, Haskell is a day-to-day struggle for me. But then I'm afraid I'll have to subject you to yet more of my Pop Sociology of Programming, because I think my struggles really do relate to the social order of the Haskell "community."

In the code I'm slowly rewriting for clarity as I understand parts of it, there's type signature for a function that implements a big part of the (naive) algorithm for Applicative Universal Grammar parsing. In my still-somehow-working rewrite, it looks like this:

app :: (Typed_Tree -> Typed_Tree -> Tree) -> Typed_Tree -> Typed_Tree-> [Typed_Tree]

This is very baffling for me, because it's called like this:

app After before after ++ app Before after before

After and Before are constructors. "before" and "after" are of type Typed_Tree. And the function body is basically a list comprehension of type [Typed_Tree]. Seemingly very simple. So why this amazingly cantilevered type signature?

So, I think: OK, why don't I try other type signatures that seem more plausible to me. Maybe the error messages will give me clues. (Or maybe super-intelligent dragonflies will pour out my ears and sing Taylor Swift hits in chorus.)

First error message (of three)

"Couldn't match expected type ‘(Tree, [Type]) -> (a0, [Type]) -> a1’ with actual type ‘(Tree, [Type])’"

And I'm in despair. I'm probably suffering from what linguists call "language interference" -- e.g. incorrectly mapping the semantic range of one English word that I take as an approximation of the meaning of a word in Japanese, but only befuddling my Japanese listener.

Unfortunately, it's like the Japanese speaker responds with elaborate questions using Japanese grammatical terminology that I don't know.

Is there really no better way to say it?

I think again, "Well, if I had a conceptual dependency diagram for Haskell, a chart I could put on the wall over my desk, maybe I could get my head straight." But then I remembered the two answers I got when I asked on the Haskell beginner's list where I could find one of those. I'll summarize these as "Could you give me a specific question to help you with?" and "Learn lambda calculus."

Hey, thanks, Haskell community! Now I've heard from the sympathetic craft-guild journeyman who feels bad for the poor newbie apprentice, but who can't actually show me the shop's chart because apparently there isn't one. (Of course there's no such chart! Why give away our trade secrets to random visitors!) AND I've heard from the monastery theologian who sees the problem as the fact that I didn't start at (mathematical) square one. It's like having a copy of Thomas Aquinas' Summa Theologica dropped dustily on my desk, just because I asked, "What's the big picture here?". And I've heard from no one else.

I assume you are talking about https://wiki.haskell.org/Haskell_in_industry This is basically an append-only log, ranging 15 years back. Most of the entries are outdated simply because most of the companies founded 15 years ago either disappeared or at least changed their website. This is true for any other language or technology as well.

So, instead of turning from an append-only log into an actually-supported wiki article, it . . . dies. That is a whole message in itself, as far as I'm concerned. REAL communities pitch in on a wiki to improve articles and keep them updated. Is there really a community here? Or there something more socially hierarchical going on?

I've been preaching (sic!) all my life that category theory, homotopic type theory, lambda calculus and other esoteric subjects are rather a distraction for a working Haskell developer.

Well, if so (your whole life? really? Looks like you got a PhD only a few years ago, and didn't start programming in Haskell until after that), it seems the preaching is not getting through.

I looked around for how category theory mattered, and I ended up at some video where Philip Wadler is supposedly talking about "category theory for the working hacker". I gave up about halfway through, because he wasn't saying anything obviously relevant to the working hacker. (Also, despite his claims that he went through three drafts on his handwritten slides, they sometimes didn't match what he was saying. Also, he shouts a lot, and for no obvious reasons.)

Oh, hey, there's a Gentle Introduction to arrays in Haskell, and it starts SO gently:

You seem to be predetermined to pick up the most ancient manual possible :)

It was the first link I got from googling "haskell" and "array." Which also seems a message in itself: PageRank is supposedly more-or-less popularity-based. If there was a great treatment of arrays in Haskell, for newbies, why didn't it bubble to the top long ago?

I'm sorry for this experience, but this was written back in 1998 for an audience with a very different background to yours.

It touts itself as "gentle." By that, I assumed, it was "Haskell for Experienced Programmers who found the language definition document baffling." But I didn't just assume. I checked. When I checked, the intro said this:

"Our goal is to provide a gentle introduction to Haskell for someone who has experience with at least one other language, preferably a functional language (even if only an "almost-functional" language such as ML or Scheme)."

OK, I learned Lisp, and later, Erlang. I should be good to go, right? Nothing in there about how mathematically prepared you should be.

And math is not really my big problem anyway. I took computing theory (recursive functions and effective computability) from this guy

https://en.wikipedia.org/wiki/Eugene_Lawler

and learned it well enough to grade homework when the same course was subsequently taught by this guy

https://en.wikipedia.org/wiki/Richard_Lipton

I got better acquainted with Skolem and Herbrand (and finally, though time was running out in the course) with Godel, through this guy

https://math.berkeley.edu/people/faculty/john-w-addison

I loved math. But decided that computer science made more sense as a career. (Spending your teen years in a family under bankruptcy protection sharpens the mercenary mind wonderfully).

What I hate: mathematical snobbism. If I learned anything from Marina Ratner

https://en.wikipedia.org/wiki/Marina_Ratner

and Gerard Debreu

https://en.wikipedia.org/wiki/G%C3%A9rard_Debreu

it was how to NOT teach that way, even in approaches to higher-math subjects.

Could you possibly give a try to https://www.fpcomplete.com/haskell/library/vector/ ? I think it will be much more to your liking.

Looked. And there it is again: not starting from the simplest possible example.

"Since we're about to jump into a few sections of descriptive text, let's kick this off with a concrete example to whet your appetite. We're going to count the frequency of different bytes that appear on standard input, and then display this content."

What follows is a page of code, one that unfortunately brings in monads. The panicked newbie: "Oh, no, monads, everywhere I look, even for something as simple as arrays!"

Do Japanese grammars ever apologise to readers for using non-Latin characters to express even some most basic words? ;)

Why should they? I didn't apologize for English spelling, in my (brief) experience of teaching English in Japan. (Though I did offer explanations -- after all, English is, to a good first approximation, mispronounced German with a lot of mispronounced French on top, with mispronounced borrowings from numerous other languages.)

Japanese is a useful language with ~120 million native speakers. Haskell, on the other hand, has been described by none other than Simon Peyton-Jones as "useless." And he wasn't entirely joking. I plug onward only in the hope that it's not quite as useless as it might seem, at least for natural-language lexical semantics. I've even thought of how I'd try to sell scholars on Haskell, in that branch of linguistics.

"Haskell in plain English: A primer for the lexical semanticist" https://docs.google.com/document/d/1GIDWMbFBAaOZc-jxOu1Majt6UNzCpg4vxMGeydb421M/edit

But I really wonder if that's going to come to anything. Especially since I'd be "mentoring" people who'd have to cope with Haskell error messages.

Yes, natural languages pick up a lot of cruft as they evolve, and they don't drop much of it because of cultural and economic momentum. When designing a programming language from scratch, however, there isn't any such excuse. A programming language defines, in effect, a user interface to the bare metal. Error messages are an extension to that user interface. User interfaces that are not designed for usability, but instead just to satisfy some abstract internal vision of the designers tend to fall by the wayside.

There are good historical examples. Smalltalk fetishized objects in class hierarchies, and to be completely consistent with that vision in its syntax, it ditched already-idiomatic operator precedence (and a fair amount of performance.) It enjoyed a brief vogue in the financial sector, but mainly because, for a while, it was the best GUI prototyping environment around -- nothing to do with the language per se. Lisp fetishized list structure, and similarly imposed it on syntax. While I have little love for Perl, Larry Wall had it right about LISP. He responded to criticisms of Perl as looking like "TTY line noise" with "LISP looks like toenail parings in oatmeal." Haskell seems to have done something similar at the type/function level. It does look pretty extensible, so maybe I can come up with something more syntactically flavorful for my linguist audience.

In any case, I expect Haskell to be a hard sell, no matter how much brown sugar and blueberries I sprinkle on top. For the error messages, I'll only be able to apologize, and explain -- IF I can. And right now, often as not, I can't.

Why you expect Haskell to be sorry?

For the same reason I'd apologize to customers for some delivered software with a crappy user interface. "I tried to tell our developers that users would find this interface strangely and unnecessarily hard. They ignored me. But look, there's value here anyway!"

The Japanese owe nobody an apology for how they adapted Chinese characters. I don't owe anybody an apology for English spelling. Natural languages (and to some extent, their writing systems) are more like natural phenomena. They are what they are, and they evolve somewhat democratically. The failure of constructed languages to catch on (e.g., Esperanto, and all the way up to the latest fad, Toki Pona) is just evidence for language as a natural phenomenon that evolves generally, under user pressure, and not so much in the direction of logical consistency and rigorous patterns as in the direction of usability, baggage and all.

But when IS an apology in order? When I finally (with regret) stopped studying English composition, my last professor was a man with a PhD in Rhetoric from U.C. Berkeley. He told us that all expository writing is rhetorical, and all good expository writing starts with an "apologia." English is the ultimate bastard language, and the word "apology" is a bastardization of the original Latin: "defend what you're going to say before you say it." But that can include a concession to the reader that what you're defending DOES have its faults. When a language does have faults, to not admit them from the outset is fundamentally dishonest. It means the reader is going to encounter a stream of nasty surprises.

Reading is harder than listening. It's not enough to say, "I wrote all this, so it must have been worth my effort, and I'm a University-Registered Smart Person, therefore you should read it." It doesn't excuse you from basic laws of rhetoric: start with an apologia for your claims.

And, as has been noted by thinkers over and over, extraordinary claims require extraordinary evidence. Haskell is at certain extraordinary extremes in programming language design. How do you justify them, and how do you justify your choices at the lexical level (e.g., keywords, etc.)?

The problem isn't limited to the core language. I've read a number of descriptions of monads in Haskell. Most of them just dive right into it, apparently under the assumption that the reader has already been persuaded that monads are useful and cool, and besides, knowing Haskell (and monads) marks you as a Really Smart Programmer. I think I have yet to read a defense of monads as actually adding a lot of value. I'm pretty sure I would have remembered such an essay, had I run across it. And for that matter (and to take it back to where this note starts), I have yet to read a defense of the use of algebraic terms like "a0" and "a1" in Haskell error messages, without at least some interlinear glossing of what they actually are. Even Learn You a Haskell for Great Good counsels the reader to not panic upon seeing that.

But why hasn't this problem been addressed in the re-design of error messages after all these years? I think it's something that my perhaps-too-sweeping characterization of the "community" would explain: there's really something like a feudal order of relations in the community. Learn lambda calculus -- it's your ticket to being considered for further theological study, and maybe you'll graduate to full monkhood someday! Learn monads -- it's your ticket to being seen as at least journeyman in our craft guild! And above all, never apologize. Because, well, if you know Haskell, you're above all other programmers in the Great Chain of Tech Being. Stay above it all.

Could you possibly give a try to https://www.fpcomplete.com/haskell/library/vector/ ? I think it will be much more to your liking.

At this point, no.

When I get some code working, and the next task is to fully understand it, I start slowly rewriting it for clarity, as I (slowly) gain understanding of what it actually means. After full understanding, I often feel confident about rewriting it with more appropriate data structures. My hope was that, after full understanding, I could keep going with the existing code, just by wrapping existing functions to bring in a clearer left-triangular-array access interface. Then refactoring toward the higher-performance data structure. I'm not so confident about that now.

With this project, I started with a good-faith assumption: the data structure choices were appropriate. The paper doesn't exactly contradict that assumption. As I gained understanding, however, I see the 1995 victory cry must have been more like, "Hot damn! It IS possible (just incredibly clumsy) to implement this in Haskell!" (It's a "dancing elephant" -- the amazing thing is not that it dances gracefully, but that it dances at all.) Then they left the "incredibly clumsy" part out of the paper.

I've found only one other stab at using Haskell within the AUG linguistic framework, apparently follow-on work, and it addresses a notoriously difficult problem in natural-language parsing: long-distance dependencies, the Sypniewski paper cited here:

https://en.wikipedia.org/wiki/Applicative_universal_grammar#cite_ref-Syp97_2-0

Unfortunately, both Hudak and Shaumyan are deceased; Mark Jones doesn't reply to my email, and I can't even find email for Sypniewski, even though he's a former CS prof.

I think if and when I finally succeed with this part of the project, I'll stop and reevaluate, while reading that follow-on paper, and see if it feels worth continuing in Haskell. Until then, I'm just making very small changes (mostly to names of types, variables and functions) and re-running the tests, because, if I do anything big, well . . . I'll hit Haskell error messages that I probably won't understand. For now, when I get error messages, I just go back and see where I might have misspelled something, or introduced a syntax error.

it's much more about educational materials for Haskell than about error messages produced by GHC. Thanks.

Oh, well, in that case, change the description of the repo. Right now, the priorities are given as:

"Serve the Haskell community, focusing on improvements to the error messages seen in the Haskell ecosystem."

"Lower Haskell's barrier-to-entry by increasing the general understanding of the error messages experienced during development"

So, in your view, it should be more like this?

"PRIMARILY: Lower Haskell's barrier-to-entry by increasing the general understanding of the error messages experienced during development"

"MUCH LESS IMPORTANT: Serve the Haskell community, focusing on improvements to the error messages seen in the Haskell ecosystem."

What if the educational materials produced still leave newbies scratching their heads, and being told, "Well, you need a mentor. It's really hard to learn Haskell without one"? Then you've just stepped off square one but stepped back into it again.

I see that you are frustrated @Yakushima, and I'm sorry for that. I agree that the online educational materials for Haskell are somewhat scattershot -- which is why I continue to recommend using a book, where the author has a financial incentive to do the work you would like done. (The grand map of Haskell concepts does not exist, so far as I know, and it would take time and effort to produce.) In any case, this thread has (in my opinion) strayed too far from error messages and I will thus close it. In the recent posts, you mention a specific expected/actual error message, but not the precise code that led to that error message. Perhaps there is an opportunity there to find an error message to fix -- if so, I encourage you to open a separate ticket focusing on that specific error message.

As for your broader frustration, it is simply beyond the scope of this particular repo to fix. Normally, I would recommend another place to bring your grievance, but you seem to want The Perfect Introduction to Haskell, which is a large, difficult undertaking, and not one that is likely to happen just by request.

haskell / error-messages

How about "contributions THEN structure them"? #4