Hi Bulat,
This seems quite reasonable to me. Have you eyeballed the assembly
GCC produces to see that the hotpath is improved? If you can submit
a patch that would be great!
Cheers,
Edward
Excerpts from Bulat Ziganshin's message of 2014-10-14 10:08:59 -0700:
Hello Glasgow-haskell-users,
i'm
Hi Iavor,
On 13/10/14 21:34, Iavor Diatchki wrote:
Hello,
We now have an implementation of type-checker with plugin support. If
you are interested in trying it out:
- Checkout and build the `wip/tc-plugins` branch of GHC
Thanks, this is great! I'd been working on a similar
This will become easier, I think. look on wip/new-flatten-skoelms-Aug14. I'm
now unflattening after solving the flat constraints.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Adam Gundry
| Sent: 16
Thanks Simon, your branch does make it a lot more feasible to unflatten,
so I'll just go ahead and implement that in my plugin for now.
Eric, that's fair enough, and I don't have any concrete use cases for
non-equality constraints at the moment. I'm just keen to minimize the
restrictions placed
With the prelude changes that people have been discussing recently
I've been wondering is there any reason why importing an identifier
explicitly and unqualified doesn't automatically hide any implicit
imports of the same identifier? Specifically I'm wondering about cases
where you've imported an
I think this is a great idea. I also think it should apply to the name
shadowing warning—identifiers imported implicitly should never trigger that.
On Thu, Oct 16, 2014 at 6:19 PM, Malcolm Gooding goodi...@gmail.com wrote:
With the prelude changes that people have been discussing recently
I've
My first thought is: Wouldn't this make it impossible to reorder or
sort imports lexicographically (or otherwise), without fully parsing,
renaming and typechecking the code?
For example, I often use ghc-mod plus stylish-haskell to order and
format my imports. If there is no syntactic indication
| Thanks Simon, your branch does make it a lot more feasible to unflatten,
| so I'll just go ahead and implement that in my plugin for now.
Actually it would be worth pausing. If you get the latest Unflattening is now
done by getInertUnsolved, which itself is called by solveFlatWanteds,
I can think of a use for a non-equality constraint: an alphabetical ordering on
Symbol. This would allow experimental implementations of extensible records
(without shadowing) which keep the labels sorted.
An order constraint on Nat might be useful, too.
Barney.
the alphabetical ordering on Symbol is already exposed via TypeLits... this
would be some machinery to help maintain that ordering with less user
intervention?
On Thu, Oct 16, 2014 at 6:59 PM, Barney Hilken b.hil...@ntlworld.com
wrote:
I can think of a use for a non-equality constraint: an
Ok, I hadn't realised that. Looking in the user's guide, I see = and =? for
Nat, but I couldn't find anything about Symbol. I must try them out!
From: Carter Schonwald carter.schonw...@gmail.com
the alphabetical ordering on Symbol is already exposed via TypeLits... this
would be some
It should be good enough (for what you're talking about) to hide them all.
Turn
import A (foo)
import B (bar)
import C hiding (baz)
import D
into
import A (foo)
import B (bar)
import C hiding (foo,bar,baz)
import D hiding (foo,bar)
There's no reason to worry about hiding nonexistent
Yeah, I just realized that would work too. You would still need to do two
passes over the imports, so foo and bar are hidden from anything imported
above A. Though while we're reasoning syntactically, you would also need to
hide them from the Prelude if it was being implicitly imported.
--
View
http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html
type family CmpSymbol m n :: Ordering
http://hackage.haskell.org/package/base-4.7.0.1/docs/Data-Ord.html#t:Ordering
On Thu, Oct 16, 2014 at 7:14 PM, Barney Hilken b.hil...@ntlworld.com
wrote:
Ok, I hadn't realised that.
mind you, i'm not sure what the ordering is specified to be :)
On Thu, Oct 16, 2014 at 9:24 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-TypeLits.html
type family CmpSymbol m n :: Ordering
Simon Marlow marlo...@gmail.com writes:
I was working on a fix yesterday but ran out of time. Frankly this code is a
nightmare, every time I touch it it breaks on some platform - this time I
validated on 64 bit Windows but not 32. Aargh indeed.
Before I start breaking this code up into
16 matches
Mail list logo
