4 ms·
Looks interesting, will definitely dig into. Right off the bat though, I see 3 different syntaxes for typing? > case Rectangle(Int32, Int32) > def origin(): (
by rco8786 4y ago
Looks interesting, will definitely dig into. Right off the bat though, I see 3 different syntaxes for typing?
> case Rectangle(Int32, Int32)
> def origin(): (Int32, Int32) =
> def twoByFour(): {w :: Int32, h :: Int32} =
case Rectangle: (Int32, Int32)
def origin(): (Int32, Int32)
def twoByFour(): (w: Int32, h: Int32)
?
- djur 4y agoThe first one is part of the syntax for defining a sum type, the second is a function returning a tuple, and the third is a function returning a record.
- rco8786 4y agoI get that I just don’t understand why they chose to make them all so different.
- deleted 4y ago[deleted]
- michaelcampbell 4y agoAre you asking why different things look different?
- rco8786 4y agoCome on. I’m asking why they chose such different syntaxes for type annotations when it would not have been terribly challenging to keep them consistent. I even gave examples. Parens vs curly braces. Single : vs double ::.
- djur 4y agoThe first example isn't a type annotation, it's a type definition. The curly braces are consistent with the literal syntax for records. I agree that the use of double colons in record types seems inconsistent. I assume it resolves some ambiguity.
- jorkadeen 4y agoYou are spot on. Its because we reserve `:` for type and kind ascriptions. For example, `42 : Int` or `true : Bool`. But we also have `Bool : Type`, i.e. `true : Bool : Type`. While kinds are not that common in every day code, we aim for consistency with ascriptions rather than with records. Hence we had to use a different symbol in record types.
- michaelcampbell 4y ago> I even gave examples. Yes, of different things that look different, then asked why.