New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow arbitrary type parameters on @:genericBuild types #3089

Closed
back2dos opened this Issue Jun 3, 2014 · 18 comments

Comments

Projects
None yet
7 participants
@back2dos
Member

back2dos commented Jun 3, 2014

Is there any reason why the type parameters must at all be declared beforehand?

Ideally, we could have types like Or<A, B, ..., X> or And<A, B, ..., X> or Minus<T, A, B, ..., C> etc.

Would it make sense to discuss an alternative syntax for @:genericBuild (which does seem a little awkward to put it mildly) or would I just be wasting everyone's time? ;)

@Simn Simn self-assigned this Jun 3, 2014

@Simn Simn added this to the 3.2 milestone Jun 3, 2014

@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jun 3, 2014

Member

I thought about this too in the context of a Tuple type. It should be possible to lift this restriction.

Member

Simn commented Jun 3, 2014

I thought about this too in the context of a Tuple type. It should be possible to lift this restriction.

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 15, 2014

Member

What's the status of this issue?

Member

nadako commented Jul 15, 2014

What's the status of this issue?

@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jul 15, 2014

Member

I implemented it but didn't really like my implementation, so this issue will probably sit here for a while.

Member

Simn commented Jul 15, 2014

I implemented it but didn't really like my implementation, so this issue will probably sit here for a while.

@Simn Simn closed this in 2050938 Jul 17, 2014

@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jul 17, 2014

Member

The type parameter name has to be Rest for this to work.

Member

Simn commented Jul 17, 2014

The type parameter name has to be Rest for this to work.

@back2dos

This comment has been minimized.

Show comment
Hide comment
@back2dos

back2dos Jul 17, 2014

Member

This is awesome! \o/

I would like to suggest for the parameter to be called _ if the parser
(or typer?) doesn't take issue with that. Just to avoid adding any more
magic identifiers.

On Thu, Jul 17, 2014 at 3:14 PM, Simon Krajewski notifications@github.com
wrote:

The type parameter name has to be Rest for this to work.


Reply to this email directly or view it on GitHub
#3089 (comment)
.

Member

back2dos commented Jul 17, 2014

This is awesome! \o/

I would like to suggest for the parameter to be called _ if the parser
(or typer?) doesn't take issue with that. Just to avoid adding any more
magic identifiers.

On Thu, Jul 17, 2014 at 3:14 PM, Simon Krajewski notifications@github.com
wrote:

The type parameter name has to be Rest for this to work.


Reply to this email directly or view it on GitHub
#3089 (comment)
.

@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jul 17, 2014

Member

That would require parser changes, and I would like to reserve the underscore in case we decide to support higher kinded types at some point.

Member

Simn commented Jul 17, 2014

That would require parser changes, and I would like to reserve the underscore in case we decide to support higher kinded types at some point.

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 17, 2014

Member

This one gives an error:

Fatal error: exception Assert_failure("type.ml", 474, 9)
Raised at file "type.ml", line 474, characters 9-21
Called from file "type.ml", line 473, characters 42-52
Called from file "type.ml", line 476, characters 13-32
Called from file "typer.ml", line 832, characters 2-35
Called from file "typer.ml", line 3195, characters 15-45
Called from file "typer.ml", line 2517, characters 13-41
Called from file "list.ml", line 55, characters 20-23
Called from file "typer.ml", line 2511, characters 10-523
Called from file "typer.ml", line 2638, characters 11-34
Called from file "typer.ml", line 2652, characters 9-16
Called from file "typer.ml", line 2716, characters 10-38
Called from file "typeload.ml", line 1280, characters 2-25
Called from file "typeload.ml", line 2028, characters 21-72
Called from file "typecore.ml", line 355, characters 3-6
Called from file "typeload.ml", line 2232, characters 51-59
Called from file "typecore.ml", line 345, characters 3-6
Called from file "main.ml", line 1401, characters 2-21
Called from file "main.ml", line 597, characters 3-11
Called from file "main.ml", line 1611, characters 1-35
class Signal<Rest> {
    public function new() {}
}

class Main {
    static function main() {
        var signal = new Signal<Int,String>();
    }
}
Member

nadako commented Jul 17, 2014

This one gives an error:

Fatal error: exception Assert_failure("type.ml", 474, 9)
Raised at file "type.ml", line 474, characters 9-21
Called from file "type.ml", line 473, characters 42-52
Called from file "type.ml", line 476, characters 13-32
Called from file "typer.ml", line 832, characters 2-35
Called from file "typer.ml", line 3195, characters 15-45
Called from file "typer.ml", line 2517, characters 13-41
Called from file "list.ml", line 55, characters 20-23
Called from file "typer.ml", line 2511, characters 10-523
Called from file "typer.ml", line 2638, characters 11-34
Called from file "typer.ml", line 2652, characters 9-16
Called from file "typer.ml", line 2716, characters 10-38
Called from file "typeload.ml", line 1280, characters 2-25
Called from file "typeload.ml", line 2028, characters 21-72
Called from file "typecore.ml", line 355, characters 3-6
Called from file "typeload.ml", line 2232, characters 51-59
Called from file "typecore.ml", line 345, characters 3-6
Called from file "main.ml", line 1401, characters 2-21
Called from file "main.ml", line 597, characters 3-11
Called from file "main.ml", line 1611, characters 1-35
class Signal<Rest> {
    public function new() {}
}

class Main {
    static function main() {
        var signal = new Signal<Int,String>();
    }
}
@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jul 17, 2014

Member

Uhm yes, it doesn't actually check for the @:genericBuild metadata right now.

Member

Simn commented Jul 17, 2014

Uhm yes, it doesn't actually check for the @:genericBuild metadata right now.

@andyli

This comment has been minimized.

Show comment
Hide comment
@andyli

andyli Jul 17, 2014

Member

Why is it named Rest, but not Any or Dynamic?
Is that it can be used like class Foo<A,B,Rest> to make sure there are >= 3 type params?

Member

andyli commented Jul 17, 2014

Why is it named Rest, but not Any or Dynamic?
Is that it can be used like class Foo<A,B,Rest> to make sure there are >= 3 type params?

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 17, 2014

Member

Here's a sample Signal class builder using this new feature: https://gist.github.com/nadako/b086569b9fffb759a1b5

Member

nadako commented Jul 17, 2014

Here's a sample Signal class builder using this new feature: https://gist.github.com/nadako/b086569b9fffb759a1b5

@waneck

This comment has been minimized.

Show comment
Hide comment
@waneck

waneck Jul 17, 2014

Member

whoa, that's awesome!

Member

waneck commented Jul 17, 2014

whoa, that's awesome!

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 17, 2014

Member

@andyli yeah, class Foo<A,B,Rest> is supposed to make sure you have >= 2 type params (not 3 tho)

Member

nadako commented Jul 17, 2014

@andyli yeah, class Foo<A,B,Rest> is supposed to make sure you have >= 2 type params (not 3 tho)

@andyli

This comment has been minimized.

Show comment
Hide comment
@andyli

andyli Jul 17, 2014

Member

I see, cool :)

Member

andyli commented Jul 17, 2014

I see, cool :)

@ncannasse

This comment has been minimized.

Show comment
Hide comment
@ncannasse

ncannasse Jul 17, 2014

Member

Nice one, Tuple should be quite easy now

Member

ncannasse commented Jul 17, 2014

Nice one, Tuple should be quite easy now

@Simn

This comment has been minimized.

Show comment
Hide comment
@Simn

Simn Jul 17, 2014

Member

haxe.ds.Tuple? :)

Member

Simn commented Jul 17, 2014

haxe.ds.Tuple? :)

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 17, 2014

Member

I dunno, IMHO the tuple type, even if implemented in a nicely optimized way (i.e. stack allocated where possible) is not very useful without some short syntax and value unpacking.

Still, I think what we can build with @:genericBuild is very nice, but I'd vote against adding it to std lib right now, because we don't want to be constrained by it later if we decide to implement some syntax-powered tuple type.

And of course I, as many people would vote for adding a properly designed core tuple type to haxe.

Member

nadako commented Jul 17, 2014

I dunno, IMHO the tuple type, even if implemented in a nicely optimized way (i.e. stack allocated where possible) is not very useful without some short syntax and value unpacking.

Still, I think what we can build with @:genericBuild is very nice, but I'd vote against adding it to std lib right now, because we don't want to be constrained by it later if we decide to implement some syntax-powered tuple type.

And of course I, as many people would vote for adding a properly designed core tuple type to haxe.

@nadako

This comment has been minimized.

Show comment
Hide comment
@nadako

nadako Jul 21, 2014

Member

Anyway, here's a simple tuple builder: https://gist.github.com/nadako/2ad4246f257e627a5833

Member

nadako commented Jul 21, 2014

Anyway, here's a simple tuple builder: https://gist.github.com/nadako/2ad4246f257e627a5833

@PDeveloper

This comment has been minimized.

Show comment
Hide comment
@PDeveloper

PDeveloper Sep 18, 2016

Would there be a way to pass generic parameters on to a superclass?

(For example, would it be possible to extend that Tuple implementation?)

PDeveloper commented Sep 18, 2016

Would there be a way to pass generic parameters on to a superclass?

(For example, would it be possible to extend that Tuple implementation?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment