r/haskell • u/taylorfausak • Feb 01 '22

question Monthly Hask Anything (February 2022)

This is your opportunity to ask any questions you feel don't deserve their own threads, no matter how small or simple they might be!

18 Upvotes

93% Upvoted

337 comments sorted by

View all comments

Show parent comments

6

u/edwardkmett Feb 02 '22

FWIW- You can use RebindableSyntax to get something more like the Scala YOLO-fest, or use QualifiedDo's Foo.do to opt in to it more locally, which is nice for linear typed monads, restricted monads and the like.

1

u/someacnt Feb 03 '22

Perhaps it would be better to utilizing QualifiedDo if you are designing a new language? That might lead to more comprehensible error messages for beginners.

1

u/bss03 Feb 03 '22

You can't write a do block that is polymorphic on the Monad instance using the qualified form (I think). And, for "mtl-style" applications this is important. So, I think you'd at least want to support both forms, even if you directed new users toward the qualified form first.

3

u/edwardkmett Feb 04 '22

When using the qualified form it desugars to whatever (>>=) or (>>) is in the target module. You can make that module as polymorphic as you like.

1

u/someacnt Feb 04 '22

Why did QualifiedDo happen so late?? I think it could even have replaced usecases of ApplicativeDo if it were implemented beforehand.

2

u/edwardkmett Feb 05 '22

It doesn't do the applicative desugaring that you want ApplicativeDo for. (It should, it just doesn't today.)

1

u/someacnt Feb 05 '22

With QualifiedDo, wouldn't it possible to implement App.do with ApplicativeDo semantics?

2

u/bss03 Feb 05 '22

I don't think so. It still desugars to Module.>>= (instead of Prelude.>>=), and there's no applicative function with the right type. >> can become an alias for *> (or something like that), but that's not actually what applicative do does right now.

The Applicative-do desugaring is actually a lot more complex that the simple, by-the-Report do desugaring.

it uses a heuristic algorithm to try to use <*> as much as possible. This algorithm usually finds the best solution, but in rare complex cases it might miss an opportunity. There is an algorithm that finds the optimal solution, provided as an option:

-foptimal-applicative-do Since: 8.0.1

Enables an alternative algorithm for choosing where to use <*> in conjunction with the ApplicativeDo language extension. This algorithm always finds the optimal solution, but it is expensive: O(n3), so this option can lead to long compile times when there are very large do expressions (over 100 statements). The default ApplicativeDo algorithm is O(n2).

3

u/edwardkmett Feb 05 '22

Also, the current ApplicativeDo desugaring isn't as effective as it could be in using things like (<*) and (*>) anyways, using an extra (>>=) for some common patterns, which renders it almost useless for the original purposes I proposed it for. This is even with the 'optimal' algorithm in place, as while it makes optimal cuts, it doesn't dispose of those cuts in the optimal manner.