You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we use [ ... ] as sugar for constructing and (in pattern matching) destructuring arrays, then unless we are using < ... > for something that appears very often in the code, I would lean towards the Java/C++ style, and it also has a longer history. But there might some conflict in the grammar that favors [ over <. Let's wait until we have the relevant grammar sorted out.
Other than those points, it might just be a subjective preference between Java and Scala style.
I stated that I think Haskell's syntax for that would be confusing to mainstream of programmers and maybe has similar issues as to why I argued for explicit parenthesis for function calls.
I think we can stick with the Java way
Also TypeScript uses the Java style and it is currently the most popular typed language targeting JavaScript.
@keean if ever you feel you would rather create a more Haskell-like syntax, then please don't be shy to tell me. I am hoping we can agree on the design. But if ever we can't, it is better to know than let it fester unstated. Ditto other readers in the potential community of the future of the language.
I know you've stated that you understand the importance of mainstream understanding on the syntax choices. You also seem to have maybe just a tad bit of saudade over not adopting more of Haskell's syntax. I noticed another comment from you that seemed to be exhibiting that?
I have written a lot in both styles, my only objection to < and > is that they are not really brackets and don't often get bracket matching in UI, and cause problems with cut and paste into HTML.
Ah yes, I had forgotten about those issues with angle brackets which are treated as 'less than' and 'greater than' in some contexts and yes the breakage of not escaping to HTML entity <.
But that HTML breakage applies to any code that has a 'less than' symbol as well. So I eliminate that as a valid differentiated concern.
And UIs not treating them as angle brackets when the file extension is a programming language, seems to be sort of worrying about the fringes of possible concerns? We'll probably have many issues on the fringes that we can't make perfect. I am thinking in terms of priorities.
The type-consructor is the bit like Add. It is clearly not a type, and only becomes a type when it's parameters are provided, so Add<Num, Num> is a type, and Add is a type constructor. I think it can be a type if you allow higher kinded types, and then it would be a type of kind * -> * -> *
For consistency, "Accepted" seems adequate to me. A proposal was put forward to choose a syntax analogous to a proposal being put forward to choose a better name than TraitScript. This proposal was decided and accepted.
Ah, you are referring to kinds? I was conflating with instance construction?
Edit: now I remember my confusion. The type parameter syntax might also apply to functions (if we don't choose my proposed less verbose type parameter syntax for functions), not just to kinds. So it seems the title of the Issue is incorrect. You could edit it, to make it more clear it about type parameter declaration, not something about kinds. Then again, if we adopt my less verbose type parameter syntax for functions, then your title ends up more or less correct.
For consistency, "Accepted" seems adequate to me. A proposal was put forward to choose a syntax analogous to a proposal being put forward to choose a better name than TraitScript. This proposal was decided and accepted.
On further thought, you could use "Decided" to differentiate reason for issue closure when the discussion was not a proposal that could be denied, but rather a discussion that could only be closed upon mutual community agreement. For example, when we eventually close the "Subtyping" Issue #8.
Activity
johnwcowan commentedon Sep 21, 2016
Assuming you use parentheses for something else, I would favor either Java or Scala style.
shelby3 commentedon Sep 21, 2016
If we use
[ ... ]as sugar for constructing and (in pattern matching) destructuring arrays, then unless we are using< ... >for something that appears very often in the code, I would lean towards the Java/C++ style, and it also has a longer history. But there might some conflict in the grammar that favors[over<. Let's wait until we have the relevant grammar sorted out.Other than those points, it might just be a subjective preference between Java and Scala style.
keean commentedon Sep 21, 2016
I think we can stick with the Java way, although the Haskell syntax is more concise.
shelby3 commentedon Sep 21, 2016
@keean wrote:
I stated that I think Haskell's syntax for that would be confusing to mainstream of programmers and maybe has similar issues as to why I argued for explicit parenthesis for function calls.
Also TypeScript uses the Java style and it is currently the most popular typed language targeting JavaScript.
shelby3 commentedon Sep 21, 2016
@keean if ever you feel you would rather create a more Haskell-like syntax, then please don't be shy to tell me. I am hoping we can agree on the design. But if ever we can't, it is better to know than let it fester unstated. Ditto other readers in the potential community of the future of the language.
I know you've stated that you understand the importance of mainstream understanding on the syntax choices. You also seem to have maybe just a tad bit of saudade over not adopting more of Haskell's syntax. I noticed another comment from you that seemed to be exhibiting that?
keean commentedon Sep 21, 2016
Okay I think that's agreed. If we wanted a recursive expression type it would be written something like:
We can also make the expression type parametric on the type of the expression like this:
I like Rust too :-) I think its going well, and I like the decisions we have made so far .
shelby3 commentedon Sep 21, 2016
@keean wrote:
Cross-referencing for readers, I had agreed on that syntax already.
shelby3 commentedon Sep 21, 2016
@keean wrote:
Ah yes, I had forgotten about those issues with angle brackets which are treated as 'less than' and 'greater than' in some contexts and yes the breakage of not escaping to HTML entity
<.But that HTML breakage applies to any code that has a 'less than' symbol as well. So I eliminate that as a valid differentiated concern.
And UIs not treating them as angle brackets when the file extension is a programming language, seems to be sort of worrying about the fringes of possible concerns? We'll probably have many issues on the fringes that we can't make perfect. I am thinking in terms of priorities.
shelby3 commentedon Sep 22, 2016
Why is the title of this issue, "Type Constructor Syntax"? What does that mean?
It seems the OP is about type parameter syntax.
keean commentedon Sep 22, 2016
The type-consructor is the bit like
Add. It is clearly not a type, and only becomes a type when it's parameters are provided, soAdd<Num, Num>is a type, andAddis a type constructor. I think it can be a type if you allow higher kinded types, and then it would be a type of kind * -> * -> *keean commentedon Sep 22, 2016
I think this is decided, will reopen if there are further issues.
shelby3 commentedon Sep 22, 2016
@keean please add a label for the resolution thus far. "Accepted" or "Decided"?
keean commentedon Sep 22, 2016
Yes, I am on my mobile at the moment and can't see how to do it. Will mark when I get home. Is accepted or decided better?
shelby3 commentedon Sep 22, 2016
For consistency, "Accepted" seems adequate to me. A proposal was put forward to choose a syntax analogous to a proposal being put forward to choose a better name than TraitScript. This proposal was decided and accepted.
shelby3 commentedon Sep 22, 2016
@keean wrote:
Ah, you are referring to kinds?
I was conflating with instance construction?Edit: now I remember my confusion. The type parameter syntax might also apply to functions (if we don't choose my proposed less verbose type parameter syntax for functions), not just to kinds. So it seems the title of the Issue is incorrect. You could edit it, to make it more clear it about type parameter declaration, not something about kinds. Then again, if we adopt my less verbose type parameter syntax for functions, then your title ends up more or less correct.
shelby3 commentedon Sep 22, 2016
@shelby3 wrote:
On further thought, you could use "Decided" to differentiate reason for issue closure when the discussion was not a proposal that could be denied, but rather a discussion that could only be closed upon mutual community agreement. For example, when we eventually close the "Subtyping" Issue #8.
shelby3 commentedon Sep 23, 2016
Reminding to attach a label "Decided" to this closed Issue.