What about implementing something like map for lists? You know literally nothing about the values and the function except for their types.
map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (a:as) = f a : map f as
Personally I don't see any reason to use longer names than f, a, and as because you can't add any additional information.You might say "well I don't write code like that", and I don't have any answer for you. But I find I write a fair amount of generic code.
> you can't add any additional information
Well you could...
map transforming_function (element:rest_of_list) = transforming_function element : map transforming_function rest_of_list
...but the cost in terms of loss of brevity would far outweigh a benefit that would only accrue to complete beginners, who would be better served by comments and test cases.
Re:Why we need a book about naming
by marcosdumay on Thursday February 13, 2020 @05:42AM
(#22316703)
> if it's meaningless, why are you saving it?
Because you are writing abstract code.
Odds are that a lot of your code is better done abstract, and only fully specified in a short context.
Re:Why we need a book about naming
by Firadeoclus on Thursday February 13, 2020 @06:42AM
(#22316944)
A variable can be a substitute for a longer expression for which a name/description is unnecessary because the expression itself is self-explanatory. The substitution with a (essentially meaningless) short name just makes repeated use of that expression more readable. Using a long, descriptive name would defeat the point.
Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.