On Tue, 2007-02-13 at 19:22 -0800, Erick Tryzelaar wrote: > What would you change? There's a couple things I wish we had, like sugar > for lists
It seems things like list comprehension in Haskell 'drop out' of the Monad typeclass, where the argument is the list functor. The challenge here is providing the sugar without worrying the compiler about it. Already the compiler 'cheats' a bit on bool and int (and a bit on float and string too). But there are other 'sugar' issues of concern. One is that with the Eq and tord typeclass, we want to derive lexicographical comparison for product and sum types. Similarly, we want to derive the Show string method (Erick, that never went into the library!). In each of these cases, the algorithm is basically a fold over a tuple or switch over a sum (recursively). But short of downright cheating which Haskell appears to unfortunately do, I can't see how to do it: the combinator algorithm should be user specified with the typeclass. I don't know how to do this: to decode a tuple requires a generic operator which makes tuples look like lists at compile time: this exists now .. but it only works on concrete tuple types .. not on type variables later instantiated as tuples. I could easily code the special case of Eq so that instance Eq[int * long] was synthesised automatically on demand (it's just a fold of the function 'eq . and', quite simple). However for Tord, the result is actually a partial order. But the point is: I do not WANT to do this for these special cases no matter how much they're needed because it's just a hack: the algorithm should be user specified. It's quite unfortunate too, that construction and management of the bound terms at the point of instantiation is basically too late .. those terms have to be instantiated too. This isn't entirely a nit: we could get an infinite instantiation recursion. [We already have a 'known failure' where this happens: Ocaml doesn't fail like this because it uses intensional polymorphism and the code leads to a unification failure] -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
