Type Constructor Syntax

[keean]

There are four obvious options:

Java style: Add<a, a> Scala style: Add[a, a] Haskell style: Add a a Prolog style: Add(a, a)

Which option should we go for?

[johnwcowan]

Assuming you use parentheses for something else, I would favor either Java or Scala style.

[shelby3]

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]

I think we can stick with the Java way, although the Haskell syntax is more concise.

[shelby3]

@keean wrote:

although the Haskell syntax is more concise.

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.

[shelby3]

@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]

Okay I think that's agreed. If we wanted a recursive expression type it would be written something like:

type Exp = (Num | Add<a, a> | Mul<a, a>) as a

We can also make the expression type parametric on the type of the expression like this:

type Exp<a> = (Lit<a> | Add<b, b> | Mul<b, b>) as b

if ever you feel you would rather create a more Haskell-like syntax, then please don't be shy to tell me

I like Rust too :-) I think its going well, and I like the decisions we have made so far .

[shelby3]

@keean wrote:

If we wanted a recursive expression type it would be written something like:

type Exp = (Num | Add<a, a> | Mul<a, a>) as a

Cross-referencing for readers, I had agreed on that syntax already.

[shelby3]

@keean wrote:

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.

[shelby3]

Why is the title of this issue, "Type Constructor Syntax"? What does that mean?

It seems the OP is about type parameter syntax.

[keean]

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 * -> * -> *

[keean]

I think this is decided, will reopen if there are further issues.

[shelby3]

@keean please add a label for the resolution thus far. "Accepted" or "Decided"?

[keean]

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]

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]

@keean wrote:

The type-consructor is the bit like Add.

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]

@shelby3 wrote:

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.

[shelby3]

Reminding to attach a label "Decided" to this closed Issue.