From 7f24020d963714dd8d4b624b0240fefcd81cc9e3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 8 Mar 2016 06:19:02 -0400 Subject: update --- .../type_level_privdata_availability_checking.mdwn | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) (limited to 'doc') diff --git a/doc/todo/type_level_privdata_availability_checking.mdwn b/doc/todo/type_level_privdata_availability_checking.mdwn index 7f02c700..cb0d157d 100644 --- a/doc/todo/type_level_privdata_availability_checking.mdwn +++ b/doc/todo/type_level_privdata_availability_checking.mdwn @@ -11,8 +11,8 @@ It would have one type-level function type instance HasPrivData "password" "foo.com" = Available -- ^ supposed to be type level strings -The file would generate instances of the type family or each available privdata -value. +The file would be generated with +instances of the type family for each available privdata value. `withPrivData` would use this type level function, and require it to return Availble. If it didn't, the type checker would blow up. @@ -23,12 +23,18 @@ may be tricky.) For this to work, `withPrivData` would need some interesting changes to its type signature, so that it has available the type level strings describing the privdata it's supposed to get. Is that practical? I think so, -actually.. +actually.. - withPrivData :: (HasPrivData source context) => source -> context -> (((PrivData -> Propellor Result) -> Propellor Result) -> Property i) -> Property HasInfo +Something like this, although my type-level comparison syntax may be off. -All that's needed is a way to provide a type level string from which a -string value can be extracted that has the same string as the type. IIRC, -that's supported by type level strings. + withPrivData :: (HasPrivData source context ~ Available) source -> context -> (((PrivData -> Propellor Result) -> Propellor Result) -> Property i) -> Property HasInfo + +All that's needed to use this is a way to provide a type level string from +which a string value can be extracted that has the same string as the type. +IIRC, that's supported by type level strings. + +But.. This may get tricky/unusable when source and context are constructed +based on data now, since the type-level source and context need to be +constructed at build time. --[[Joey]] -- cgit v1.2.3