On Sun, Sep 16, 2012 at 5:49 PM, Simon Peyton-Jones
wrote:
>
> Fixing Any
> ~~~
> * I think we can fix the Any problem readily by making Any into a type family,
> that has no instances. We certainly allow equalities with a type
> *family* application on the left and a type construc
My workaround is to wrap types of all kinds as kind *:
data WrapType (a :: k)
...or better yet, as its own kind:
data WrappedType = forall a. WrapType a
Now I can make an apples-to-apples comparison of types of different
kinds, e.g. "WrapType []" and "WrapType Bool". All I need now is a w
1) kudos to iavor and edward on the slick notation invention!
2) the key point is that ghc 7.6 does not have support for infix type
variable notation, and how to encode infix arrow notations nicely subject
that design choice, right?
i'm likely just being a tad redundant in this conversation, b
On Mon, Sep 17, 2012 at 1:02 PM, Sjoerd Visscher wrote:
> Hi,
>
> Note that nobody was suggesting two pragmas with incompatible behaviors,
> only to have just one symbol reserved to still be able to have type
> operator variables.
>
An issue with reserving a symbol for type operator variables is
Iavor: Wow, I really like the >--c--> trick at the type level.
Note: we can shorten that somewhat and improve the fixity to associate
correctly, matching the associativity of (->), which fortunately associates
to the right. (associating to the left can be done with a similar trick,
based on the or
On Fri, Sep 7, 2012 at 11:05 AM, Herbert Valerio Riedel wrote:
> Ian Lynagh writes:
>> On Thu, Sep 06, 2012 at 09:42:53AM -0700, Johan Tibell wrote:
>>> 2. Could you please push all the packages that were released in GHC
>>> 7.6.1 to Hackage as well?
>> I've now uploaded those that we maintain.
>
Hi,
Note that nobody was suggesting two pragmas with incompatible behaviors, only
to have just one symbol reserved to still be able to have type operator
variables.
I do like your suggestion, although >--c--> is quite a bit longer than ~>.
Sjoerd
On Sep 17, 2012, at 6:28 PM, Iavor Diatchki wr
Hello,
I think that it would be a mistake to have two pragmas with incompatible
behaviors: for example, we would not be able to write modules that use
Conal's libraries and, say, the type nats I've been working on.
If the main issue is the notation for arrows, has anoyone played with what
can be
I see what you're getting at, but the problem is more fundamental than just the
lack of a type *. GHC has no notion of equality between kinds other than
syntactic identity. If two kinds are other than syntactically identical, they
are considered distinct. This fact basically renders your approac
On Mon, Sep 17, 2012 at 1:07 AM, Conal Elliott wrote:
> Hi Simon,
>
> Yes, I could live with (.->), (.+), etc more easily than `arr`, `plus` etc.
>
> Better yet would be a LANGUAGE pragma I can add to my libraries to get the
> old behavior back.
>
What about treating operators as constructs unless
Hi,
recently I run into an issue using ghc-mod, as described here:
https://github.com/kazu-yamamoto/ghc-mod/issues/75
In summary, ghc-mod fails if the source file contains a `foreign'
declaration. I played around a bit, but I have no experience with the
GHC API, so any help is appreciated!
Thanks
11 matches
Mail list logo
