Hacker News Reader

Comment by al2o3cr | Hacker News Reader

The article starts off with a motivating example of effects getting "bigger" when composed but I don't see where it does anything to contain / control that expansion (other than "proto" which does full inference)

Seems like complex functions could end up with effects lists of unwieldy size, similar to how Elm programs end up with a giant "Msg" type.

View on HN

This was the problem we saw in practice building an effects based system at work. It had a lot of nice properties, and type inference worked better than you might expect, but there was no way around the types with 100+ effects in the type signature, and people really disliked it.

There are some things you can do to make it more ergonomic. One mistake we made was not focusing on ergonomics early on, and that lead to people having some pretty sour experiences. It's something you really have to pay a lot of attention to.

Can you not combine effects into unions and/or intersections resulting in more abstract effects?

In real world languages with effects, like F* or Koka, you can

The "getting bigger" actually happens in reverse. `main` has god-mode privileges, and it can selectively grant smaller or equivalent privileges to the functions it calls, which in turn, grant smaller or equivalent privileges to the functions they call. A function can't call another with greater privilege than it has itself. Ideally we should aim to grant only the necessary privileges to functions that need them, with the leaf functions in the call graph being pure functions - those which have no privilege to do anything but compute (or never return, which can be considered a side-effect). We might also want total pure functions, which are guaranteed to return (they only use primitive recursion), though there's no guarantee that they'll return in any reasonable time.

Haskell is a pretty lousy example because it bundles everything up into one big `IO` privilege, which gets passed around everywhere, and monads aren't that great. Monad transformers are terrible at scaling.

> monads aren't that great. Monad transformers are terrible at scaling.

I've dabbled in Haskell, but making anything more than toys became infuriating when dealing with deep stacks of monad transformers: the inscrutable error messages that maybe you just need another `lift` to fix or maybe need to rearrange the whole stack IDK WTF FML LOL.

I'm now poking around Unison, though without any ideas so far on what to write with it. The Abilities system looks refreshingly simple, and there's even a fair explanation somewhere on the site of how they're at least as powerful as Monads.

I personally think these effect systems are trying to solve the wrong problem. What we really want is capabilities[1], and the means of enforcing them, which I suspect is best done with linear types and uniqueness types. Granule[2] is certainly of interest as it combines these two typing disciplines. Austral[3] is another worth looking into, though uniqueness and referential transparency is not one of its goals, it does provide capabilities which are encapsulated in linear types, which serve a similar purpose as uniqueness types for guaranteeing unforgeability.

[1]:https://en.wikipedia.org/wiki/Capability-based_security

[2]:https://granule-project.github.io/

[3]:https://austral-lang.org/

I think the solution to that is to have only a few builtin effects. This is the approach taken by the Verse language:

https://dev.epicgames.com/documentation/en-us/uefn/specifier...

It's a compromise between the granularity of correctness checks and readability, but IMHO it's still a big improvement over current type systems.

Reply on news.ycombinator.com