4 ms·

In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But e

In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them. Personally, I would like a language that pushes the programmer to write the types as part of a doc comment. Also think about returning lambda's. Should it look like this? fn foo(n i32) (i32 i32) {} Of course the IDE could help by showing the typographic arrows and other delineations, but as plaintext this is completely unreadable. > And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. You still have to think about stuff like currying. You either delimit the line, or you use significant white space.

gethly 10mo ago
> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}
- exceptione 10mo ago
  > fn foo(n i32, m i32) (i32, i32) {} But now consider returning a function with type¹ Foo<T<string, T2>> -> (bool -> IDictionary<string, T3> -> i32 -> T3) where T2 : T3 even if you leave out the latter type constraint, I think it is hard to avoid undecidable ambiguity. fn foo(n i32, m T2) (????) {} You quickly get ambiguity due to type parameters / generics, functions as arguments, and tuples if you don't syntactically separate them. Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical. ____ 1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.
  - gethly 10mo ago
    This is pointless discussion as Go has all of these things already implemented, so there is no point in going backwards.
    - exceptione 10mo ago
      The point is that a (new) syntax for any language needs to support any such implementation. The language implementation itself is not the point.
      - gethly 10mo ago
        Yes, and I am saying Go has already solved all of this and it makes little sense to deviate too much from its syntax.

gethly 10mo ago

> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}

exceptione 10mo ago
> fn foo(n i32, m i32) (i32, i32) {} But now consider returning a function with type¹ Foo<T<string, T2>> -> (bool -> IDictionary<string, T3> -> i32 -> T3) where T2 : T3 even if you leave out the latter type constraint, I think it is hard to avoid undecidable ambiguity. fn foo(n i32, m T2) (????) {} You quickly get ambiguity due to type parameters / generics, functions as arguments, and tuples if you don't syntactically separate them. Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical. ____ 1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.
- gethly 10mo ago
  This is pointless discussion as Go has all of these things already implemented, so there is no point in going backwards.
  - exceptione 10mo ago
    The point is that a (new) syntax for any language needs to support any such implementation. The language implementation itself is not the point.
    - gethly 10mo ago
      Yes, and I am saying Go has already solved all of this and it makes little sense to deviate too much from its syntax.