type constructor polymorphism

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

type constructor polymorphism

Heinz Hölzer-2
Hi List,

would it be possible and useful to include type constructor polymorphism into the language (together with function type constraints). I'm currently getting my hands dirty on monads.
I understand the concept and how useful it is (especially for library designers), but there is currently no way to define abstractions of them. For example a functor is defined in haskell as:
class Functor f where
   fmap :: (a -> b) -> f a -> f b

or in scala as :
(i removed xmap and extends for simplicity)
trait Functor[F[_]] {
  def fmap[A, B](r: F[A], f: A => B): F[B]
}

in haxe this would be something like:

interface Functor<F<_>> {
	public function fmap <A, B> (r:F<A>, f: A-> B): F<B>;
}

interface Functor<F> {
	public function fmap <A, B> (r:F<A>, f: A-> B): F<B>;
}


and Usage

class Option<T> implements Functor<Option> {}

best,
h


btw: this is a nice paper about this concept: http://www.cs.kuleuven.be/publicaties/doctoraten/cw/CW2009_03.pdf


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Heinz Hölzer-2
Sorry for the links inside of the scala implementation, it should be:

trait Functor[F[_]] {
  def fmap[A, B](r: F[A], f: A => B): F[B]
}

Am 07.11.2011 17:39, schrieb Heinz Hölzer:
Hi List,

would it be possible and useful to include type constructor polymorphism into the language (together with function type constraints). I'm currently getting my hands dirty on monads.
I understand the concept and how useful it is (especially for library designers), but there is currently no way to define abstractions of them. For example a functor is defined in haskell as:
class Functor f where
   fmap :: (a -> b) -> f a -> f b

or in scala as :
(i removed xmap and extends for simplicity)
trait Functor[F[_]] {
  def fmap[A, B](r: F[A], f: A => B): F[B]
}

in haxe this would be something like:

interface Functor<F<_>> {
	public function fmap <A, B> (r:F<A>, f: A-> B): F<B>;
}

interface Functor<F> {
	public function fmap <A, B> (r:F<A>, f: A-> B): F<B>;
}


and Usage

class Option<T> implements Functor<Option> {}

best,
h


btw: this is a nice paper about this concept: http://www.cs.kuleuven.be/publicaties/doctoraten/cw/CW2009_03.pdf


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
In reply to this post by Heinz Hölzer-2
Let me argue you don't want to derive a category (like Functor) but instanciate it in scope for implicit usage like haskell and scala does.
That's the other half of the technic to unleash all benefits!

+1

Stephane..

Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Johann Borck
In reply to this post by Heinz Hölzer-2
On 11/07/2011 05:39 PM, Heinz Hölzer wrote:
Hi List,

would it be possible and useful to include type constructor polymorphism into the language (together with function type constraints).
Hello Heinz,
IMO it is the single missing feature that'd make haxe second to none. Well, almost. I'd be interested in contributing to this effort, maybe those interested could work out a more concrete proposal, starting with an evaluation of the current implementations of the type checker and type inference algorithms in haxe, and what would be required to make it work.

BTW, scuts is awesome, you made my weekend :)

regards,
Johann


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Tarwin Stroh-Spijer
You're going to have to convince luddite (non-programmers) like myself that this is really that useful before I'll fight for you. This means concrete examples, and useful / interesting derived work - not just syntactic-sugar-programming-theory.

Thanks! 


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Mon, Nov 7, 2011 at 1:10 PM, Johann Borck <[hidden email]> wrote:
On 11/07/2011 05:39 PM, Heinz Hölzer wrote:
Hi List,

would it be possible and useful to include type constructor polymorphism into the language (together with function type constraints).
Hello Heinz,
IMO it is the single missing feature that'd make haxe second to none. Well, almost. I'd be interested in contributing to this effort, maybe those interested could work out a more concrete proposal, starting with an evaluation of the current implementations of the type checker and type inference algorithms in haxe, and what would be required to make it work.

BTW, scuts is awesome, you made my weekend :)

regards,
Johann


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
I realize a lot of people here are not versed in type theory and, yes, to be frank it can some what feel like pedantic people speaking for themselves.

It is really not, it's just a matter of knowing the concept and the name it has, and it's very enlighting.

It's like explaining parametric types (or templates) to someone which never heard of it.
So there's two possibilities; just trust or invest enough time to understand the concept.
I bet you're on the latter case :)

So I think the best is to direct you to this excellent paper from Martin Odersky, Adriaan Moors & Frank Piessens - it has code examples in it showing how it reduces code duplication and generalize APIs:

http://adriaanm.github.com/files/higher.pdf

Everyone can learn from other languages with different type system to expand its knowledge and tools.
(and read on my lipses:  java, c#, c++, actionscript, etc.. are all the same, uninteresting and retarded old shit... )

Learning other languages will bring important concepts / abstractions in light.

Stephane

Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
In reply to this post by Johann Borck
I'm just afraid bringing Kinds won't make it into haxe without breaking compatibility (I think about macros manipulating the AST for instance)..
So may be good for a major haXe version like 3.0..

!! Pure speculative part !!:
As for the will of Nicolas to do so.. I'm skeptical as I think he may want to keep things simpler on the compiler side and I think that haXe is designed as a RAD language and not as general as these features could bring it to. It's matter of choices and tradeoffs; there's so much type theory stuff that would be nice.. (and I would love).

However; perhaps I'm completely wrong.. it would be nice to hear his position about that..

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Nicolas Cannasse
Le 08/11/2011 10:49, sledorze a écrit :

> I'm just afraid bringing Kinds won't make it into haxe without breaking
> compatibility (I think about macros manipulating the AST for instance)..
> So may be good for a major haXe version like 3.0..
>
> !! Pure speculative part !!:
> As for the will of Nicolas to do so.. I'm skeptical as I think he may want
> to keep things simpler on the compiler side and I think that haXe is
> designed as a RAD language and not as general as these features could bring
> it to. It's matter of choices and tradeoffs; there's so much type theory
> stuff that would be nice.. (and I would love).
>
> However; perhaps I'm completely wrong.. it would be nice to hear his
> position about that..

It entirely depends on the ratio of compiler changes wrt what the
feature brings. In the current topic case, this seems quite hard to get
it right compared to what it would bring.

A counter example is GADT, which I think could be added quite easily to
haXe with only minor syntax changes and a little code :

enum Op<T> {
    OInt( v : Int ) : Op<Int>;
    OBool( b : Bool ) : Op<Bool>;
    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
}

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
That's what I though.. It's a major change.
(
Let me argur however that the benefits depends on the usage of the language..
An interesting example is the difference in the collection library - pre / post  the higher kind introduction in Scala; it's now just dead obvious it's the right solution to this particular usage..
)

Anyway; I can criticize the choices but reality remains; haXe is here; it works it's nice for RAD and that's why I use it; if I want to build an heavy system with big abstractions; I would develop with Scala and some other alternatives; at another pace..

GADTs would be a very nice addition indeed! :)
(and the nested destructuring switchs!!)

Let me propose also a last entry:

enum Op<T> { 
    OInt( v : Int ) : Op<Int>; 
    OBool( b : Bool ) : Op<Bool>; 
    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>; 
    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>; 
    OFoo<S>( a : Op<S>, b : Op<Bool> ) : Op<S>; 
}


On Tue, Nov 8, 2011 at 11:14 AM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 08/11/2011 10:49, sledorze a écrit :

> I'm just afraid bringing Kinds won't make it into haxe without breaking
> compatibility (I think about macros manipulating the AST for instance)..
> So may be good for a major haXe version like 3.0..
>
> !! Pure speculative part !!:
> As for the will of Nicolas to do so.. I'm skeptical as I think he may want
> to keep things simpler on the compiler side and I think that haXe is
> designed as a RAD language and not as general as these features could bring
> it to. It's matter of choices and tradeoffs; there's so much type theory
> stuff that would be nice.. (and I would love).
>
> However; perhaps I'm completely wrong.. it would be nice to hear his
> position about that..
It entirely depends on the ratio of compiler changes wrt what the
feature brings. In the current topic case, this seems quite hard to get
it right compared to what it would bring.

A counter example is GADT, which I think could be added quite easily to
haXe with only minor syntax changes and a little code :

enum Op<T> {
    OInt( v : Int ) : Op<Int>;
    OBool( b : Bool ) : Op<Bool>;
    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
}

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6973779.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Heinz Hölzer-2
In reply to this post by Nicolas Cannasse
GADT sounds really interesting, let me ask some questions, because i'm
not sure if i understand it correctly.

1) It's only a compile time construct, right?

2) How do i add functions for such a type?

something like:

enum Show<T> {
     SAll<S>(s:S):Show<String>;
}

class ShowString {
     public static function show (s:Show<String>):String {
         // do we need to switch on s here to get the String value, and
if yes, does this switch only exist at compile time.
     }
}

class ShowInt {
     public static function show (i:Show<Int>):String {
         // do we need to switch on i here?
     }
}

3) How do i call such a function:

import Show;
import ShowString;

var s = "foo";

ShowString.show(SAll(s));

// maybe we can get implicit conversions like

s.show();


4) Would it allow raw types like Op<Array>?

enum Op<T> {
     OArray<S>( s:Array<S> ): Op<Array>;
}



best,
h



Am 08.11.2011 11:12, schrieb Nicolas Cannasse:

> Le 08/11/2011 10:49, sledorze a écrit :
>> I'm just afraid bringing Kinds won't make it into haxe without breaking
>> compatibility (I think about macros manipulating the AST for instance)..
>> So may be good for a major haXe version like 3.0..
>>
>> !! Pure speculative part !!:
>> As for the will of Nicolas to do so.. I'm skeptical as I think he may
>> want
>> to keep things simpler on the compiler side and I think that haXe is
>> designed as a RAD language and not as general as these features could
>> bring
>> it to. It's matter of choices and tradeoffs; there's so much type theory
>> stuff that would be nice.. (and I would love).
>>
>> However; perhaps I'm completely wrong.. it would be nice to hear his
>> position about that..
>
> It entirely depends on the ratio of compiler changes wrt what the
> feature brings. In the current topic case, this seems quite hard to
> get it right compared to what it would bring.
>
> A counter example is GADT, which I think could be added quite easily
> to haXe with only minor syntax changes and a little code :
>
> enum Op<T> {
>    OInt( v : Int ) : Op<Int>;
>    OBool( b : Bool ) : Op<Bool>;
>    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
Think of it has an enum.

1) Runtime; only type checking is done at compile time.

2) You need a switch to destructure it (an alternative would be to use Views (aka Extractors in Scala); but this is another feature).

3)
or SAll(s).show() if using ('using').
implicits are another topic.. (orthogonal)

It's not a function but a constructor (even if constructors are functions on disguise.. (everything is a function in some ways))

4) -> this is orthogonal to GADTs; your using a higher kind here (Type function; Array is a function from a type T to a type Array<T>).

2011/11/8 Heinz Hölzer-2 [via Haxe] <[hidden email]>
GADT sounds really interesting, let me ask some questions, because i'm
not sure if i understand it correctly.

1) It's only a compile time construct, right?

2) How do i add functions for such a type?

something like:

enum Show<T> {
     SAll<S>(s:S):Show<String>;
}

class ShowString {
     public static function show (s:Show<String>):String {
         // do we need to switch on s here to get the String value, and
if yes, does this switch only exist at compile time.
     }
}

class ShowInt {
     public static function show (i:Show<Int>):String {
         // do we need to switch on i here?
     }
}

3) How do i call such a function:

import Show;
import ShowString;

var s = "foo";

ShowString.show(SAll(s));

// maybe we can get implicit conversions like

s.show();


4) Would it allow raw types like Op<Array>?

enum Op<T> {
     OArray<S>( s:Array<S> ): Op<Array>;
}



best,
h



Am 08.11.2011 11:12, schrieb Nicolas Cannasse:

> Le 08/11/2011 10:49, sledorze a écrit :
>> I'm just afraid bringing Kinds won't make it into haxe without breaking
>> compatibility (I think about macros manipulating the AST for instance)..
>> So may be good for a major haXe version like 3.0..
>>
>> !! Pure speculative part !!:
>> As for the will of Nicolas to do so.. I'm skeptical as I think he may
>> want
>> to keep things simpler on the compiler side and I think that haXe is
>> designed as a RAD language and not as general as these features could
>> bring
>> it to. It's matter of choices and tradeoffs; there's so much type theory
>> stuff that would be nice.. (and I would love).
>>
>> However; perhaps I'm completely wrong.. it would be nice to hear his
>> position about that..
>
> It entirely depends on the ratio of compiler changes wrt what the
> feature brings. In the current topic case, this seems quite hard to
> get it right compared to what it would bring.
>
> A counter example is GADT, which I think could be added quite easily
> to haXe with only minor syntax changes and a little code :
>
> enum Op<T> {
>    OInt( v : Int ) : Op<Int>;
>    OBool( b : Bool ) : Op<Bool>;
>    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas
>
>

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6974422.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Heinz Hölzer-2
Thx a lot.

i'm trying to get my head around this. Do you have a real world example, especially with recursive typing?

best,
h


Am 08.11.2011 15:31, schrieb sledorze:
Think of it has an enum.

1) Runtime; only type checking is done at compile time.

2) You need a switch to destructure it (an alternative would be to use Views (aka Extractors in Scala); but this is another feature).

3)
or SAll(s).show() if using ('using').
implicits are another topic.. (orthogonal)

It's not a function but a constructor (even if constructors are functions on disguise.. (everything is a function in some ways))

4) -> this is orthogonal to GADTs; your using a higher kind here (Type function; Array is a function from a type T to a type Array<T>).

2011/11/8 Heinz Hölzer-2 [via Haxe] <[hidden email]>
GADT sounds really interesting, let me ask some questions, because i'm
not sure if i understand it correctly.

1) It's only a compile time construct, right?

2) How do i add functions for such a type?

something like:

enum Show<T> {
     SAll<S>(s:S):Show<String>;
}

class ShowString {
     public static function show (s:Show<String>):String {
         // do we need to switch on s here to get the String value, and
if yes, does this switch only exist at compile time.
     }
}

class ShowInt {
     public static function show (i:Show<Int>):String {
         // do we need to switch on i here?
     }
}

3) How do i call such a function:

import Show;
import ShowString;

var s = "foo";

ShowString.show(SAll(s));

// maybe we can get implicit conversions like

s.show();


4) Would it allow raw types like Op<Array>?

enum Op<T> {
     OArray<S>( s:Array<S> ): Op<Array>;
}



best,
h



Am 08.11.2011 11:12, schrieb Nicolas Cannasse:

> Le 08/11/2011 10:49, sledorze a écrit :
>> I'm just afraid bringing Kinds won't make it into haxe without breaking
>> compatibility (I think about macros manipulating the AST for instance)..
>> So may be good for a major haXe version like 3.0..
>>
>> !! Pure speculative part !!:
>> As for the will of Nicolas to do so.. I'm skeptical as I think he may
>> want
>> to keep things simpler on the compiler side and I think that haXe is
>> designed as a RAD language and not as general as these features could
>> bring
>> it to. It's matter of choices and tradeoffs; there's so much type theory
>> stuff that would be nice.. (and I would love).
>>
>> However; perhaps I'm completely wrong.. it would be nice to hear his
>> position about that..
>
> It entirely depends on the ratio of compiler changes wrt what the
> feature brings. In the current topic case, this seems quite hard to
> get it right compared to what it would bring.
>
> A counter example is GADT, which I think could be added quite easily
> to haXe with only minor syntax changes and a little code :
>
> enum Op<T> {
>    OInt( v : Int ) : Op<Int>;
>    OBool( b : Bool ) : Op<Bool>;
>    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas
>
>

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6974422.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze




View this message in context: Re: type constructor polymorphism
Sent from the Haxe mailing list archive at Nabble.com.




--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
Check this snippet (Scala case classes hierarchy can represent (open) GADTs).
http://www.scala-lang.org/node/48

You cannot represent the same type garantees without GADTs as each enum entry would be polymorphic.
Think about it; try to write it with current enums.
You'll understand by yourself then.

If haskell syntax (damn lovely after the first frightning) does not hurt you; then you're at google far from a ton of papers about it..

2011/11/8 Heinz Hölzer-2 [via Haxe] <[hidden email]>
Thx a lot.

i'm trying to get my head around this. Do you have a real world example, especially with recursive typing?

best,
h


Am 08.11.2011 15:31, schrieb sledorze:
Think of it has an enum.

1) Runtime; only type checking is done at compile time.

2) You need a switch to destructure it (an alternative would be to use Views (aka Extractors in Scala); but this is another feature).

3)
or SAll(s).show() if using ('using').
implicits are another topic.. (orthogonal)

It's not a function but a constructor (even if constructors are functions on disguise.. (everything is a function in some ways))

4) -> this is orthogonal to GADTs; your using a higher kind here (Type function; Array is a function from a type T to a type Array<T>).

2011/11/8 Heinz Hölzer-2 [via Haxe] <[hidden email]>

GADT sounds really interesting, let me ask some questions, because i'm
not sure if i understand it correctly.

1) It's only a compile time construct, right?

2) How do i add functions for such a type?

something like:

enum Show<T> {
     SAll<S>(s:S):Show<String>;
}

class ShowString {
     public static function show (s:Show<String>):String {
         // do we need to switch on s here to get the String value, and
if yes, does this switch only exist at compile time.
     }
}

class ShowInt {
     public static function show (i:Show<Int>):String {
         // do we need to switch on i here?
     }
}

3) How do i call such a function:

import Show;
import ShowString;

var s = "foo";

ShowString.show(SAll(s));

// maybe we can get implicit conversions like

s.show();


4) Would it allow raw types like Op<Array>?

enum Op<T> {
     OArray<S>( s:Array<S> ): Op<Array>;
}



best,
h



Am 08.11.2011 11:12, schrieb Nicolas Cannasse:

> Le 08/11/2011 10:49, sledorze a écrit :
>> I'm just afraid bringing Kinds won't make it into haxe without breaking
>> compatibility (I think about macros manipulating the AST for instance)..
>> So may be good for a major haXe version like 3.0..
>>
>> !! Pure speculative part !!:
>> As for the will of Nicolas to do so.. I'm skeptical as I think he may
>> want
>> to keep things simpler on the compiler side and I think that haXe is
>> designed as a RAD language and not as general as these features could
>> bring
>> it to. It's matter of choices and tradeoffs; there's so much type theory
>> stuff that would be nice.. (and I would love).
>>
>> However; perhaps I'm completely wrong.. it would be nice to hear his
>> position about that..
>
> It entirely depends on the ratio of compiler changes wrt what the
> feature brings. In the current topic case, this seems quite hard to
> get it right compared to what it would bring.
>
> A counter example is GADT, which I think could be added quite easily
> to haXe with only minor syntax changes and a little code :
>
> enum Op<T> {
>    OInt( v : Int ) : Op<Int>;
>    OBool( b : Bool ) : Op<Bool>;
>    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas
>
>

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6974422.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15




View this message in context: Re: type constructor polymorphism
Sent from the Haxe mailing list archive at Nabble.com.




--
haXe - an open source web programming language
http://haxe.org


If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6974916.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Juraj Kirchheim
In reply to this post by Nicolas Cannasse
> A counter example is GADT, which I think could be added quite easily to haXe
> with only minor syntax changes and a little code :
>
> enum Op<T> {
>   OInt( v : Int ) : Op<Int>;
>   OBool( b : Bool ) : Op<Bool>;
>   OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>   OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas

Can't one simply compose this?

enum Logic {
     Atom(b:Bool);
     And(l1:Logic, l2:Logic);
     Eq<A>(v1:A, v2:A);
     Lte<A : Float>(v1:A, v2:A);//assuming the constraint would work -
which is something far more helpful IMHO
}
enum Arithmetic<T : Float> {
     Const(x:T);
     Add(v1:T, v2:T);
}

I think throwing them together makes things a lot harder to compose
and to deal with. And opens up question like: If I know something is
Op<Int> will I only have to check OInt and OAdd in a switch statement?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
In reply to this post by Nicolas Cannasse
I meant
    OFoo<S>( a : Op<S>, b : Op<T> ) : Op<T>; 


On Tue, Nov 8, 2011 at 11:25 AM, Stephane Le Dorze <[hidden email]> wrote:
That's what I though.. It's a major change.
(
Let me argur however that the benefits depends on the usage of the language..
An interesting example is the difference in the collection library - pre / post  the higher kind introduction in Scala; it's now just dead obvious it's the right solution to this particular usage..
)

Anyway; I can criticize the choices but reality remains; haXe is here; it works it's nice for RAD and that's why I use it; if I want to build an heavy system with big abstractions; I would develop with Scala and some other alternatives; at another pace..

GADTs would be a very nice addition indeed! :)
(and the nested destructuring switchs!!)

Let me propose also a last entry:

enum Op<T> { 
    OInt( v : Int ) : Op<Int>; 
    OBool( b : Bool ) : Op<Bool>; 
    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>; 
    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>; 
    OFoo<S>( a : Op<S>, b : Op<Bool> ) : Op<S>; 
}


On Tue, Nov 8, 2011 at 11:14 AM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 08/11/2011 10:49, sledorze a écrit :

> I'm just afraid bringing Kinds won't make it into haxe without breaking
> compatibility (I think about macros manipulating the AST for instance)..
> So may be good for a major haXe version like 3.0..
>
> !! Pure speculative part !!:
> As for the will of Nicolas to do so.. I'm skeptical as I think he may want
> to keep things simpler on the compiler side and I think that haXe is
> designed as a RAD language and not as general as these features could bring
> it to. It's matter of choices and tradeoffs; there's so much type theory
> stuff that would be nice.. (and I would love).
>
> However; perhaps I'm completely wrong.. it would be nice to hear his
> position about that..
It entirely depends on the ratio of compiler changes wrt what the
feature brings. In the current topic case, this seems quite hard to get
it right compared to what it would bring.

A counter example is GADT, which I think could be added quite easily to
haXe with only minor syntax changes and a little code :

enum Op<T> {
    OInt( v : Int ) : Op<Int>;
    OBool( b : Bool ) : Op<Bool>;
    OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
    OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
}

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6973779.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15





--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

sledorze
In reply to this post by Juraj Kirchheim
Your enum is not parametrized or not recursive (in the latter case).
And you lost specific constructors constraints.
This is less generic and expressive.


On Tue, Nov 8, 2011 at 6:35 PM, Juraj Kirchheim [via Haxe] <[hidden email]> wrote:
> A counter example is GADT, which I think could be added quite easily to haXe

> with only minor syntax changes and a little code :
>
> enum Op<T> {
>   OInt( v : Int ) : Op<Int>;
>   OBool( b : Bool ) : Op<Bool>;
>   OAdd( a : Op<Int>, b : Op<Int> ) : Op<Int>;
>   OAnd( a : Op<Bool>, b : Op<Bool> ) : Op<Bool>;
> }
>
> Best,
> Nicolas
Can't one simply compose this?

enum Logic {
     Atom(b:Bool);
     And(l1:Logic, l2:Logic);
     Eq<A>(v1:A, v2:A);
     Lte<A : Float>(v1:A, v2:A);//assuming the constraint would work -
which is something far more helpful IMHO
}
enum Arithmetic<T : Float> {
     Const(x:T);
     Add(v1:T, v2:T);
}

I think throwing them together makes things a lot harder to compose
and to deal with. And opens up question like: If I know something is
Op<Int> will I only have to check OInt and OAdd in a switch statement?

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/type-constructor-polymorphism-tp6971073p6975191.html
To unsubscribe from type constructor polymorphism, click here.



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: type constructor polymorphism

Heinz Hölzer-2
In reply to this post by Johann Borck
IMO it is the single missing feature that'd make haxe second to none. Well, almost. I'd be interested in contributing to this effort, maybe those interested could work out a more concrete proposal, starting with an evaluation of the current implementations of the type checker and type inference algorithms in haxe, and what would be required to make it work.

Sounds great, but to be honest, in the moment i'm just trying to get my head around this stuff. So my knowledge in this area is really limited ;)

BTW, scuts is awesome, you made my weekend :)

Thx, but it's not really useable at the moment, i'm changing lots of things currently.


Am 07.11.2011 22:10, schrieb Johann Borck:
On 11/07/2011 05:39 PM, Heinz Hölzer wrote:
Hi List,

would it be possible and useful to include type constructor polymorphism into the language (together with function type constraints).
Hello Heinz,
IMO it is the single missing feature that'd make haxe second to none. Well, almost. I'd be interested in contributing to this effort, maybe those interested could work out a more concrete proposal, starting with an evaluation of the current implementations of the type checker and type inference algorithms in haxe, and what would be required to make it work.

BTW, scuts is awesome, you made my weekend :)

regards,
Johann





--
haXe - an open source web programming language
http://haxe.org