4 ms·

Here are a few possible complaints: 1. It's way longer 2. Naming the monad "Action" may be misleading depending on choice of Monad 3. It's

by tel 11y ago

Here are a few possible complaints: 1. It's way longer 2. Naming the monad "Action" may be misleading depending on choice of Monad 3. It's tied syntactically to the syntax of the implementation 4. The <>s are superfluous 5. The argument names are superfluous (to the type) 6. The explicit type quantification is superfluous and verbose

masklinn 11y ago
> It's way longer Because of the much longer type names which have nothing to do with the syntax. By just replacing all the type names by the original single-letter names, it goes from 107 to 72 characters, that's almost 50% increase in size (49%) due to longer type names, which incidentally is nearly double the increase in size between the Haskell signature and this new signature (57 -> 72, or 26%) def M2<A1, A2, R, M: Monad>(f: (A1, A2) => R, a: M<A1>, b: M<A2>): M<R> Funnily enough, this expansion is relatively worse if applied to the Haskell signature (57 -> 87, +53%) > Naming the monad "Action" may be misleading depending on choice of Monad Nothing to do with syntax either. > It's tied syntactically to the syntax of the implementation ? > The argument names are superfluous (to the type) That can trivially be removed when just displaying the function's type (`f`'s arguments are not explicitly named after all), likewise for the unnecessary type quantifications, so a type-view of this function (rather than a source view) could be: def M2<M: Monad>((A1, A2) => R, M<A1>, M<A2>) => M<R> Oh look, it's now shorter than the original signature (though somewhat more noisy, I'll give you that)
- evincarofautumn 11y ago
  Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. And if you want to be true to the semantics, you might write something like this: def M2 ((A1 => A2 => R) => M<A1> => M<A2> => M<R>) where Monad<M> At which point the Haskell syntax is shorter. However, concision is not the goal—it’s merely a proxy for clarity.
  - masklinn 11y ago
    > Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. But the conventions are whatever we want for a resyntacting no? > However, concision is not the goal I was answering a comment putting concision forward as reasons to dislike the alternate syntax.
- tel 11y ago
  Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature. Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't. And by the definition being tied to the implementation I mean that it's not possible to write, e.g. foo :: Type1 bar :: Type2 foo = ... bar = ...
  - masklinn 11y ago
    > Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature. pekk asked what was wrong with the syntax. > Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't. I didn't change the syntax in any way. > And by the definition being tied to the implementation I mean that it's not possible to write, e.g. 'k. Is that actually used? Global type inference I could see, but that seems odder.
    - tel 11y ago
      Fair enough. I conflated syntax with convention. It is used quite frequently, actually, e.g. in describing type classes.

by tel 11y ago

masklinn 11y ago

> It's way longer Because of the much longer type names which have nothing to do with the syntax. By just replacing all the type names by the original single-letter names, it goes from 107 to 72 characters, that's almost 50% increase in size (49%) due to longer type names, which incidentally is nearly double the increase in size between the Haskell signature and this new signature (57 -> 72, or 26%) def M2<A1, A2, R, M: Monad>(f: (A1, A2) => R, a: M<A1>, b: M<A2>): M<R> Funnily enough, this expansion is relatively worse if applied to the Haskell signature (57 -> 87, +53%) > Naming the monad "Action" may be misleading depending on choice of Monad Nothing to do with syntax either. > It's tied syntactically to the syntax of the implementation ? > The argument names are superfluous (to the type) That can trivially be removed when just displaying the function's type (`f`'s arguments are not explicitly named after all), likewise for the unnecessary type quantifications, so a type-view of this function (rather than a source view) could be: def M2<M: Monad>((A1, A2) => R, M<A1>, M<A2>) => M<R> Oh look, it's now shorter than the original signature (though somewhat more noisy, I'll give you that)

evincarofautumn 11y ago
Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. And if you want to be true to the semantics, you might write something like this: def M2 ((A1 => A2 => R) => M<A1> => M<A2> => M<R>) where Monad<M> At which point the Haskell syntax is shorter. However, concision is not the goal—it’s merely a proxy for clarity.
- masklinn 11y ago
  > Conventions are as important as syntax when it comes to legibility of a language, so phrasing “M” as “Action” seemed a fair comparison. But the conventions are whatever we want for a resyntacting no? > However, concision is not the goal I was answering a comment putting concision forward as reasons to dislike the alternate syntax.
tel 11y ago
Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature. Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't. And by the definition being tied to the implementation I mean that it's not possible to write, e.g. foo :: Type1 bar :: Type2 foo = ... bar = ...
- masklinn 11y ago
  > Hey, I didn't say one was worse or better but merely suggested some arguments as to why one might dislike that signature. pekk asked what was wrong with the syntax. > Clearly, as you demonstrate, the syntax described can be shortened—but it wasn't. I didn't change the syntax in any way. > And by the definition being tied to the implementation I mean that it's not possible to write, e.g. 'k. Is that actually used? Global type inference I could see, but that seems odder.
  - tel 11y ago
    Fair enough. I conflated syntax with convention. It is used quite frequently, actually, e.g. in describing type classes.