summaryrefslogtreecommitdiff
path: root/doc/todo/type_level_OS_requirements.mdwn
blob: 5654d49a84f751b533b2786e30aa3ddcb370b034 (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
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?
(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 
(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]]