From 0ab312ec4bc2fe78b1a77c01fd3217577a0fa12c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 7 Mar 2016 23:37:54 -0400 Subject: idea --- doc/todo/type_level_OS_requirements.mdwn | 49 ++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 doc/todo/type_level_OS_requirements.mdwn (limited to 'doc/todo') 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]] -- cgit v1.2.3