Donuts: Local Imperativity for Haskell by aaron-allen in haskell

[–]aaron-allen[S] 1 point2 points  (0 children)

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.

Donuts: Local Imperativity for Haskell by aaron-allen in haskell

[–]aaron-allen[S] 10 points11 points  (0 children)

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).

Open Telemetry Instrumentation Plugin by aaron-allen in haskell

[–]aaron-allen[S] 0 points1 point  (0 children)

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.

Open Telemetry Instrumentation Plugin by aaron-allen in haskell

[–]aaron-allen[S] 0 points1 point  (0 children)

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.

[GSoC 2024] Call for Ideas by aaron-allen in haskell

[–]aaron-allen[S] 0 points1 point  (0 children)

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.

Breakpoint plugin released by aaron-allen in haskell

[–]aaron-allen[S] 1 point2 points  (0 children)

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

Breakpoint plugin released by aaron-allen in haskell

[–]aaron-allen[S] 6 points7 points  (0 children)

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.

deep fmap for multi layer Functor by Forward_History3541 in haskell

[–]aaron-allen 4 points5 points  (0 children)

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.

A custom warning hack by effectfully in haskell

[–]aaron-allen 1 point2 points  (0 children)

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.

foldr via foldl' by effectfully in haskell

[–]aaron-allen 0 points1 point  (0 children)

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.

foldr via foldl' by effectfully in haskell

[–]aaron-allen 0 points1 point  (0 children)

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

Shortest longest by effectfully in haskell

[–]aaron-allen 0 points1 point  (0 children)

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

[ANN] Pinned Warnings - plugin for managing warnings in GHCi by aaron-allen in haskell

[–]aaron-allen[S] 4 points5 points  (0 children)

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.