April 2015 - ghc-devs

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by David Feuer 10 Apr '15

10 Apr '15

I think a module exporting some but not all data constructors of a type is fundamentally broken behavior. I would generally be in favor of prohibiting it altogether, and I would be strongly opposed to letting continued support for it break anything else. On Apr 10, 2015 9:05 AM, "Douglas McClean" <douglas.mcclean(a)gmail.com> wrote: > I don't think that 2+3 is equivalent to 2', because an explicit import > list or hiding list could've brought only some of the datatype's > constructors into visibility. > > On Fri, Apr 10, 2015 at 8:07 AM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > >> Here's an idea: For a module to be Safe, then for each exported datatype, >> one of the following must hold: >> 1) The datatype comes with a role annotation. >> 2) The module exports all of the datatype's constructors. >> 3) If the datatype is defined in a place other than the current module, >> the current module exports no fewer data constructors than are exported in >> the datatype's defining module. >> >> Why? >> 1) The role annotation, even if it has no effect, shows that the >> programmer has considered roles. Any mistake here is clearly the >> programmer's fault. >> 2) This datatype is clearly meant not to be abstract. `Coercible` then >> gives clients no more power than they already have. >> 3) This is subtler. It is a common idiom to export a datatype's >> constructors from a package-internal module, but then never to export the >> constructors beyond the package. If such a datatype has a role annotation >> (in its defining module, of course), then we're fine, even if it is >> exported abstractly later. However, suppose we are abstractly re-exporting >> a datatype that exports its constructors from its defining module. If there >> is no role annotation on the datatype, we're in trouble and should fail. >> BUT, if the datatype were exported abstractly in its defining module, then >> we don't need to fail on re-export, because nothing has changed. >> >> >> Actually, we could simplify the conditions. Change (2) to: >> >> 2') The module exports all of the datatype's visible constructors. >> >> I think explaining in terms of separate rules (2) and (3) is a little >> clearer, because the re-export case is slightly subtle, and this subtlety >> can be lost in (2'). >> >> This proposal would require tracking (in interface files, too) whether or >> not a datatype comes with a role annotation. This isn't hard, though. It >> might even help in pretty-printing. >> >> >> An alternative would be to have a way of setting roles differently on >> export than internally. I don't think this breaks the type system, but it's >> yet another thing to specify and support. And we'd have to consider the >> possibility that some module will import a datatype from multiple >> re-exporting modules, each with different ascribed role annotations. Is >> this an error? Does GHC take some sort of least upper bound? I prefer not >> to go here, but there's nothing terribly wrong with this approach. >> >> Richard >> >> On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei(a)gmail.com> wrote: >> >> > I'll prepare a patch for the userguide soon. >> > >> > As for something better, yes I think we can and should. It's on my >> > todo list :) Basically, the new-GND design has all the mechanisms to >> > be safe, but sadly the defaults are rather worrying. Without explicit >> > annotations from the user, module abstractions are broken. This is why >> > we left GND out of Safe Haskell for the moment as it is a subtle and >> > easy mistake to make. >> > >> > If the module contained explicit role annotations then it could be >> > allowed. The discussion in >> > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that >> > I prefer, such as only exporting the Coerce instance if all the >> > constructors are exported, it seems that the ship sailed on these >> > bigger changes sadly. >> > >> > Cheers, >> > David >> > >> > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> >> wrote: >> >> There is a long discussion on >> https://ghc.haskell.org/trac/ghc/ticket/8827 >> >> about whether the new Coercible story makes GND ok for Safe Haskell. >> At a >> >> type-soundness level, definitely yes. But there are other >> less-clear-cut >> >> issues like “breaking abstractions” to consider. The decision on the >> ticket >> >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but >> there >> >> is room for a better proposal. >> >> >> >> >> >> >> >> I don’t have an opinion myself. David Terei and David Mazieres are in >> the >> >> driving seat, but I’m sure they’ll be responsive to user input. >> >> >> >> >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> >> sentence “GeneralizedNewtypeDeriving — It can be used to violate >> constructor >> >> access control, by allowing untrusted code to manipulate protected data >> >> types in ways the data type author did not intend, breaking invariants >> they >> >> have established.” vanished from the 7.8 user manual (links below). >> Maybe >> >> it should be restored. >> >> >> >> >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the >> manual? >> >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Omari Norman [mailto:omari@smileystation.com] >> >> Sent: 09 April 2015 02:44 >> >> To: haskell Cafe >> >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> >> >> >> >> When compiling code with Generalized Newtype Deriving and the >> -fwarn-unsafe >> >> flag, I get >> >> >> >> >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the >> safe >> >> language? The GHC manual used to state that GNTD is not allowed in >> Safe >> >> Haskell: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… >> >> >> >> >> >> >> >> But this language on GNTD not being part of the safe language was >> removed in >> >> the 7.8 manual: >> >> >> >> >> >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… >> >> >> >> >> >> >> >> The GHC release notes don't say anything about this one way or the >> other. >> >> Thoughts? >> >> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs(a)haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > J. Douglas McClean > > (781) 561-5540 (cell) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

1 0

Collapsing HsForAllTy, again
by Alan & Kim Zimmerman 10 Apr '15

10 Apr '15

With the help of Jan Stolarek I tracked down the HsForAllTy flattening to `HsTypes.mk_forall_ty`. This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one. I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation. But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy causes significant gymnastics in the parser [1]. So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity. Regards Alan [1] https://phabricator.haskell.org/D833

2 7

API Annotations, MINIMAL pragma and BooleanFormula
by Alan & Kim Zimmerman 10 Apr '15

10 Apr '15

My last (known) issue is the MINIMAL pragma for a class definition. In Parser.y this is captured (via `name_boolformula`) as a BooleanFormula (Located RdrName) There is a problem with this from an API annotations point of view in that the constructors (mkBool,mkAnd,mkOr) are smart and try to minimise the boolean formula as it is constructed. Unfortunately this discards information in the process. I see a number of potential solutions a. Capture the original source string for the pragma, and use that for the annotations. This is a bad option. b. Introduce a new variant of BooleanFormula for the AST, and convert to use the current one when evaluating the pragma. c. Keep the BooleanFormula as it is, but do not minimise the formula on construction. I suspect that c is the best option, I do not believe the formulas constructed are particularly complex or numerous, so early optimisation is not necessary. Which is the best option? Or is there a different one? Regards Alan

1 0

RE: Advice on replacing ghc-split
by Tamar Christina 09 Apr '15

09 Apr '15

Thanks Mikhail, I'll read through the threads. Cheers, TamarFrom: Mikhail Glushenkov Sent: ‎09/‎04/‎2015 22:56 To: Tamar Christina Cc: GHC Subject: Re: Advice on replacing ghc-split Hi, On 9 April 2015 at 20:14, Tamar Christina <lonetiger(a)gmail.com> wrote: > [...] > > So I see my options as follows: > > Inline one of the regexp libraries, e.g. pcre-light > [...] When LLVM developers were faced with a similar issue [1], they decided to use OpenBSD's regex implementation [2,3]. [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025047.html [2] http://llvm.org/docs/doxygen/html/regexec_8c_source.html [3] http://llvm.org/docs/doxygen/html/classllvm_1_1Regex.html

1 0

Advice on replacing ghc-split
by Tamar Christina 09 Apr '15

09 Apr '15

Hi All, I have been working on creating a Haskell replacement for the perl script ghc-split. The issue I need some advice on is that the perl script is 280 SLOC primarily because of the use of RegExpr. The problem I have is that It seems i’m limited to only packages that are available already because GHC needs them (since it seems to compile using the in-place cabal and pkg list, am I correct here?). So I see my options as follows: Inline one of the regexp libraries, e.g. pcre-light Create my own string matching functions (possibly a simple DFA and encode the rexexpr into that) Use parsec (which I think is available as part of the ghc build no?) Does anyone have an idea on what the best approach would be? The regexpr don’t seem to use any perl extensions, so normal posix regex would be fine, I thought Base contained a regexp component. But it seems that’s now a separate library? Kind Regards, Tamar

2 1

Where are the HsTyVarBndrs collapsed in an explicit HsForAllTy?
by Alan & Kim Zimmerman 09 Apr '15

09 Apr '15

When parsing extremumNewton :: (Eq a, Fractional a) => (forall tag. forall tag1. Tower tag1 (Tower tag a) -> Tower tag1 (Tower tag a)) -> a -> [a] the nested `forall` declarations are parsed by ctypedoc :: { LHsType RdrName } : 'forall' tv_bndrs '.' ctypedoc {% hintExplicitForall (getLoc $1) >> ams (sLL $1 $> $ mkExplicitHsForAllTy $2 (noLoc []) $4) [mj AnnForall $1,mj AnnDot $3] } This generates a HsForAllTy for the first forall that simply wraps the second one, which is also a `ctypedoc`. But, when looking at the AST provided via ParsedSource, the two `forall`s are collapsed into a single one, containing both `tag` and `tag1` in the TyVarBndrs. In the process the annotation for the second forall loses its anchor, as that span is no longer in the AST. I cannot find where this collapsing takes place, can anyone point me at it? Thanks Alan

1 0

Flurry of late patches for 7.10.2
by Alan & Kim Zimmerman 08 Apr '15

08 Apr '15

You may have noticed that I have submitted a lot of patches for the 7.10.2 release at a very late stage. I apologise for this, but it has been triggered by an exciting test conducted by Matt Pickering using the new ghc-exactprint[1] based on the API Annotations in 7.10.1 He ran it in round-trip mode over all the source files in hackage, with the following results Total: 62,741 files. Parse fails: 6,611 CPP: 4,487 (not currently processed, coming soon) So the total succesfully processed was 51,643 files. Of these, 3,042 failed to reproduce the source exactly. The patches coming in are to bring the 3,042 count down even further. Regards Alan [1] https://github.com/alanz/ghc-exactprint

1 0

Toward better syntax errors
by Dan Aloni 08 Apr '15

08 Apr '15

Hello, Forwarded here is a link to a blog post I authored about improving GHC's syntax errors: http://blog.aloni.org/posts/toward-better-ghc-syntax-errors/ In fact, this came about after I started using Happy more extensively, and at one point thought that GHC could benefit too The gist of it, is that it was relatively easy to reach an improvement such as follows (notice 'possible tokens' below): input: -- test i = case i of 2 main = return () output: -- example1.hs:2:1: parse error (possibly incorrect indentation or mismatched brackets), possible tokens: '|' '->' It spawned a more extensive discussion regarding type errors here: https://www.reddit.com/r/haskell/comments/31m7pc/toward_better_ghc_syntax_e… Following to that, it was suggested that a further discussion in the GHC dev mailing list can continue about this direction (syntax errors, type errors and whatnot). -- Dan Aloni

2 2

Validate problems on Windows
by Simon Peyton Jones 07 Apr '15

07 Apr '15

Folks I'm getting this stuff at the end of a validate run. The test failures are at least understandable. But what's all this "traceback" stuff from Python? And "Warning:haddock-interfaces"? Simon Unexpected failures: ../../libraries/array/tests T9220 [bad stdout] (ghci) ../../libraries/base/tests/System Timeout001 [bad exit code] (normal) codeGen/should_compile debug [bad exit code] (normal) ghc-e/should_fail T9930fail [bad exit code] (normal) ghci/linking T1407 [bad stderr] (ghci) ghci/scripts T5975a [bad stderr] (ghci) ghci/scripts T9878b [bad exit code] (ghci) rts T7037 [bad stdout] (normal) stranal/should_run T10148 [bad stderr] (optasm) Unexpected stat failures: perf/compiler T5030 [stat too good] (normal) perf/compiler T5837 [stat too good] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9872d [stat not good enough] (normal) perf/should_run T9203 [stat not good enough] (normal) Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist-install/doc/html/base/base.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist-install/doc/html/Cabal/Cabal.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t' make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' == Start post-testsuite package check Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d\package.cache Timestamp 2015-04-07 18:53:42 UTC for C:/code/HEAD/inplace\lib\package.conf.d (same as cache) using cache: C:/code/HEAD/inplace\lib\package.conf.d\package.cache db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] modifying: Nothing flag db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] Warning: haddock-interfaces: C:\code\HEAD\libraries\stm\dist-install\doc\html\stm\stm.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\parallel\dist-install\doc\html\parallel\parallel.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\compiler\stage2\doc\html\ghc\ghc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\haskeline\dist-install\doc\html\haskeline\haskeline.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\transformers\dist-install\doc\html\transformers\transformers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hoopl\dist-install\doc\html\hoopl\hoopl.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bin-package-db\dist-install\doc\html\bin-package-db\bin-package-db.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Cabal\Cabal\dist-install\doc\html\Cabal\Cabal.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\binary\dist-install\doc\html\binary\binary.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\template-haskell\dist-install\doc\html\template-haskell\template-haskell.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\pretty\dist-install\doc\html\pretty\pretty.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hpc\dist-install\doc\html\hpc\hpc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\process\dist-install\doc\html\process\process.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\directory\dist-install\doc\html\directory\directory.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\time\dist-install\doc\html\time\time.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Win32\dist-install\doc\html\Win32\Win32.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\containers\dist-install\doc\html\containers\containers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bytestring\dist-install\doc\html\bytestring\bytestring.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\deepseq\dist-install\doc\html\deepseq\deepseq.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\array\dist-install\doc\html\array\array.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\filepath\dist-install\doc\html\filepath\filepath.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\base\dist-install\doc\html\base\base.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\integer-gmp\dist-install\doc\html\integer-gmp\integer-gmp.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\ghc-prim\dist-install\doc\html\ghc-prim\ghc-prim.haddock doesn't exist or isn't a file == End post-testsuite package check

1 0

[haskell.org Google Summer of Code] Call for Mentors
by Edward Kmett 06 Apr '15

06 Apr '15

We have had a rather large pool of potential students apply for this year's Google Summer of Code, but, ultimately, Google won't let us ask for a slot unless we have a potential mentor assigned in advance. On top of that, one thing we try to do with each project is wherever possible, assign both a primary and a backup mentor, so the available mentoring pool is drawn a little thin. Many hands make for light work, though: If you've mentored or thought about mentoring in years past, I'd encourage you to sign up on google-melange for the Google Summer of Code at: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and request a connection to haskell.org as a Mentor. Once you've done this you can help us vote on proposals, and should something seem appropriate to you, you can flag yourself as available as a potential mentor or backup mentor for one (or more) of the projects. We have a couple of weeks left to rate proposals and request slots, but it'd be good to make as much progress as we can this week. If you have any questions, feel free to reach out to me, or to Shachaf Ben-Kiki or Gershom Bazerman who have been helping out with organizational issues this year. We also have a #haskell-gsoc channel on irc.freenode.net if you have questions about what is involved. Thank you for your time and consideration, -Edward Kmett

1 0