Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Hello John, I tried to install the Haskell demo Cube on my Nexus 7 and got: Error: package file was not signed correctly. D On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: > In case anyone wanted to start writing haskell android code now, jhc > fully supports android as a target. here is an app made with it > > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > > this was made with Kiwamu's ajhc branch but code has been merged back > into the main tree. > > On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > wrote: >> This would probably be a great boon for those trying to use haskell for >> Android and IOS right? how might the emulation setup work for those? >> >> >> >> >> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >> wrote: >>> >>> wow, this is great work! >>> >>> If theres a clear path to getting the generic tooling into 7.10, i'm all >>> for it :) (and willing to help on concrete mechanical subtasks) >>> >>> >>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >>> wrote: hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> ___ >> Glasgow-haskel
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
> The on-screen distraction of line comments, and the nuisance of writing them, > is not > trivial. Well, I don't consider one-line comments to be distracting at all. To each his own, I guess., though your opinion on this is more important than mine. But I don't agree that writing one-line comments is a nuisance. Actually, it's very simple in Emacs: M-j will start a new line of comment. Maintains indentation. M-q will reformat a single paragraph of a comment to match the default line length (known as "fill-collumn" in Emacs). Use C-x f to set or add this to your Emacs file: (setq-default fill-column 80) Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Head's up, yall: Cabal's dir layout changed
I'll admit i've pushed a lot of haskell platform users to migrate to 1.20 style ~/.cabal/config's for a while :) On Thu, Jul 3, 2014 at 6:35 PM, Mark Lentczner wrote: > I just noticed that the default directory layout that cabal uses (under > .cabal) has changed between 1.16 and 1.18. In particular: > > In 1.16 > -- libsubdir: $pkgid/$compiler > -- datasubdir: $pkgid > -- docdir: $datadir/doc/$pkgid > > in 1.18 > -- libsubdir: $arch-$os-$compiler/$pkgid > -- datasubdir: $arch-$os-$compiler/$pkgid > -- docdir: $datadir/doc/$arch-$os-$compiler/$pkgid > > This is a rather big change: When the same package is built with multiple > compilers, before they were stored all under the same dir, now the packages > are grouped by compiler. > > This change is actually better from a system-installer (and uninstaller) > point of view, and the Mac platfrom has been shipping with a customer cabal > wrapper that sets up the user's default in a similar fashion for years. > > This change breaks the existing uninstaller, and will require some > retrenching on the platform... I'm going to try to reconcile the existing > "Mac way" with the "new way" since they are closer. > > - Mark > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Head's up, yall: Cabal's dir layout changed
I just noticed that the default directory layout that cabal uses (under .cabal) has changed between 1.16 and 1.18. In particular: In 1.16 -- libsubdir: $pkgid/$compiler -- datasubdir: $pkgid -- docdir: $datadir/doc/$pkgid in 1.18 -- libsubdir: $arch-$os-$compiler/$pkgid -- datasubdir: $arch-$os-$compiler/$pkgid -- docdir: $datadir/doc/$arch-$os-$compiler/$pkgid This is a rather big change: When the same package is built with multiple compilers, before they were stored all under the same dir, now the packages are grouped by compiler. This change is actually better from a system-installer (and uninstaller) point of view, and the Mac platfrom has been shipping with a customer cabal wrapper that sets up the user's default in a similar fashion for years. This change breaks the existing uninstaller, and will require some retrenching on the platform... I'm going to try to reconcile the existing "Mac way" with the "new way" since they are closer. - Mark ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
In case anyone wanted to start writing haskell android code now, jhc fully supports android as a target. here is an app made with it https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube this was made with Kiwamu's ajhc branch but code has been merged back into the main tree. On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald > wrote: >> >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >>> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some other >>> disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or operating >>> system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure more >>> tricky, making end users think about libgmp or libiconv locations, since it >>> basically required the same preparation as building GHC from source. This >>> change will make installing much easier and more reliable (we still have to >>> update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up and >>> push the patches for the directory and process packages, but after that, the >>> TH code can read/write files, run processes and interact with them and make >>> network connections, all through node.js. >>> >>> Now since this approach is in no way specific to JavaScript, I was >>> wondering if there's any interest in getting this functionality into GHC >>> 7.10 for general cross compilation. The runner would be a native (target) >>> program with dynamic libraries (or object files) being sent over to the >>> target machine (or emulator) for the splices. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>> concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> glasgow-haskell-us...@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- John Meacham - http://notanumber.net/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Re-add more primops for atomic ops on byte arrays (4ee4ab0)
Hello Johan, 2014-06-30 22:13 GMT+02:00 : > commit 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49 > Author: Johan Tibell > Date: Fri Jun 27 13:48:24 2014 +0200 > > Re-add more primops for atomic ops on byte arrays It seems this change breaks the build on FreeBSD/i386 [1]: "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O-hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist-install/build -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/filepath/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/containers/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/deepseq/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/array/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/base/dist-install/build' -optl-L'/usr/local/lib' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/integer-gmp/dist-install/build' -optl-L'/usr/local/lib' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/rts/dist/build' -optl-liconv -optl-lcharset -optl-lgmp -optl-lm -optl-lrt -optl-lpthread -fPIC -dynamic -H32m -O-hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell2010 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split/dist-install/build/Main.dyn_o /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_xor_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_and_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_nand_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_val_compare_and_swap_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_sub_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_add_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_or_8' collect2: error: ld returned 1 exit status This probably due to the strict defaults of the FreeBSD of GCC, where march=i386 is assumed, which does not support the required CMPXCHG8B instruction. One would need at least an i586 to get that. It is not observed on GNU/Linux as it allegedly defaults to i586 code generation. The trivial patch below makes this explicit so now it could build: --- ghc-prim.cabal.orig 2014-07-03 03:06:16.0 +0200 +++ ghc-prim.cabal 2014-07-03 20:27:49.709087595 +0200 @@ -62,3 +62,6 @@ -- We need to set the package name to ghc-prim (without a version number) -- as it's magic. ghc-options: -package-name ghc-prim +-- Due to CMPXCHG8B, we have to ask for Pentium code generation. +cc-options: -march=i586 + However, my fellow developer, Konstantin Belousov pointed out that using CMPXCHG8B would officially require checking for the corresponding CPUID bit set, because that is what truly in
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
On Thu, Jul 3, 2014 at 6:29 PM, Simon Peyton Jones
wrote:
>
> * Insisting on line comments exclusively, carries a cost. The on-screen
> distraction
> of line comments, and the nuisance of writing them, is not trivial.
> Perhaps it
> is bearable, but it's non-zero. See example below.
I think you can use
{-|
Note [Extra dependencies from .hs-boot files]
~
Consider the following case:
module A where
import B
data A1 = A1 B1
module B where
import {-# SOURCE #-} A
type DisguisedA1 = A1
data B1 = B1 DisguisedA1
We do not follow type synonyms when building the dependencies for each
datatype,
so we will not find out that B1 really depends on A1 (which means it
depends on
itself). To handle this problem, at the moment we add dependencies to
everything
that comes from an .hs-boot file. But we don't add those dependencies to
everything. Imagine module B above had another datatype declaration:
data B2 = B2 Int
Even though B2 has a dependency (on Int), all its dependencies are from
things
that live on other packages. Since we don't have mutual dependencies across
packages, it is safe not to add the dependencies on the .hs-boot stuff to
B2.
See also Note [Grouping of type and class declarations] in TcTyClsDecls.
-}
instead (skip the | after {- if you don't want it to be a Haddock comment).
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: RFC: style cleanup & guidelines for GHC, and related bikeshedding
Just to say that
* In general I don't have a strong opinion about these stylistic issues.
Moreover I have little bikeshed time, and if I don't contribute to
a debate I can't expect to influence it much. So I'm mostly happy to
accept a consensus view.
However, some thoughts
* I don't think we should be over-prescriptive. Eg personally I like a
do-notation style with semicolons at the beginning, eg
do { blah
; x <- foo
; etc }
but I'm disinclined to force everyone to do so, and I don't want to be
forced to do something different myself. I can adapt to the style of the
author here.
* A *primary* form of consumption is the source code itself. I've found that
Haddock-compliant comments can be rather less readable in source code.
(Eg. CoreSyn.lhs where the #blah# notation coexists uneasily with Note
[blah].)
So I'd be nervous of mandating Haddock-compliance.
* Insisting on line comments exclusively, carries a cost. The on-screen
distraction
of line comments, and the nuisance of writing them, is not trivial. Perhaps
it
is bearable, but it's non-zero. See example below.
Simon
With line comments
-- Note [Extra dependencies from .hs-boot files]
-- ~
-- Consider the following case:
--
-- module A where
-- import B
-- data A1 = A1 B1
--
-- module B where
-- import {-# SOURCE #-} A
-- type DisguisedA1 = A1
-- data B1 = B1 DisguisedA1
--
-- We do not follow type synonyms when building the dependencies for each
datatype,
-- so we will not find out that B1 really depends on A1 (which means it depends
on
-- itself). To handle this problem, at the moment we add dependencies to
everything
-- that comes from an .hs-boot file. But we don't add those dependencies to
-- everything. Imagine module B above had another datatype declaration:
--
-- data B2 = B2 Int
--
-- Even though B2 has a dependency (on Int), all its dependencies are from
things
-- that live on other packages. Since we don't have mutual dependencies across
-- packages, it is safe not to add the dependencies on the .hs-boot stuff to B2.
--
-- See also Note [Grouping of type and class declarations] in TcTyClsDecls.
With block comments
Note [Extra dependencies from .hs-boot files]
~
Consider the following case:
module A where
import B
data A1 = A1 B1
module B where
import {-# SOURCE #-} A
type DisguisedA1 = A1
data B1 = B1 DisguisedA1
We do not follow type synonyms when building the dependencies for each datatype,
so we will not find out that B1 really depends on A1 (which means it depends on
itself). To handle this problem, at the moment we add dependencies to everything
that comes from an .hs-boot file. But we don't add those dependencies to
everything. Imagine module B above had another datatype declaration:
data B2 = B2 Int
Even though B2 has a dependency (on Int), all its dependencies are from things
that live on other packages. Since we don't have mutual dependencies across
packages, it is safe not to add the dependencies on the .hs-boot stuff to B2.
See also Note [Grouping of type and class declarations] in TcTyClsDecls.
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 03 July 2014 09:45
| To: ghc-devs@haskell.org
| Subject: Re: RFC: style cleanup & guidelines for GHC, and related
| bikeshedding
|
| I fully support Austin's proposal. My eyes hurt when I work on 5 files
| and each of them is written
| in a different style.
|
| Now, to address a few points that were raised.
|
| > Is it just for the sake of beauty (not to diminish the importance of
| beauty)?
|
| * I believe that trailing whitespaces are a practical issue: they are
| invisible to the human eye
| (unless you have (setq-default show-trailing-whitespace t) \n (setq-
| default indicate-empty-lines
| t) in your .emacs file) but carry a semantic meaning for git and other
| version control systems.
| This means that accidental removal of a trailing whitespace - which can
| and will happen if you
| don't highlight them - will lead to false changes in the diff.
| That said, simply removing existing trailing whitespaces is not enough -
| we would need a way to
| keep them from reappearing. Sadly, this idea was rejected:
| http://www.haskell.org/pipermail/ghc-devs/2013-August/002074.html
| Git has some cool tools (like git diff --check) that aid programmer in
| dealing with trailing
| whitespaces, but not everyone uses them. Here's a relatively recent
| example of a new trailing
| whitespace sneaking into the source code:
|
| https://github.com/ghc/ghc/commit/ce19d5079ea85d3190e837a1fc6fbd82134
| d#diff-ababf87bf3da1f44484a901a8fbc0eb6R388
|
| So without a way to enforce this policy removing trailing whitespaces
| doesn't seem to make sense.
|
| * Tabs will become a practical problem once #9230 i
Re: "No entry for "Haskell CPP command"" error with testsuite
I wonder if we should have some magic variable in the build system that induces a full rebuild, so if you push a patch which requires a rebuild you can bump the variable and let it know. Edward Excerpts from Carter Schonwald's message of 2014-07-03 17:20:44 +0100: > yay! :) > (i spent quite a bit of time working on that patch, so you scared me > initially) > > On Thu, Jul 3, 2014 at 11:39 AM, Jan Stolarek > wrote: > > > > Did you do a make maintainer-clean ; perl boot ; ./configure > > > After you pulled the new changes? It patched the build system so you have > > > to do the above. Can't reuse a previous build > > I guess that was it. Did a clean build and all is fine. > > > > Janek > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "No entry for "Haskell CPP command"" error with testsuite
yay! :) (i spent quite a bit of time working on that patch, so you scared me initially) On Thu, Jul 3, 2014 at 11:39 AM, Jan Stolarek wrote: > > Did you do a make maintainer-clean ; perl boot ; ./configure > > After you pulled the new changes? It patched the build system so you have > > to do the above. Can't reuse a previous build > I guess that was it. Did a clean build and all is fine. > > Janek > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Luite I lack the bandwidth to respond at any technical depth, but I’d like to make encouraging noises. If you can figure out a way to make GHC do these things without making the compiler terribly complicated and making maintaining it harder, then I’m open to your proposals. Several people seem to have said “oh yes, that’d be interesting”. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Luite Stegeman Sent: 02 July 2014 17:14 To: ghc-devs; glasgow-haskell-us...@haskell.org Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
On Thu, Jul 3, 2014 at 4:13 AM, Joachim Breitner wrote: > On the other hand, having a “detab and rename” horizon where merging patches > from > before is much harder, and where "git log -L" and "git blame" fail to > work properly would be a hindrance. Minor point, but you can use "git blame -w" to tell blame to ignore whitespace changes and show you the last commit that actually changed the code. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "No entry for "Haskell CPP command"" error with testsuite
> Did you do a make maintainer-clean ; perl boot ; ./configure > After you pulled the new changes? It patched the build system so you have > to do the above. Can't reuse a previous build I guess that was it. Did a clean build and all is fine. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/07/14 17:38, Jan Stolarek wrote: > I think the reason we still have tabs in the source code is that > people usually don't change 90% of a file, but 5% or something > like that and they feel this is not enough to justify detabing of a > whole file. Which is fine, in my opinion. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlO1eTcACgkQRtClrXBQc7WqzwD+NdW5OqYSLpIlMgbOBI3grR5i EpKPA2+SWboRvdB1iAIBAKBn4lZ7CaofQ2YOnXpjX0eV3kauOxBZ27YpaQ2xQ11i =QDfM -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
> And if you are changing 90% of a file for some reason, it > probably doesn't hurt to detab it as well, etc. I think the reason we still have tabs in the source code is that people usually don't change 90% of a file, but 5% or something like that and they feel this is not enough to justify detabing of a whole file. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/07/14 11:13, Joachim Breitner wrote: > So my conclusion is that it?s ok to have the mess in the source > code forever. I mostly agree. The only way to handle this that I can presently identify is to agree on some guidelines, put them up on the Wiki, enforce them socially (maybe technologically as well, using e.g. Phabricator) with code review. I.e. make sure to not make the source *uglier* at least. Anything more drastic than this will get in everyone's way. Of course if something sufficiently drastic has to happen anyhow (AMP etc.), then this is an apt opportunity to beautifying the related code. And if you are changing 90% of a file for some reason, it probably doesn't hurt to detab it as well, etc. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlO1bJYACgkQRtClrXBQc7Wp8wEAjdnJRecFseuhW5Vxd41N7Z6f E0+PqXXpU/T8oiYuzt4A/1+7imYJOt1vsaRhj+HvSCvM5SoRk7T1M8Aoxh3QEOsC =CeaG -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "No entry for "Haskell CPP command"" error with testsuite
Did you do a make maintainer-clean ; perl boot ; ./configure After you pulled the new changes? It patched the build system so you have to do the above. Can't reuse a previous build On Thursday, July 3, 2014, Jan Stolarek wrote: > I'm trying to run the testsuite in my symlinked build tree, but keep > getting this error: > > [killy@xerxes : /dane/projekty/ghc/build] make test > make -C testsuite/tests CLEANUP=1 > OUTPUT_SUMMARY=../../testsuite_summary.txt fast > make[1]: Wejście do katalogu `/dane/projekty/ghc/build/testsuite/tests' > ../mk/boilerplate.mk:168: ../mk/ > ghcconfig_dane_projekty_ghc_build_inplace_bin_ghc-stage2.mk: No > such file or directory > "/dane/projekty/ghc/build/inplace/bin/ghc-stage2" --make -o > ../mk/ghc-config ../mk/ghc-config.hs > No entry for "Haskell CPP command" in > "/dane/projekty/ghc/build/inplace/lib/settings" > make[1]: *** [../mk/ghc-config] Error 1 > make[1]: Leaving directory `/dane/projekty/ghc/build/testsuite/tests' > make: *** [test] Error 2 > > Help? > > Janek > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
I think GHC could use more or less the same communication method as GHCJS now does: Start some user-specifiied process and send messages through pipes (GHCJS uses stdin/stderr of the node process), with the difference that it would get dynamic libraries for the target rather than blobs of JS code. That user process is then responsible for setting up the actual communication with the runner on the emulator or development device. A requirement for complete TH support is that more code can be loaded at runtime, so that multiple splices can be run by the same runner (because of the persistent map, qGetQ / qPutQ), I'm not sure if this is problematic on iOS. On Thu, Jul 3, 2014 at 2:54 AM, Carter Schonwald wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some >>> other disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or >>> operating system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure >>> more tricky, making end users think about libgmp or libiconv locations, >>> since it basically required the same preparation as building GHC from >>> source. This change will make installing much easier and more reliable (we >>> still have to update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up >>> and push the patches for the directory and process packages, but after >>> that, the TH code can read/write files, run processes and interact with >>> them and make network connections, all through node.js. >>> >>> Now since this approach is in no way specific to JavaScript, I was >>> wondering if there's any interest in getting this functionality into GHC >>> 7.10 for general cross compilation. The runner would be a native (target) >>> program with dynamic libraries (or object files) being sent over to the >>> target machine (or emulator) for the splices. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof >>> of concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> ___ >>> Glasgow-haskell-users mailing list >>> glasgow-haskell-us...@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
That is great! Please send your patches to me. I would love to update ghc-android to support 7.8. A pull request on github would be ideal, but plain patches are ok too. On 2014-07-03 05:18, member MP2E wrote: > 1. Cross GHC 7.8 using the Stage1 TH patch and a few other patches > available from Neurocyte. These need to be updated slightly as they are > for GHC 7.6, I can post updated patches if anyone else is curious. I > would be very interested in cleaning up and integrating the needed > changes into GHC, if cross Template Haskell is to be implemented. > 2. Create wrappers for hsc2hs and cabal for the cross compiler (I also > have updated these) -- CJ van den Berg mailto:c...@vdbonline.com xmpp:neuroc...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: "No entry for "Haskell CPP command"" error with testsuite
The error is probably related to: https://phabricator.haskell.org/D26 Adam Sandberg Ericsson On Thu, Jul 3, 2014 at 8:44 AM, Jan Stolarek wrote: > I'm trying to run the testsuite in my symlinked build tree, but keep > getting this error: > > [killy@xerxes : /dane/projekty/ghc/build] make test > make -C testsuite/tests CLEANUP=1 > OUTPUT_SUMMARY=../../testsuite_summary.txt fast > make[1]: Wejście do katalogu `/dane/projekty/ghc/build/testsuite/tests' > ../mk/boilerplate.mk:168: ../mk/ > ghcconfig_dane_projekty_ghc_build_inplace_bin_ghc-stage2.mk: No > such file or directory > "/dane/projekty/ghc/build/inplace/bin/ghc-stage2" --make -o > ../mk/ghc-config ../mk/ghc-config.hs > No entry for "Haskell CPP command" in > "/dane/projekty/ghc/build/inplace/lib/settings" > make[1]: *** [../mk/ghc-config] Error 1 > make[1]: Leaving directory `/dane/projekty/ghc/build/testsuite/tests' > make: *** [test] Error 2 > > Help? > > Janek > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
Yes! This would definitely be of great interest to users of the Android cross compilers. It should be quite feasible to drive a TH runner process on a development device or emulator. Having genuine TH support would be a huge improvement to the usefulness of GHC in a cross compiling scenario. I would love to start work on integrating TH runner support into ghc-android. On 2014-07-02 18:14, Luite Stegeman wrote: > Now since this approach is in no way specific to JavaScript, I was > wondering if there's any interest in getting this functionality into GHC > 7.10 for general cross compilation. The runner would be a native > (target) program with dynamic libraries (or object files) being sent > over to the target machine (or emulator) for the splices. > -- CJ van den Berg mailto:c...@vdbonline.com xmpp:neuroc...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
Hi, Am Donnerstag, den 03.07.2014, 10:44 +0200 schrieb Jan Stolarek: > Now, I understand people who don't want such change because of merge > conflicts. But the truth is there will never be a good moment to > implement such changes because there is always some ongoing > work and outstanding branches. when I first looked at GHC code I also thought “ugh, ugly”. But I can cope, it does not actually hinder me while working on GHC. On the other hand, having a “detab and rename” horizon where merging patches from before is much harder, and where "git log -L" and "git blame" fail to work properly would be a hindrance. Also, backporting patches from GHC HEAD to distribution releases would become annoying, for at least one release cycle. So my conclusion is that it’s ok to have the mess in the source code forever. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GenericsPropositionalEquality [Was: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index]
Gabor and all,
Below you'll find my encoding of GHC.Generics with DataKinds. The most
important part, for this discussion, is the treatment of meta-information.
I don't think we need |sameDatatype|, in particular; why not just use
|sameSymbol|?
Cheers,
Pedro
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ScopedTypeVariables#-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE OverlappingInstances #-}
module Test where
import GHC.TypeLits
import Data.Proxy ( Proxy(..) )
-- Universe encoding
data Un s = -- s is to always be set to *
-- Void (used for datatypes without constructors)
VV
-- Unit
| UU
-- Meta-data
| MD MetaData (Un s)
| MC MetaCons (Un s)
| MS MetaSel (Un s)
-- A parameter
| PAR
-- Constants (either other parameters or recursion into types of kind *)
| KK PRU s
-- Recursion into types of kind (* -> *)
| REC SO (s -> s)
-- Sum, product
| Un s :+: Un s
| Un s :**: Un s
-- Composition
| (s -> s) :.: Un s
-- Meta-data
-- Parameter, Recursive occurrence, or Unknown/other
data PRU = P | R SO | U
-- Self or Other
data SO = S | O
data MetaData = MetaData { dataName :: Symbol, dataModule :: Symbol }
data MetaCons = MetaCons { conName :: Symbol
, conFixity :: Fixity
, conIsRecord :: Bool }
data Fixity = Prefix | Infix Associativity Nat
data Associativity = LeftAssociative
| RightAssociative
| NotAssociative
deriving (Eq, Show, Ord, Read)
data MetaSel = MetaSel { selName :: Maybe Symbol }
-- Interpretation (as a GADT)
data In (u :: Un *) (p :: *) :: * where
-- No interpretation for VV, as it shouldn't map to any value
-- Unit
U1 :: In UU p
-- Datatype meta-data
D1 :: { unD1 :: In a p } -> In (MD md a) p
-- Constructor meta-data
C1 :: { unC1 :: In a p } -> In (MC mc a) p
-- Selector meta-data
S1 :: { unS1 :: In a p } -> In (MS ms a) p
-- The parameter
Par1 :: { unPar1 :: p } -> In PAR p
-- Constants
K1 :: { unK1 :: x} -> In (KK pru x) p
-- Recursion
Rec1 :: { unRec1 :: f p } -> In (REC i f) p
-- Sum
L1 :: In f p -> In (f :+: g) p
R1 :: In g p -> In (f :+: g) p
-- Product
(:*:) :: In f p -> In g p -> In (f :**: g) p
-- Composition
Comp1 :: { unComp1 :: f (In g p) } -> In (f :.: g) p
-- Conversions to/from user datatypes
class Generic (a :: *) where
type Rep a :: Un *
from :: a -> In (Rep a) p
to :: In (Rep a) p -> a
class Generic1 (f :: * -> *) where
type Rep1 f :: Un *
from1 :: f p -> In (Rep1 f) p
to1 :: In (Rep1 f) p -> f p
-- Example encoding: lists (with some twisted meta-data for example
purposes)
instance Generic [a] where
type Rep [a] = MD ('MetaData "[]" "Prelude")
(MC ('MetaCons "[]" Prefix False) UU
:+: MC ('MetaCons ":" (Infix RightAssociative 5)
False)
( MS ('MetaSel (Just "el")) (KK P a)
:**: MS ('MetaSel Nothing) (KK (R S) [a])))
from []= D1 (L1 (C1 U1))
from (h:t) = D1 (R1 (C1 (S1 (K1 h) :*: S1 (K1 t
to (D1 (L1 (C1 U1)))= []
to (D1 (R1 (C1 (S1 (K1 h) :*: S1 (K1 t) = h:t
-- Should have meta-information as well, but the one above is enough for now
instance Generic1 [] where
type Rep1 [] = UU :+: (PAR :**: REC S [])
from1 []= L1 U1
from1 (h:t) = R1 (Par1 h :*: Rec1 t)
to1 (L1 U1) = []
to1 (R1 (Par1 h :*: Rec1 t)) = h:t
-- Show
class GShow (r :: Un *) where
gshow :: In r p -> String
instance (Show' a) => GShow (KK pru a) where
gshow (K1 a) = show' a
instance GShow UU where
gs
Re: RFC: style cleanup & guidelines for GHC, and related bikeshedding
I fully support Austin's proposal. My eyes hurt when I work on 5 files and each
of them is written
in a different style.
Now, to address a few points that were raised.
> Is it just for the sake of beauty (not to diminish the importance of beauty)?
* I believe that trailing whitespaces are a practical issue: they are
invisible to the human eye
(unless you have (setq-default show-trailing-whitespace t) \n (setq-default
indicate-empty-lines
t) in your .emacs file) but carry a semantic meaning for git and other version
control systems.
This means that accidental removal of a trailing whitespace - which can and
will happen if you
don't highlight them - will lead to false changes in the diff.
That said, simply removing existing trailing whitespaces is not enough - we
would need a way to
keep them from reappearing. Sadly, this idea was rejected:
http://www.haskell.org/pipermail/ghc-devs/2013-August/002074.html
Git has some cool tools (like git diff --check) that aid programmer in dealing
with trailing
whitespaces, but not everyone uses them. Here's a relatively recent example of
a new trailing
whitespace sneaking into the source code:
https://github.com/ghc/ghc/commit/ce19d5079ea85d3190e837a1fc6fbd82134d#diff-ababf87bf3da1f44484a901a8fbc0eb6R388
So without a way to enforce this policy removing trailing whitespaces doesn't
seem to make sense.
* Tabs will become a practical problem once #9230 is fixed. Also, tab width
can be custom-set to
whatever value in an editor, which can trip some people. I for one used to have
tab width set to
2 (unlike the default of 4 or 8) but gave up, because too many tab-formatted
things were
displayed incorrectly.
* I strongly support turning lhs files into hs files. This is practical and
explained below.
>From my point of view other things are just pure aesthetics.
==
I'm not sure about the style of do-notation. When I first saw do { ... ; ... }
I thought it was
terrible but now, after some time, I see the merit of it. Consider this code
snippet from
StgCmmBind:
\(_offset, node, arg_regs) -> do
{ (...)
; withSelfLoop (bndr, loop_header_id, arg_regs) $ do
{ (...)
; entryHeapCheck cl_info node' arity arg_regs $ do
{
(...)
}}}
I believe that without { ... ; ... } these nested dos would have to be
indented, which wouldn't
aid readability IMO. I agree that we should use one style of the do-notation
but I'm not sure
which one should that be. I'd favor the { ... ; ... } one.
=
> So, overall, I kind of like our current policy of fixing tabs and white-space
> when we have to
modify the code anyway.
I proposed to remove tabs from the source code 1,5 year ago:
http://www.haskell.org/pipermail/ghc-devs/2013-January/53.html
Back then my conclusion was that most of the files that contain tabs were
modified in the previous
6 months. This means that people are not following the policy to remove tabs
when they modify the
file (or at least they weren't following that policy back then). So this policy
seems to be only
theory.
==
One more style issue that was not mentioned by Austin are block comments: I
strongly advocate
removal of all block comments in favour of single-line ones. Why? Here's a
reason:
{-
Note [Blah blah]
... Code snippet:
foo :: Foo -> Bar
foo = ...
-}
My primary method of finding things in the source code is grepping and I
believe that many people
do the same. With block comments it is impossible to tell whether the line
found by grep is part
of the comment. With line comments it is immediately obvious. Moreover, if all
comments were line
comments it would be really easy to grep for something only in the comments.
Currently this is
impossible. This is also true for lhs files and for that reason I also consider
lhs files to be
practical issue.
Another reason (albeit minor) to have line comments instead of block comments
is that with the
former style each comment is independent and can be freely moved around. With
block comments we
might need to create extra comment blocks when moving comments around.
==
Now, I understand people who don't want such change because of merge conflicts.
But the truth is
there will never be a good moment to implement such changes because there is
always some ongoing
work and outstanding branches. So I believe we should think whether these
changes move us in a
good direction or not and if we decide that these changes are a Good Thing -
which I believe they
are - we should bite the bullet. Otherwise we will have mess in the source code
forever.
Since I'm advocating strongly for these I am of course willing to put my work
into making this
happen. So far I've assigned #9230 to myself and if we agree to detab all the
source code I can
be the person to do it.
Janek
PS. I am proud of myself, because I
