Sometimes better ideas can be around for a really long time before they gain any mainstream traction. Some ideas which come to mind are anonymous functions and sum types with pattern matching, which are only recently finding their way into mainstream languages, despite having been around for ages.

What it might take is a dedicated effort over time by a group of believers, to keep the ideas alive and create new attempts, new projects regularly. So that when there is a mainstream opening, there is the knownhow to implement them.

I always include a lecture or two in my software security course (150 students per year), on capability based security. I am also on the lookout for projects which could use the ideas, but so far I have only vague ideas that they could be combined with algebraic effects in some way in functional programming.

▲

codethief 3 days ago | parent [-]

> but so far I have only vague ideas that they could be combined with algebraic effects in some way in functional programming.

This. Algebraic effects seem very much destined for this purpose. You could safely run any code snippet (LLM generated or not) and know that it will only produce the effects you allowed.

▲

nostrademons 3 days ago | parent [-]

Interesting. I hadn't heard of algebraic effects, but they remind me a lot of the Common Lisp condition system, or delimited continuations, or monads in Haskell. There's even a shoutout to monads in the top Google result for the context:

https://overreacted.io/algebraic-effects-for-the-rest-of-us/

I assume that the connection to capability security is that you use the effect handler to inject the capabilities you want to offer to the callee, and their access is limited to a particular dynamic scope, and is then revoked once it exits from that block? Handler types effectively provide for the callee and define what capabilities it may invoke, but the actual implementation is injected from a higher level?

▲

black_knight 2 days ago | parent [-]

Your description sounds about right!

I learned to understand it [0][1] as a way of creating free monads by wishing for a list of effects at the type level. Then later you worry about how to implement the effects. Solves the same problem as monad transformers, but without commit to an order up front (and without all the boilerplate of mtl).

My idea is that you should be able to create and pass around typed capabilities for effects, and then transparently get them “effectuated at their place of creation”.

[0] : http://okmij.org/ftp/Haskell/extensible/more.pdf

[1] : https://hackage.haskell.org/package/freer-simple

▲

tome 2 days ago | parent [-]

Have you seen my effect system Bluefin? It sounds like exactly what you're describing:

https://hackage-content.haskell.org/package/bluefin-0.0.16.0...

Happy to answer any questions about it, either here, or if you open an issue: https://github.com/tomjaguarpaw/bluefin/issues/new

	▲	black_knight 2 days ago \| parent [-]
		Nice! This looks very interesting. Will for sure check it out.