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

stack based tuples #38

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
8 participants
@jdonaldson
Copy link
Member

jdonaldson commented Nov 17, 2017

Here's a proposal for stack-based tuples.

var (a,b,c) = (1,2,3);

They could be used for key/value iteration:

for ((k,v) in map){
  trace('$k: $v');
}

Or, as async continuation expressions:

suspend function some_async_function(continuation : Bool->Int->Void){
 [...]
};
var (success : Bool ,value : Int) = some_async_function();

(check @nadako's proposal here : https://github.com/nadako/haxe-coroutines)

Or as multireturns (which have native support on some platforms):

 var (x,y,z) = tupleGenerator();

It should be possible to define a special kind of typedef for them, similar to a complex type:

stacktype StackType = (foo: Int, bar : Float, baz : String);

You could reference parts of the stack by name or index this way.

Rendered version

@skial skial referenced this pull request Nov 22, 2017

Closed

Haxe Roundup 409 #452

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Dec 7, 2017

I am not sure about it.
Having used tuples in OCaml for a long time, I don't think they fit well in Haxe design.

You don't really want to have 4+ elements tuples because they are messy and then would be a lot better with proper field names ( = haxe structures ). 3 is a bit in the middle. 2 might be useful, 1 is... well....

So if the question is should we have tuples for the possibility of returning two values in a function, my conclusion would be no.

@jdonaldson

This comment has been minimized.

Copy link
Member

jdonaldson commented Dec 7, 2017

I agree, if this proposal is just about handling 2-value multireturns, it's not worth it.

Let's see if @nadako thinks this would work for async scenarios. I think stack based tuples may not get used much for Haxe code that is written from scratch, but if you're writing a lot of async wrappers for pre-existing callback functions, or if you're writing externs for messy multireturns I think it's a good idea.

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Dec 7, 2017

stack based multi return is a bad optimization for us I think, because we have very few platforms that can implement it. So this will lead to some users using them massively and then later noticing they are causing a lot of performance problems on other platforms.

@jdonaldson

This comment has been minimized.

Copy link
Member

jdonaldson commented Dec 7, 2017

I think there's ways to reduce the overhead on platforms that can't implement natively, but I defer to your experience on that point.

Is the mechanism for async handling clear? I haven't had any feedback on that. The support there will be the same for all platforms.

If necessary I can split the proposal here and/or refactor.

@nadako

This comment has been minimized.

Copy link
Member

nadako commented Dec 7, 2017

I'm not sure about async stuff atm, but I think Haxe would benefit from tuples a lot. We cannot and we should not make any promises about whether they are stack-allocated or not, but if we say they are non-nullable and read-only, they can be implemented in a native and/or optimized way on many targets, which is not the case with anonymous structures/classes.

As for the usefullness, I think they should have "use-site only" field names, similar to new function type with named argument, so, e.g.:

// these two types unify (same arity and types)
typedef T = (a:Int, b:String);
typedef T2 = (c:Int, d:String);

var t1:T = (10, "hi")
trace(t1.a, t1.b);

var t2:T2 = t1;
trace(t2.c, t2.d);

Unpacking into local vars is a topic that is not strictly related to tuples, and my current opinion is that we should go for a convention-based destructuring, similar to one implemented in Kotlin, basically:

class Pair<T1,T2> {
  public var _1:T1;
  public var _2:T2;
}

// and then
var (a, b) = somePair;

// translated into:
var a = somePair._1;
var b = somePair._2;

This convention would then be simply used by tuples, so any tuple type would have _1/_2/etc. fields.

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Dec 8, 2017

I have designed Haxe to be as simple as possible. Simple to read, simple to learn. This means that only the feature that brings something expressive enough to justify adding them to the syntax/language should be considered for addition. Given the amount of overlap between Tuples and anonymous structures, and the ability to generate these tuples with macro, I'm not in favor of adding them to the official language syntax.

@bendmorris

This comment has been minimized.

Copy link

bendmorris commented Apr 2, 2018

To clarify the status of this proposal - is this a veto by @ncannasse, or a no vote? If the latter, it sounds like the vote is currently 1 in favor, 1 opposed?

@Justinfront

This comment has been minimized.

Copy link

Justinfront commented Apr 2, 2018

Is there a repo I can try them out where the c++ and js implementations provide both speed and expressive advantages, along with predictable special cases, I think that should be a minimum before you start counting votes. If users like me feel they offer an advantage then your halfway there, I already know Tuples so would be keen to see them as part of the language. Time to demo the implementation, if the theory was enough Nicolas would have agreed? So initially myself - I only care about js and c++... very pragmatic, flash would be nice but like many of the other targets not the main USP.
benmorris no disrespect but I have only seen your commits for a short time - so if your not happy with Nicolas vote then rather than talk about votes I think you need to get an implement together so we can try it out, seems it's at that stage?

@bendmorris

This comment has been minimized.

Copy link

bendmorris commented Apr 2, 2018

so if your not happy with Nicolas vote...

I'm simply asking for an update on the status of this proposal - please don't read any more intent into that.

Edit: and I'm not volunteering to implement this either :) doesn't seem prudent to work on features that don't have a good chance of being accepted...

@Justinfront

This comment has been minimized.

Copy link

Justinfront commented Apr 2, 2018

Well I am happy to try out a branch if you have one.

@jdonaldson

This comment has been minimized.

Copy link
Member

jdonaldson commented Apr 2, 2018

FWIW this feature would require a lot of buy-in from the rest of the compiler team. The lack of a stack-indexed datastructure is a minor nuisance now, but it seems like a really good idea for certain async features.

Also as a side note, I realize not all platforms would support these datastructures in all cases. They could be emulated with a simple array in most cases I think.

@ncannasse

This comment has been minimized.

Copy link
Member

ncannasse commented Apr 3, 2018

We might reconsider this while working on Haxe-in-Haxe (OCaml backend etc) but atm I still don't think it would make a good addition for Haxe "core" language. We will eventually experiment it for the OCaml backend if necessary and see how it plays.

@Simn

This comment has been minimized.

Copy link
Member

Simn commented Apr 17, 2018

I want destructuring, but I don't think I want tuples. I also don't want to overload the ( ) syntax any further.

@jdonaldson

This comment has been minimized.

Copy link
Member

jdonaldson commented Apr 18, 2018

I propose we add new bracket symbols in that case:

var 🍺a,b,c 🍺 = 🍺1,2,3 🍺

@markknol

This comment has been minimized.

Copy link
Member

markknol commented Apr 18, 2018

Fwiw, in typescript they use { } for destructuring

 let {x,y} = point;
@RealyUniqueName

This comment has been minimized.

Copy link
Member

RealyUniqueName commented Sep 21, 2018

We discussed it and decided to close this proposal for the reasons mentioned above.
However, we should look into providing a way to access platform-specific tuples.

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