3 ms·

This might be just my "ignorance", but am I the only one who thinks that "where" actually hurts readability? I mean, it's not a problem when it's just a few li

This might be just my "ignorance", but am I the only one who thinks that "where" actually hurts readability? I mean, it's not a problem when it's just a few lines, but when you have a lot of code, and you have to scroll further down to see, what do parts of it mean, and then jump back... It just seems backwards to me. And yes, I know there is "let ... in", and if I ever start writing in functional languages I will use it, but when reading functional programs, I see way more "where" than "let ... in".

lmm 8y ago
> I mean, it's not a problem when it's just a few lines, but when you have a lot of code, and you have to scroll further down to see, what do parts of it mean, and then jump back... It just seems backwards to me. It's the same thing you'd have to do when the code was factored out into separate functions, which is generally (though not universally) seen as good practice in those circumstances in languages that don't have `where`. You want to be able to see a high level overview of what the function is doing and then drill down into the details, rather than be overwhelmed by all the details right from the start.
- mannykannot 8y ago
  The fracturing of the narrative is an argument against the idea sometimes espoused (most often implicitly, but sometimes explicitly) that, as functions are useful, then the maximal factoring into functions must be optimal. Nevertheless, functions (with names) differ from 'where' clauses in precisely that: they have a name, and ideally, a function's name might tell you everything you need to know about it, though in practice, it is hard to fully and unambiguously state a function's contract in its name, especially if it has side effects. I doubt it is possible for a language to be such that everything that matters in understanding a given part is always lexically local. I think we need to look to tools, rather than syntax, to help with that.
  - lmm 8y ago
    > Nevertheless, functions (with names) differ from 'where' clauses in precisely that: they have a name, and ideally, a function's name might tell you everything you need to know about it, though in practice, it is hard to fully and unambiguously state a function's contract in its name, especially if it has side effects. Huh? What's the difference in "naminess" between: bar x = ... foo x y = bar (x + y) and foo x y = bar (x + y) where bar x = ... ?
    - mannykannot 8y ago
      I see that you are right; 'where' clauses don't restrict the ways an author can introduce what Landin calls user-coined names.

lmm 8y ago

> I mean, it's not a problem when it's just a few lines, but when you have a lot of code, and you have to scroll further down to see, what do parts of it mean, and then jump back... It just seems backwards to me. It's the same thing you'd have to do when the code was factored out into separate functions, which is generally (though not universally) seen as good practice in those circumstances in languages that don't have `where`. You want to be able to see a high level overview of what the function is doing and then drill down into the details, rather than be overwhelmed by all the details right from the start.

mannykannot 8y ago
The fracturing of the narrative is an argument against the idea sometimes espoused (most often implicitly, but sometimes explicitly) that, as functions are useful, then the maximal factoring into functions must be optimal. Nevertheless, functions (with names) differ from 'where' clauses in precisely that: they have a name, and ideally, a function's name might tell you everything you need to know about it, though in practice, it is hard to fully and unambiguously state a function's contract in its name, especially if it has side effects. I doubt it is possible for a language to be such that everything that matters in understanding a given part is always lexically local. I think we need to look to tools, rather than syntax, to help with that.
- lmm 8y ago
  > Nevertheless, functions (with names) differ from 'where' clauses in precisely that: they have a name, and ideally, a function's name might tell you everything you need to know about it, though in practice, it is hard to fully and unambiguously state a function's contract in its name, especially if it has side effects. Huh? What's the difference in "naminess" between: bar x = ... foo x y = bar (x + y) and foo x y = bar (x + y) where bar x = ... ?
  - mannykannot 8y ago
    I see that you are right; 'where' clauses don't restrict the ways an author can introduce what Landin calls user-coined names.