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
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
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
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
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
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
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
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
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
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
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
`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
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
. 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
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
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
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
21 matches
Mail list logo
