… and yet another language realizing that spending all its bracket budget on luxuries like array syntax backfires spectacularly.
The first rule of language design should be: “You got 4 pairs of brackets, (), {}, [] and <>. Use them wisely – once they are spent, they are pretty much gone forever.”
I’m all for generics, but the draft syntax coupled with Go’s ident Type syntax turns the code into a one-letter alphabet soup.
I like it. Why should type parameters use a totally different syntax to normal parameters? They’re not really that different. From the sounds of it, they’re going to be able to be dispatched at runtime sometimes anyway (a bit like how in Go objects will be heap allocated if you return pointers to them but stack-allocated otherwise, I guess).
Also I’m firmly of the opinion that lists are waaay more important to programming than types.
Why should type parameters use a totally different syntax to normal parameters?
Because they are completely different. If you want to turn Go into a dependently-typed language where the difference between types and terms ceased to exist, go ahead, but until then, types and terms are fundamentally different and should receive different syntax (especially because you can often infer the types), so it’s important to see which one of the parameter lists was left out.
My experience in Myrddin makes me think that you don’t actually need syntax to instantiate or specify generics. You just need a syntax for a ‘type parameter’, and let type inference unify for you. So, for example, a generic sort function in Myrddin looks like:
generic sort : (a : @t[:], cmp : (a : @t, b : @t -> std.order) -> void)
If Go were to adopt the same sort of syntax, where @a represents a type parameter, it might look like:
There’s some design needed around how constraints work – my first attempt in Myrddin directly attached them to the type, which made a few things syntactically impossible, specifically specifying auxiliary types, but I think that’s more surmountable than trying to make explicit instantiation pretty.
But the types for these function calls are just as strongly specified as any other function call: ‘a slice of @t’ isn’t fundamentally different from ‘a slice of int’, beyond code generation concerns.
… and yet another language realizing that spending all its bracket budget on luxuries like array syntax backfires spectacularly.
The first rule of language design should be: “You got 4 pairs of brackets,
(),{},[]and<>. Use them wisely – once they are spent, they are pretty much gone forever.”I’m all for generics, but the draft syntax coupled with Go’s
ident Typesyntax turns the code into a one-letter alphabet soup.Dare we resort to 「」 and 『』?
No. ;)
I like it. Why should type parameters use a totally different syntax to normal parameters? They’re not really that different. From the sounds of it, they’re going to be able to be dispatched at runtime sometimes anyway (a bit like how in Go objects will be heap allocated if you return pointers to them but stack-allocated otherwise, I guess).
Also I’m firmly of the opinion that lists are waaay more important to programming than types.
Because they are completely different. If you want to turn Go into a dependently-typed language where the difference between types and terms ceased to exist, go ahead, but until then, types and terms are fundamentally different and should receive different syntax (especially because you can often infer the types), so it’s important to see which one of the parameter lists was left out.
My experience in Myrddin makes me think that you don’t actually need syntax to instantiate or specify generics. You just need a syntax for a ‘type parameter’, and let type inference unify for you. So, for example, a generic sort function in Myrddin looks like:
If Go were to adopt the same sort of syntax, where
@arepresents a type parameter, it might look like:To invoke it, you just call it with the value:
There’s some design needed around how constraints work – my first attempt in Myrddin directly attached them to the type, which made a few things syntactically impossible, specifically specifying auxiliary types, but I think that’s more surmountable than trying to make explicit instantiation pretty.
Sometimes specifying the types at the instantiation site also serves readability purposes for the next developer coming along.
But the types for these function calls are just as strongly specified as any other function call: ‘a slice of @t’ isn’t fundamentally different from ‘a slice of int’, beyond code generation concerns.