From f931c35e3d2dc3d8a9cf71fc78cdb6c2fdd1c434 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 17 Mar 2019 14:40:48 -0400 Subject: idea --- .../serialize_actions_via_free_applicative.mdwn | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/todo/serialize_actions_via_free_applicative.mdwn diff --git a/doc/todo/serialize_actions_via_free_applicative.mdwn b/doc/todo/serialize_actions_via_free_applicative.mdwn new file mode 100644 index 00000000..8659e76e --- /dev/null +++ b/doc/todo/serialize_actions_via_free_applicative.mdwn @@ -0,0 +1,34 @@ +A persistent problem with propellor is that Propellor actions cannot be +compared for equality or serialized. + +This prevents eg, propellor outside a chroot from passing a Property to run +to the propellor running inside the chroot. (Because Property contains +a Propellor action.) A workaround is used, that gives the +Property a name at compile time. + +Another problem is that Propellor actions currently run whatever IO they +perform, and can't be examined in a no-op mode. + +If Propellor actions were somehow represented as an AST, all these problems +would be eliminated; they could be serialized, compared, examined, and run +in modes that don't really run them. + +(This might also allow the local propellor to ship the AST off to the +remote propellor to run, without the remote propellor needing to be +rebuilt, if they share the same version of the AST.) + +Unfortunately, a free Monad can't be serialized, it's an AST but an AST +embedding haskell functions. However, a free Applicative can apparently be +serialized. + +See +and + +Question is, would an Applicative building an AST be sufficient for +everything that a Propellor action needs to do? + +This needs some investigation of the kind of IO that Propellor actions do. +Much of it, I suspect is not very monadic, in that it mostly does some IO +and returns a Result, rather than building up complex IO sequences based on +previous inputs. --[[Joey]] + -- cgit v1.2.3