On 13/02/2012, at 11:10, Simon Peyton-Jones wrote:
| Should there perhaps be a NewTypeable module which could then be renamed
| into Typeable once it is sufficiently well established?
I started with that idea, but there would be a 2-stage process:
* Step 1: (when PolyTypable becomes
Sent from my iPhone
On Feb 14, 2012, at 3:00 AM, Roman Leshchinskiy r...@cse.unsw.edu.au wrote:
On 13/02/2012, at 11:10, Simon Peyton-Jones wrote:
| Should there perhaps be a NewTypeable module which could then be renamed
| into Typeable once it is sufficiently well established?
I
Hello,
On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett ekm...@gmail.com wrote:
There are fewer combinators from commonly used classes for working with
the left argument of a bifunctor, however.
I think that the bifunctor part of Bas's version is a bit of a red herring.
What I like about it is
On Tue, Feb 14, 2012 at 11:18 AM, Iavor Diatchki
iavor.diatc...@gmail.comwrote:
Hello,
On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett ekm...@gmail.com wrote:
There are fewer combinators from commonly used classes for working with
the left argument of a bifunctor, however.
I think that the
Proxy also has the advantage that it almost exactly mirrors what it
ends up looking
like in core. The application to proxy is the user visible type application.
John
On Tue, Feb 14, 2012 at 8:18 AM, Iavor Diatchki
iavor.diatc...@gmail.com wrote:
Hello,
On Mon, Feb 13, 2012 at 5:32 PM,
| Should there perhaps be a NewTypeable module which could then be renamed
| into Typeable once it is sufficiently well established?
I started with that idea, but there would be a 2-stage process:
* Step 1: (when PolyTypable becomes available) People change to import
Data.PolyTypeable
* Step
On 10/02/2012 16:03, Simon Peyton-Jones wrote:
Friends
The page describes an improved implementation of the Typeable class, making use
of polymorphic kinds. Technically it is straightforward, but it represents a
non-backward-compatible change to a widely used library, so we need to make a
You could probably get away with something like
data Proxy = Proxy a
class Typeable a where
typeOfProxy :: Proxy a - TypeRep
typeOf :: forall a. Typeable a = a - TypeRep
typeOf = typeOfProxy (Proxy :: Proxy a)
which being outside of the class won't contribute to the inference of 'a's
kind.
On 13/02/12 18:16, Edward Kmett wrote:
You could probably get away with something like
data Proxy = Proxy a
class Typeable a where
typeOfProxy :: Proxy a - TypeRep
typeOf :: forall a. Typeable a = a - TypeRep
typeOf = typeOfProxy (Proxy :: Proxy a)
which being outside of the class won't
On Mon, Feb 13, 2012 at 3:27 PM, Simon Marlow marlo...@gmail.com wrote:
On 13/02/12 18:16, Edward Kmett wrote:
You could probably get away with something like
data Proxy = Proxy a
class Typeable a where
typeOfProxy :: Proxy a - TypeRep
typeOf :: forall a. Typeable a = a - TypeRep
On 12/02/2012, at 03:21, Iavor Diatchki wrote:
PS: I wouldn't worry too much about breaking existing code, as long as
derived Typeable instances continue to work---I never provide custom
ones and, in fact, I think that GHC should no allow them or, at least,
give a stern warning when it sees
In practice I've found that working with Tagged is a huge pain relative to
working with Proxy.
You usually need to use ScopedTypeVariables or do asTypeOf/asArgOf tricks
that are far more complicated than they need to be.
For reference you can compare the internals of reflection before when it
On 10/02/2012, at 23:30, John Meacham wrote:
something I have thought about is perhaps a special syntax for Proxy, like
{:: Int - Int } is short for (Proxy :: Proxy (Int - Int)). not sure whether
that is useful enough in practice though, but could be handy if we are
throwing
around types a
I am not so sure, adding type applications to the language seems
fairly radical and will change many aspects of the language. Something
like Proxy that can be expressed in relatively vanilla haskell and
some handy desugarings is much more attractive to me.
With type apllications you end up with
On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh ig...@earth.li wrote:
But it would be better if they could use the new definition. Is
PolyKinds sufficiently well-defined and simple that it is feasible for
other Haskell implementations to implement it?
There is actually a much simpler extension I
typo, I meant
Proxy :: (exists k . k) - * is isomorphic to Proxy :: forall k . k - *
John
On Sat, Feb 11, 2012 at 6:02 PM, John Meacham j...@repetae.net wrote:
On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh ig...@earth.li wrote:
But it would be better if they could use the new definition. Is
Hello,
I like Bas's variation on the design (except, perhaps, for the name
Tagged ;) It captures exactly what we are trying to do: the
dictionary for Typeable becomes simply the run-time representation of
the type. Coincidentally, this is exactly the same as what I am using
to link value level
On 2/11/12 8:12 PM, John Meacham wrote:
On Sat, Feb 11, 2012 at 5:05 PM, Roman Leshchinskiyr...@cse.unsw.edu.au
wrote:
IMO, polymorphic kinds are far too experimental at this stage to be used in
such a fundamental library. I also fully agree with Ian's point about other
implementations.
On 10.02.2012 20:03, Simon Peyton-Jones wrote:
Friends
The page describes an improved implementation of the Typeable class, making use
of polymorphic kinds. Technically it is straightforward, but it represents a
non-backward-compatible change to a widely used library, so we need to make a
| Where is Proxy data type defined?
In the section The new Typeable class of
http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable
| Which instances should it have?
Well, Typeable, perhaps! But that is no so relevant here.
S
___
On Fri, Feb 10, 2012 at 04:03:42PM +, Simon Peyton-Jones wrote:
The page describes an improved implementation of the Typeable class, making
use of polymorphic kinds. Technically it is straightforward, but it
represents a non-backward-compatible change to a widely used library, so we
Would it be useful to make 'Proxy' an unboxed type itself? so
Proxy :: forall k . k - #
This would statically ensure that no one accidentally passes ⊥ as a parameter
or will get anything other than the unit 'Proxy' when trying to evaluate it.
So the compiler can unconditionally elide the
On Fri, Feb 10, 2012 at 03:30:02PM -0800, John Meacham wrote:
something I have thought about is perhaps a special syntax for Proxy, like
{:: Int - Int } is short for (Proxy :: Proxy (Int - Int)). not sure whether
that is useful enough in practice though, but could be handy if we are
23 matches
Mail list logo
