+1 for orthogonal -XDotPostfixApply.
I'm in the absolutely-love-using-dot-for-records camp, but I also like "foo
s1.toUpper s2.toUpper".
We're already so lazy about parentheses -- e.g. the non-haskellers I show
code to are always appalled at $ ;-) -- and this helps scrap more parens!
On Mon, J
This is an exciting effort! Just a quick reaction to Simon's comments on
CoreM.
On Tue, Jul 2, 2013 at 9:11 AM, Simon Peyton-Jones wrote:
> To your questions:
>
> **
>
> **·**To do these kind of things, CoreM will need more reader
> stuff. In particular:
>
> **o **The global TypeE
| I also noticed a problem with my logic for creating the NT-lifting
| function. Suppose
| data C a = MkC (Foo a)
| Just having the constructors of C in scope is not sufficient
| to safely provide
| NT a b -> NT (C a) (C b)
| as the parameters of the constructor might wrap a in another
Hi,
Am Dienstag, den 02.07.2013, 14:11 + schrieb Simon Peyton-Jones:
> I'm not sure that a plugin is the way to go here, though it's a good
> start.
as I said, it is just to host the prototype that allows for quick
experimentation and allows people to test it without having to compile
GHC.
On 02/07/13 10:57, Simon Peyton-Jones wrote:
Here is Plan A: use fundep (or type function)
class Has r f t | r f -> t where
getFld :: r -> t
instance Has (R a) “foo” (a -> a) where ..
instance Has S “bar” (forall b. b -> b) where ...
Lacking (as we still do) impredicative p
Good stuff. The basic idea seems good to me.
I'm not sure that a plugin is the way to go here, though it's a good start.
·Exactly which programs are type-correct? Eg
coerce (listNT createNT)
It all depends on exactly what type args createNT is applied to.
·A function f =
On Tue, Jul 2, 2013 at 4:53 AM, AntC wrote:
> >
> > I was envisaging that we might well need a functional dependency
> >
>
> Hi Adam, Edward, (Simon),
>
> I think we should be really careful before introducing FunDeps (or type
> functions).
>
> Can we get to the needed type inference with Undecid
Unfortunately, I don't think we get away with this...
On 02/07/13 11:45, AntC wrote:
> There's **three** alternatives. ...
>
>>
>> data R a = MkR { foo :: a -> a }
>> data S= MkS { bar :: forall b. b -> b }
>>
>
> Try Plan C: use a cleverer (associated) type function
>
> Simon Peyton-Jones microsoft.com> writes:
>
> ...; it’s a tradeoff between polymorphism and overloading.
>
Hah! my post crossed with Simon's. This time I'll be succinct.
There's **three** alternatives. ...
>
> data R a = MkR { foo :: a -> a }
> data S = MkS { bar ::
Edward, is quite right. Thank you for pointing this out; I hadn’t fully
absorbed the consequences of the three-parameter Has class. This isn’t a
fundep-vs-type-function thing; it’s a tradeoff between polymorphism and
overloading.
There seem to be two alternatives. I’ll use fundep notation j
>
> I was envisaging that we might well need a functional dependency
>
Hi Adam, Edward, (Simon),
I think we should be really careful before introducing FunDeps (or type
functions).
Can we get to the needed type inference with UndecidableInstances?
Is that so bad?
In the original SORF proposa
11 matches
Mail list logo
