I would treat multiple _ in a type the same way as multiple _ in a
pattern.
They can all be different. It might be useful to have multiple
"variables",
say _a, in a type too, all standing for the same type. But I'd
settle for _ for now. :)
And yes, contexts even more so!
Contexts are really annoying in Haskell, they can become quite large,
but they cannot be named.
Speaking of wishlist, I'd also like to see context synonyms, e.g.,
context C a = (Ord a, Num a)
The current situation is quite bad, there's no way to abstract
contexts. Well,
you can leave out type signatures altogether (but only a few people
advocate this (hello John!)).
-- Lennart
On Dec 7, 2006, at 07:20 , Johannes Waldmann wrote:
Lennart Augustsson wrote:
Btw, this reminds me again that I'd like to be able to use _ in type
signatures.
With the meaning of _ being, "there's a type here, but I can't be
bothered to write it out in full."
you're not alone ...
what is the meaning of two _ in one expression?
do they necessarily denote the same type? (probably not.)
what about type classes? for example,
given sort :: Ord a => [a] -> [a],
would it be ok to write sort :: [ _ ] -> [ _ ]
(that is, omitting the context)
or is it more like sort :: _ => [ _ ] -> [ _ ]
BTW, this "_ for context" would be useful on its own!
I have several cases where the conxtext for the type decl
is longer than the implementation of the function. Well, nearly.
With previous ghc versions, I could get this effect
by omitting the type decl but writing
f ( x :: type1) ( y :: type2 ) = ...
I sometimes wish haddock would understand that. (*)
Because - if you write a haddoc comment for a type declaration,
then you don't have names for the function's arguments.
This leads to either awkward prose (random example, from Data.Maybe:)
The maybe function takes a default value, a function, and a Maybe
value. If the Maybe value is Nothing ...
(this only works here because all the argument types are different in
this case) or you have to re-invent names, random example:
approxRational :: RealFrac a => a -> a -> Rational
approxRational, applied to two real fractional numbers x and epsilon,
which looks like duplication of work.
(*) of course the full form would include the return type
fun (x :: type1 ) (y :: type2) :: type3 = ...
I expect strong opposition from those who write
functions with pattern matching (then there is a group of declarations
and which one should be type-annotated?) but that's bad style anyway
since constructors should not be exported :-)
Best regards,
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
