Add an agenda for the meeting on 16 June 2015.
authorAndrey Mokhov <andrey.mokhov@gmail.com>
Tue, 16 Jun 2015 00:08:05 +0000 (01:08 +0100)
committerAndrey Mokhov <andrey.mokhov@gmail.com>
Tue, 16 Jun 2015 00:08:05 +0000 (01:08 +0100)
doc/meeting-16-June-2015.txt [new file with mode: 0644]

diff --git a/doc/meeting-16-June-2015.txt b/doc/meeting-16-June-2015.txt
new file mode 100644 (file)
index 0000000..a407bb9
--- /dev/null
@@ -0,0 +1,83 @@
+Shaking up GHC (3rd shake) meeting, 16 June 2015\r
+\r
+Things to discuss:\r
+================================================\r
+\r
+1. Parameters of the build system that are still not user configurable:\r
+\r
+* targetDirectory (Targets.hs) -- is this important? Can be moved to\r
+UserSettings.hs, but will clutter it (what is the good balance of\r
+what we expose to users?). Can be made into a conditional expression\r
+similar to userWays, userPackages and userSettings, but is it worth it?\r
+\r
+* knownPackages (Targets.hs) -- fix by adding knownUserPackages? A nasty\r
+import cycle is then created between Targets.hs and UserSettings.hs\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
+\r
+* Any other parameters I missed which should be user configurable?\r
+\r
+================================================\r
+\r
+2. When predicates are moved from configuration files to UserSettings we\r
+no longer track their state in oracles. This may lead to inconsistent\r
+state of the build system. A more general problem: how do we accurately\r
+track changes in the build systems, specifically in UserSettings.hs?\r
+\r
+================================================\r
+\r
+3. Discuss if the current design 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
+possible to check at compile which questions a given environment can\r
+answer and raise an error if an expression needs to know more.\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
+\r
+exprS = stage0 ? foo\r
+\r
+exprSP = stage0 ? package base ? bar\r
+\r
+Now I'd like the following to produce a compile error:\r
+\r
+interpret envS exprSP\r
+\r
+However, all other combinations should be fine:\r
+\r
+interpret envS  exprS\r
+interpret envSP exprS\r
+interpret envSP exprSP\r
+\r
+I played with some possible solutions using type classes, but they all\r
+seem clumsy/heavy.\r
+\r
+Hence, for now I have:\r
+\r
+data Environment = Environment\r
+     {\r
+        getStage   :: Stage,\r
+        getBuilder :: Builder,\r
+        getPackage :: Package\r
+     }\r
+\r
+defaultEnvironment :: Environment\r
+defaultEnvironment = Environment\r
+    {\r
+        getStage   = error "Stage not set in the environment",\r
+        getBuilder = error "Builder not set in the environment",\r
+        getPackage = error "Package not set in the environment"\r
+    } \r
+\r
+which leads to a lot of partial functions all over the build system.
\ No newline at end of file