3 ms·

In the case of folding at least, I think there is a function, a value, and a collection -- personally I'd call them something like "func", "val", and "list" rat

by Shish2k 13y ago

In the case of folding at least, I think there is a function, a value, and a collection -- personally I'd call them something like "func", "val", and "list" rather than "f", "z" and "t" -- still very generic, but not completely generic (though perhaps in haskell, functions, values, and collections are interchangeable? I can't imagine how that would work though, if you pass a collection in as the first parameter to foldr...)

ufo 13y ago
There are some single letter names that are kind of standardized and don't get better with longer names, kind of like i, j and k. For example, f and g will usually stand for functions, a and b in a type signature will usually stand for some opaque "value" type and x and y will be used to refer to variables of these types. xs is a list of x and m usually stands for monad something (`m a` is a monadic type, mapM is the version of map for monads, etc). Going back to the foldr example, its actually not that bad. The f is already clearly a function (from name and type) and the full type of foldr is [1] foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b so you actually are told what the `t` is (its a Foldable). I could see them using `zero` instead of `z` but its a 3 line function that does what you would expect from the name so its not that big of a deal. TBH, the bigger problem is having a folding abstraction in the first place. If no one ever teaches you about it, its hard to get the point just by reading the source code but once you know about what a fold is you don't need to actually look inside the implementation that much. That said, there are cases where I do think that longer variable names would help a bit. For example, you might come across types with 5 or 6 type parameters like [2] data Pipe l i o u m r and I think in these cases the more descriptive names like in [3] newtype Form m input error view proof a might help a bit. Its still a tradeoff though - types get harder to read if they get too long and types show up all over the place so they tend to need shorter names than variables. [1] http://www.haskell.org/hoogle/?hoogle=foldr http://www.haskell.org/hoogle/?hoogle=foldr [2] http://hackage.haskell.org/package/conduit-0.5.0/docs/Data-Conduit.html#g:3 http://hackage.haskell.org/package/conduit-0.5.0/docs/Data-C... [3] http://www.happstack.com/docs/reform-0.1.1/doc/html/reform/Text-Reform-Core.html#g:3 http://www.happstack.com/docs/reform-0.1.1/doc/html/reform/T...

by Shish2k 13y ago

ufo 13y ago

There are some single letter names that are kind of standardized and don't get better with longer names, kind of like i, j and k. For example, f and g will usually stand for functions, a and b in a type signature will usually stand for some opaque "value" type and x and y will be used to refer to variables of these types. xs is a list of x and m usually stands for monad something (`m a` is a monadic type, mapM is the version of map for monads, etc). Going back to the foldr example, its actually not that bad. The f is already clearly a function (from name and type) and the full type of foldr is [1] foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b so you actually are told what the `t` is (its a Foldable). I could see them using `zero` instead of `z` but its a 3 line function that does what you would expect from the name so its not that big of a deal. TBH, the bigger problem is having a folding abstraction in the first place. If no one ever teaches you about it, its hard to get the point just by reading the source code but once you know about what a fold is you don't need to actually look inside the implementation that much. That said, there are cases where I do think that longer variable names would help a bit. For example, you might come across types with 5 or 6 type parameters like [2] data Pipe l i o u m r and I think in these cases the more descriptive names like in [3] newtype Form m input error view proof a might help a bit. Its still a tradeoff though - types get harder to read if they get too long and types show up all over the place so they tend to need shorter names than variables. [1] http://www.haskell.org/hoogle/?hoogle=foldr http://www.haskell.org/hoogle/?hoogle=foldr [2] http://hackage.haskell.org/package/conduit-0.5.0/docs/Data-Conduit.html#g:3 http://hackage.haskell.org/package/conduit-0.5.0/docs/Data-C... [3] http://www.happstack.com/docs/reform-0.1.1/doc/html/reform/Text-Reform-Core.html#g:3 http://www.happstack.com/docs/reform-0.1.1/doc/html/reform/T...