Skip to content
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

what should we use { } for? #8470

Open
JeffBezanson opened this issue Sep 25, 2014 · 62 comments
Open

what should we use { } for? #8470

JeffBezanson opened this issue Sep 25, 2014 · 62 comments
Labels
breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@JeffBezanson
Copy link
Member

@jakebolewski had this very good idea today.

Our tuple types are currently quite ugly since they are not distinguished from tuple values. This causes various problems in the system, such as whether to treat () as a type. We also need to specialize tuple representations (e.g. storing (Float64,Float64) as compactly as a Complex128), which means tuple types will need to contain extra layout information that tuple values do not have. This would also eliminate the need for a fancy predicate to test whether some tuple is a type.

It would be quite easy to use Union{...} for union types, and then all types would be constructed with curly braces 👍.

This change also makes it easy to use (x, y...) for splatting in tuple construction (#4869), and {Int...} for varargs types.

All current uses of { } can be replaced with Any[ ] or (Any=>Any)[ ], so that syntax is effectively up for grabs. The wastefulness of the current { } has been discussed elsewhere. I admit this proposal feels slightly wasteful as well, but it could be worth it for solving various problems in the type system and making type syntax highly consistent. On the whole, I am in favor of this idea.

@JeffBezanson JeffBezanson added needs decision A decision on this change is needed breaking This change will break code labels Sep 25, 2014
@quinnj
Copy link
Member

quinnj commented Sep 25, 2014

I think this would be a great change. More consistency with { } and types. I think changing [] to default to Any[] should go along with this too.

@garborg
Copy link
Contributor

garborg commented Sep 25, 2014

👍

@IainNZ
Copy link
Member

IainNZ commented Sep 25, 2014

I like it a lot

{Vector{Int}, Int}
Union{Vector{Int}, Int}
foo{T<:Union{Int,Float64}(x::Vector{T}, y::{Int,Int}) = print(T," ",y)

All seem pretty human-parseable. The (,) thing for tuple types has always been a big confusing for me.

@jiahao
Copy link
Member

jiahao commented Sep 25, 2014

Two other things from today's discussion:

  1. Currently typeof has two fixed points. typeof(X) == X has the solution X = DataType, but also X = ().
  2. If tuples are product types, then (as discussed in Extraneous ambiguity warning: (MyType{T},T) vs (T,MyType{T}) #1631) finite-length tuples of the form (T1, ..., T2, None, T3, ..., T4) should be reducible to just None, but they aren't right now. Currently there is a single tuple constructor for value tuples and type tuples, which makes it difficult to implement such a reduction rule. With this proposed change we could do these kinds of checks and simplifications when constructing tuple types.

@johnmyleswhite
Copy link
Member

I like this.

If we make this change and also change [] to not do automatic splatting, will we have no syntax for arrays with automatic splatting? I'd like that, so I'm just wondering.

@garborg
Copy link
Contributor

garborg commented Sep 25, 2014

👍 to that, too.

@simonster
Copy link
Member

@jiahao I think typeof currently has an infinite number of fixed points, since typeof(((),)) == ((),), typeof((((),),)) == (((),),), etc.

@toivoh
Copy link
Contributor

toivoh commented Sep 25, 2014

  • a lot for distinguishing tuples from tuple types.

However, I think there's many legitimate uses contending for the braces. An alternative would be to use Tuple{Int, String} etc.

+1 for Union{} as well, that has always felt inconsistent (though maybe it isn't).

@kmsquire
Copy link
Member

I think I finally stopped typing Union{Int, Uint} about a week ago....

@catawbasam
Copy link
Contributor

+1 for Tuple{Int, String} and Union{} for being explicit and obviously describing types.

@JeffBezanson
Copy link
Member Author

I think we could implement Tuple{Int,String} first, and later remove the Tuple part if it is too annoying.

@StefanKarpinski
Copy link
Member

I think I finally stopped typing Union{Int, Uint} about a week ago....

LOL.

@jiahao, @simonster – there is a free monoid of fixed points with () and DataType as generators. With this change, there would only be DataType, which seems a little more sane. Not that fixed points of the typeof operator are particularly problematic, but it does seem simpler.

I'd be ok with this change, although it does really feel a bit wasteful. The idea of making { } entirely "typey" is appealing. I kind of wish this change had just a little more umph to push it over the edge...

@JeffBezanson
Copy link
Member Author

I know what you mean. We do need at least Tuple{ }; otherwise tuples will never quite be sane.

@jiahao
Copy link
Member

jiahao commented Apr 17, 2015

Closed by #10380

@jiahao jiahao closed this as completed Apr 17, 2015
@jakebolewski jakebolewski reopened this Apr 17, 2015
@jakebolewski
Copy link
Member

I still hold out hope that this will be the final syntax.

@JeffBezanson
Copy link
Member Author

I agree. I'm 100% in favor of this. I'm tired of typing "Tuple", and hopefully soon everybody else will be too.

@tkelman
Copy link
Contributor

tkelman commented Apr 17, 2015

Based on the deprecation policy, we should really leave {} as its former deprecated meaning for at least one release. So I don't think this syntax change needs to be resolved until early in 0.5-dev.

@JeffBezanson
Copy link
Member Author

In that case, we might want to continue allowing tuples of types in various places. Writing code_typed(foo, Tuple{ ... }) gets old.

@StefanKarpinski
Copy link
Member

Can't you do that just by writing methods that convert tuples to tuple types?

@JeffBezanson JeffBezanson modified the milestones: 1.0, 0.6.0 Jan 4, 2017
@JeffBezanson JeffBezanson changed the title use { } for tuple types? what should we use { } for? Jul 13, 2017
@JeffBezanson
Copy link
Member Author

For 1.0, we should change the parsing to not use the expression head cell1d (lol), then the rest of this will be non-breaking and this can be moved out of 1.0.

@JeffBezanson
Copy link
Member Author

Parser change done.

@JeffBezanson JeffBezanson modified the milestones: 1.x, 1.0 Jul 28, 2017
@mauro3
Copy link
Contributor

mauro3 commented Aug 15, 2017

I don't know whether it is still on the table to use {} for Tuple{}. But here one argument against it: in where constructs, which already use bare {} it would be confusing to have another set of bare {}.

Tuple{X,Y} where X<:Tuple{T,Y} where {Y,T}
# would become
{X,Y} where X<:{T,Y} where {Y,T}

@oscardssmith
Copy link
Member

I would like to +1 {} for sets and dicts. Besides compatibility with python, it goes two very common structures one very convenient syntax

@timholy
Copy link
Member

timholy commented Dec 29, 2017

Another option is a lisp-like representation of tuples (as a linked list). There's one coming (called TupleLL) as part of #23692.

@davidanthoff
Copy link
Contributor

Another option is a lisp-like representation of tuples (as a linked list)

Do we expect that to be widely used by a large fraction of the user base? In my mind that should be an important factor in the decision what to do with {},

@timholy
Copy link
Member

timholy commented Dec 30, 2017

Unlikely but possible. Currently "lispy-tuple" programming with ordinary tuples is O(N^2) on the compiler, but if we introduced an efficient conversion between ordinary tuples and linked-list tuples then we could make it O(N). If that happened, then they might end up being used relatively widely.

@sighoya
Copy link

sighoya commented Dec 30, 2017

Another problem with {} as Tuple type is the inclusion of values inside the curly brackets:

Array{Int64,2}

which is maybe a problem for future syntax:

struct A{S,T=S*3} ... end

@StefanKarpinski
Copy link
Member

I really think we should let 1.0 come out, settle in and see where there's real syntactic pain. Having some good syntax available to address pain points that emerge is a good thing. It's hard to predict what the real issues will be and which apparent problems evaporate as people work around them.

@timholy
Copy link
Member

timholy commented Dec 31, 2017

Agreed, I was definitely not suggesting this for now (that would be crazy), simply planting the seed for some future discussion. Months or years later It's easy to forget these thoughts.

@ajkeller34
Copy link
Contributor

ajkeller34 commented Jan 18, 2018

I really think we should let 1.0 come out, settle in and see where there's real syntactic pain.

There's some syntactic pain in conflating indexing by integer offsets and getting keys when both could be considered useful operations on a data structure, for example in AxisArrays but not exclusively there. Curly braces could lower to get (which could be renamed getkey for clarity, because what am I getting exactly?). See #25057 (comment) On second thought, I don't think that's the available curly brace syntax under consideration, but the syntactic pain remains...

@StefanKarpinski
Copy link
Member

The is now getproperty which addresses some of that. The only syntax that’s available here is braces not used for indexing.

@JeffBezanson JeffBezanson removed their assignment Apr 17, 2018
@ViralBShah ViralBShah modified the milestones: 1.x, 2.0 Mar 12, 2022
@RaulDurand
Copy link

Sorry for awakening this old topic. I was introducing the language to a C++ programmer and he was not very attracted to the use of begin-end delimiters. I was wondering if, at some point, the use of {} as the block delimiter had been discussed.

@StefanKarpinski
Copy link
Member

Lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests