Determining if an instance is provided by the environment
Hello all, Suppose I have a ClsInst from typechecking the following instance declaration: instance Show [Char] -- i.e. String I'd now like to answer the question: "Is this instance 'provided' by the instance environment?" For example, this instance is provided given that I have these two instances in the environment: instance Show a => Show [a] -- (1) instance Show Char -- (2) However, if I have just instance (1) in the environment, it's not provided (and if you tried to use show "foo", you'd get the error that Char is not an instance of Show.) Is there are convenient way to do this from TcM? With 'tcMatchTys' and I can easily test if there is some instance in the environment which *matches* my instance head (e.g., Show [a] matches Show [Char]) but this doesn't tell me if all the resulting constraints are solvable. Thanks, Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2016 edition (30th edition)
Mihai Maruseac writes: > Hi, > > Thanks for the entry. In the past, I was copying the text at > https://ghc.haskell.org/trac/ghc/wiki/Status/May16 (with the > corresponding different date at the end) and formatting it in LaTeX. > Now I got a tex file which looks exactly like the text in the Trac > wiki. If not mentioned otherwise, I guess I'll use the .tex file, > since it will be easier. > Ahh, I see; thanks for letting me know! I think this time around it would be better you use the TeX source I provided as I made a few formatting improvements over the Trac document. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Looking for GHC compile-time performance tests
tl;dr. Do you have a Haskell project which GHC now compiles more slowly than in the past? If you would like to see your program's compilation time improve in 8.2, reduce it to a minimal testcase, and provide it to us via Trac. Good news everyone, GHC 8.2 will be a release largely targetting consolidation instead of new features. In particular, we will focus on compiler performance issues. One of the challenges of this task is knowing in which ways GHC has regressed. It is currently hard to know how much of the apparent compiler performance regression is due to GHC getting slower and how much is due to users demanding more of it. To better understand the performance of our compiler, we would like to collect modern Haskell code samples that exhibit compile-time performance issues (either regressions or otherwise). For this we are asking for your help: we are looking for projects that, * are small-to-moderate-sized Haskell programs which you believe have regressed in compile time in the last few GHC releases * have minimal build dependencies, in the ideal case none outside of the standard GHC boot libraries * can be licensed for use under 3-clause BSD In some cases we may also be able to make use of examples with a few library dependencies that are necessary to demonstrate the performance issue (for instance, a suspected issue stemming from stream fusion requiring Conduit). For performance issues exhibiting non-linear scaling in some quantity (e.g. the size of a type in the program), it would be extremely helpful if the testcase exposed a "knob" demonstrating this scaling. So, if you would like to see your program's compilation time improve in GHC 8.2, put some time into reducing it to something minimal, submit it to us via a Trac ticket, and let us know in this thread. Thanks for your help! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2016 edition (30th edition)
Ben Gamari writes:
> [ Unknown signature status ]
> Mihai Maruseac writes:
>
>> Dear all,
>>
>> It's that time of the year again (https://ro-che.info/ccc/16). :)
>>
>> We would like to collect contributions for the 30th edition of the
>>
> Hello Mihai,
>
> Here is GHC's contribution to the current HCAR. Let me know if you'd
> like me to make any revisions. Sorry for the late submission!
>
Hi Mihai,
If possible, it would be great if you could instead use this revised
HCAR text as GHC's submission. This includes a few late amendments that
would be nice to have.
Cheers,
- Ben
signature.asc
Description: PGP signature
\documentclass[DIV16,twocolumn,10pt]{scrreprt}
\usepackage{paralist}
\usepackage{graphicx}
\usepackage[final]{hcar}
%include polycode.fmt
\begin{document}
\begin{hcarentry}{(GHC Status Report)}
\report{the GHC developers}
\status{GHC developments continues to race forward with exciting news abounding.}
\makeheader
GHC development churns onward --- and \textbf{GHC 8.0 is right around the corner!}
The final set of bugs are being fixed, and we hope to have a final release
candidate, followed by the final release, in just a few weeks. More exciting
developments await for 8.2 and beyond.
\subsubsection{Major changes in GHC 8.0.1}
GHC 8.0.1, the first release in the 8.0 series, will be released in May 2016.
While this is significantly later than expected, we think that the features that
this release brings should be well worth the wait. These include,
\begin{itemize}
\item \textbf{Lightweight, implicit call-stacks}\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations}}.
Provides a \texttt{HasCallStack} constraint that can be added to any
function to obtain a partial call-stack, with source locations, at that point in
the program. \texttt{HasCallStack} and all related API functions are provided by
the \texttt{GHC.Stack} module in \texttt{base}. The functions \texttt{error} and
\texttt{undefined} now have a \texttt{HasCallStack} constraint and will print
out the partial call-stack alongside the given error message.
\item \textbf{Injective type families}
(Wiki\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies}},
paper\footnote{\url{http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/injective-type-families-acm.pdf}}).
Allows to annotate type families with injectivity information. Correctness of
injectivity annotation is then verified by the compiler. Once compiler knows the
annotation is correct it can us injectivity information during type checking.
\item \textbf{Applicative do notation}.
With the new \texttt{-XApplicativeDo} extension, GHC tries to desugar \texttt{do}-notation
to \texttt{Applicative} where possible, giving a more convenient sugar for
many common \texttt{Applicative} expressions. See the
draft paper\footnote{\url{http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/applicativedo.pdf}}
and GHC Wiki\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo}} for details.
\item A \textbf{beautiful new users guide}\footnote{\url{http://downloads.haskell.org/~ghc/8.0.1-rc4/docs/html/users_guide/}}.
Now rewritten in reStructured
Text, and with significantly improved output and documentation.
\item \textbf{Visible type application}.
This allows you to say, for example, \texttt{id @Bool} to specialize
\texttt{id} to \texttt{Bool -> Bool}. With this feature, proxies are needed only
in data constructors for pattern matching. Visible type patterns are due to be
included sometime in the indeterminate future. See the
Wiki\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/ExplicitTypeApplication}}
for details.
\item \textbf{Kind Equalities}, which form the first step to building
Dependent Haskell. This feature enables promotion of GADTs to kinds, kind
families, heterogeneous equality (kind-indexed GADTs), and \texttt{* :: *}.
See the Wiki\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1}}
for more information.
\item \textbf{Record system enhancements}. A new extension
\texttt{DuplicateRecordFields} will be available in GHC 8.0, allowing
multiple uses of the same field name with a very limited form of type-directed
name resolution. Support for polymorphism over record fields is being worked on;
another provisional new extension \texttt{OverloadedLabels} represents a first
step in this process. See the GHC
Wiki\footnote{\url{http://ghc.haskell.org/trac/ghc/wiki/OverloadedRecordFields}}
for details.
\item A huge improvement to \textbf{pattern match checking} (including much
better coverage of GADTs), based on the work of Simon PJ and Georgios
Karachalias. For more details, see their paper
\footnote{\url{https://people.cs.kuleuven.be/~george.karachalias/papers/p424-karachalias.pdf}}
wit
Generics performance
Hi Ryan! As you may know, we are encouraging contributors to view the 8.2 release as a consolidation release, using it as an opportunity to optimize, stabilize, document, and refine existing features instead of introducing new ones. It seems like there is plenty of optimization that could be done in your area of generics. In particular #5642 and #11991 are quite relevant and have been felt by a fair number of users. While compiling derived Generic instances can necessarily produce quadratic code (see ticket:5642#comment:8), the costs that we are seeing do seem a bit high so perhaps there are some constant factors that we can knock down. However, working this out will require a concerted effort. Would you be interested in picking up this issue as a task for 8.2? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
