On 2/11/12 8:12 PM, John Meacham wrote:
On Sat, Feb 11, 2012 at 5:05 PM, Roman Leshchinskiy
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.
Should there perhaps be
On 2/11/12 9:47 AM, Greg Weber wrote:
What is the use case for changing the type of a record field on update?
I use it all the time. One may just as well ask: What is the use case
for changing the type of a Maybe on update? Or what is the use case for
changing only one of the types for a tupl
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 12/02/2012, at 01:44, John Meacham wrote:
> 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 attra
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 wrote:
> On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh wrote:
>> But it would be better if they could use the new definition. Is
>> PolyKinds sufficie
On Fri, Feb 10, 2012 at 2:24 PM, Ian Lynagh 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 have in jhc c
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 od
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 ty
I hate using things like 'new', 'old', 'unsafe' in module names, the
words are too overloaded and mean different things in different
contexts. you end up with things like 'NewerTypeable'. So why not call
it what it is already known by, 'Data.PolyTypeable'.
John
On Sat, Feb 11, 2012 at 5:05 P
On 10/02/2012, at 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
> nee
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
use
Hi,
Greg Wever wrote:
> What is the use case for changing the type of a record field on
> update?
Lots.
For example, I often use in the context of abstract syntax parametrised
on the type of some kind of "annotation". A transformation may then
take an abstract syntax tree with one type of anno
On Tue, Aug 09, 2011 at 06:37:11PM +0200, Goetz Isenmann wrote:
>
> please consider the following two patches for DragonFly support.
Applied, thanks.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.hask
[snip]
>
> | So I propose we move forward with implementing Has constraints, but do
> | not expose it to the user (similar to TDNR). We don't add abstraction
> | over fields or virtual fields or any special capabilities that would
> | expose the implementation.
>
> Fair enough. I call this the "M
14 matches
Mail list logo
