summaryrefslogtreecommitdiff
path: root/doc/todo/info_propigation_out_of_nested_properties.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/info_propigation_out_of_nested_properties.mdwn')
-rw-r--r--doc/todo/info_propigation_out_of_nested_properties.mdwn109
1 files changed, 85 insertions, 24 deletions
diff --git a/doc/todo/info_propigation_out_of_nested_properties.mdwn b/doc/todo/info_propigation_out_of_nested_properties.mdwn
index e6427069..536d6719 100644
--- a/doc/todo/info_propigation_out_of_nested_properties.mdwn
+++ b/doc/todo/info_propigation_out_of_nested_properties.mdwn
@@ -1,36 +1,97 @@
> Now [[fixed|done]]!! --[[Joey]]
-Currently, Info about a Host's Properties is manually gathered and
-propigated. propertyList combines the Info of the Properties in the list.
-Docker.docked extracts relevant Info from the Properties of the container
-(but not al of it, intentionally!).
+Currently, Info about a Host's Properties is propigated to the host by
+examining the tree of Properties.
-This works, but it's error-prone. Consider this example:
+This works, but there's one problem. Consider this example:
withOS desc $ \o -> case o of
(Just (System (Debian Unstable) _)) -> ensureProperty foo
_ -> ensureProperty bar
Here, the Info of `foo` is not propigated out. Nor is `bar`'s Info.
-Of course, only one of them will be run, and only its info should be propigated
-out..
+It's not really clear if just one Info, or both should be propigated out.
-This commonly afflicts eg, privData. For example, `User.hasPassword'`
-has this problem, and this prevents --list-fields from listing privdata
-that's not set from that property.
+----
One approach might be to make the Propellor monad be able to be run in two
-modes. In one mode, it actually perform IO, etc. In the other mode, all
-liftIO is a no-op, but all Info encountered is accumulated using a Reader
-monad. This might need two separate monad definitions.
-
-That is surely doable, but the withOS example above shows a problem with it --
-the OS is itself part of a Host's info, so won't be known until all its
-properties have been examined for info!
-
-Perhaps that can be finessed. We don't really need to propigate out OS info.
-Just DNS and PrivDataField Info. So info could be collected in 2 passes,
-first as it's done now by static propertyInfo values. Then take that
-and use it as the Info when running the Properties in the Reader monad.
-Combine what the Reader accumulates with the static info to get the full
-info.
+modes. In run mode, it actually performs IO, etc. In introspection mode, all
+liftIO is a no-op, but all Info encountered is accumulated using a Reader.
+This might need two separate monad definitions.
+
+That is surely doable, but consider this example:
+
+ property "demo" = do
+ needfoo <- liftIO checkFoo
+ if needfoo
+ then ensureProperty foo
+ else ensureProperty . bar =<< liftIO (getBarParam)
+
+In introspection mode, the liftIO is a no-op, but needs to return a Bool.
+That seems unlikely (how to pick which?), but even if some defaulting is
+used, only one of foo or bar's info will be seen.
+
+Worse, the bar property is not fully known until IO can be performed to get
+its parameter.
+
+----
+
+Another approach could be something like this:
+
+ withInfoFrom foo $ \callfoo ->
+ withInfoFrom bar $ \callbar ->
+ property "demo" = do
+ needfoo <- liftIO checkFoo
+ if needfoo
+ then callfoo
+ else callbar
+
+Here withInfoFrom adds foo and bar as child properties of the demo property
+that (may) call them.
+
+This approach is not fully type safe; it would be possible to call
+withInfoFrom in a way that didn't let it propigate the info.
+
+And again this doesn't solve the problem that IO can be needed to get
+a parameter of a child property.
+
+----
+
+Another approach would be to add a new SimpleProperty, which is a property
+that has no Info. Only allow calling ensureProperty on this new type.
+
+(Or, remove propertyInfo from Property, and add a new InfoProperty that
+has the info.)
+
+But, propertyList can only contain one type at a time,
+not a mixed list of Property and SimpleProperty.
+
+Could a GADT be used instead?
+
+ {-# LANGUAGE GADTs #-}
+ {-# LANGUAGE EmptyDataDecls #-}
+
+ data HasInfo
+ data NoInfo
+
+ data Property = IProperty (GProperty HasInfo) | SProperty (GProperty NoInfo)
+
+ data GProperty i where
+ GIProperty :: Desc -> Propellor Result -> Info -> GProperty HasInfo
+ GSProperty :: Desc -> Propellor Result -> GProperty NoInfo
+
+ ensureProperty :: GProperty NoInfo -> Propellor Result
+ ensureProperty (GSProperty d r) = r
+
+That works. I made a `gadtwip` git branch that elaborated on that,
+to the point that Property.File compiles, but is otherwise
+unfinished. Most definitions of `Property` need to be changed to
+`GProperty NoInfo`, so that ensureProperty can call them. It's a big,
+intrusive change, and it may complicate propellor too much.
+
+I've tried to make this change a couple times now, and not been completely
+successful so far.
+
+(I may need to make instances of Prop for `GProperty NoInfo` and `GProperty
+HasInfo`, if that's possible, and make more Property combinators work on
+Prop.)