are lots of heuristics in GHC's optimiser which mean that in more
complicated situations it will not always apply full-laziness as much as
possible. Moreover, full-laziness can introduce space leaks. My
colleague Edsko wrote a nice blog post a few years ago that explores
this in more detai
ome
> devious/indirect other classes/instances or exploits separate
> compilation, to hide what's going on from the compiler's enthusiasm.)
>
> But (~) does some sort of magic: it's a kinda typeclass but without a
> method. How does it mesh with type improvement in the goldilocks
on the GHC proposals process being
formally sanctioned. ;-)
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman
ight not want to! But the ramifications haven't been
fully thought through, e.g. we'd need to be able to solve the constraint
HasField T "foo" (((forall a . a -> a) -> Bool) -> Bool)
even though it has a polytype as an argument.
S
ords/OverloadedRecordFields/DuplicateRecordFields
[2]
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/MagicClasses
[3] https://phabricator.haskell.org/D1687
[4]
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/OverloadedLabels
--
Adam Gundry, Haskell Consultant
cd HListPlugin/ex
make
Is this approach supposed to be possible, or am I supposed to rewrite
things such that I only produce CtGivenS from the plugin?
Regards,
Adam
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
Hi Merijn,
Thanks for persevering with explaining things to me. :-)
On 09/02/15 09:47, Merijn Verstraaten wrote:
On 6 Feb 2015, at 21:31, Adam Gundry a...@well-typed.com wrote:
What does all monomorphic cases mean? Is the idea what GHC would
typecheck an expression involving a literal
. Finding unused syntax is always a problem, of course.
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow
with strings (e.g. checking that
ByteStrings are ASCII) is rather out of reach at present.
Adam
[1]
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign#Implicitvalues
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
the
intermediate lists?
Hope this helps,
Adam
The program is a solution to this problem:
https://open.kattis.com/problems/tourist
The input data can be found here:
http://heim.ifi.uio.no/~db/nm-i-programmering/nm2004/testdata/h.in
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http
wrote:
Hello,
On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com
mailto:a...@well-typed.com wrote:
One problem I've run into is transforming the flattened
CFunEqCans into
unflattened form (so the flatten-skolems don't get in the way
` on
`TcPlugin` in the names of all things plugin related, so you could
grep for this. The basic API
types and functions are defined in `TcRnTypes` and `TcRnMonad`.
Happy hacking,
-Iavor
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
the flat constraints.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Adam Gundry
| Sent: 16 October 2014 11:59
| To: Iavor Diatchki
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Type
the idea:
https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker
Feedback is very welcome, particularly if (a) you have an interesting
use for this feature or (b) you think this is a terrible idea!
Thanks,
Adam
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com
On 04/07/13 12:27, AntC wrote:
H-R fields are a limitation because we can't update them either. So I
think it's a fair question whether supporting h-r polymorphism is
worth the limitations?
Yes, higher rank polymorphism is bound to cause trouble with polymorphic
projections, and perhaps it
Hi all,
I have amended the plan [1] as a result of the ongoing discussion,
including leaving the syntax alone for the time being, so record
projections are written prefix.
Regarding Barney's suggestion of field declarations:
On 01/07/13 10:50, Barney Hilken wrote:
All this extra syntax,
Hi Edward,
I was envisaging that we might well need a functional dependency
class Has (r :: *) (x :: Symbol) (t :: *) | r x - t
and, as you point out, composition of polymorphic accessors certainly
motivates this. Isn't that enough, though? I think it works out more
neatly than the type family
Thanks everyone for the illuminating discussion, and for your awareness
of the dangers of bikeshedding. ;-) I think we are making progress though.
I like the idea of making -XFunnyDotSyntax or whatever a separate
extension. It's simple, resolves something of a love-hate issue, and
reduces
If you have any comments on the proposed changes, or anything is unclear
about the design, I'd like to hear from you.
Thanks,
Adam Gundry
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo
Hi,
On 13/05/13 03:47, Akio Takano wrote:
Hi,
The attached program does not typecheck if I don't include a type
signature for 'bar' (the line C). I can't figure out if this is a
limitation in the type system or a bug in GHC. One thing that confuses
me is that replacing the line (B) with
I'm not Conor, but I'll have a go...
On 31/08/12 20:14, Simon Peyton-Jones wrote:
Try translating into System FC! It’s not just a question of what the
type checker will pass; we also have to produce a well-typed FC program.
As Edward and others have recognised, the problem here is that FC
21 matches
Mail list logo