A (failed) attempt at doing IO with Dhall

#1

HI everyone!

So I’m on spring break, and what better way to spend it than committing functional programming crimes of the highest order? This week I attempted to make an IO library and runtime for Dhall. You can check the code on github.

It’s not very organized, and I started this with simply making functor, applicative, and monad types (which is why they’re in the package.dhall). An proceeded to design something that would work only on std{in,out,err}, so the World type would actually be the the world (all known files and their contents). In its current state, the World isn’t very useful, only the WorldResult is really used (as an out-paramer for the “system calls”).

Most importantly this runtime does not work reliably. I think the root of the problem is in Dhall’s normalization algorithm, but I’ve intentionally not looked under the hood to avoid shaving more Yaks.

Sorry if this isn’t very detailed, I’d be happy to explain more if anyone is interested!

3 Likes
#2

Nice! Always fun to explor ethese kinds of things :slight_smile: I wrote a proposal about do notation earlier too along the lines of doing something like this (Proposal: "Do notation" syntax - #6 by Gabriel439), it can be kind of interesting to imagine dhall as a language to write normalizable EDSLs for scripts, of which IO can be one of the execution environments.

#3

I might be missing something, but isn’t IO exactly the kind of thing that configuration files should not do?
Or is it my idea of where to use Dhall that is wrong, since I consider using it as part of an automated pipeline.

#4

Your idea of Dhall is correct!

My original motivation was access to stdin/out/err and exit codes, for using Dhall in a more general purpose way. However, I got a little carried away and tried to make a generic IO mechanism.

1 Like