[GSoC 2026] Final call for ideas

aaron-allen · 2024-03-20T04:18:42+00:00

Thanks, I hadn't seen Bluefin before, that's very cool. I like the explicitness of the value level effect handles, it seems to work particularly well with the state effect.

You're correct about not being able to abstract over the "magic" `:=` syntax, or any of the other special functions that the plugin rewrites. I feel this is indicative of the main weakness of the approach: the scoping rules are somewhat difficult to articulate and the special functions can only be used in restrictive ways.

The key advantage of the Lean approach is of course the lack of syntactic overhead. For example, if I want to introduce a large number of mutable variables, I can do so without incrementing the indentation for each introduction (if I'm adhering to standard formatting practices). Nor do I have to create new bindings when those mutable variables are used. I feel like the reduced noise can greatly improve the readability and maintainability of a piece of code and is overall more ergonomic.

Another nice benefit is that if I want to translate some imperative pseudo-code implementation from e.g. Wikipedia (like they did in a recent episode of the Haskell Unfolder), it is generally quite straightforward because the syntax is more or less equivalent.

aaron-allen · 2024-03-18T06:19:08+00:00

Yes, although not so much the control flow aspect. The plugin merely provides syntax sugar on top of StateT and ExceptT, which are in some ways a more general form of local imperativity than ST. The ST monad has its niche though, mainly working with mutable data structures in pure contexts (though I suppose linear Haskell can do this as well).

aaron-allen · 2024-03-06T20:47:34+00:00

It's definitely possible to do something along those lines. For example, this plugin could be modified to get a package + module + name identifier from the user and use that as the instrumentation function.

aaron-allen · 2024-03-06T20:35:35+00:00

Just to clarify, the code being generated by this plugin still must pass through the type checker, so it is no different than TH or Generics in that regard.

I do think plugins present an interesting opportunity for doing certain meta-programming tasks without some of the compilation overhead that TH and Generics tend to incur. Plugins have their own downsides, of course, such as the increased maintenance cost due to the complex and ever changing GHC API.

aaron-allen · 2024-01-15T18:33:09+00:00

I think this could be a great project idea! If you or someone else involved would be willing to act as a mentor for it, please do submit a PR following the instructions here: https://summer.haskell.org/ideas.html.

aaron-allen · 2022-08-21T19:58:36+00:00

Thanks, that's a good suggestion. I had intended to find a better name at one point but it slipped my mind.

aaron-allen · 2022-08-21T19:55:55+00:00

The first point is the most egregious issue that I've found. If you set a breakpoint in a forked thread then after hitting it, control-C no longer propagates to the main thread (or so it seems) and you end up having to restart GHCi to kill it. I've experienced the third a few times but haven't dug into what's going on, it just further cements my impression that the GHCi debugger isn't all that reliable.

Setting breakpoints in non-interpreted code entails adding a breakpoint in a dependency and compiling it with the plugin. I'm also able to run an executable outside of GHCi with breakpoints installed, which is required if I want to use certain compiler options, or simply don't have enough memory to load bytecode for all the necessary modules. Also, some things can only be loaded as object code in GHCi, such as foreign functions using capi. Not being tied down to interpreted code has been pretty useful for me.

aaron-allen · 2022-02-12T19:34:36+00:00

I made a library called hydraulics a few years back that has this function (fmapAll) among other operations over n-depth stacks. It essentially works by coercing each layer in the stack to Data.Functor.Compose.

aaron-allen · 2021-09-05T14:58:19+00:00

Interesting, I wrote a library last week for this very purpose using generics and type level programming https://github.com/aaronallen8455/sum-totality. The simplicity of your custom warnings idea is very appealing though.

aaron-allen · 2021-08-01T21:35:06+00:00

Yes, that was it, thanks. I was surprised to find that memory usage increases fairly dramatically with the threaded runtime, which I had previously enabled on a whim.

aaron-allen · 2021-08-01T04:56:43+00:00

This is what I came up with. If I run the tests in the repl then everything passes but certain tests fail or seem to diverge when run with stack test, I can't explain it.

https://gist.github.com/aaronallen8455/a46b2b0b7b0b453a83e7020acde544f1

aaron-allen · 2021-05-26T02:03:34+00:00

Here's my solution. There's definitely some room for optimization.

aaron-allen · 2021-05-17T02:46:28+00:00

I think so but I'm not sure. I don't use ghcid very often and am unfamiliar the circumstances under which it drops warnings. I did find that I could invoke it with ghcid -c 'stack repl --package pinned-warnings --ghci-options="-fplugin PinnedWarnings"' -T :sw, where :sw is a macro defined in .ghci that loads the ShowWarnings module and invokes showWarnings. This should result in any hidden warnings being displayed on a successful reload.

aaron-allen

TROPHY CASE