tuple component functions
As Haskell has the standard functions fst, snd to decompose (a,b), maybe, it worths to provide also tuple31, tuple31, tuple31, ... tuple51, tuple52, tuple53, tuple54, tuple55 for the tuples of n = 3,4,5 ? -- Sergey Mechveliani [EMAIL PROTECTED]
language extension proposal
Dear Haskell users and developers,
I announce that manual.txt from the archive
ftp.botik.ru:/pub/local/Mechveliani/docon/2/docon-2.zip
http://www.botik.ru...
contains the section
--
{lne} Language extension proposal
*
Adding the following language features seem to make Haskell more fit
the needs of programming mathematics:
(der)more "deriving" abilities
(overl) extended polymorphism for values and instance overlap
(dc) automatic conversion between types (domains)
(recat) reorganising standard algebraic categories
(es) equational simplifier annotations
...
...
--
You see, i worry about Haskell fitness for the programming of certain
tasks.
--
Sergey Mechveliani
[EMAIL PROTECTED]
RE: Haskell Wish list: library documentation
On Thu, 16 Sep 1999, Lars Lundgren wrote: [snip] myProg:: StateMT IO Int myProg = return 5 main = do n - runSMT myProg print n I forgot to show something interesting in my first example, try this instead: myProg:: StateMT IO Int myProg = do lift $ putStrLn "HelloWorld!" -- a lifted IO value return 5-- a StateMT value /Lars L
RE: tuple component functions
| As Haskell has the standard functions fst, snd to decompose (a,b),
| maybe, it worths to provide also
| tuple31, tuple31, tuple31,
| ...
| tuple51, tuple52, tuple53, tuple54, tuple55
|
| for the tuples of n = 3,4,5 ?
Simon PJ and I have written a proposal for Lightweight extensible
records in Haskell. You can find the most recent version on Simon's
web page or in the link that Erik posted to the proceedings of the
upcoming Haskell workshop. With the ideas described there, tuples
could be implemented as records, with labels chosen in some natural
way. (This idea comes from SML.) For example, you could treat
(e,f,g) as a short hand for {1=e, 2=f, 3=g}. And, if you have a
tuple t with at least three components, then you can write t.1, t.2,
and t.3 to extract those values. Notice that you don't have to say
anything about the size of the tuple; the type system will figure
that out for you, and complain as appropriate if you try to access
a component that isn't there. I think this would be a more attractive
solution than introducing a new, potentially unbounded family of
somewhat awkwardly named projection operators..
All the best,
Mark
Re: tuple component functions
As Haskell has the standard functions fst, snd to decompose (a,b), maybe, it worths to provide also tuple31, tuple31, tuple31, ... tuple51, tuple52, tuple53, tuple54, tuple55 for the tuples of n = 3,4,5 ? Yes! I often want fst3, snd3, thd3, at least. I suggest calling them "pi13" or "prj13" rather than "tuple31", though. I use them too, but I would prefer "pi1_3" or "prj1_3" so that we can keep the same convention for arbitrary length (...for generated programs, of course) and also, tuple3 a b c = (a,b,c) I prefer "tuple3" than "(,,)" , I don't manage to understand how to use "," alone. -- Bruno Barbier Laboratoire d'Informatique de Besancon, Universite de Franche-Comte, France Phone/Fax : (33) 381.666.459 / (33) 381.666.450 Mailto: [EMAIL PROTECTED]
Re: tuple component functions
As Haskell has the standard functions fst, snd to decompose (a,b), maybe, it worths to provide also tuple31, tuple31, tuple31, ... tuple51, tuple52, tuple53, tuple54, tuple55 for the tuples of n = 3,4,5 ? Yes! I often want fst3, snd3, thd3, at least. I suggest calling them "pi13" or "prj13" rather than "tuple31", though. --KW 8-) -- : Keith Wansbrough, MSc, BSc(Hons) (Auckland) : : PhD Student, Computer Laboratory, University of Cambridge, England. : : (and recently of the University of Glasgow, Scotland. [] ) : : Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.: : http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] : :-:
Novice question 2
Thanks again for your help with the previous question. I have another one. (If there is a more appropriate forum for simple questions like this, please let me know; I don't want to waste your time.) I am confused about the rules for constraints on polymorphic classes. Suppose I write a class intended to represent a "Map" data structure such as Java's java.util.Map or Ocaml's Hashtbl.t: class Map m where map_get:: (Eq a) = m a b - a - Maybe b map_put:: (Eq a) = a - b - m a b - m a b map_assocs :: (Eq a) = m a b - [(a, b)] Say I want to write a binary-tree implementation, which will require the key type a to have an ordering: data (Ord a) = BtreeMap a b = Leaf | Branch a b (BtreeMap a b) (BtreeMap a b) deriving (Eq, Ord, Show) instance Map BtreeMap where -- this doesn't work -- (obvious implementations) Then BtreeMap is not an instance of Map, because its methods come with the constraint (Ord a). If I instead write the class class SortedMap m where map_get:: (Ord a) = m a b - a - Maybe b map_put:: (Ord a) = a - b - m a b - m a b map_assocs :: (Ord a) = m a b - [(a, b)] then the instance declaration instance SortedMap BtreeMap where -- (obvious declarations) works fine. But with this setup, every Map is a SortedMap, because the constraint on the key type is looser for Map. This is the opposite of what I want! I think I just haven't understood the Haskell Way to do this. Can you show me what I'm missing? A related question -- Suppose instead I want to implement Map with association lists: type Alist a b = [(a, b)] instance Map Alist where -- this doesn't work map_get [] x' = Nothing map_get ((x, y):pairs) x' | x' == x = Just y | otherwise = map_get pairs x' map_put x' y' [] = [(x', y')] map_put x' y' ((x, y):pairs) | x' == x = (x, y'):pairs | otherwise = (x, y):(map_put x' y' pairs) map_assocs m = m This doesn't work because the type synonym Alist cannot be partially applied, being a type synonym. But if I use `newtype' instead, then I have to clutter up the code with an identity type constructor `A' and projector `unA'. Is there a cleaner way to do it? thanks peace, Chris Jeris
WAAAPL proceedings available
The proceedings of WAAAPL (Workshop on Algorithmic Aspects of Advaced Programming Languages) is now available electronically. WAAAPL will be held in Paris on September 30--between ICFP and the Haskell Workshop. The entire proceedings is at http://www.cs.columbia.edu/~cdo/waaapl99.pdf The program and links to invidual papers are at http://www.cs.columbia.edu/~cdo/waaapl-prog.html The proceedings will also be available shortly as a Columbia University technical report. Enjoy, Chris Okasaki
RE: Haskell Wish list: library documentation
| * stToIO . This is often necessary for programs that do |stateful things as well as IO. A few years ago, having read |all relevant papers, I was very perplexed by the problem of |doing stateful things and IO at the same time. Eventually I |realised it is not possible to nest monads, | | But it is possible! You just need to use a monadtransformer: While the discussion about monad transformers etc. is interesting, it might be worth pointing out that Hugs 98 already has stToIO. It's a standard function of type: ST s a - IO a that is exported from both the ST and LazyST libraries. Tim already explained that his wishlist was based on Hugs about a year ago. But that predates Haskell 98, Hugs 98, and another major effort that we made to bring Hugs and GHC that little bit closer together. But if you haven't downloaded Hugs 98 already, I'd suggest waiting a little longer for the next release. All the best, Mark
Re: tuple component functions
On 16 Sep, Keith Wansbrough wrote: I suggest calling them "pi13" or "prj13" rather than "tuple31", though. pi1_3 or proj1_3 or select_1_3 or sel_1_3, even s_1_3 -- omitting the "_" means sel is ambiguous (!). We should choose a scheme that can cope with such things even if they are unlikely. I don't think pi_m_n looks right unless you replace pi with the greek letter (UNICODE, anyone?). -- Jón Fairbairn [EMAIL PROTECTED]
Re: tuple component functions
Jón Fairbairn wrote (to the Haskell mailing list): pi1_3 or proj1_3 or select_1_3 or sel_1_3, even s_1_3 -- omitting the "_" means sel is ambiguous (!). We should choose a scheme that can cope with such things even if they are unlikely. I don't think pi_m_n looks right unless you replace pi with the greek letter (UNICODE, anyone?). Or adopt the proposal by Mark Jones and Simon Peyton Jones for records http://research.microsoft.com/~simonpj/#records and its extension to tuples, and you can write x.1, x.2, x.3 etc. Tbey don't seem sure about the syntax, but I don't mind using integers as field names for tuples. I think in all cases records are a better data structure. Just use tuples for functions with multiple results. Cheers, Ronny Wichers Schreur
