summaryrefslogtreecommitdiff
path: root/doc/todo/type_level_OS_requirements.mdwn
blob: a73ac13b7474ed31f27e6c3a457bc8e09bc1aaf0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
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.

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?
(See: <https://www.schoolofhaskell.com/user/thoughtpolice/using-reflection>)
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 
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]].

----

Note that propellor needs to remain buildable with Debian stable's
ghc 7.6.3. Stuff like type level lists needs a newer ghc. So any work on
this may need to be deferred merging into propellor mainline unless it can
be made to build with the old ghc (even if perhaps not doing the full type
checking of OS's there).

--[[Joey]]