All the side effects were never mentioned to me
I am innocent of uncontrolled abuse

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Well-Typed Blog: Haskell Symposium 2023 (well-typed.com)

The Haskell Symposium is a two-day workshop co-located with the International Conference on Functional Programming (ICFP). In a previous blog post we discussed the Haskell Implementors’ Workshop (HIW), which is another Haskell-workshop co-located with ICFP, but unlike HIW, the Haskell Symposium is a scientific workshop with...

Haskell Interlude 39: Rebecca Skinner (haskell.foundation)

In this episode, we are joined by Rebecca Skinner. She talks about her new book, Effective Haskell, which takes you from list manipulation to thunks to type-level programming. She also tells us about large scale industrial applications in Haskell, and how the architecture is shaped by the organization of the engineering teams.

The Haskell Unfolder Episode 16: monads and deriving via (well-typed.com)

In this episode, we'll see how deriving-via can be used to capture rules that relate type classes to each other. As a specific example, we will discuss the definition of the Monad type class: ever since this definition was changed back in 2015 in the Applicative Monad Proposal, instantiating Monad to a new datatype requires...

jaror,
@jaror@kbin.social avatar

For more details on DerivingVia, check out the paper:

https://ryanglscott.github.io/papers/deriving-via.pdf

Especially Section 4 which lists many use cases including the superclasses demonstrated in the video.

jaror,
@jaror@kbin.social avatar

I think Idris' bang notation for performing effects in a do-block is pretty, it could look like this:

main = do putStrLn ("You said: " ++ !getLine)

Today, you'd have to come up with a new variable name or figure out the right combinator names:

main = do line <- getLine; putStrLn ("You said: " ++ line)

main = putStrLn . ("You said: " ++) =<< getLine

But unfortunately there are more complicated cases:

main = do print (True || !getLine == "foo")

In a strict language with built-in short-circuiting logical operations the getLine would never be performed, but in Haskell || is just a normal function that happens to be lazy in its second argument. The only reasonable way to implement it seems to be to treat every function as if it was strict and always perform the getLine:

main = do line <- getLine; print (True || line == "foo")

Do you think this is confusing? Or is the bang notation useful enough that you can live with these odd cases? I'm not very happy with this naive desugaring.

jaror, to haskell
@jaror@kbin.social avatar

Anyone want to guess how many errors this code generates:

{-# LANGUAGE DerivingVia #-}

module T where

newtype OrdList1 a = OrdList1 [a]
  deriving (Functor, Foldable, Traversable) via []

newtype OrdList2 a = OrdList2 [a]
  deriving (Functor, Foldable, Traversable) via Maybe

#haskell

jaror,
@jaror@kbin.social avatar
jaror,
@jaror@kbin.social avatar
jaror,
@jaror@kbin.social avatar

The changes seem pretty modest as the costs and drawbacks section also says. But I wouldn't know how complicated it is to combine normal constraints with dependent types, let alone linear constraints.

Haskell Interlude: Episode 37 – John MacFarlane (haskell.foundation)

Joachim Breitner and David Christiansen interview John MacFarlane, a professor of philosophy at UC Berkeley, but also the author of the popular pandoc document conversion tool, which has been around half as long as Haskell itself. He also explains the principle of uniformity as a design goal for lightweight markup languages, the...

jaror, (edited )
@jaror@kbin.social avatar

Djot looks very cool: https://djot.net/.

jaror,
@jaror@kbin.social avatar

Oops, it seems this was my fault, the link should have been https://djot.net

jaror,
@jaror@kbin.social avatar

Affects on maintenance

Is this an example of https://xkcd.com/326/ or is this a typo?

jaror,
@jaror@kbin.social avatar

It's great to see windows TUI support so soon after the vty release! Especially since Windows users are not known for their fondness of command lines. I hope this has lowered one barrier to entry to Haskell and will give a more pleasant experience to many Windows users.

[Haskell Foundation] Welcome to our new Executive Director, José (discourse.haskell.org)

It is my great pleasure to announce that we have hired a new Executive Director for the Haskell Foundation: José Manuel Calderón Trilla. José is a long-time Haskeller and Haskeller-educator, with a PhD from the University of York, a stint at Galois, and is currently wrapping up a lectureship at the University of Maryland...

jaror,
@jaror@kbin.social avatar

It's still going strong. It's a pretty unique language. I use it among many other hobbyists and academics. Some well known companies like GitHub, Meta, and Tesla and of course many smaller companies use it too. Why aren't you using it?

jaror, to haskell
@jaror@kbin.social avatar
jaror, to haskell
@jaror@kbin.social avatar

The fastest effect system approaches translate operations into a fast concrete monad like IO or State.

https://gist.github.com/noughtmare/cccda38eb7c67c1ea6df6a3377f1da0d

Vty 6 released, now with support for Windows! (discourse.haskell.org)

Preview: I’m happy to announce the release of vty version 6.0. The highlight of this release is that vty now works on Windows, thanks to hard work by Chris Hackett and Timofey Zakrevskiy! For years, many people in the Haskell community have requested Windows support in vty. Thanks to Chris and Timofey for the time and energy...

Haskell Interlude 36 - John Hughes (haskell.foundation)

In this episode, Matti and Wouter are joined by John Hughes. John is one of the authors of the original Haskell Report and talks about why functional programming matters, the origins of QuickCheck testing, and how higher order functions and lazy evaluation is the key that makes functional programming so productive, and so much...

jaror,
@jaror@kbin.social avatar

Great point about Haskell seemingly becoming less and less easy to learn for beginners around 15:00. I hope some day we get a language levels system where you can start with a very simple subset and slowly expand to the full language.

jaror,
@jaror@kbin.social avatar

Type classes are a big cause of confusion among newcomers, and even parametric polymorphism.

If you want to see how simple a language can really get you should check out Hedy: https://www.hedycode.com/. It even removes string quotes (let alone variables) at the simplest level. Although it is too imperative for my taste.

jaror,
@jaror@kbin.social avatar

I'm not suggesting you should never explain type classes. I simply want to avoid having to explain type classes before I can explain how to add two integers. And more importantly, I don't want error messages to mention type classes until they have been understood.

jaror,
@jaror@kbin.social avatar

There are so many options to work around type classes. As you say, we could be looser with our types and have one general number type that includes integers and floats. (And I don't even think array indexing is much of a problem, it could just throw an error or automatically round to an integer.)

Another option is to just have separate number types with separate functions for addition and multiplication etc. For example OCaml has + and +..

Perhaps more of a stepping stone towards full type classes would be a limited system where only a few pre-defined classes and instances exist. Then you'll never run into the dreadful could not deduce Num (a -> b) error message, but you can still use a nice overloaded + for both Int and Double.

jaror,
@jaror@kbin.social avatar

I'm not sure which options you are referring to, I had three options: a JS-style number type (with two suboptions for indexing: throwing errors or rounding), separate types, or a fixed set of classes and instances.

Your first point seems to be against the error throwing approach to array indexing with a JS-style number type. I kind of agree, but then we should also handle out of bounds indexing in a type safe way. I still don't see the problem with rounding to an integer, I think that's also what beginners intuitively expect if they write e.g. xs !! (length xs / 2).

Your second point seems to be against having separate types and separate instructions like + and +.. I think I'd agree that semantically it is not much simpler, but programming is more than just semantics. For example, error messages will be much simpler if there's no Num type class involved (at least the error messages that GHC gives). Perhaps it is possible to develop a better error reporting mechanism for type classes, but that would require more research.

Did I interpret your comment correctly?

simonmic, to random
@simonmic@fosstodon.org avatar

Some nice -adjacent discussion on HN this morning:

https://news.ycombinator.com/item?id=37920633 new IRS tax software, PTA tax prep

https://news.ycombinator.com/item?id=37940973 Accounting for Computer Scientists

https://news.ycombinator.com/item?id=37953094 GNUCash and PTA

One comment I loved:

> Ok. But written in Haskell? Why would you write this kind of stuff in anything but python - it’s trivial after all, and it should stay trivial through all layers…

jaror,
@jaror@kbin.social avatar

@ffaff To be fair, the comment was about https://github.com/dpaetzel/buchhaltung, which seems to be much smaller than hledger.

@simonmic

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • uselessserver093
  • Food
  • aaaaaaacccccccce
  • test
  • CafeMeta
  • testmag
  • MUD
  • RhythmGameZone
  • RSS
  • dabs
  • KamenRider
  • TheResearchGuardian
  • KbinCafe
  • Socialism
  • oklahoma
  • SuperSentai
  • feritale
  • All magazines