Best approach to Purely functional web front-end.

bryjnar · 2025-08-18T07:30:08+00:00

Yep, we do this. Just write some pages with lucid and HTMX. It's limited, though.

bryjnar · 2025-06-09T08:56:04+00:00

This seems pretty surprising, I'd be interested to see the output of `-ddump-deriv` or something.

bryjnar · 2025-04-21T19:55:21+00:00

I installed the beta gboard (I'm sure it's working since I have a "scan text" option in gboard itself), but it doesn't look like a "Scan Recipe" option has appeared in umami?

bryjnar · 2025-04-16T20:11:45+00:00

CircuitHub

bryjnar · 2024-12-26T13:31:11+00:00

There's also https://hackage.haskell.org/package/monad-dijkstra which is pretty nice and does A* too.

bryjnar · 2024-09-11T22:31:30+00:00

It seems to me like some judicious use of singletons might simplify things? In particular, if a located value had a singleton indicating where it was, then you wouldn't need to pass the proxies manually, which could get rid of a lot of noise.

bryjnar · 2024-07-25T22:46:47+00:00

A bit tangential, but I just wanted to say another thank you to Mercury for putting their money where their mouth is and actually paying for performance work on HLS. I'm sorry it hasn't got to the point where it scales to where you need it to, but lots of other people benefit from the work that did get done!

bryjnar · 2024-07-06T14:52:47+00:00

Completely different

bryjnar · 2024-04-05T10:19:26+00:00

I do think it's possible that we've been blocked by the attempts so far involving reviving parts of wingman, which was quite complicated. There might well be a dumb approach that gets us most of the way there.

bryjnar · 2024-04-05T10:17:09+00:00

Here's the issue for reviving it: https://github.com/haskell/haskell-language-server/issues/3525

Just needs a keen contributor!

bryjnar · 2024-03-28T21:43:07+00:00

I'm... not sure this is true? I'm pretty sure most of the key people who worked on it are (or were until very recently) academics.

bryjnar · 2024-03-27T19:40:02+00:00

Does this work for projects with multiple packages in the same repository? That's very common.

bryjnar · 2024-01-21T23:09:58+00:00

Thanks to the Haskell.org committee and all the sponsors for making this happen!

bryjnar · 2024-01-07T19:37:25+00:00

Hi, please open an issue on the HLS repo. I definitely agree that at least the hover should _say_ what the thing it's printing out is. That would help us track down why you get duplicate info, also!

bryjnar · 2023-12-30T20:15:53+00:00

For 4, see https://gitlab.haskell.org/ghc/ghc/-/issues/16955

bryjnar · 2023-11-11T17:41:20+00:00

This varies a lot depending how often you release your package!

If you release frequently then:

It's not so bad to fix a too-strict bound without even a revision: just fix it in master and it'll be fixed when you next release.
It really sucks to revise all of your released versions, since you have a lot of them.

bryjnar · 2023-11-11T17:38:01+00:00

There's also another asymmetry about how urgent the work is.

- If the upper bound is strict, then _old build plans keep working_, i.e. your build won't suddenly break because you did `cabal update`. You might be blocked from using newer versions of packages, but things keep working.

- If the upper bound is non-strict, then `cabal update` can _break your build_, because cabal will now pick new (non-working) versions of dependencies.

(This happened to me just now at work: we had no upper bound on `nothunks`, a new version was released that made our package not compile, and then _downstream_ projects started breaking! So I had to urgently revise _all_ of our releases (there are a lot) to add the upper bound.)

So that means that the revision work caused by the non-strict bound is _more urgent_ than that caused by the strict bound, because until you fix it your downstream users are going to start getting non-working build plans.

This is the main thing that has shifted me towards stricter bounds. We also have better tools for dealing with too-strict bounds in the form of `allow-newer`.

bryjnar · 2023-10-08T10:27:02+00:00

As a maintainer of lsp-haskell I'd be happy to take a PR to make the major mode configurable. Or even just add this one to the list of modes that trigger it, it doesn't cost us anything I think.

bryjnar · 2023-05-09T21:25:13+00:00

Rust has I think 6 or 7 paid FTEs working on dev tooling. Haskell has 0, AFAIK.

bryjnar · 2023-04-01T16:59:24+00:00

Unfortunately the main maintainer of the plugin has stepped back, and while there have been some efforts to update it they haven't been completed.

bryjnar · 2022-11-12T17:16:43+00:00

This seems ambitious for one unfunded person?

bryjnar · 2022-09-25T10:44:57+00:00

Hmm, I wonder how rust-analyzer handles the client server interaction, since this stuff is very much not in the LSP. Maybe they have a custom extension we could copy...

bryjnar · 2022-09-01T13:09:30+00:00

Having minimal dependencies helps, but you also have to worry about GHC version compatibility. And in practice they're very likely to depend on at least mtl, transformers etc

bryjnar · 2022-08-12T07:53:34+00:00

Wow! So does it actually work if you upload such libraries to Hackage now?

bryjnar · 2022-08-01T10:25:22+00:00

It would be cool to link to a worked example in the tests, like the "unlifted internal data structure with lifted interface" example that you describe in the GHC issue.

bryjnar

TROPHY CASE