summaryrefslogtreecommitdiff
path: root/doc/todo/type_level_OS_requirements.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/type_level_OS_requirements.mdwn')
-rw-r--r--doc/todo/type_level_OS_requirements.mdwn13
1 files changed, 8 insertions, 5 deletions
diff --git a/doc/todo/type_level_OS_requirements.mdwn b/doc/todo/type_level_OS_requirements.mdwn
index d18f2351..7c2fb78f 100644
--- a/doc/todo/type_level_OS_requirements.mdwn
+++ b/doc/todo/type_level_OS_requirements.mdwn
@@ -12,10 +12,7 @@ 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?
+type error.
Another kind of property combination would be to glue two properties that
support different OS's together, yielding a property that supports both,
@@ -35,7 +32,7 @@ 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`.
+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.
@@ -47,6 +44,12 @@ the Propellor Result extracted from the resulting single property.
This is somewhat similar to [[type_level_port_conflict_detection]].
+----
+
+Note that propellor needs to remain buildable with Debian stable's
+ghc 7.6.3. I was able to get the type level OS implementation backported to
+work with that version, with some added ugliness.
+
--[[Joey]]
[[!tag user/joey]]