Longer term goals of the language and its associated ecosystems

#1

Hi & thanks for setting up this system!

Is there somewhere shortish descriptions of what are the longer term goals of the language (haskell), the main tools, and its ecosystem? By longer term goals I mean something that is not a vision/mission but rather something that can be semi-concretely worked towards. (Actually a link to vision/mission statement wouldn’t hurt if it is somewhere.)

I tried to find something but didn’t find anything quickly. If there isn’t published one & why to ask this?

  • If the goal is hard/impossible for small group, it might be possible for larger one. E.g. it may help getting company sponsors and coordinate actions to make things realize.
  • It would show to people, what kind of great things to expect. I think that new-comers, those who just use the tools & libs, and those who dev the tools & libs, would benefit or find this interesting.
  • E.g. if trying to show-case and introduce Haskell in a company, it would tell about coordinated and goal set path (as opposite to the random path).
  • On other forum was a short discussion about language 2020 report and links to emails discussing if there is actually a need for the report. The init msg had quite critical tone. Having goals that are updated regularly would show certain kind of seriousness / a pro attitude / ?? and sometimes would help to make an answer.

If there is nothing published yet, whose job would it be to write one? Committee or community or both? (The yearly questionnaire has had q’s that are related.)

And as a last one, what would you like to see as a goal set?

4 Likes
Haskell Debugger
#2

The Haskell 1.0 report (published almost 20 years ago, and still worth a look!) described some goals:

  1. It should be suitable for teaching, research, and applications, including building large systems.
  2. It should be completely described via the publication of a formal syntax and semantics.
  3. It should be freely available. Anyone should be permitted to implement the language and distribute it to whomever they please.
  4. It should be based on ideas that enjoy a wide concensus.
  5. It should reduce unnecessary diversity in function programming languages.

(3) and (5) need to be understood in the context of its time, because at that time there were a lot of Haskell-like but incompatible and non-free languages available, e.g. Miranda. I feel like that problem has been mostly solved.

(1), however, is still extremely relevant and I would even call it the main goal of Haskell: building something that can be used to build large applications, to teach, and to do research.

4 Likes
#3

Hi & thanks!

It seems that the 1.0 is from 1990, so almost 30 years now :slight_smile: And language reports 98 and 2010 also have the same texts (goals) in the preface sections.

Which gives - together with your post - a thought that maybe it could be updated. My proposal would be to include something like “suitable for building high performance data mining, AI, numerical and statistical applications”. And maybe some other things.

Anyhow, this goal statement looks like an “vision/mission statement” and as such it cannot have too narrow goals. That’s why there might be room for some more specific goals, something that could be made into a measurable project (but potentially huge one) and that are updated more often than once in 40-50 years.

E.g. please do consider the high performance numerical apps. What this kind of enormous goal (but a kind of mid-term goal) would mean from the point of view of Haskell as language, ghc, libs, etc. There are bindings to external libs that most people are happy to use. Yet I’d prefer to have everything in Haskell. Addressing some of the pain points may improve things also in other areas? Maybe.

Ok, I’d also like to see a road-map for the base-libs (things like fut view on totality, string/text things, etc, which really is hard thing to do because of the amount of things that rely on the current one, like books, libs, blogs, apps etc.) And on ghc the plans/goals for the next level support for multiple backends (so that reflex-dom could work on it and produce js) etc.

And yes, all this is the strategy work many do dislike.

1 Like
#4

include something like “suitable for building high performance data mining, AI, numerical and statistical applications”.

These are application areas I (and many others) deeply care about. We have a sub-community/“focus group” around datahaskell.org that tinkers with these things and tries to make sense of the current ecosystem: what’s missing, what’s to be built and how. Apart from a directory of related packages (http://www.datahaskell.org/docs/community/current-environment.html) we have an embryonic monorepo project to work on a smoother interface between related libraries: https://github.com/DataHaskell/dh-core .

It’s a long way still from here to any sort of standardization but I believe it’s a very interesting space to be in, the potential for declarative data science/numerics is huge, and if you’re interested too I’d invite you to join the conversation.

3 Likes
#5

Hi & thanks!

I’m definitely interested in this stuff and try to follow-up later this week or next week.

In the context of road-maps and such things, the numerics area is one area that would probably happily benefit from some attention & love on ghc as well.

Other possible things worth addressing/focusing: ergonomics of type system usage and type level programming? Multi-base-approach to hackage (e.g. current one, one based on a total custom prelude with freer way to handle effects, etc.)

Ok, maybe that was too provocative, sorry for it. But e.g. I find extensible-effs/freer things very natural to introduce local effects (e.g. multiple & varying number of readers, not a one global env), and then there are some difficulties when using some other libs (cannot describe this very well, maybe it was just too many lines of clue code to use exceptions). And this is the reason I’d like to see full freer-based libs along with couple of other major libs. While waiting someone to invent a way to automatically construct this multitude of bases, maybe it could be road-map thingy. Ok, it is monday.

#6

[Are] there … descriptions of what are the longer term goals of the language (haskell)?

Unfortunately, the answer is no. The reason is that there aren’t plans to write about. (Please correct me, someone if I’m wrong.)

I’d love for the situation to be different, but as you can see from the responses, the last time a leadership group actually set out goals was 20-30 years ago. And so there isn’t anything to write up.

#7

[…] from now on, a main goal in designing a language should be to plan for growth. The language must start small, and the language must grow as the set of users grows. - Guy Steele, Growing a language, 1998 (https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf)