Dear Haskellers, Could you, please, tell me what is the recent state of the Haskell Standard development? I have a wish for the Standard Library: FiniteMap, Set (of GHC library). And I have a question on the function name overloading, and on the record field name overloading. A language should support a natural naming of objects. For example: data Operator = Operator{opName :: String, opWeight :: Int, opSortage :: ([String],[String],String), opOrd :: Int, opPrecedences :: (Int, Int) } is not good -- due to `op' prefix. And many other data also have name, weight, ord, and so on. So, one may try to introduce class WithName a where name :: a -> String set_name :: a -> String -> a class WithWeight a where weight :: a -> Int set_weight :: a -> Int -> a ... trivialOperator = Operator{ ... some trivial setting ...} , to change the names like opName to opName__, opWeight__, ... to show that the latter are local and not for usage, to introduce instance WithName Operator where name = opName__ ... , and then, use all this, for example, as follows: let nm = name opr opr' = set_name "foo" $ set_weight 1 $ set_ord 2 $ opr in ... This leads to following complications. * Class declarations add. * The Standard does not allow to define the instances like type BN = (String, Bool) instance WithName BN where name = fst * There are many operations that should be synonymic but have different kind. For example, weight :: a -> Int weight :: Table -> a -> Int This leads to adventures with multiple parameter classes, and so on. Similar difficulties arise with the function names. Is Haskell all right at this point? Reply, please, to mechvel@botik.ru Thank you in advance for the explanation. ----------------- Serge Mechveliani mechvel@botik.ru
Serge, I support your point of view
A language should support a natural naming of objects. data Operator = Operator{opName :: String, ... } is not good -- due to `op' prefix.
You can use qualified names, this solves the problem (to a certain extent) module Operator where data Operator = Operator { name :: String, ... } module Foo where import qualified Operator ; foo = Operator.name bar It is a bit tedious to construct records that way, as in bar = Operator.Operator { Operator.name = "bar", ... } there are (at least) two better (?) solutions: a) something that works "only" for records, for instance one would like to write the above as bar = Operator.Operator { name = "bar", ... } (I think this has been suggested here before) Actually, the above looks a bit silly, so one should write module Operator where data Type = New { name :: String } module Foo where import qualified Operator bar = Operator.New { name = "bar" , .. } :: Operator.Type b) full static overloading (resolved by looking at the argument types) of course this is (one more) source of increased complexity in the language (affecting the user, and the implementors) (This has been discussed here as well, although I don't remember the result. Was there one?) It is sometimes strange to see how Haskell as a language is so powerful in all its advanced respects (esp. the type/class system) but is obviously lacking in some others (e. g., naming issues like the above) On the other hand, this seems to reflect the "academic" origin of the language (resp., its main body of designers, implementors, and users): You won't get promoted, or tenured, or whatever, just for implementing something as (seemingly) simple as a module and scoping system - that's not research, "just" engineering. And indeed, some of the more "engineered" languages (think of Ada or Java) seem to have got this one right, or at least better. But we can't blame the academics for doing their job (i. e. research is what they're paid for). Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
participants (2)
-
Johannes Waldmann -
Serge D. Mechveliani