Finalise meeting agenda.
authorAndrey Mokhov <andrey.mokhov@gmail.com>
Tue, 16 Jun 2015 08:53:30 +0000 (09:53 +0100)
committerAndrey Mokhov <andrey.mokhov@gmail.com>
Tue, 16 Jun 2015 08:53:30 +0000 (09:53 +0100)
doc/meeting-16-June-2015.txt

index bd2b94f..d58b541 100644 (file)
@@ -13,45 +13,76 @@ similar to userWays, userPackages and userSettings, but is it worth it?
 * knownPackages (Targets.hs) -- fix by adding knownUserPackages? A nasty\r
 import cycle is then created between Targets.hs and UserSettings.hs. Possible\r
 solution: add file Settings/Targets.hs which will actually put two things\r
-together similar to what's done with userWays, userPackages and userSettings.\r
+together similar to how it's done with userWays, userPackages and userSettings.\r
 \r
 * integerLibraryImpl (Switches.hs) -- fix by having three integer library\r
 packages in Targets.hs and choosing which one to build in userPackages, e.g.:\r
 \r
 userPackages = remove [integerGmp2] <> append [integerSimple]\r
 \r
-* In general, should Targets.hs be editable by users as well? Ideally,\r
-there should only be one place for user to look: UserSettings.hs.\r
+(Maybe a useful pattern: replace a b = remove a <> append b.)\r
+\r
+* In general, should Targets.hs (or any other file) be editable by users?\r
+Ideally, there should only be one place for users to look: UserSettings.hs.\r
 \r
 * Any other parameters I missed which should be user configurable?\r
 \r
 ================================================\r
 \r
 2. When predicates (e.g. buildHaddock) are moved from configuration files to\r
-UserSettings we no longer track their state in oracles. This may lead to an\r
+UserSettings.hs we no longer track their state in oracles. This may lead to an\r
 inconsistent state of the build system. This is a special case of a more general\r
 problem: how do we accurately track changes in the build system, specifically\r
 in UserSettings.hs? Although in general this is a hard problem, this special\r
-case may be easier to solve: just channel everything exported from\r
+case may be easier to solve: e.g., just channel everything exported from\r
 UserSettings.hs through oracles? Another alternative which was discussed\r
 previously: pass the final lists of arguments through oracles. Care must\r
-be taken though as final command lines can be as large as 5Mb!\r
+be taken though as final command lines can be as large as 5Mb and may bloat\r
+the Shake database!\r
 \r
 ================================================\r
 \r
-3. Discuss if the current design makes recording provenance information\r
+3. Discuss if/how the current approach makes recording provenance information\r
 possible. (Should probably be implemented only after the first successful\r
 complete build though.)\r
 \r
 ==============================================\r
 \r
-4. I'd like interpret/interpretDiff to be total functions. It should be\r
+4. Duplication of information in knownPackages and packages.\r
+\r
+I'd like to enforce the following invariant: whenever a package is used\r
+in userPackages, it must also be placed in knownPackages/knownUserPackages.\r
+\r
+This feels awkward/redundant. The reason for having knownPackages is that I\r
+need a list of packages outside the Action monad for it to be useable in\r
+packageRules (see Rules.hs). The current solution seems to be the cheapest way\r
+to achieve that. An alternative would be to have one additional implementation\r
+of interpret, which would extract the 'support' from a given expression, i.e.\r
+the set of packages that can occur in a given expression, regardless of how\r
+predicates evaluate (without looking up oracles which live in the Action monad).\r
+\r
+For example,\r
+\r
+interpret' (stage0 ? base <> stage1 ? compiler) == [base, compiler]\r
+\r
+This seems to require a lot of extra code though. Hence redundant knownPackages.\r
+\r
+==============================================\r
+\r
+5. (Just realised that the following is trickier than I thought. Maybe not\r
+worth raising at this meeting if not enough time.)\r
+\r
+I'd like interpret/interpretDiff to be total functions. It should be\r
 possible to check at compile which questions a given environment can\r
-answer and raise a *compile* error if the expression needs to know more.\r
+answer and raise a *compile* error if the expression needs to know more. Why\r
+is this useful? For example, I'd like to allow only getStage and\r
+platform-specific predicates in userPackages (since nothing else is known at\r
+this point; one can argue that we should even forbid to use such predicates\r
+when constructing expressions of type Packages).\r
 \r
 For example, consider an environment envS that can only answer 'getStage'\r
 question, and environment envSP that can answer questions 'getStage' and\r
-'getPackage'. Now consider two expressions\r
+'getPackage'. Now consider two expressions:\r
 \r
 exprS = stage0 ? arg "foo"\r
 \r
@@ -106,3 +137,6 @@ getPackage, getBuilder, getFile, getWay. Hence, it may be OK to have only
 6 combinations of getters in a type constraint, not 2^5, e.g.: empty,\r
 GetStage env, (GetStage env, GetPackage env), etc.\r
 \r
+==============================================\r
+\r
+\r