summaryrefslogtreecommitdiff
path: root/doc/todo/type_level_OS_requirements.mdwn
diff options
context:
space:
mode:
authorJoey Hess2016-03-07 23:37:54 -0400
committerJoey Hess2016-03-07 23:37:54 -0400
commit0ab312ec4bc2fe78b1a77c01fd3217577a0fa12c (patch)
tree847761df2726a9fc48854a665a8bc2b559c1de35 /doc/todo/type_level_OS_requirements.mdwn
parent4c33389b219d51b44d6b1ebc07a1d17b47be1cf7 (diff)
idea
Diffstat (limited to 'doc/todo/type_level_OS_requirements.mdwn')
-rw-r--r--doc/todo/type_level_OS_requirements.mdwn49
1 files changed, 49 insertions, 0 deletions
diff --git a/doc/todo/type_level_OS_requirements.mdwn b/doc/todo/type_level_OS_requirements.mdwn
new file mode 100644
index 00000000..47f9710e
--- /dev/null
+++ b/doc/todo/type_level_OS_requirements.mdwn
@@ -0,0 +1,49 @@
+Currently, properties don't indicate what OS, or OS's, they work with.
+
+Using `withOS` means throwing a runtime error on an unsupported OS. Yuck.
+
+Could the OS of a property be lifted to the type level?
+
+If we had `Property i [OS]` then combining properties would need to update
+the type-level OS list.
+
+For example, `Property i [Debian, FreeBSD]` combined with `Property i [Debian, Buntish]`
+yields a `Property i [Debian]` -- the intersection of the OS's supported by
+the combined properties.
+
+And, combining two properties that demand different OS's would need to be a
+type error. Can a type level function combine two types successfully, and
+fail to combine two others somehow? Don't know. Maybe combine to an
+IncoherentOS and don't allow a `Property i IncoherentOS` to be used in a
+Host?
+
+Another kind of property combination would be to glue two properties that
+support different OS's together, yielding a property that supports both,
+and so has both in its [OS] type list, and that choses which to run using
+withOS.
+
+The `os` property would need to yield a `Property (os:[])`, where the type
+level list contains a type-level eqivilant of the value passed to the
+property. Is that possible to do? reification or something?
+Or, alternatively, could have less polymorphic `debian` etc
+properties replace the `os` property.
+
+If a Host's list of properties, when all combined together,
+contains more than one element in its [OS], that needs to be a type error,
+the OS of the Host is indeterminite. Which would be fixed by using the `os`
+property to specify.
+
+On the other hand, if a Host's list of properties yields a single OS
+(or perhaps no OS requirement), the type needs to be just `Host`.
+After all, propellor operates on a `[Host]`; if we had `Host OS`,
+the list couldn't contain host's with different OS's.
+
+One way to do this would be to make a Host not contain a Property, but a
+Propellor Result. The list of Properties could be combined together, and
+the Propellor Result extracted from the resulting single property.
+
+----
+
+This is somewhat similar to [[type_level_port_conflict_detection]].
+
+--[[Joey]]