Aerith Gainsborough (Final Fantasy = VII)
"All I=20 know is..."
"The Cetra were born from the Planet, speak with the = Planet, and=20
unlock the Planet."
"And....... then......"
"The Cetra will = return=20 to the Promised Land. A land that promises supreme happiness."=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
M. Faisal Fariduddin Attar=20 Nasution
-----------------------------------
farkinas@cbn.net.id
------=_NextPart_000_0007_01C0DF28.18AAB360-- From uk1o@rz.uni-karlsruhe.de Thu May 17 17:18:13 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 17 May 2001 18:18:13 +0200 Subject: Monads In-Reply-To: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl>; from rjchaaft@cs.uu.nl on Thu, May 17, 2001 at 11:57:45AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> Message-ID: <20010517181811.C14548@rz.uni-karlsruhe.de> Hello! On Thu, May 17, 2001 at 11:57:45AM +0200, Rijk-Jan van Haaften wrote: > >So what you are saying is that I actually don't need > >Monads to perform the tasks Monads supports ? > Indeed. However, not using the Monadic do syntax results in > hardly-readible code. I don't really think so. The operator precedences for >> and >>= are quite okay, especially combined to the precedence of lambda binding. How is main = getLine >>= \line -> let number = read line in let result = number + 42 in print result less readable than main = do line <- getLine let number = read line let result = number + 42 print result ? Or main = putStr "Hello! What's your name?" >> getLine >>= \name -> putStrLn ("Hello, " ++ name ++ "!") compared to main = do putStr "Hello! What's your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!") > [...] Yes, I use do syntax where appropriate (e.g. also for usual parser monads), however, the operator syntax can be written quite readably too. Kind regards, Hannah. From simonpj@microsoft.com Thu May 17 17:52:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 17 May 2001 09:52:10 -0700 Subject: Ix class Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F4C@red-msg-09.redmond.corp.microsoft.com> I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding=20 a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com]=20 | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class |=20 |=20 | Hello, |=20 | I am working on an Ix instance for one of my types and=20 | finding it rather restrictive. For me it would be useful to=20 | have rangeSize be defined in the Ix class (with a default=20 | definition of course), so that it can be overridden. |=20 | Also, does anybody know why Ix derives from Ord? It seems to=20 | me this is an unnecessary limitation on the types that can be=20 | instances of Ix. I cannot think of a reason why the=20 | implementation of anything in the Ix or Array modules would=20 | require that every Ix be an Ord (with a minor exception --=20 | see below). If an implementation is using a comparison on an=20 | Ix type, chances are it should be using inRange or comparing=20 | (index bnds x) with (index bnds y) instead. |=20 | One change would have to be made in the Array module if Ord=20 | is removed from Ix: | instance (Ix a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | would become: | instance (Ix a, Eq a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | As I said, I think this is a very minor issue. |=20 | I believe that making these changes in the standard would not=20 | impact existing programs in any way. Could these changes be=20 | considered as a possible "typo" to be fixed in the Library Report? |=20 |=20 | P.S. In case anybody's interested, here's why I want to override | rangeSize: |=20 | > newtype Honeycomb =3D Hx (Int,Int) deriving (Eq,Show,Ord) | >=20 | > indexError =3D error "Index out of range" | >=20 | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) =3D | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) =3D | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) =3D | > let i =3D index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | >=20 | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) =3D x `mod` 2 =3D=3D y `mod` 2 |=20 | This implements a honeycomb or hexagonal tiling for a maze=20 | generating program. The honeycomb is superimposed on a grid=20 | such that only every other square is "active", corresponding=20 | to a particular hexagon in the honeycomb. It's similar to a=20 | checkers game, where only the dark squares are used. |=20 | I would like _any_ pair of Ints to be an acceptable boundary=20 | for the honeycomb, not just the ones that represent valid=20 | indexes. For example, (Hx (0,0), Hx (15,12)) should be a=20 | valid set of bounds. The current definition of rangeSize=20 | makes this impossible, which is why I would like to override=20 | it. By the way, the Library Report does not explicitly say=20 | that the bounds have to both be valid indexes, though it does=20 | imply this with the sample definition of rangeSize. |=20 | Thanks, | Matt Harden |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From gruenbacher-lists@geoinfo.tuwien.ac.at Thu May 17 19:03:23 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Thu, 17 May 2001 20:03:23 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) Message-ID: Hello, I was trying to write an abstraction for bidirectional communication between two threads. For some reason, MVars seem to break: ----------------------------------------------- class Cords c t u where newCord :: IO (c t u) listen :: c t u -> IO t speak :: c t u -> u -> IO () data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) instance Cords Cord t u where newCord = return (Cord newEmptyMVar newEmptyMVar) speak (Cord _ s) t = do s' <- s ; putMVar s' t listen (Cord h s) = do h' <- h ; takeMVar h' otherEnd (Cord t u) = Cord u t showT :: Cord Int String -> IO () showT cord = do putStrLn "Runnning..." x <- listen cord putStrLn ("Heard " ++ show x) speak cord (show x) putStr ("Said " ++ (show x)) showT cord main :: IO () main = do cord <- newCord forkIO (showT (otherEnd cord)) speak cord 1 str <- listen cord putStrLn str ----------------------------------------------- Hugs writes: Main> main Runnning... Program error: no more threads (deadlock?) (131 reductions, 307 cells) Any ideas? Thanks, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789 From john@repetae.net Thu May 17 19:42:50 2001 From: john@repetae.net (John Meacham) Date: Thu, 17 May 2001 11:42:50 -0700 Subject: Proposal for generalized function partition in List-library In-Reply-To: ; from mg169780@zodiac.mimuw.edu.pl on Thu, May 17, 2001 at 12:36:39PM +0200 References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: <20010517114250.D13591@mark.ugcs.caltech.edu> this is just how I understand things at the moment, if I am wrong or misleading anywhere then please speak up. I am unconvinced that such generalizations must come as speed hits, but perhaps someone can enlighten me. compilers seem to support seperate compilation and polymorphism at the moment by boxing polymorphic types and passing their class-context (term?) as a hidden parameter to the polymorphic function. but it seems that since haskell is strongly type checked at compile time, we already KNOW all of the types with certainty when it comes to compiling the program in the end so this would seem to be unnecisarry. now there are two cases where this breaks down * seperate compilation * code bloat namely that you don't necisarilly know all of the types of polymorphic functions when they are in a module that is compiled seperately from the rest of the program. the solution used by many C++ compilers is to inline all polymorphic code in place (this is why templates are in header files). there is no reason this won't work in haskell and give back all of the speed benefits of base types everwhere (as it would in this example) but has the unfortunate side effect of causing worst case exponential code bloat as every function is re-written for every type combination it is used with. the solution I see (and probably exists) is a hybrid model, one that lets the compiler know to specialize certain polymorphic functions as well as let the compiler utilize such specialized functions. a pragma which lets the compiler know that a certain specialization would be useful such as partition :: (Eq b) => (a -> b) -> [a] -> [[a]] partition fn ls = ... {-# specialize partition :: (a -> Bool) -> [a] [[a]] -} which would let the compiler know to generate code for partition specificially optimized for (a -> Bool) and thus obviating the need for the Eq hidden argument. the fully polymorphic version would of course also have to be generated. specializations would be advertised in the header file and utilized whenever the typechecker determined you were using partition in the specialized case. this seems like a better solution than the current practice of providing seperate general and specific functions, take, genTake, max, genMax and whatnot. you would just specify that specializations for the case of 'Int' should be generated as it would be the most common case. an {-# inline partition -} might also be useful which would actually place the text of the function into the .hi file to be in-line expanded as is done in C++... I imagine there would be some tweaking to determine when this is a win and when it isn't... some of this stuff probably exists in current compilers, but polymorphism need not be at the expense of speed. -John On Thu, May 17, 2001 at 12:36:39PM +0200, Michal Gajda wrote: > On Thu, 17 May 2001, Bernd [iso-8859-2] Holzmüller wrote: > > This partitioning function builds equivalence classes from the list > > argument, where each element list within the result list consists of > > elements that all map to the same value when applying f to it. > > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] > > > > This is much more general than the existing partitioning function and > > applicable in many practical cases. > > But here generality comes at the expense of speed I think. -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Thu May 17 20:36:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:36:44 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: Thu, 17 May 2001 10:06:55 +0200, Bernd Holzmüller pisze: > I would like to propose a new function for module List that generalizes > the current function partition :: (a -> Bool) -> [a] -> [[a]] No, current partition has type (a -> Bool) -> [a] -> ([a], [a]) so your function is not compatible with it, so shouldn't replace such standard function. > partition:: Eq b => (a -> b) -> [a] -> [[a]] > partition _ [] = [] > partition f (a:as) = > let (as',as'') = foldr (select (f a)) ([],[]) as > in (a:as'):partition f as'' > where > select b x (ts,fs) | f x == b = (x:ts,fs) > | otherwise = (ts,x:fs) This function doesn't give a hint which sublists correspond to which results of the function, so I'm afraid it's easy to make errors by assuming that they will come in a different order. And it's inefficient: the cost is the number of elements times the number of different results of the function. I would write it thus: \f xs -> groupBy (\(a, _) (b, _) -> a == b) $ sortBy (\(a, _) (b, _) -> compare a b) [(f x, x) | x <- xs] You can apply 'map (map snd)' to the result to remove the results of f. I don't have a good name for it and I'm not sure it's common enough to put it in the standard library. It can also be more efficiently written using Array.accumArray for particular types of the result of the function. PS. What I would perhaps put into standard library: uniq :: Eq a => [a] -> [a] uniqBy :: (a -> a -> Bool) -> [a] -> [a] so people don't use nub unnecessarily (if elements are adjacent or can be made adjacent by sorting), and takeLastWhile :: (a -> Bool) -> [a] -> [a] dropLastWhile :: (a -> Bool) -> [a] -> [a] spanEnd :: (a -> Bool) -> [a] -> ([a], [a]) (with some better names) which iterate forward and are lazy, to avoid double reversing in case the test is cheap but the list is long, and partitionM :: Monad m => (a -> m Bool) -> [a] -> m ([a], [a]) Here are implementations of some of these: takeLastWhile p xs = case span p xs of (ys, []) -> ys (_, _:zs) -> takeLastWhile p zs dropLastWhile p xs = case span p xs of (_, []) -> [] (ys, z:zs) -> ys ++ z : dropLastWhile p zs spanEnd p xs = case span p xs of (ys, []) -> ([], ys) (ys, z:zs) -> (ys ++ z : ys', zs') where (ys', zs') = spanEnd p zs -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Thu May 17 20:43:46 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:43:46 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: 17 May 2001 19:36:44 GMT, Marcin 'Qrczak' Kowalczyk pisze: > PS. What I would perhaps put into standard library: And also: split :: (a -> Bool) -> [a] -> [[a]] split p c = let (xs, ys) = break p c in xs : case ys of [] -> [] _:zs -> split p zs softSplit :: (a -> Bool) -> [a] -> [[a]] -- softSplit p c = filter (not . null) (split p c) softSplit p c = case dropWhile p c of [] -> [] x:xs -> let (ys, zs) = break p xs in (x:ys) : softSplit p zs It follows that words = softSplit isSpace. Any better name? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jenglish@flightlab.com Thu May 17 22:14:53 2001 From: jenglish@flightlab.com (Joe English) Date: Thu, 17 May 2001 14:14:53 -0700 Subject: Monads In-Reply-To: <200105170912.CAA09737@mail4.halcyon.com> References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <200105172114.OAA07367@dragon.flightlab.com> Ashley Yakeley wrote: > At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. [...] > >[...] Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. I don't know about that; I use monads most often when dealing with container classes (sets, bags, lists). They also provide a useful way to reason about parts of XPath and XSLT. As far as learning about them goes, I don't think I really "got" monads until reading Wadler's aptly-titled "Comprehending Monads", which approaches them from this perspective. --Joe English jenglish@flightlab.com From agold@bga.com Thu May 17 22:21:21 2001 From: agold@bga.com (Arthur H. Gold) Date: Thu, 17 May 2001 16:21:21 -0500 Subject: Questions about Trie References: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> Message-ID: <3B0440D1.2248C105@bga.com> > "M. Faisal Fariduddin Attar Nasution" wrote: > > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using > basic Lempel-zif technique. I use a Trie (retrieval) as a data > structure for the dynamic dictionary aplication. The problem is Trie > uses not just an ordinary binary tree, but it uses a multiple-weighted > tree, where one node has at most 256 children. Most literatures about > Haskell show only binary tree for the example in tree or Abstract Data > Structures subject. So, does anyone know how to code the > implementation for trie. Thanks for paying attention and I'm really > hoping for the answer immediately. > IIRC, there's a trie implementation in Chris Okasaki's "Purely Functional Data Structures" -- that might be a start (there's also his "Edison" library, which contains many of the components you'd need). HTH (and sorry if it doesn't) --ag -- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu -- I am looking for work. Contact me. From ken@digitas.harvard.edu Thu May 17 22:17:49 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Thu, 17 May 2001 17:17:49 -0400 Subject: Wadler (was RE: Monads) In-Reply-To: ; from Joe.Bowers@CanopySystems.com on Thu, May 17, 2001 at 09:35:19AM -0400 References: Message-ID: <20010517171749.A25335@digitas.harvard.edu> --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-17T09:35:19-0400, Joe Bowers wrote: > There have been several references to "a paper by > Wadler" in this thread- some folks (well, at least > one folk :) on this list may not be familiar with > the work surrounding Haskell yet, and (from this context) > This paper seems like a pretty good place to start. > =20 > Would anybody have a detailed citation for it, > or (even better) is it up on the web? Wadler's monad papers, including "Comprehending Monads", are at http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig My god, I've seen heaven. - Flute at Band Camp --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BD/9zjAc4f+uuBURAnmcAJ9M6+wyOg+izO2eQo3GS5ovm55P+ACguuzz 9a35nSAI8w6IuYvSs7+ei7M= =9zoV -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From karczma@info.unicaen.fr Fri May 18 07:56:57 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 08:56:57 +0200 Subject: Monads References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> Message-ID: <3B04C7B9.D14AA827@info.unicaen.fr> Rijk-Jan van Haaften >>= Hannah Schroeter: > > ... However, not using the Monadic do syntax results in > > hardly-readible code. > > I don't really think so. The operator precedences for >> and >>= are > quite okay, especially combined to the precedence of lambda binding. ... > main = do > putStr "Hello! What's your name?" ... > Yes, I use do syntax where appropriate (e.g. also for usual parser > monads), however, the operator syntax can be written quite readably > too. I would add that sometimes you may be interested in Monadic SEMANTICS at a more profound level, trying to hide it completely at the surface. Then, the <> syntax is an abomination. The examples are already in the Wadler's "Essence". Imagine the construction of a small interpreter, a virtual machine which not only evaluates the expressions (belonging to a trivial Monad), but perform some side effects, or provides for exceptions propagated through a chain of Maybes. Then the idea is to * base the machine on the appropriate Monad * "lift" all standard operators so that an innocent user can write (f x) and never x >>= f (or even worse). The <> construct in such a context resembles the programming in assembler, and calling it more readable is hmmmm... not very convincing. (My favourite example is the "time-machine" monad, a counter-clock-wise State Monad proposed once by Wadler, and used by myself to implement the reverse automatic differentiation algorithm. Understanding what's going on is difficult. The <> syntax makes it *worse*.) Jerzy Karczmarczuk Caen, France From josefs@cs.chalmers.se Fri May 18 09:32:54 2001 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Fri, 18 May 2001 10:32:54 +0200 (MET DST) Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: John, On Thu, 17 May 2001, John Meacham wrote: [..] > namely that you don't necisarilly know all of the types of polymorphic > functions when they are in a module that is compiled seperately from the > rest of the program. the solution used by many C++ compilers is to > inline all polymorphic code in place (this is why templates are in > header files). there is no reason this won't work in haskell and give > back all of the speed benefits of base types everwhere (as it would in > this example) but has the unfortunate side effect of causing worst case > exponential code bloat as every function is re-written for every type > combination it is used with. > This is true in ML but not in Haskell. Haskell has polymorphic recursion which makes it impossible to predict statically at what types a function will be called. So trying to inline away polymorphism would lead to infinite unwindings. Cheers, /Josef From Colin.Runciman@cs.york.ac.uk Fri May 18 09:43:10 2001 From: Colin.Runciman@cs.york.ac.uk (Colin.Runciman@cs.york.ac.uk) Date: Fri, 18 May 2001 09:43:10 +0100 Subject: Questions about Trie Message-ID: <200105180843.JAA00498@pc179.cs.york.ac.uk> > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using basic > Lempel-zif technique. I use a Trie (retrieval) as a data structure for > the dynamic dictionary aplication. The problem is Trie uses not just an > ordinary binary tree, but it uses a multiple-weighted tree, where one > node has at most 256 children. Most literatures about Haskell show only > binary tree for the example in tree or Abstract Data Structures subject. > So, does anyone know how to code the implementation for trie. Thanks for > paying attention and I'm really hoping for the answer immediately. There is some relevant material in Chapter 6 (Text compression) of `Applications of Functional Programming', UCL Press, 1995. ISBN: 1-85728-377-5. (With apologies for self-reference, as co-editor of the book.) Colin R From lennart@mail.augustsson.net Fri May 18 10:02:58 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Fri, 18 May 2001 11:02:58 +0200 Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library References: Message-ID: <3B04E542.76BA65A5@mail.augustsson.net> Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. This is true in theory, but in practice most polymorphism can be removed by inlining. I'm sure some pragmatic solution with limited inlining would work quite well. You'd still need to be able to handle polymorphism without inlining, of course, so you could cope with the exceptional cases. Mark Jones did some experiments with this kind of inlining that worked very well. -- Lennart From karczma@info.unicaen.fr Fri May 18 10:25:14 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 11:25:14 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> Message-ID: <3B04EA7A.90D83CFB@info.unicaen.fr> Maestri, Primaballerine, I have a really provocative question. One of my student posed it, and I could not respond in a satisfactory manner, especially for myself it was really unsatisfactory. We know that a good part of "top-down" polymorphism (don't ask me what do I mean by that...) in C++ is emulated using templates. Always when somebody mentions templates in presence of a True Functionalist Sectarian, the reaction is "What!? Abomination!!". Now the question: WHY? Why so many people say "the C++ templates are *wrong*" (and at the same time so many people use it every day...) Is it absolutely senseless to make a functional language with templates? Or it is just out of fashion, and difficult to implement? == This is a sequel to a former discussion about macros, of course... Jerzy Karczmarczuk Caen, France From bjpop@cs.mu.OZ.AU Fri May 18 10:30:38 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Fri, 18 May 2001 19:30:38 +1000 (EST) Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library In-Reply-To: <3B04E542.76BA65A5@mail.augustsson.net> from Lennart Augustsson at "May 18, 2001 11:02:58 am" Message-ID: <200105180930.TAA25290@mulga.cs.mu.OZ.AU> Lennart wrote: > This is true in theory, but in practice most polymorphism can be removed > by inlining. I'm sure some pragmatic solution with limited inlining would > work quite well. You'd still need to be able to handle polymorphism without > inlining, of course, so you could cope with the exceptional cases. > > Mark Jones did some experiments with this kind of inlining that worked very well. > > -- Lennart The MLton compiler (http://www.clairv.com/MLton/) uses whole program compilation and monomorphises ML code (again they do not have to deal with potential polymorhpic recursion, but as Lennart says, it can be treated as a special case in Haskell). I have never used it though, so I can't vouch for its performance. They are motivated to use unboxed representations and so on. The danger with whole program compilation is long compile times. But it might be possible to allow separate compilation for development and put up with the overheads of boxed representations and so on, but get the benefits of the optimisations flowing from whole program compilation when needed (ie released binaries). Sounds like a lot of work to me though. Bernie. From simonpj@microsoft.com Fri May 18 08:28:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 18 May 2001 00:28:50 -0700 Subject: Questions about Trie Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F50@red-msg-09.redmond.corp.microsoft.com> Perhaps this monads discussion might move to haskell-cafe@haskell.org? It's a good discussion, but it's just what haskell-cafe is for. http://www.haskell.org/mailinglist.html Simon | -----Original Message----- | From: Arthur H. Gold [mailto:agold@bga.com]=20 | Sent: 17 May 2001 22:21 | To: haskell@haskell.org | Cc: M. Faisal Fariduddin Attar Nasution | Subject: Re: Questions about Trie |=20 |=20 | > "M. Faisal Fariduddin Attar Nasution" wrote: | >=20 | > Greeting, I'm a last year student in a computer science=20 | field. I'm=20 | > currently trying to code an implementation for a =20 | compression using=20 | > basic Lempel-zif technique. I use a Trie (retrieval)=20 | as a data=20 | > structure for the dynamic dictionary aplication. The=20 | problem is Trie=20 | > uses not just an ordinary binary tree, but it uses a=20 | multiple-weighted=20 | > tree, where one node has at most 256 children. Most=20 | literatures about=20 | > Haskell show only binary tree for the example in tree or=20 | Abstract Data | > Structures subject. So, does anyone know how to =20 | code the | > implementation for trie. Thanks for paying attention and=20 | I'm really=20 | > hoping for the answer immediately. | >=20 |=20 | IIRC, there's a trie implementation in Chris Okasaki's=20 | "Purely Functional Data Structures" -- that might be a start=20 | (there's also his "Edison" library, which contains many of=20 | the components you'd need). |=20 | HTH (and sorry if it doesn't) | --ag |=20 | --=20 | Artie Gold, Austin, TX (finger the cs.utexas.edu account for=20 | more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu | -- | I am looking for work. Contact me. |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From tweed@compsci.bristol.ac.uk Fri May 18 11:22:36 2001 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Fri, 18 May 2001 11:22:36 +0100 (BST) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: (This response comes from the context of someone who like FP but has a day job writing in C++.) On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. Umm... what do you mean by `top down'? The two senses in which I use polymorphism in C++ are: (i) using super classes (in the sence that A is a superclass of B is B inherits from A) to perform operations that only make sense for objects of the semantic type A. My canonical example is working with quadtree nodes, where a there are various types nodes which can hold different kinds of data but the base class qnode holds things like position, etc. (ii) using templates to write generic algorithms which either don't depend on the object type at all (e.g., vectors, lists, etc) or which depend on one or two conceptual operations which are very elementary (e.g., meaningful equality, addition or a `display yourself on stdout' function). In C++ these could _almost_ be done using superclasses but with problems because (A) the standard types (e.g., int) can't have their place in the class hierarchy redefined (e.g., int inherits from debug_show) (B) deep hierarchies are really not handled well by debuggers and it'd be a real pain trying to look at the C++ equivalent of the haskell `data A = ... deriving (Show,Ord,Monad,...)' The almost that I referred to above comes from the fact that (AFAIK) without using something nasty like RTTI you can't create new objects of the true type in a function to which you've passed a pointer to the base class. That's the conceptual overview. In terms of pragmatics __at least for my work in image processing__ I don't write classes that much, seldom use inheritance and I'm 99% sure I don't have any inheritance more than 1 level deep. On the other hand I write a lot of templated code which would be equivalent in haskell to either f :: a -> b -> .... -> a or f :: Eq a => a -> b -> ... -> a (i.e., algorithms that need just one or two low-level ideas such as equality). I much prefer the Haskell way of doing this with superclasses but I just don't feel brave enough to attempt the levels of class hierarchy that this implies in C++. (In some ways this is a shame since, because in template function names member functions used are only matched syntactically -- as there's no superclass to ensure semantic equivalence -- I've made one or two mistakes when I forgot a member function with the same name actually meant something different.) > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) In my experience the C++ idiom `you only pay for what you use' (==> templates are essentially type-checked macros) and the fact most compilers are evolved from C compilers makes working with templates a real pain in practice. Additionally, I think a lot of people who dislike them are old-time C hackers who don't see why it isn't good enough to do polymorphism via void*'s and function pointers. As to why I at least use it, it lets me write polymorphic functions without needing deep class hierarchies (which as noted above aren't nice in C++) or going into the error prone mire of the void* approach. > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? I may be missing something obvious, but given Haskell's well thought out (IMO) prelude class structure and the fact that deep class hierarchies with `multiple inheritance' aren't a problem in Haskell, I don't see that it would buy you anything in Haskell. On the other hand, if the standard prelude didn't have the class hierarchy I think they would be much more useful. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. From heringto@cs.unc.edu Fri May 18 15:30:38 2001 From: heringto@cs.unc.edu (Dean Herington) Date: Fri, 18 May 2001 10:30:38 -0400 Subject: MVar Problem (Concurrent Hugs) References: Message-ID: <3B05320E.6FE477AA@cs.unc.edu> Andreas Gruenbacher wrote: > Hello, > > I was trying to write an abstraction for bidirectional communication > between two threads. For some reason, MVars seem to break: > > ----------------------------------------------- > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > > data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) > > instance Cords Cord t u where > newCord = return (Cord newEmptyMVar newEmptyMVar) > speak (Cord _ s) t = do s' <- s ; putMVar s' t > listen (Cord h s) = do h' <- h ; takeMVar h' > > otherEnd (Cord t u) = Cord u t > > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStr ("Said " ++ (show x)) > showT cord > > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str > ----------------------------------------------- You are creating a new MVar with each listen and speak. As a result, the two threads never agree on an MVar, so deadlock occurs. Instead, you should create the pair of MVars in newCord. Try the code below. > import Concurrent > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > data Cord t u = Cord (MVar t) (MVar u) > instance Cords Cord t u where > newCord = do t <- newEmptyMVar > u <- newEmptyMVar > return (Cord t u) > listen (Cord t _) = takeMVar t > speak (Cord _ u) s = putMVar u s > otherEnd (Cord t u) = Cord u t > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStrLn ("Said " ++ show x) > showT cord > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str Dean From gruenbacher-lists@geoinfo.tuwien.ac.at Fri May 18 16:54:49 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Fri, 18 May 2001 17:54:49 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) In-Reply-To: <3B05320E.6FE477AA@cs.unc.edu> Message-ID: On Fri, 18 May 2001, Dean Herington wrote: > You are creating a new MVar with each listen and speak. As a result, the > two threads never agree on an MVar, so deadlock occurs. Instead, you should > create the pair of MVars in newCord. Try the code below. > > [...] Thanks, this works. Thanks! --Andreas. From ger@tzi.de Fri May 18 17:22:07 2001 From: ger@tzi.de (George Russell) Date: Fri, 18 May 2001 18:22:07 +0200 Subject: Templates in FPL? Message-ID: <3B054C2F.C1BBE335@tzi.de> The MLj compiler from ML to the Java Virtual Machine (which is being actively worked on by the geniuses at Microsoft as we speak) expands out all polymorphism. I helped develop this compiler and I believe this approach to be a good one. There are particular reasons why it's good for this case (1) as has been said before, ML does not have polymorphic recursion; (2) the cost of object creation in Java used at least to be horrendous, so it was well worth working hard to get rid of it. However I think long term it's a good idea for normal Haskell compilers because my guess is you will Win Big on quite a lot of things, because you don't have to carry around and use dictionaries (for method lookup in class instances) and can do a lot more specialisation and inlining. Strict values can also be unboxed. Of course you can control specialisation used unboxed values already in Glasgow Haskell, but it requires special annotations or special types. The minus points are thuswise, so far as I know: (1) the compiled code is bigger. This means the code might indeed run more slowly. But with MLj I think we found that in normal cases it isn't THAT much bigger (maybe about 50%), because the functions which get specialised a lot (like "length" and "map") tend to be pretty small. Of course you can construct artificial cases where the code size will explode. (2) It takes much longer to compile. I'm waiting for Moore's law here, but at present I would be surprised if (say) Glasgow Haskell could compile itself inlining out all polymorphism, without it taking a very long time or a very fast computer or lots of nasty imperative optimisations. (3) You can't inline everything, because of polymorphic recursion, and also because it would be nice to allow Haskell code to be dynamically linked in (see GHCi). Or you can inline everything, but then you need to implement a Haskell Virtual Machine which does the inlining (and the whole compiler backend) on demand at runtime. I don't think you have to inline everything; it should surely be possible to leave polymorphic versions of the functions around, to use for hard cases. From msk@post.tepkom.ru Fri May 18 17:33:46 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Fri, 18 May 2001 20:33:46 +0400 (MSD) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? ordinary FP polymorphish is as strict analogue of the C++ template-functions Haskell type clasess is as close analog for the C++ template classes (studing of the Haskell type classes clarify to me many aspects of the C++ classes templates semantic). Regards, Anton From ken@digitas.harvard.edu Fri May 18 20:08:47 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Fri, 18 May 2001 15:08:47 -0400 Subject: Monads In-Reply-To: <3B04C7B9.D14AA827@info.unicaen.fr>; from karczma@info.unicaen.fr on Fri, May 18, 2001 at 08:56:57AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> <3B04C7B9.D14AA827@info.unicaen.fr> Message-ID: <20010518150847.A6077@digitas.harvard.edu> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-18T08:56:57+0200, Jerzy Karczmarczuk wrote: > The examples are already in the Wadler's "Essence". Imagine the=20 > construction of a small interpreter, a virtual machine which not only > evaluates the expressions (belonging to a trivial Monad), but perform > some side effects, or provides for exceptions propagated through a > chain of Maybes. Then the idea is to >=20 > * base the machine on the appropriate Monad > * "lift" all standard operators so that an innocent user can write (f x) > and never x >>=3D f (or even worse). Perhaps you already know about Filinski's PhD thesis? He seems to have proven that we already have the "small interpreter" you want, inside of any programming language that supports call/cc and storing a function in a single storage cell. ML is such a programming language. You can define your own monads yet rely on implicit evaluation ordering in ML to do the lifting you want! --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Learn Esperanto and make friends around the world http://www.esperanto.net --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BXM/zjAc4f+uuBURAtYcAKCafrEuesrlWUObVdidMDJf5VCzwACfcAQb 9vI2sHi/yei+T2JVHxC/sZE= =fDKP -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From qrczak@knm.org.pl Fri May 18 20:11:21 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 19:11:21 GMT Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Fri, 18 May 2001 11:25:14 +0200, Jerzy Karczmarczuk pisze: > Always when somebody mentions templates in presence of a True > Functionalist Sectarian, the reaction is "What!? Abomination!!". They aren't that wrong, but they have some problems: * It's not specified what interface they require from types to be instantiated to. * The whole implementation must be present in a public header file. Well, there is the 'export' keyword, but no compiler implements it. It follows that all things used by implementation of a template must be included too. And compilation time of a large project is larger than necessary. * They introduce very complex rules about name lookup (environment in which a specialized template is compiled is a weird mix of environments of the point of definition and point of usage of the template), deduction which overloading to use (with choosing the candidate according to partial ordering of better fitting), deduction of template types and what partial specialization to use, complicated by the fact that there are complex rules of implicit conversions. Templates don't obey a Haskell's rule that adding code doesn't change the meaning of previously valid code and can at most introduce an ambiguity which is flagged as error. * Types can't be deduced from the context of usage. For example handling the empty set or monadic 'return' would require either spelling the type at each use or introducing another type and deferring deduction of the real type until an operation is performed with a value of a known type. * Since they are similar to macros, they tend to give horrible error messages which mentions things after expansion. Here is what I once got: mico-c++ -Wall -I. -c serwer.cc -o serwer.o serwer.cc: In method `void Firma_impl::usun(const char *)': serwer.cc:92: `struct __rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *>' has no member named `second' serwer.cc:93: no matching function for call to `map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase (__rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *> &)' /usr/include/g++/stl_map.h:156: candidates are: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>) /usr/include/g++/stl_map.h:157: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(const string &) /usr/include/g++/stl_map.h:158: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>, __rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair, __default_alloc_template >,Katalog *> *>) make: *** [serwer.o] Error 1 They also have some advantages over mechanisms available in Haskell: * A templatized class can contain types, values with arbitrary types, other templates etc. so it's easy to have parametrization of all things by types. Haskell requires fundeps, dummy arguments and local quantifiers to handle these things - sometimes it's not nice. * A template can be parametrized by values of primitive types (by expressions using builtin operations which can be evaluated at compile time). Yes, it's ugly that types and operations don't have equal rights, but it's sometimes useful. * A template is in practice guaranteed to be specialized to used types, so they don't have a performance overheads over non-templatized variants. My not-quite-done-right attempt at inlining dictionary functions in ghc is a step in this direction, as is the proposal of export-unfolding-and-specialize-but-not-necessarily-inline. I hope that SimonPJ will sort this out. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@repetae.net Fri May 18 20:32:11 2001 From: john@repetae.net (John Meacham) Date: Fri, 18 May 2001 12:32:11 -0700 Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: ; from josefs@cs.chalmers.se on Fri, May 18, 2001 at 10:32:54AM +0200 References: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: <20010518123211.E13591@mark.ugcs.caltech.edu> this is interesting, could someone give an example of how polymorphic recursion would disallow specialization of a function? i mean, it seems to me that even if you had recursion, you still have to actually call the function at some point with some real type and at that point you can decide whether to use the specialized version or not. One of the main things i was hopeing was that the seperate 'generic' and 'concrete' functions in the Prelude could be dumped for just the generic ones. the compiler should be able to optimize for the common cases of Nums being Ints and whatnot. (with the help of some pragma annotations.) -John On Fri, May 18, 2001 at 10:32:54AM +0200, Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. > > Cheers, > /Josef -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From mg169780@students.mimuw.edu.pl Fri May 18 22:10:54 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Fri, 18 May 2001 23:10:54 +0200 (CEST) Subject: Templates in FPL? In-Reply-To: <3B054C2F.C1BBE335@tzi.de> Message-ID: On Fri, 18 May 2001, George Russell wrote: > The minus points are thuswise, so far as I know: > (1) the compiled code is bigger. (...) > (2) It takes much longer to compile. (...) As it is very aggressive optimization, I strongly suggest explicit(non-default) compiler switch Greetings :-) Michal Gajda korek@icm.edu.pl From qrczak@knm.org.pl Fri May 18 21:44:52 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 20:44:52 GMT Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library References: <20010517114250.D13591@mark.ugcs.caltech.edu> <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > this is interesting, could someone give an example of how polymorphic > recursion would disallow specialization of a function? test:: Show a => a -> [String] test x = show x : test [x] -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From Jan de Wit"

<20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: <002a01c0e076$6029f8a0$9505c5d5@yatima> From: "Marcin 'Qrczak' Kowalczyk" > Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > > > this is interesting, could someone give an example of how polymorphic > > recursion would disallow specialization of a function? > > test:: Show a => a -> [String] > test x = show x : test [x] Another source of programs needing polymorphic recursion are non-regular datatypes, which occur frequently in Chris Okasaki's _Purely_Functional_Data_Structures_. A bare-bones example is: | data Perfect a = One a | Two (Perfect (a,a)) | deriving Show | | mkPerfect :: Int -> a -> Perfect a | mkPerfect 1 x = One x | mkPerfect (n+1) x = Two (mkPerfect n (x,x)) mkPerfect will be called with a number of different types for its second argument, depending on the first argument. HTH, Jan de Wit From luc.taesch@csfb.com Mon May 21 12:48:22 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Mon, 21 May 2001 13:48:22 +0200 Subject: PP with HaXml 1.02 Message-ID: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Im proceeding with basic exploratory tests witrh HaXml (1.02, winhugs feb 2001) the pretty print return the closing < on the next line, like what am i doing wrong ? ( the call is like import qualified XmlPP as PP ... main = do content <- readFile "subjdb.xml" (putStrLn . render . PP.document . parse) content (btw, thanks malcolm for packaging a specific hugs distribution) This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ketil@ii.uib.no Mon May 21 13:48:36 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 21 May 2001 14:48:36 +0200 Subject: PP with HaXml 1.02 In-Reply-To: "Taesch, Luc"'s message of "Mon, 21 May 2001 13:48:22 +0200" References: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Message-ID: "Taesch, Luc" writes: > the pretty print return the closing < on the next line, like > > > where i expect > > > My guess is that HaXML doesn't validate (using the DTD) or simply ignores it for pretty printing purposes. If the "Person-XML" element were defined to hold #PCDATA as well as (a) "Name" element(s), the two examples above are not equivalent, since you've added white space characters to the contents. Adding whitespace within the tag is okay, though, since it doesn't change the semantics of the document. > This message is for the named person's use only. It may contain [...] (Jeez! Has CSFB hear of mailing lists?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From taha@cs.yale.edu Mon May 21 16:17:26 2001 From: taha@cs.yale.edu (Walid Taha) Date: Mon, 21 May 2001 11:17:26 -0400 (EDT) Subject: SAIG'01 Extended Deadline In-Reply-To: References:

Message-ID: CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (EXTENDED DEADLINE: June 1st, 2001) Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and system= s address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice= =2E The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) I= n addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by June 1st, 2001. This extended deadline is final. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha,Yale (PC Chair) URL: http://cs-www.cs.yale.edu/homes/taha/saig/cfp01.html From Malcolm.Wallace@cs.york.ac.uk Mon May 21 19:01:01 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Mon, 21 May 2001 19:01:01 +0100 Subject: ANNOUNCE: nhc98 1.04 and Hat 1.04 Message-ID: We are pleased to announce a new release of the nhc98 compiler, and in particular its facilities (both brand new and improved old stuff) for tracing and debugging Haskell programs - the Hat system. The basic nhc98 compiler version 1.04 is mostly a bugfix release (details listed at the bottom of this announcement). http://www.cs.york.ac.uk/fp/nhc98/ However, the stuff we are really excited about is Hat - our Haskell tracer. A full user guide to these new tools is available on the website. http://www.cs.york.ac.uk/fp/hat/ Hat 1.04 ======== * Lots more tools for tracing! hat-stack - Displays a "virtual" stack-trace for any program that failed with a runtime error. hat-detect - Algorithmic bug detection, based on a textual question-and-answer session. hat-trail - The original graphical trail browser, now with several presentation enhancements. hat-observe - Examine the inputs and outputs of any named function, in the style of HOOD. * Tracing with Hat is now based on a completely new architecture (although still within the nhc98 compilation system). A program compiled for tracing now builds its "redex trails" in file, not in the heap. This has some performance consequences: (1) you no longer need to allocate large amounts of heap memory for tracing; (2) but you will probably need large amounts of disk space instead - remember disk space is cheap; (3) and traced programs still run somewhat slowly. * However, there are a couple of major benefits in return: (1) A trace is persistent, so after running your program once, you can examine many different aspects of the trace without re-computation. (2) Traces are now first-class objects, so you can examine and manipulate them in far more detail - hence the variety of new tracing tools. * Greater Haskell'98 compatibility. Almost all language features are now supported: named fields and better handling of pattern bindings are the main additions. All standard libraries except Time and Locale are now supported. nhc98 1.04 ========== * New: Improved (more accurate) time profiling now provided. * New: Support for extended module namespaces of the form Long.Hierarchical.Module.Name is now provided in both nhc98 and hmake. * Bugfix: An identifier hidden on import and redefined in the current module, then exported, but also imported qualified and used qualified in the current module, led to an incorrect interface file being generated. * Bugfix: hmake issued an unnecessary -cpp flag on some literate files. * Bugfix: Type of IO.hSetPosn :: Handle -> HandlePosn -> IO () was incorrect. * Bugfix: Compile-time error in src/tracer/runtime/ident.c on RedHat 7 and other systems using the new ISO C standard for fpos_t. * Bugfix: A file opened in ReadMode or WriteMode was actually opened in ReadWriteMode, so if the file had strict permissions the correct opening command would fail. Conversely, opening in ReadWriteMode actually gave ReadMode instead, and file updates silently failed. * Bugfix: Operator sections suffered from priority inversion, for example (^2*3) was incorrectly parsed as (^(2*3)), even though ^ binds more tightly than *. * Bugfix: The library function Directory.createDirectory gave strange permissions to the new directory. (Mode was in hex, but should have been octal!) * New: Improved printing of I/O error messages. Happy tracing! The Hat team at York (Colin Runciman, Olaf Chitil, Malcolm Wallace, Thorsten Brehm, Phil Hassall) From mikg@free.fr Mon May 21 19:51:37 2001 From: mikg@free.fr (=?iso-8859-1?Q?Micka=EBl_GAUTIER?=) Date: Mon, 21 May 2001 20:51:37 +0200 Subject: Problem to load the file Stack.hs with Hugs98 Message-ID: <00c901c0e227$74411c80$3406e4d5@machinegun> This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to use the file stack.hs wich is provided with Hugs 98 but = the following message errors display: "Haskell98 does not support restricted type synonyms" Can you explain me why and how I can load stack.hs ? Thanks in advance ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I would like to use the file stack.hs wich is = provided=20 with Hugs 98 but the following message errors display:

"Haskell98 does not support restricted type=20 synonyms"

Can you explain me why and how I can load stack.hs=20 ?

Thanks in advance

------=_NextPart_000_00BA_01C0E237.D4539520-- From qrczak@knm.org.pl Mon May 21 21:30:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 21 May 2001 20:30:44 GMT Subject: Problem to load the file Stack.hs with Hugs98 References: <00c901c0e227$74411c80$3406e4d5@machinegun> Message-ID: Mon, 21 May 2001 20:51:37 +0200, Mickaël GAUTIER pisze: > I would like to use the file stack.hs wich is provided with Hugs 98 but > the following message errors display: > "Haskell98 does not support restricted type synonyms" > Can you explain me why and how I can load stack.hs ? hugs -98 Stack.hs This command line flag enables non-Haskell-98 extensions. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From davidbak@microsoft.com Tue May 22 02:23:31 2001 From: davidbak@microsoft.com (David Bakin) Date: Mon, 21 May 2001 18:23:31 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm having trouble understanding recursive types (e.g., as described in Functional Programming with Overloading and Higher-Order Polymorphism by Jones. =20 He gives as an example =20 =20 > data Mu f =3D In (f (Mu f)) =20 > data NatF s =3D Zero | Succ s > type Nat =3D Mu NatF =20 Among the things I don't get are: =20 1. Comparing this to the non-higher-order type: =20 > data NatX =3D Zero | Succ NatX =20 What are the advantages of the higher-order type? What are the disadvantages (incl. runtime costs)? =20 2. How are values of type Nat represented? (It helps me to think about these things concretely.) =20 Thanks! -- Dave =20 =20 ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm = having trouble=20 understanding recursive types (e.g., as described in Functional = Programming=20 with Overloading and Higher-Order Polymorphism by=20 Jones.

He = gives as an=20 example

> = data Mu f =3D In=20 (f (Mu f))

> = data NatF s =3D=20 Zero | Succ s

> = type Nat =3D Mu=20 NatF

Among = the things I=20 don't get are:

1. Comparing=20 this to the non-higher-order type:

> = data NatX =3D=20 Zero | Succ NatX

What = are the=20 advantages of the higher-order type? What are the disadvantages = (incl.=20 runtime costs)?

2. How are=20 values of type Nat represented? (It helps me to think about these things = concretely.)

Thanks! --=20 Dave

------_=_NextPart_001_01C0E25D.CFC0BA65-- From Tom.Pledger@peace.com Tue May 22 03:24:55 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Tue, 22 May 2001 14:24:55 +1200 Subject: Recursive types? In-Reply-To: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> Message-ID: <15113.52727.506242.598828@waytogo.peace.co.nz> David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | | He gives as an example | | | > data Mu f = In (f (Mu f)) | | > data NatF s = Zero | Succ s | > type Nat = Mu NatF | | Among the things I don't get are: | | 1. Comparing this to the non-higher-order type: | | > data NatX = Zero | Succ NatX | | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e = c k (Tree c k e) -- Contained Tree, container, key, element data Tree c k e = Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t = Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom From luc.taesch@csfb.com Tue May 22 11:19:01 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Tue, 22 May 2001 12:19:01 +0200 Subject: using haxml dynamically Message-ID: <9818339E731AD311AE5C00902715779C0371A779@szrh00313.tszrh.csfb.com> How can i use HaXml to produce xml, but in a dynamic way? i mean : 1) what i understand from the example is - u have a type H in haskell - u derive (manally or with drift) an instance Haskell2xml out of it (defines tocontenst, from contents) - u use it, say with to xml, from xml 2) id like to generate an xml structure computed from some schema works, which means that the structure will be build "dynamically" at run time, ie I wont build the structure from an haskell type, not wont i have an haskell2xml instance at hand. (and i dont want to generate an intermediate haskell file and load/compile it) are there a way to create/fill/describe an xml structure "dynamically", ie as a result of some computation (with haxml, i mean) ? a bit like the example 4 from the paper , fixed with the recent names ? This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ltaesch@europemail.com Tue May 22 22:25:05 2001 From: ltaesch@europemail.com (luc) Date: Tue, 22 May 2001 21:25:05 +0000 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> <15107.31057.395890.996366@tcc2> Message-ID: <3B0AD931.190DCF22@europemail.com> Timothy Docker wrote: for info, there is a gui lib on top of sdl (then portable to linux, win) at http://www.bms-austria.com/projects/paragui/ > Jerzy Karczmarczuk writes: > > [Some interesting points on functional wrappings of graphics libraries] > > Has anyone considered writing a haskell wrapper for SDL - Simple > Directmedia Layer at http://www.libsdl.org ? > > This is a cross platform library intended for writing games, and aims > for a high performance, low level API. It would be interesting to see > how clean a functional API could be built around such an imperative > framework. > > Tim > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From davidbak@microsoft.com Tue May 22 21:16:15 2001 From: davidbak@microsoft.com (David Bakin) Date: Tue, 22 May 2001 13:16:15 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D700190C19@red-msg-07.redmond.corp.microsoft.com> Thank you. Now, on seeing your Tree example I tried to use it by defining height using structural recursion. But I couldn't find a valid syntax to pattern match - or otherwise define the function - on the type CT. Is there one? Or, maybe, are constructor classes the only way to use these types? If that's the case - is that inherent in these types or just the way Haskell does it? Because I was thinking that although you don't know much about these types (e.g., the operations you can perform on k) you should be able to compute height (& size) and leaves :: Tree c k e -> [e] and even replMin on the information that's there in the type. -- Dave -----Original Message----- From: Tom Pledger [mailto:Tom.Pledger@peace.com] Sent: Monday, May 21, 2001 7:25 PM To: haskell@haskell.org Subject: Recursive types? David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | =20 | He gives as an example | =20 | =20 | > data Mu f =3D In (f (Mu f)) | =20 | > data NatF s =3D Zero | Succ s | > type Nat =3D Mu NatF | =20 | Among the things I don't get are: | =20 | 1. Comparing this to the non-higher-order type: | =20 | > data NatX =3D Zero | Succ NatX | =20 | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | =20 | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e =3D c k (Tree c k e) -- Contained Tree, container, key, = element data Tree c k e =3D Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t =3D Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From bhalchin@hotmail.com Tue May 22 22:08:56 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Tue, 22 May 2001 21:08:56 Subject: Haskell & .NET CLR Message-ID: Hello, Are any of the various Haskell implm., e.g. ghc, being targeted for the .NET CLR? Also can anybody point in the direction of any projects to implement the .NET CLR on anything other than Win32 platforms, e.g. that evil Free Software Foundation :^)?? Let's make .NET open source! hehehehhee Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ndalton@ics.uci.edu Tue May 22 22:14:29 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 14:14:29 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: Hi, > Are any of the various Haskell implm., e.g. ghc, being > targeted for the .NET CLR? There is a beta haskell compiler, based on ghc-4.08.1 I believe, at http://www.mondrian-script.org/ I haven't used it, so I can't comment further. > Also can anybody point in the > direction of any projects to implement the .NET CLR on anything > other than Win32 platforms I haven't seen any public projects like that. Would be interesting though.. Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From cwitty@newtonlabs.com Wed May 23 01:19:50 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 17:19:50 -0700 Subject: Templates in FPL? In-Reply-To: "D. Tweed"'s message of "Fri, 18 May 2001 11:22:36 +0100 (BST)" References: Message-ID: "D. Tweed" writes: > In my experience the C++ idiom `you only pay for what you use' (==> > templates are essentially type-checked macros) and the fact most compilers > are evolved from C compilers makes working with templates a real pain in > practice. I'm not sure what you mean by type-checked here. Templates are not type-checked at definition time, but are type-checked when they are used; the same is true of ordinary macros. Carl Witty From trd@cs.mu.OZ.AU Wed May 23 01:22:38 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Wed, 23 May 2001 10:22:38 +1000 Subject: Haskell & .NET CLR In-Reply-To: ; from ndalton@ics.uci.edu on Tue, May 22, 2001 at 02:14:29PM -0700 References:

Message-ID: <20010523102238.A2949@cs.mu.oz.au> > > Also can anybody point in the > > direction of any projects to implement the .NET CLR on anything > > other than Win32 platforms > I haven't seen any public projects like that. Would be > interesting though.. Well, there is: http://www.southern-storm.com.au/ Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working on a C# compiler. See: http://primates.helixcode.com/~miguel/activity-log.html Finally, there was recently an article in Linux Magazine (??? not Linux Journal) about targetting gcc at the .NET CLR. I'm afraid I have no information more than that, since I don't think I can get the magazine in Australia. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From cwitty@newtonlabs.com Wed May 23 02:25:15 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 18:25:15 -0700 Subject: Templates in FPL? In-Reply-To: Jerzy Karczmarczuk's message of "Fri, 18 May 2001 11:25:14 +0200" References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Jerzy Karczmarczuk writes: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) I agree with Marcin about the bad points of templates. (I'd like to point out, though, that the idea that "adding new code can't change the meaning of a program" no longer holds in Haskell extended with overlapping type classes.) > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? There are some very cool things about C++ templates; they are more powerful than you might suspect. (Note: the following summarizes and paraphrases several papers I've read on the topic; let me know if you want more information and I'll look up references for you.) Basically, templates let you extend the compiler. You get a primitive functional programming language, with which you can do basically arbitrary computations on types and on integers; this language can be used to generate special-purpose code. One way to look at this is as a form of partial evaluation (although there's nothing which automatically decides which computation to do at compile time and which at run time). In the functional programming language, you have conditionals, the usual arithmetic operations, pairing, recursion, etc.; basically, it's a real programming language (although a very annoying one -- the syntax is atrocious). Here are a few examples of the kind of thing you can do with C++ templates: * Compute log base 2 at compile time. You can write a template such that if n is a compile-time constant, Log2::val is its log base 2. * Generate FFT routines. You can write a template such that if n is a compile-time constant which is a power of 2, then FFT::do_fft() is a routine which computes an FFT on an array of size n, as a single chunk of straight-line code (no loops). (Not necessarily useful -- it generates a lot of code for reasonable-sized arrays, and cache effects probably mean that something with loops is more efficient -- but cool nonetheless.) * Implement lambda (over a subset of full C++). You can make lambda(X, a*(X+b)) do "the right thing" (basically by arranging for the expression a*(X+b) to have a type like Times > and then writing a function using recursion over this type). These techniques are useful when you're going for speed and generality; I would certainly imagine that such things could be useful in a functional programming language as well. In fact, over the past few weeks, people on the Haskell mailing lists have been trying to do vaguely similar kinds of compile-time computation at the type level, using type classes and functional dependencies. On the other hand, C++ templates have huge flaws for this kind of thing. As I mentioned, the syntax is atrocious; also, there are lots of things you would like to do which are apparently just out of reach (the template language is not quite powerful enough). I'd like to see somebody make a serious effort to add this kind of compile-time processing to Haskell. It might not look anything like templates; something like OpenC++ and OpenJava might be better. (These are C++ and Java compilers which are extensible; you can write compiler extension modules using a standard API, and the compiler dynamically loads your extensions.) There is a big reason why C++ templates (or any other form of compile-time arbitrary computation on types) would be hard to add to Haskell: type inference and polymorphism. For C++ templates, you need to know the argument types before you can do the template processing, and you cannot know the type of the result until the processing is done. Probably this facility would only be useful for monomorphic parts of your program, which might mean it's not appropriate for Haskell at all. Carl Witty From ndalton@ics.uci.edu Wed May 23 04:09:23 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 20:09:23 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: <20010523102238.A2949@cs.mu.oz.au> Message-ID: On Wed, 23 May 2001, Tyson Dowd wrote: > Well, there is: > http://www.southern-storm.com.au/ Interesting, I wish them well. > Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working > on a C# compiler. Well I see from: http://primates.ximian.com/~miguel/cs-compiler.html that his experiment has finished, and I do not think that there is a complete compiler? From the activity log it looks like he got as far as a syntax checker. > Finally, there was recently an article in Linux Magazine (??? not Linux > Journal) about targetting gcc at the .NET CLR. I'm afraid I have no > information more than that, since I don't think I can get the magazine > in Australia. As far as I know, that article was speculating on whether this would be a good idea or not, not reporting on a port of gcc. Regards, Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From bhalchin@hotmail.com Wed May 23 05:27:44 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Wed, 23 May 2001 04:27:44 Subject: Haskell & .NET CLR Message-ID:

Hello Everybody,

The second part of my question pertained only to have a working version of the .NET CLR

running on non-win32 platforms, e.g. Linux.It won't do any good to only having compilers

targeted for .NET CLR if this run-time system and it's libraries only run on win32. Then

darth vadar wins....

Bill

>From: Tyson Dowd

>To: Niall Dalton

>CC: Bill Halchin , haskell@haskell.org

>Subject: Re: Haskell & .NET CLR

>Date: Wed, 23 May 2001 10:22:38 +1000

> > > Also can anybody point in the

> > > direction of any projects to implement the .NET CLR on anything

> > > other than Win32 platforms

> > I haven't seen any public projects like that. Would be

> > interesting though..

>Well, there is:

>http://www.southern-storm.com.au/

>Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working

>on a C# compiler.

>See:

>http://primates.helixcode.com/~miguel/activity-log.html

>Finally, there was recently an article in Linux Magazine (??? not Linux

>Journal) about targetting gcc at the .NET CLR. I'm afraid I have no

>information more than that, since I don't think I can get the magazine

>in Australia.

>--

> Tyson Dowd #

> # Surreal humour isn't everyone's cup of fur.

> trd@cs.mu.oz.au #

>http://www.cs.mu.oz.au/~trd #

Get your FREE download of MSN Explorer at http://explorer.msn.com

From ndalton@ics.uci.edu Wed May 23 05:35:03 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 21:35:03 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: > The second part of my question pertained only to have a working version > of the .NET CLR running on non-win32 platforms, e.g. Linux.It won't do Well you will need compilers as part of that to convert the MSIL into executable code. As I understand it there are several compilers in Microsoft's .NET implementation. A 'pre-jit' that is used as an install time compiler, a typical jit used at runtime and perhaps an optimizing compiler as well. Unfortunately I don't know much about the optimizing compiler plans, nor how things like the ssa stuff in the IL will be safely used. Perhaps we should move this conversation off the haskell list, as we drifted rather far off topic.. niall From simonpj@microsoft.com Wed May 23 08:53:55 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 23 May 2001 00:53:55 -0700 Subject: Haskell & .NET CLR Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond.corp.microsoft.com> | Are any of the various Haskell implm., e.g. ghc, being=20 | targeted for the .NET CLR?=20 Yes, we are, here in Cambridge. We've run some Haskell programs on the CLR already, but it's not nearly ready for release. =20 Simon From Jbkim1078@aol.com Wed May 23 10:59:15 2001 From: Jbkim1078@aol.com (Jbkim1078@aol.com) Date: Wed, 23 May 2001 05:59:15 EDT Subject: Tutor for Haskell is Wanted Message-ID: Hello, I am Yoon, a student of UNSW in Sydney,Australia. I am learning Haskell but need a lot of help for the course. Is there any way that I can get a private tutor? Thanks very much. From sk@mathematik.uni-ulm.de Wed May 23 13:55:16 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 23 May 2001 14:55:16 +0200 Subject: Dependent types (Was: Re: BAL paper available) In-Reply-To: ; from C.T.McBride@durham.ac.uk on Wed, May 16, 2001 at 01:03:25PM +0100 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <20010523125516.21796.qmail@thales.mathematik.uni-ulm.de> C T McBride schrieb folgendes am Wed, May 16, 2001 at 01:03:25PM +0100: > On Wed, 16 May 2001, Stefan Karrmann wrote: > > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > ... you really need types that > > > depend on parameters (in particular, integer parameters). This is, > > > indeed, a problem--currently, you have to do runtime checks. > > > > > > Full-fledged dependent types à la Cayenne are undecidable, but there > > > are weaker variants that are likely to be good enough. > > > > What are the weaker variants? Do you know some references? > > Are they still decidable? That surprises me. If you allow integer > > arithmetic you can do already all computations (Church). > > The idea that `dependent types are undecidable' is a popular but > understandable misconception arising from a particular design decision in > a particular system---Cayenne. > > Dependent types as found in proof systems such as Coq and Lego do have > decidable typechecking: programs may only use structural recursion, and > hence all the evaluation which takes place during typechecking is > guaranteed to terminate. However, in order to support real programming, > Cayenne allows general recursion: as it makes no distinction between the > programs which are executed at compile-time and those only executed at > run-time, undecidability creeps in. Understandably, neither horn of this > dilemma is particularly attractive to programmers who want to combine > flexibility at run-time with a genuinely static notion of typechecking. With constructor type we can do dimension checking, as shown earlier on this list. Can't we check in a similiar way an integer paramter? But is this general enough? You may compute some integer n and then do some calculations in Z/n. How can this be done? Do you need to do the calculation only with structural recursion? > (Of course, post-98 Haskell with certain type class options selected has a > type-level language containing non-terminating programs, making > typechecking undecidable for exactly the same reason as in Cayenne.) If possibly non-terminating type analysis creeps into Haskell, why don't we choose the Cayenne style? > However, there is a middle way: we can distinguish compile-time programs > from run-time programs and restrict the former to the structurally > recursive fragment, leaving general recursion available in the latter. Is there any (syntactical) proposal somewhere? -- Stefan Karrmann From luc.taesch@csfb.com Wed May 23 17:08:49 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Wed, 23 May 2001 18:08:49 +0200 Subject: creating xml doc with haxml Message-ID: <9818339E731AD311AE5C00902715779C0371A7AC@szrh00313.tszrh.csfb.com> i understand now how to filter existing xml doc with haxml. but what about creation from scratch ? if i have myCFel = mkElem "tag" [(literal "value")] myel is a CFilter, not an element so i i want to create a effective element ( to pass to putStrLn . render $ ppContent for instance), i should give it something to filter, like emptyContent = CString False "" to finally do myel = mylit emptyContent . are there any other way to use combinator for creating a structure ( as opposed to "operate on an existing structure")? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From fjh@cs.mu.oz.au Wed May 23 17:35:07 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 24 May 2001 02:35:07 +1000 Subject: Templates in FPL? In-Reply-To: References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <20010524023506.A14295@hg.cs.mu.oz.au> On 22-May-2001, Carl R. Witty wrote: > > I agree with Marcin about the bad points of templates. Me too. Marcin summed it up very well. Of the five disadvantages that he mentioned, I think at least three (lack of explicit interfaces, incredibly complicated rules about name lookup, and very poor error messages) are very serious problems. For an example of the problems caused by the lack of explicit interfaces, the C++ standards committee has still not agreed on what the interface to vector is. The standard is contradictory, because the vector specialization doesn't obey the rules specified for vector, and as yet there's no concensus about which should be changed. For an example of the problems caused by the complicated rules about name lookup, just today someone posted a bug report for gcc 2.95.* to gcc@gcc.gnu.org, reporting a problem where one of the standard library templates didn't work when they had a typedef named `destroy' in their code. My guess is that it was probably because the standard library code was using the function std::destroy(), but the standard library implementor didn't realize that it had to be explicitly namespace qualified; in other words, the rules were too complex and/or too cumbersome for the standard library developer to understand and/or apply. Marcin already posted a good example of a poor error message ;-) > (I'd like to > point out, though, that the idea that "adding new code can't change > the meaning of a program" no longer holds in Haskell extended with > overlapping type classes.) Yes... hence overlapping type classes are EVIL! ;-) ;-) ;-) ;-) > There are some very cool things about C++ templates; they are more > powerful than you might suspect. > > Basically, templates let you extend the compiler. You get a primitive > functional programming language, with which you can do basically > arbitrary computations on types and on integers; > In the functional programming language, you have conditionals, the > usual arithmetic operations, pairing, recursion, etc.; basically, it's > a real programming language (although a very annoying one -- the > syntax is atrocious). Right. It wasn't designed for that purpose, it just turned out that it could be used for it. It's a bit like that simulation of Conway's game of life in vi macros! Makes for a very impressive demo, but there are serious drawbacks to using such techniques in day-to-day work. I agree that it would be very nice if Haskell and other FPLs had some equivalent feature, with a nicer syntax. I think you might be able to do a lot of it using ordinary Haskell syntax with just some additional annotation that directs the compiler to evaluate part of the program at compile time. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From karczma@info.unicaen.fr Wed May 23 17:46:02 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 23 May 2001 18:46:02 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> <20010524023506.A14295@hg.cs.mu.oz.au> Message-ID: <3B0BE94A.76CB56FE@info.unicaen.fr> Fergus Henderson : > I agree that it would be very nice if Haskell and other FPLs had some > equivalent feature, with a nicer syntax. I think you might be able to > do a lot of it using ordinary Haskell syntax with just some additional > annotation that directs the compiler to evaluate part of the program at > compile time. Actually, whole my posting was driven by that. (And by Clean macros which are not macros, but not yet templates, and by the fact that you can parameterize templates with constants, and Haskell classes not). Yours anwers, very thorough, concentrated sometimes on the realization of templates in C++, and I am the last to defend them, or to want to see them implemented in Haskell. But, as a - not too run-time-expensive way to deal with some facets of polymorphism by compiling specialized functions, it is a possible option. The syntactic issues, and the relation of these "macros" to class system is another story. Thanks. Jerzy Karczmarczuk Caen, France From brent.fulgham@xpsystems.com Wed May 23 22:56:19 2001 From: brent.fulgham@xpsystems.com (Brent Fulgham) Date: Wed, 23 May 2001 14:56:19 -0700 Subject: Cygwin Build Bug (Probably Affects other GNU GLIBC Builds) Message-ID: For thread-safety reasons, the GNU C Library (2.2+) defines "errno" as a macro that calls a function to get the errno of the current thread. Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs to include the header file, rather than declaring an extern variable. Diff: ========================================================================== *** cIOExtras.old.c Wed May 23 14:54:58 2001 --- cIOExtras.c Wed May 23 14:26:54 2001 *************** *** 1,10 **** /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! extern int errno; int getErrNo (void) { return errno; } --- 1,11 ---- /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" + #include "errno.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! /*extern int errno;*/ int getErrNo (void) { return errno; } From jcab@roningames.com Thu May 24 03:18:32 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Wed, 23 May 2001 19:18:32 -0700 Subject: Templates in FPL? In-Reply-To: <20010524023506.A14295@hg.cs.mu.oz.au> References:

<3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: > > Basically, templates let you extend the compiler. You get a primitive > > functional programming language, with which you can do basically > > arbitrary computations on types and on integers; > > In the functional programming language, you have conditionals, the > > usual arithmetic operations, pairing, recursion, etc.; basically, it's > > a real programming language (although a very annoying one -- the > > syntax is atrocious). > >Right. It wasn't designed for that purpose, it just turned out >that it could be used for it. It's a bit like that simulation of >Conway's game of life in vi macros! Makes for a very impressive >demo, but there are serious drawbacks to using such techniques in >day-to-day work. :) So true. In some ways, it sounds great: here we have a useful general-purpose feature that you can use for all kinds of things (a programming Swiss army knife, so to speak), and then build all kinds of _concrete_ useful things with it. Problem is that it doesn't allow you to redefine the syntax in any way. Thus, you can do compile-time assertions, computations, things like that, but the meaning of what you want to do often gets quite obfuscated by this syntax and by the contrived compiler error messages. I must say, though, that the beta compiler of MSVC 7 does a MUCH improved work on it. >I agree that it would be very nice if Haskell and other FPLs had some >equivalent feature, with a nicer syntax. I think you might be able to >do a lot of it using ordinary Haskell syntax with just some additional >annotation that directs the compiler to evaluate part of the program at >compile time. This is close to my personal vision. That is, a language that handles both run-time and compile-time computations seamlessly. Thus, the compiler would evaluate as much as it can, and then what's left is put in the executable. I assume that's something optimizing compilers for Haskell already do, at least in part. Problem is that, ideally, the language should allow the programmer to be explicit about things that should be done at compile-time and things that should be done at run-time, which Haskell doesn't quite have. Let's see how this could work: - IO actions must be executed at run-time, evidently. - We might be able to define another action monad (let's call it "CT", for compile-time) which defines just the opposite: an action that must be executed by the compiler. - We'd need a new primitive function: executeCompilerAction :: CT a -> a - And we'd need another: compilerEval :: a -> CT a So, let's say we want to force this program: main = print (fact 1000) to evaluate the factorial expression at compile-time. Then, we'd write something like: main = print (executeCompilerAction (compilerEval (fact 1000))) Of course, we'd eventually define any useful recurring patterns as new functions, as in here: eval a = executeCompilerAction (compilerEval a) Anyway, I don't know if I'm making much sense here. Just letting my brains fly on their own. Then, there's the explicit handling of types which templates allow and Haskell doesn't. I think that, the hardest part of Haskell that I'm having trouble with here is the way overloading is defined, using classes. I still have problems with that. Some times it is really obvious that it's best. Some other times, it really doesn't seem to fit (finding about the multi-parameter class extension was a very gratifying moment there). I can think of something that I don't know how to do in Haskell. Suppose that I have two classes, which I'll call Class1 and Class2: class Class1 a where func1 :: a -> Bool class Class2 a where ... (doesn't matter what goes here) And say that I want to express the fact that ALL types that are instances of Class2 will ALWAYS be instances of Class1, and will always return "False" from "func1". So, is there any way to express this kind of class-relationship in Haskell? It's not definitely inheritance, I think. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From simonmar@microsoft.com Thu May 24 10:02:43 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 24 May 2001 10:02:43 +0100 Subject: I/O buffering (was: Endangered I/O operations) Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115893@TVP-MSG-01.europe.corp.microsoft.com> [ moved from glasgow-haskell-users to haskell@haskell.org ] Carl Witty writes: > If the report does not allow the implementation to flush buffers at > any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be "returned to the file" (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that "Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer". What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon > I would much rather > use an implementation where stdout and stderr came out in the right > order, and reading from stdin flushed stdout. (As another example, an > implementation might want to flush all buffers before doing a fork(), > to avoid duplicated output.) >=20 > The only caveat is that if such flushing is allowed but not required, > it might encourage writing sloppy, nonportable code. >=20 >=20 >=20 From Dominic.J.Steinitz@BritishAirways.com Thu May 24 10:45:54 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 09:45:54 Z Subject: Building Programs Message-ID: <"04B7D3B0CD852002*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> What's the recommended way of building a system consisting of many Haskell modules? Should I use hmake, make or is there some other preferred mechanism in the Haskell world? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonpj@microsoft.com Thu May 24 11:06:41 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 24 May 2001 03:06:41 -0700 Subject: Building Programs Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> It depends on which implementation you have.=20 hmake is good, and is independent of implementation. ghc 5.0 has a make system built in, so you can say ghc --make Main to build your program. Or=20 ghc --interactive Main to run it interactively. Hugs also follows module dependencies automatically. hbc had a similar mechanism I think. =20 Simon | -----Original Message----- | From: Steinitz, Dominic J=20 | [mailto:Dominic.J.Steinitz@BritishAirways.com]=20 | Sent: 24 May 2001 10:46 | To: haskell | Subject: Building Programs |=20 |=20 | What's the recommended way of building a system consisting of=20 | many Haskell modules? Should I use hmake, make or is there=20 | some other preferred mechanism in the Haskell world? |=20 | Dominic. |=20 | -------------------------------------------------------------- | ----------------------------------- | 21st century air travel http://www.britishairways.com |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From v-julsew@microsoft.com Thu May 24 13:57:06 2001 From: v-julsew@microsoft.com (Julian Seward (Intl Vendor)) Date: Thu, 24 May 2001 05:57:06 -0700 Subject: ghc-5.00.1 is available Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.00.1. The source distribution is freely available via the World-Wide Web and through anon. FTP, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, and Solaris(sparc) are also available. Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.00.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is a bug-fix release. Most reported bugs in 5.00 have been fixed, including a substantial number of show-stopping bugs. The system should be much more usable for more people. Upgrading to 5.00.1 is recommended. To all those who tried out 5.00 and reported bugs, we thank you for your feedback and patience. At the moment there is no Win32 build of 5.00 or 5.00.1 available. We decided to push Win32 support to the 5.02 release, so as not to delay 5.00.1 any further. What's new in 5.00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.00 has been majorly revamped since the previous stable version, 4.08.2. This should be a stable release. Major changes since 4.08.2 are: - An interactive system, similar in style to Hugs. You can interactively load and unload modules, run expressions, ask the types of things. Module dependencies are tracked and chased automatically. Combinations of compiled and interpreted modules may be used. All the GHC libraries are available in interactive mode, as are most of the Glasgow extensions to Haskell 98. Compilation in interactive mode (to bytecode) is about three times faster than compiling to object code. - Batch compilation of multiple modules at once, with automatic dependency chasing. For large programs this can halve compilation times, and removes the need for Makefiles. - Enhanced package (library) management system. Packages may be installed and removed from an installation using the ghc-pkg tool. - Initial Unicode support - the Char type is now 31 bits. - Sparc native code generator, giving much faster compilation on sparcs. (Native code generation for x86s has been available for a while). - Improved heap profiling - you can restrict heap profiles by type, closure description, cost centre, and module. - Support for the latest Foreign Function Interface (FFI) proposals. Marcin Kowalczyk's hsc2hs tool is included. - Language extensions: parallel list comprehensions and functional dependencies. - The usual huge collection of bug fixes. Most reported bugs have been fixed. For full details see the release notes: http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html How to get it =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in .rpm/.deb form for all you Linux junkies out there, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To compile programs with GHC, you need a machine with 32+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * alpha-dec-osf{2,3} * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/5.00/building/building-guide.html Mailing lists =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org; GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding edge CVS users party on cvs-ghc@haskell.org. From Malcolm.Wallace@cs.york.ac.uk Thu May 24 15:34:08 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Thu, 24 May 2001 15:34:08 +0100 Subject: Building Programs In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> Message-ID: > What's the recommended way of building a system consisting of > many Haskell modules? Should I use hmake, make or is there > some other preferred mechanism in the Haskell world? As Simon PJ already mentioned, hmake is entirely platform independent, so if there is any likelihood that you may need to change between Haskell compilers, or to distribute your software in a portable source form, it is probably the top option. But for quick hacking, or non-portable software using language extensions, individual compiler mechanisms such as Hugs' import chasing, ghc --make, and hbcmake, are just as good. Writing Makefiles is the least attractive option, even though they have good portability, because they are clunky and it is tricky to keep them synchronised with the true source dependencies. However, I think even when using hmake or ghc --make, you are likely to end up writing a small and simple Makefile anyway. Regards, Malcolm From Dominic.J.Steinitz@BritishAirways.com Thu May 24 18:47:42 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 17:47:42 Z Subject: ghc-5.00.1 is available Message-ID: <"04CAB3B0D493E00E*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From avv@quasar.ipa.nw.ru Thu May 24 19:11:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 11:11:41 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <3B0D4EDD.968E297C@quasar.ipa.nw.ru> Hi All, Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander From ashley@semantic.org Thu May 24 22:41:21 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 24 May 2001 14:41:21 -0700 Subject: Unicode Message-ID: <200105242141.OAA15819@mail4.halcyon.com> At 2001-05-24 05:57, Julian Seward (Intl Vendor) wrote: > - Initial Unicode support - the Char type is now 31 bits. It might be appropriate to have two types for Unicode, a UCS2 type (16 bits) and a UCS4 type (31 bits). For instance, something like: -- newtype UCS2CodePoint = MkUCS2CodePoint Word16 newtype UCS4CodePoint = MkUCS4CodePoint Word31 type Char = UCS4CodePoint toUCS4 :: UCS2CodePoint -> UCS4CodePoint fromUCS4 :: UCS4CodePoint -> Maybe UCS2CodePoint encodeUTF16 :: [UCS4CodePoint] -> Maybe [UCS2CodePoint] decodeUTF16 :: [UCS2CodePoint] -> Maybe [UCS4CodePoint] -- -- Ashley Yakeley, Seattle WA From Dominic.J.Steinitz@BritishAirways.com Thu May 24 22:48:11 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 21:48:11 Z Subject: ghc-5.00.1 is available Message-ID: <"046603B0D819B004*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From qrczak@knm.org.pl Thu May 24 23:04:22 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 24 May 2001 22:04:22 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: >> - Initial Unicode support - the Char type is now 31 bits. > > It might be appropriate to have two types for Unicode, a UCS2 type > (16 bits) and a UCS4 type (31 bits). Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char is '\x10FFFF' now. Among encodings of Unicode in a stream of bytes there are UTF-8, UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and UCS4 are obsolete: there is a single code space 0..0x10FFFF and various ways to serialize characters. Ghc is going to support conversion between internal Unicode and some encodings for external byte streams. Among them there will be UTF-{8,16,32} (with endianness variants), all treated as streams of bytes. There is no point in storing characters in UTF-16 internally. Especially in ghc where characters are boxed objects, and Word16 is represented as a full machine word (32 or 64 bits). UTF-16 will be supported as an external encoding, parallel to ISO-8859-x etc. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From miketh@brisbane.paradigmgeo.com Fri May 25 03:36:19 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 12:36:19 +1000 Subject: a cygwin binary package of ghc-5.00.x References: Message-ID: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Hi. > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > Thank you in advance > > > > Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas. From avv@quasar.ipa.nw.ru Fri May 25 04:10:15 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 20:10:15 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Message-ID: <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Hi Mike, Thank you very much for the reply. After having asked I managed to build ghc-5.00.1, and almost succeeded in the rest, till the place where it failed to invoke ghc-asm (or so, I don't remember, it's on a different machine). It's not impossible that I understand how to fix it (it was just before I went home). I use normal latest cygwin installation, binary installation of ghc-4.08, and tell i686-pc-mingw32 to the configure of ghc. Looks like it's impossible to build it for the full cygwin (but does anybody care?) and also I failed to --enable-win32-dlls (that is _it_ failed, not me :-); it stopped at something like Main.dll_o. During the build I was really scared looking at the resident sizes of the compiler process, which is an ordinary haskell application, with its most adequate application domain. Does it mean that my _real_ programs would expose the same? Alexander Mike Thomas wrote: > > Hi. > > > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > > > Thank you in advance > > > > > > Alexander > > I have one, which uses the Mingw standalone GCC compiler for Windows. It > seems to be capable of compiling itself. > > Problems: > > 1. It is not in an installer - you would have to hand patch the package file > and install by hand. > > 2. It is not supported by anyone and is non-standard in the way it uses > Mingw32. > > 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 > though). > > 4. I haven't bootstrapped GHCi, yet (maybe by next week). > > 5. It is only GHC 5.00, not 5.00.1. (maybe next week). > > 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) > yourself. > > 7. It is very big, mainly because of the profiled libraries. > > 8. I don't have an FTP site to put it. > > 9. It doesn't do dynamic libraries, only static. > > etc. > > Unless you're desperate, I suggest waiting for the official release. > > Cheers > > Mike Thomas. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From miketh@brisbane.paradigmgeo.com Fri May 25 07:09:13 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 16:09:13 +1000 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Message-ID: <005801c0e4e1$3c061520$0cb4a8c0@brisbane.paradigmgeo.com> Hi there. > I use normal latest cygwin installation, > binary installation of ghc-4.08, and tell i686-pc-mingw32 to the > configure of ghc. Same here, except I used the standalone Mingw, which meant that I had to alter certain parts of the makefile which relied on Cygwin links (in the gmp library), and alter the parameters sent to GCC. > Looks like it's impossible to build it for the full > cygwin (but does anybody care?) I certainly don't ! > and also I failed to --enable-win32-dlls > (that is _it_ failed, not me :-); it stopped at something like > Main.dll_o. I haven't tried that option yet, as there is apparently a bug in Mingw for large heaps when linked dynamically. > During the build I was really scared looking at the resident sizes of > the compiler process, which is an ordinary haskell application, with its > most adequate application domain. Does it mean that my _real_ programs > would expose the same? Yeah, it's pretty big, but I guess that not all programs use as much memory as a compiler. Good luck. Mike Thomas. From simonpj@microsoft.com Fri May 25 08:01:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 25 May 2001 00:01:22 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 working here, but we are trying to get the packaging right so that it doesn't require Cygwin etc.=20 If you want to build it from source, you might want to wait for Reuben to put up the 4.08 download he's about to distribute. I have myself used this download to compile the head from source yesterday, so I know it works! Simon | -----Original Message----- | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 | Sent: 24 May 2001 19:12 | To: haskell@haskell.org | Subject: a cygwin binary package of ghc-5.00.x |=20 |=20 | Hi All, |=20 | Do anybody have one? I failed to recompile it with ghc 4.08.x. |=20 | Thank you in advance |=20 | Alexander |=20 |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From Dominic.J.Steinitz@BritishAirways.com Fri May 25 11:35:06 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 10:35:06 Z Subject: IO Errors Message-ID: <"03C413B0E355A011*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can anyone tell me why this behaves as it does? In Hugs, I get C:\My Documents\functional\ldapsck1\buffer.hs Main> main Illegal operation (561 reductions, 1029 cells) Main> If the input file is the one line: 1234567812345678 the output file is: Starting logging 1234567812345678 Error In ghc, the program hangs without even creating a file. Dominic import IO main :: IO () main = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" ifh <- openFile "tst.txt" ReadMode let loop = do b <- try (getBuffer ifh 16) case b of Right msg -> do logMessage ofh msg loop Left e -> if isEOFError e then do logMessage ofh "Finishing logging" hClose ofh else do logMessage ofh "Error" ioError e in loop logMessage :: Handle -> String -> IO () logMessage hd msg = do hPutStrLn hd msg hFlush hd getBuffer :: Handle -> Int -> IO String getBuffer h n = if (n <= 0) then return "" else do c <- hGetChar h cs <- getBuffer h (n-1) return (c:cs) ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From ltaesch@europemail.com Fri May 25 14:34:22 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 13:34:22 +0000 Subject: combinators Message-ID: <3B0E5F5E.4541CF5@europemail.com> beyond specific combinator tutorial, are there any generic combinator paper, or introductory ones ? thks Luc From joe@isun.informatik.uni-leipzig.de Fri May 25 12:56:39 2001 From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann) Date: Fri, 25 May 2001 13:56:39 +0200 (MET DST) Subject: combinators In-Reply-To: <3B0E5F5E.4541CF5@europemail.com> from luc at "May 25, 2001 01:34:22 pm" Message-ID: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> > beyond specific combinator tutorial, are there any generic combinator > paper, or introductory ones ? what exactly do you mean by "combinator". there's the recent area of parser combinators and such, but there's also Combinatory Logic in itself, which is a formal system closely related to the lambda calculus. a nice introduction is here: http://uq.net.au/~zzdkeena/Lambda/index.htm which is based on the "ornithology" from here: Smullyan, R.M. (1985) To mock a mockingbird. Alfred A. Knopf, New York. of course, the definitive references on Comb. L. and Lambda Calc. are the books by Curry, Feys, Hindley, Seldin, Barendregt (check your library). beware that the classical theory (as expressed in these books) is mostly un-typed (you can apply anything to anything). enjoy, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 -- From simonmar@microsoft.com Fri May 25 12:49:16 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Fri, 25 May 2001 12:49:16 +0100 Subject: IO Errors Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD709@TVP-MSG-01.europe.corp.microsoft.com> > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon From action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee Fri May 25 12:47:30 2001 From: action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee (Marjan Mernik) Date: Fri, 25 May 2001 13:47:30 +0200 Subject: CFP: LDTA'2002 Message-ID: <3B0E4652.3F402DE1@uni-mb.si> [apologies if you receive multiple copies of this message] ----------------------------------------------------------- 2nd Workshop on Language Descriptions, Tools and Applications LDTA'2002 Affiliated with ETAPS'2002 April 13, 2002 Grenoble, France The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications of these language definitions and tools developed for or with these language definitions. For call for papers and additional information please check the following URL: http://www.cwi.nl/conferences/LDTA2002 Schedule Submission of full paper December 15, 2001 Notification January 31, 2002 Final version due February 28, 2002 From ltaesch@europemail.com Fri May 25 15:17:14 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 14:17:14 +0000 Subject: combinators References: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> Message-ID: <3B0E696A.7BCF46A0@europemail.com> Johannes Waldmann wrote: > > beyond specific combinator tutorial, are there any generic combinator > > paper, or introductory ones ? > > what exactly do you mean by "combinator". > there's the recent area of parser combinators and such, well, i didnt knew it was new, but , yes, that's it. ive read some paper on parser combinator, and as im working with haxml, id like to have some of my stuuf done in the same style, then i realize i had a tendency to design function that reacted on data (itself), rather than combinators. (probably too mucj of "old stuff in my head ;-) so i would like to backstep , and look at combinator as such , and not applied in a given context (liker parser or haxml)) which example i can understand, but not easily change my style of programming accordingly. so, reformulation : has anyone know a paper like : "change ure mindset from data oriented programming to combinators one " ? > > > but there's also Combinatory Logic in itself, > which is a formal system closely related to the lambda calculus. is this then relevnt for me to look t that, in the light of my previous explanation ? From ketil@ii.uib.no Fri May 25 15:34:41 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 25 May 2001 16:34:41 +0200 Subject: Templates in FPL? In-Reply-To: Juan Carlos Arevalo Baeza's message of "Wed, 23 May 2001 19:18:32 -0700" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Juan Carlos Arevalo Baeza writes: > At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: >> I agree that it would be very nice if Haskell and other FPLs had some >> equivalent feature, with a nicer syntax. I think you might be able to >> do a lot of it using ordinary Haskell syntax with just some additional >> annotation that directs the compiler to evaluate part of the program at >> compile time. > This is close to my personal vision. That is, a language that handles both > run-time and compile-time computations seamlessly. Thus, the compiler would > evaluate as much as it can, and then what's left is put in the > executable. I must be missing something crucial here - I thought that was exactly what GHC did? I've certainly had it optimize toy benchmarks completely away... Could somebody elucidate, please? Of course, having annotations to hint about specialization might be a good thing. Perhaps this could be profiled and fed back to the compiler? ISTR this is common for the SPEC benchmarks (in C or Fortran, I presume) > Problem is that, ideally, the language should allow the programmer to > be explicit about things that should be done at compile-time and things that > should be done at run-time, which Haskell doesn't quite have. Why/when do you need this? I would go for -O implying optimizing away as much as possible (i.e all constant expressions), and else no optimization (for compilation speed). -kzm -- If I haven't seen further, it is by standing in the footprints of giants From Dominic.J.Steinitz@BritishAirways.com Fri May 25 17:09:05 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 16:09:05 Z Subject: IO Errors Message-ID: <"019E13B0E83A103F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Simon, I (stupidly) called the executable logger and then presumably invoked something on linux of the same name. Giving it a different name gave the same result as you got. I assume this is a bug in hugs and I will refer it to that mailing list. Dominic. simonmar@microsoft.com on 25/05/2001 13:03:00 To: Dominic Steinitz haskell cc: bcc: Subject: RE: IO Errors > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From fjh@cs.mu.oz.au Fri May 25 18:17:40 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 26 May 2001 03:17:40 +1000 Subject: Unicode In-Reply-To: References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: <20010526031740.A27447@hg.cs.mu.oz.au> On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > (16 bits) and a UCS4 type (31 bits). > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > is '\x10FFFF' now. > > Among encodings of Unicode in a stream of bytes there are UTF-8, > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > various ways to serialize characters. > > Ghc is going to support conversion between internal Unicode and > some encodings for external byte streams. Among them there will be > UTF-{8,16,32} (with endianness variants), all treated as streams > of bytes. > > There is no point in storing characters in UTF-16 internally. > Especially in ghc where characters are boxed objects, and Word16 is > represented as a full machine word (32 or 64 bits). UTF-16 will be > supported as an external encoding, parallel to ISO-8859-x etc. What about for interfacing with Win32, MacOS X, or Java? Your talk about "external" versus "internal" worries me a bit, since the distinction between these is not always clear. Is there a way to convert a Haskell String into a UTF-16 encoded byte stream without writing to a file and then reading the file back in? -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jcab@roningames.com Fri May 25 18:45:59 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Fri, 25 May 2001 10:45:59 -0700 Subject: Templates in FPL? In-Reply-To: References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: <4.3.2.7.2.20010525104210.02f0cfd8@207.33.235.243> At 04:34 PM 5/25/2001 +0200, Ketil Malde wrote: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > >I must be missing something crucial here - I thought that was exactly >what GHC did? I don't presume to know what GHC does. After all, Haskell was completely unknown to me three months ago. O:-) I did hope that was the case, though: "I assume that's something optimizing compilers for Haskell already do, at least in part". > > Problem is that, ideally, the language should allow the programmer to > > be explicit about things that should be done at compile-time and things > that > > should be done at run-time, which Haskell doesn't quite have. > >Why/when do you need this? I would go for -O implying optimizing away >as much as possible (i.e all constant expressions), and else no >optimization (for compilation speed). Oh, there are several reasons for the programmer to make her wishes clear to the compiler. Especially when having something NOT calculated at compile time is not acceptable. In that case, you want the compiler to return an error, instead of emitting the runtime calculations. A silly example of this that comes to mind is non-converging calculations. Say we have a wrong factorial function: tcaf 0 = 1 tcaf n = n * tcaf (n+1) Pass this program through GHC: main = print (tcaf 3) Will it evaluate "tcaf 3" at compile-time? Will it error-out at compile-time? I don't have the compiler here (I'm writing from work, but I'm trying Haskell out at home). My guess would be that GHC will evaluate as much as it can, and leave the rest for the run-time program. Specifically, the best I'd expect it to do is to lessen the recursion by expanding several levels of it. For example, for two levels, it'd be reduced to: tcaf = (\n -> case n of 0 = 1; -1 = -1; _ = n * (n+1) * tcaf (n+2)) Of course, I might be completely wrong here. I don't think it'd be terribly hard for the compiler to deduce that a function like this, called with a positive argument, is never going to finish evaluating. But in more complex cases, it might not be possible for the compiler to know. Then again, GHC might actually be evaluating EVERYTHING that doesn't depend on IO actions... without exception... This brings me to a question. What would a good optimizing compiler (GHC) do in this case: main = do num <- return 3 print (tcaf num) I'll be trying all these things tonight. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From avv@quasar.ipa.nw.ru Fri May 25 19:14:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Fri, 25 May 2001 11:14:41 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B0EA111.A4A2821@quasar.ipa.nw.ru> Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >= 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one > working here, but we are trying to get the packaging right > so that it doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for > Reuben to put up the 4.08 download he's about to distribute. > I have myself used this download to compile the head from > source yesterday, so I know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From taha@cs.yale.edu Fri May 25 19:29:44 2001 From: taha@cs.yale.edu (Walid Taha) Date: Fri, 25 May 2001 14:29:44 -0400 (EDT) Subject: NEPLS In-Reply-To: <200105251821.OAA16140@bosch.cs.brown.edu> Message-ID: Dear all, If you want to be added to the NEPLS page, please send ME your email and I'll forward it to Shriram. Cheers, Walid. On Fri, 25 May 2001, Shriram Krishnamurthi wrote: |Hi Walid, | |You were never on the mailing list (for reasons that escape me). You |are now. | |Do me a favor. Send mail around to the programming languages people |at Yale asking whether they'd like to be on the list. Find someone to |collect all these names and send them to me in a single message, |line-at-a-time (usual mail alias file format). I'll take care of |including y'all. If the name's not obvious from the email address, |please also include the full name in the usual mail format: | | "Walid Taha" | |Btw, the only cs.yale.edu addresses currently on the list are | | Walid Taha | hudak@cs.yale.edu | shao-zhong@cs.yale.edu | carsten@cs.yale.edu | |League and Courtney are on through other hostnames. Maybe I'm missing |a few others. | |Thanks. | |Shriram | From Roger McKenssy" We are looking for new faces for TV & Movie productions. All ages and looks. All countries. If you are interested, Please email or fax us your: ---------------------------------------------- -Name: -Age: -Country: -City: -email address: ---------------------------------------------- If your email reply gives you a delivery error, please use Fax nr 1-309-276-9964 to ensure that we get your message. Please reply only if TV, movie or modeling is of an interest to you. We hope you understand that we are trying to get ONLY serious people who really want to try and like the camera. Feel free to pass this email to a friend or a family member who maybe interested. There is absolutely no payment of any form required from your side. On the oposite, all jobs we offers are well paid. You'll be contacted for an online interview as soon as we can. Best Regards, Roger McKenssy Fax nr 1-309-276-9964 ------------------------------- This email is sent to you in full compliance with all existing and proposed email legislation. Note: You are not on a mailing list, and this is a one-time email. If we don't get an answer, you'll never hear from us any more. You are removed by default. You can still reply with the word Remove in the subject. This right is yours by law. Use Fax nr 1-309-276-9964 From cwitty@newtonlabs.com Fri May 25 19:33:37 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 25 May 2001 11:33:37 -0700 Subject: Templates in FPL? In-Reply-To: Ketil Malde's message of "25 May 2001 16:34:41 +0200" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Ketil Malde writes: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > > I must be missing something crucial here - I thought that was exactly > what GHC did? I've certainly had it optimize toy benchmarks > completely away... Could somebody elucidate, please? I don't know what GHC does, but there are certainly reasons why you might not want to evaluate everything possible at compile time. For instance, there may be some sort of lookup table which is very large, but is fast to compute at runtime; you might not want to store the large table on disk in your executable. Carl Witty From john@repetae.net Fri May 25 21:12:49 2001 From: john@repetae.net (John Meacham) Date: Fri, 25 May 2001 13:12:49 -0700 Subject: Unicode In-Reply-To: <20010526031740.A27447@hg.cs.mu.oz.au>; from fjh@cs.mu.oz.au on Sat, May 26, 2001 at 03:17:40AM +1000 References: <200105242141.OAA15819@mail4.halcyon.com> <20010526031740.A27447@hg.cs.mu.oz.au> Message-ID: <20010525131249.C18660@mark.ugcs.caltech.edu> The algorithms for encoding unicode characters into the various transport formats, UTF16,UTF8,UTF32 are well defined, they can trivially be implemented in Haskell, for instance encodeUTF8 :: String -> [Byte] decodeUTF8 :: [Byte] -> Maybe String would be easily definable. BTW, since a char is no longer a byte, how about making a standard type Byte = Word8 declaration in a readily accesable and standard place. then we can start revamping the large amounts of legacy code which assume a Char is 8 bits. in particular the POSIX APIs are no good in this respect, as well as many of the example programs out there on the web... John On Sat, May 26, 2001 at 03:17:40AM +1000, Fergus Henderson wrote: > On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > > (16 bits) and a UCS4 type (31 bits). > > > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > > is '\x10FFFF' now. > > > > Among encodings of Unicode in a stream of bytes there are UTF-8, > > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > > various ways to serialize characters. > > > > Ghc is going to support conversion between internal Unicode and > > some encodings for external byte streams. Among them there will be > > UTF-{8,16,32} (with endianness variants), all treated as streams > > of bytes. > > > > There is no point in storing characters in UTF-16 internally. > > Especially in ghc where characters are boxed objects, and Word16 is > > represented as a full machine word (32 or 64 bits). UTF-16 will be > > supported as an external encoding, parallel to ISO-8859-x etc. > > What about for interfacing with Win32, MacOS X, or Java? > Your talk about "external" versus "internal" worries me a bit, > since the distinction between these is not always clear. > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? > > -- > Fergus Henderson | "I have always known that the pursuit > | of excellence is a lethal habit" > WWW: | -- the last words of T. S. Garp. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 25 21:07:25 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 25 May 2001 20:07:25 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> <9emde2$kcv$1@qrnik.zagroda> Message-ID: Sat, 26 May 2001 03:17:40 +1000, Fergus Henderson pisze: > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? Sure: all conversions are available as memory to memory conversions for direct use. My conversion type is parametrized by input and output character types, so you can even define UTF-16 as giving [Word16]. But [Word8] must be used for handles, so I think that in practice conversions are generally between [Char] and [Word8]. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From konsu@microsoft.com Fri May 25 23:47:00 2001 From: konsu@microsoft.com (Konst Sushenko) Date: Fri, 25 May 2001 15:47:00 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <0FA38CF91938AC4F8FDC4960E389D76315D2FF@red-msg-10.redmond.corp.microsoft.com> Alexander, It looks like I had a similar problem with ghc script not being recognised by cygwin, and I assume that ghc-asm is also a perl script. I ended up invoking perl explicitly thus perl -S ghc ... I guess if you do the same with ghc-asm, it will work. Hope this helps Konst -----Original Message----- From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 Sent: Friday, May 25, 2001 11:15 AM To: Simon Peyton-Jones Cc: haskell@haskell.org Subject: Re: a cygwin binary package of ghc-5.00.x Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >=3D 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 > working here, but we are trying to get the packaging right so that it=20 > doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for Reuben > to put up the 4.08 download he's about to distribute. I have myself=20 > used this download to compile the head from source yesterday, so I=20 > know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From leelati@yahoo.com Sat May 26 07:52:31 2001 From: leelati@yahoo.com (Rab Lee) Date: Fri, 25 May 2001 23:52:31 -0700 (PDT) Subject: can anyone help? Message-ID: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Dear Experts, I would appreciate any help that anyone can give me. I'm having a bit of trouble with Haskell, my question is pretty simple and i was wonder if anyone could please tell me how to change a string into a list??? Thank you in advance Leat __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From dscarlett@optushome.com.au Sat May 26 08:05:17 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Sat, 26 May 2001 17:05:17 +1000 Subject: can anyone help? References: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Message-ID: <000701c0e5b2$38140770$0100a8c0@CO3003288A> ----- Original Message ----- From: "Rab Lee" To: Sent: Saturday, May 26, 2001 4:52 PM Subject: can anyone help? > Dear Experts, > I would appreciate any help that anyone can give me. > I'm having a bit of trouble with Haskell, my question > is pretty simple and i was wonder if anyone could > please tell me how to change a string into a list??? > Thank you in advance > Leat > A String is a type of list already........ It is a list of Chars. Could you be a bit more specific as to what you want to do? Do you mean (for example), change a String of digits into a list of Ints? ie. "12345" -> [1,2,3,4,5] From leelati@yahoo.com Sat May 26 08:47:21 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:21 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074721.75623.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From leelati@yahoo.com Sat May 26 08:47:56 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:56 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074756.75644.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From N.Perry@massey.ac.nz Sat May 26 11:33:07 2001 From: N.Perry@massey.ac.nz (Nigel Perry) Date: Sat, 26 May 2001 22:33:07 +1200 Subject: Haskell & .NET CLR In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> Message-ID: At 12:53 am -0700 23/5/01 you wrote: >| Are any of the various Haskell implm., e.g. ghc, being >| targeted for the .NET CLR? You can get a beta version of ghc for .NET from www.mondrian-script.org. A lot, but far from all, or the standard libraries are provided. There is no floating point support (use the Mondrian compiler ;-)). This version of ghc will be superceded by another from a different source... Cheers, Nigel -- Nigel Perry, New Zealand From chak@cse.unsw.edu.au Sat May 26 13:53:43 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sat, 26 May 2001 22:53:43 +1000 Subject: ghc-5.00.1 is available In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> Message-ID: <20010526225343M.chak@cse.unsw.edu.au> "Julian Seward (Intl Vendor)" wrote, > The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 > ============================================================== > > We are pleased to announce a new patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.00.1. There are rpm packages for x86 GNU/Linux now. For glibc 2.2 systems, build on RedHat 7.0, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.1-1.i386.rpm For RedHat 6.2, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.1-1.i386.rpm The matching source rpm is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.1-1.src.rpm The RedHat 6.2 packages have been kindly contributed by Tom Moertel. Cheers, Manuel PS: The problems with the documentation in the 5.00 rpms have been resolved (at least in the RH7.0 packages, I didn't check the others). From ashley@semantic.org Sun May 27 22:18:13 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sun, 27 May 2001 14:18:13 -0700 Subject: (no subject) Message-ID: <200105272118.OAA09091@mail4.halcyon.com> At 2001-05-26 00:47, Rab Lee wrote: >hi, i'm having a bit more touble, can anyone help me >or give me any hints on how to do this : >"x 2 3 4" = ("x", [2, 3, 4]) Generally we don't solve homework for people. Unless they're studying under Prof. Karczmarczuk, of course. -- Ashley Yakeley, Seattle WA From karczma@info.unicaen.fr Mon May 28 09:21:25 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Mon, 28 May 2001 10:21:25 +0200 Subject: Homeworks and art of flying. References: <200105272118.OAA09091@mail4.halcyon.com> Message-ID: <3B120A85.1CCD25F0@info.unicaen.fr> Ashley Yakeley answers the query of Rab Lee: > > >hi, i'm having a bit more touble, can anyone help me > >or give me any hints on how to do this : > >"x 2 3 4" = ("x", [2, 3, 4]) > > Generally we don't solve homework for people. Unless they're studying > under Prof. Karczmarczuk, of course. > > -- > Ashley Yakeley, Seattle WA Now, now, this is cruel and ati-pedagogical. I changed my mind, we should all be friends, and help each other. Here is the ideal solution, very fast, and protected against viral contamination homework "x 2 3 4" = ("x", [2, 3, 4]) homework _ = error "You can't" Note the cleverness and universalness of the solution. Jerzy Karczmarczuk Caen, France PS. A deep philosophical quotation seems appropriate here. Here is one from Douglas Adams: Flying is an art, or rather a knack. The knack consists in throwing oneself to ground, and miss. From simonpj@microsoft.com Mon May 28 09:31:56 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 28 May 2001 01:31:56 -0700 Subject: (no subject) Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FAD@red-msg-09.redmond.corp.microsoft.com> This looks like a good thread to move to haskell-cafe@haskell.org http://haskell.org/mailinglist.html Simon | -----Original Message----- | From: Rab Lee [mailto:leelati@yahoo.com]=20 | Sent: 26 May 2001 08:48 | To: haskell@haskell.org | Subject: (no subject) |=20 |=20 | hi, i'm having a bit more touble, can anyone help me | or give me any hints on how to do this : | "x 2 3 4" =3D ("x", [2, 3, 4]) |=20 | __________________________________________________ | Do You Yahoo!? | Yahoo! Auctions - buy the things you want at great prices=20 http://auctions.yahoo.com/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From Dominic.J.Steinitz@BritishAirways.com Mon May 28 14:05:48 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 28 May 2001 13:05:48 Z Subject: Building Programs Again Message-ID: <"035493B124D2C001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> I am going to install hmake and upgrade to ghc 5 but in the meantime I decided to use make. I am puzzled however. Presumably building a module that imports a module needs the .hi file and therefore the makefile should be something like this: Tagsv1.o : Tagsv1.hs ghc -c Tagsv1.hs -package lang Basev1.o : Tagsv1.hi Basev1.hs ghc -c Basev1.hs -package lang But if I do this then make complains if I want to see what it will generate [dom@lhrtba8fd85 maketest]$ make -n ghc -c Tagsv1.hs -package lang make: *** No rule to make target `Tagsv1.hi', needed by `Basev1.o'. Stop. Running make works as by the time the rule gets executed the .hi file exists. Can anyone suggest something better? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonmar@microsoft.com Mon May 28 14:46:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Mon, 28 May 2001 14:46:56 +0100 Subject: Building Programs Again Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD713@TVP-MSG-01.europe.corp.microsoft.com> > I am going to install hmake and upgrade to ghc 5 but in the=20 > meantime I decided to use make. >=20 > I am puzzled however. Presumably building a module that=20 > imports a module needs the .hi file and therefore the=20 > makefile should be something like this: >=20 > Tagsv1.o : Tagsv1.hs > ghc -c Tagsv1.hs -package lang >=20 > Basev1.o : Tagsv1.hi Basev1.hs > ghc -c Basev1.hs -package lang >=20 > But if I do this then make complains if I want to see what it=20 > will generate >=20 > [dom@lhrtba8fd85 maketest]$ make -n > ghc -c Tagsv1.hs -package lang > make: *** No rule to make target `Tagsv1.hi', needed by=20 > `Basev1.o'. Stop. =20 >=20 > Running make works as by the time the rule gets executed the=20 > .hi file exists. >=20 > Can anyone suggest something better? GHC's documentation has some useful tips on using make with Haskell: =09 http://www.haskell.org/ghc/docs/latest/set/separate-compilation.html#USI NG-MAKE Chees, Simon From franka@cs.uu.nl Mon May 28 15:49:31 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Mon, 28 May 2001 16:49:31 +0200 Subject: The next step In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 10:17:03AM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010528164931.B4803@cs.uu.nl> Simon Marlow wrote (on 28-05-01 10:17 +0100): > It's not propaganda. The fact is if any of the standard libraries use > the LGPL, then some people will be prevented from using them. That's > the last thing we want, right? Now you might argue from a moral > standpoint that the companies that these people work for are basing > their business models on intellectual property and therefore deserve > everything they get, but we're not trying to do open source advocacy > here, we're just trying to put together a set of libraries that everyone > can use. Some people don't see it that way. They would say that the GPL is the _less_ restrictive license because it ensures that everybody benefits (equally) from everybody else's improvements. From that perspective, companies benefit also since they may use and improve the code, provided they "publish" it. Will they lose some potential revenue that way? Possibly. But as you suggested, the idea is to make the audience as _wide_ as possible, not as _rich_ as possible. ;) -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From davidbak@cablespeed.com Mon May 28 21:25:22 2001 From: davidbak@cablespeed.com (David Bakin) Date: Mon, 28 May 2001 13:25:22 -0700 Subject: Why is there a space leak here? Message-ID: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs Nov = '99) foo1 eats cells (and eventually runs out) where foo2 doesn't. = That is, if I do (length (foo1 1000000)) I eventually run out of cells = but (length (foo2 1000000)) runs fine (every GC returns basically the = same amount of space). Something must be wrong in flatten but it = follows the pattern of many functions in the prelude (which I'm trying = to learn from). I have been puzzling over this for nearly a full day (getting this = reduced version from my own code which wasn't working). In general, how = can I either a) analyze code looking for a space leak or b) experiment = (e.g., using Hugs) to find a space leak? Thanks! -- Dave -- This has a space leak, e.g., when reducing (length (foo1 1000000)) foo1 m=20 =3D take m v where v =3D 1 : flatten (map triple v) triple x =3D [x,x,x] -- This has no space leak, e.g., when reducing (length (foo2 1000000)) foo2 m=20 =3D take m v where v =3D 1 : flatten (map single v) single x =3D [x] -- flatten a list-of-lists flatten :: [[a]] -> [a] flatten [] =3D [] flatten ([]:xxs) =3D flatten xxs flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs flatten' [] xxs =3D flatten xxs flatten' (x':xs') xxs =3D x': flatten' xs' xxs ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Why is there a space leak in foo1 but not in = foo2? =20 (I.e., in Hugs Nov '99) foo1 eats cells (and eventually runs out) where = foo2=20 doesn't. That is, if I do (length (foo1 1000000)) I = eventually run=20 out of cells but (length (foo2 1000000)) runs fine (every GC returns = basically=20 the same amount of space). Something must be wrong in flatten but = it=20 follows the pattern of many functions in the prelude (which I'm trying = to learn=20 from).

I have been puzzling over this for nearly a full day = (getting=20 this reduced version from my own code which wasn't working). In = general,=20 how can I either a) analyze code looking for a space leak or b) = experiment=20 (e.g., using Hugs) to find a space leak? Thanks! --=20 Dave

-- This has a space leak, e.g., = when=20 reducing (length (foo1 1000000))
foo1 m
=3D take m=20 v
    where
      v =3D 1 = : flatten=20 (map triple v)
      triple x =3D = [x,x,x]

-- This has no space leak, = e.g., when=20 reducing (length (foo2 1000000))
foo2 m
=3D take m=20 v
    where
      v =3D 1 = : flatten=20 (map single v)
      single x =3D = [x]

-- flatten a = list-of-lists
flatten ::=20 [[a]] -> [a]
flatten=20 []            = ; =3D=20 []
flatten ([]:xxs)       =3D flatten=20 xxs
flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs
flatten' []=20 xxs       =3D flatten = xxs
flatten' (x':xs')=20 xxs =3D x': flatten' xs' xxs

------=_NextPart_000_0063_01C0E779.A61E3330-- From jcab@roningames.com Tue May 29 02:02:09 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 18:02:09 -0700 Subject: Notation question In-Reply-To: References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Just a very naive question, because I'm really curious. I've seen in previous messages here discussions about type systems using this kind of notation: > G |- f :: all x::S . T G |- s :: S >-------------------------------------- > G |- f s :: [s/x]T I'd never seen it before, and a few searches I've launched over the net have turned up just a couple more examples of this notation, but without a single reference to how it works or what it means, or even what it's called, for that matter. I'd appreciate any pointers. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From mark@chaos.x-philes.com Tue May 29 02:24:04 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Mon, 28 May 2001 21:24:04 -0400 (EDT) Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: On Mon, 28 May 2001, Juan Carlos Arevalo Baeza wrote: > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. (snip) I'm far from the right person to have a go, but while we're waiting for someone who knows what they're talking about: I bet that |- is 'entails'. My impression of it is rather like 'implies', but clearly that's not quite right or we wouldn't need a different term for it. The . might be 'such that'. The thing below the ----- might be a consequence of the two things above it. The [s/x]T means, probably, "T with s substituted for any occurrence of x". (Did I get that the right way around?) I hope that's a start. -- Mark From jcab@roningames.com Tue May 29 03:18:11 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 19:18:11 -0700 Subject: Notation question In-Reply-To: References: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <4.3.2.7.2.20010528190819.03795668@207.33.235.243> At 09:24 PM 5/28/2001 -0400, Mark Carroll wrote: > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > >I'm far from the right person to have a go, but while we're waiting for >someone who knows what they're talking about: :) Thanx. >"I bet ...", "My impression of it is rather like ...", "..., but clearly >that's not quite right or ...", "... might be ...", "... means, probably, ..." > >I hope that's a start. Ufff... O:-) Sorry for pointing this out, but I couldn't resist. No offense intended. I actually appreciate your response. Really, I mean it. But it's not quite what I was looking for O:-) Anyway, I just saw that I had another reply (this on direct email, not posted to the list) with more info, so if you (or anyone) wants it just ask. Anyway, as the helpful person said about the expression above, "It's a theorem, really". Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From dscarlett@optushome.com.au Tue May 29 04:53:44 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Tue, 29 May 2001 13:53:44 +1000 Subject: Notation question References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <00c401c0e7f2$f4f87780$0100a8c0@CO3003288A> ----- Original Message ----- From: "Juan Carlos Arevalo Baeza" To: Sent: Tuesday, May 29, 2001 11:02 AM Subject: Notation question > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > I think I've seen it (or something similar) in an imperative language called "Imp". From rjmh@cs.chalmers.se Tue May 29 08:13:37 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Tue, 29 May 2001 09:13:37 +0200 (MET DST) Subject: Notation question Message-ID: <200105290713.JAA22503@muppet30.cs.chalmers.se> > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. This is a standard notation for describing type systems in articles on the subject -- so standard that it's hard to think of a good reference that actually explains it! However, I'd suggest looking at Michael Schwartzbach's lecture notes on Polymorphic Type Inference, which are on the web at http://www.daimi.aau.dk/~mis/typeinf.ps The typing rule notation is explained in the first couple of pages, and then used to explain many variants on type systems, show how inference works, etc. I have a collection of links to such articles at http://www.md.chalmers.se/~rjmh/tutorials.html which you might find useful. John Hughes From Andrew.Pitts@cl.cam.ac.uk Tue May 29 08:53:31 2001 From: Andrew.Pitts@cl.cam.ac.uk (Andrew Pitts) Date: Tue, 29 May 2001 08:53:31 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 09:13:37 +0200." <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: John Hughes said > > > > G |- f :: all x::S . T G |- s :: S > > > >-------------------------------------- > > > > G |- f s :: [s/x]T > > > Any more takers? I still don't have any pointers to literature where > this theorem notation is explained more fully, and I'd really like to have > some. > This is a standard notation for describing type systems in articles on the > subject -- so standard that it's hard to think of a good reference that > actually explains it! and not just type systems but also other aspects of operational semantics. What we have here is a single rule from a rule-based inductive definition of a certain relation G |- s :: S between typing environments G, expressions s and types S. I seem to spend half my life using such inductive definitions and the other half teaching them to undergraduates (and the third half doing university administration, hey ho). Casting modesty aside, to read about such things let me recommend lecture notes on operational semantics (esp section 2.3) Andy Pitts From franka@cs.uu.nl Tue May 29 11:39:56 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Tue, 29 May 2001 12:39:56 +0200 Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243>; from jcab@roningames.com on Mon, May 28, 2001 at 06:02:09PM -0700 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <20010529123956.B5078@cs.uu.nl> Juan Carlos Arevalo Baeza wrote (on 28-05-01 18:02 -0700): > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. May I also recommend my PL theory references page?: http://www.cs.uu.nl/people/franka/ref.html BTW, here is the quick version: It says: Suppose term f has type all x::S.T in free variable environment G. Suppose further that term s has type S in environment G. Then the term f s has type [s/x]T (T with s substituted for x) in environment G. But this in itself is really not very meaningful unless you assume some standard definitions. For example, there should be rules for introducing variables, introducing/eliminating "all" types, manipulating environments, a definition for substitution, etc. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From Jon.Fairbairn@cl.cam.ac.uk Tue May 29 11:44:08 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Tue, 29 May 2001 11:44:08 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 08:53:31 BST." Message-ID: <23944.991133048@cl.cam.ac.uk> > and not just type systems but also other aspects of operational > semantics. What we have here is a single rule from a rule-based > inductive definition of a certain relation G |- s :: S between typing > environments G, expressions s and types S. It's probably worth mentioning here that this notation originated (I think) in mathematical logic, as a way of presenting formal systems. Try "Gentzen", "Natural Deduction" and "Sequent Calculus" as search terms. J=F3n From Phil Trinder Tue May 29 15:24:35 2001 From: Phil Trinder (Phil Trinder) Date: Tue, 29 May 2001 15:24:35 +0100 (GMT Daylight Time) Subject: SFP Call for Participation Message-ID: CALL FOR PARTICIPATION 3rd Scottish Functional Programming Workshop University of Stirling Aug 22nd-24th, 2001 You are invited to participate in the 3rd Scottish Functional Programming Workshop. The draft programme is below, and both registration form and additional information are available at: http://www.cee.hw.ac.uk/~greg/sfp3/ SFP'3 Draft Programme ===================== Parallelism ----------- A Comparative Study of Skeleton-based Parallel Programming Environments Allowing Arbitrary Nesting Remi Coudarcher, Jocelyn Serot, Jean-Pierre Derutin Universite Blaise Pascal - Clermont II, France BSP in a Lazy Functional Context Quentin Miller Universite d'Orleans, France Parallel Functional Genetic Programming Graeme McHale and Greg Michaelson Heriot-Watt University, Scotland Introduction of Pipelining into Gaussian Elimination Joy Goodman Glasgow University, Scotland The Efficiency of Parallel Graph Reduction on a Loosely-coupled Multiprocessor Hans Wolfgang Loidl An SPMD environment machine for functional BSP programs Armelle Merlin, Gaetan Hains Universite d'Orleans, France Implementing and Measuring GdH Skeletons Phil Trinder Heriot-Watt University, Scotland Distribution ------------ Distributed Programming with Dynamic Reply Channels Rita Loogen, Steffen Priebe Philips-Universitat Marburg, Germany Distributed Applications in GdH Robert Pointon Heriot-Watt University, Scotland Applications ------------ Haskell: Language for Business Systems Dominic Steinitz, British Airways Chris Reade, Dan Russell, Phil Molyneux, Barry Avery Kingston Business School, England Functional programming languages for verification tools: experiences with ML and Haskell Martin Leucker, Thomas Noll, Perdita Stevens, Michael Weber RWTCH Aachen, Germany/University of Edinburgh, Scotland Infinite Pretty Printing in eXene Allen Stoughton Kansas State University, USA Derivation and Transformation ----------------------------- Extending Higher-Order Deforestation: Transforming Programs to Eliminate Even More Trees Geoff Hamilton, Dublin City University, Ireland Deriving Non-heirarchical Process Topologies Ricardo Pena, Fernando Rubio, Clara Segura Universidad Complutense de Madrid, Spain Language Design and Implementation ---------------------------------- Some Experiences Connecting Functional Languages and Java Andre Rauber Du Bois, Antonio Carlos da Rocha Costa Universidade Federal do Rio Grande do Sul/ Universidade Catolica de Pelotas, Brazil Paging Behaviour of List-based Memory in a Distributed Virtual Memory System for Pure Functional Languages Marco T. Morazan and Douglas R. Troeger City University of New York, USA Types ----- How to Fix Type Errors Automatically Bruce J. McAdam University of Edinburgh, Scotland Function Types and Complete type Inference Manfred Widera, Christoph Bierle Fern Universitat Hagen, Germany Human-like Explanations of Polymorphic Types Yang Jun, Greg Michaelson, Phil Trinder Heriot-Watt University, Scotland Theory ------ The dual of grafting is decoration Tarmo Uustalu, Varmo Vene Universidade do Minho, Portugal University of Tartu, Estonia Towards a Denotational semantics for Eden Mercedes Hidalgo-Herrero, Yolanda Ortega-Mallen Universidad Complutense de Madrid, Spain From thor-list-haskell@banyan.moertel.com Tue May 29 16:35:41 2001 From: thor-list-haskell@banyan.moertel.com (Tom Moertel) Date: Tue, 29 May 2001 11:35:41 -0400 Subject: Notation question References: <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: <3B13C1CD.2AC0CEBA@banyan.moertel.com> Another introduction, with emphasis on the historical development: Philip Wadler, "Proofs are Programs: 19th Century Logic and 21st Century Computing." http://www.cs.bell-labs.com/who/wadler/topics/history.html It's a fun read, too. Cheers, Tom From tullsen@cs.yale.edu Tue May 29 17:48:52 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Tue, 29 May 2001 12:48:52 -0400 Subject: Recursive types? References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> <15113.52727.506242.598828@waytogo.peace.co.nz> Message-ID: <3B13D2F4.F525CFDC@cs.yale.edu> Tom Pledger wrote: > I don't know whether this is a shining example of an advantage, > and am keen to see other comments. For what it's worth, I've pulled some snippets from some code I wrote. I wanted three recursive types which were nearly identical (Exp,ExpQv,ExpPr). Rather than write three different type declarations data Exp = ... data ExpQv = ... data ExpPr = ... I was able to abstract out the commonality into one non-recursive type data FctrExp a = ... Note how concise some of my "Sample Functions" can be. These would have been very long and ugly to write were I to use the first approach. At the expense of now using a "two-level" type, I've gained some expressiveness. - Mark ---- Fix Type ----------------------------------------------------------------- data Fix f = In (f (Fix f)) class FixEq f where fixEq :: Eq a => (f a -> f a -> Bool) class FixShow f where fixShowsPrec :: Show a => (Int -> f a -> ShowS) instance FixEq f => Eq (Fix f) where (==) (In x) (In y) = fixEq x y instance FixShow f => Show (Fix f) where showsPrec p (In x) = showString "In (" . fixShowsPrec p x . showChar ')' ---- Types for Documentation -------------------------------------------------- type Var = String type Env x = [(Var,x)] type Pat = Exp type Type = Exp ---- Form & FormPr Related Types --------------------------------------------- type Qv = (Exp,Exp) data Pr = Pstep (ExpPr,Justifier,ExpPr) | Pletu (Var, Type, ExpPr) deriving(Show,Eq) data Justifier = Stub1 deriving (Show,Eq) ---- Exp,ExpPr,ExpQv Types ---------------------------------------------------- data Ftype = Stub2 deriving (Show,Eq) data Ltype = Stub3 deriving (Show,Eq) data Const = Stub4 deriving (Show,Eq) data FctrExp a = Econ Const | Evar Var | Eapp (Ftype, a, a) | Elet (Ltype, Pat, Type, a, a) -- let x:t=e1 in e2 | Elam (Ftype, Pat, Type, a) -- \x:t=>e | Eqnt (Ftype, Pat, Type, a) -- |~|x:t=>e | Etup [a] -- | Emu a | Ecase a -- case e | Ein (a,a) -- In i e deriving (Show,Eq) data FctrExpQv a = ExpQvExp (FctrExp a) | ExpQvQv Qv deriving (Show,Eq) data FctrExpPr a = ExpPrExp (FctrExp a) | ExpPrPr Pr deriving (Show,Eq) type Exp = Fix FctrExp type ExpQv = Fix FctrExpQv type ExpPr = Fix FctrExpPr ---- Define Appropriate Functors ---------------------------------------------- instance Functor FctrExp where fmap = fmapFctrExp fmapFctrExp :: (a->b) -> (FctrExp a -> FctrExp b) fmapFctrExp f e = case e of Econ x -> Econ x Evar x -> Evar x Eapp (x,e1,e2) -> Eapp (x,f e1, f e2) Elet (x,v,t,y,z) -> Elet (x,v,t,f y,f z) Elam (x,v,t,e) -> Elam (x,v,t,f e) Eqnt (x,v,t,e) -> Eqnt (x,v,t,f e) Etup es -> Etup (map f es) Emu e -> Emu (f e) Ecase e -> Ecase (f e) Ein (i,e) -> Ein (f i,f e) ---- Make Exp,ExpQv,ExpPr instances of Show and Eq ---------------------------- instance FixEq FctrExp where fixEq = (==) instance FixShow FctrExp where fixShowsPrec = showsPrec instance FixEq FctrExpQv where fixEq = (==) instance FixShow FctrExpQv where fixShowsPrec = showsPrec instance FixEq FctrExpPr where fixEq = (==) instance FixShow FctrExpPr where fixShowsPrec = showsPrec ---- Sample Functions --------------------------------------------------------- expToExpPr :: Exp -> ExpPr expToExpPr (In x) = In (ExpPrExp (fmap expToExpPr x)) firstExpPr, finalExpPr :: ExpPr -> Exp firstExpPr (In x) = case x of ExpPrExp e -> In $ fmap firstExpPr e ExpPrPr (Pstep (p,_,_)) -> firstExpPr p ExpPrPr (Pletu _) -> error "firstExpPr" finalExpPr (In x) = case x of ExpPrExp e -> In $ fmap finalExpPr e ExpPrPr (Pstep (_,_,p)) -> finalExpPr p ExpPrPr (Pletu _) -> error "finalExpPr" From awfurtado@uol.com.br Wed May 30 02:04:02 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 29 May 2001 22:04:02 -0300 Subject: Announcement: new HOpenGL Tutorial Message-ID: <00a401c0e8a4$7101d540$bd30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there. I've just released the first version of my HOpenGL (Haskell = Open Graphics Library) tutorial. I hope it will encourage (and help) = people around the world to use this great library/binding. I also would = like to hear some feedback from you. You can visit the tutorial at: www.cin.ufpe.br/~haskell/hopengl/ Thank you, Andre W B Furtado ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello there. I've just released the = first version=20 of my HOpenGL (Haskell Open Graphics Library) tutorial. I hope it = will=20 encourage (and help) people around the world to use this great = library/binding.=20 I also would like to hear some feedback from you. You can visit the = tutorial=20 at:

www.cin.ufpe.br/~haskel= l/hopengl/

Thank you,

Andre W B = Furtado

------=_NextPart_000_009C_01C0E88B.44EDB0A0-- From simonpj@microsoft.com Wed May 30 11:37:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 03:37:10 -0700 Subject: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Folks, I'm about to put out (what I hope is) the final revised Haskell98 report. Here, though, is one good point I propose to clarify. I propose to say that every H98 impl must support tuples up to size 7 and their instances for Eq, Ord, Bounded, Read, Show [Of course, one might hope that impls would do better, but the report should be conservative.] Simon | -----Original Message----- | From: Olaf Chitil [mailto:olaf@cs.york.ac.uk]=20 | Sent: 23 April 2001 12:11 | To: nhc-users@cs.york.ac.uk | Cc: haskell@haskell.org; Simon Peyton-Jones | Subject: Re: Eq instance for (a,b,c,d,e) and upwards |=20 |=20 |=20 | I think that this discussion about tuples shows that there is=20 | a problem with the Haskell 98 report which should be=20 | corrected. I hope Simon accepts it as a minor bug fix. |=20 | 1) The current wording of paragraph 6.1.4 is highly ambigious. |=20 | > 6.1.4 Tuples | > =20 | > Tuples are algebraic datatypes with special syntax, as defined | > in Section 3.8. Each tuple type has a single constructor. There | > is no upper bound on the size of a tuple. However, some Haskell | > implementations may restrict the size of tuples and limit the | > instances associated with larger tuples. The Prelude and=20 | libraries | > define tuple functions such as zip for tuples up to a=20 | size of 7. All | > tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes | > defined in the libraries may also supply instances for=20 | tuple types. |=20 | May the limit for the size of tuples and the limit for=20 | instances be different? Do tuples exist at least for a size=20 | up to 7? What is the purpose of the last sentence? |=20 | We should decide what we want and the paragraph should then=20 | state it clearly. |=20 | 2) The arbitrary restrictions that Haskell implementations=20 | are permitted to apply, basically imply that you shouldn't=20 | use tuples at all if you want your code to be portable. Maybe=20 | there isn't even a Show instance for ()? |=20 | So I think the report should demand that tuples and instances=20 | for Eq,Ord,Bounded,Read and Show should be implemented for at=20 | least up to a size of a given number n. |=20 | 3) I propose this number n to be 7. This fits well with the=20 | fact that zip etc are defined for tuples up to a size of 7. I=20 | agree with Martin that you should use a labelled record or at=20 | least an own type instead of large tuples anyway.=20 | Programs that generate code should als generate definitions=20 | for data types, if large product types are needed.=20 |=20 | Olaf |=20 | --=20 | OLAF CHITIL,=20 | Dept. of Computer Science, University of York, York YO10 5DD, UK.=20 | URL: http://www.cs.york.ac.uk/~olaf/ | Tel: +44 1904 434756; Fax: +44 1904 432767 |=20 From simonpj@microsoft.com Wed May 30 12:08:26 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 04:08:26 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Folks I've finished what I hope is the final version of the Haskell 98=20 Language and Library Reports http://research.microsoft.com/~simonpj/haskell98-revised However, experience shows that bug fixes are often themselves buggy, so I urge you, once again, to take a look at your favourite passages and check they are correct. As ever, there's a complete list of changes at the above URL, with the ones I've made since the April release identified for your pleasure. Comments (hopefully vanishingly few) by 15 June please. Thanks very much Simon From rjljr2@yahoo.com Wed May 30 12:27:01 2001 From: rjljr2@yahoo.com (Ronald Legere) Date: Wed, 30 May 2001 04:27:01 -0700 (PDT) Subject: Announcement: new HOpenGL Tutorial In-Reply-To: <00a401c0e8a4$7101d540$bd30e3c8@windows9> Message-ID: <20010530112701.62154.qmail@web10006.mail.yahoo.com> Looks great! I think the community will really appreciate it. I will have to 'give it a whirl' myself, if I can ever get HOpenGL to compile on my solaris sparc. (I keep having trouble with 'test' in the makefiles. I must have a wierd version of test or something. I am no OS guru :) (If anyone has ever seen this problem, let me know ) Cheers! --- Andre W B Furtado wrote: > Hello there. I've just released the first version of > my HOpenGL (Haskell Open Graphics Library) tutorial. > I hope it will encourage (and help) people around > the world to use this great library/binding. I also > would like to hear some feedback from you. You can > visit the tutorial at: > > www.cin.ufpe.br/~haskell/hopengl/ > > Thank you, > Andre W B Furtado > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From tullsen@cs.yale.edu Wed May 30 17:04:49 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 12:04:49 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B151A21.BD5CA994@cs.yale.edu> Simon Peyton-Jones wrote: > > Folks > > I've finished what I hope is the final version of the Haskell 98 > Language and Library Reports > http://research.microsoft.com/~simonpj/haskell98-revised > > However, experience shows that bug fixes are often themselves > buggy, so I urge you, once again, to take a look at your favourite > passages and check they are correct. > > As ever, there's a complete list of changes at the above URL, > with the ones I've made since the April release identified for your > pleasure. > > Comments (hopefully vanishingly few) by 15 June please. Simon, Sorry to get this comment in so late, but it is a small change. In the List module, the type signature for deleteBy is not as general as it could be, given the definition. It could be generalized to the following (no change to the definition): deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] I've found it usefully used at this more general type. Thanks. - Mark From simonpj@microsoft.com Wed May 30 17:46:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 09:46:53 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> | Sorry to get this comment in so late, but it is a small=20 | change. In the List module, the type signature for deleteBy=20 | is not as general as it could be, given the definition. It=20 | could be generalized to the following (no change to the definition): |=20 | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] |=20 | I've found it usefully used at this more general type. Indeed, and=20 deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] I can't see any reason not to do this. Furthermore, the Report omits to export deleteFirstsBy, though GHC and Hugs both remember to do so. Simon From ross@soi.city.ac.uk Wed May 30 17:57:08 2001 From: ross@soi.city.ac.uk (Ross Paterson) Date: Wed, 30 May 2001 17:57:08 +0100 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010530175708.A3688@soi.city.ac.uk> On Wed, May 30, 2001 at 09:46:53AM -0700, Simon Peyton-Jones wrote: > | Sorry to get this comment in so late, but it is a small > | change. In the List module, the type signature for deleteBy > | is not as general as it could be, given the definition. It > | could be generalized to the following (no change to the definition): > | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > | > | I've found it usefully used at this more general type. > > Indeed, and > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] and intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] From zhanyong.wan@yale.edu Wed May 30 18:41:49 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 13:41:49 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3B1530DC.AAC1220D@yale.edu> Hello Simon, Looking at the definition for deleteBy: deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] deleteBy eq x [] = [] deleteBy eq x (y:ys) = if x `eq` y then ys else y : deleteBy eq x ys I can't help wondering why it isn't deleteBy' :: (a -> Bool) -> [a] -> [a] deleteBy' f [] = [] deleteBy' f (y:ys) = if f y then ys else y : deleteBy' f ys The point is that in the definition of deleteBy, all references to eq and x are in the form (eq x), and hence the two parameters can be combined. Is there a reason that the current design was favored when Prelude was designed? Thanks. - Zhanyong -- # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ # Yale University, Dept of Computer Science /\___\ # P.O.Box 208285, New Haven, CT 06520-8285 ||___| From Malcolm.Wallace@cs.york.ac.uk Wed May 30 18:37:47 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Wed, 30 May 2001 18:37:47 +0100 Subject: Haskell 98 Report In-Reply-To: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3FkAAOsvFTt4cwoA@cs.york.ac.uk> > > | It could be generalized to the following (no change to the definition): > > | > > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > > > > Indeed, and > > > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] > > and > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Although curiously, its dual 'unionBy' cannot also take the more general type unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] at least, not with its current specification in terms of 'nubBy'. Regards, Malcolm From Tom.Pledger@peace.com Wed May 30 21:16:44 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 08:16:44 +1200 Subject: Haskell 98 Report In-Reply-To: <3B1530DC.AAC1220D@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <15125.21804.829456.439929@waytogo.peace.co.nz> Zhanyong Wan writes: : | I can't help wondering why it isn't | | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] = [] | deleteBy' f (y:ys) = if f y then ys else | y : deleteBy' f ys deleteBy'' f = filter (not . f) Malcolm Wallace writes: : | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | Although curiously, its dual 'unionBy' cannot also take the more | general type | | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | at least, not with its current specification in terms of 'nubBy'. That suggests a reason to leave the type of intersectBy alone - the generalisation would arbitrarily favour the first list's type over the second list's type. To me, the word "intersect" implies symmetry. - Tom From zhanyong.wan@yale.edu Wed May 30 22:15:48 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 17:15:48 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> Message-ID: <3B156304.BD9F41F8@yale.edu> Tom Pledger wrote: > > Zhanyong Wan writes: > : > | I can't help wondering why it isn't > | > | deleteBy' :: (a -> Bool) -> [a] -> [a] > | deleteBy' f [] = [] > | deleteBy' f (y:ys) = if f y then ys else > | y : deleteBy' f ys > > deleteBy'' f = filter (not . f) No. deleteBy' f only deletes the *first* element that satisfies the predicate f, while filter (not . f) deletes *all* such elements. -- Zhanyong From Tom.Pledger@peace.com Wed May 30 22:25:53 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 09:25:53 +1200 Subject: Haskell 98 Report In-Reply-To: <3B156304.BD9F41F8@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> <3B156304.BD9F41F8@yale.edu> Message-ID: <15125.25953.715929.236763@waytogo.peace.co.nz> Zhanyong Wan writes: | Tom Pledger wrote: : | > deleteBy'' f = filter (not . f) | | No. deleteBy' f only deletes the *first* element that satisfies the | predicate f, while filter (not . f) deletes *all* such elements. Oops. Sorry. I ought to become less SQL-oriented... From tullsen@cs.yale.edu Thu May 31 00:59:44 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 19:59:44 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <3B158970.9C5D11EE@cs.yale.edu> Zhanyong Wan wrote: > > Hello Simon, > > Looking at the definition for deleteBy: > > deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] > deleteBy eq x [] = [] > deleteBy eq x (y:ys) = if x `eq` y then ys else > y : deleteBy eq x ys > > I can't help wondering why it isn't > > deleteBy' :: (a -> Bool) -> [a] -> [a] > deleteBy' f [] = [] > deleteBy' f (y:ys) = if f y then ys else > y : deleteBy' f ys > > The point is that in the definition of deleteBy, all references to eq > and x are in the form (eq x), and hence the two parameters can be > combined. Is there a reason that the current design was favored when > Prelude was designed? Thanks. > > - Zhanyong Zhanyong, I didn't mean to open up a can of worms! Although, when viewed in isolation, it would make sense to change deleteBy as you suggest; but when we look at the conventions of the List module, I think that it would be undesirable, even if we didn't care about breaking programs, because it would break the "xBy" convention described below. Originally we had this: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] And all the functions "x" with a "xBy" form have types which are related in a particular way, for some functor f: x :: Eq a => f a xBy :: (a -> a -> Bool) -> f a Now, if we generalize the type of deleteBy as I previously suggested, we have these two types: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] And it is still the case that functions "x" and "xBy" have types which are related as follows (generalizing the rule): x :: Eq a => f a a xBy :: (a -> b -> Bool) -> f a b (Where we would instantiate 'b' to 'a' for "xBy" functions which have a less general type.) - Mark From nilsson@cs.yale.edu Thu May 31 03:07:29 2001 From: nilsson@cs.yale.edu (Henrik Nilsson) Date: Wed, 30 May 2001 22:07:29 -0400 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B15A761.8C3F418C@cs.yale.edu> Hi, Simon Peyton-Jones wrote: > Folks, > > I'm about to put out (what I hope is) the final revised Haskell98 > report. > > Here, though, is one good point I propose to clarify. I propose to > say that > > every H98 impl must support tuples up to size 7 > and their instances for Eq, Ord, Bounded, Read, Show > > > [Of course, one might hope that impls would do better, but the report > should be conservative.] Clearly, the report has to state the minimal bound. And I agree that 7 is a choice which is consistent with the current Prelude. However, 7 is also a number which is uncomfortably close to what I've seen in real code and used myself. Yes, one might hope that this is a non issue, since all implementations I'm aware of does considerably better anyway. But if one wants to write portable code, it does become an issue. And yes, one could argue that records or user-defined product types should be used anyway. But that is really a matter of taste, and I'd say that there are reasonable examples where forcing the user to introduce a product type just to wrap up a bunch of values would harm rather than improve the readability. So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu From ralf@informatik.uni-bonn.de Thu May 31 08:20:43 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Thu, 31 May 2001 09:20:43 +0200 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> Message-ID: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal > bound cannot be "infinity", could it at least be a great deal > bigger than what reasonably would be used in *hand-written* > code? Say 15. An arbitrary choice, of course, but it is not > excessive from an implementation perspective, yet large enough > that I cannot imagine hand-written code getting close to the > limit. I second Henrik here, 15 is much better than 7. Cheers, Ralf From chak@cse.unsw.edu.au Thu May 31 08:21:52 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 31 May 2001 17:21:52 +1000 Subject: Eq instance for (a,b,c,d,e) and upwards In-Reply-To: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Message-ID: <20010531172152T.chak@cse.unsw.edu.au> Ralf Hinze wrote, > Henrik Nilsson wrote: > > > So, if, in the interest of being conservative, the stated minimal > > bound cannot be "infinity", could it at least be a great deal > > bigger than what reasonably would be used in *hand-written* > > code? Say 15. An arbitrary choice, of course, but it is not > > excessive from an implementation perspective, yet large enough > > that I cannot imagine hand-written code getting close to the > > limit. > > I second Henrik here, 15 is much better than 7. I agree. Manuel From simonpj@microsoft.com Thu May 31 08:58:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:58:58 -0700 Subject: FW: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73004@red-msg-09.redmond.corp.microsoft.com> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal=20 > bound cannot be "infinity", could it at least be a great deal bigger=20 > than what reasonably would be used in *hand-written* code? Say 15. An=20 > arbitrary choice, of course, but it is not excessive from an=20 > implementation perspective, yet large enough that I cannot imagine=20 > hand-written code getting close to the limit. A fair point. If you care either way, send me a note. (Not to the list.) Henrik leaves open the question of which tuple *instances* you can rely on. Up to 7, like zip and friends? Or up to 15? By analogy with the zip functions, I think I'd go for 7. Again, let me know, but don't trouble the list unless you want to raise a new point. Simon From simonpj@microsoft.com Thu May 31 08:53:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:53:50 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] | > |=20 | > | I've found it usefully used at this more general type. | >=20 | > Indeed, and | >=20 | > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] |=20 | and |=20 | intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Indeed. We should either generalise all three deleteBy deleteFirstsBy intersectBy or none. In favour: the more general types are occasionally useful no programs stop working Against it's an unforced change perhaps some error message may get more obscure Tom wrote | That suggests a reason to leave the type of intersectBy alone=20 | - the generalisation would arbitrarily favour the first=20 | list's type over the second list's type. To me, the word=20 | "intersect" implies symmetry. The point is that you can always use it at the symmetrical type too. This isn't a big issue, or I would not be considering it at this point. So I solicit feedback, and will then just decide something. Simon From simonpj@microsoft.com Thu May 31 08:43:13 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:43:13 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73000@red-msg-09.redmond.corp.microsoft.com> I don't think there was a deep reason, but the current story makes it more like the other 'By' functions. Anyway, this is one thing that is not going to change! (Not that you were proposing that it should.) Simon | -----Original Message----- | From: Zhanyong Wan [mailto:zhanyong.wan@yale.edu]=20 | Sent: 30 May 2001 18:42 | To: Simon Peyton-Jones | Cc: haskell@haskell.org | Subject: Re: Haskell 98 Report |=20 |=20 | Hello Simon, |=20 | Looking at the definition for deleteBy: |=20 | deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] | deleteBy eq x [] =3D [] | deleteBy eq x (y:ys) =3D if x `eq` y then ys else | y : deleteBy eq x ys |=20 | I can't help wondering why it isn't |=20 | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] =3D [] | deleteBy' f (y:ys) =3D if f y then ys else | y : deleteBy' f ys |=20 | The point is that in the definition of deleteBy, all=20 | references to eq and x are in the form (eq x), and hence the=20 | two parameters can be combined. Is there a reason that the=20 | current design was favored when Prelude was designed? Thanks. |=20 | - Zhanyong |=20 | --=20 | # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ | # Yale University, Dept of Computer Science /\___\ | # P.O.Box 208285, New Haven, CT 06520-8285 ||___| |=20 From S.J.Thompson@ukc.ac.uk Thu May 31 13:40:54 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Thu, 31 May 2001 13:40:54 +0100 Subject: Teaching Assistantships in the Computing Lab, University of Kent Message-ID: Haskellers welcome! Simon Teaching Assistantships in the Computing Lab, University of Kent Applications are invited for two posts of teaching assistant in the Computing Laboratory at the University of Kent. These posts are for a fixed-term period of four years and are intended to support postgraduate researchers during their period of registration for a part-time PhD in one of the research groups in the Computing Laboratory. The successful applicants will be required to participate in up to eight hours teaching per week during academic terms. Applicants will be expected to provide evidence of their experience in teaching or equivalent activities. Total remuneration is at the rate of 13,231 GBP per annum, made up of 6931 GBP salary and 6300 GBP PhD bursary; PhD fees are paid in addition to this. Application procedure Applications should be sent by email to the professorial secretary, Mrs Jenny Oatley, jao@ukc.ac.uk, with the subject line 'Teaching Assistant Application'. Applications should include - A brief curriculum vitae, detailing - educational history and qualifications; - employment history; - details of teaching experience, if any; - country of residence, native language (if not English please include TOEFL/IELTS score). - A statement of your proposed research project, including the research group in which that research project lies. - Names, addresses and email addresses of two academic referees. The deadline for applications is 21 June 2001, and interviews will take place on 28 June 2001. Applicants who are unable to attend interviews may be asked for telephone interview. From joshuag@ozemail.com.au Thu May 31 17:02:37 2001 From: joshuag@ozemail.com.au (Joshua Ginges) Date: Fri, 01 Jun 2001 02:02:37 +1000 Subject: Dividing floats Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3074205757_1755708 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Can anyone please help me. How can you divide two floats? (and return a float, even if they divide equally) Ie (something like...) div 2.4 1.2 ---> 2.0 Thanks Josh --B_3074205757_1755708 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Dividing floats Can anyone please help me.

How can you divide two floats? (and return a float, even if they divide equ= ally)

Ie (something like...) div 2.4 1.2 ---> 2.0

Thanks

Josh
--B_3074205757_1755708-- From djrussell@kingston.ac.uk Thu May 31 17:25:46 2001 From: djrussell@kingston.ac.uk (Daniel Russell) Date: Thu, 31 May 2001 17:25:46 +0100 (BST) Subject: Dividing Floats Message-ID: <200105311625.RAA08117@helios.king.ac.uk> > Can anyone please help me. > How can you divide two floats? (and return a float, even if they divide > equally) > Ie (something like...) div 2.4 1.2 ---> 2.0 The above doesn't work since div can only be applied to integral numbers: div :: Integral a => a -> a -> a What you need is the operator (/) which can only be applied to fractional numbers: (/) :: Fractional a => a -> a -> a For example: 2.4 / 1.2 ---> 2.0 or (/) 2.4 1.2 ---> 2.0 Dan Russell Kingston University From fjh@cs.mu.oz.au Thu May 31 19:19:23 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 04:19:23 +1000 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010601041923.A10308@hg.cs.mu.oz.au> On 31-May-2001, Simon Peyton-Jones wrote: > We should either generalise all three > deleteBy > deleteFirstsBy > intersectBy > or none. > > In favour: > the more general types are occasionally useful > no programs stop working Actually some programs will stop working, because the types will be underconstrained, so the compiler won't know how to satisfy some type class constraint. For example: import List main = print (deleteBy (\x _y -> x > 0) 1 []) With the generalized type, you'd get an unresolved `Show' constraint. The number of real programs for which this is a problem is most likely very small, and the work-around (typically just adding an explicit type qualification) is not hard once you understand what the problem is, but figuring out what the problem is could take some time. Since it does break some obscure programs, and since it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature, my preference would be to leave this out of Haskell 98, but include it in the next version of Haskell. (It would be good for someone, perhaps Simon P-J., to keep a list of issues like this which have been left out of Haskell 98 due to backwards compatibility concerns, so that they don't get forgotten about when it comes to time for the next version.) -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From C.Reinke@ukc.ac.uk Thu May 31 19:48:24 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 31 May 2001 19:48:24 +0100 Subject: Haskell 98 Report In-Reply-To: Message from Fergus Henderson of "Fri, 01 Jun 2001 04:19:23 +1000." <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: "..it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature,.." Fergus Henderson, June 2001 Is this definition of reuse in Haskell quotable?-) Claus From tullsen@cs.yale.edu Thu May 31 20:04:02 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Thu, 31 May 2001 15:04:02 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: <3B1695A2.2318EBC0@cs.yale.edu> So much for my small, innocuous, non controversial suggestion :-). Fergus Henderson wrote: > > On 31-May-2001, Simon Peyton-Jones wrote: > > We should either generalise all three > > deleteBy > > deleteFirstsBy > > intersectBy > > or none. > > > > In favour: > > the more general types are occasionally useful > > no programs stop working > > Actually some programs will stop working, because the types will be > underconstrained, so the compiler won't know how to satisfy some type class > constraint. > > For example: > > import List > main = print (deleteBy (\x _y -> x > 0) 1 []) > > With the generalized type, you'd get an unresolved `Show' constraint. That's a good point Fergus, I hadn't noticed the potential problem here. > The number of real programs for which this is a problem is most likely very > small, and the work-around (typically just adding an explicit type > qualification) is not hard once you understand what the problem is, but > figuring out what the problem is could take some time. My intuition (whatever it's worth) tells me that the real programs that would be affected are close to nil. Would you agree? > Since it does break some obscure programs, and since it's easy enough > for programmers who want a generalized version to just cut and paste > the code from the Haskell report and give it a more general type signature, Sure, it's easy enough, but one of the reasons I like Haskell so much over languages like C is that I almost never have to resort to programming by "cut and paste". I generally prefer to give the most general type signature for each definition. It makes programs more robust. It gives a stronger "free theorem"; in other words, I can tell more about the function by just looking at the type. For instance ... Tom Pledger wrote: > Malcolm Wallace writes: > : > | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | Although curiously, its dual 'unionBy' cannot also take the more > | general type > | > | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | at least, not with its current specification in terms of 'nubBy'. > > That suggests a reason to leave the type of intersectBy alone - the > generalisation would arbitrarily favour the first list's type over the > second list's type. To me, the word "intersect" implies symmetry. But to me it seems a good reason to change the type of intersectBy: the definition isn't really symmetric, so why should the type signature be symmetric? - Mark From fjh@cs.mu.oz.au Thu May 31 22:20:10 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 07:20:10 +1000 Subject: Haskell 98 Report In-Reply-To: References:

Message-ID: <20010601072010.A10659@hg.cs.mu.oz.au> On 31-May-2001, C.Reinke wrote: > > "..it's easy enough for programmers who want a generalized version to just cut > and paste the code from the Haskell report and give it a more general type > signature,.." > > Fergus Henderson, June 2001 > > Is this definition of reuse in Haskell quotable?-) Sure, feel free to go ahead and quote it (you just did already ;-). But it's taken a little out of context. Certainly I wouldn't recommend that as a method of code reuse in ordinary cases, let alone posit it as a _definition_ of reuse. However, in this particular case, where the algorithm is fairly trivial, and the code is well tested, the costs of cut-and-paste reuse are not high, and specifically the downside of that approach is comparable to the downside of the other approach, namely the need to diagnose and fix type errors in programs like the one I posted. So we need to consider the likely frequency of these scenarios, and the benefits/costs of keeping the Haskell 98 standard as stable as possible or making minor changes like this that could also cause problems when converting between one "Haskell 98, 2002 revision" compiler and another "classic Haskell 98" implementation. It's all about trade-offs. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Thu May 31 23:10:43 2001 From: reid@cs.utah.edu (Alastair David Reid) Date: 31 May 2001 16:10:43 -0600 Subject: Haskell 98 Report In-Reply-To: <20010601041923.A10308@hg.cs.mu.oz.au> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: Fergus Henderson writes: > (It would be good for someone, perhaps Simon P-J., to keep a > list of issues like this which have been left out of Haskell 98 > due to backwards compatibility concerns, so that they don't get > forgotten about when it comes to time for the next version.) Such a list would indeed be useful but I think it's important that the list should record that there are reasons besides backwards compatability for leaving things as they are. IIRC, at the time that the functions were added to List, someone proposed generalisations like those currently on the table but they were rejected because they made it harder to state the relationship between the By functions and their overloaded brethren. With things as they are now, the relationship between the By functions and their overloaded variants is very, very simple to state: if foo has type foo :: (Eq a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an equivalence relation) and foo = fooBy (==) and if foo has type foo :: (Ord a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an reflexive, transitive relation) and foo = fooBy (<=) Making the types of the By functions as general as possible would break the consistency of this story. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/ From ml_dk@excite.com Tue May 1 13:31:03 2001 From: ml_dk@excite.com (ml_dk@excite.com) Date: Tue, 1 May 2001 14:31:03 +0200 Subject: The Haskell kernel Message-ID: <3AE495BD00012269@cpmail.asap.asp.net> In the report on the Haskell programming language (http://www.haskell.org= /onlinereport/), the Haskell kernel is mentionen in several places. It says in section 1.2= that the Haskell kernel is a slightly sugared form of lambda calculus. Fu= thermore most expression should be possible to translate to the Haskell kernel. But where is this kernel defined (I cannot find it in the report) ? Actually the case-expression(section 3.13) seems more fundamental than th= e lambda-expression in Haskell. Several construct translate to the case-exp= ression instead of lambda-expression as the if-expression(section 3.6). It is als= o shown howto translate the lambda-expression into the case-expression in section 3.3. Am I missing something here ? Grateful for any hint. Mads ________________________________________ Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt! From simonpj@microsoft.com Tue May 1 17:22:19 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 1 May 2001 09:22:19 -0700 Subject: The Haskell kernel Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E6A@red-msg-09.redmond.corp.microsoft.com> I'm afraid the "Haskell kernel" isn't formally defined. The Report describes how to translate complex constructs into simpler ones, but neither specifies *exactly* what these simpler ones are, nor gives their meaning in a formal way. Simon | -----Original Message----- | From: ml_dk@sol.dk [mailto:ml_dk@sol.dk]=20 | Sent: 01 May 2001 13:31 | To: Haskell mailinglist | Subject: The Haskell kernel |=20 |=20 |=20 | In the report on the Haskell programming language=20 | (http://www.haskell.org/onlinereport/), | the Haskell kernel is mentionen in several places. It says in=20 | section 1.2 that the Haskell kernel is a slightly sugared=20 | form of lambda calculus. Futhermore most expression should be=20 | possible to translate to the Haskell kernel. |=20 | But where is this kernel defined (I cannot find it in the report) ? |=20 | Actually the case-expression(section 3.13) seems more=20 | fundamental than the lambda-expression in Haskell. Several=20 | construct translate to the case-expression instead of=20 | lambda-expression as the if-expression(section 3.6). It is=20 | also shown howto translate the lambda-expression into the=20 | case-expression in section 3.3. Am I missing something here ? |=20 | Grateful for any hint. |=20 | Mads |=20 |=20 |=20 | ________________________________________ | F=E5 din egen webmail p=E5 http://mail.sol.dk - gratis og med dig = overalt! |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From senganb@ia.nsc.com Wed May 2 01:58:07 2001 From: senganb@ia.nsc.com (Sengan) Date: Tue, 01 May 2001 20:58:07 -0400 Subject: Interesting: "Lisp as a competitive advantage" Message-ID: <3AEF5B9F.88D92A76@ia.nsc.com> http://www.paulgraham.com/paulgraham/avg.html I wonder how Haskell compares in this regard. Any comment from Haskell startups? (eg Galois Connections) Sengan From matth@mindspring.com Wed May 2 02:42:34 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 01 May 2001 20:42:34 -0500 Subject: User defined Ix instances potentially unsafe Message-ID: <3AEF660A.87AF9D6C@mindspring.com> Sorry if this has been reported before. I shouldn't be able to crash ghc or hugs without using any "unsafe" features, right? Well, here 'tis: > module CrashArray where > > import Array > import Ix > > newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show) > > instance Enum CrashIx where > toEnum x = (CrashIx x) > fromEnum (CrashIx x) = x > > instance Ix CrashIx where > inRange (_,_) _ = True > index (_,_) (CrashIx x) = x > range (x,y) = [x..y] > > myArray = listArray (CrashIx 0, CrashIx 0) [0] > crash = myArray ! (CrashIx maxBound) In ghci-5.00, I get a segfault and hugs-feb-2000 says: INTERNAL ERROR: Error in graph Now, admittedly my Ix instance is broken, but I don't think I should be able to segfault the interpreter. Unfortunately, I think the only way to fix this without changing the Library Report would be to add another layer of range checking to the array implementation. Bleh. Note also that the (inefficient) implementation in the report wouldn't crash, but would get the "wrong" error: "Undefined array element" instead of "Index out of range". I think we might describe this as a bug in the Library Report, rather than in any particular Haskell implementation. Enjoy! Matt Harden From chak@cse.unsw.edu.au Wed May 2 08:21:00 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Wed, 02 May 2001 17:21:00 +1000 Subject: Interesting: "Lisp as a competitive advantage" In-Reply-To: <3AEF5B9F.88D92A76@ia.nsc.com> References: <3AEF5B9F.88D92A76@ia.nsc.com> Message-ID: <20010502172100G.chak@cse.unsw.edu.au> Sengan wrote, > http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. > Any comment from Haskell startups? (eg Galois Connections) I already see John Launchbury asking us not to teach Haskell anymore ;-) Manuel From lordcrucifix@yahoo.com Wed May 2 09:31:54 2001 From: lordcrucifix@yahoo.com (lynn yeong) Date: Wed, 2 May 2001 01:31:54 -0700 (PDT) Subject: List of words Message-ID: <20010502083154.19873.qmail@web14208.mail.yahoo.com> --0-1918502651-988792314=:18992 Content-Type: text/plain; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992 Content-Type: text/html; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks!

Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992-- From uk1o@rz.uni-karlsruhe.de Wed May 2 09:34:31 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Wed, 2 May 2001 10:34:31 +0200 Subject: List of words In-Reply-To: <20010502083154.19873.qmail@web14208.mail.yahoo.com>; from lordcrucifix@yahoo.com on Wed, May 02, 2001 at 01:31:54AM -0700 References: <20010502083154.19873.qmail@web14208.mail.yahoo.com> Message-ID: <20010502103428.B7733@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:31:54AM -0700, lynn yeong wrote: > Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! [please wrap your lines!] How about this: import Char(toUpper) capitalize :: String -> String capitalize [] = [] capitalize (c:cs) = toUpper c : cs capitalizeList :: [String] -> [String] capitalizeList = map capitalize Kind regards, Hannah. From ashley@semantic.org Wed May 2 09:42:55 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 01:42:55 -0700 Subject: List of words Message-ID: <200105020842.BAA13085@mail4.halcyon.com> At 2001-05-02 01:34, Hannah Schroeter wrote: >How about this: > >import Char(toUpper) > >capitalize :: String -> String >capitalize [] = [] >capitalize (c:cs) = toUpper c : cs > >capitalizeList :: [String] -> [String] >capitalizeList = map capitalize ...or if you prefer... capitalizeList :: [String] -> [String] capitalizeList = map (map toUpper) -- Ashley Yakeley, Seattle WA From rjmh@cs.chalmers.se Wed May 2 09:51:58 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 10:51:58 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105020851.KAA15484@muppet30.cs.chalmers.se> (B) Monomorphism restriction "wins" Bindings that fall under the monomorphism restriction can't be generalised Always generalise over implicit parameters *except* for bindings that fall under the monomorphism restriction Consequences * Inlining isn't valid in general * No unexpected loss of sharing * Simple bindings like z = ?y + 1 accepted (get value of ?y from binding site) (C) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised, EXCEPT for implicit parameters Consequences * Inlining remains valid * Unexpected loss of sharing (from the extra generalisation) * Simple bindings like z = ?y + 1 accepted (get value of ?y from occurrence sites) Discussion ~~~~~~~~~~ None of these choices seems very satisfactory. But at least we should decide which we want to do. It's really not clear what is the Right Thing To Do. If you see z = (x::Int) + ?y would you expect the value of ?y to be got from the *occurrence sites* of 'z', or from the valuue of ?y at the *definition* of 'z'? In the case of function definitions, the answer is clearly the former, but less so in the case of non-fucntion definitions. On the other hand, if we say that we get the value of ?y from the definition site of 'z', then inlining 'z' might change the semantics of the program. Choice (C) really says "the monomorphism restriction doesn't apply to implicit parameters". Which is fine, but remember that every innocent binding 'x = ...' that mentions an implicit parameter in the RHS becomes a *function* of that parameter, called at each use of 'x'. Now, the chances are that there are no intervening 'with' clauses that bind ?y, so a decent compiler should common up all those function calls. So I think I strongly favour (C). Indeed, one could make a similar argument for abolishing the monomorphism restriction altogether. I disagree. I think it's important to have a simple model of how many times expressions are evaluated. Function bodies are clearly evaluated many times, once for each call, but non-function bindings should be evaluated at most once to respect call-by-need semantics. Breaking the monomorphism restriction in ANY case makes both space and time cost of evaluation unpredictable, and brittle when program changes elsewhere introduce or remove an implicit parameter. It isn't good enough to say `the chances are' that a program has, for example, linear time and constant space complexity: the programmer should be able to convince himself of such properties. As far as what one would `expect', it's in the very nature of dynamic binding that it makes the meaning of an expression depend on its context. I for one would certainly not expect that inlining a definition bound to such an expression should preserve its meaning! Inlining changes the context, so `of course' can change the meaning. So I strongly prefer (B)! John Hughes From karczma@info.unicaen.fr Wed May 2 10:51:18 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 02 May 2001 11:51:18 +0200 Subject: List of words References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <3AEFD896.1A168297@info.unicaen.fr> I am relatively new to Haskell. Somebody told me that it is a very good language, because all the people on its mailing list are so nice that they solve all homeworks, even quite silly, of all students around, provided they ask for a solution in Haskell. Is that true, or a little exaggerated? Jerzy Karczmarczuk From rjmh@cs.chalmers.se Wed May 2 12:29:46 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 13:29:46 +0200 (MET DST) Subject: Erlang workshop Message-ID: <200105021129.NAA18088@muppet30.cs.chalmers.se> (apologies if you receive more than one copy of this). Call for abstracts to the Erlang Workshop Firenze, September 2, 2001, in connection with PLI2001=20 (Principles, Logics, and Implementations of high-level=20 programming languages). Scope Contributions are invited on experience with and=20 applications of Erlang, critiques and proposals for=20 extensions, design methods and structuring principles=20 for large functional systems, implementation techniques,=20 programming tools, verification methods, etc. Submitted abstracts should be 2-12 pages, and will be=20 judged on the potential for an interesting presentation. Abstracts should in text, postscript or PDF format and sent to workshop@erix.ericsson.se by May 15, 2001.=20 Authors will be notified of acceptance by June 15, 2001. Authors of accepted abstracts are welcome to submit=20 full papers or additional accompanying materials for=20 inclusion in the informal proceedings by August 15, 2001. Home page of the Erlang workshop http://www.erlang.se/workshop/ Home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome Joe Armstrong, Alteon Websystems Bjarne D=E4cker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee) From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 12:54:38 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 12:54:38 +0100 Subject: List of words In-Reply-To: Message from Jerzy Karczmarczuk of "Wed, 02 May 2001 11:51:18 +0200." <3AEFD896.1A168297@info.unicaen.fr> Message-ID: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Ah, but (i) not all the solutions are correct (sorry Ashley); and (ii) some of the solutions should be recognisable by markers as not the work of a newbie (explicit import lists, map, ...). Essentially, though, your friend is correct. --KW 8-) From ashley@semantic.org Wed May 2 13:19:52 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 05:19:52 -0700 Subject: List of words Message-ID: <200105021219.FAA23304@mail4.halcyon.com> At 2001-05-02 04:54, Keith Wansbrough wrote: >Ah, but (i) not all the solutions are correct (sorry Ashley); That rather depends on what you mean by CAPITALISE, does it not? capitalise, -ize to print or write with capital letters [Chambers] -- Ashley Yakeley, Seattle WA From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 13:27:18 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 13:27:18 +0100 Subject: List of words In-Reply-To: Message from Ashley Yakeley of "Wed, 02 May 2001 05:19:52 PDT." <200105021219.FAA23304@mail4.halcyon.com> Message-ID: > >Ah, but (i) not all the solutions are correct (sorry Ashley); > > That rather depends on what you mean by CAPITALISE, does it not? > > capitalise, -ize to print or write with capital letters [Chambers] I guess so. Maybe someone at Monash University (Australia) would care to enlighten us? >;-> --KW 8-) -- Keith Wansbrough http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory. From jans@numeric-quest.com Wed May 2 08:36:14 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Wed, 2 May 2001 03:36:14 -0400 (EDT) Subject: List of words In-Reply-To: <3AEFD896.1A168297@info.unicaen.fr> Message-ID: On Wed, 2 May 2001, Jerzy Karczmarczuk wrote: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Not really. No one wants to answer my questions. :-) Do you think that this list is the only source of easy solutions? See what people ask Google and what Google sends to our web server: procedural+design+for+a+program+that+accepts+a+string +as+input+and+then+converts+all+upper+case+to+lower+case +and++vice-versa+and+prints+resulting+string+as+output Must be a tough and generic problem. Notice that Haskell is not mentioned here at all, but yet Google happily directed it to one of Haskell pages here. By the way, this is not the longest question that I've seen in the logs. Some are so long and weird that must match any web page out there. Jan From ralf@cs.uu.nl Tue May 1 17:47:11 2001 From: ralf@cs.uu.nl (Ralf Hinze) Date: Tue, 01 May 2001 18:47:11 +0200 Subject: 2001 Haskell Workshop: final call for papers Message-ID: <3AEEE88F.1BA9E9BC@cs.uu.nl> ============================================================================ FINAL CALL FOR PAPERS [Deadline for submission: 1st June 2001] 2001 Haskell Workshop Firenze, Italy, 2nd September 2001 The Haskell Workshop forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/people/ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. Submission details ------------------ Deadline for submission: 1st June 2001 Notification of acceptance: 12th July 2001 Final submission due: 1st August 2001 Haskell Workshop: 2nd September 2001 Authors should submit papers in postscript format, formatted for A4 paper, to Ralf Hinze (ralf@cs.uu.nl) by 1st June 2001. Use of the ENTCS style files is strongly recommended. The length should be restricted to the equivalent of 5000 words (which is approximately 24 pages in ENTCS format, or 12 pages in ACM format). Note that this word limit represents a change from the first call for papers. Application letters and functional pearls should be labeled as such on the first page; they may be any length up to the above limit, though shorter submissions are welcome. The accepted papers will initially appear as a University of Utrecht technical report, and subsequently be published as an issue of Electronic Notes in Theoretical Computer Science. Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================ From rossberg@ps.uni-sb.de Wed May 2 18:07:31 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Wed, 02 May 2001 19:07:31 +0200 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF03ED3.754BD3F3@ps.uni-sb.de> John Hughes wrote: > > I think it's important to have a simple model of how many > times expressions are evaluated. Function bodies are clearly > evaluated many times, once for each call, but non-function > bindings should be evaluated at most once to respect > call-by-need semantics. Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From uk1o@rz.uni-karlsruhe.de Wed May 2 23:44:54 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 3 May 2001 00:44:54 +0200 Subject: List of words In-Reply-To: <200105020842.BAA13085@mail4.halcyon.com>; from ashley@semantic.org on Wed, May 02, 2001 at 01:42:55AM -0700 References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <20010503004453.A14362@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:42:55AM -0700, Ashley Yakeley wrote: > At 2001-05-02 01:34, Hannah Schroeter wrote: > >capitalize (c:cs) = toUpper c : cs > >capitalizeList = map capitalize > ...or if you prefer... > capitalizeList :: [String] -> [String] > capitalizeList = map (map toUpper) I understood "capitalize" as toUpper only the *first* character of a string. Your capitalizeList at least isn't denotationally the same as mine. hannahCapitalizeList ["this", "is", "a", "fox"] === ["This", "Is", "A", "Fox"] ashleyCapitalizeList ["this", "is", "a", "fox"] === ["THIS", "IS", "A", "FOX"] Kind regards, Hannah. From erik@meijcrosoft.com Thu May 3 01:57:34 2001 From: erik@meijcrosoft.com (Erik Meijer) Date: Wed, 2 May 2001 17:57:34 -0700 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <006401c0d36c$0af45f90$34b11eac@redmond.corp.microsoft.com> > [...many lines deleted...] > I think it's important to have a simple model of how many times expressions > are evaluated. Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Breaking the monomorphism restriction in ANY case > makes both space and time cost of evaluation unpredictable, and brittle when > program changes elsewhere introduce or remove an implicit parameter. It isn't > good enough to say `the chances are' that a program has, for example, linear > time and constant space complexity: the programmer should be able to convince > himself of such properties. But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. > As far as what one would `expect', it's in the very nature of dynamic binding > that it makes the meaning of an expression depend on its context. I for one > would certainly not expect that inlining a definition bound to such an > expression should preserve its meaning! Inlining changes the context, so > `of course' can change the meaning. So I strongly prefer (B)! > > John Hughes > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From nikhil@acm.org Thu May 3 02:19:57 2001 From: nikhil@acm.org (Rishiyur S. Nikhil) Date: Wed, 02 May 2001 21:19:57 -0400 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF0B23D.B703F8D4@mediaone.net> John Hughes wrote: > ... Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Isn't this a very fragile distinction? It seems so susceptible to routine program transformations by both programmers and compilers (e.g., lambda lifting/unlifting, which can change a non-function finding into a function binding and vice versa). Also, I agree with Andreas Rossberg's observation: > ... the Haskell Report ... does not even > demand call-by-need evaluation (it only speaks of non-strict > semantics). Nikhil From matth@mindspring.com Thu May 3 03:39:13 2001 From: matth@mindspring.com (Matt Harden) Date: Wed, 02 May 2001 21:39:13 -0500 Subject: User defined Ix instances potentially unsafe References: <3AEF660A.87AF9D6C@mindspring.com> Message-ID: <3AF0C4D1.AB12C703@mindspring.com> Matt Harden wrote: > blah, blah, blah, bug in the Library Report, blah, blah... OK, so I failed to read the Library Report. It clearly states: > An implementation is entitled to assume the following laws about these operations: > > range (l,u) !! index (l,u) i == i -- when i is in range > inRange (l,u) i == i `elem` range (l,u) So my "bug" is only in my mind. Sorry for bothering everyone. Regards, Matt From Critterrathman@aol.com Thu May 3 07:54:26 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 02:54:26 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_da.5caeee1.28225aa2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman --part1_da.5caeee1.28225aa2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While
trying to learn a little more about how to use them, I keep running into
problem. The existential types work great for code that I constructed if the
functions take a single argument. However, if the function takes more than
one argument, I can't seem to figure out how to get them to work.

In the test code below, everything compiles in Hugs (hugs98-Feb2001) except
the last line in the instance declaration (setx). Is there something
fundamental that I'm missing about how to create an existential instance
and/or data declaration - given the listed class definition?

module Test

  where

  class Shape a where
     getx :: a -> Int
     setx :: a -> Int -> a

  data ExistentialShape =
     forall a. Shape a => MakeExistentialShape a

  instance Shape ExistentialShape where
     getx (MakeExistentialShape a) = getx a
     setx (MakeExistentialShape a) newx = setx a newx

-- here's the error message I get when I try to :load the module
ERROR test.hs:14 - Type error in instance member binding
*** Term           : setx
*** Type           : ExistentialShape -> Int -> _12
*** Does not match : ExistentialShape -> Int -> ExistentialShape
*** Because        : cannot instantiate Skolem constant

Thanks,
Chris Rathman --part1_da.5caeee1.28225aa2_boundary-- From simonpj@microsoft.com Thu May 3 08:13:23 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 00:13:23 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> | As far as what one would `expect', it's in the very nature of=20 | dynamic binding that it makes the meaning of an expression=20 | depend on its context. I for one would certainly not expect=20 | that inlining a definition bound to such an=20 | expression should preserve its meaning! Inlining changes the=20 | context, so `of course' can change the meaning. So I strongly=20 | prefer (B)! John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. (For ordinary type classes, the monomorphism restriction will reject some programs that would otherwise be well typed;=20 for implicit parameters, (B) will accept the program but with --- potentially ---- a different meaning.) b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon From rjmh@cs.chalmers.se Thu May 3 08:48:20 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 09:48:20 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030748.JAA05638@muppet30.cs.chalmers.se> But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. I don't buy that. You could equally well say a term with a free variable is a "function" (of the environment): sure it is, but if it's bound with a let then the function is called only once. John From rjmh@cs.chalmers.se Thu May 3 09:02:10 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:02:10 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030802.KAA05827@muppet30.cs.chalmers.se> Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. Well, the Haskell Report may not require call-by-need semantics, but it permits it at least. Without the MR that would not be the case: some programs would *require* call-by-name. Actually I would prefer the report to be much more explicit about both sharing and evaluation order, to enable compiler-independent reasoning about time and space behaviour. As it stands, compilers do in fact implement call-by-need, and so one can in practice reason fairly safely about time behaviour, but they vary in the choice of evaluation order, which makes space leaks come and go on different compilers. In any case, I don't buy the argument that because reasoning about costs is already problematic in Haskell, it doesn't matter if we make it even harder...! > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. I have no faith in compiler warnings. For one thing, they're irritating. For another, you don't see them when it matters -- when you *read* the code. I'd far rather explicitly distinguish call-by-name and call-by-value in the source code (and made a suggestion along these lines some time ago), so that the semantics is visible to all. Of course, we can't forbid the programmer to write inefficient programs. But we can make gross inefficiencies easier or harder to find. Haskell just can't be used in practice unless one tracks down and fixes space leaks. I don't want to be debugging "time leaks" caused by unexpected call-by-name as well! -- Andreas Rossberg, rossberg@ps.uni-sb.de John Hughes From jeff@nwlewis.com Thu May 3 09:12:02 2001 From: jeff@nwlewis.com (Jeffrey R. Lewis) Date: Thu, 03 May 2001 01:12:02 -0700 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF112D2.B0DEBD9A@nwlewis.com> Simon Peyton-Jones wrote: > | As far as what one would `expect', it's in the very nature of > | dynamic binding that it makes the meaning of an expression > | depend on its context. I for one would certainly not expect > | that inlining a definition bound to such an > | expression should preserve its meaning! Inlining changes the > | context, so `of course' can change the meaning. So I strongly > | prefer (B)! > > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. > Certainly a point well worth thinking about... > > > b) That whether or not a definition is unconditionally inlinable > at the source-language level cannot be determined by looking > at the expression. You have to do something rather like effects > analysis: look to see if it calls any function (transitively) that > uses > an implicit parameter. This apparently esoteric effects analysis is called `type inference' ;-) Oh for better programming environments where it's easy to ask questions about the types of things. But the fun thing is, a) that analysis is way too conservative, and b) it is not even necessary in order to actually do the inlining safely. To do the inlining, you have to be careful to observe any `with' bindings that *statically scope* over the location of the inlining, and do some dynamic variable renaming to avoid capture. Yes, this isssue is well worth thinking about from a design decision point of view, but the situation is not as dire as it seems at first sight. --Jeff From rjmh@cs.chalmers.se Thu May 3 09:22:24 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:22:24 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030822.KAA06145@muppet30.cs.chalmers.se> John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. At present, adding a type signature changes both the static semantics and the cost of running a program -- one should already understand that a type signature with a non-empty context means the expression is evaluated at its uses rather than at its definition. Given that one understands that, and that an expression which uses an implicit parameter will have a type signature which explicitly indicates that, I don't think this is really such a big deal. b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon Are you sure this second one really holds? I claim the effects analysis is just type inference! If the expression has a context referring to an implicit parameter, then it cannot be unconditionally inlined -- it's as simple as that, isn't it? Admittedly, this really only solves the problem for the compiler -- the poor programmer may have more trouble doing type inference in his head. (How much easier life would be with = for call-by-name, := for call-by-need...) So maybe not so dire as you made out! John From ashley@semantic.org Thu May 3 09:57:33 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 3 May 2001 01:57:33 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105030857.BAA20037@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >| In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: >| >| class X a b | a -> b where x :: a; >| class (X a b) => Y a b | a -> b where y :: a; >| instance (X a b) => Y a b where y = x; >| instance (Num a) => X a a where x = 0; -- line A > >Quite right too! The final instance declaration says that the two >arguments of X must always be the same: Hmm... > * the class says a->b Yes. > * the instance matches any first arg I was rather hoping that the instance would match only (Num a => a) rather than (a). > and says that the second must be equal. Yes. -- Ashley Yakeley, Seattle WA From qrczak@knm.org.pl Thu May 3 09:15:06 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 08:15:06 GMT Subject: Existential Type Declarations in Hugs References: Message-ID: Thu, 3 May 2001 02:54:26 EDT, Critterrathman@aol.com pisze: > class Shape a where > getx :: a -> Int > setx :: a -> Int -> a > > data ExistentialShape = > forall a. Shape a => MakeExistentialShape a > > instance Shape ExistentialShape where > getx (MakeExistentialShape a) = getx a > setx (MakeExistentialShape a) newx = setx a newx Should be: setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a newx) The result of setx must have the same type as its first argument. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Thu May 3 09:42:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:42:10 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E99@red-msg-09.redmond.corp.microsoft.com> | In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: |=20 | class X a b | a -> b where x :: a; | class (X a b) =3D> Y a b | a -> b where y :: a; | instance (X a b) =3D> Y a b where y =3D x; | instance (Num a) =3D> X a a where x =3D 0; -- line A Quite right too! The final instance declaration says that the two arguments of X must always be the same: * the class says a->b * the instance matches any first arg and says that the second must be equal. So when typechecking the instance for Y a b, a and b are forced to be equal, and that's less general than the instance claims to be. Simon From simonpj@microsoft.com Thu May 3 09:37:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:37:22 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> | a) That adding a type signature can change the dynamic semantics | of the program. This would be the first and only=20 | occurrence of | such behaviour. |=20 | At present, adding a type signature changes both the static=20 | semantics and the cost of running a program=20 That's true: but adopting (B) means that adding a type signature may cause the program to print a different answer! That seems qualitiatively different to giving the same answer only slower or faster; or rejecting the program altogether. Type signatures should specialise a type -- which means that efficiency may increase, or that the program may no longer be typable, but surely it shouldn't change the answer! =20 | Are you sure this second one really holds? I claim the=20 | effects analysis is just type inference!=20 Indeed it is. I just don't want programmers to have to do type=20 inference in their heads to figure out the meaning of the program. Simon From lennart@mail.augustsson.net Thu May 3 10:33:40 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 05:33:40 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF125F4.E967A796@mail.augustsson.net> Simon Peyton-Jones wrote: > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. Not so, there are already Haskell program that give a different results with and without type signatures. -- Lennart From lennart@mail.augustsson.net Thu May 3 11:29:35 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 06:29:35 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF1330E.B383F42C@mail.augustsson.net> Simon Peyton-Jones wrote: > | a) That adding a type signature can change the dynamic semantics > | of the program. This would be the first and only > | occurrence of > | such behaviour. > | > | At present, adding a type signature changes both the static > | semantics and the cost of running a program > > That's true: but adopting (B) means that adding a type signature > may cause the program to print a different answer! That seems > qualitiatively different to giving the same answer only slower or > faster; > or rejecting the program altogether. Type signatures should specialise > a type -- which means that efficiency may increase, or that the program > may > no longer be typable, but surely it shouldn't change the answer! Try this program: -- Try commenting out this type signature. fun :: (Num a) => a -> Int fun 0 = if fun 1 == 1 then fun 2 else fun (3::Int) g :: (a -> b) -> b g f = f undefined ii = g fun class C a where m :: a -> String instance C Int where m _ = "You have a type signature" instance C Integer where m _ = "You forgot the type signature" main = putStrLn (m ii) -- Lennart PS. There are better examples, but this was all I could think of right now. From qrczak@knm.org.pl Thu May 3 12:50:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 11:50:47 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > Try this program: > -- Try commenting out this type signature. > fun:: (Num a) => a -> Int Test.hs:7: Ambiguous type variable(s) `a' in the constraint `Num a' arising from use of `fun' at Test.hs:7 In the first argument of `g', namely `fun' In the definition of `ii': g fun Test.hs:18: Ambiguous type variable(s) `a' in the constraint `C a' arising from use of `m' at Test.hs:18 In the first argument of `putStrLn', namely `(m ii)' In the definition of `main': putStrLn (m ii) Defaulting applies only when all classes involved are Haskell 98. hbc, nhc98 and Hugs are not conforming. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From lennart@mail.augustsson.net Thu May 3 13:07:10 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 08:07:10 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: <3AF149EE.3C252258@mail.augustsson.net> Marcin 'Qrczak' Kowalczyk wrote: > Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > > Test.hs:7: > Ambiguous type variable(s) `a' in the constraint `Num a' > arising from use of `fun' at Test.hs:7 > In the first argument of `g', namely `fun' > In the definition of `ii': g fun > > Test.hs:18: > Ambiguous type variable(s) `a' in the constraint `C a' > arising from use of `m' at Test.hs:18 > In the first argument of `putStrLn', namely `(m ii)' > In the definition of `main': putStrLn (m ii) > > Defaulting applies only when all classes involved are Haskell 98. First, I cannot parse that sentence, but I assume you mean when all classes are Prelude classes. Second, I'm pretty sure we all agreed that this was a silly rule and should not be in the Haskell definition. I was certain that that it had been removed from the Haskell report, but I guess not. (hbc used to make this check, but I removed it when everyone seemed to agree that rule was a bad idea). Third, moving ii to a different module might still exhibit this problem. (I'm not sure how ghc defaults exported definitions.) But most importantly, this was a bad example. There was a much better one posted on this mailing list a while ago. Does anyone remember it? -- Lennart > > hbc, nhc98 and Hugs are not conforming. From fst@informatik.uni-kiel.de Thu May 3 13:09:01 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Thu, 3 May 2001 14:09:01 +0200 Subject: WFLP 2001 - Final Call for Papers Message-ID: <200105031209.OAA02408@listrac.informatik.uni-kiel.de> ====================================================================== FINAL CALL FOR PAPERS WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming comprising the 10th International Workshop on Functional and Logic Programming and 16th Workshop on Logic Programming Kiel, Germany September 13-15, 2001 ====================================================================== NEW: * Submission guidelines for electronic submissions * Special issue of ENTCS (Electronic Notes in Theoretical Computer Science) for selected papers ---------------------------------------------------------------------- GENERAL WFLP 2001 is the combination of two workshops of a successful series of annual workshops on declarative programming. The international workshops on functional and logic programming aimed at bringing together researchers interested in functional programming, logic programming, as well as their integration. Previous workshops have been held in Benicassim (Spain), Grenoble (France), Bad Honnef (Germany). The workshops on (constraint) logic programming are the annual meeting of the Society of Logic Programming (GLP e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases and artificial intelligence. Previous workshops have been held in Germany, Austria and Switzerland. In this year both workshops will be jointly organized in order to promote the cross-fertilizing exchange of ideas and experiences among researches and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The technical program of the workshop will include invited talks, presentations of refereed papers and demo presentations. The WWW page of the workshop is: http://www.informatik.uni-kiel.de/~wflp2001 ---------------------------------------------------------------------- TOPICS The topics of interest include (but are not limited to): * Functional programming * Logic programming * Constraint programming * Deductive databases * Extensions of declarative languages, objects * Multi-paradigm declarative programming * Foundations, semantics, nonmonotonic reasoning, dynamics * Parallelism, concurrency * Program analysis, abstract interpretation * Program transformation, partial evaluation, meta-programming * Specification, verification, declarative debugging * Knowledge representation, machine learning * Implementation of declarative languages * Advanced programming environments and tools * Applications The primary focus is on new and original research results but submissions describing innovative products, prototypes under development or interesting experiments (e.g., benchmarks) are also encouraged. ---------------------------------------------------------------------- IMPORTANT DATES Submission of papers: May 15, 2001 Notification of acceptance: June 20, 2001 Camera-ready papers: July 20, 2001 Workshop: September 13 - 15, 2001 ---------------------------------------------------------------------- SUBMISSION Authors are invited to submit an extended abstract (no longer than 10 pages including figures and references) or a system description (no longer than 3 pages) in postscript format (11pt) before May 15, 2001. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. *NEW* The details about the procedure to submit papers electronically are described on the workshop website. If you have any problems with submitting papers, please send an email to wflp2001@informatik.uni-kiel.de. ---------------------------------------------------------------------- BEST NEWCOMER AWARD An award will be given to the best paper exclusively written by one or several young researchers who have not yet obtained their PhD degrees. Papers written in this category should be clearly marked "Student papers" in the submission. ---------------------------------------------------------------------- PROCEEDINGS The proceedings with the full versions of all accepted contributions (no longer than 15 pages for regular contributions and 3 pages for system descriptions) will be published as a Technical Report of the University of Kiel. *NEW* A special issue of ENTCS (Electronic Notes in Theoretical Computer Science) containing revised versions of high-quality contributions will be organized after the workshop. ---------------------------------------------------------------------- PROGRAM The workshop will be a 3-day event including presentations of the accepted papers, system demos, and INVITED TALKS by Peter Van Roy (Catholic University of Louvain) Thomas Arts (Ericsson) ---------------------------------------------------------------------- LOCATION WFLP 2001 will take place at the Christian-Albrechts-University of Kiel. More details about the accomodation, traveling information, etc., will be available at the WFLP 2001 WWW page at http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- CONTACT WFLP 2001 Prof. Michael Hanus Institut fuer Informatik und Praktische Mathematik Christian-Albrechts-Universitaet Kiel Olshausenstr. 40 D-24098 Kiel, Germany Phone: ++49-(0)431-880-7271 or -7270 (Secr.) Fax : ++49-(0)431-880-7613 Email: wflp2001@informatik.uni-kiel.de WWW: http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- PROGRAM COMMITTEE Slim Abdennadher (LMU Muenchen) Maria Alpuente (UP Valencia) Sergio Antoy (Portland State University) Christoph Beierle (FernUniv. Hagen) Alexander Bockmayr (Univ. Henri Poincare, Nancy) Harold Boley (DFKI Kaiserslautern) François Bry (LMU Muenchen) Juergen Dix (Univ. Koblenz) Rachid Echahed (IMAG, Grenoble) Uwe Egly (TU Wien) Moreno Falaschi (Univ. Udine) Burkhard Freitag (Univ. Passau) Thom Fruehwirth (LMU Muenchen) Norbert E. Fuchs (Univ. Zuerich) Ulrich Geske (GMD-FIRST Berlin) Michael Hanus (CAU Kiel) Herbert Kuchen (Univ. Muenster) Juan Jose Moreno Navarro (UP Madrid) Mario Rodriguez-Artalejo (UC Madrid) Dietmar Seipel (Univ. Wuerzburg) ---------------------------------------------------------------------- LOCAL ORGANIZING COMMITTEE Wolfgang Goerigk Michael Hanus Klaus Hoeppner Ulrike Pollakowski-Geuther Friedemann Simon Frank Steiner ---------------------------------------------------------------------- From C.Reinke@ukc.ac.uk Thu May 3 13:19:49 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:19:49 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from "Marcin 'Qrczak' Kowalczyk" of "03 May 2001 11:50:47 GMT." Message-ID: > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > Defaulting applies only when all classes involved are Haskell 98. > hbc, nhc98 and Hugs are not conforming. Seems you're right (all classes for the ambiguous type variable need to be from prelude or standard libraries). Okay, so let's try the good old boring show: -- ii :: Double ii = 1 main = case length (show ii) of { 1 -> putStrLn "type signature excluded" ; _ -> putStrLn "type signature included" } Still, I liked Lennart's "magic" version;-) Claus From rossberg@ps.uni-sb.de Thu May 3 13:23:27 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Thu, 03 May 2001 14:23:27 +0200 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: <3AF14DBF.24C85EF1@ps.uni-sb.de> Lennart Augustsson wrote: > > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? No, but this should do it: data T = T Int instance Show T where show (T n) = show n instance Eq instance Num T where fromInteger n = T n (+) (T _) (T _) = T 0 x :: T -- try removing this type signature x = 1 + 2 main = putStr (show x) - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From C.Reinke@ukc.ac.uk Thu May 3 13:31:01 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:31:01 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > > > Try this program: > > > -- Try commenting out this type signature. > > > fun:: (Num a) => a -> Int > > Defaulting applies only when all classes involved are Haskell 98. > > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. (hbc used > to make this check, but I removed it when everyone seemed to > agree that rule was a bad idea). http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-bugs.html (Could it be made more prominent on www.haskell.org that this Haskell98 bugs list is indeed part of Simon's ongoing, soon to be completed revision of the two reports? Just so that people like me notice that the revised reports take priority over whatever the current ones say..) Page 49, Section 4.3.4, Ambiguous Types... In the third paragraph from the end of Section 4.3.4, replace "...an ambiguous type variable is defaultable if at least one of its classes is a numeric class..." by "...an ambiguous type variable, v, is defaultable if v appears only in constraints of the form (C v), where C is a class, and if at least one of its classes is a numeric class...". The new phrase is "if v appears only in constraints of the form (C v) where C is a class". Without this condition the rest of the sentence does not make sense. Claus From qrczak@knm.org.pl Thu May 3 13:48:39 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 12:48:39 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: Thu, 03 May 2001 08:07:10 -0400, Lennart Augustsson pisze: > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. Not only Prelude but the whole Haskell 98 standard library. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. It was not removed, it's still in . So probably it should be removed now: SimonPJ wanted to freeze the revised report in May. > Third, moving ii to a different module might still exhibit this problem. Indeed. > (I'm not sure how ghc defaults exported definitions.) I'm sure that it works as it should: they are defaulted according to visible definitions, to Int or Integer here, and from another module it is not known that the types have been ambiguous, so constraints from non-Haskell-98 classes can't stop the defaulting. This is an argument for removing that part of the defaulting rule. Or for removing the monomorphism restriction. Or both. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From C.Reinke@ukc.ac.uk Thu May 3 14:46:44 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 14:46:44 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? > > -- Lennart Perhaps I should mention a useful application of this game, somewhat unhelpfully named "Representative thingies" in my Haskell corner: http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/ Load the file R.hs in your favourite Hugs (Hugs mode), and you'll see things like this (see comments in R.hs for more examples): Main> foldl (+) 0 [1..4] :: Int 10 Main> foldr (+) 0 [1..4] :: Int 10 Main> foldl (+) 0 [1..4] ((((0 + 1) + 2) + 3) + 4) Main> foldr (+) 0 [1..4] (1 + (2 + (3 + (4 + 0)))) Well, I found it useful (and fun; just a pity that you can't overload (implicit) application in Haskell;-).. Claus From augustss@augustsson.net Thu May 3 15:24:22 2001 From: augustss@augustsson.net (Lennart Augustsson) Date: Thu, 3 May 2001 10:24:22 -0400 (EDT) Subject: Implict parameters and monomorphism Message-ID: <200105031424.f43EOMq11179@hobbessandburst.com> OK, so since noone liked my original example here's another one. It involves no defaulting and no classes in the funny function definition. -- Here's the type signature that makes a difference. --fun :: a -> Char fun x = const (fun x) (fun True) fix f = let x = f x in x class C a where m :: a -> String instance C Char where m _ = "has signature" instance C Bool where m _ = "no signature" main = putStrLn (m (fix fun)) It is not at all surprising that you can write this. Originally type signatures only allowed you to put a signature that was more specific. Polymorhic recursion on the other hand allows you to make the type more general by putting a type signature on a definition. Combining these you can make the signature be incomparable to the deduced type. Using the class system you can then dispatch on the type and get different behaviour. -- Lennart From qrczak@knm.org.pl Thu May 3 16:04:17 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 15:04:17 GMT Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: Wed, 2 May 2001 10:51:58 +0200 (MET DST), John Hughes pisze: > Breaking the monomorphism restriction in ANY case makes both space > and time cost of evaluation unpredictable, and brittle when program > changes elsewhere introduce or remove an implicit parameter. You can always use 'case' instead of 'let' for variable bindings. I would remove the monomorphism restriction, leaving 'let' mostly for function-like bindings, which can be optimized to value bindings in some cases. Perhaps it would be good to introduce strictness annotations in 'let' and 'where'. Clean has 'let!'. It would allow increasing strictness yet more than 'case' does, without the need of transforming 'let' into 'case' or adding `seq`. I would attach '!' to individual variables (or patterns) rather than to 'let', so it's usable in 'where', 'case' and function arguments, with some bindings strict and others lazy. The semantics would insert var `seq` at the start of the appropriate body or rhs for each strict-marked var, in unspecified order (it doesn't matter in what order they are evaluated, it matters that all are evaluated). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 (EDT) Subject: FINAL CFP: SAIG'01 In-Reply-To: References:

Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 Subject: FINAL CFP: SAIG'01 In-Reply-To: References:

Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From Critterrathman@aol.com Thu May 3 22:20:06 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 17:20:06 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_cd.61a8300.28232586_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time, qrczak@knm.org.pl writes: > Should be: > setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a > newx) > The result of setx must have the same type as its first argument. > Thanks. That solves my problem. BTW, what is this "Skolem constant" that's referred to in the error message that I received? Chris Rathman --part1_cd.61a8300.28232586_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time,
qrczak@knm.org.pl writes:

Should be:
setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a
newx)
The result of setx must have the same type as its first argument.

Thanks. That solves my problem.

BTW, what is this "Skolem constant" that's referred to in the error message
that I received?

Chris Rathman

--part1_cd.61a8300.28232586_boundary-- From reid@cs.utah.edu Thu May 3 22:26:38 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Thu, 3 May 2001 15:26:38 -0600 Subject: Implict parameters and monomorphism In-Reply-To: Message-ID: > You can always use 'case' instead of 'let' for variable bindings. Except, of course, for top level bindings which is where the monomorphism restriction is usually most noticable. > I would remove the monomorphism restriction, [...] This seems to be a pretty common sentiment but I don't see anyone pointing out that the monomorphism restriction is there for _two_ reasons: 1) The performance issues that are currently getting all the attention. 2) Preventing ambiguity in examples like: [(n,s)] = reads t where the value of "s" (whose type is String) is determined by the type of "n". This example comes from the H'98 report, section 4.5.5 "The Monomorphism Restriction". Unless I missed something, reason (2) prevents us from completely getting rid of the restriction even if we are willing to ignore (1). (Though if our only goal was to solve (2), it may be that the rule could be a lot less restrictive.) -- Alastair Reid From mark@chaos.x-philes.com Thu May 3 22:33:32 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Thu, 3 May 2001 17:33:32 -0400 (EDT) Subject: Existential Type Declarations in Hugs In-Reply-To: Message-ID: On Thu, 3 May 2001 Critterrathman@aol.com wrote: (snip) > BTW, what is this "Skolem constant" that's referred to in the error message > that I received? A combination of http://www.sdsc.edu/~tbailey/teaching/cse151/lectures/chap09a.html and http://cs.wwc.edu/~aabyan/Logic/normal.html may answer that for you. (-: (It was too long ago now for me to remember much, and I'm not sure where my notes are, so I daren't attempt an explanation myself!) -- Mark From qrczak@knm.org.pl Thu May 3 23:23:19 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 22:23:19 GMT Subject: Implict parameters and monomorphism References: Message-ID: Thu, 3 May 2001 15:26:38 -0600, Alastair Reid pisze: >> You can always use 'case' instead of 'let' for variable bindings. > > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. > Unless I missed something, reason (2) prevents us from completely > getting rid of the restriction even if we are willing to ignore (1). Ok. Let's keep (2) and remove (1). ghc -fno-monomorphism-restriction allows polymorphis cases like (2) and they do create ambiguous types like Read a => String. I would treat it as a bug: removing monomorphism restriction should not go that far. Haskell 98 doesn't allow removing it for pattern bindings by supplying a type signature. Here is a crazy idea: either of these ~x = ... x@_ = ... creates a pattern binding, so it's a way of writing it without a type signature if there was no monomorphic restriction :-) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@launchbury.org Thu May 3 22:33:44 2001 From: john@launchbury.org (John Launchbury) Date: Thu, 03 May 2001 14:33:44 -0700 Subject: Implict parameters and monomorphism References: <200105030802.KAA05827@muppet30.cs.chalmers.se> Message-ID: <3AF1CEB8.A992F053@launchbury.org> This whole monomorphism-restriction debate was one that we had when we were writing the implicit parameters paper. We noted the dire impact of the monomorphism restriction, and commented upon it. On reviewing the whole issue again I am forced again to conclude: There Is No Satisfactory Solution. At least not in Haskell as it is at the moment. Again and again I have been forced to conclude, the only thing worse than having the monomorphism restriction is not having the monomorphism restriction. John's point about evaluation sharing is absolutely critical. We have to be able to distinguish between linear and exponential code, and not have the compiler switch from one to the other unpredictably. On the other hand, as Simon points out, having the MR changing program behavior silently is just as bad. And despite Lennart's comment, the situation is Much Worse with implicit parameters than with type classes. Aaarghh!! So what to do? As a quick fix we should just pick one of A, B or C. Maybe A is the right one, prohibiting the problematical situation from arising at all. For the long term, this issue provides strong supporting evidence for John H's suggestion of having two kinds of binding: the by-name binding has generalization (polymorphism, type classes, implicit parameters etc); and by need, without generalization (monomorphic). As a meta comment: it would be good to hear from people who have made extensive use of implicit parameters, to find out how they are really used in practice. This can often provide quite surprising input. For example, in the original paper we argued that implicit bindings should not be recursive, because we expected a certain style of use would be quite common. Now is seems that other usage styles are more common, for which recursive bindings may be better. Oh well. John From rjmh@cs.chalmers.se Fri May 4 08:27:51 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Fri, 4 May 2001 09:27:51 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105040727.JAA26061@muppet30.cs.chalmers.se> > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. This is a matter of taste, and Haskell deliberately supports both a style with and without type signatures on top-level bindings. I'd be sorry to see that change. One good reason for NOT giving inferrable type signatures is that including them makes programs less modifiable: a small local change, such as adding a parameter to a type, may force a large number of consequential changes to type signatures. I've seen cases where programmers refrained from a significant improvement, because of the labour required to update type signatures (which had been included, ironically, to disable the monomorphism restriction!). I'm not saying it's bad to give type signatures, just that there are arguments for both styles, and the language ought not to make either one difficult to use. John From qrczak@knm.org.pl Fri May 4 11:40:34 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 10:40:34 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, > such as adding a parameter to a type, may force a large number of > consequential changes to type signatures. Type synonyms should make this easier. Maybe the language should be improved somewhere here: class context synonyms? unbound type variables on the rhs of type synonyms? specifying parts of a type leaving the rest inferred? These problems shouldn't arise for ensuring evaluation once, where the type is usually monomorphic! It's the other way around which can cause trouble (e.g. there are no class context synonyms). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Fri May 4 11:40:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 4 May 2001 03:40:53 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Now that is a *really* amazing example. I had no idea that polymorphic recursion would do this. =20 I withdraw my claim that a type signature can't change the answer. But I'm worried. Simon | -----Original Message----- | From: Lennart Augustsson [mailto:augustss@augustsson.net]=20 | Sent: 03 May 2001 15:24 | To: C.Reinke@ukc.ac.uk; qrczak@knm.org.pl | Cc: haskell@haskell.org | Subject: Re: Implict parameters and monomorphism |=20 |=20 | OK, so since noone liked my original example here's another=20 | one. It involves no defaulting and no classes in the funny=20 | function definition. |=20 | -- Here's the type signature that makes a difference. | --fun :: a -> Char | fun x =3D const (fun x) (fun True) |=20 | fix f =3D let x =3D f x in x |=20 | class C a where | m :: a -> String |=20 | instance C Char where | m _ =3D "has signature" |=20 | instance C Bool where | m _ =3D "no signature" |=20 | main =3D putStrLn (m (fix fun)) |=20 |=20 | It is not at all surprising that you can write this. =20 | Originally type signatures only allowed you to put a=20 | signature that was=20 | more specific. | Polymorhic recursion on the other hand allows you to make the=20 | type more general by putting a type signature on a=20 | definition. Combining these you can make the signature be=20 | incomparable to the deduced type. Using the class system you=20 | can then dispatch on the type and get different behaviour. |=20 | -- Lennart |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From igloo@earth.li Fri May 4 15:20:02 2001 From: igloo@earth.li (Ian Lynagh) Date: Fri, 4 May 2001 15:20:02 +0100 Subject: Unicode and is* Message-ID: <20010504152002.A14500@stu163.keble.ox.ac.uk> Hi all Is there a reason why isUpper and isLower include all unicode characters of the appropriate class but isDigit is only 0..9? Are there any Haskell unicode libraries around? And is the implementation of unicode support for GHC being discussed/developed anywhere? BTW, The comments in the report (primUnicodeIsUpper -- 'A'..'Z') are also misleading. Thanks Ian From qrczak@knm.org.pl Fri May 4 16:50:37 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 15:50:37 GMT Subject: Unicode and is* References: <20010504152002.A14500@stu163.keble.ox.ac.uk> Message-ID: Fri, 4 May 2001 15:20:02 +0100, Ian Lynagh pisze: > Is there a reason why isUpper and isLower include all unicode > characters of the appropriate class but isDigit is only 0..9? There are also other weirdnesses, e.g. isSpace is specified to work only on ISO-8859-1 spacing characters, and caseless letters are considered uppercase. > Are there any Haskell unicode libraries around? http://www.sourceforge.net/projects/qforeign/ It provides module Char replacement with more full character properties, charset conversion framework, and inefficient IO wrapper with transparent conversion of Handle data. It also provides FFI support, but it's almost the same as in ghc-5.00 now, except that string conversion between C and Haskell takes character encoding into account. It's undocumented except some comments, sorry. QForeign works with ghc >= 4.08 and nhc98 >= 1.01, but depends on Unicode support in the compiler: some bits are disabled when the compiler doesn't support character literals above '\255' (i.e. nhc98 compiled with ghc < 5.00 and probably with itself), the whole Unicode story is disabled when Char has 8 bits (i.e. ghc < 5.00). > And is the implementation of unicode support for GHC being > discussed/developed anywhere? I'm afraid they are not discussed. I received no feedback on Unicode features in qforeign. They are experimental; nobody told me that they are good or wrong, or how to design them better. They are changing very slowly now. I think they will find their way to ghc when they are finished (with total reimplementation of IO, integrating the conversion with buffering, and also using the new FFI), but it would be great if they represented some consensus rather than my thoughts alone. For example I don't like the HsAndC variant of implmenetation of a conversion (ConvBase), but some tests suggest that it's really best to use a Haskell implementation of UTF-32 when called from Haskell and a C implementation when called to work on character arrays, so I don't know how to do it more clearly. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From elf@sandburst.com Fri May 4 19:12:13 2001 From: elf@sandburst.com (Mieszko Lis) Date: Fri, 4 May 2001 14:12:13 -0400 Subject: Implict parameters and monomorphism In-Reply-To: <200105040727.JAA26061@muppet30.cs.chalmers.se>; from rjmh@cs.chalmers.se on Fri, May 04, 2001 at 09:27:51AM +0200 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504141213.E12269@sandburst.com> On Fri, May 04, 2001 at 09:27:51AM +0200, John Hughes wrote: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, such as > adding a parameter to a type, may force a large number of consequential > changes to type signatures. Absolutely -- suppose you add a `trace' somewhere in your program, which conjures up a Show constraint everywhere... -- Mieszko From john@foo.net Fri May 4 19:27:07 2001 From: john@foo.net (John Meacham) Date: Fri, 4 May 2001 11:27:07 -0700 Subject: Implict parameters and monomorphism In-Reply-To: ; from qrczak@knm.org.pl on Fri, May 04, 2001 at 10:40:34AM +0000 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504112707.A474@mark.ugcs.caltech.edu> I have thought about this too. omission of type signatures seems to be an effective catalyst for code re-use yet this benefit is rarely emphasised. I was thinking about ways to make it easier and toyed around with allowing 'unkowns' in type declarations to allow you to specify only the important part of what you want in a type signature without having to over-specify the types. My idea was to allow '_' to be used in type signatures and represent any type. foo s = 4 foo :: _ foo :: _ -> Int foo :: String -> _ foo :: String -> Int would all be valid types (with different meanings) for 'foo'. This would be useful if say, you had to specify a function returned a plain Int to resolve ambiguity but you didn't want to specify the type of the input argument, perhaps because you are in the process of writing/debugging code and know the type will change. this has the nice generalization that all undeclared types are taken to be ':: _' note that this is not universal quantification because that would imply any type will work, where in actuality we just want to use the specific type infered via standard type inference for part of the declaration and specify exactly another part. The reason I didn't make the proposal was because I am not sure how useful such a thing would be in production code, even though there have been many times during the development/discovery process when such a feature would have signifigantly eased incremental development. John On Fri, May 04, 2001 at 10:40:34AM +0000, Marcin 'Qrczak' Kowalczyk wrote: > Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > > > One good reason for NOT giving inferrable type signatures is that > > including them makes programs less modifiable: a small local change, > > such as adding a parameter to a type, may force a large number of > > consequential changes to type signatures. > > Type synonyms should make this easier. Maybe the language should > be improved somewhere here: class context synonyms? unbound type > variables on the rhs of type synonyms? specifying parts of a type > leaving the rest inferred? > > These problems shouldn't arise for ensuring evaluation once, where > the type is usually monomorphic! It's the other way around which can > cause trouble (e.g. there are no class context synonyms). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 4 19:50:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 18:50:30 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: Fri, 4 May 2001 11:27:07 -0700, John Meacham pisze: > My idea was to allow '_' to be used in type signatures and represent > any type. I like it. There were also proposals for '..'. It would be useful in cases analogous to this: import IArray import MArray f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do marr <- thaw arr do some stateful operations on marr freeze marr) where the type of thaw and freeze make the mutable array type ambiguous. A type signature to disambiguate it would have to mention element and index types, which are type variables bound outside, and the state token, which is eaten by runST. So you have to either use a ghc/Hugs extension of pattern or result type signatures, to bind all these types to names, and move the body to a separate function, so the state token is visible - or specify a polymorphic function type signature on freeze alone or use a specialized variant of freeze. It would be nice to write just (marr :: STArray _ _ _) without having to invent types for the state, index and element. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From nr@eecs.harvard.edu Fri May 4 20:02:25 2001 From: nr@eecs.harvard.edu (Norman Ramsey) Date: Fri, 4 May 2001 15:02:25 -0400 Subject: Help wanted with hugs error message Message-ID: <200105041902.PAA06505@labrador.eecs.harvard.edu> I am compiling the following inoffensive source file, dubbed finterp.lhs: '''Interpreter for factors''' > module FactorInterp where > import Ast (Sym) > import Value () > import Factor > result = "*" > exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Hugs reports: ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import But there is no explicit `exp' in any of my other modules: : nr@labrador 1337 ; grep -w exp *.lhs finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Can anyone help me to find an expunge this error? Thanks, Norman From Robert.Ennals@cl.cam.ac.uk Fri May 4 20:06:23 2001 From: Robert.Ennals@cl.cam.ac.uk (Robert Ennals) Date: Fri, 04 May 2001 20:06:23 +0100 Subject: Help wanted with hugs error message In-Reply-To: Your message of Fri, 04 May 2001 15:02:25 -0400. <200105041902.PAA06505@labrador.eecs.harvard.edu> Message-ID: [snip] > Hugs reports: > > ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import > > > But there is no explicit `exp' in any of my other modules: > > : nr@labrador 1337 ; grep -w exp *.lhs > finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] > > > Can anyone help me to find an expunge this error? [snip] "exp" is defined as exponentiation, as part of the "Floating" type class in the standard Prelude - which is imported by default. -Rob From qrczak@knm.org.pl Fri May 4 20:56:24 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 19:56:24 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: 4 May 2001 18:50:30 GMT, Marcin 'Qrczak' Kowalczyk pisze: > f :: (IArray a e, Ix i) => a i e -> a i e > f arr = runST (do > marr <- thaw arr > do some stateful operations on marr > freeze marr) Actually using pattern type signatures alone is almost enough here: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) except that ghc has a small bug: pattern type signatures don't introduce type variables in the 'do' notation, as they do in lambda arguments. Rewriting it to use '>>=' and lambdas instead of 'do' helps: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST ( thaw arr >>= \(marr :: STArray s i e) -> do some stateful operations on marr >> freeze marr) But doesn't solve completely. There is a strange error message "Could not deduce `MArray (STArray s1) e (ST s)' from the context (IArray a e, Ix i)" with two suggested resolutions, both bogus. The problem is with 's': it's not bound by lambda but eaten by runST. I have to move the argument of runST to a separate function, to bind 's' in its result type signature, to be able to use it in the pattern type signature of marr. This situation can be improved. There was a discussion three months ago about making pattern and result type signatures one-way matching. Currently if a part of the type of an argument is not a type variable bound at the given place, I can't write a type variable in the appropriate pattern type signature, but must spell the inferred type. Except that its context is not written. For example changing 'e' in the type of f above into 'Int' makes the type signature on marr illegal: I must write 'STArray s i Int' too. This is especially tricky in the presence of fundeps, because whether a type is fully determined is not necessarily obvious if it's deduced from fundeps. Ghc requires the programmer to manually follow fundeps to infer the same amount that ghc knows, instead of specifying just the part of the type I am interested in. Another bad case is above. The problematic type is not bound by the given lambda, it's not a constant, and it's not bound by a pattern outside either. It's a free type variable of the argument of runST, eaten by runST. There is no way to write it except by moving the body of runST to a separate function with a result type signature. I would like to make pattern and result type signatures one-way matching, like in OCaml: a type variable just gives a name to the given part of the type, without constraining it any way - especially without "negative constraining", i.e. without yielding an error if it will be known more than that it's a possibly constrained type variable... SimonPJ sais he agreed and asked Hugs people what they think, and they didn't reply. This reminds me the 'with' story :-( This change, together with fixing pattern type signatures in 'do', would make the function at the top legal. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Fri May 4 21:10:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 20:10:30 GMT Subject: Help wanted with hugs error message References: Message-ID: Fri, 04 May 2001 20:06:23 +0100, Robert Ennals pisze: > "exp" is defined as exponentiation, as part of the "Floating" > type class in the standard Prelude - which is imported by default. And to fix the problem you may do either of these: * import Prelude hiding (exp) * Use FactorInterp.exp everywhere except the definition. * Choose a different name. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jans@numeric-quest.com Fri May 4 17:10:03 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Fri, 4 May 2001 12:10:03 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer Message-ID: Hoping to get some early feedback I am posting this very preliminary version: http://www.numeric-quest.com/haskell/QuantumComputer.html Jan From Michael.Fliegner@hansenet.de Fri May 4 23:51:41 2001 From: Michael.Fliegner@hansenet.de (Michae Fliegner) Date: Sat, 5 May 2001 00:51:41 +0200 Subject: Question: Hugs as Browser Plug In Message-ID: <01C0D4FD.B0E165F0@GATEWAY> I have - or at least dreamt I had - read about using Hugs as a Netscape Plug In, but can't find that anymore. Any hints - positive or negative? thanks in advance Michael FLiegner From Erik Meijer" Message-ID: <000a01c0d521$a2f9f0a0$0100a8c0@mshome.net> In the good old days, you could use Hugs as a IE scripting engine, but that is not supported anymore. ----- Original Message ----- From: "Michae Fliegner" To: Sent: Friday, May 04, 2001 3:51 PM Subject: Question: Hugs as Browser Plug In > I have - or at least dreamt I had - read about using Hugs as a Netscape > Plug In, but can't find that anymore. Any hints - positive or negative? > > thanks in advance > Michael FLiegner > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From ashley@semantic.org Sat May 5 07:52:40 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Fri, 4 May 2001 23:52:40 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105050652.XAA19806@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >Quite right too! OK, I understand it a bit better now. This code does not compile: -- class X a instance X Bool instance (Num a) => X a -- Can someone explain why the two instances overlap, given that Bool is not an instance of Num? Would it be possible for Haskell to figure out this sort of thing and not complain about it, or would that lead to nasty problems? -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 09:48:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 5 May 2001 18:48:18 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <3AF0C4D1.AB12C703@mindspring.com> References: <3AEF660A.87AF9D6C@mindspring.com> <3AF0C4D1.AB12C703@mindspring.com> Message-ID: <20010505184818.A6194@hg.cs.mu.oz.au> On 02-May-2001, Matt Harden wrote: > Matt Harden wrote: > > > blah, blah, blah, bug in the Library Report, blah, blah... > > OK, so I failed to read the Library Report. It clearly states: > > > An implementation is entitled to assume the following laws about these operations: > > > > range (l,u) !! index (l,u) i == i -- when i is in range > > inRange (l,u) i == i `elem` range (l,u) > > So my "bug" is only in my mind. Sorry for bothering everyone. I don't think it's quite as straight-forward as that. Hugs and ghc may conform to the Library Report, but the behaviour is still undesirable, and IMHO should be fixed. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From Jon.Fairbairn@cl.cam.ac.uk Sat May 5 11:21:10 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Sat, 05 May 2001 11:21:10 +0100 Subject: Anomalous Class Fundep Inference In-Reply-To: Your message of "Fri, 04 May 2001 23:52:40 PDT." <200105050652.XAA19806@mail4.halcyon.com> Message-ID: <29591.989058070@cl.cam.ac.uk> Ashley Yakeley wrote > OK, I understand it a bit better now. This code does not compile: > -- > class X a > instance X Bool > instance (Num a) =3D> X a > -- > Can someone explain why the two instances overlap, given that Bool is n= ot = > an instance of Num? > = > Would it be possible for Haskell to figure out this sort of thing and n= ot = > complain about it, or would that lead to nasty problems? Think what would happen if someone had a module that did define Bool as an instance of Num and imported the class X. -- = J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u= k 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) From msk@post.tepkom.ru Sat May 5 11:46:10 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Sat, 5 May 2001 14:46:10 +0400 (MSD) Subject: Anomalous Class Fundep Inference In-Reply-To: <29591.989058070@cl.cam.ac.uk> Message-ID: On Sat, 5 May 2001, Jon Fairbairn wrote: > Ashley Yakeley wrote > > OK, I understand it a bit better now. This code does not compile: > > -- > > class X a > > instance X Bool > > instance (Num a) => X a > > -- > > Can someone explain why the two instances overlap, given that Bool is not > > an instance of Num? > > > > Would it be possible for Haskell to figure out this sort of thing and not > > complain about it, or would that lead to nasty problems? > > Think what would happen if someone had a module that did define > Bool as an instance of Num and imported the class X. Program will be rejected at point of such import (or instance declaration)? More simple example: importing two different modules with the exactly same instance declarations for some type. Anton Moscal From ashley@semantic.org Sat May 5 12:03:06 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sat, 5 May 2001 04:03:06 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105051103.EAA02114@mail4.halcyon.com> At 2001-05-05 03:21, Jon Fairbairn wrote: >Ashley Yakeley wrote >> OK, I understand it a bit better now. This code does not compile: >> -- >> class X a >> instance X Bool >> instance (Num a) => X a >> -- >> Can someone explain why the two instances overlap, given that Bool is not >> an instance of Num? >> >> Would it be possible for Haskell to figure out this sort of thing and not >> complain about it, or would that lead to nasty problems? > >Think what would happen if someone had a module that did define >Bool as an instance of Num Should give an error. >and imported the class X. Curiously, whereas Hugs -98 rejects this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x instance (Num a) => X a a where x = 0 -- line A -- ...it accepts this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x module P where import M instance (Num a) => X a a where x = 0 -- line A -- i.e., simply moving line A to a different module. In the latter case it claims these: x :: X a a => a y :: Y a a => a -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 15:16:11 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sun, 6 May 2001 00:16:11 +1000 Subject: Implict parameters and monomorphism In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010506001611.B6194@hg.cs.mu.oz.au> On 04-May-2001, Simon Peyton-Jones wrote: > Lennart Augustsson [mailto:augustss@augustsson.net] wrote: > | It is not at all surprising that you can write this. > | Originally type signatures only allowed you to put a > | signature that was more specific. > | Polymorhic recursion on the other hand allows you to make the > | type more general by putting a type signature on a > | definition. Combining these you can make the signature be > | incomparable to the deduced type. Using the class system you > | can then dispatch on the type and get different behaviour. > > Now that is a *really* amazing example. I had no > idea that polymorphic recursion would do this. Blaming polymorphic recursion is not really fair, IMHO. In particular, Mercury allows polymorphic recursion, but does not suffer from this problem, because it's type inference is capable of inferring the correct most general types even for examples that use polymorphic recursion. In contrast, Haskell uses a type inference algorithm which sometimes infers what I would call wrong answers: types which are less general that can be obtained with an explicit type declaration. These types might not be what the programmer had intended, and this can affect a program's meaning and result. The advantage of Haskell's approach is of course that the type inference process is guaranteed to terminate. In contrast, Mercury's type inference process may fail to terminate for certain ill-typed programs. The Mercury compiler uses a user-configurable iteration limit, and rejects programs for which type inference exceeds this limit. In practice this is very very rare. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jans@numeric-quest.com Sat May 5 22:22:06 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Sat, 5 May 2001 17:22:06 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer In-Reply-To: Message-ID: > Hoping to get some early feedback I am posting this > very preliminary version: > http://www.numeric-quest.com/haskell/QuantumComputer.html > > Jan The bug mentioned in the write-up has been fixed and QFT behaves well now. New versions of both files (module and html page) are ready at the same location. Sorry for talking to myself, but the thought of having posted something buggy (in hope of getting some help) really bothered me. Jan From bjpop@cs.mu.OZ.AU Sun May 6 07:58:02 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Sun, 6 May 2001 16:58:02 +1000 (EST) Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <20010506001611.B6194@hg.cs.mu.oz.au> from Fergus Henderson at "May 6, 2001 00:16:11 am" Message-ID: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> > Fergus Henderson wrote: > In contrast, Haskell uses a type inference algorithm > which sometimes infers what I would call wrong answers: > types which are less general that can be obtained with an explicit > type declaration. These types might not be what the programmer had > intended, and this can affect a program's meaning and result. As you have noted there are advantages and disadvantages of both schemes. I will say that the Haskell requirement of type annotations does sometimes catch accidental (and unintended) uses of polymorphic recursion, thus making compile-time errors out of possible run-time errors (I have seen this happen on dozens of occassions with first year students). Granted that this favourable side-effect was probably never a goal of the Haskell scheme, and it does not always work (in the case that a type scheme is provided which is (accidentally) an acceptable solution to the typing problem of a polymorphically recursive binding group). In the case of the Mercury algorithm, I think that it may be useful for some very verbose mode of the compiler to issue a warning that a function/procedure/predicate is used in a polymorphically recursive manner, if only for the occasional circumstance when it results from a typo in the program. > The advantage of Haskell's approach is of course that the type > inference process is guaranteed to terminate. In contrast, > Mercury's type inference process may fail to terminate for > certain ill-typed programs. The Mercury compiler uses > a user-configurable iteration limit, and rejects programs > for which type inference exceeds this limit. If you applied the Mercury algorithm to Haskell (ie used fixed point iteration to search for a type, rather than requiring a type annotation), would the new type inference algorithm accept/reject the same programs as the existing Haskell algorithm? (assuming an arbitrary user-defined iteration limit, and suitable type annotations for the existing Haskell algorithm). >In practice this is very very rare. I would guess that this is very rare because the (intentional) use of polymorphic recursion is rare (for the predominant case of monomorphic recursion the solution to the fixed point iteration would be almost immediate). Regards, Bernie. From fjh@cs.mu.oz.au Mon May 7 02:57:29 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Mon, 7 May 2001 11:57:29 +1000 Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> References: <20010506001611.B6194@hg.cs.mu.oz.au> <200105060658.QAA20373@mulga.cs.mu.OZ.AU> Message-ID: <20010507115728.A18321@hg.cs.mu.oz.au> On 06-May-2001, Bernard James POPE wrote: > > If you applied the Mercury algorithm to Haskell (ie used fixed point iteration > to search for a type, rather than requiring a type annotation), would > the new type inference algorithm accept/reject the same programs as the > existing Haskell algorithm? (assuming an arbitrary user-defined iteration > limit, and suitable type annotations for the existing Haskell algorithm). Yes, I believe so. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Mon May 7 11:04:57 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:04:57 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC8@red-msg-09.redmond.corp.microsoft.com> There's a design space about how vigorous one is about checking for "unsatisfiable" instances when doing overlap things. It's quite a complicated design space that I don't fully understand, which is why GHC at least implements a conservative rule. For example, does one complain about overlap when the instance declarations are defined, or when they are used? Does one assume that new instances can be added "later"? and there is more I think. =20 Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org]=20 | Sent: 05 May 2001 07:53 | To: Haskell List | Subject: RE: Anomalous Class Fundep Inference |=20 |=20 | At 2001-05-03 01:42, Simon Peyton-Jones wrote: |=20 | >Quite right too! |=20 | OK, I understand it a bit better now. This code does not compile: | -- | class X a | instance X Bool | instance (Num a) =3D> X a | -- | Can someone explain why the two instances overlap, given that=20 | Bool is not=20 | an instance of Num? |=20 | Would it be possible for Haskell to figure out this sort of=20 | thing and not=20 | complain about it, or would that lead to nasty problems? |=20 | --=20 | Ashley Yakeley, Seattle WA |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From simonpj@microsoft.com Mon May 7 11:15:16 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:15:16 -0700 Subject: User defined Ix instances potentially unsafe Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> [Here's a possible Haskell 98 Library Ix "typo"] | > > An implementation is entitled to assume the following laws about=20 | > > these operations: | > >=20 | > > range (l,u) !! index (l,u) i =3D=3D i -- when i is in = range | > > inRange (l,u) i =3D=3D i `elem` range (l,u) | >=20 | > So my "bug" is only in my mind. Sorry for bothering everyone. |=20 | I don't think it's quite as straight-forward as that. | Hugs and ghc may conform to the Library Report, but the=20 | behaviour is still undesirable, and IMHO should be fixed. I rather agree with this. But I'm not sure what the fix is. In thinking about this I've realised that there's an assumption in=20 the Ix interface that (*) map index (range (l,u)) =3D [0..rangeSize (l,u)-1] That is, index maps an index densely into the range 0..N where N is the size of the array. Without this assumption, an array implementation would need to store the Int bounds of the array as well as the ix bounds. I bet that no Haskell implementation does this. If this were not so, the implementation of rangeSize in Section 5.2=20 would be utterly wrong rangeSize b@(l,u) =3D index b h + 1 The constraint (*) also specifies that 'range' returns subscripts in increasing order of index. That seems reasonable, but perhaps less important. One could alternatively say=20 (*a) index (l,u) l =3D 0 (*b) index (l,u) u =3D rangeSize (l,u) - 1 In the spirit of making minimal changes/additions to H98, perhaps (*a) and (*b) would be better. Any thoughts? Simon PS: none of this answers Matt's original question which I can rephrase thus: if a user provides implementations of index, range etc that do not obey the specified invariants, can that crash the system? I would rather the answer were 'no'. But that means the implementation would have to check the output of 'index' against the size of the array allocated from the supplied bounds. Which means that in the common case that 'index' also makes such a check there'd be two checks. Unless the compiler was clever enough=20 to eliminate one of them, which isn't easy since one is at the 'ix' type and the other at 'Int'. From R.Crole@mcs.le.ac.uk Fri May 4 17:49:24 2001 From: R.Crole@mcs.le.ac.uk (Roy L. Crole) Date: Fri, 04 May 2001 17:49:24 +0100 Subject: MERLIN Call for Participation Message-ID: CALL FOR PARTICIPATION Workshop on MEchanized Reasoning about Languages with variable bINding (MERLIN 2001) Siena, Italy, June 18-19, 2001 in connection with IJCAR 2001 ********************************** * http://www.mcs.le.ac.uk/merlin * ********************************** **** Early registration: May 15, 2001 **** ********************************** Currently, there is considerable interest in the use of computers to encode (operational) semantic descriptions of programming languages. Such encodings are often done within the metalanguage of a theorem prover or related system. The encodings may require the use of variable binding constructs, inductive definitions, coinductive definitions, and associated schemes of (co)recursion. The aim of this workshop is to provide researchers with a forum to review state of the art results and techniques, and to present recent and new progress in the areas of: + The automation of the metatheory of programming languages, particularly work which involves variable binding. + Theoretical and practical problems of encoding variable binding, especially the representation of, and reasoning about, datatypes defined from binding signatures. IMPORTANT DATES Early registration: **** May 15, 2001 **** MERLIN workshop: June 18, 2001 IJCAR 2001: June 20-23, 2001 REGISTRATION For details of registration, please see the IJCAR 2001 website at http://www.dii.unisi.it/~ijcar/ INVITED TALK Andrew Pitts, University of Cambridge, has agreed to give an invited talk on "A First Order Theory of Names and Binding". ACCEPTED PAPERS Andreas Abel (Carnegie Mellon, USA). A Third-Order Encoding of the Lambda-Mu-Calculus. Gilles Dowek (INRIA, France), Therese Hardin (LIP6, UPMC, France) and Claude Kirchner (LORIA & INRIA, France). A Completeness Theorem for an Extension of First-Order Logic with Binders. Marino Miculan (Udine, Italy). Developing (Meta)Theory of Lambda-Calculus in the Theory of Contexts. Dale Miller (Pennsylvania State, USA). Encoding Generic Judgements. Christine Roeckl (LAMP-DI-EPFL, Switzerland). A First-Order Syntax for the Pi-Calculus in Isabelle/HOL using Permutations. Carsten Schurmann, Dachuan Yu and Zhaozhong Ni (Yale, USA). Case Study: Formal Development of Safe Intermediate Languages. Rene Vestergaard (CNRS-IML, France) and James Brotherston (Edinburgh, UK). The Mechanisation of Barendregt-Style Equational Proofs (the Residual Perspective). PROGRAMME COMMITTEE Simon Ambler (University of Leicester) Roy Crole (Chair; University of Leicester) Amy Felty (University of Ottawa) Andrew Gordon (Microsoft Research, Cambridge) Furio Honsell (University of Udine) Tom Melham (University of Glasgow) Frank Pfenning (Carnegie Mellon University) FURTHER DETAILS For further details about the Workshop, please contact one of + Roy L. Crole, email: R.Crole@mcs.le.ac.uk + Simon J. Ambler, email: S.Ambler@mcs.le.ac.uk + Alberto Momigliano (Local Organizer), email: A.Momigliano@mcs.le.ac.uk at postal address: Department of Mathematics and Computer Science, University of Leicester, University Road, LEICESTER, LE1 7RH, United Kingdom. From simonpj@microsoft.com Mon May 7 12:55:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 04:55:22 -0700 Subject: FW: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> This is the message that Marcin referred to, proposing a change in the semantics of scoped type variables. I may just go ahead and implement it in GHC. (The implementation is easy: delete a couple of lines; and I guess the same is so for Hugs. The question is whether it's a desirable change.) Simon -----Original Message----- From: Simon Peyton-Jones=20 Sent: 08 February 2001 02:32 Cc: Simon Peyton-Jones; qrczak@knm.org.pl Subject: Scoped type variables Dear Huggy people | But for pattern and result type signatures changing the rules makes=20 | sense. | f (x::a) =3D ... | does not mean that x has type "forall a. a" anyway. It should actually | only give the type a name, no matter what it is. |=20 | Similarly, | f (x :: (a,b)) =3D ... | should unify the appropriate type variable with (,), and give names to | monomorphic arguments of (,) used in the call we are in. I must say that I agree with Marcin's point. When we write f x =3D e we mean that x is a name for whatever argument f is given. Marcin argues that the same should apply for=20 f (x :: (a,b)) =3D e Namely, that x is a name for the argument, a is a name for the type of the fst of x, and slly b. Arguments in favour: - It's more like term-variable pattern matching - In the present system, saying (x::a) doesn't mean x's type is really universally quantified -- it may have a type constraint. And there's really a continuum between saying=20 forall a. C a =3D> t[a] and t[Int] because the Int amounts to a rather strong constraint on a. Indeed, when we have functional dependencies, forall a. C Int a =3D> t[a] may indeed be the same as C Int Int =3D> t[Int] - It's simpler; less to explain to the programmer (quite a bit of the GHC documentation on this stuff is to explain what about the universal quantification) Arguments against - It's not what GHC and Hugs do now. It would be an easy change to make, but I'd prefer it if GHC and Hugs stayed in sync over this (modulo release schedules), so I'd be interested in your views. Simon Someone (Jeff?) wrote: | Could you clarify what you are proposing? Is it | something like "let me name that type `a' even tho I know=20 | it's really something more specific"? (i.e. similar to the=20 | current hugs extension, but without the "can't be more=20 | specific than inferred" restriction) Exactly so. For example f (x::a) =3D let y::a =3D x+1 in h x y would be legal even if=20 h :: Int -> Int -> Int The point is that 'a' simply names the type of x, even if that type isn't a type variable. From qrczak@knm.org.pl Mon May 7 16:22:08 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 7 May 2001 15:22:08 GMT Subject: User defined Ix instances potentially unsafe References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: Mon, 7 May 2001 03:15:16 -0700, Simon Peyton-Jones pisze: > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. It is important if elems should return elements in the same order as indices returns indices, and as listArray accepts. I'm afraid that making arrays robust wrt. bogus Ix instances at the cost of further overheads means a larger pressure to avoid Ix at all in other contexts. It's already avoided in Manuel's parallel arrays, and it was a trouble for me for making ghc's Array/UArray/IArray/MArray operations faster - for example there is an better implementation of compare which works only for index types with particular properties, including Int but not (Int,Int), and sticking to 0-based Ints would make this much simpler, as well as making packed strings implemented in terms of UArrays more efficient. There are other problems. The report says that repeated indices in array construction is an error. Ghc doesn't check that and lets later values win. To implement what the report says it would have to be less efficient: avoiding a separate array for marking which elements are initialized would need unsafePtrEq on each store and probably a loop after the construction which would replace missing elements with bottoms which are not unsafePtrEq, so initialization of another array can distinguish absent elements from elements taken from this array. I'm not sure whether I should still use Ix-based arrays in my unified collection experiments etc., which don't fit there well, or say STOP at some point, concentrate on 0-based Int-indexed dynamic vectors with the interface of sequences, optionally adding Array support as a Haskell 98 compatibility kludge. Having mutable arrays with immutable bounds is also a small problem. Generally Ix-based Arrays may become a larger trouble to support than they are really worth. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From fjh@cs.mu.oz.au Mon May 7 17:15:26 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 8 May 2001 02:15:26 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010508021526.A20463@hg.cs.mu.oz.au> On 07-May-2001, Simon Peyton-Jones wrote: > In thinking about this I've realised that there's an assumption in > the Ix interface that > > (*) map index (range (l,u)) = [0..rangeSize (l,u)-1] ... > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. One could alternatively say > > (*a) index (l,u) l = 0 > (*b) index (l,u) u = rangeSize (l,u) - 1 > > In the spirit of making minimal changes/additions to H98, perhaps (*a) > and (*b) would be better. Given that (*a)+(*b) already pin the end-points, I *think* you might as well go all the way and use (*); I don't *think* the extra flexibility of (*a)+(*b) would be useful. Given a type T which satisfies (*a)+(*b) one can defined a new range function which sorts the elements by index range' b@(l,u) = sortBy compareIndex range b where compareIndex x y = compare (index b x) (index b y) and then after renaming range as e.g. unsortedRange and range' as range, the type will now satisfy (*). So for Haskell 200X, (*) would certainly be preferable, IMHO. For Haskell 98, I'm not sure; perhaps it is best to be conservative. > PS: none of this answers Matt's original question which I can rephrase > thus: > if a user provides implementations of index, range etc that do not obey > the specified invariants, can that crash the system? I would rather the > answer were 'no'. I think the answer should be "no, unless the user specified the appropriate compiler option to disable array bounds checking". > But that means the implementation would have to check the output of > 'index' against the size of the array allocated from the supplied bounds. > Which means that in the common case that 'index' also makes such a > check there'd be two checks. If you really want to squeeze the last drops of performance out, then there's always that compiler option to disable array bounds checking... > Unless the compiler was clever enough > to eliminate one of them, which isn't easy since one is at the 'ix' > type and the other at 'Int'. One possible way to eliminate them would be to add an extra method called unchecked_index or __unchecked_index to the Ix class. By default this would do the same as index class Ix t where ... __unchecked_index = index but you could define the instances for the standard library types such as Int, Char, etc. so that they just skip the check and return an out-of-range Int; for array operations such as (!) where you're going to do a range check on the value returned from index, you can safely use __unchecked_index instead. The reason for using a name such as __unchecked_index rather than just unchecked_index would be for strict compatibility with Haskell 98: to avoid clashing with user-defined identifiers, you need to use a name that is reserved for use by the implementation, Unfortunately, unless I missed something, Haskell 98 does seem to reserved any identifiers at all for use by the implementation, other than the standard reserved words, so I think even using a name like `__unchecked_index' here would not be 100% strictly Haskell 98 compatible. I think it would be good enough in practice, though. For Haskell 200X, where strict backwards compatibility is not required, unchecked_index should be introduced as a documented new method for the Ix class. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Mon May 7 20:31:57 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Mon, 7 May 2001 13:31:57 -0600 Subject: User defined Ix instances potentially unsafe In-Reply-To: <20010508021526.A20463@hg.cs.mu.oz.au> Message-ID: > If you really want to squeeze the last drops of performance out, then > there's always that compiler option to disable array bounds checking... If you mean: "disable array bounds checking" == assume that the (possibly user-supplied) Ix instance is correct but still perform the Ix-based range check. [This is the status quo.] "enable array bounds checking" == perform a possibly redundant range check because the Ix instance may be broken then this sounds like an excellent idea. Especially given that Pascal compilers (not exactly new technology) used to do a pretty good job of eliminating redundant bounds checks so I imagine that that redundant check could be eliminated from all the easy cases without too much work. > For Haskell 200X, where strict backwards compatibility is not required, > unchecked_index should be introduced as a documented new method for the > Ix class. Is this enough? Most of the array code I write uses the higher-level operations like fmap and ixmap. Do I need unchecked versions of them too? Can the higher-level operations amortise the cost of those extra bounds checks? I think fmap can but ixmap can't and I haven't considered the others. -- Alastair Reid From mpj@cse.ogi.edu Tue May 8 06:41:27 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Mon, 7 May 2001 22:41:27 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon! | This is the message that Marcin referred to, proposing a change in | the semantics of scoped type variables. I may just go ahead and | implement it in GHC. (The implementation is easy: delete a couple | of lines; and I guess the same is so for Hugs. The question is = whether | it's a desirable change.) I think that it is an undesirable change. For example, the type theoretic and practical implications of the current semantics are known quantities. I'm not aware of similar foundations to support the new semantics. Nor have I seen any believable motivation for the change. For example: | I must say that I agree with Marcin's point. When we write | f x =3D e | we mean that x is a name for whatever argument f is given. Marcin | argues that the same should apply for=20 | f (x :: (a,b)) =3D e | Namely, that x is a name for the argument, a is a name for the type of | the fst of x, and slly b. |=20 | Arguments in favour: | - It's more like term-variable pattern matching Term variables in a pattern are binding occurrences, but type variables are not. Making the latter look more like the former would appear to be a recipe for unnecessary confusion given that that they are actually different. (As an aside, pushing an argument like the above, you might also argue that when we write "f x =3D e" we mean that "f" is a name for whatever function "x" is passed to as an argument. I'm sure we can all agree here: that would definitely be "slly"!) There's good precedent for the current semantics, both in practice (e.g., Standard ML) and in theory (e.g., typed lambda-calculi). It would be a mistake to switch to an untested and unusual semantics, especially without compelling motivating examples. All the best, Mark From simonpj@microsoft.com Tue May 8 08:47:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 00:47:58 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Hi Mark,=20 Thanks for your reply. | | Arguments in favour: | | - It's more like term-variable pattern matching |=20 | Term variables in a pattern are binding occurrences, but type=20 | variables are not. Making the latter look more like the=20 | former would appear to be a recipe for unnecessary confusion=20 | given that that they are actually different. Why do you say "type variables are not"?. When I say f x =3D e I mean "inside e, use x as the name for whatever value is=20 passed as argument to f". Under what Marcin proposes=20 f (x::a) =3D e would mean "inside (type signatures in) e, use a as the name for whatever type is the type of the argument passed to f". When you say there's a good theoretical foundation (typed lambda calcului) I think you are imagining that when we say f (x::a) =3D e we are saying "There's a /\a as well as a \x::a in this definition". In which case it would certainly be wrong to allow f :: Int -> Int f (x::a) =3D e But I'm suggesting something different * Place the big lambdas wherever they would be now (i.e. not influenced by the position of (x::a) type signatures. * Explain the pattern type signatures as let-bindings for types. Thus we might translate f to system-F like this: f =3D \x::T -> let-type a =3D T in e I've use let-type here, but one could equally well say (/\a -> e) T. This (admittedly informal) translation works fine if T happens to be Int, for exampe; i.e. x's type is not universally quantified. =20 In short, the pattern type signature is used solely to bind names to types, and not for universal quantification. I want to have a slightly more elaborate let-type, thus: g :: (Int,Bool) -> Int g (x::(a,b)) =3D e translates to g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e But notice that the RHS of a pattern-matching let-type is statically guaranteed to have the right shape. So I don't allow let-type (a,b) =3D c in ... (where c is a type variable). So it's just syntactic sugar, like let-type itself, and I could equally well write g =3D \x::(Int,Bool) -> let-type a =3D Int; b =3D Bool in e OK, so there are two questions a) does that answer the question about the techincal foundation b) is it a good design from a software engineering point of view I hope the answer to (a) is yes, but I realise that opinions may differ about (b). I thought this might be of general enough interest to be worth continuing to cc the Haskell list. Simon From Gnzgncrls@netscape.net Mon May 7 21:53:52 2001 From: Gnzgncrls@netscape.net (Gian) Date: Tue, 08 May 2001 06:53:52 +1000 Subject: making plurals Message-ID: <3AF70B60.3000205@netscape.net> i was wandering if you would be able to show me how to implement a function which converts a list of words into the plurals say maybe to convert "shelf" into "shelves". I thought maybe with using some kind of recursion, tupples and the prelude function isSuffixOf. but im not sure how to implement it can you help. From Markus Lauer Tue May 8 11:07:48 2001 From: Markus Lauer (Markus Lauer) Date: Tue, 8 May 2001 12:07:48 +0200 (MEST) Subject: question on type classes Message-ID: Is it possible in Haskell to define a type class like Show, which has a generic implementation for Lists and a special one for [Char], but (in contrast to Show) where Char is not in this Class I'd like to have something like the following, but this example doesn't work: ------------------------------------------- module Test where class Foo a where foo :: a -> a .... .... instance FooList a => Foo [a] where foo lst = fooList lst .... .... class FooList a where fooList :: [a] -> [a] .... .... genericImpl :: Foo a => [a] -> [a] genericImpl = ... specialImpl :: String -> String specialImpl = .... instance FooList Char where fooList s = specialImpl s ..... instance Foo a => FooList a where fooList lst = genericImpl lst ..... --------------------------------------------- Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor expected) ghc (5.00) sais Test.hs:20: Illegal instance declaration for `FooList a' (the instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) is there a better way, than to copy the instance declaration of FooList for every a in that is in class Foo? Thanks for any hint, Markus -- Markus Lauer From ashley@semantic.org Tue May 8 11:38:25 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 8 May 2001 03:38:25 -0700 Subject: question on type classes Message-ID: <200105081038.DAA25076@mail4.halcyon.com> At 2001-05-08 03:07, Markus Lauer wrote: >Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor > expected) Invoke as 'hugs -98' to switch on extensions. Hugs will then complain of overlapping instances: instance FooList Char instance Foo a => FooList a Yes, I know Char is not an instance of Foo. See the "Anomalous Class Fundep Inference" thread. -- Ashley Yakeley, Seattle WA From bdhumb@students.cs.mu.OZ.AU Tue May 8 13:44:24 2001 From: bdhumb@students.cs.mu.OZ.AU (Bryn Humberstone) Date: Tue, 8 May 2001 22:44:24 +1000 Subject: making plurals In-Reply-To: <3AF70B60.3000205@netscape.net>; from Gian on Tue, May 08, 2001 at 06:53:52AM +1000 References: <3AF70B60.3000205@netscape.net> Message-ID: <20010508224424.A11969@holly.cs.mu.OZ.AU> Gian, > i was wandering if you would be able to show me how to > implement a function which converts a list of words into the plurals > say maybe to convert "shelf" into "shelves". I thought maybe with using > some kind of recursion, tupples and the prelude function isSuffixOf. but > im not sure how to implement it can you help. I can't help noticing your question sounds remarkably like the sort of assignment question that gets set in a first year university course. Most universities don't allow students to solicit help from mailing lists so you probably should look away now before I reveal the answer. I'm sure that your tutors, lab demonstrators and lecturers will be happy to help you since you sound as though you're quite close to the solution. Nevertheless, I've devised a solution that seems to meet most of your requirements. It is quite inefficient on most words, but it should be a good place to start looking (apart from, say, your lecture notes). import List overallProgram = map makePlural makePlural word = case word of "shelf" -> "shelves" _ -> fst (makePlural word, let foo = "heating" in isSuffixOf foo ('c':foo)) And to the people on the list, please try to resist giving any answers to this or similar problems for the next few weeks as it just makes life more difficult for the students who invariably get caught. I think that the map (map toUpper)/capitalise controversy was originally sparked as a result of a question pertaining to this project as well. Cheers, Bryn From qrczak@knm.org.pl Tue May 8 15:59:20 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 14:59:20 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 00:47:58 -0700, Simon Peyton-Jones pisze: > g = \x::(Int,Bool) -> let-type (a,b) = (Int,Bool) in e > > But notice that the RHS of a pattern-matching let-type is statically > guaranteed to have the right shape. So I don't allow > > let-type (a,b) = c in ... > > (where c is a type variable). Really? I disagree. Making pattern type sygnatures perform unification of the variable with the supplied signature is useful for resolving ambiguities, and backward-compatible (valid programs will remain valid), and doesn't allow "unwanted generality" to cause trouble (when an expression has a more general type than needed). Currently ghc does not accept: (\(x::a) -> x) :: Int->Int but accepts this: (let f = \(x::a) -> x in f) :: Int->Int Hugs accepts both! But it doesn't like (\(x::a) -> (x::Int)) I would make all three legal. Unfortunately it doesn't help for my example: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) unless the type inference could deduce that the constraint MArray (STArray s') e (ST s) in the presence of instance MArray (STArray s) e (ST s) unifies s' with s. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Tue May 8 16:25:39 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 08:25:39 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> | > g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e | >=20 | > But notice that the RHS of a pattern-matching let-type is=20 | statically=20 | > guaranteed to have the right shape. So I don't allow | >=20 | > let-type (a,b) =3D c in ... | >=20 | > (where c is a type variable). |=20 | Really? I disagree. Making pattern type sygnatures perform=20 | unification of the variable with the supplied signature is=20 | useful for resolving ambiguities, and backward-compatible=20 | (valid programs will remain valid), and doesn't allow=20 | "unwanted generality" to cause trouble (when an expression=20 | has a more general type than needed). I was meaning in the translation into System F of the program. Under my proposal (=3D yours) if one writes f (x::(a,b)) =3D e then f is forced to have type f :: (T1, T2) -> ... for some T1, T2. In saying that let-type can't pattern-match against a type variable c, I'm just saying that f cannot have type f :: forall c. c -> .... I think I just didn't express myself well enough. Simon From jefu@cs20.eou.edu Tue May 8 17:33:10 2001 From: jefu@cs20.eou.edu (jefu) Date: Tue, 08 May 2001 09:33:10 -0700 Subject: cross product of lists Message-ID: <200105081633.f48GXAi20714@cs20.eou.edu> This is not a class assignment - indeed I'm a professor who has used haskell in classes (and is currently being fired for having done so - it seems teaching anything other than c++ is questionable). I'd like to have a program that will take a description of a regular language and produce a list of strings in that language in order of size. If the lists are infinite (a* and the like) things work fine, but when the lists are finite, things dont work. I have two programs that I've tried to use and both have been hacked a bit in my process of experimentation so they're not the nicely honed final product I'd like to have. The first is based on my original ideas but with some attempt to cajole the finite/infinite list problem - it still seems to me that this would be a good way to go if possible, but I'm stumped. It is at : http://cs.eou.edu/jefu/reglang.hs The second is built on the idea of remembering if a list is finite or infinite and handling it accordingly. This one manages to segfault hugs and ghci also just quits about half the time (linux, redhat 7). This one is at : http://cs.eou.edu/jefu/nreglang.hs Any suggestions ? jefu -- jeff putnam -- jefu@eou.edu -- http://cs.eou.edu/~jefu From qrczak@knm.org.pl Tue May 8 17:32:53 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 16:32:53 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 08:25:39 -0700, Simon Peyton-Jones pisze: > I was meaning in the translation into System F of the program. [...] Ah, OK, sorry. More strange behavior of Hugs (none of this is allowed by ghc): \(x :: a) (y :: b) -> x+y -- not allowed \(x :: a) -> \(y :: b) -> x+y -- allowed f :: Int->Int->Int; f x = \(y::a) -> x+y -- not allowed f :: Int->Int->Int; f = \x (y::a) -> x+y -- allowed I guess that the constraint that a type is not more specific than a pattern type signature tells is checked once at some point of time. It is rejected only when the type inference determined the more specific type before this check was performed, but it might be determined later which is not caught. I would remove the check altogether. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From ham@cs.utexas.edu Tue May 8 19:01:41 2001 From: ham@cs.utexas.edu (Hamilton Richards) Date: Tue, 8 May 2001 13:01:41 -0500 Subject: cross product of lists In-Reply-To: <200105081633.f48GXAi20714@cs20.eou.edu> Message-ID: At 11:33 AM -0500 5/8/01, jefu wrote: [...] >I'd like to have a program that will take a description of a regular >language and produce a list of strings in that language in order >of size. [...] > > >Any suggestions ? Have a look at http://www.cs.utexas.edu/users/pete/research/enumeration.html. --Ham ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu ------------------------------------------------------------------ From rjchaaft@cs.uu.nl Wed May 9 13:05:56 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 09 May 2001 14:05:56 +0200 Subject: Class RealFrac: round Message-ID: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Hello, While I were writing a RealFrac implementation for BigDouble's (for high-precision computations) I found a strange implementation of round in the standard prelude (from the haskell definition): round x = let (n,r) = properFraction x m = if r < 0 then n - 1 else n + 1 in case signum (abs r - 0.5) of -1 -> n 0 -> if even n then n else m 1 -> m The strange case is if signum (abs r - 0.5) is 0: such numbers are round to the nearest EVEN integer. In mathematics, computer science (the studies I'm doing) and physics, as far as I know, it is usual to round such numbers up, rather than to the nearest integer. For example: Number Hugs Math 0.5 0 1 1.5 2 2 -3.5 -4 -4 6.5 6 7 Why did the Haskell designers choose this behaviour? Thanks in advance, Rijk-Jan van Haaften From lennart@mail.augustsson.net Wed May 9 13:14:11 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Wed, 09 May 2001 08:14:11 -0400 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Message-ID: <3AF93493.A46D22D3@mail.augustsson.net> Rijk-Jan van Haaften wrote: > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): > > round x = > let (n,r) = > properFraction x > m = if r < 0 then n - 1 else n + 1 > in case signum (abs r - 0.5) of > -1 -> n > 0 -> if even n then n else m > 1 -> m > > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: Rounding to the nearest even number is considered the best practice by people doing numerical analysis. Even when I went to school (25 - 30 years ago) we were taught to round to the nearest even number, so it's not exactly new. -- Lennart From karczma@info.unicaen.fr Wed May 9 16:07:21 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 09 May 2001 17:07:21 +0200 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> <3AF93493.A46D22D3@mail.augustsson.net> Message-ID: <3AF95D29.6068FA5@info.unicaen.fr> Lennart Augustsson comment to : > Rijk-Jan van Haaften wrote: ... > > The strange case is if signum (abs r - 0.5) is 0: > > such numbers are round to the nearest EVEN integer. In mathematics, > > computer science (the studies I'm doing) and physics, as far as I > > know, it is usual to round such numbers up, rather than to the nearest > > integer. For example: > ... > Rounding to the nearest even number is considered the best practice by > people doing numerical analysis. Even when I went to school (25 - 30 > years ago) we were taught to round to the nearest even number, so it's > not exactly new. > > -- Lennart I wonder whether it has anything to do with the "best practice". I suppose that this is the natural way to get rid of one more bit of mantissa. Anyway, there is the standard IEEE 754 (with its 4 rounding modes...) and it is good to have a published standard, even if it results in some hangover of some people. The reported behaviour is also visible in Clean, and I spent 2 days on debugging because of that "round-ties-to-even rule"... It is not very "natural" psychologically, and from time to time I do some mistakes, although I know the stuff. Look here: (among 100 other references I could give you) http://www.validgh.com/goldberg/addendum.html http://developer.intel.com/technology/itj/q41999/articles/art_6.htm http://www.cs.umass.edu/~weems/CmpSci535/535lecture6.html Jerzy Karczmarczuk Caen, France From Joe.Bowers@CanopySystems.com Wed May 9 14:09:46 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Wed, 9 May 2001 09:09:46 -0400 Subject: Class RealFrac: round Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/plain I'm not one of the implementors, but this sort of behavior can reduce error in fields where X.5 is a common result- a rule like "The nearest even integer" moves upward half the time and downward half the time- hopefully cancelling itself out. Or maybe they had other reasons... Joe > -----Original Message----- > From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl] > Sent: Wednesday, May 09, 2001 8:06 AM > To: haskell@haskell.org > Subject: Class RealFrac: round > > > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): ... > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: > > Number Hugs Math > 0.5 0 1 > 1.5 2 2 > -3.5 -4 -4 > 6.5 6 7 > > Why did the Haskell designers choose this behaviour? > > Thanks in advance, > > Rijk-Jan van Haaften > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Class RealFrac: round

I'm not one of the implementors, but this sort of = behavior
can reduce error in fields where X.5 is a common = result-
a rule like "The nearest even integer" = moves upward half
the time and downward half the time- hopefully = cancelling
itself out.

Or maybe they had other reasons...
Joe

> -----Original Message-----
> From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl]
> Sent: Wednesday, May 09, 2001 8:06 AM
> To: haskell@haskell.org
> Subject: Class RealFrac: round
>
>
> Hello,
>
> While I were writing a RealFrac implementation = for BigDouble's (for
> high-precision computations) I found a strange = implementation of
> round in the standard prelude (from the haskell = definition):

...

> The strange case is if signum (abs r - 0.5) is = 0:
> such numbers are round to the nearest EVEN = integer. In mathematics,
> computer science (the studies I'm doing) and = physics, as far as I
> know, it is usual to round such numbers up, = rather than to the nearest
> integer. For example:
>
> Number   Hugs    = Math
>   0.5      = 0       1
>   1.5      = 2       2
> -3.5     = -4      -4
>   6.5      = 6       7
>
> Why did the Haskell designers choose this = behaviour?
>
> Thanks in advance,
>
> Rijk-Jan van Haaften
>
>
> = _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>

------_=_NextPart_001_01C0D889.5242C2C0-- From jbw@izanami.cee.hw.ac.uk Wed May 9 13:28:30 2001 From: jbw@izanami.cee.hw.ac.uk (Joe Wells) Date: 09 May 2001 13:28:30 +0100 Subject: RA position @ Heriot-Watt Univ. in program analysis Message-ID: --=-=-= Content-Disposition: inline Research Assistant Position Useful Logics, Types, Rewriting, and Applications (ULTRA) Group Computing and Electrical Engineering Department Heriot-Watt University Edinburgh, Scotland, UK A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland. The RA should either already have skills in some of the following areas and be interested and able to learn about several others: * type systems, especially those with intersection and union types, * static analysis of computer programs, * constraint solving, * higher-order programming languages, * programming language semantics, design, and/or implementation. The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done. The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science. To formally apply for this position, please do the following: * Arrange for 3 letters of reference to be sent. * Send the following yourself: + your complete curriculum vitae, + a brief statement of your research accomplishments and interests and why you think you would be a good match for the job, + web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and + contact details for the people writing your letters of reference. If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected. Applications or inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw@cee.hw.ac.uk fax: +44 131 449 3834 post: Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN --=-=-= Content-Type: text/html Content-Disposition: inline Research Assistant Position

Research Assistant Position

Useful Logics, Types, Rewriting, and Applications (ULTRA) Group
Computing and Electrical Engineering Department
Heriot-Watt University
Edinburgh, Scotland, UK

A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland.

The RA should either already have skills in some of the following areas and be interested and able to learn about several others:

type systems, especially those with intersection and union types,
static analysis of computer programs,
constraint solving,
higher-order programming languages,
programming language semantics, design, and/or implementation.

The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done.

The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science.

To formally apply for this position, please do the following:

Arrange for 3 letters of reference to be sent.
Send the following yourself:
- your complete curriculum vitae,
- a brief statement of your research accomplishments and interests and why you think you would be a good match for the job,
- web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and
- contact details for the people writing your letters of reference.

If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected.

Applications or inquiries should be directed to Joe Wells at:

web:	http://www.cee.hw.ac.uk/~jbw/
e-mail:	jbw@cee.hw.ac.uk
fax:	+44 131 449 3834
post:	Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN

--=-=-=-- From chak@cse.unsw.edu.au Thu May 10 10:26:59 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 10 May 2001 19:26:59 +1000 Subject: ANNOUNCE: Happy 1.10 released In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510192659H.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell An RPM package for x86 RedHat Linux[1] is now available at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm Happy LALRing, Manuel [1] The binary has been build on RH7.0 with glibc2.2. From ml_dk@excite.com Thu May 10 10:56:00 2001 From: ml_dk@excite.com (=?iso-8859-1?Q?Mads_Lindstr=F8m?=) Date: Thu, 10 May 2001 02:56:00 -0700 (PDT) Subject: The definition of lhsfun in the report Message-ID: <24443469.989488562297.JavaMail.imail@ringo.excite.com> I'am confused about the "funlhs" production, in "Report on the programming Language Haskell 98" of the 1st February 1999. In the report one of the "funlhs"-productions is (see page 127): funlhs -> var apat {apat} That is a followed by one to many . But you can have functions like this: fun :: Int fun = 17 That is without any patterns to match, so why is the rule not ? funlhs -> var {apat} That is a followed by zero to many . I will be very happy for an answer to my question. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From franka@cs.uu.nl Thu May 10 12:12:30 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Thu, 10 May 2001 13:12:30 +0200 Subject: The definition of lhsfun in the report In-Reply-To: <24443469.989488562297.JavaMail.imail@ringo.excite.com> Message-ID: > I'am confused about the "funlhs" production, in "Report on the programming > Language Haskell 98" of the 1st February 1999. > > In the report one of the "funlhs"-productions is (see page 127): > > funlhs -> var apat {apat} > > That is a followed by one to many . But you can have functions > like this: > > fun :: Int > fun = 17 This does not declare a function. If you look at the decl production, you will see that there is another possibility, namely pat^0, which provides this syntax. OTOH it is possible to declare a function using pat, e.g.: fun = \x -> x+1 In other words, funlhs is redundant. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791 From luc.taesch@csfb.com Thu May 10 14:07:43 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Thu, 10 May 2001 15:07:43 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. what is the best organisation ? -import module P everywhere - isolate this datatype in a module, which would be imported everywhere ?(very "include like") - merging the module around this datatype ? this last option is not a good option here as : - this would be too big - P is generated by Happy. this look very much like a OO/non OO debate, which I dont want to spawn again. I can suppose its a FAQ like question. any good pointer ? whats the best practice around ? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From alex@shop.com Thu May 10 15:24:51 2001 From: alex@shop.com (S. Alexander Jacobson) Date: Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time) Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: Combining two threads... Like macros and preprocessors, Happy generates code. I assume the justification for this is that hand-coding a parser in Haskell is presumed to be too difficult or that it is too hard to get the right level of abstraction (and therefore a macro-like facility is required). However, I've also used Hutton & Meijer style monadic parsers and found them extremely elegant, clean, and easy to use in both Haskell and Python (though in Python they were too slow for my xml application -- function call overhead is _very_ high in Python). I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? And generalizing from the above, since Monads/Arrows are types that describe a computation declaratively and Macros are functions that describe a computation procedurally, is it possible that, for any application of Macros, you can find a suitable Monad/Arrow? Or am I not understanding either well enough? -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) From kort@science.uva.nl Thu May 10 15:36:25 2001 From: kort@science.uva.nl (Jan Kort) Date: Thu, 10 May 2001 16:36:25 +0200 Subject: sharing datatypes : best practice ? References: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> Message-ID: <3AFAA769.D699EE5F@wins.uva.nl> "Taesch, Luc" wrote: > > i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. > > what is the best organisation ? > > -import module P everywhere > - isolate this datatype in a module, which would be imported everywhere ?(very "include like") > - merging the module around this datatype ? > > this last option is not a good option here as : > - this would be too big > - P is generated by Happy. Hi Luc, Isolating the datatype in a module is what I always do. Only "Main.hs" calls the happy parser and just about every module uses the datatype, so it makes sense to separate them. Jan From simonmar@microsoft.com Thu May 10 15:42:00 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 10 May 2001 15:42:00 +0100 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) Message-ID: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on=20 > macros, I > have to ask: why use happy rather than monadic parsing? =20 > Monadic parsing > allows you to avoid a whole additional language/compilation=20 > step and work > in Hugs (where you don't have a makefile). What does Happy=20 > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon From cwitty@newtonlabs.com Thu May 10 18:48:52 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 10 May 2001 10:48:52 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "S. Alexander Jacobson"'s message of "Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)" References: Message-ID: "S. Alexander Jacobson" writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? I've used Happy instead of parser combinators because I wanted the additional global error-checking. I believe that the standard implementations of parser combinators will allow you to specify an ambiguous grammar, and return one of the multiple possible parses, without warning. Carl Witty From qrczak@knm.org.pl Thu May 10 20:13:05 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 10 May 2001 19:13:05 GMT Subject: Fundeps and class contexts Message-ID: Would allowing this make sense? class C a b | a -> b class C a b => S a I want to simulate a particular "class synonym" (with four superclasses instead of one C here) where the type 'b' is uninteresting for its users. Currently I have to write class C a b | a -> b class C a b => S a b | a -> b and use f :: S a b => T(a) instead of f :: S a => T(a) even though T(a) usually doesn't contain b. If it does, I would write f :: (S a, C a b) => T(a) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@foo.net Thu May 10 22:22:04 2001 From: john@foo.net (John Meacham) Date: Thu, 10 May 2001 14:22:04 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Thu, May 10, 2001 at 03:42:00PM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510142203.A16027@mark.ugcs.caltech.edu> Just out of curiosity, has anyone done any work at benchmarking the various parsers? I use Parsec pretty exclusivly since it comes with ghc and is pretty straightforward and lightweight to use. I am wondering what I am giving up in terms of speed by going that route, rather than Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm... John On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote: > > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From johnsson@crt.se Fri May 11 08:01:04 2001 From: johnsson@crt.se (Thomas Johnsson) Date: Fri, 11 May 2001 09:01:04 +0200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: <15099.36400.547112.275888@spitfire.crt.se> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? Happy and others like it generate an LR parser, which is a well-established technology since the late 60's (Knuth): efficient, deterministic, and checks the grammar for you. Parser combinators are usually nondeterministic ie backtracking (pre-Knuth!:-) though Cleverly Disguised in Haskell Higher Order clothes.... LR parsers gives you greated freedom in expressing the grammar, with the LR parser generator leaning over your shoulder. Grammars possible with parsing combinators are more constrained: cannot use left recursion, order of rules matters, etc. On the other hand, one has the whole abstraction machinery of Haskell or whatever at hand for writing the grammar rules. The analogy that comes to mind is statically typed languages vs runtime typed ones. --Thomas PS would be cool to try to marry the two approaches.... From chak@cse.unsw.edu.au Fri May 11 08:09:44 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Fri, 11 May 2001 17:09:44 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010511170944K.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). I don't think, the point is the test for non-ambiguity. At least, Doitse's and my self-optimising parser combinator library will detect that a grammar is ambigious when you parse a sentence involving the ambiguous productions. So, you can check that by parsing a file involving all grammar constructs of the language. The point is much more the level of help that you get if your grammar happens to be ambiguous. My combinators at the moment just tell you that the grammar is ambiguous, but provide no help as to where and why. I think, this is similar for Doitse's combinators. Happy helps you much more in this situation. Cheers, Manuel From luc.taesch@csfb.com Fri May 11 08:53:00 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:53:00 +0200 Subject: haskell wiki wiped ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CD@szrh00313.tszrh.csfb.com> i tried to acces the hasakell wiki ? it s just all blank. has it been purged ? i remember having seen some idioms ... This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From luc.taesch@csfb.com Fri May 11 08:56:37 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:56:37 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CF@szrh00313.tszrh.csfb.com> do u isolate just the datatype, or a few related with, in a very small file (header like, i would say) or some basic accessor function with it ? isnt it leading to massiv quantities of small files ? > -----Original Message----- > From: Jan Kort [mailto:kort@science.uva.nl] > Sent: Donnerstag, 10. Mai 2001 16:36 > To: Taesch, Luc > Cc: 'haskell@haskell.org' > Subject: Re: sharing datatypes : best practice ? > > > "Taesch, Luc" wrote: > > > > i ve developped a datatype in a module P, and another > module will use it, and most probably a few others, and its > quite central to the apps Im building. > > > > what is the best organisation ? > > > > -import module P everywhere > > - isolate this datatype in a module, which would be > imported everywhere ?(very "include like") > > - merging the module around this datatype ? > > > > this last option is not a good option here as : > > - this would be too big > > - P is generated by Happy. > > Hi Luc, > Isolating the datatype in a module is what I always do. > Only "Main.hs" calls the happy parser and just about > every module uses the datatype, so it makes sense to > separate them. > > Jan > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From dongen@cs.ucc.ie Fri May 11 10:52:55 2001 From: dongen@cs.ucc.ie (Marc van Dongen) Date: Fri, 11 May 2001 10:52:55 +0100 Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)] In-Reply-To: <20010511170944K.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Fri, May 11, 2001 at 05:09:44PM +1000 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010511105255.S12168@cs.ucc.ie> Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote: [received message twice] Am I just the only one or does everybody receive messages posted to haskell@haskell.org and glasgow-haskell-users@haskell.org twice? I find it a bit (I know I am exaggerating) annoying. Is there a way to avoid this? Regards, Marc From cwitty@newtonlabs.com Fri May 11 18:13:49 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 11 May 2001 10:13:49 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Fri, 11 May 2001 17:09:44 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I don't think, the point is the test for non-ambiguity. At > least, Doitse's and my self-optimising parser combinator > library will detect that a grammar is ambigious when you > parse a sentence involving the ambiguous productions. So, > you can check that by parsing a file involving all grammar > constructs of the language. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty From brian@boutel.co.nz Sat May 12 05:57:34 2001 From: brian@boutel.co.nz (Brian Boutel) Date: Sat, 12 May 2001 16:57:34 +1200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <3AFCC2BE.B75CB113@boutel.co.nz> "Carl R. Witty" wrote: > > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. > This illustrates the difference between generality and usefulness. Often, one is less interested in learning that a grammar is ambiguous than learning that it is not. If you have a parser generator for a class of grammars, it will tell you if (and probably why) a candidate grammar you feed to it is not a member of that class. If it is accepted by, for example, a parser generator for LR(1) grammars, then it is a DCFG and therefore unambiguous. If you start with a "natural" grammar for the language, i.e. one that corresponds to the abstract syntax, and use a generator for a broad class of grammars (e.g LR(1)) then failure will give a good hint that the only way to get an unambiguous grammar in that class is to restrict the language, and you can use that information to make design decisions. For example, although Haskell has both 'let' and 'where' for introducing local definitions, thereby reflecting the typical committee decision when there are varying stylistic preferences, 'where' is not part of the expression syntax. If you write a grammar which includes the "natural" productions exp -> let defs in exp exp -> exp where defs and put this through a suitable generator, you will see why not. Of course, it is possible that an unambiguous grammar will fail to be LR(1) - by being non-deterministic, so the proper conclusion is that "G is ambiguous or non-deterministic". But that is close enough for most purposes. Early versions of Hope had both 'let' and 'where' as expressions, and had three different forms of condtional. Most combinations of these constructs would interract to create ambiguity. The hand-coded parsers in use had not picked this up. That shows the advantage of using a generator - you get a constructive proof that the grammar is in the desired class. --brian From chak@cse.unsw.edu.au Sun May 13 07:51:38 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 16:51:38 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010513165138B.chak@cse.unsw.edu.au> cwitty@newtonlabs.com (Carl R. Witty) wrote, > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. I didn't say that this works for any kind of parser combinator, I merely said that it works Doitse's and mine. Both implement SLL(1) parsers for which - as I am sure, you know - there exists a decision procedure for testing ambiguity. More precisely, whenever the library can build the parse table, the grammar must be non-ambigious. As the parse table construction is lazy, this covers only the productions exercised in that particular run, which is why I said that you need a "file involving all grammar constructs of the language." Nothing magic here. Cheers, Manuel PS: AFAIK Doitse recently made his combinators a bit more general, and I am not entirely sure how that affects the ambiguity check. From chak@cse.unsw.edu.au Sun May 13 08:40:26 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 17:40:26 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <15099.36400.547112.275888@spitfire.crt.se> References: <20010510192659H.chak@cse.unsw.edu.au> <15099.36400.547112.275888@spitfire.crt.se> Message-ID: <20010513174026V.chak@cse.unsw.edu.au> Thomas Johnsson wrote, > Happy and others like it generate an LR parser, which is a well-established > technology since the late 60's (Knuth): efficient, > deterministic, and checks the grammar for you. > Parser combinators are usually nondeterministic ie > backtracking (pre-Knuth!:-) > though Cleverly Disguised in Haskell Higher Order clothes.... [..] > PS would be cool to try to marry the two approaches.... Doaitse Swierstra et al have done this to a certain extent: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/ Parser combinators that are efficient, deterministic, and handle errors much better than the classic form of parser combinators. Manuel From ltaesch@europemail.com Sun May 13 10:22:05 2001 From: ltaesch@europemail.com (luc) Date: Sun, 13 May 2001 11:22:05 +0200 Subject: io monad question Message-ID: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , mainly String -> [String], or similar = with types, plus some more complex datatypes. Up to now; i was testing them on a basic database I was creating in the = core main, "by hand". Then i added a basic parser with happy; and bingo; my test database is = now loaded from a file... as IO String..; huh! after a second though; this makes sense, except that i have to change = all the type of my functions; now IO String.. plus a few that just dont compile; and i cant understand why... my question: I had to change most of my type of the functions.as is propagated = through the code. (i.e. f need g; that need h; etc...) to add IO. is that kind of propagation normal, or can i Stop it somewhere ? how? is that because my functions just uses string as type ? and not data (ie = type relation =3Dstring; instead data Relation String) can i design a function that will do IO String-> String, or IO String -> = Data X, that will stop that IO propagation , through my code ? how can i handle function when my database is not IO, then ? i suppose im not the first to ask. any link ? thread ? faq example would = be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , = mainly String=20 -> [String], or similar with types, plus some more complex=20 datatypes. Up to now; i was testing them on a = basic database I=20 was creating in the core main, "by hand". Then i added a basic parser with happy; = and bingo;=20 my test database is now loaded from a file... as IO String..; = huh! after a second though; this makes = sense, except=20 that i have to change all the type of my functions; now IO = String.. plus a few that just dont compile; and = i cant=20 understand why... my question: I had to change most of my type of the = functions.as=20 is propagated through the code. (i.e. f need g; that need h; etc...) to = add=20 IO. is that kind of propagation normal, or = can i Stop=20 it somewhere ? how? is that because my functions just uses = string as=20 type ? and not data (ie type relation =3Dstring; instead data Relation=20 String) can i design a function that will do IO = String->=20 String, or IO String -> Data X, that will stop that IO propagation , = through=20 my code ? how can i handle function when my = database is not=20 IO, then ? i suppose im not the first to ask. any = link ?=20 thread ? faq example would be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0-- From khaliff@astercity.net Sun May 13 10:07:54 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Sun, 13 May 2001 11:07:54 +0200 (CEST) Subject: io monad question In-Reply-To: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> Message-ID: On Sun, 13 May 2001, luc wrote: > i designed some basic functions, , mainly String -> [String], or similar with types, plus some more complex datatypes. > > Up to now; i was testing them on a basic database I was creating in the core main, "by hand". > Then i added a basic parser with happy; and bingo; my test database is now loaded from a file... as IO String..; huh! > > after a second though; this makes sense, except that i have to change all the type of my functions; now IO String.. > > plus a few that just dont compile; and i cant understand why... > > my question: > I had to change most of my type of the functions.as is propagated through the code. (i.e. f need g; that need h; etc...) to add IO. > is that kind of propagation normal, or can i Stop it somewhere ? how? You can stop it at the very beginning: f :: String -> String g :: [A] -> [B] -- etc, any functions without IO parse :: [String] -> [ A ] main = do h <- openFile "sampleFile" ReadMode contents <- hGetContents h -- and now you have file contents binded to contents and you can apply your --functions any way you want, i. e. let result = g (parse contents) putStrLn (show result) Wojciech Moczydlowski, Jr From Ben Mon May 14 03:43:31 2001 From: Ben (Ben) Date: Sun, 13 May 2001 21:43:31 -0500 Subject: typing question Message-ID: <20010513214331.A16503@one.net> Hello, I hope that a question here wont be too much of a bother. Yesterday I wrote a library for polynomial manipulation. Everything is fine except for the composition operator. Which I having problems with, probably trivial, but as I don't program in Haskell everyday a solution isn't clear. I have my polynomials defined as: newtype Polynomial a = Polynomial [a] deriving (Eq) with toPolynomial :: (Num a) => [a] -> Polynomial a toPolynomial x = Polynomial x fromPolynomial :: Polynomial a -> [a] fromPolynomial (Polynomial x) = x instance Show a => Show (Polynomial a) where instance Num a => Num (Polynomial a) where... and defined appropriately I also have a function, degree :: Polynomial a -> Int but to be more pointed my question is related to, (@@) :: (Num a) => Polynomial a -> a -> a f @@ g = applyrec (fromPolynomial f) g 0 where applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 This was originally written to evaluate f at value, ie n \mapsto f(n). But I realized that this should also work for overloading, as my Polynomials are Nums. In hugs the following works fine, t = Polynomial [1,2,3] @@ Polynomial [3,2,1] but I suspect that there is a type conversion happening for me which I should be aware of as something like the following doesn't work, [ f @@ g | f <- poly, g <- poly, f /= g ] where poly is a list of polynomials gives me, *** Expression : f @@ g *** Term : f *** Type : Polynomial Integer *** Does not match : Polynomial (Polynomial Integer) so my question boils down to, how do I tell hugs/Haskell that Polynomials over Polynomials of Integers are just Polynomials of Integers or at least that this kind of composition is ok? I am not on this mailing list so please CC me any responses. Thank you. Ben. From Ben Mon May 14 04:02:47 2001 From: Ben (Ben) Date: Sun, 13 May 2001 22:02:47 -0500 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net>; from neb@one.net on Sun, May 13, 2001 at 09:43:31PM -0500 References: <20010513214331.A16503@one.net> Message-ID: <20010513220247.A16641@one.net> The following appears to work, (@\@) :: (Num a) => Polynomial a -> Polynomial a -> Polynomial a f @\@ g = applyrec pp g 0 where pp = map (\x -> toPolynomial [x]) (fromPolynomial f) applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 Sorry for the original email, although I would be interested in a better solution if there is any commentary. Ben. On Sun, May 13, 2001 at 09:43:31PM -0500, Ben wrote: > Hello, I hope that a question here wont be too much of a bother. > > Yesterday I wrote a library for polynomial manipulation. Everything is fine > except for the composition operator. Which I having problems with, probably > trivial, but as I don't program in Haskell everyday a solution isn't clear. ...etc. From Tom.Pledger@peace.com Mon May 14 03:35:14 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Mon, 14 May 2001 14:35:14 +1200 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net> References: <20010513214331.A16503@one.net> Message-ID: <15103.17506.714186.42965@waytogo.peace.co.nz> Ben writes: : | (@@) :: (Num a) => Polynomial a -> a -> a : | the following doesn't work, | [ f @@ g | f <- poly, g <- poly, f /= g ] | where poly is a list of polynomials gives me, | | *** Expression : f @@ g | *** Term : f | *** Type : Polynomial Integer | *** Does not match : Polynomial (Polynomial Integer) | | so my question boils down to, how do I tell hugs/Haskell that | Polynomials over Polynomials of Integers are just Polynomials of | Integers or at least that this kind of composition is ok? Your definition of (@@) looks OK. The only problem is that you've applied it to two arguments of the same type (f, g :: Polynomial Integer), which don't unify with the parameter types (Polynomial a and a). Hugs has compared the type of the second parameter (a) with the type of the second argument (Polynomial Integer), and applied the Most General Unifier (the substitution of Polynomial Integer for a). The details of the error message refer to what happened when it compared the types of the first argument and the first parameter. It's worth checking whether [ f @@ g | f <- poly, g <- poly, f /= g ] really means what you intended. From andyfugard@eircom.net Mon May 14 12:06:24 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 12:06:24 +0100 Subject: Permutations of a list Message-ID: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Hi all, I'm currently teaching myself a little Haskell. This morning I coded the following, the main function of which, permutate, returns all the permutations of a list. (Well it seems to at least!) insertAt :: a -> Int -> [a] -> [a] insertAt x i xs | i < 0 || i > length xs = error "invalid position" | otherwise = front ++ x:back where (front,back) = splitAt i xs insertAtAll :: a -> (Int,Int) -> [a] -> [[a]] insertAtAll x (i,j) xs | i > j = error "PRE: i <= j" | i == j = [insertAt x i xs] | otherwise = (insertAt x i xs):(insertAtAll x (i+1,j) xs) buildPermList :: a -> [[a]] -> [[a]] buildPermList x xs | length xs == 0 = [] | otherwise = list ++ buildPermList x (tail xs) where list = insertAtAll x (0, length curr) curr; curr = head xs permutate :: [a] -> [[a]] permutate xs | length xs == 0 = [[]] | otherwise = buildPermList (last xs) (permutate (init xs)) and some test runs.... Main> permutate "" [""] Main> permutate "a" ["a"] Main> permutate "ab" ["ba","ab"] Main> permutate "abc" ["cba","bca","bac","cab","acb","abc"] My main question is really what facilities of the language I should be looking at to make this code more elegant! As you can see I currently know only the basics of currying, and some list operations. Also regarding the method of generating the permutations; is there a better way? The current is just "Method 1" from Knuth's TAOCP, volume 1 (3rd edition), p45-46. Thanks in advance, Andy -- [ Andy Fugard /'andi fju:ga:d/ ] [ Phone: +44 (0)7901 603075 ] From ralf@informatik.uni-bonn.de Mon May 14 12:43:14 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Mon, 14 May 2001 13:43:14 +0200 Subject: Permutations of a list References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <3AFFC4D2.2114F872@informatik.uni-bonn.de> Andy Fugard wrote: > My main question is really what facilities of the language I should be > looking at to make this code more elegant! As you can see I currently know > only the basics of currying, and some list operations. Definitely list comprehensions! I digged out some old code: > module Perms where Permutations. > perms :: [a] -> [[a]] > perms [] = [ [] ] > perms (a : x) = [ z | y <- perms x, z <- insertions a y ] > > insertions :: a -> [a] -> [[a]] > insertions a [] = [ [a] ] > insertions a x@(b : y) = (a : x) : [ b : z | z <- insertions a y ] Using deletions instead of insertions; generates the permutations in lexicographic order, but is a bit slower. > perms' :: [a] -> [[a]] > perms' [] = [ [] ] > perms' x = [ a : z | (a, y) <- deletions x, z <- perms' y ] > deletions :: [a] -> [(a, [a])] > deletions [] = [] > deletions (a : x) = (a, x) : [ (b, a : y) | (b, y) <- deletions x ] Cheers, Ralf From andyfugard@eircom.net Mon May 14 13:02:14 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 13:02:14 +0100 Subject: Permutations of a list In-Reply-To: <3AFFC4D2.2114F872@informatik.uni-bonn.de> References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <5.1.0.14.0.20010514125913.00a78670@mail1.eircom.net> At 13:43 14/05/01 +0200, Ralf Hinze wrote: >Andy Fugard wrote: > > > My main question is really what facilities of the language I should be > > looking at to make this code more elegant! As you can see I currently know > > only the basics of currying, and some list operations. > >Definitely list comprehensions! I digged out some old code: [ ... ] Thanks for the quick response; that's much nicer! I think I'll have a look at list comprehensions.... Cheers, Andy From mechvel@math.botik.ru Mon May 14 13:05:13 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 16:05:13 +0400 Subject: permutations. Reply Message-ID: Andy Fugard writes > Hi all, > > I'm currently teaching myself a little Haskell. This morning I coded the > following, the main function of which, permutate, returns all the > permutations of a list. (Well it seems to at least!) > > [..] The BAL library implements several operations with permutations. In particular, it can list permutations by applying nextPermutation. You may look into the source and demonstration example: http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ ----------------- Serge Mechveliani mechvel@botik.ru From mechvel@math.botik.ru Mon May 14 14:44:15 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 17:44:15 +0400 Subject: CA proposal by D.Thurston Message-ID: I was said that there exists an algebraic library proposal for Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. Who could, please, tell me where to download this document from? For I could not find it from http://haskell.org Thanks in advance for the help. ----------------- Serge Mechveliani mechvel@botik.ru From herrmann@infosun.fmi.uni-passau.de Mon May 14 15:42:27 2001 From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann) Date: Mon, 14 May 2001 16:42:27 +0200 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <15103.61139.512952.903922@reger.fmi.uni-passau.de> Hi Haskellers, >>>>> "S" == S D Mechveliani writes: S> I was said that there exists an algebraic library proposal for S> Haskell (version 0.02) dated by February (2001?), by Dylan S> Thurston. that sounds interesting for me. Sorry, that I don't have an answer to your question, but I like to state some points about an algebraic library. A standard algebraic library has several advantages to many different tools developed by individual programmers: (1) One can benefit from the knowledge and experience of others (and of their work also, of course) (2) An open discussion process will help to avoid errors or difficulties in use (3) Programs written by others that use the library functions are more comprehensible I've got no impression of how such a library may look like and if the library is meant to be updated from time to time. Anyway, an algebraic library is important: it is nice that Haskell has the rational numbers but recently, it appeared useful for me also to have the algebraic numbers, e.g., to evaluate expressions containing roots exactly. The problem is that I'm not an expert in this stuff and thus, be very glad if such things are added by an expert. On the other hand, I'd like to add things like a linear equation solver for a non-invertible system which may help to convince people that Haskell provides more features than other programming languages do. Cheers Christoph From fjh@cs.mu.oz.au Mon May 14 18:01:32 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 15 May 2001 03:01:32 +1000 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <20010515030132.A4701@hg.cs.mu.oz.au> On 14-May-2001, S.D.Mechveliani wrote: > I was said that there exists an algebraic library proposal for > Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. > > Who could, please, tell me where to download this document from? > For I could not find it from http://haskell.org It was posted to the haskell-cafe list, and is available from the archives of that list: . -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From cwitty@newtonlabs.com Mon May 14 20:31:43 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 14 May 2001 12:31:43 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Sun, 13 May 2001 16:51:38 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010513165138B.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I didn't say that this works for any kind of parser > combinator, I merely said that it works Doitse's and mine. > Both implement SLL(1) parsers for which - as I am sure, you > know - there exists a decision procedure for testing > ambiguity. More precisely, whenever the library can build > the parse table, the grammar must be non-ambigious. As the > parse table construction is lazy, this covers only the > productions exercised in that particular run, which is why I > said that you need a "file involving all grammar constructs > of the language." Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty From mechvel@math.botik.ru Tue May 15 05:45:25 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 08:45:25 +0400 Subject: standard library. Reply Message-ID: Ch. A. Herrmann writes > [..] > Anyway, an algebraic library is important: > it is nice that Haskell has the rational numbers but recently, it > appeared useful for me also to have the algebraic numbers, e.g., > to evaluate expressions containing roots exactly. The problem is > that I'm not an expert in this stuff and thus, be very glad if > such things are added by an expert. > > On the other hand, I'd like to add things like a linear equation solver > for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. The BAL library http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ provides such linear solver, as well as operations with roots. For example, the root of x^5 - x + 1 can be handled (in many respects) in BAL as only a residue of polynomials modulo this equation - a data like (Rse ...(x^5-x+1))). But BAL is not a standard library. And there is another point: > [..] for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. In any case, we have to distinguish between a standard library and an application. A standard library should be small. I think, for Haskell, it should be something that you mention now. But, for example, the true algebraic number theory algorithms are too complex, it is for the non-standard application writers. And if a language is good, there should come many special applications (non-standard ones). Haskell's www page does reveal some. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mpj@cse.ogi.edu Tue May 15 08:16:10 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Tue, 15 May 2001 00:16:10 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon, | When you say there's a good theoretical foundation (typed lambda | calcului) I think you are imagining that when we say |=20 | f (x::a) =3D e |=20 | we are saying "There's a /\a as well as a \x::a in this definition". No, that's not what I'm thinking. When you say "f (x::a) =3D e", I'm reading it as meaning something like: "f =3D \(x::a).e". This is the typed lambda-calculus perspective that I was referring to. And, in such systems (whether simply typed or polymorphicly typed) the type annotation on the lambda bound variable x does not bind any type variables appearing in a. (And note that the type annotation may not contain any variables, or it could contain repeated uses of the same variable, etc...) Binding of type variables is a separate matter. It may be done by some kind of /\, either explicit or implicit. For the binding above, those variables would have to be bound somewhere, either added, implicitly to the binding of f, or else to some enclosing function. | But I'm suggesting something different |=20 | * Place the big lambdas wherever they would be now (i.e. not = influenced | by the position of (x::a) type signatures. |=20 | * Explain the pattern type signatures as let-bindings for types. Thus | we might translate f to system-F like this: |=20 | f =3D \x::T -> let-type a =3D T in e |=20 | I've use let-type here, but one could equally well say (/\a -> e) T. This is a different interpretation of type annotations than the one you'll find in many typed lambda-calculi. (That's a statement of fact rather than a judgment of merits.) In fact I'm not aware of any work on type systems like this. The simple translation that you give for let-type looks ok from the perspective of System-F, say. However, in the context of Haskell, I think it would be prudent to determine how it extends to and interacts with things like type inference, polymorphism, and overloading. Perhaps it would be worth considering a new language construct, such as: let-type expr :: type in expr with the intention that the first expr is not evaluated, but used to guide the binding of type variables in the "type" part, which would then be in scope in the second expression. This is a little more powerful than your let-type because it allows a kind of pattern matching on type expressions. But I don't know if this would be a well-behaved construct, or if it would be useful ... | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may = differ | about (b). I'm not persuaded about (a), I can't comment on (b), and I think there should be a third question: c) when is it useful? what holes does it fill? All the best, Mark PS. Aside ... if you'd like type variables in type annotations to be binding, then perhaps you'd also like them to work more like regular pattern bindings and to see functions like the following: f :: a -> b -> String f (x::a) (y::a) =3D "Yes, the arguments are the same type" f _ _ =3D "No, the arguments have different types" showList :: [a] -> String showList (xs::[Char]) =3D ... show a string enclosed in "'s ... showList xs =3D ... show list enclosed in [ ... ]s ... Who needs overloading anyway? :-) From mechvel@math.botik.ru Tue May 15 13:10:20 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 16:10:20 +0400 Subject: BAL paper available Message-ID: Paper announcement ------------------ The file http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip contains more expanded explanations on the BAL (Basic Algebra Library) project (previous variant was haskellInCA.ps.zip). My real intention in whole this line of business was always not just to propose a standard but rather to discuss and to find, what may be an appropriate way to program mathematics in Haskell. The matter was always in parametric domains ... Whoever tried to program real CA in Haskell, would agree that such a problem exists. ----------------- Serge Mechveliani mechvel@botik.ru From karczma@info.unicaen.fr Tue May 15 17:33:41 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Tue, 15 May 2001 18:33:41 +0200 Subject: BAL paper available References: Message-ID: <3B015A65.C87801F5@info.unicaen.fr> Serge Mechveliani : > > Paper announcement > ------------------ > > The file > http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip > > contains more expanded explanations on the BAL (Basic Algebra Library) > project > (previous variant was haskellInCA.ps.zip). > > My real intention in whole this line of business was always not just > to propose a standard but rather to discuss and to find, what may be > an appropriate way to program mathematics in Haskell. > The matter was always in parametric domains ... > Whoever tried to program real CA in Haskell, would agree that such a > problem exists. Absolutely. The point is that this seems - for various, perfectly understandable reasons - not to be the priority of the implementors. Graphics/imagery neither. Nor hard numeric work (efficient, easy to manipulate arrays). And now I will say something horrible. Despite my extremely deep respect for all people contributing to Haskell, despite my love for the language etc. I begin to suspect that it has been standardized too early, and if we (Sergey, other people interested in math, as Dylan Thurston, myself, etc., as well as people who want to do *serious* graphics in a functional way) want an adapted functional language, either we will have to wait quite long, or perhaps it is the time to invent another language, with a more dynamic type system, with intrinsic graphic utilities, and other goodies. For the moment - this is my personal viewpoint - it might be better to write concrete applications, and papers describing those applications. Then we shall perhaps know better what kind of structures, algorithms, representations, genericities, etc. we REALLY need for practical purposes. Anyway, Sergey did a formidable work, and this should be acknowledged even by those who on this list criticized his presentation. Thanks. Jerzy Karczmarczuk Caen, France From dpt@math.harvard.edu Tue May 15 19:14:02 2001 From: dpt@math.harvard.edu (Dylan Thurston) Date: Tue, 15 May 2001 21:14:02 +0300 Subject: BAL paper available In-Reply-To: <3B015A65.C87801F5@info.unicaen.fr>; from karczma@info.unicaen.fr on Tue, May 15, 2001 at 06:33:41PM +0200 References: <3B015A65.C87801F5@info.unicaen.fr> Message-ID: <20010515211402.B24804@math.harvard.edu> On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > Serge Mechveliani : > > ... > > My real intention in whole this line of business was always not just > > to propose a standard but rather to discuss and to find, what may be > > an appropriate way to program mathematics in Haskell. > > The matter was always in parametric domains ... > > Whoever tried to program real CA in Haskell, would agree that such a > > problem exists. Can you be more precise what the problem is? One problem I see is that referred to in Section 3 of the paper: you really need types that depend on parameters (in particular, integer parameters). This is, indeed, a problem--currently, you have to do runtime checks. Full-fledged dependent types à la Cayenne are undecidable, but there are weaker variants that are likely to be good enough. > The point is that this seems - for various, perfectly understandable > reasons - not to be the priority of the implementors. > Graphics/imagery neither. > Nor hard numeric work (efficient, easy to manipulate arrays). If I understand correctly, Marcin Kowalczyk is working on exactly this last point... > Despite my extremely deep respect for all people contributing to > Haskell, despite my love for the language etc. I begin to suspect > that it has been standardized too early, and if we [...] want an > adapted functional language, either we will have to wait quite long, > or perhaps it is the time to invent another language, with a more > dynamic type system, with intrinsic graphic utilities, and other > goodies. For myself, I don't see a problem here. For "intrinsic graphic utilities", someone has to write the graphic libraries. (You don't mean they should be built into the language, do you?) The type system is about as strong as anyone knows how to make a static type system; and it's not too hard to fall back on run-time type checking when necessary (as Sergey does in BAL). > Anyway, Sergey did a formidable work, and this should be acknowledged even > by those who on this list criticized his presentation. Thanks. Yes, absolutely. I think perhaps some things could be done better (for instance, I see that all Sergey's classes derive from Eq, which is one of my principal complaints with the Haskell 98 classes), but I appreciate the work and want to study it more. Best, Dylan Thurston From qrczak@knm.org.pl Tue May 15 20:11:49 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 19:11:49 GMT Subject: BAL paper available References: Message-ID: Tue, 15 May 2001 16:10:20 +0400, S.D.Mechveliani pisze: > The matter was always in parametric domains ... The solution is simple: don't model domains as types. Model them as values (records with operations). Some simple domains can be also modelled as types for convenience. But it doesn't work in general. Similarly as standard sort :: (Ord a) => [a] -> [a] is not as expressive as soryBy :: (a -> a -> Ordering) -> [a] -> [a] even though it's more convenient in case it works. It doesn't work when various instances of the same kind of algebraic structure over the same carrier set are considered. And it doesn't work when a domain should be parametrized by something which is hard to express by a type. And it constrains programs which want to choose the domain dynamically. Carrier sets are modelled as types, OK. But it won't work for all algebraic structures. About program transformation possibility: I don't see how it would be applied in practice. There is no use of associativity of (+) for the compiler. It can do many optimizations, but it won't rewrite x+(y+z) to (x+y)+z nor vice versa. Sample arguments are ugly, almost always unnecessary, and constrain interfaces (functions like 'sum :: Num a => [a] -> a' would have to have a different intreface). They are a solution to a wrong problem: some domains should not have been modelled as types in the first place. Algebraic operations don't belong to elements of algebras; they belong to algebras. In simple cases they can be deduced from the types of elements if the given carrier has a reasonable default interpretation of these operations (e.g. (+) on Integers), but it's not general. I don't believe that dependent types would come into Haskell in the near future. And they are unnecessary for the discussed purpose: domains which would require them should not be modelled as types. Don't abuse types to model values. Haskell's types are too static for that. The class hierarchy is unacceptable for me as standard Haskell. It's way too complex. Currently I have to define instances of Eq, Show, Num and Fractional to have field operations. With BAL I would have to define instances of Eq, Show, Set, Additive, AddSemigroup, AddGroup, Multiplicative, MulSemigroup, Ring, CommutativeRing, GCDRing, EuclideanRing, FactorizationRing and Field. They require such things as specifying an arbitrarily chosen set of properties of the domain and partially defined versions of most operations... The hierarchy contains many unnecessary superclass relationships. For example Show, specifying bounds and conversion from 'Expression String' are not necessary for Ord, where your classes artificially require them. There are no class synonyms in Haskell, so classes like OrdAddGroup can't be treated as implicit. Later parts are too heavy for me to understand them well, but I see some ugly points, like abusing Char arguments to virtually extend the function name, or requirement to provide reflection capabilities at the very beginning by every type wanting to use overloading of basic operations, or requirement that the programmer knows more advanced math than should be necessary to use Haskell. I hope that a similar proposal won't go into standard Haskell. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Tue May 15 21:05:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 20:05:47 GMT Subject: BAL paper available References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: >> Nor hard numeric work (efficient, easy to manipulate arrays). > > If I understand correctly, Marcin Kowalczyk is working on exactly > this last point... Well, I improved efficiency of ghc's arrays by removing various unnecessary overheads and I'm working on a generic interface of collections, but I don't have any deeper plans about arrays. What should be improved compared to existing STUArray Int Double and similar? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From conal@microsoft.com Tue May 15 21:44:03 2001 From: conal@microsoft.com (Conal Elliott) Date: Tue, 15 May 2001 13:44:03 -0700 Subject: BAL paper available Message-ID: Small comment. Marcin wrote: > About program transformation possibility: I don't see how it would > be applied in practice. There is no use of associativity of (+) for > the compiler. It can do many optimizations, but it won't rewrite > x+(y+z) to (x+y)+z nor vice versa. Associativity and commutativity (AC) are not optimizations in themselves, but rather enable optimizations if you have an AC matcher in your rewriting system (as, for instance, in Mathematica). - Conal From khaliff@astercity.net Tue May 15 21:31:40 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Tue, 15 May 2001 22:31:40 +0200 (CEST) Subject: BAL paper available In-Reply-To: Message-ID: On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: > > >> Nor hard numeric work (efficient, easy to manipulate arrays). > > > > If I understand correctly, Marcin Kowalczyk is working on exactly > > this last point... > > Well, I improved efficiency of ghc's arrays by removing various > unnecessary overheads and I'm working on a generic interface > of collections, but I don't have any deeper plans about arrays. > > What should be improved compared to existing STUArray Int Double > and similar? > > QRCZAK A simple standard proposal, not using ST and multiparameter type classes, so that it would be possible to implement it in other compilers (namely nhc), would be a great improvement for me. Wojciech Moczydlowski, Jr From matth@mindspring.com Wed May 16 00:43:28 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 15 May 2001 18:43:28 -0500 Subject: Ix class Message-ID: <3B01BF20.952F55FE@mindspring.com> Hello, I am working on an Ix instance for one of my types and finding it rather restrictive. For me it would be useful to have rangeSize be defined in the Ix class (with a default definition of course), so that it can be overridden. Also, does anybody know why Ix derives from Ord? It seems to me this is an unnecessary limitation on the types that can be instances of Ix. I cannot think of a reason why the implementation of anything in the Ix or Array modules would require that every Ix be an Ord (with a minor exception -- see below). If an implementation is using a comparison on an Ix type, chances are it should be using inRange or comparing (index bnds x) with (index bnds y) instead. One change would have to be made in the Array module if Ord is removed from Ix: instance (Ix a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' would become: instance (Ix a, Eq a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' As I said, I think this is a very minor issue. I believe that making these changes in the standard would not impact existing programs in any way. Could these changes be considered as a possible "typo" to be fixed in the Library Report? P.S. In case anybody's interested, here's why I want to override rangeSize: > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) > > indexError = error "Index out of range" > > instance Ix Honeycomb where > range (Hx b1, Hx b2) = > [Hx x | x <- range (b1,b2), isHexIx x] > inRange (Hx b1, Hx b2) (Hx x) = > inRange (b1,b2) x && isHexIx x > index (Hx b1, Hx b2) (Hx x) = > let i = index (b1,b2) x in > if isHexIx x then i `div` 2 else indexError > > isHexIx :: (Int,Int) -> Bool > isHexIx (x,y) = x `mod` 2 == y `mod` 2 This implements a honeycomb or hexagonal tiling for a maze generating program. The honeycomb is superimposed on a grid such that only every other square is "active", corresponding to a particular hexagon in the honeycomb. It's similar to a checkers game, where only the dark squares are used. I would like _any_ pair of Ints to be an acceptable boundary for the honeycomb, not just the ones that represent valid indexes. For example, (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current definition of rangeSize makes this impossible, which is why I would like to override it. By the way, the Library Report does not explicitly say that the bounds have to both be valid indexes, though it does imply this with the sample definition of rangeSize. Thanks, Matt Harden From jans@numeric-quest.com Tue May 15 20:08:38 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Tue, 15 May 2001 15:08:38 -0400 (EDT) Subject: Ix class In-Reply-To: <3B01BF20.952F55FE@mindspring.com> Message-ID: On Tue, 15 May 2001, Matt Harden wrote: [..] > I would like _any_ pair of Ints to be an acceptable boundary for the > honeycomb, not just the ones that represent valid indexes. For example, > (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current > definition of rangeSize makes this impossible, which is why I would like > to override it. By the way, the Library Report does not explicitly say > that the bounds have to both be valid indexes, though it does imply this > with the sample definition of rangeSize. There is an old article [1], that is somehow related to what you do. Looks like it could add some extra fuel to your arguments if re-examined in terms of current Haskell. [It might be also interesting to those discussing arrays in the other thread.] Jan [1] D.B. Carpenter, Some Lattice-based Scientific Problems, Expressed in Haskell, http://citeseer.nj.nec.com/157672.html From sk@mathematik.uni-ulm.de Wed May 16 06:38:06 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 16 May 2001 07:38:06 +0200 Subject: BAL paper available In-Reply-To: <20010515211402.B24804@math.harvard.edu>; from dpt@math.harvard.edu on Tue, May 15, 2001 at 09:14:02PM +0300 References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > Serge Mechveliani : > > > ... > > > The matter was always in parametric domains ... > > > Whoever tried to program real CA in Haskell, would agree that such a > > > problem exists. > > Can you be more precise what the problem is? One problem I see is > that referred to in Section 3 of the paper: you really need types that > depend on parameters (in particular, integer parameters). This is, > indeed, a problem--currently, you have to do runtime checks. > > Full-fledged dependent types à la Cayenne are undecidable, but there > are weaker variants that are likely to be good enough. What are the weaker variants? Do you know some references? Are they still decidable? That surprises me. If you allow integer arithmetic you can do already all computations (Church). -- Stefan Karrmann From fjh@cs.mu.oz.au Wed May 16 07:16:08 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 16:16:08 +1000 Subject: BAL paper available In-Reply-To: References: Message-ID: <20010516161608.A22442@hg.cs.mu.oz.au> On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > What should be improved compared to existing STUArray Int Double > > and similar? > > A simple standard proposal, not using ST and multiparameter type classes, > so that it would be possible to implement it in other compilers (namely nhc), > would be a great improvement for me. I think multiparameter type classes or other extensions to Haskell 98 are really needed to solve these kinds of problems in a simple and elegant way. The right solution, IMHO, is to extend nhc and other Haskell compilers to support multiparameter type classes, not to try to shoehorn things that don't fit into Haskell 98. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From khaliff@astercity.net Wed May 16 08:18:01 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Wed, 16 May 2001 09:18:01 +0200 (CEST) Subject: BAL paper available In-Reply-To: <20010516161608.A22442@hg.cs.mu.oz.au> Message-ID: On Wed, 16 May 2001, Fergus Henderson wrote: > On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > > What should be improved compared to existing STUArray Int Double > > > and similar? > > > > A simple standard proposal, not using ST and multiparameter type classes, > > so that it would be possible to implement it in other compilers (namely nhc), > > would be a great improvement for me. > > I think multiparameter type classes or other extensions to Haskell 98 are > really needed to solve these kinds of problems in a simple and elegant way. > > The right solution, IMHO, is to extend nhc and other Haskell compilers > to support multiparameter type classes, not to try to shoehorn things > that don't fit into Haskell 98. > > Fergus Henderson | "I have always known that the pursuit I don't like the idea of a program working which compiles only under compilers which have certain language extensions built in. If I understand things correctly, there is a list of language extensions (FFI for example), which has been accepted by all Haskell compilers developers. If multiparameter type classes were in that list, I would agree. Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification. I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps. By the way, I'm really surprised by the lack of time complexity information in MArray. I mean, that's the most important thing in arrays - that one can update/read a data in O(1). Wojciech Moczydlowski, Jr From fst@informatik.uni-kiel.de Wed May 16 09:30:57 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Wed, 16 May 2001 10:30:57 +0200 Subject: WFLP 2001 deadline extension to May 22, 2001 Message-ID: <200105160830.KAA02124@listrac.informatik.uni-kiel.de> Due to various requests, the DEADLINE FOR SUBMISSIONS to WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming Kiel, Germany, September 13-15, 2001 http://www.informatik.uni-kiel.de/~wflp2001 has been EXTENDED TO MAY 22, 2001. From ashley@semantic.org Wed May 16 09:39:08 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 16 May 2001 01:39:08 -0700 Subject: BAL paper available Message-ID: <200105160839.BAA01875@mail4.halcyon.com> At 2001-05-16 00:18, Wojciech Moczydlowski, Jr wrote: >> I think multiparameter type classes or other extensions to Haskell 98 are >> really needed to solve these kinds of problems in a simple and elegant way. >> >> The right solution, IMHO, is to extend nhc and other Haskell compilers >> to support multiparameter type classes, not to try to shoehorn things >> that don't fit into Haskell 98. >I don't like the idea of a program working which compiles only under >compilers which have certain language extensions built in. > >If I understand things correctly, there is a list of language extensions >(FFI for example), which has been accepted by all Haskell compilers >developers. If >multiparameter type classes were in that list, I would agree. I tend to share Fergus Henderson's viewpoint. I see a Haskell with multiparameter type classes as a language I want to work with, and it would be great to have libraries written for that. I'm less interested in Haskell 98, since it means muckier solutions to the same problems. -- Ashley Yakeley, Seattle WA From simonmar@microsoft.com Wed May 16 09:36:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Wed, 16 May 2001 09:36:56 +0100 Subject: BAL paper available Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> >=20 > I don't like the idea of a program working which compiles only under > compilers which have certain language extensions built in.=20 >=20 > If I understand things correctly, there is a list of language=20 > extensions > (FFI for example), which has been accepted by all Haskell=20 > compilers developers. If > multiparameter type classes were in that list, I would agree. >=20 > Besides, MArray.lhs uses ST and ST requires not only=20 > multiparameter type > classes, but also explicit universal quantification. ST doesn't require multiparameter type classes (although MArray does). It also doesn't require full support for explicit universal quantification, if runST is known to the compiler. Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types. > I don't like ST and the idea that someone who wants to use arrays > outside of IO has to use ST gives me creeps.=20 What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?). > By the way, I'm really surprised by the lack of time=20 > complexity information > in MArray. I mean, that's the most important thing in arrays=20 > - that one can > update/read a data in O(1).=20 Point taken, I'll update the documentation to include more of this info. Cheers, Simon From S.J.Thompson@ukc.ac.uk Wed May 16 11:32:01 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Wed, 16 May 2001 11:32:01 +0100 Subject: Book reviewers for Journal of Functional Programming Message-ID: I am looking for book reviewers for the Journal of Functional Programming. Book reviews provide a service to the functional programming community by critically appraising many of the key books coming out in the field. If you are interested in becoming a reviewer, please send me an email with - A two sentence biography. - Your particular reviewing interests (e.g. teaching texts, books on ML, etc.) Current books up for review include Trends in Functional Programming edited by Greg Michaelson, et al Intellect Books, 1999 Trends in Functional Programming vol 2 edited by Stephen Gilmore Intellect Books, 2000 How to Design Programs by Felleisen et al MIT Press, 2001 Objective Caml Pascal Manoury and Bruno Pagano O'Reilly, 2000 Principles of Programming Languages Bruce Maclennan Oxford University Press, 1999 so let me know if you are interested in reviewing one of these, or indeed please make any suggestions about books you would like to see reviewed. You can find guidelines for writing JFP book reviews at http://www.dcs.gla.ac.uk/jfp/guidelines.html Thanks very much, Simon Thompson s.j.thompson@ukc.ac.uk From Dominic.J.Steinitz@BritishAirways.com Wed May 16 11:42:22 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 16 May 2001 10:42:22 Z Subject: Integers to Ints Message-ID: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can someone explain the following behaviour? Or is it a bug in hugs? X690v5> (fromIntegral(toInteger(minBound::Int))::Int) Program error: {primIntegerToInt (-2147483648)} (15 reductions, 70 cells) X690v5> (fromIntegral(toInteger((minBound::Int)+1))::Int) -2147483647 (21 reductions, 29 cells) X690v5> minBound::Int -2147483648 (9 reductions, 19 cells) Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From rjchaaft@cs.uu.nl Wed May 16 11:54:12 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 16 May 2001 12:54:12 +0200 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <4.3.0.20010516125151.00b2f3c8@pop.students.cs.uu.nl> Hello, >Can someone explain the following behaviour? Or is it a bug in hugs? I can not explain it. Rather strange is that even this is allowed: (fromIntegral (toInteger (minBound::Int) + 1) -1) :: Int yielding -2147483648 > > (fromIntegral(toInteger(minBound::Int))::Int) > >Program error: {primIntegerToInt (-2147483648)} >(15 reductions, 70 cells) > > > (fromIntegral(toInteger((minBound::Int)+1))::Int) >-2147483647 >(21 reductions, 29 cells) > > > minBound::Int >-2147483648 >(9 reductions, 19 cells) From C.T.McBride@durham.ac.uk Wed May 16 13:03:25 2001 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Wed, 16 May 2001 13:03:25 +0100 (BST) Subject: BAL paper available In-Reply-To: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: On Wed, 16 May 2001, Stefan Karrmann wrote: > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > Serge Mechveliani : > > > > ... > > > > The matter was always in parametric domains ... > > > > Whoever tried to program real CA in Haskell, would agree that such = a > > > > problem exists. > >=20 > > Can you be more precise what the problem is? One problem I see is > > that referred to in Section 3 of the paper: you really need types that > > depend on parameters (in particular, integer parameters). This is, > > indeed, a problem--currently, you have to do runtime checks. > >=20 > > Full-fledged dependent types =E0 la Cayenne are undecidable, but there > > are weaker variants that are likely to be good enough. >=20 > What are the weaker variants? Do you know some references? > Are they still decidable? That surprises me. If you allow integer > arithmetic you can do already all computations (Church). The idea that `dependent types are undecidable' is a popular but understandable misconception arising from a particular design decision in a particular system---Cayenne. Dependent types as found in proof systems such as Coq and Lego do have decidable typechecking: programs may only use structural recursion, and hence all the evaluation which takes place during typechecking is guaranteed to terminate. However, in order to support real programming, Cayenne allows general recursion: as it makes no distinction between the programs which are executed at compile-time and those only executed at run-time, undecidability creeps in. Understandably, neither horn of this dilemma is particularly attractive to programmers who want to combine flexibility at run-time with a genuinely static notion of typechecking.=20 (Of course, post-98 Haskell with certain type class options selected has a type-level language containing non-terminating programs, making typechecking undecidable for exactly the same reason as in Cayenne.) However, there is a middle way: we can distinguish compile-time programs from run-time programs and restrict the former to the structurally recursive fragment, leaving general recursion available in the latter.=20 In this way, all the programs we know and love remain available at run-time, whilst the type system acquires a large yet decidable extension to its expressive power. The key is the application rule, for it is here that programs leak into types. G |- f :: all x::S . T G |- s :: S -------------------------------------- G |- f s :: [s/x]T If s is potentially non-terminating, typechecking becomes undecidable: [s/x]T may not have a normal form.=20 Now let's separate compile-time programs (typed with `|-') from run-time programs (typed with `/-', say). Restricting the compile-time language to structural recursion, the above rule poses no threat. We can add G |- t :: T ------------- (a compile-time program is a run-time program) G /- t :: T G /- f :: all x::S . T G |- s :: S -------------------------------------- x free in T G /- f s :: [s/x]T G /- f :: S -> T G /- s :: S -------------------------------- (S -> T abbreviates all x::S. T G /- f s :: T when x is not free in T) G /- f :: T -> T -------------------- (fixpoint) G /- Y f :: T -> T compile-time structurally recursive programs, extending with general recursion only at run-time. Typechecking is thus decidable, with all your old code intact.=20 Structural recursion is a syntactically checkable notion which allows a large, but obviously not complete language of terminating programs to be recognized as such. How large? Well, first-order unification is structurally recursive, and so is normalization for simply-typed lambda-calculus. As decidable type systems go, this one is better than a poke in the eye.=20 I respectfully suggest that dependent types are worth a second look. Cheers Conor From fjh@cs.mu.oz.au Wed May 16 13:27:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 22:27:18 +1000 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> References: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <20010516222718.A23867@hg.cs.mu.oz.au> On 16-May-2001, Steinitz, Dominic J wrote: > Can someone explain the following behaviour? Or is it a bug in hugs? It looks to me very much like it is a bug in Hugs. ghc 4.04 does not suffer from this bug. It's easy to make mistakes like this, which can often arise from forgetting the assymetric nature of twos-complement signed integers, which have more negative numbers than positive numbers. We once had a similar kind of bug in the Mercury standard library implementation, where string__to_int was not handling the most negative integer correctly. We fixed that one in March 1998. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Wed May 16 11:35:24 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 03:35:24 -0700 Subject: BAL paper available Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F2E@red-msg-09.redmond.corp.microsoft.com> | Despite my extremely deep respect for all people contributing=20 | to Haskell, despite my love for the language etc. I begin to=20 | suspect that it has been standardized too early, and if we=20 | (Sergey, other people interested in math,=20 | as Dylan Thurston, myself, etc., as well as people who want=20 | to do *serious* graphics in a functional way) want an adapted=20 | functional language, either we will have to wait quite long,=20 | or perhaps it is the time to invent another language, with a=20 | more dynamic type system, with intrinsic graphic utilities,=20 | and other goodies. For the moment - this is my personal=20 | viewpoint - it might be better to write concrete=20 | applications, and papers describing those applications. Then=20 | we shall perhaps know better what kind of structures,=20 | algorithms, representations, genericities, etc. we REALLY=20 | need for practical purposes. H98 is standardised, but Haskell certainly isn't. GHC and Hugs both have numerous extensions. So I don't think standardisation is a difficulty. The availability of implemention effort certainly is. But even before that, to implement something one needs a good clear specification, and preferably one that several people subscribe to (i.e. agree with the need and the design of the extension to meet that need). My guess is that the lacks you allude are due not to standardisation, nor to implementation effort, but rather to the lack of design/specfication. If there are things you want, perhaps you can contribute to a design for that thing? (Of course, the existence of a design doesn't guarantee an implementation; implementation effort is certainly an issue. But the absence of a design more or less guarantees the absence of an implementation.) I too have a great respect for the work that Sergey, Jerzy and others=20 have been doing. Indeed I don't understand the half of it. I hope I don't even need to understand it because it's a Haskell library. But not understanding it leaves me badly placed to know what the language difficulties are and maybe there are others in my position. Simon From simonpj@microsoft.com Wed May 16 15:26:42 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 07:26:42 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F3A@red-msg-09.redmond.corp.microsoft.com> | | When you say there's a good theoretical foundation (typed lambda | | calcului) I think you are imagining that when we say | |=20 | | f (x::a) =3D e | |=20 | | we are saying "There's a /\a as well as a \x::a in this definition". |=20 | No, that's not what I'm thinking.=20 OK, let me try to give some type rules for what I have in mind. In these rules, I'm going to have an environment, T, that binds user type variables to types. (A "user type variable" is a type variable that appears in the program text.) There is still a conventional type environment, G (usually written=20 Greek Gamma), that associates user term variables with their types. I'll just deal with type variables in lambda patterns, like \ (x::a) -> E Here's the rule: x_i =3D free-term-vars(pat) a_i =3D free-type-vars(pat) \ T (T, a_i=3Dtaua_i); (G, x_i:taux_i) |- pat : tau_1 (T, a_i=3Dtaua_i); (G, x_i:taux_i) |-- E : tau_2 ------------------------------------------------------- T;G |- \pat -> E : tau_1 -> tau_2 The a_i are the type variables brought into scope by the pattern; namely the free type variable of the pattern which are not already in scope (hence the \ T). The T environment is extended by binding each user type variable a_i to a type taua_i that is gotten out of thin air (as is common in type rules). This new T env is used when typechecking the pattern itself and the body E. The intereesting bit is how to typecheck patterns, and type inside them: T;G |- pat : tau T |- ty : tau ----------------- T;G |- pat::ty : tau That is, to typecheck the pattern (pat::ty), typecheck pat and typecheck ty. The judgement T |- ty : tau checks that the user type ty is well formed with type tau. The key rule of this judgement looks up a type variable in T: ----------------- T |- a : T(a) OK, that's it. The point is simply that the user type variables are regarded as the name of a type; the programmer doesn't specify just what that type is. The type rules just 'inline' the type wherever the name is used. All this translates into completely unmodified System F. =20 | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may=20 | differ about (b). This message is really just a second attempt at (a) Simon From khaliff@astercity.net Wed May 16 23:19:23 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Thu, 17 May 2001 00:19:23 +0200 (CEST) Subject: BAL paper available In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: On Wed, 16 May 2001, Simon Marlow wrote: > > Besides, MArray.lhs uses ST and ST requires not only > > multiparameter type > > classes, but also explicit universal quantification. > > ST doesn't require multiparameter type classes (although MArray does). You're of course right. > It also doesn't require full support for explicit universal > quantification, if runST is known to the compiler. So it's another thing to put inside a compiler? > Also, the ST array types are really an optional part of the MArray > interface - it works perfectly well with just the IO array types. Perhaps. It just shows that the module was created specifically for ghc. > > I don't like ST and the idea that someone who wants to use arrays > > outside of IO has to use ST gives me creeps. > > What would you suggest as an alternative? I suppose you could have a > monad which just supported a single array, but special-purpose monads > tend to be a pain in practice (eg. what happens when you want two > arrays?). I'd rather have a monad which just supports a single array as a standard and IO/STArray as a language extension, than the other way. You could tell the same about MonadState. And I've never needed to use ST - somehow MonadState was always enough. And I vaguely remember some problems with typing when I tried to use ST once. IOArray is better - though it is unnatural to be forced to use IO whenever one wants to do something on arrays. So, in the end, if I were to choose between STArray, IOArray and a monad with a single array, I'd choose the monad. Though the best solution probably would be to support all of them. I don't know how the TODO list of nhc developers looks like, but if they aren't implementing multiparameter type classes now, it probably (disclaimer: I am not a Haskell compiler developer) would be easier to implement a simple monad, than type classes + ST. > Simon Wojciech Moczydlowski, Jr From karczma@info.unicaen.fr Thu May 17 07:49:48 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 08:49:48 +0200 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <3B03748C.D65FDD19@info.unicaen.fr> Dylan Thurston cites : > > ... if we [...] want an > > adapted functional language, either we will have to wait quite long, > > or perhaps it is the time to invent another language, with a more > > dynamic type system, with intrinsic graphic utilities, and other > > goodies. > > For myself, I don't see a problem here. For "intrinsic graphic > utilities", someone has to write the graphic libraries. (You don't > mean they should be built into the language, do you?) The type system > is about as strong as anyone knows how to make a static type system; > and it's not too hard to fall back on run-time type checking when > necessary (as Sergey does in BAL). Look what happens with functional graphics. Dozens of really good papers, I could mention many names here. (Some bad papers as well, some people formalize and formalize without any contact with reality...) So, one may want to check all this. You take Alastair Reid's Hugs graphic library, and you discover that: The IO monadic framework is so rigid that you program imperatively, and after a few minutes you ask yourself why for goodness sake do it in Haskell? The programming style is not functional at all. In C++ or Java you do it faster and without more pain. (From the syntactic point of view this is a step backward wrt. the Henderson's book showing how to compose graphics objects in Scheme...) You can't draw individual pixels. (OK, lines with length 1 work). So, impossible to create complicated textures. Impossible to generate complex geometric models rendered pixel by pixel. Try, please, to fill a rectangle with a texture. The graphic updates by the Draw monad will explode the memory quite fast. No relation between bitmaps and arrays. (If the bitmaps work at all.) Similar problems are visible in the Clean library. Both, Hugs and Clean libraries have been added ad hoc to the language environment. Plenty of horrible Windows quirks squeezed into a functional interface. What I mean by *intrinsic* graphics: The graphic primitives should be WELL integrated with the underlying virtual machine. No silly "external" bitmaps impossible to garbage-collect, and impossible to process (thresholding, transfer curves, algebra). No pixels drawn using "line". True, fast access to primitive data. Efficient 2dim and 3dim vectors, with optimized processing thereof. Mapped arrays, easy passage from screen to bitmap DContext. Possibility to have decent functional binding of OpenGL calls. And mind you, OpenGL is not just a bunch of graphic calls, but a "state machine". Some graphic data must be processed by strict algorithms, laziness may deteriorate the efficiency considerably. No, this is not JUST the problem of external libraries. It would be, if the language were at the level of, say, C. But if the runtime is complex with plenty of dynamical data to protect and to recover, and if the internal control transfer is non-trivial (continuations, private stacks, etc.) then adding efficient and powerful graphics <> is not easy. === In my opinion one of best decisions taken by the Rice mafia was to base the DrScheme interface on WxWindows. What a pleasure to produce graphic exercises for students under Linux, test it under Solaris, and work with them under W2000 without a single incompatibility. I am still unhappy, because it is too slow to generate textures at a respectable rate, but no comparison with Hugs which bombs. But perhaps the next version (if ...) will optimize a few things. === And, if you want to have *interactive* graphics, then obviously you must provide some kind of event-processing functionalities. Is this just an external library question? ****************************** No place to discuss type systems here, but "falling back" into run-time checks is not enough in this context, we know that we need a genuine object-oriented genericity for graphical entities. Perhaps even with multiple inheritance or the java-style "interfaces". So, again, a bit more than just "graphic library". Jerzy Karczmarczuk Caen, France From timd@macquarie.com.au Thu May 17 08:42:14 2001 From: timd@macquarie.com.au (Timothy Docker) Date: Thu, 17 May 2001 17:42:14 +1000 (EST) Subject: BAL paper available >> graphic libraries In-Reply-To: <3B03748C.D65FDD19@info.unicaen.fr> References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> Message-ID: <15107.31057.395890.996366@tcc2> Jerzy Karczmarczuk writes: [Some interesting points on functional wrappings of graphics libraries] Has anyone considered writing a haskell wrapper for SDL - Simple Directmedia Layer at http://www.libsdl.org ? This is a cross platform library intended for writing games, and aims for a high performance, low level API. It would be interesting to see how clean a functional API could be built around such an imperative framework. Tim From holzmueller@ics-ag.de Thu May 17 09:06:55 2001 From: holzmueller@ics-ag.de (Bernd =?iso-8859-2?Q?Holzm=FCller?=) Date: Thu, 17 May 2001 10:06:55 +0200 Subject: Proposal for generalized function partition in List-library Message-ID: <3B03869F.88D5EF9D@ics-ag.de> Hi all, knowing that the Haskell library report is currently being rewritten, I would like to propose a new function for module List that generalizes the current function partition :: (a -> Bool) -> [a] -> [[a]] in the following way: partition :: Eq b => (a -> b) -> [a] -> [[a]] partition _ [] = [] partition f (a:as) = let (as',as'') = foldr (select (f a)) ([],[]) as in (a:as'):partition f as'' where select b x (ts,fs) | f x == b = (x:ts,fs) | otherwise = (ts,x:fs) This partitioning function builds equivalence classes from the list argument, where each element list within the result list consists of elements that all map to the same value when applying f to it. Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] This is much more general than the existing partitioning function and applicable in many practical cases. Cheers, Bernd Holzmüller From bedloose@hotmail.com Thu May 17 09:25:10 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:25:10 +0200 (CEST) Subject: Monads Message-ID: <20010517082510.32473.qmail@web14306.mail.yahoo.com> Hi I'v currently working on a school-project where I have to describe the Haskell programming language. I've been looking through Monads and especially the IO monad, the Maybe monad and the list monad My question is why are monads necessary in the language ? Is it not possible to construct the features provided by Monads using basic functional constructs ? What do I gain using Monads ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From ashley@semantic.org Thu May 17 09:41:11 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 01:41:11 -0700 Subject: Monads Message-ID: <200105170841.BAA08310@mail4.halcyon.com> At 2001-05-17 01:25, Mads Skagen wrote: >My question is why are monads necessary in the >language ? > >Is it not possible to construct the features provided >by Monads using basic functional constructs ? Monads themselves are made purely out of basic functional constructs. >What do I gain using Monads ? They happen to be a very convenient pattern. Mostly they're used to model imperative actions: while a purely functional language cannot actually execute actions as part of its evaluation, it can compose them, along the lines of "AB is the action of doing A, and then doing B with its result". Monads happen to be a useful pattern for such things. -- Ashley Yakeley, Seattle WA From bedloose@hotmail.com Thu May 17 09:47:50 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:47:50 +0200 (CEST) Subject: Monads Message-ID: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Thank you for your reply. So what you are saying is that I actually don't need Monads to perform the tasks Monads supports ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From karczma@info.unicaen.fr Thu May 17 10:03:22 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 11:03:22 +0200 Subject: Monads References: <200105170841.BAA08310@mail4.halcyon.com> Message-ID: <3B0393DA.8A105FD7@info.unicaen.fr> Ashley Yakeley answer to Mads Skagen: > >My question is why are monads necessary in the > >language ? > > > >Is it not possible to construct the features provided > >by Monads using basic functional constructs ? > > Monads themselves are made purely out of basic functional constructs. > > >What do I gain using Monads ? > > They happen to be a very convenient pattern. Mostly they're used to model > imperative actions: while a purely functional language cannot actually > execute actions as part of its evaluation, it can compose them, along the > lines of "AB is the action of doing A, and then doing B with its result". > Monads happen to be a useful pattern for such things. PLEASE!!! I disagree quite strongly with such severely limited answers addressed to people who don't know about monads. Monads are *much* more universal than that. They are "convenient patterns" to code the non-determinism (lazy list monads), to generalize the concept of continuations, to add tracing, exceptions, and all stuff called "computation" by the followers of Moggi. They are natural thus to construct parsers. Imperative programming is just one facet of the true story. Mads Skagen: please read the paper by Wadler on the essence of functional programming, and other stuff picked, say, from here: http://hypatia.dcs.qmw.ac.uk/SEL-HPC/Articles/FuncArchive.html That's right you don't really NEED monads (unless you are forced to do IO...), but when you learn them you will feel better and older. Jerzy Karczmarczuk Caen, France From ashley@semantic.org Thu May 17 10:12:16 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 02:12:16 -0700 Subject: Monads Message-ID: <200105170912.CAA09737@mail4.halcyon.com> At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: >Monads are *much* more universal than that. They are "convenient patterns" >to code the non-determinism (lazy list monads), to generalize the concept >of continuations, to add tracing, exceptions, and all stuff called >"computation" by the followers of Moggi. They are natural thus to construct >parsers. Imperative programming is just one facet of the true story. Perhaps, but mostly monads are used to model imperative actions. And their use in imperative programming is the obvious starting point to learning about them. -- Ashley Yakeley, Seattle WA From rjchaaft@cs.uu.nl Thu May 17 10:57:45 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Thu, 17 May 2001 11:57:45 +0200 Subject: Monads In-Reply-To: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Message-ID: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> >So what you are saying is that I actually don't need >Monads to perform the tasks Monads supports ? Indeed. However, not using the Monadic do syntax results in hardly-readible code. For an explanation of how monads can be written in a functional way, see http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm From mg169780@students.mimuw.edu.pl Thu May 17 11:36:39 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Thu, 17 May 2001 12:36:39 +0200 (CEST) Subject: Proposal for generalized function partition in List-library In-Reply-To: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: On Thu, 17 May 2001, Bernd [iso-8859-2] Holzm=FCller wrote: > This partitioning function builds equivalence classes from the list > argument, where each element list within the result list consists of > elements that all map to the same value when applying f to it. > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] >=20 > This is much more general than the existing partitioning function and > applicable in many practical cases. But here generality comes at the expense of speed I think. =09Greetings :-) =09=09Michal Gajda =09=09korek@icm.edu.pl From dscarlett@optushome.com.au Thu May 17 12:07:56 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Thu, 17 May 2001 21:07:56 +1000 Subject: HUGS error: Unresolved overloading Message-ID: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Can anyone shed some light on the following error? Thanks in advance. isSorted :: Ord a => [a] -> Bool isSorted [] = True isSorted [x] = True isSorted (x1:x2:xs) | x1 <= x2 = isSorted (x2:xs) | otherwise = False -------- Hugs session for: /usr/local/share/hugs/lib/Prelude.hs haskell/sort.hs Main> isSorted [1] True Main> isSorted [1,2] True Main> isSorted [2,1] False Main> isSorted [] ERROR: Unresolved overloading *** Type : Ord a => Bool *** Expression : isSorted [] -------- From karczma@info.unicaen.fr Thu May 17 12:36:54 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 13:36:54 +0200 Subject: Monads References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <3B03B7D6.AE80F472@info.unicaen.fr> Ashley Yakeley comments: > > Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. They are "convenient patterns" > >to code the non-determinism (lazy list monads), to generalize the concept > >of continuations, to add tracing, exceptions, and all stuff called > >"computation" by the followers of Moggi. They are natural thus to construct > >parsers. Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. "Mostly" is very relative. The real power of monads is their universality. This "modelling of imperative actions" is just a way to hide the State, which in IO is rather unavoidable. But in my opinion it is rather antipedagogic to introduce monads in such a way to beginners. "Obvious starting point"? My goodness, but this is selling a black, closed box, which smells badly (imperatively) to innocent souls. People see then just do rubbish <- rubbish more_rubbish and don't know anything about the true sense of return, of the relation of <- to >>=, and finally they can use ONLY the IO Monad, nothing else. They start posing questions what is the difference between a <- b and let a = b ... and they get often ungodly answers to that, answers which say that the main difference is that <- "executes side-effects", and let doesn't. It choked me a bit. (Was it on comp.lang.functional, or on one of Haskell lists?) My philosophy is completely opposite. Introduce Monads as a natural way of chaining complex data transfer and hiding useless information, and when the idea is assimilated, then pass to IO. I begin usually with Maybe, then with backtrack Monad, and some simple State Transformers. Then, the students can grasp the Wadler's style slogan "Monads can Change the World". Oh, well, all teaching approaches are imperfect. Jerzy Karczmarczuk Caen, France From rkrueger@TechFak.Uni-Bielefeld.DE Thu May 17 12:56:20 2001 From: rkrueger@TechFak.Uni-Bielefeld.DE (Ralf Krueger) Date: Thu, 17 May 2001 13:56:20 +0200 Subject: HUGS error: Unresolved overloading References: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Message-ID: <3B03BC64.7745016C@uni-bielefeld.de> David Scarlett wrote: > > Can anyone shed some light on the following error? Thanks in advance. > > isSorted :: Ord a => [a] -> Bool > isSorted [] = True > isSorted [x] = True > isSorted (x1:x2:xs) > | x1 <= x2 = isSorted (x2:xs) > | otherwise = False > > -------- [...] > Main> isSorted [] > ERROR: Unresolved overloading > *** Type : Ord a => Bool > *** Expression : isSorted [] > -------- The list constructor [] is overloaded, so it's type cannot be infered inambigously. The empty list can be of any list type, HUGS cannot check if it's parameter's type is an instance of Ord. -- Ralf Krueger E-Mail: rkrueger@TechFak.Uni-Bielefeld.DE URL: http://www.Ralf-Krueger.DE Bielefeld University Center for Interdisciplinary Research (ZiF) WWW Administration Wellenberg 1 33615 Bielefeld Germany Tel: ++49 521 106-2777 From peterd@availant.com Thu May 17 14:25:43 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 09:25:43 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5910@smail01.clam.com> Monads are used not only for programming IO, state, exceptions etc, but also are the foundation of lists. It is hard to imagine functional programming without this basic datatype. Sets, Bags, trees etc are also monads. Phil Wadler wrote a very useful paper Comprehending Monads which I notice is not found on the Haskell/bookshelf web page. It can be found at http://www.cs.bell-labs.com/who/wadler/topics/monads.html I recommend this page for anyone interested in monads. --PeterD > -----Original Message----- > From: Mads Skagen [mailto:bedloose@yahoo.dk] > Sent: Thursday, May 17, 2001 4:25 AM > To: haskell@haskell.org > Subject: Monads > Hi > I'v currently working on a school-project where I have > to describe the Haskell programming language. > I've been looking through Monads and especially the IO > monad, the Maybe monad and the list monad > > My question is why are monads necessary in the > language ? > Is it not possible to construct the features provided > by Monads using basic functional constructs ? > What do I gain using Monads ? > Thank you very much. > Regards Skagen From Joe.Bowers@CanopySystems.com Thu May 17 14:35:19 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Thu, 17 May 2001 09:35:19 -0400 Subject: Wadler (was RE: Monads) Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/plain There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/html Wadler (was RE: Monads) There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0-- From peterd@availant.com Thu May 17 15:30:23 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 10:30:23 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5914@smail01.clam.com> I should probably mention that one doesn't need to know that a list is a monad in order to use a list. However, understanding that a list obeys the monad laws is a useful way to learn about monads. --PeterD > -----Original Message----- > From: Peter Douglass > Sent: Thursday, May 17, 2001 9:26 AM > To: 'bedloose@hotmail.com'; haskell@haskell.org > Subject: RE: Monads > > > Monads are used not only for programming IO, state, > exceptions etc, but also > are the foundation of lists. It is hard to imagine > functional programming > without this basic datatype. Sets, Bags, trees etc are also > monads. Phil > Wadler wrote a very useful paper Comprehending Monads which I > notice is not > found on the Haskell/bookshelf web page. It can be found at > > http://www.cs.bell-labs.com/who/wadler/topics/monads.html > > I recommend this page for anyone interested in monads. > --PeterD > > > > -----Original Message----- > > From: Mads Skagen [mailto:bedloose@yahoo.dk] > > Sent: Thursday, May 17, 2001 4:25 AM > > To: haskell@haskell.org > > Subject: Monads > > > Hi > > > I'v currently working on a school-project where I have > > to describe the Haskell programming language. > > > I've been looking through Monads and especially the IO > > monad, the Maybe monad and the list monad > > > > My question is why are monads necessary in the > > language ? > > > Is it not possible to construct the features provided > > by Monads using basic functional constructs ? > > > What do I gain using Monads ? > > > Thank you very much. > > > Regards Skagen > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From nick@microsoft.com Thu May 17 16:09:06 2001 From: nick@microsoft.com (Nick Benton) Date: Thu, 17 May 2001 08:09:06 -0700 Subject: Final CfP: BABEL Workshop on Multilanguage Infrastructure and Interoperability Message-ID: <0C682B70CE37BC4EADED9D375809768A48EDD9@red-msg-04.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BABEL'01 FINAL CALL FOR PAPERS =20 First Workshop on Multi-Language Infrastructure and Interoperability =20 http://research.microsoft.com/~nick/babel01.htm =20 Satellite to PLI'01 =20 Firenze, Italy, 8th September 2001 =20 Submission Deadline: 1st June 2001 =20 ** The Submission Site is now open ** http://cmt.research.microsoft.com/BABEL01/ =20 AIMS AND SCOPE =20 Recent years have seen a resurgence of interest in multi-language tools and intermediate languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being able to interoperate easily with code written in existing languages is essential for such an implementation to be useful in practice. This workshop aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not limited to: =20 * Compilation of high level languages to common executable formats such as Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common Language Runtime. =20 * Defining and using bindings for component middleware such as OMG's CORBA or Microsoft's COM. =20 * Language constructs to support interoperability between different languages, particularly from different paradigms (e.g. OO/functional). =20 * Multi-language backends for compilation and/or analysis (e.g. MLRISC, FLINT, C--, TAL, SUIF). =20 * Type theoretic and semantic foundations for multi-language work. =20 * Multi-language development environments and tools (e.g. debuggers, profilers). =20 Submissions may address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors unsure of the appropriateness of a potential submission should email the PC chair (nick@microsoft.com). =20 =20 PROGRAMME COMMITTEE =20 Nick Benton (chair) Microsoft Research Fergus Henderson University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett Cornell University Martin Odersky Ecole Polytechnique Federale de Lausanne=20 John Reppy Bell Labs=20 Andrew Tolmach Portland State University=20 David Wakeling University of Exeter =20 =20 INVITED SPEAKERS =20 Zhong Shao Yale University =20 =20 IMPORTANT DATES =20 Deadline for submission 1st June 2001 Notification of acceptance 9th July 2001 Final version due 10th August 2001 =20 =20 SUBMISSION DETAILS =20 Papers should be at most 14 pages and should be submitted in Ghostscript-compatible PostScript or PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS style files (see http://math.tulane.edu/~entcs/). Papers should be submitted electronically via the submission site at http://cmt.research.microsoft.com/BABEL01/ Submissions should not overlap significantly with work which has already been published or submitted to any other conference or journal. An informal proceedings will be published as a technical report and distributed at the workshop. It is intended that a final proceedings will be published in a volume of ENTCS. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable &= nbsp; &n= bsp; BABEL'01 &= nbsp; &n= bsp; FINAL CALL FOR PAPERS &= nbsp; First Workshop on Multi-Language &= nbsp; Infrastructure and Interoperability http://research.= microsoft.com/~nick/babel01.htm &= nbsp; &n= bsp; Satellite to PLI'01 &= nbsp; Firenze, = Italy, 8th September 2001 &= nbsp; Submission Deadline: 1st June = 2001 &= nbsp; ** The Submission Site is now open ** &= nbsp; http://cmt.research.m= icrosoft.com/BABEL01/ AIMS AND = SCOPE Recent years have = seen a resurgence of interest in multi-language tools and intermediate = languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, = analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being = able to interoperate easily with code written in existing languages is essential = for such an implementation to be useful in practice. This workshop = aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not = limited to: * Compilation of = high level languages to common executable formats such as = Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common = Language Runtime. * Defining and = using bindings for component middleware such as OMG's CORBA or = Microsoft's COM. * Language = constructs to support interoperability between different languages, particularly from different paradigms (e.g. = OO/functional). * Multi-language = backends for compilation and/or analysis (e.g. = MLRISC, FLINT, C--, TAL, = SUIF). * Type theoretic = and semantic foundations for multi-language work. * Multi-language = development environments and tools (e.g. debuggers, = profilers). Submissions may = address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors = unsure of the appropriateness of a potential submission should email the PC = chair (nick@microsoft.com). PROGRAMME = COMMITTEE Nick Benton (chair) Microsoft Research Fergus Henderson &= nbsp; University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett &= nbsp; Cornell = University Martin Odersky &= nbsp; Ecole Polytechnique Federale de Lausanne John Reppy &n= bsp; Bell Labs = Andrew Tolmach &= nbsp; Portland = State University David Wakeling &= nbsp; University of Exeter INVITED = SPEAKERS Zhong Shao &= nbsp; Yale = University IMPORTANT = DATES Deadline for submission 1st June 2001 Notification of acceptance 9th July = 2001 Final version due = 10th August 2001 SUBMISSION = DETAILS Papers should be at = most 14 pages and should be submitted in Ghostscript-compatible PostScript or = PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS = style files (see http://math.tulane.edu/~e= ntcs/). Papers should be submitted electronically via the submission site = at http://cmt.research.m= icrosoft.com/BABEL01/ Submissions should = not overlap significantly with work which has already been published or = submitted to any other conference or journal. An informal proceedings will = be published as a technical report and distributed at the workshop. = It is intended that a final proceedings will be published in a volume of = ENTCS. =00 ------_=_NextPart_001_01C0DEE3.5106F5A1-- From farkinas@cbn.net.id Thu May 17 17:21:26 2001 From: farkinas@cbn.net.id (M. Faisal Fariduddin Attar Nasution) Date: Thu, 17 May 2001 23:21:26 +0700 Subject: Questions about Trie Message-ID: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting, I'm a last year student in a computer science field. I'm = currently trying to code an implementation for a compression using basic = Lempel-zif technique. I use a Trie (retrieval) as a data structure for = the dynamic dictionary aplication. The problem is Trie uses not just an = ordinary binary tree, but it uses a multiple-weighted tree, where one = node has at most 256 children. Most literatures about Haskell show only = binary tree for the example in tree or Abstract Data Structures subject. = So, does anyone know how to code the implementation for trie. Thanks for = paying attention and I'm really hoping for the answer immediately. Aerith Gainsborough (Final Fantasy VII) "All I know is..."=20 "The Cetra were born from the Planet, speak with the Planet, and=20 unlock the Planet."=20 "And....... then......"=20 "The Cetra will return to the Promised Land. A land that promises = supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = Greeting, I'm a=20 last year student in a computer science field. I'm currently trying to = code an=20 implementation for a compression using basic Lempel-zif technique. I use = a Trie=20 (retrieval) as a data structure for the dynamic dictionary = aplication. The=20 problem is Trie uses not just an ordinary binary tree, but it uses a=20 multiple-weighted tree, where one node has at most 256 children. Most=20 literatures about Haskell show only binary tree for the example in tree = or=20 Abstract Data Structures subject. So, does anyone know how to code the=20 implementation for trie. Thanks for paying attention and I'm really = hoping for=20 the answer immediately. Aerith Gainsborough (Final Fantasy = VII) "All I=20 know is..." "The Cetra were born from the Planet, speak with the = Planet, and=20 unlock the Planet." "And....... then......" "The Cetra will = return=20 to the Promised Land. A land that promises supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar=20 Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360-- From uk1o@rz.uni-karlsruhe.de Thu May 17 17:18:13 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 17 May 2001 18:18:13 +0200 Subject: Monads In-Reply-To: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl>; from rjchaaft@cs.uu.nl on Thu, May 17, 2001 at 11:57:45AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> Message-ID: <20010517181811.C14548@rz.uni-karlsruhe.de> Hello! On Thu, May 17, 2001 at 11:57:45AM +0200, Rijk-Jan van Haaften wrote: > >So what you are saying is that I actually don't need > >Monads to perform the tasks Monads supports ? > Indeed. However, not using the Monadic do syntax results in > hardly-readible code. I don't really think so. The operator precedences for >> and >>= are quite okay, especially combined to the precedence of lambda binding. How is main = getLine >>= \line -> let number = read line in let result = number + 42 in print result less readable than main = do line <- getLine let number = read line let result = number + 42 print result ? Or main = putStr "Hello! What's your name?" >> getLine >>= \name -> putStrLn ("Hello, " ++ name ++ "!") compared to main = do putStr "Hello! What's your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!") > [...] Yes, I use do syntax where appropriate (e.g. also for usual parser monads), however, the operator syntax can be written quite readably too. Kind regards, Hannah. From simonpj@microsoft.com Thu May 17 17:52:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 17 May 2001 09:52:10 -0700 Subject: Ix class Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F4C@red-msg-09.redmond.corp.microsoft.com> I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding=20 a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com]=20 | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class |=20 |=20 | Hello, |=20 | I am working on an Ix instance for one of my types and=20 | finding it rather restrictive. For me it would be useful to=20 | have rangeSize be defined in the Ix class (with a default=20 | definition of course), so that it can be overridden. |=20 | Also, does anybody know why Ix derives from Ord? It seems to=20 | me this is an unnecessary limitation on the types that can be=20 | instances of Ix. I cannot think of a reason why the=20 | implementation of anything in the Ix or Array modules would=20 | require that every Ix be an Ord (with a minor exception --=20 | see below). If an implementation is using a comparison on an=20 | Ix type, chances are it should be using inRange or comparing=20 | (index bnds x) with (index bnds y) instead. |=20 | One change would have to be made in the Array module if Ord=20 | is removed from Ix: | instance (Ix a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | would become: | instance (Ix a, Eq a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | As I said, I think this is a very minor issue. |=20 | I believe that making these changes in the standard would not=20 | impact existing programs in any way. Could these changes be=20 | considered as a possible "typo" to be fixed in the Library Report? |=20 |=20 | P.S. In case anybody's interested, here's why I want to override | rangeSize: |=20 | > newtype Honeycomb =3D Hx (Int,Int) deriving (Eq,Show,Ord) | >=20 | > indexError =3D error "Index out of range" | >=20 | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) =3D | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) =3D | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) =3D | > let i =3D index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | >=20 | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) =3D x `mod` 2 =3D=3D y `mod` 2 |=20 | This implements a honeycomb or hexagonal tiling for a maze=20 | generating program. The honeycomb is superimposed on a grid=20 | such that only every other square is "active", corresponding=20 | to a particular hexagon in the honeycomb. It's similar to a=20 | checkers game, where only the dark squares are used. |=20 | I would like _any_ pair of Ints to be an acceptable boundary=20 | for the honeycomb, not just the ones that represent valid=20 | indexes. For example, (Hx (0,0), Hx (15,12)) should be a=20 | valid set of bounds. The current definition of rangeSize=20 | makes this impossible, which is why I would like to override=20 | it. By the way, the Library Report does not explicitly say=20 | that the bounds have to both be valid indexes, though it does=20 | imply this with the sample definition of rangeSize. |=20 | Thanks, | Matt Harden |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From gruenbacher-lists@geoinfo.tuwien.ac.at Thu May 17 19:03:23 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Thu, 17 May 2001 20:03:23 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) Message-ID: Hello, I was trying to write an abstraction for bidirectional communication between two threads. For some reason, MVars seem to break: ----------------------------------------------- class Cords c t u where newCord :: IO (c t u) listen :: c t u -> IO t speak :: c t u -> u -> IO () data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) instance Cords Cord t u where newCord = return (Cord newEmptyMVar newEmptyMVar) speak (Cord _ s) t = do s' <- s ; putMVar s' t listen (Cord h s) = do h' <- h ; takeMVar h' otherEnd (Cord t u) = Cord u t showT :: Cord Int String -> IO () showT cord = do putStrLn "Runnning..." x <- listen cord putStrLn ("Heard " ++ show x) speak cord (show x) putStr ("Said " ++ (show x)) showT cord main :: IO () main = do cord <- newCord forkIO (showT (otherEnd cord)) speak cord 1 str <- listen cord putStrLn str ----------------------------------------------- Hugs writes: Main> main Runnning... Program error: no more threads (deadlock?) (131 reductions, 307 cells) Any ideas? Thanks, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789 From john@repetae.net Thu May 17 19:42:50 2001 From: john@repetae.net (John Meacham) Date: Thu, 17 May 2001 11:42:50 -0700 Subject: Proposal for generalized function partition in List-library In-Reply-To: ; from mg169780@zodiac.mimuw.edu.pl on Thu, May 17, 2001 at 12:36:39PM +0200 References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: <20010517114250.D13591@mark.ugcs.caltech.edu> this is just how I understand things at the moment, if I am wrong or misleading anywhere then please speak up. I am unconvinced that such generalizations must come as speed hits, but perhaps someone can enlighten me. compilers seem to support seperate compilation and polymorphism at the moment by boxing polymorphic types and passing their class-context (term?) as a hidden parameter to the polymorphic function. but it seems that since haskell is strongly type checked at compile time, we already KNOW all of the types with certainty when it comes to compiling the program in the end so this would seem to be unnecisarry. now there are two cases where this breaks down * seperate compilation * code bloat namely that you don't necisarilly know all of the types of polymorphic functions when they are in a module that is compiled seperately from the rest of the program. the solution used by many C++ compilers is to inline all polymorphic code in place (this is why templates are in header files). there is no reason this won't work in haskell and give back all of the speed benefits of base types everwhere (as it would in this example) but has the unfortunate side effect of causing worst case exponential code bloat as every function is re-written for every type combination it is used with. the solution I see (and probably exists) is a hybrid model, one that lets the compiler know to specialize certain polymorphic functions as well as let the compiler utilize such specialized functions. a pragma which lets the compiler know that a certain specialization would be useful such as partition :: (Eq b) => (a -> b) -> [a] -> [[a]] partition fn ls = ... {-# specialize partition :: (a -> Bool) -> [a] [[a]] -} which would let the compiler know to generate code for partition specificially optimized for (a -> Bool) and thus obviating the need for the Eq hidden argument. the fully polymorphic version would of course also have to be generated. specializations would be advertised in the header file and utilized whenever the typechecker determined you were using partition in the specialized case. this seems like a better solution than the current practice of providing seperate general and specific functions, take, genTake, max, genMax and whatnot. you would just specify that specializations for the case of 'Int' should be generated as it would be the most common case. an {-# inline partition -} might also be useful which would actually place the text of the function into the .hi file to be in-line expanded as is done in C++... I imagine there would be some tweaking to determine when this is a win and when it isn't... some of this stuff probably exists in current compilers, but polymorphism need not be at the expense of speed. -John On Thu, May 17, 2001 at 12:36:39PM +0200, Michal Gajda wrote: > On Thu, 17 May 2001, Bernd [iso-8859-2] Holzmüller wrote: > > This partitioning function builds equivalence classes from the list > > argument, where each element list within the result list consists of > > elements that all map to the same value when applying f to it. > > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] > > > > This is much more general than the existing partitioning function and > > applicable in many practical cases. > > But here generality comes at the expense of speed I think. -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Thu May 17 20:36:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:36:44 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: Thu, 17 May 2001 10:06:55 +0200, Bernd Holzmüller pisze: > I would like to propose a new function for module List that generalizes > the current function partition :: (a -> Bool) -> [a] -> [[a]] No, current partition has type (a -> Bool) -> [a] -> ([a], [a]) so your function is not compatible with it, so shouldn't replace such standard function. > partition:: Eq b => (a -> b) -> [a] -> [[a]] > partition _ [] = [] > partition f (a:as) = > let (as',as'') = foldr (select (f a)) ([],[]) as > in (a:as'):partition f as'' > where > select b x (ts,fs) | f x == b = (x:ts,fs) > | otherwise = (ts,x:fs) This function doesn't give a hint which sublists correspond to which results of the function, so I'm afraid it's easy to make errors by assuming that they will come in a different order. And it's inefficient: the cost is the number of elements times the number of different results of the function. I would write it thus: \f xs -> groupBy (\(a, _) (b, _) -> a == b) $ sortBy (\(a, _) (b, _) -> compare a b) [(f x, x) | x <- xs] You can apply 'map (map snd)' to the result to remove the results of f. I don't have a good name for it and I'm not sure it's common enough to put it in the standard library. It can also be more efficiently written using Array.accumArray for particular types of the result of the function. PS. What I would perhaps put into standard library: uniq :: Eq a => [a] -> [a] uniqBy :: (a -> a -> Bool) -> [a] -> [a] so people don't use nub unnecessarily (if elements are adjacent or can be made adjacent by sorting), and takeLastWhile :: (a -> Bool) -> [a] -> [a] dropLastWhile :: (a -> Bool) -> [a] -> [a] spanEnd :: (a -> Bool) -> [a] -> ([a], [a]) (with some better names) which iterate forward and are lazy, to avoid double reversing in case the test is cheap but the list is long, and partitionM :: Monad m => (a -> m Bool) -> [a] -> m ([a], [a]) Here are implementations of some of these: takeLastWhile p xs = case span p xs of (ys, []) -> ys (_, _:zs) -> takeLastWhile p zs dropLastWhile p xs = case span p xs of (_, []) -> [] (ys, z:zs) -> ys ++ z : dropLastWhile p zs spanEnd p xs = case span p xs of (ys, []) -> ([], ys) (ys, z:zs) -> (ys ++ z : ys', zs') where (ys', zs') = spanEnd p zs -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Thu May 17 20:43:46 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:43:46 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: 17 May 2001 19:36:44 GMT, Marcin 'Qrczak' Kowalczyk pisze: > PS. What I would perhaps put into standard library: And also: split :: (a -> Bool) -> [a] -> [[a]] split p c = let (xs, ys) = break p c in xs : case ys of [] -> [] _:zs -> split p zs softSplit :: (a -> Bool) -> [a] -> [[a]] -- softSplit p c = filter (not . null) (split p c) softSplit p c = case dropWhile p c of [] -> [] x:xs -> let (ys, zs) = break p xs in (x:ys) : softSplit p zs It follows that words = softSplit isSpace. Any better name? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jenglish@flightlab.com Thu May 17 22:14:53 2001 From: jenglish@flightlab.com (Joe English) Date: Thu, 17 May 2001 14:14:53 -0700 Subject: Monads In-Reply-To: <200105170912.CAA09737@mail4.halcyon.com> References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <200105172114.OAA07367@dragon.flightlab.com> Ashley Yakeley wrote: > At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. [...] > >[...] Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. I don't know about that; I use monads most often when dealing with container classes (sets, bags, lists). They also provide a useful way to reason about parts of XPath and XSLT. As far as learning about them goes, I don't think I really "got" monads until reading Wadler's aptly-titled "Comprehending Monads", which approaches them from this perspective. --Joe English jenglish@flightlab.com From agold@bga.com Thu May 17 22:21:21 2001 From: agold@bga.com (Arthur H. Gold) Date: Thu, 17 May 2001 16:21:21 -0500 Subject: Questions about Trie References: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> Message-ID: <3B0440D1.2248C105@bga.com> > "M. Faisal Fariduddin Attar Nasution" wrote: > > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using > basic Lempel-zif technique. I use a Trie (retrieval) as a data > structure for the dynamic dictionary aplication. The problem is Trie > uses not just an ordinary binary tree, but it uses a multiple-weighted > tree, where one node has at most 256 children. Most literatures about > Haskell show only binary tree for the example in tree or Abstract Data > Structures subject. So, does anyone know how to code the > implementation for trie. Thanks for paying attention and I'm really > hoping for the answer immediately. > IIRC, there's a trie implementation in Chris Okasaki's "Purely Functional Data Structures" -- that might be a start (there's also his "Edison" library, which contains many of the components you'd need). HTH (and sorry if it doesn't) --ag -- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu -- I am looking for work. Contact me. From ken@digitas.harvard.edu Thu May 17 22:17:49 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Thu, 17 May 2001 17:17:49 -0400 Subject: Wadler (was RE: Monads) In-Reply-To: ; from Joe.Bowers@CanopySystems.com on Thu, May 17, 2001 at 09:35:19AM -0400 References: Message-ID: <20010517171749.A25335@digitas.harvard.edu> --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-17T09:35:19-0400, Joe Bowers wrote: > There have been several references to "a paper by > Wadler" in this thread- some folks (well, at least > one folk :) on this list may not be familiar with > the work surrounding Haskell yet, and (from this context) > This paper seems like a pretty good place to start. > =20 > Would anybody have a detailed citation for it, > or (even better) is it up on the web? Wadler's monad papers, including "Comprehending Monads", are at http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig My god, I've seen heaven. - Flute at Band Camp --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BD/9zjAc4f+uuBURAnmcAJ9M6+wyOg+izO2eQo3GS5ovm55P+ACguuzz 9a35nSAI8w6IuYvSs7+ei7M= =9zoV -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From karczma@info.unicaen.fr Fri May 18 07:56:57 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 08:56:57 +0200 Subject: Monads References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> Message-ID: <3B04C7B9.D14AA827@info.unicaen.fr> Rijk-Jan van Haaften >>= Hannah Schroeter: > > ... However, not using the Monadic do syntax results in > > hardly-readible code. > > I don't really think so. The operator precedences for >> and >>= are > quite okay, especially combined to the precedence of lambda binding. ... > main = do > putStr "Hello! What's your name?" ... > Yes, I use do syntax where appropriate (e.g. also for usual parser > monads), however, the operator syntax can be written quite readably > too. I would add that sometimes you may be interested in Monadic SEMANTICS at a more profound level, trying to hide it completely at the surface. Then, the <> syntax is an abomination. The examples are already in the Wadler's "Essence". Imagine the construction of a small interpreter, a virtual machine which not only evaluates the expressions (belonging to a trivial Monad), but perform some side effects, or provides for exceptions propagated through a chain of Maybes. Then the idea is to * base the machine on the appropriate Monad * "lift" all standard operators so that an innocent user can write (f x) and never x >>= f (or even worse). The <> construct in such a context resembles the programming in assembler, and calling it more readable is hmmmm... not very convincing. (My favourite example is the "time-machine" monad, a counter-clock-wise State Monad proposed once by Wadler, and used by myself to implement the reverse automatic differentiation algorithm. Understanding what's going on is difficult. The <> syntax makes it *worse*.) Jerzy Karczmarczuk Caen, France From josefs@cs.chalmers.se Fri May 18 09:32:54 2001 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Fri, 18 May 2001 10:32:54 +0200 (MET DST) Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: John, On Thu, 17 May 2001, John Meacham wrote: [..] > namely that you don't necisarilly know all of the types of polymorphic > functions when they are in a module that is compiled seperately from the > rest of the program. the solution used by many C++ compilers is to > inline all polymorphic code in place (this is why templates are in > header files). there is no reason this won't work in haskell and give > back all of the speed benefits of base types everwhere (as it would in > this example) but has the unfortunate side effect of causing worst case > exponential code bloat as every function is re-written for every type > combination it is used with. > This is true in ML but not in Haskell. Haskell has polymorphic recursion which makes it impossible to predict statically at what types a function will be called. So trying to inline away polymorphism would lead to infinite unwindings. Cheers, /Josef From Colin.Runciman@cs.york.ac.uk Fri May 18 09:43:10 2001 From: Colin.Runciman@cs.york.ac.uk (Colin.Runciman@cs.york.ac.uk) Date: Fri, 18 May 2001 09:43:10 +0100 Subject: Questions about Trie Message-ID: <200105180843.JAA00498@pc179.cs.york.ac.uk> > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using basic > Lempel-zif technique. I use a Trie (retrieval) as a data structure for > the dynamic dictionary aplication. The problem is Trie uses not just an > ordinary binary tree, but it uses a multiple-weighted tree, where one > node has at most 256 children. Most literatures about Haskell show only > binary tree for the example in tree or Abstract Data Structures subject. > So, does anyone know how to code the implementation for trie. Thanks for > paying attention and I'm really hoping for the answer immediately. There is some relevant material in Chapter 6 (Text compression) of `Applications of Functional Programming', UCL Press, 1995. ISBN: 1-85728-377-5. (With apologies for self-reference, as co-editor of the book.) Colin R From lennart@mail.augustsson.net Fri May 18 10:02:58 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Fri, 18 May 2001 11:02:58 +0200 Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library References: Message-ID: <3B04E542.76BA65A5@mail.augustsson.net> Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. This is true in theory, but in practice most polymorphism can be removed by inlining. I'm sure some pragmatic solution with limited inlining would work quite well. You'd still need to be able to handle polymorphism without inlining, of course, so you could cope with the exceptional cases. Mark Jones did some experiments with this kind of inlining that worked very well. -- Lennart From karczma@info.unicaen.fr Fri May 18 10:25:14 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 11:25:14 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> Message-ID: <3B04EA7A.90D83CFB@info.unicaen.fr> Maestri, Primaballerine, I have a really provocative question. One of my student posed it, and I could not respond in a satisfactory manner, especially for myself it was really unsatisfactory. We know that a good part of "top-down" polymorphism (don't ask me what do I mean by that...) in C++ is emulated using templates. Always when somebody mentions templates in presence of a True Functionalist Sectarian, the reaction is "What!? Abomination!!". Now the question: WHY? Why so many people say "the C++ templates are *wrong*" (and at the same time so many people use it every day...) Is it absolutely senseless to make a functional language with templates? Or it is just out of fashion, and difficult to implement? == This is a sequel to a former discussion about macros, of course... Jerzy Karczmarczuk Caen, France From bjpop@cs.mu.OZ.AU Fri May 18 10:30:38 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Fri, 18 May 2001 19:30:38 +1000 (EST) Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library In-Reply-To: <3B04E542.76BA65A5@mail.augustsson.net> from Lennart Augustsson at "May 18, 2001 11:02:58 am" Message-ID: <200105180930.TAA25290@mulga.cs.mu.OZ.AU> Lennart wrote: > This is true in theory, but in practice most polymorphism can be removed > by inlining. I'm sure some pragmatic solution with limited inlining would > work quite well. You'd still need to be able to handle polymorphism without > inlining, of course, so you could cope with the exceptional cases. > > Mark Jones did some experiments with this kind of inlining that worked very well. > > -- Lennart The MLton compiler (http://www.clairv.com/MLton/) uses whole program compilation and monomorphises ML code (again they do not have to deal with potential polymorhpic recursion, but as Lennart says, it can be treated as a special case in Haskell). I have never used it though, so I can't vouch for its performance. They are motivated to use unboxed representations and so on. The danger with whole program compilation is long compile times. But it might be possible to allow separate compilation for development and put up with the overheads of boxed representations and so on, but get the benefits of the optimisations flowing from whole program compilation when needed (ie released binaries). Sounds like a lot of work to me though. Bernie. From simonpj@microsoft.com Fri May 18 08:28:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 18 May 2001 00:28:50 -0700 Subject: Questions about Trie Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F50@red-msg-09.redmond.corp.microsoft.com> Perhaps this monads discussion might move to haskell-cafe@haskell.org? It's a good discussion, but it's just what haskell-cafe is for. http://www.haskell.org/mailinglist.html Simon | -----Original Message----- | From: Arthur H. Gold [mailto:agold@bga.com]=20 | Sent: 17 May 2001 22:21 | To: haskell@haskell.org | Cc: M. Faisal Fariduddin Attar Nasution | Subject: Re: Questions about Trie |=20 |=20 | > "M. Faisal Fariduddin Attar Nasution" wrote: | >=20 | > Greeting, I'm a last year student in a computer science=20 | field. I'm=20 | > currently trying to code an implementation for a =20 | compression using=20 | > basic Lempel-zif technique. I use a Trie (retrieval)=20 | as a data=20 | > structure for the dynamic dictionary aplication. The=20 | problem is Trie=20 | > uses not just an ordinary binary tree, but it uses a=20 | multiple-weighted=20 | > tree, where one node has at most 256 children. Most=20 | literatures about=20 | > Haskell show only binary tree for the example in tree or=20 | Abstract Data | > Structures subject. So, does anyone know how to =20 | code the | > implementation for trie. Thanks for paying attention and=20 | I'm really=20 | > hoping for the answer immediately. | >=20 |=20 | IIRC, there's a trie implementation in Chris Okasaki's=20 | "Purely Functional Data Structures" -- that might be a start=20 | (there's also his "Edison" library, which contains many of=20 | the components you'd need). |=20 | HTH (and sorry if it doesn't) | --ag |=20 | --=20 | Artie Gold, Austin, TX (finger the cs.utexas.edu account for=20 | more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu | -- | I am looking for work. Contact me. |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From tweed@compsci.bristol.ac.uk Fri May 18 11:22:36 2001 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Fri, 18 May 2001 11:22:36 +0100 (BST) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: (This response comes from the context of someone who like FP but has a day job writing in C++.) On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. Umm... what do you mean by `top down'? The two senses in which I use polymorphism in C++ are: (i) using super classes (in the sence that A is a superclass of B is B inherits from A) to perform operations that only make sense for objects of the semantic type A. My canonical example is working with quadtree nodes, where a there are various types nodes which can hold different kinds of data but the base class qnode holds things like position, etc. (ii) using templates to write generic algorithms which either don't depend on the object type at all (e.g., vectors, lists, etc) or which depend on one or two conceptual operations which are very elementary (e.g., meaningful equality, addition or a `display yourself on stdout' function). In C++ these could _almost_ be done using superclasses but with problems because (A) the standard types (e.g., int) can't have their place in the class hierarchy redefined (e.g., int inherits from debug_show) (B) deep hierarchies are really not handled well by debuggers and it'd be a real pain trying to look at the C++ equivalent of the haskell `data A = ... deriving (Show,Ord,Monad,...)' The almost that I referred to above comes from the fact that (AFAIK) without using something nasty like RTTI you can't create new objects of the true type in a function to which you've passed a pointer to the base class. That's the conceptual overview. In terms of pragmatics __at least for my work in image processing__ I don't write classes that much, seldom use inheritance and I'm 99% sure I don't have any inheritance more than 1 level deep. On the other hand I write a lot of templated code which would be equivalent in haskell to either f :: a -> b -> .... -> a or f :: Eq a => a -> b -> ... -> a (i.e., algorithms that need just one or two low-level ideas such as equality). I much prefer the Haskell way of doing this with superclasses but I just don't feel brave enough to attempt the levels of class hierarchy that this implies in C++. (In some ways this is a shame since, because in template function names member functions used are only matched syntactically -- as there's no superclass to ensure semantic equivalence -- I've made one or two mistakes when I forgot a member function with the same name actually meant something different.) > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) In my experience the C++ idiom `you only pay for what you use' (==> templates are essentially type-checked macros) and the fact most compilers are evolved from C compilers makes working with templates a real pain in practice. Additionally, I think a lot of people who dislike them are old-time C hackers who don't see why it isn't good enough to do polymorphism via void*'s and function pointers. As to why I at least use it, it lets me write polymorphic functions without needing deep class hierarchies (which as noted above aren't nice in C++) or going into the error prone mire of the void* approach. > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? I may be missing something obvious, but given Haskell's well thought out (IMO) prelude class structure and the fact that deep class hierarchies with `multiple inheritance' aren't a problem in Haskell, I don't see that it would buy you anything in Haskell. On the other hand, if the standard prelude didn't have the class hierarchy I think they would be much more useful. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. From heringto@cs.unc.edu Fri May 18 15:30:38 2001 From: heringto@cs.unc.edu (Dean Herington) Date: Fri, 18 May 2001 10:30:38 -0400 Subject: MVar Problem (Concurrent Hugs) References: Message-ID: <3B05320E.6FE477AA@cs.unc.edu> Andreas Gruenbacher wrote: > Hello, > > I was trying to write an abstraction for bidirectional communication > between two threads. For some reason, MVars seem to break: > > ----------------------------------------------- > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > > data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) > > instance Cords Cord t u where > newCord = return (Cord newEmptyMVar newEmptyMVar) > speak (Cord _ s) t = do s' <- s ; putMVar s' t > listen (Cord h s) = do h' <- h ; takeMVar h' > > otherEnd (Cord t u) = Cord u t > > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStr ("Said " ++ (show x)) > showT cord > > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str > ----------------------------------------------- You are creating a new MVar with each listen and speak. As a result, the two threads never agree on an MVar, so deadlock occurs. Instead, you should create the pair of MVars in newCord. Try the code below. > import Concurrent > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > data Cord t u = Cord (MVar t) (MVar u) > instance Cords Cord t u where > newCord = do t <- newEmptyMVar > u <- newEmptyMVar > return (Cord t u) > listen (Cord t _) = takeMVar t > speak (Cord _ u) s = putMVar u s > otherEnd (Cord t u) = Cord u t > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStrLn ("Said " ++ show x) > showT cord > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str Dean From gruenbacher-lists@geoinfo.tuwien.ac.at Fri May 18 16:54:49 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Fri, 18 May 2001 17:54:49 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) In-Reply-To: <3B05320E.6FE477AA@cs.unc.edu> Message-ID: On Fri, 18 May 2001, Dean Herington wrote: > You are creating a new MVar with each listen and speak. As a result, the > two threads never agree on an MVar, so deadlock occurs. Instead, you should > create the pair of MVars in newCord. Try the code below. > > [...] Thanks, this works. Thanks! --Andreas. From ger@tzi.de Fri May 18 17:22:07 2001 From: ger@tzi.de (George Russell) Date: Fri, 18 May 2001 18:22:07 +0200 Subject: Templates in FPL? Message-ID: <3B054C2F.C1BBE335@tzi.de> The MLj compiler from ML to the Java Virtual Machine (which is being actively worked on by the geniuses at Microsoft as we speak) expands out all polymorphism. I helped develop this compiler and I believe this approach to be a good one. There are particular reasons why it's good for this case (1) as has been said before, ML does not have polymorphic recursion; (2) the cost of object creation in Java used at least to be horrendous, so it was well worth working hard to get rid of it. However I think long term it's a good idea for normal Haskell compilers because my guess is you will Win Big on quite a lot of things, because you don't have to carry around and use dictionaries (for method lookup in class instances) and can do a lot more specialisation and inlining. Strict values can also be unboxed. Of course you can control specialisation used unboxed values already in Glasgow Haskell, but it requires special annotations or special types. The minus points are thuswise, so far as I know: (1) the compiled code is bigger. This means the code might indeed run more slowly. But with MLj I think we found that in normal cases it isn't THAT much bigger (maybe about 50%), because the functions which get specialised a lot (like "length" and "map") tend to be pretty small. Of course you can construct artificial cases where the code size will explode. (2) It takes much longer to compile. I'm waiting for Moore's law here, but at present I would be surprised if (say) Glasgow Haskell could compile itself inlining out all polymorphism, without it taking a very long time or a very fast computer or lots of nasty imperative optimisations. (3) You can't inline everything, because of polymorphic recursion, and also because it would be nice to allow Haskell code to be dynamically linked in (see GHCi). Or you can inline everything, but then you need to implement a Haskell Virtual Machine which does the inlining (and the whole compiler backend) on demand at runtime. I don't think you have to inline everything; it should surely be possible to leave polymorphic versions of the functions around, to use for hard cases. From msk@post.tepkom.ru Fri May 18 17:33:46 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Fri, 18 May 2001 20:33:46 +0400 (MSD) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? ordinary FP polymorphish is as strict analogue of the C++ template-functions Haskell type clasess is as close analog for the C++ template classes (studing of the Haskell type classes clarify to me many aspects of the C++ classes templates semantic). Regards, Anton From ken@digitas.harvard.edu Fri May 18 20:08:47 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Fri, 18 May 2001 15:08:47 -0400 Subject: Monads In-Reply-To: <3B04C7B9.D14AA827@info.unicaen.fr>; from karczma@info.unicaen.fr on Fri, May 18, 2001 at 08:56:57AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> <3B04C7B9.D14AA827@info.unicaen.fr> Message-ID: <20010518150847.A6077@digitas.harvard.edu> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-18T08:56:57+0200, Jerzy Karczmarczuk wrote: > The examples are already in the Wadler's "Essence". Imagine the=20 > construction of a small interpreter, a virtual machine which not only > evaluates the expressions (belonging to a trivial Monad), but perform > some side effects, or provides for exceptions propagated through a > chain of Maybes. Then the idea is to >=20 > * base the machine on the appropriate Monad > * "lift" all standard operators so that an innocent user can write (f x) > and never x >>=3D f (or even worse). Perhaps you already know about Filinski's PhD thesis? He seems to have proven that we already have the "small interpreter" you want, inside of any programming language that supports call/cc and storing a function in a single storage cell. ML is such a programming language. You can define your own monads yet rely on implicit evaluation ordering in ML to do the lifting you want! --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Learn Esperanto and make friends around the world http://www.esperanto.net --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BXM/zjAc4f+uuBURAtYcAKCafrEuesrlWUObVdidMDJf5VCzwACfcAQb 9vI2sHi/yei+T2JVHxC/sZE= =fDKP -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From qrczak@knm.org.pl Fri May 18 20:11:21 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 19:11:21 GMT Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Fri, 18 May 2001 11:25:14 +0200, Jerzy Karczmarczuk pisze: > Always when somebody mentions templates in presence of a True > Functionalist Sectarian, the reaction is "What!? Abomination!!". They aren't that wrong, but they have some problems: * It's not specified what interface they require from types to be instantiated to. * The whole implementation must be present in a public header file. Well, there is the 'export' keyword, but no compiler implements it. It follows that all things used by implementation of a template must be included too. And compilation time of a large project is larger than necessary. * They introduce very complex rules about name lookup (environment in which a specialized template is compiled is a weird mix of environments of the point of definition and point of usage of the template), deduction which overloading to use (with choosing the candidate according to partial ordering of better fitting), deduction of template types and what partial specialization to use, complicated by the fact that there are complex rules of implicit conversions. Templates don't obey a Haskell's rule that adding code doesn't change the meaning of previously valid code and can at most introduce an ambiguity which is flagged as error. * Types can't be deduced from the context of usage. For example handling the empty set or monadic 'return' would require either spelling the type at each use or introducing another type and deferring deduction of the real type until an operation is performed with a value of a known type. * Since they are similar to macros, they tend to give horrible error messages which mentions things after expansion. Here is what I once got: mico-c++ -Wall -I. -c serwer.cc -o serwer.o serwer.cc: In method `void Firma_impl::usun(const char *)': serwer.cc:92: `struct __rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *>' has no member named `second' serwer.cc:93: no matching function for call to `map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase (__rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *> &)' /usr/include/g++/stl_map.h:156: candidates are: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>) /usr/include/g++/stl_map.h:157: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(const string &) /usr/include/g++/stl_map.h:158: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>, __rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair, __default_alloc_template >,Katalog *> *>) make: *** [serwer.o] Error 1 They also have some advantages over mechanisms available in Haskell: * A templatized class can contain types, values with arbitrary types, other templates etc. so it's easy to have parametrization of all things by types. Haskell requires fundeps, dummy arguments and local quantifiers to handle these things - sometimes it's not nice. * A template can be parametrized by values of primitive types (by expressions using builtin operations which can be evaluated at compile time). Yes, it's ugly that types and operations don't have equal rights, but it's sometimes useful. * A template is in practice guaranteed to be specialized to used types, so they don't have a performance overheads over non-templatized variants. My not-quite-done-right attempt at inlining dictionary functions in ghc is a step in this direction, as is the proposal of export-unfolding-and-specialize-but-not-necessarily-inline. I hope that SimonPJ will sort this out. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@repetae.net Fri May 18 20:32:11 2001 From: john@repetae.net (John Meacham) Date: Fri, 18 May 2001 12:32:11 -0700 Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: ; from josefs@cs.chalmers.se on Fri, May 18, 2001 at 10:32:54AM +0200 References: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: <20010518123211.E13591@mark.ugcs.caltech.edu> this is interesting, could someone give an example of how polymorphic recursion would disallow specialization of a function? i mean, it seems to me that even if you had recursion, you still have to actually call the function at some point with some real type and at that point you can decide whether to use the specialized version or not. One of the main things i was hopeing was that the seperate 'generic' and 'concrete' functions in the Prelude could be dumped for just the generic ones. the compiler should be able to optimize for the common cases of Nums being Ints and whatnot. (with the help of some pragma annotations.) -John On Fri, May 18, 2001 at 10:32:54AM +0200, Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. > > Cheers, > /Josef -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From mg169780@students.mimuw.edu.pl Fri May 18 22:10:54 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Fri, 18 May 2001 23:10:54 +0200 (CEST) Subject: Templates in FPL? In-Reply-To: <3B054C2F.C1BBE335@tzi.de> Message-ID: On Fri, 18 May 2001, George Russell wrote: > The minus points are thuswise, so far as I know: > (1) the compiled code is bigger. (...) > (2) It takes much longer to compile. (...) As it is very aggressive optimization, I strongly suggest explicit(non-default) compiler switch Greetings :-) Michal Gajda korek@icm.edu.pl From qrczak@knm.org.pl Fri May 18 21:44:52 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 20:44:52 GMT Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library References: <20010517114250.D13591@mark.ugcs.caltech.edu> <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > this is interesting, could someone give an example of how polymorphic > recursion would disallow specialization of a function? test:: Show a => a -> [String] test x = show x : test [x] -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From Jan de Wit" <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: <002a01c0e076$6029f8a0$9505c5d5@yatima> From: "Marcin 'Qrczak' Kowalczyk" > Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > > > this is interesting, could someone give an example of how polymorphic > > recursion would disallow specialization of a function? > > test:: Show a => a -> [String] > test x = show x : test [x] Another source of programs needing polymorphic recursion are non-regular datatypes, which occur frequently in Chris Okasaki's _Purely_Functional_Data_Structures_. A bare-bones example is: | data Perfect a = One a | Two (Perfect (a,a)) | deriving Show | | mkPerfect :: Int -> a -> Perfect a | mkPerfect 1 x = One x | mkPerfect (n+1) x = Two (mkPerfect n (x,x)) mkPerfect will be called with a number of different types for its second argument, depending on the first argument. HTH, Jan de Wit From luc.taesch@csfb.com Mon May 21 12:48:22 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Mon, 21 May 2001 13:48:22 +0200 Subject: PP with HaXml 1.02 Message-ID: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Im proceeding with basic exploratory tests witrh HaXml (1.02, winhugs feb 2001) the pretty print return the closing < on the next line, like what am i doing wrong ? ( the call is like import qualified XmlPP as PP ... main = do content <- readFile "subjdb.xml" (putStrLn . render . PP.document . parse) content (btw, thanks malcolm for packaging a specific hugs distribution) This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ketil@ii.uib.no Mon May 21 13:48:36 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 21 May 2001 14:48:36 +0200 Subject: PP with HaXml 1.02 In-Reply-To: "Taesch, Luc"'s message of "Mon, 21 May 2001 13:48:22 +0200" References: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Message-ID: "Taesch, Luc" writes: > the pretty print return the closing < on the next line, like > > > where i expect > > > My guess is that HaXML doesn't validate (using the DTD) or simply ignores it for pretty printing purposes. If the "Person-XML" element were defined to hold #PCDATA as well as (a) "Name" element(s), the two examples above are not equivalent, since you've added white space characters to the contents. Adding whitespace within the tag is okay, though, since it doesn't change the semantics of the document. > This message is for the named person's use only. It may contain [...] (Jeez! Has CSFB hear of mailing lists?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From taha@cs.yale.edu Mon May 21 16:17:26 2001 From: taha@cs.yale.edu (Walid Taha) Date: Mon, 21 May 2001 11:17:26 -0400 (EDT) Subject: SAIG'01 Extended Deadline In-Reply-To: References: Message-ID: CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (EXTENDED DEADLINE: June 1st, 2001) Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and system= s address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice= =2E The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) I= n addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by June 1st, 2001. This extended deadline is final. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha,Yale (PC Chair) URL: http://cs-www.cs.yale.edu/homes/taha/saig/cfp01.html From taha@cs.yale.edu Mon May 21 16:17:26 2001 From: taha@cs.yale.edu (Walid Taha) Date: Mon, 21 May 2001 11:17:26 -0400 Subject: SAIG'01 Extended Deadline In-Reply-To: References: Message-ID: CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (EXTENDED DEADLINE: June 1st, 2001) Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and system= s address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice= =2E The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) I= n addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by June 1st, 2001. This extended deadline is final. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha,Yale (PC Chair) URL: http://cs-www.cs.yale.edu/homes/taha/saig/cfp01.html From Malcolm.Wallace@cs.york.ac.uk Mon May 21 19:01:01 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Mon, 21 May 2001 19:01:01 +0100 Subject: ANNOUNCE: nhc98 1.04 and Hat 1.04 Message-ID: We are pleased to announce a new release of the nhc98 compiler, and in particular its facilities (both brand new and improved old stuff) for tracing and debugging Haskell programs - the Hat system. The basic nhc98 compiler version 1.04 is mostly a bugfix release (details listed at the bottom of this announcement). http://www.cs.york.ac.uk/fp/nhc98/ However, the stuff we are really excited about is Hat - our Haskell tracer. A full user guide to these new tools is available on the website. http://www.cs.york.ac.uk/fp/hat/ Hat 1.04 ======== * Lots more tools for tracing! hat-stack - Displays a "virtual" stack-trace for any program that failed with a runtime error. hat-detect - Algorithmic bug detection, based on a textual question-and-answer session. hat-trail - The original graphical trail browser, now with several presentation enhancements. hat-observe - Examine the inputs and outputs of any named function, in the style of HOOD. * Tracing with Hat is now based on a completely new architecture (although still within the nhc98 compilation system). A program compiled for tracing now builds its "redex trails" in file, not in the heap. This has some performance consequences: (1) you no longer need to allocate large amounts of heap memory for tracing; (2) but you will probably need large amounts of disk space instead - remember disk space is cheap; (3) and traced programs still run somewhat slowly. * However, there are a couple of major benefits in return: (1) A trace is persistent, so after running your program once, you can examine many different aspects of the trace without re-computation. (2) Traces are now first-class objects, so you can examine and manipulate them in far more detail - hence the variety of new tracing tools. * Greater Haskell'98 compatibility. Almost all language features are now supported: named fields and better handling of pattern bindings are the main additions. All standard libraries except Time and Locale are now supported. nhc98 1.04 ========== * New: Improved (more accurate) time profiling now provided. * New: Support for extended module namespaces of the form Long.Hierarchical.Module.Name is now provided in both nhc98 and hmake. * Bugfix: An identifier hidden on import and redefined in the current module, then exported, but also imported qualified and used qualified in the current module, led to an incorrect interface file being generated. * Bugfix: hmake issued an unnecessary -cpp flag on some literate files. * Bugfix: Type of IO.hSetPosn :: Handle -> HandlePosn -> IO () was incorrect. * Bugfix: Compile-time error in src/tracer/runtime/ident.c on RedHat 7 and other systems using the new ISO C standard for fpos_t. * Bugfix: A file opened in ReadMode or WriteMode was actually opened in ReadWriteMode, so if the file had strict permissions the correct opening command would fail. Conversely, opening in ReadWriteMode actually gave ReadMode instead, and file updates silently failed. * Bugfix: Operator sections suffered from priority inversion, for example (^2*3) was incorrectly parsed as (^(2*3)), even though ^ binds more tightly than *. * Bugfix: The library function Directory.createDirectory gave strange permissions to the new directory. (Mode was in hex, but should have been octal!) * New: Improved printing of I/O error messages. Happy tracing! The Hat team at York (Colin Runciman, Olaf Chitil, Malcolm Wallace, Thorsten Brehm, Phil Hassall) From mikg@free.fr Mon May 21 19:51:37 2001 From: mikg@free.fr (=?iso-8859-1?Q?Micka=EBl_GAUTIER?=) Date: Mon, 21 May 2001 20:51:37 +0200 Subject: Problem to load the file Stack.hs with Hugs98 Message-ID: <00c901c0e227$74411c80$3406e4d5@machinegun> This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to use the file stack.hs wich is provided with Hugs 98 but = the following message errors display: "Haskell98 does not support restricted type synonyms" Can you explain me why and how I can load stack.hs ? Thanks in advance ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to use the file stack.hs wich is = provided=20 with Hugs 98 but the following message errors display: "Haskell98 does not support restricted type=20 synonyms" Can you explain me why and how I can load stack.hs=20 ? Thanks in advance ------=_NextPart_000_00BA_01C0E237.D4539520-- From qrczak@knm.org.pl Mon May 21 21:30:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 21 May 2001 20:30:44 GMT Subject: Problem to load the file Stack.hs with Hugs98 References: <00c901c0e227$74411c80$3406e4d5@machinegun> Message-ID: Mon, 21 May 2001 20:51:37 +0200, Mickaël GAUTIER pisze: > I would like to use the file stack.hs wich is provided with Hugs 98 but > the following message errors display: > "Haskell98 does not support restricted type synonyms" > Can you explain me why and how I can load stack.hs ? hugs -98 Stack.hs This command line flag enables non-Haskell-98 extensions. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From davidbak@microsoft.com Tue May 22 02:23:31 2001 From: davidbak@microsoft.com (David Bakin) Date: Mon, 21 May 2001 18:23:31 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm having trouble understanding recursive types (e.g., as described in Functional Programming with Overloading and Higher-Order Polymorphism by Jones. =20 He gives as an example =20 =20 > data Mu f =3D In (f (Mu f)) =20 > data NatF s =3D Zero | Succ s > type Nat =3D Mu NatF =20 Among the things I don't get are: =20 1. Comparing this to the non-higher-order type: =20 > data NatX =3D Zero | Succ NatX =20 What are the advantages of the higher-order type? What are the disadvantages (incl. runtime costs)? =20 2. How are values of type Nat represented? (It helps me to think about these things concretely.) =20 Thanks! -- Dave =20 =20 ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm = having trouble=20 understanding recursive types (e.g., as described in Functional = Programming=20 with Overloading and Higher-Order Polymorphism by=20 Jones. He = gives as an=20 example > = data Mu f =3D In=20 (f (Mu f)) > = data NatF s =3D=20 Zero | Succ s > = type Nat =3D Mu=20 NatF Among = the things I=20 don't get are: 1. Comparing=20 this to the non-higher-order type: > = data NatX =3D=20 Zero | Succ NatX What = are the=20 advantages of the higher-order type? What are the disadvantages = (incl.=20 runtime costs)? 2. How are=20 values of type Nat represented? (It helps me to think about these things = concretely.) Thanks! --=20 Dave ------_=_NextPart_001_01C0E25D.CFC0BA65-- From Tom.Pledger@peace.com Tue May 22 03:24:55 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Tue, 22 May 2001 14:24:55 +1200 Subject: Recursive types? In-Reply-To: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> Message-ID: <15113.52727.506242.598828@waytogo.peace.co.nz> David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | | He gives as an example | | | > data Mu f = In (f (Mu f)) | | > data NatF s = Zero | Succ s | > type Nat = Mu NatF | | Among the things I don't get are: | | 1. Comparing this to the non-higher-order type: | | > data NatX = Zero | Succ NatX | | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e = c k (Tree c k e) -- Contained Tree, container, key, element data Tree c k e = Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t = Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom From luc.taesch@csfb.com Tue May 22 11:19:01 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Tue, 22 May 2001 12:19:01 +0200 Subject: using haxml dynamically Message-ID: <9818339E731AD311AE5C00902715779C0371A779@szrh00313.tszrh.csfb.com> How can i use HaXml to produce xml, but in a dynamic way? i mean : 1) what i understand from the example is - u have a type H in haskell - u derive (manally or with drift) an instance Haskell2xml out of it (defines tocontenst, from contents) - u use it, say with to xml, from xml 2) id like to generate an xml structure computed from some schema works, which means that the structure will be build "dynamically" at run time, ie I wont build the structure from an haskell type, not wont i have an haskell2xml instance at hand. (and i dont want to generate an intermediate haskell file and load/compile it) are there a way to create/fill/describe an xml structure "dynamically", ie as a result of some computation (with haxml, i mean) ? a bit like the example 4 from the paper , fixed with the recent names ? This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ltaesch@europemail.com Tue May 22 22:25:05 2001 From: ltaesch@europemail.com (luc) Date: Tue, 22 May 2001 21:25:05 +0000 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> <15107.31057.395890.996366@tcc2> Message-ID: <3B0AD931.190DCF22@europemail.com> Timothy Docker wrote: for info, there is a gui lib on top of sdl (then portable to linux, win) at http://www.bms-austria.com/projects/paragui/ > Jerzy Karczmarczuk writes: > > [Some interesting points on functional wrappings of graphics libraries] > > Has anyone considered writing a haskell wrapper for SDL - Simple > Directmedia Layer at http://www.libsdl.org ? > > This is a cross platform library intended for writing games, and aims > for a high performance, low level API. It would be interesting to see > how clean a functional API could be built around such an imperative > framework. > > Tim > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From davidbak@microsoft.com Tue May 22 21:16:15 2001 From: davidbak@microsoft.com (David Bakin) Date: Tue, 22 May 2001 13:16:15 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D700190C19@red-msg-07.redmond.corp.microsoft.com> Thank you. Now, on seeing your Tree example I tried to use it by defining height using structural recursion. But I couldn't find a valid syntax to pattern match - or otherwise define the function - on the type CT. Is there one? Or, maybe, are constructor classes the only way to use these types? If that's the case - is that inherent in these types or just the way Haskell does it? Because I was thinking that although you don't know much about these types (e.g., the operations you can perform on k) you should be able to compute height (& size) and leaves :: Tree c k e -> [e] and even replMin on the information that's there in the type. -- Dave -----Original Message----- From: Tom Pledger [mailto:Tom.Pledger@peace.com] Sent: Monday, May 21, 2001 7:25 PM To: haskell@haskell.org Subject: Recursive types? David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | =20 | He gives as an example | =20 | =20 | > data Mu f =3D In (f (Mu f)) | =20 | > data NatF s =3D Zero | Succ s | > type Nat =3D Mu NatF | =20 | Among the things I don't get are: | =20 | 1. Comparing this to the non-higher-order type: | =20 | > data NatX =3D Zero | Succ NatX | =20 | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | =20 | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e =3D c k (Tree c k e) -- Contained Tree, container, key, = element data Tree c k e =3D Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t =3D Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From bhalchin@hotmail.com Tue May 22 22:08:56 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Tue, 22 May 2001 21:08:56 Subject: Haskell & .NET CLR Message-ID: Hello, Are any of the various Haskell implm., e.g. ghc, being targeted for the .NET CLR? Also can anybody point in the direction of any projects to implement the .NET CLR on anything other than Win32 platforms, e.g. that evil Free Software Foundation :^)?? Let's make .NET open source! hehehehhee Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ndalton@ics.uci.edu Tue May 22 22:14:29 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 14:14:29 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: Hi, > Are any of the various Haskell implm., e.g. ghc, being > targeted for the .NET CLR? There is a beta haskell compiler, based on ghc-4.08.1 I believe, at http://www.mondrian-script.org/ I haven't used it, so I can't comment further. > Also can anybody point in the > direction of any projects to implement the .NET CLR on anything > other than Win32 platforms I haven't seen any public projects like that. Would be interesting though.. Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From cwitty@newtonlabs.com Wed May 23 01:19:50 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 17:19:50 -0700 Subject: Templates in FPL? In-Reply-To: "D. Tweed"'s message of "Fri, 18 May 2001 11:22:36 +0100 (BST)" References: Message-ID: "D. Tweed" writes: > In my experience the C++ idiom `you only pay for what you use' (==> > templates are essentially type-checked macros) and the fact most compilers > are evolved from C compilers makes working with templates a real pain in > practice. I'm not sure what you mean by type-checked here. Templates are not type-checked at definition time, but are type-checked when they are used; the same is true of ordinary macros. Carl Witty From trd@cs.mu.OZ.AU Wed May 23 01:22:38 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Wed, 23 May 2001 10:22:38 +1000 Subject: Haskell & .NET CLR In-Reply-To: ; from ndalton@ics.uci.edu on Tue, May 22, 2001 at 02:14:29PM -0700 References: Message-ID: <20010523102238.A2949@cs.mu.oz.au> > > Also can anybody point in the > > direction of any projects to implement the .NET CLR on anything > > other than Win32 platforms > I haven't seen any public projects like that. Would be > interesting though.. Well, there is: http://www.southern-storm.com.au/ Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working on a C# compiler. See: http://primates.helixcode.com/~miguel/activity-log.html Finally, there was recently an article in Linux Magazine (??? not Linux Journal) about targetting gcc at the .NET CLR. I'm afraid I have no information more than that, since I don't think I can get the magazine in Australia. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From cwitty@newtonlabs.com Wed May 23 02:25:15 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 18:25:15 -0700 Subject: Templates in FPL? In-Reply-To: Jerzy Karczmarczuk's message of "Fri, 18 May 2001 11:25:14 +0200" References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Jerzy Karczmarczuk writes: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) I agree with Marcin about the bad points of templates. (I'd like to point out, though, that the idea that "adding new code can't change the meaning of a program" no longer holds in Haskell extended with overlapping type classes.) > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? There are some very cool things about C++ templates; they are more powerful than you might suspect. (Note: the following summarizes and paraphrases several papers I've read on the topic; let me know if you want more information and I'll look up references for you.) Basically, templates let you extend the compiler. You get a primitive functional programming language, with which you can do basically arbitrary computations on types and on integers; this language can be used to generate special-purpose code. One way to look at this is as a form of partial evaluation (although there's nothing which automatically decides which computation to do at compile time and which at run time). In the functional programming language, you have conditionals, the usual arithmetic operations, pairing, recursion, etc.; basically, it's a real programming language (although a very annoying one -- the syntax is atrocious). Here are a few examples of the kind of thing you can do with C++ templates: * Compute log base 2 at compile time. You can write a template such that if n is a compile-time constant, Log2::val is its log base 2. * Generate FFT routines. You can write a template such that if n is a compile-time constant which is a power of 2, then FFT::do_fft() is a routine which computes an FFT on an array of size n, as a single chunk of straight-line code (no loops). (Not necessarily useful -- it generates a lot of code for reasonable-sized arrays, and cache effects probably mean that something with loops is more efficient -- but cool nonetheless.) * Implement lambda (over a subset of full C++). You can make lambda(X, a*(X+b)) do "the right thing" (basically by arranging for the expression a*(X+b) to have a type like Times > and then writing a function using recursion over this type). These techniques are useful when you're going for speed and generality; I would certainly imagine that such things could be useful in a functional programming language as well. In fact, over the past few weeks, people on the Haskell mailing lists have been trying to do vaguely similar kinds of compile-time computation at the type level, using type classes and functional dependencies. On the other hand, C++ templates have huge flaws for this kind of thing. As I mentioned, the syntax is atrocious; also, there are lots of things you would like to do which are apparently just out of reach (the template language is not quite powerful enough). I'd like to see somebody make a serious effort to add this kind of compile-time processing to Haskell. It might not look anything like templates; something like OpenC++ and OpenJava might be better. (These are C++ and Java compilers which are extensible; you can write compiler extension modules using a standard API, and the compiler dynamically loads your extensions.) There is a big reason why C++ templates (or any other form of compile-time arbitrary computation on types) would be hard to add to Haskell: type inference and polymorphism. For C++ templates, you need to know the argument types before you can do the template processing, and you cannot know the type of the result until the processing is done. Probably this facility would only be useful for monomorphic parts of your program, which might mean it's not appropriate for Haskell at all. Carl Witty From ndalton@ics.uci.edu Wed May 23 04:09:23 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 20:09:23 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: <20010523102238.A2949@cs.mu.oz.au> Message-ID: On Wed, 23 May 2001, Tyson Dowd wrote: > Well, there is: > http://www.southern-storm.com.au/ Interesting, I wish them well. > Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working > on a C# compiler. Well I see from: http://primates.ximian.com/~miguel/cs-compiler.html that his experiment has finished, and I do not think that there is a complete compiler? From the activity log it looks like he got as far as a syntax checker. > Finally, there was recently an article in Linux Magazine (??? not Linux > Journal) about targetting gcc at the .NET CLR. I'm afraid I have no > information more than that, since I don't think I can get the magazine > in Australia. As far as I know, that article was speculating on whether this would be a good idea or not, not reporting on a port of gcc. Regards, Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From bhalchin@hotmail.com Wed May 23 05:27:44 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Wed, 23 May 2001 04:27:44 Subject: Haskell & .NET CLR Message-ID: Hello Everybody, The second part of my question pertained only to have a working version of the .NET CLR running on non-win32 platforms, e.g. Linux.It won't do any good to only having compilers targeted for .NET CLR if this run-time system and it's libraries only run on win32. Then darth vadar wins.... Bill >From: Tyson Dowd >To: Niall Dalton >CC: Bill Halchin , haskell@haskell.org >Subject: Re: Haskell & .NET CLR >Date: Wed, 23 May 2001 10:22:38 +1000 > > > > Also can anybody point in the > > > direction of any projects to implement the .NET CLR on anything > > > other than Win32 platforms > > I haven't seen any public projects like that. Would be > > interesting though.. > >Well, there is: >http://www.southern-storm.com.au/ > >Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working >on a C# compiler. > >See: >http://primates.helixcode.com/~miguel/activity-log.html > >Finally, there was recently an article in Linux Magazine (??? not Linux >Journal) about targetting gcc at the .NET CLR. I'm afraid I have no >information more than that, since I don't think I can get the magazine >in Australia. > >-- > Tyson Dowd # > # Surreal humour isn't everyone's cup of fur. > trd@cs.mu.oz.au # >http://www.cs.mu.oz.au/~trd # Get your FREE download of MSN Explorer at http://explorer.msn.com From ndalton@ics.uci.edu Wed May 23 05:35:03 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 21:35:03 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: > The second part of my question pertained only to have a working version > of the .NET CLR running on non-win32 platforms, e.g. Linux.It won't do Well you will need compilers as part of that to convert the MSIL into executable code. As I understand it there are several compilers in Microsoft's .NET implementation. A 'pre-jit' that is used as an install time compiler, a typical jit used at runtime and perhaps an optimizing compiler as well. Unfortunately I don't know much about the optimizing compiler plans, nor how things like the ssa stuff in the IL will be safely used. Perhaps we should move this conversation off the haskell list, as we drifted rather far off topic.. niall From simonpj@microsoft.com Wed May 23 08:53:55 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 23 May 2001 00:53:55 -0700 Subject: Haskell & .NET CLR Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond.corp.microsoft.com> | Are any of the various Haskell implm., e.g. ghc, being=20 | targeted for the .NET CLR?=20 Yes, we are, here in Cambridge. We've run some Haskell programs on the CLR already, but it's not nearly ready for release. =20 Simon From Jbkim1078@aol.com Wed May 23 10:59:15 2001 From: Jbkim1078@aol.com (Jbkim1078@aol.com) Date: Wed, 23 May 2001 05:59:15 EDT Subject: Tutor for Haskell is Wanted Message-ID: Hello, I am Yoon, a student of UNSW in Sydney,Australia. I am learning Haskell but need a lot of help for the course. Is there any way that I can get a private tutor? Thanks very much. From sk@mathematik.uni-ulm.de Wed May 23 13:55:16 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 23 May 2001 14:55:16 +0200 Subject: Dependent types (Was: Re: BAL paper available) In-Reply-To: ; from C.T.McBride@durham.ac.uk on Wed, May 16, 2001 at 01:03:25PM +0100 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <20010523125516.21796.qmail@thales.mathematik.uni-ulm.de> C T McBride schrieb folgendes am Wed, May 16, 2001 at 01:03:25PM +0100: > On Wed, 16 May 2001, Stefan Karrmann wrote: > > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > ... you really need types that > > > depend on parameters (in particular, integer parameters). This is, > > > indeed, a problem--currently, you have to do runtime checks. > > > > > > Full-fledged dependent types à la Cayenne are undecidable, but there > > > are weaker variants that are likely to be good enough. > > > > What are the weaker variants? Do you know some references? > > Are they still decidable? That surprises me. If you allow integer > > arithmetic you can do already all computations (Church). > > The idea that `dependent types are undecidable' is a popular but > understandable misconception arising from a particular design decision in > a particular system---Cayenne. > > Dependent types as found in proof systems such as Coq and Lego do have > decidable typechecking: programs may only use structural recursion, and > hence all the evaluation which takes place during typechecking is > guaranteed to terminate. However, in order to support real programming, > Cayenne allows general recursion: as it makes no distinction between the > programs which are executed at compile-time and those only executed at > run-time, undecidability creeps in. Understandably, neither horn of this > dilemma is particularly attractive to programmers who want to combine > flexibility at run-time with a genuinely static notion of typechecking. With constructor type we can do dimension checking, as shown earlier on this list. Can't we check in a similiar way an integer paramter? But is this general enough? You may compute some integer n and then do some calculations in Z/n. How can this be done? Do you need to do the calculation only with structural recursion? > (Of course, post-98 Haskell with certain type class options selected has a > type-level language containing non-terminating programs, making > typechecking undecidable for exactly the same reason as in Cayenne.) If possibly non-terminating type analysis creeps into Haskell, why don't we choose the Cayenne style? > However, there is a middle way: we can distinguish compile-time programs > from run-time programs and restrict the former to the structurally > recursive fragment, leaving general recursion available in the latter. Is there any (syntactical) proposal somewhere? -- Stefan Karrmann From luc.taesch@csfb.com Wed May 23 17:08:49 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Wed, 23 May 2001 18:08:49 +0200 Subject: creating xml doc with haxml Message-ID: <9818339E731AD311AE5C00902715779C0371A7AC@szrh00313.tszrh.csfb.com> i understand now how to filter existing xml doc with haxml. but what about creation from scratch ? if i have myCFel = mkElem "tag" [(literal "value")] myel is a CFilter, not an element so i i want to create a effective element ( to pass to putStrLn . render $ ppContent for instance), i should give it something to filter, like emptyContent = CString False "" to finally do myel = mylit emptyContent . are there any other way to use combinator for creating a structure ( as opposed to "operate on an existing structure")? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From fjh@cs.mu.oz.au Wed May 23 17:35:07 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 24 May 2001 02:35:07 +1000 Subject: Templates in FPL? In-Reply-To: References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <20010524023506.A14295@hg.cs.mu.oz.au> On 22-May-2001, Carl R. Witty wrote: > > I agree with Marcin about the bad points of templates. Me too. Marcin summed it up very well. Of the five disadvantages that he mentioned, I think at least three (lack of explicit interfaces, incredibly complicated rules about name lookup, and very poor error messages) are very serious problems. For an example of the problems caused by the lack of explicit interfaces, the C++ standards committee has still not agreed on what the interface to vector is. The standard is contradictory, because the vector specialization doesn't obey the rules specified for vector, and as yet there's no concensus about which should be changed. For an example of the problems caused by the complicated rules about name lookup, just today someone posted a bug report for gcc 2.95.* to gcc@gcc.gnu.org, reporting a problem where one of the standard library templates didn't work when they had a typedef named `destroy' in their code. My guess is that it was probably because the standard library code was using the function std::destroy(), but the standard library implementor didn't realize that it had to be explicitly namespace qualified; in other words, the rules were too complex and/or too cumbersome for the standard library developer to understand and/or apply. Marcin already posted a good example of a poor error message ;-) > (I'd like to > point out, though, that the idea that "adding new code can't change > the meaning of a program" no longer holds in Haskell extended with > overlapping type classes.) Yes... hence overlapping type classes are EVIL! ;-) ;-) ;-) ;-) > There are some very cool things about C++ templates; they are more > powerful than you might suspect. > > Basically, templates let you extend the compiler. You get a primitive > functional programming language, with which you can do basically > arbitrary computations on types and on integers; > In the functional programming language, you have conditionals, the > usual arithmetic operations, pairing, recursion, etc.; basically, it's > a real programming language (although a very annoying one -- the > syntax is atrocious). Right. It wasn't designed for that purpose, it just turned out that it could be used for it. It's a bit like that simulation of Conway's game of life in vi macros! Makes for a very impressive demo, but there are serious drawbacks to using such techniques in day-to-day work. I agree that it would be very nice if Haskell and other FPLs had some equivalent feature, with a nicer syntax. I think you might be able to do a lot of it using ordinary Haskell syntax with just some additional annotation that directs the compiler to evaluate part of the program at compile time. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From karczma@info.unicaen.fr Wed May 23 17:46:02 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 23 May 2001 18:46:02 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> <20010524023506.A14295@hg.cs.mu.oz.au> Message-ID: <3B0BE94A.76CB56FE@info.unicaen.fr> Fergus Henderson : > I agree that it would be very nice if Haskell and other FPLs had some > equivalent feature, with a nicer syntax. I think you might be able to > do a lot of it using ordinary Haskell syntax with just some additional > annotation that directs the compiler to evaluate part of the program at > compile time. Actually, whole my posting was driven by that. (And by Clean macros which are not macros, but not yet templates, and by the fact that you can parameterize templates with constants, and Haskell classes not). Yours anwers, very thorough, concentrated sometimes on the realization of templates in C++, and I am the last to defend them, or to want to see them implemented in Haskell. But, as a - not too run-time-expensive way to deal with some facets of polymorphism by compiling specialized functions, it is a possible option. The syntactic issues, and the relation of these "macros" to class system is another story. Thanks. Jerzy Karczmarczuk Caen, France From brent.fulgham@xpsystems.com Wed May 23 22:56:19 2001 From: brent.fulgham@xpsystems.com (Brent Fulgham) Date: Wed, 23 May 2001 14:56:19 -0700 Subject: Cygwin Build Bug (Probably Affects other GNU GLIBC Builds) Message-ID: For thread-safety reasons, the GNU C Library (2.2+) defines "errno" as a macro that calls a function to get the errno of the current thread. Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs to include the header file, rather than declaring an extern variable. Diff: ========================================================================== *** cIOExtras.old.c Wed May 23 14:54:58 2001 --- cIOExtras.c Wed May 23 14:26:54 2001 *************** *** 1,10 **** /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! extern int errno; int getErrNo (void) { return errno; } --- 1,11 ---- /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" + #include "errno.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! /*extern int errno;*/ int getErrNo (void) { return errno; } From jcab@roningames.com Thu May 24 03:18:32 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Wed, 23 May 2001 19:18:32 -0700 Subject: Templates in FPL? In-Reply-To: <20010524023506.A14295@hg.cs.mu.oz.au> References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: > > Basically, templates let you extend the compiler. You get a primitive > > functional programming language, with which you can do basically > > arbitrary computations on types and on integers; > > In the functional programming language, you have conditionals, the > > usual arithmetic operations, pairing, recursion, etc.; basically, it's > > a real programming language (although a very annoying one -- the > > syntax is atrocious). > >Right. It wasn't designed for that purpose, it just turned out >that it could be used for it. It's a bit like that simulation of >Conway's game of life in vi macros! Makes for a very impressive >demo, but there are serious drawbacks to using such techniques in >day-to-day work. :) So true. In some ways, it sounds great: here we have a useful general-purpose feature that you can use for all kinds of things (a programming Swiss army knife, so to speak), and then build all kinds of _concrete_ useful things with it. Problem is that it doesn't allow you to redefine the syntax in any way. Thus, you can do compile-time assertions, computations, things like that, but the meaning of what you want to do often gets quite obfuscated by this syntax and by the contrived compiler error messages. I must say, though, that the beta compiler of MSVC 7 does a MUCH improved work on it. >I agree that it would be very nice if Haskell and other FPLs had some >equivalent feature, with a nicer syntax. I think you might be able to >do a lot of it using ordinary Haskell syntax with just some additional >annotation that directs the compiler to evaluate part of the program at >compile time. This is close to my personal vision. That is, a language that handles both run-time and compile-time computations seamlessly. Thus, the compiler would evaluate as much as it can, and then what's left is put in the executable. I assume that's something optimizing compilers for Haskell already do, at least in part. Problem is that, ideally, the language should allow the programmer to be explicit about things that should be done at compile-time and things that should be done at run-time, which Haskell doesn't quite have. Let's see how this could work: - IO actions must be executed at run-time, evidently. - We might be able to define another action monad (let's call it "CT", for compile-time) which defines just the opposite: an action that must be executed by the compiler. - We'd need a new primitive function: executeCompilerAction :: CT a -> a - And we'd need another: compilerEval :: a -> CT a So, let's say we want to force this program: main = print (fact 1000) to evaluate the factorial expression at compile-time. Then, we'd write something like: main = print (executeCompilerAction (compilerEval (fact 1000))) Of course, we'd eventually define any useful recurring patterns as new functions, as in here: eval a = executeCompilerAction (compilerEval a) Anyway, I don't know if I'm making much sense here. Just letting my brains fly on their own. Then, there's the explicit handling of types which templates allow and Haskell doesn't. I think that, the hardest part of Haskell that I'm having trouble with here is the way overloading is defined, using classes. I still have problems with that. Some times it is really obvious that it's best. Some other times, it really doesn't seem to fit (finding about the multi-parameter class extension was a very gratifying moment there). I can think of something that I don't know how to do in Haskell. Suppose that I have two classes, which I'll call Class1 and Class2: class Class1 a where func1 :: a -> Bool class Class2 a where ... (doesn't matter what goes here) And say that I want to express the fact that ALL types that are instances of Class2 will ALWAYS be instances of Class1, and will always return "False" from "func1". So, is there any way to express this kind of class-relationship in Haskell? It's not definitely inheritance, I think. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From simonmar@microsoft.com Thu May 24 10:02:43 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 24 May 2001 10:02:43 +0100 Subject: I/O buffering (was: Endangered I/O operations) Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115893@TVP-MSG-01.europe.corp.microsoft.com> [ moved from glasgow-haskell-users to haskell@haskell.org ] Carl Witty writes: > If the report does not allow the implementation to flush buffers at > any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be "returned to the file" (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that "Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer". What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon > I would much rather > use an implementation where stdout and stderr came out in the right > order, and reading from stdin flushed stdout. (As another example, an > implementation might want to flush all buffers before doing a fork(), > to avoid duplicated output.) >=20 > The only caveat is that if such flushing is allowed but not required, > it might encourage writing sloppy, nonportable code. >=20 >=20 >=20 From Dominic.J.Steinitz@BritishAirways.com Thu May 24 10:45:54 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 09:45:54 Z Subject: Building Programs Message-ID: <"04B7D3B0CD852002*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> What's the recommended way of building a system consisting of many Haskell modules? Should I use hmake, make or is there some other preferred mechanism in the Haskell world? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonpj@microsoft.com Thu May 24 11:06:41 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 24 May 2001 03:06:41 -0700 Subject: Building Programs Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> It depends on which implementation you have.=20 hmake is good, and is independent of implementation. ghc 5.0 has a make system built in, so you can say ghc --make Main to build your program. Or=20 ghc --interactive Main to run it interactively. Hugs also follows module dependencies automatically. hbc had a similar mechanism I think. =20 Simon | -----Original Message----- | From: Steinitz, Dominic J=20 | [mailto:Dominic.J.Steinitz@BritishAirways.com]=20 | Sent: 24 May 2001 10:46 | To: haskell | Subject: Building Programs |=20 |=20 | What's the recommended way of building a system consisting of=20 | many Haskell modules? Should I use hmake, make or is there=20 | some other preferred mechanism in the Haskell world? |=20 | Dominic. |=20 | -------------------------------------------------------------- | ----------------------------------- | 21st century air travel http://www.britishairways.com |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From v-julsew@microsoft.com Thu May 24 13:57:06 2001 From: v-julsew@microsoft.com (Julian Seward (Intl Vendor)) Date: Thu, 24 May 2001 05:57:06 -0700 Subject: ghc-5.00.1 is available Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.00.1. The source distribution is freely available via the World-Wide Web and through anon. FTP, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, and Solaris(sparc) are also available. Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.00.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is a bug-fix release. Most reported bugs in 5.00 have been fixed, including a substantial number of show-stopping bugs. The system should be much more usable for more people. Upgrading to 5.00.1 is recommended. To all those who tried out 5.00 and reported bugs, we thank you for your feedback and patience. At the moment there is no Win32 build of 5.00 or 5.00.1 available. We decided to push Win32 support to the 5.02 release, so as not to delay 5.00.1 any further. What's new in 5.00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.00 has been majorly revamped since the previous stable version, 4.08.2. This should be a stable release. Major changes since 4.08.2 are: - An interactive system, similar in style to Hugs. You can interactively load and unload modules, run expressions, ask the types of things. Module dependencies are tracked and chased automatically. Combinations of compiled and interpreted modules may be used. All the GHC libraries are available in interactive mode, as are most of the Glasgow extensions to Haskell 98. Compilation in interactive mode (to bytecode) is about three times faster than compiling to object code. - Batch compilation of multiple modules at once, with automatic dependency chasing. For large programs this can halve compilation times, and removes the need for Makefiles. - Enhanced package (library) management system. Packages may be installed and removed from an installation using the ghc-pkg tool. - Initial Unicode support - the Char type is now 31 bits. - Sparc native code generator, giving much faster compilation on sparcs. (Native code generation for x86s has been available for a while). - Improved heap profiling - you can restrict heap profiles by type, closure description, cost centre, and module. - Support for the latest Foreign Function Interface (FFI) proposals. Marcin Kowalczyk's hsc2hs tool is included. - Language extensions: parallel list comprehensions and functional dependencies. - The usual huge collection of bug fixes. Most reported bugs have been fixed. For full details see the release notes: http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html How to get it =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in .rpm/.deb form for all you Linux junkies out there, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To compile programs with GHC, you need a machine with 32+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * alpha-dec-osf{2,3} * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/5.00/building/building-guide.html Mailing lists =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org; GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding edge CVS users party on cvs-ghc@haskell.org. From Malcolm.Wallace@cs.york.ac.uk Thu May 24 15:34:08 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Thu, 24 May 2001 15:34:08 +0100 Subject: Building Programs In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> Message-ID: > What's the recommended way of building a system consisting of > many Haskell modules? Should I use hmake, make or is there > some other preferred mechanism in the Haskell world? As Simon PJ already mentioned, hmake is entirely platform independent, so if there is any likelihood that you may need to change between Haskell compilers, or to distribute your software in a portable source form, it is probably the top option. But for quick hacking, or non-portable software using language extensions, individual compiler mechanisms such as Hugs' import chasing, ghc --make, and hbcmake, are just as good. Writing Makefiles is the least attractive option, even though they have good portability, because they are clunky and it is tricky to keep them synchronised with the true source dependencies. However, I think even when using hmake or ghc --make, you are likely to end up writing a small and simple Makefile anyway. Regards, Malcolm From Dominic.J.Steinitz@BritishAirways.com Thu May 24 18:47:42 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 17:47:42 Z Subject: ghc-5.00.1 is available Message-ID: <"04CAB3B0D493E00E*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From avv@quasar.ipa.nw.ru Thu May 24 19:11:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 11:11:41 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <3B0D4EDD.968E297C@quasar.ipa.nw.ru> Hi All, Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander From ashley@semantic.org Thu May 24 22:41:21 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 24 May 2001 14:41:21 -0700 Subject: Unicode Message-ID: <200105242141.OAA15819@mail4.halcyon.com> At 2001-05-24 05:57, Julian Seward (Intl Vendor) wrote: > - Initial Unicode support - the Char type is now 31 bits. It might be appropriate to have two types for Unicode, a UCS2 type (16 bits) and a UCS4 type (31 bits). For instance, something like: -- newtype UCS2CodePoint = MkUCS2CodePoint Word16 newtype UCS4CodePoint = MkUCS4CodePoint Word31 type Char = UCS4CodePoint toUCS4 :: UCS2CodePoint -> UCS4CodePoint fromUCS4 :: UCS4CodePoint -> Maybe UCS2CodePoint encodeUTF16 :: [UCS4CodePoint] -> Maybe [UCS2CodePoint] decodeUTF16 :: [UCS2CodePoint] -> Maybe [UCS4CodePoint] -- -- Ashley Yakeley, Seattle WA From Dominic.J.Steinitz@BritishAirways.com Thu May 24 22:48:11 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 21:48:11 Z Subject: ghc-5.00.1 is available Message-ID: <"046603B0D819B004*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From qrczak@knm.org.pl Thu May 24 23:04:22 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 24 May 2001 22:04:22 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: >> - Initial Unicode support - the Char type is now 31 bits. > > It might be appropriate to have two types for Unicode, a UCS2 type > (16 bits) and a UCS4 type (31 bits). Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char is '\x10FFFF' now. Among encodings of Unicode in a stream of bytes there are UTF-8, UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and UCS4 are obsolete: there is a single code space 0..0x10FFFF and various ways to serialize characters. Ghc is going to support conversion between internal Unicode and some encodings for external byte streams. Among them there will be UTF-{8,16,32} (with endianness variants), all treated as streams of bytes. There is no point in storing characters in UTF-16 internally. Especially in ghc where characters are boxed objects, and Word16 is represented as a full machine word (32 or 64 bits). UTF-16 will be supported as an external encoding, parallel to ISO-8859-x etc. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From miketh@brisbane.paradigmgeo.com Fri May 25 03:36:19 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 12:36:19 +1000 Subject: a cygwin binary package of ghc-5.00.x References: Message-ID: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Hi. > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > Thank you in advance > > > > Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas. From avv@quasar.ipa.nw.ru Fri May 25 04:10:15 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 20:10:15 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Message-ID: <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Hi Mike, Thank you very much for the reply. After having asked I managed to build ghc-5.00.1, and almost succeeded in the rest, till the place where it failed to invoke ghc-asm (or so, I don't remember, it's on a different machine). It's not impossible that I understand how to fix it (it was just before I went home). I use normal latest cygwin installation, binary installation of ghc-4.08, and tell i686-pc-mingw32 to the configure of ghc. Looks like it's impossible to build it for the full cygwin (but does anybody care?) and also I failed to --enable-win32-dlls (that is _it_ failed, not me :-); it stopped at something like Main.dll_o. During the build I was really scared looking at the resident sizes of the compiler process, which is an ordinary haskell application, with its most adequate application domain. Does it mean that my _real_ programs would expose the same? Alexander Mike Thomas wrote: > > Hi. > > > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > > > Thank you in advance > > > > > > Alexander > > I have one, which uses the Mingw standalone GCC compiler for Windows. It > seems to be capable of compiling itself. > > Problems: > > 1. It is not in an installer - you would have to hand patch the package file > and install by hand. > > 2. It is not supported by anyone and is non-standard in the way it uses > Mingw32. > > 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 > though). > > 4. I haven't bootstrapped GHCi, yet (maybe by next week). > > 5. It is only GHC 5.00, not 5.00.1. (maybe next week). > > 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) > yourself. > > 7. It is very big, mainly because of the profiled libraries. > > 8. I don't have an FTP site to put it. > > 9. It doesn't do dynamic libraries, only static. > > etc. > > Unless you're desperate, I suggest waiting for the official release. > > Cheers > > Mike Thomas. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From miketh@brisbane.paradigmgeo.com Fri May 25 07:09:13 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 16:09:13 +1000 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Message-ID: <005801c0e4e1$3c061520$0cb4a8c0@brisbane.paradigmgeo.com> Hi there. > I use normal latest cygwin installation, > binary installation of ghc-4.08, and tell i686-pc-mingw32 to the > configure of ghc. Same here, except I used the standalone Mingw, which meant that I had to alter certain parts of the makefile which relied on Cygwin links (in the gmp library), and alter the parameters sent to GCC. > Looks like it's impossible to build it for the full > cygwin (but does anybody care?) I certainly don't ! > and also I failed to --enable-win32-dlls > (that is _it_ failed, not me :-); it stopped at something like > Main.dll_o. I haven't tried that option yet, as there is apparently a bug in Mingw for large heaps when linked dynamically. > During the build I was really scared looking at the resident sizes of > the compiler process, which is an ordinary haskell application, with its > most adequate application domain. Does it mean that my _real_ programs > would expose the same? Yeah, it's pretty big, but I guess that not all programs use as much memory as a compiler. Good luck. Mike Thomas. From simonpj@microsoft.com Fri May 25 08:01:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 25 May 2001 00:01:22 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 working here, but we are trying to get the packaging right so that it doesn't require Cygwin etc.=20 If you want to build it from source, you might want to wait for Reuben to put up the 4.08 download he's about to distribute. I have myself used this download to compile the head from source yesterday, so I know it works! Simon | -----Original Message----- | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 | Sent: 24 May 2001 19:12 | To: haskell@haskell.org | Subject: a cygwin binary package of ghc-5.00.x |=20 |=20 | Hi All, |=20 | Do anybody have one? I failed to recompile it with ghc 4.08.x. |=20 | Thank you in advance |=20 | Alexander |=20 |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From Dominic.J.Steinitz@BritishAirways.com Fri May 25 11:35:06 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 10:35:06 Z Subject: IO Errors Message-ID: <"03C413B0E355A011*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can anyone tell me why this behaves as it does? In Hugs, I get C:\My Documents\functional\ldapsck1\buffer.hs Main> main Illegal operation (561 reductions, 1029 cells) Main> If the input file is the one line: 1234567812345678 the output file is: Starting logging 1234567812345678 Error In ghc, the program hangs without even creating a file. Dominic import IO main :: IO () main = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" ifh <- openFile "tst.txt" ReadMode let loop = do b <- try (getBuffer ifh 16) case b of Right msg -> do logMessage ofh msg loop Left e -> if isEOFError e then do logMessage ofh "Finishing logging" hClose ofh else do logMessage ofh "Error" ioError e in loop logMessage :: Handle -> String -> IO () logMessage hd msg = do hPutStrLn hd msg hFlush hd getBuffer :: Handle -> Int -> IO String getBuffer h n = if (n <= 0) then return "" else do c <- hGetChar h cs <- getBuffer h (n-1) return (c:cs) ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From ltaesch@europemail.com Fri May 25 14:34:22 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 13:34:22 +0000 Subject: combinators Message-ID: <3B0E5F5E.4541CF5@europemail.com> beyond specific combinator tutorial, are there any generic combinator paper, or introductory ones ? thks Luc From joe@isun.informatik.uni-leipzig.de Fri May 25 12:56:39 2001 From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann) Date: Fri, 25 May 2001 13:56:39 +0200 (MET DST) Subject: combinators In-Reply-To: <3B0E5F5E.4541CF5@europemail.com> from luc at "May 25, 2001 01:34:22 pm" Message-ID: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> > beyond specific combinator tutorial, are there any generic combinator > paper, or introductory ones ? what exactly do you mean by "combinator". there's the recent area of parser combinators and such, but there's also Combinatory Logic in itself, which is a formal system closely related to the lambda calculus. a nice introduction is here: http://uq.net.au/~zzdkeena/Lambda/index.htm which is based on the "ornithology" from here: Smullyan, R.M. (1985) To mock a mockingbird. Alfred A. Knopf, New York. of course, the definitive references on Comb. L. and Lambda Calc. are the books by Curry, Feys, Hindley, Seldin, Barendregt (check your library). beware that the classical theory (as expressed in these books) is mostly un-typed (you can apply anything to anything). enjoy, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 -- From simonmar@microsoft.com Fri May 25 12:49:16 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Fri, 25 May 2001 12:49:16 +0100 Subject: IO Errors Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD709@TVP-MSG-01.europe.corp.microsoft.com> > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon From action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee Fri May 25 12:47:30 2001 From: action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee (Marjan Mernik) Date: Fri, 25 May 2001 13:47:30 +0200 Subject: CFP: LDTA'2002 Message-ID: <3B0E4652.3F402DE1@uni-mb.si> [apologies if you receive multiple copies of this message] ----------------------------------------------------------- 2nd Workshop on Language Descriptions, Tools and Applications LDTA'2002 Affiliated with ETAPS'2002 April 13, 2002 Grenoble, France The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications of these language definitions and tools developed for or with these language definitions. For call for papers and additional information please check the following URL: http://www.cwi.nl/conferences/LDTA2002 Schedule Submission of full paper December 15, 2001 Notification January 31, 2002 Final version due February 28, 2002 From ltaesch@europemail.com Fri May 25 15:17:14 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 14:17:14 +0000 Subject: combinators References: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> Message-ID: <3B0E696A.7BCF46A0@europemail.com> Johannes Waldmann wrote: > > beyond specific combinator tutorial, are there any generic combinator > > paper, or introductory ones ? > > what exactly do you mean by "combinator". > there's the recent area of parser combinators and such, well, i didnt knew it was new, but , yes, that's it. ive read some paper on parser combinator, and as im working with haxml, id like to have some of my stuuf done in the same style, then i realize i had a tendency to design function that reacted on data (itself), rather than combinators. (probably too mucj of "old stuff in my head ;-) so i would like to backstep , and look at combinator as such , and not applied in a given context (liker parser or haxml)) which example i can understand, but not easily change my style of programming accordingly. so, reformulation : has anyone know a paper like : "change ure mindset from data oriented programming to combinators one " ? > > > but there's also Combinatory Logic in itself, > which is a formal system closely related to the lambda calculus. is this then relevnt for me to look t that, in the light of my previous explanation ? From ketil@ii.uib.no Fri May 25 15:34:41 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 25 May 2001 16:34:41 +0200 Subject: Templates in FPL? In-Reply-To: Juan Carlos Arevalo Baeza's message of "Wed, 23 May 2001 19:18:32 -0700" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Juan Carlos Arevalo Baeza writes: > At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: >> I agree that it would be very nice if Haskell and other FPLs had some >> equivalent feature, with a nicer syntax. I think you might be able to >> do a lot of it using ordinary Haskell syntax with just some additional >> annotation that directs the compiler to evaluate part of the program at >> compile time. > This is close to my personal vision. That is, a language that handles both > run-time and compile-time computations seamlessly. Thus, the compiler would > evaluate as much as it can, and then what's left is put in the > executable. I must be missing something crucial here - I thought that was exactly what GHC did? I've certainly had it optimize toy benchmarks completely away... Could somebody elucidate, please? Of course, having annotations to hint about specialization might be a good thing. Perhaps this could be profiled and fed back to the compiler? ISTR this is common for the SPEC benchmarks (in C or Fortran, I presume) > Problem is that, ideally, the language should allow the programmer to > be explicit about things that should be done at compile-time and things that > should be done at run-time, which Haskell doesn't quite have. Why/when do you need this? I would go for -O implying optimizing away as much as possible (i.e all constant expressions), and else no optimization (for compilation speed). -kzm -- If I haven't seen further, it is by standing in the footprints of giants From Dominic.J.Steinitz@BritishAirways.com Fri May 25 17:09:05 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 16:09:05 Z Subject: IO Errors Message-ID: <"019E13B0E83A103F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Simon, I (stupidly) called the executable logger and then presumably invoked something on linux of the same name. Giving it a different name gave the same result as you got. I assume this is a bug in hugs and I will refer it to that mailing list. Dominic. simonmar@microsoft.com on 25/05/2001 13:03:00 To: Dominic Steinitz haskell cc: bcc: Subject: RE: IO Errors > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From fjh@cs.mu.oz.au Fri May 25 18:17:40 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 26 May 2001 03:17:40 +1000 Subject: Unicode In-Reply-To: References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: <20010526031740.A27447@hg.cs.mu.oz.au> On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > (16 bits) and a UCS4 type (31 bits). > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > is '\x10FFFF' now. > > Among encodings of Unicode in a stream of bytes there are UTF-8, > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > various ways to serialize characters. > > Ghc is going to support conversion between internal Unicode and > some encodings for external byte streams. Among them there will be > UTF-{8,16,32} (with endianness variants), all treated as streams > of bytes. > > There is no point in storing characters in UTF-16 internally. > Especially in ghc where characters are boxed objects, and Word16 is > represented as a full machine word (32 or 64 bits). UTF-16 will be > supported as an external encoding, parallel to ISO-8859-x etc. What about for interfacing with Win32, MacOS X, or Java? Your talk about "external" versus "internal" worries me a bit, since the distinction between these is not always clear. Is there a way to convert a Haskell String into a UTF-16 encoded byte stream without writing to a file and then reading the file back in? -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jcab@roningames.com Fri May 25 18:45:59 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Fri, 25 May 2001 10:45:59 -0700 Subject: Templates in FPL? In-Reply-To: References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: <4.3.2.7.2.20010525104210.02f0cfd8@207.33.235.243> At 04:34 PM 5/25/2001 +0200, Ketil Malde wrote: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > >I must be missing something crucial here - I thought that was exactly >what GHC did? I don't presume to know what GHC does. After all, Haskell was completely unknown to me three months ago. O:-) I did hope that was the case, though: "I assume that's something optimizing compilers for Haskell already do, at least in part". > > Problem is that, ideally, the language should allow the programmer to > > be explicit about things that should be done at compile-time and things > that > > should be done at run-time, which Haskell doesn't quite have. > >Why/when do you need this? I would go for -O implying optimizing away >as much as possible (i.e all constant expressions), and else no >optimization (for compilation speed). Oh, there are several reasons for the programmer to make her wishes clear to the compiler. Especially when having something NOT calculated at compile time is not acceptable. In that case, you want the compiler to return an error, instead of emitting the runtime calculations. A silly example of this that comes to mind is non-converging calculations. Say we have a wrong factorial function: tcaf 0 = 1 tcaf n = n * tcaf (n+1) Pass this program through GHC: main = print (tcaf 3) Will it evaluate "tcaf 3" at compile-time? Will it error-out at compile-time? I don't have the compiler here (I'm writing from work, but I'm trying Haskell out at home). My guess would be that GHC will evaluate as much as it can, and leave the rest for the run-time program. Specifically, the best I'd expect it to do is to lessen the recursion by expanding several levels of it. For example, for two levels, it'd be reduced to: tcaf = (\n -> case n of 0 = 1; -1 = -1; _ = n * (n+1) * tcaf (n+2)) Of course, I might be completely wrong here. I don't think it'd be terribly hard for the compiler to deduce that a function like this, called with a positive argument, is never going to finish evaluating. But in more complex cases, it might not be possible for the compiler to know. Then again, GHC might actually be evaluating EVERYTHING that doesn't depend on IO actions... without exception... This brings me to a question. What would a good optimizing compiler (GHC) do in this case: main = do num <- return 3 print (tcaf num) I'll be trying all these things tonight. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From avv@quasar.ipa.nw.ru Fri May 25 19:14:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Fri, 25 May 2001 11:14:41 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B0EA111.A4A2821@quasar.ipa.nw.ru> Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >= 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one > working here, but we are trying to get the packaging right > so that it doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for > Reuben to put up the 4.08 download he's about to distribute. > I have myself used this download to compile the head from > source yesterday, so I know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From taha@cs.yale.edu Fri May 25 19:29:44 2001 From: taha@cs.yale.edu (Walid Taha) Date: Fri, 25 May 2001 14:29:44 -0400 (EDT) Subject: NEPLS In-Reply-To: <200105251821.OAA16140@bosch.cs.brown.edu> Message-ID: Dear all, If you want to be added to the NEPLS page, please send ME your email and I'll forward it to Shriram. Cheers, Walid. On Fri, 25 May 2001, Shriram Krishnamurthi wrote: |Hi Walid, | |You were never on the mailing list (for reasons that escape me). You |are now. | |Do me a favor. Send mail around to the programming languages people |at Yale asking whether they'd like to be on the list. Find someone to |collect all these names and send them to me in a single message, |line-at-a-time (usual mail alias file format). I'll take care of |including y'all. If the name's not obvious from the email address, |please also include the full name in the usual mail format: | | "Walid Taha" | |Btw, the only cs.yale.edu addresses currently on the list are | | Walid Taha | hudak@cs.yale.edu | shao-zhong@cs.yale.edu | carsten@cs.yale.edu | |League and Courtney are on through other hostnames. Maybe I'm missing |a few others. | |Thanks. | |Shriram | From Roger McKenssy" We are looking for new faces for TV & Movie productions. All ages and looks. All countries. If you are interested, Please email or fax us your: ---------------------------------------------- -Name: -Age: -Country: -City: -email address: ---------------------------------------------- If your email reply gives you a delivery error, please use Fax nr 1-309-276-9964 to ensure that we get your message. Please reply only if TV, movie or modeling is of an interest to you. We hope you understand that we are trying to get ONLY serious people who really want to try and like the camera. Feel free to pass this email to a friend or a family member who maybe interested. There is absolutely no payment of any form required from your side. On the oposite, all jobs we offers are well paid. You'll be contacted for an online interview as soon as we can. Best Regards, Roger McKenssy Fax nr 1-309-276-9964 ------------------------------- This email is sent to you in full compliance with all existing and proposed email legislation. Note: You are not on a mailing list, and this is a one-time email. If we don't get an answer, you'll never hear from us any more. You are removed by default. You can still reply with the word Remove in the subject. This right is yours by law. Use Fax nr 1-309-276-9964 From cwitty@newtonlabs.com Fri May 25 19:33:37 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 25 May 2001 11:33:37 -0700 Subject: Templates in FPL? In-Reply-To: Ketil Malde's message of "25 May 2001 16:34:41 +0200" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Ketil Malde writes: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > > I must be missing something crucial here - I thought that was exactly > what GHC did? I've certainly had it optimize toy benchmarks > completely away... Could somebody elucidate, please? I don't know what GHC does, but there are certainly reasons why you might not want to evaluate everything possible at compile time. For instance, there may be some sort of lookup table which is very large, but is fast to compute at runtime; you might not want to store the large table on disk in your executable. Carl Witty From john@repetae.net Fri May 25 21:12:49 2001 From: john@repetae.net (John Meacham) Date: Fri, 25 May 2001 13:12:49 -0700 Subject: Unicode In-Reply-To: <20010526031740.A27447@hg.cs.mu.oz.au>; from fjh@cs.mu.oz.au on Sat, May 26, 2001 at 03:17:40AM +1000 References: <200105242141.OAA15819@mail4.halcyon.com> <20010526031740.A27447@hg.cs.mu.oz.au> Message-ID: <20010525131249.C18660@mark.ugcs.caltech.edu> The algorithms for encoding unicode characters into the various transport formats, UTF16,UTF8,UTF32 are well defined, they can trivially be implemented in Haskell, for instance encodeUTF8 :: String -> [Byte] decodeUTF8 :: [Byte] -> Maybe String would be easily definable. BTW, since a char is no longer a byte, how about making a standard type Byte = Word8 declaration in a readily accesable and standard place. then we can start revamping the large amounts of legacy code which assume a Char is 8 bits. in particular the POSIX APIs are no good in this respect, as well as many of the example programs out there on the web... John On Sat, May 26, 2001 at 03:17:40AM +1000, Fergus Henderson wrote: > On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > > (16 bits) and a UCS4 type (31 bits). > > > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > > is '\x10FFFF' now. > > > > Among encodings of Unicode in a stream of bytes there are UTF-8, > > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > > various ways to serialize characters. > > > > Ghc is going to support conversion between internal Unicode and > > some encodings for external byte streams. Among them there will be > > UTF-{8,16,32} (with endianness variants), all treated as streams > > of bytes. > > > > There is no point in storing characters in UTF-16 internally. > > Especially in ghc where characters are boxed objects, and Word16 is > > represented as a full machine word (32 or 64 bits). UTF-16 will be > > supported as an external encoding, parallel to ISO-8859-x etc. > > What about for interfacing with Win32, MacOS X, or Java? > Your talk about "external" versus "internal" worries me a bit, > since the distinction between these is not always clear. > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? > > -- > Fergus Henderson | "I have always known that the pursuit > | of excellence is a lethal habit" > WWW: | -- the last words of T. S. Garp. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 25 21:07:25 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 25 May 2001 20:07:25 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> <9emde2$kcv$1@qrnik.zagroda> Message-ID: Sat, 26 May 2001 03:17:40 +1000, Fergus Henderson pisze: > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? Sure: all conversions are available as memory to memory conversions for direct use. My conversion type is parametrized by input and output character types, so you can even define UTF-16 as giving [Word16]. But [Word8] must be used for handles, so I think that in practice conversions are generally between [Char] and [Word8]. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From konsu@microsoft.com Fri May 25 23:47:00 2001 From: konsu@microsoft.com (Konst Sushenko) Date: Fri, 25 May 2001 15:47:00 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <0FA38CF91938AC4F8FDC4960E389D76315D2FF@red-msg-10.redmond.corp.microsoft.com> Alexander, It looks like I had a similar problem with ghc script not being recognised by cygwin, and I assume that ghc-asm is also a perl script. I ended up invoking perl explicitly thus perl -S ghc ... I guess if you do the same with ghc-asm, it will work. Hope this helps Konst -----Original Message----- From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 Sent: Friday, May 25, 2001 11:15 AM To: Simon Peyton-Jones Cc: haskell@haskell.org Subject: Re: a cygwin binary package of ghc-5.00.x Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >=3D 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 > working here, but we are trying to get the packaging right so that it=20 > doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for Reuben > to put up the 4.08 download he's about to distribute. I have myself=20 > used this download to compile the head from source yesterday, so I=20 > know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From leelati@yahoo.com Sat May 26 07:52:31 2001 From: leelati@yahoo.com (Rab Lee) Date: Fri, 25 May 2001 23:52:31 -0700 (PDT) Subject: can anyone help? Message-ID: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Dear Experts, I would appreciate any help that anyone can give me. I'm having a bit of trouble with Haskell, my question is pretty simple and i was wonder if anyone could please tell me how to change a string into a list??? Thank you in advance Leat __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From dscarlett@optushome.com.au Sat May 26 08:05:17 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Sat, 26 May 2001 17:05:17 +1000 Subject: can anyone help? References: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Message-ID: <000701c0e5b2$38140770$0100a8c0@CO3003288A> ----- Original Message ----- From: "Rab Lee" To: Sent: Saturday, May 26, 2001 4:52 PM Subject: can anyone help? > Dear Experts, > I would appreciate any help that anyone can give me. > I'm having a bit of trouble with Haskell, my question > is pretty simple and i was wonder if anyone could > please tell me how to change a string into a list??? > Thank you in advance > Leat > A String is a type of list already........ It is a list of Chars. Could you be a bit more specific as to what you want to do? Do you mean (for example), change a String of digits into a list of Ints? ie. "12345" -> [1,2,3,4,5] From leelati@yahoo.com Sat May 26 08:47:21 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:21 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074721.75623.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From leelati@yahoo.com Sat May 26 08:47:56 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:56 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074756.75644.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From N.Perry@massey.ac.nz Sat May 26 11:33:07 2001 From: N.Perry@massey.ac.nz (Nigel Perry) Date: Sat, 26 May 2001 22:33:07 +1200 Subject: Haskell & .NET CLR In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> Message-ID: At 12:53 am -0700 23/5/01 you wrote: >| Are any of the various Haskell implm., e.g. ghc, being >| targeted for the .NET CLR? You can get a beta version of ghc for .NET from www.mondrian-script.org. A lot, but far from all, or the standard libraries are provided. There is no floating point support (use the Mondrian compiler ;-)). This version of ghc will be superceded by another from a different source... Cheers, Nigel -- Nigel Perry, New Zealand From chak@cse.unsw.edu.au Sat May 26 13:53:43 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sat, 26 May 2001 22:53:43 +1000 Subject: ghc-5.00.1 is available In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> Message-ID: <20010526225343M.chak@cse.unsw.edu.au> "Julian Seward (Intl Vendor)" wrote, > The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 > ============================================================== > > We are pleased to announce a new patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.00.1. There are rpm packages for x86 GNU/Linux now. For glibc 2.2 systems, build on RedHat 7.0, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.1-1.i386.rpm For RedHat 6.2, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.1-1.i386.rpm The matching source rpm is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.1-1.src.rpm The RedHat 6.2 packages have been kindly contributed by Tom Moertel. Cheers, Manuel PS: The problems with the documentation in the 5.00 rpms have been resolved (at least in the RH7.0 packages, I didn't check the others). From ashley@semantic.org Sun May 27 22:18:13 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sun, 27 May 2001 14:18:13 -0700 Subject: (no subject) Message-ID: <200105272118.OAA09091@mail4.halcyon.com> At 2001-05-26 00:47, Rab Lee wrote: >hi, i'm having a bit more touble, can anyone help me >or give me any hints on how to do this : >"x 2 3 4" = ("x", [2, 3, 4]) Generally we don't solve homework for people. Unless they're studying under Prof. Karczmarczuk, of course. -- Ashley Yakeley, Seattle WA From karczma@info.unicaen.fr Mon May 28 09:21:25 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Mon, 28 May 2001 10:21:25 +0200 Subject: Homeworks and art of flying. References: <200105272118.OAA09091@mail4.halcyon.com> Message-ID: <3B120A85.1CCD25F0@info.unicaen.fr> Ashley Yakeley answers the query of Rab Lee: > > >hi, i'm having a bit more touble, can anyone help me > >or give me any hints on how to do this : > >"x 2 3 4" = ("x", [2, 3, 4]) > > Generally we don't solve homework for people. Unless they're studying > under Prof. Karczmarczuk, of course. > > -- > Ashley Yakeley, Seattle WA Now, now, this is cruel and ati-pedagogical. I changed my mind, we should all be friends, and help each other. Here is the ideal solution, very fast, and protected against viral contamination homework "x 2 3 4" = ("x", [2, 3, 4]) homework _ = error "You can't" Note the cleverness and universalness of the solution. Jerzy Karczmarczuk Caen, France PS. A deep philosophical quotation seems appropriate here. Here is one from Douglas Adams: Flying is an art, or rather a knack. The knack consists in throwing oneself to ground, and miss. From simonpj@microsoft.com Mon May 28 09:31:56 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 28 May 2001 01:31:56 -0700 Subject: (no subject) Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FAD@red-msg-09.redmond.corp.microsoft.com> This looks like a good thread to move to haskell-cafe@haskell.org http://haskell.org/mailinglist.html Simon | -----Original Message----- | From: Rab Lee [mailto:leelati@yahoo.com]=20 | Sent: 26 May 2001 08:48 | To: haskell@haskell.org | Subject: (no subject) |=20 |=20 | hi, i'm having a bit more touble, can anyone help me | or give me any hints on how to do this : | "x 2 3 4" =3D ("x", [2, 3, 4]) |=20 | __________________________________________________ | Do You Yahoo!? | Yahoo! Auctions - buy the things you want at great prices=20 http://auctions.yahoo.com/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From Dominic.J.Steinitz@BritishAirways.com Mon May 28 14:05:48 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 28 May 2001 13:05:48 Z Subject: Building Programs Again Message-ID: <"035493B124D2C001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> I am going to install hmake and upgrade to ghc 5 but in the meantime I decided to use make. I am puzzled however. Presumably building a module that imports a module needs the .hi file and therefore the makefile should be something like this: Tagsv1.o : Tagsv1.hs ghc -c Tagsv1.hs -package lang Basev1.o : Tagsv1.hi Basev1.hs ghc -c Basev1.hs -package lang But if I do this then make complains if I want to see what it will generate [dom@lhrtba8fd85 maketest]$ make -n ghc -c Tagsv1.hs -package lang make: *** No rule to make target `Tagsv1.hi', needed by `Basev1.o'. Stop. Running make works as by the time the rule gets executed the .hi file exists. Can anyone suggest something better? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonmar@microsoft.com Mon May 28 14:46:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Mon, 28 May 2001 14:46:56 +0100 Subject: Building Programs Again Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD713@TVP-MSG-01.europe.corp.microsoft.com> > I am going to install hmake and upgrade to ghc 5 but in the=20 > meantime I decided to use make. >=20 > I am puzzled however. Presumably building a module that=20 > imports a module needs the .hi file and therefore the=20 > makefile should be something like this: >=20 > Tagsv1.o : Tagsv1.hs > ghc -c Tagsv1.hs -package lang >=20 > Basev1.o : Tagsv1.hi Basev1.hs > ghc -c Basev1.hs -package lang >=20 > But if I do this then make complains if I want to see what it=20 > will generate >=20 > [dom@lhrtba8fd85 maketest]$ make -n > ghc -c Tagsv1.hs -package lang > make: *** No rule to make target `Tagsv1.hi', needed by=20 > `Basev1.o'. Stop. =20 >=20 > Running make works as by the time the rule gets executed the=20 > .hi file exists. >=20 > Can anyone suggest something better? GHC's documentation has some useful tips on using make with Haskell: =09 http://www.haskell.org/ghc/docs/latest/set/separate-compilation.html#USI NG-MAKE Chees, Simon From franka@cs.uu.nl Mon May 28 15:49:31 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Mon, 28 May 2001 16:49:31 +0200 Subject: The next step In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 10:17:03AM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010528164931.B4803@cs.uu.nl> Simon Marlow wrote (on 28-05-01 10:17 +0100): > It's not propaganda. The fact is if any of the standard libraries use > the LGPL, then some people will be prevented from using them. That's > the last thing we want, right? Now you might argue from a moral > standpoint that the companies that these people work for are basing > their business models on intellectual property and therefore deserve > everything they get, but we're not trying to do open source advocacy > here, we're just trying to put together a set of libraries that everyone > can use. Some people don't see it that way. They would say that the GPL is the _less_ restrictive license because it ensures that everybody benefits (equally) from everybody else's improvements. From that perspective, companies benefit also since they may use and improve the code, provided they "publish" it. Will they lose some potential revenue that way? Possibly. But as you suggested, the idea is to make the audience as _wide_ as possible, not as _rich_ as possible. ;) -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From davidbak@cablespeed.com Mon May 28 21:25:22 2001 From: davidbak@cablespeed.com (David Bakin) Date: Mon, 28 May 2001 13:25:22 -0700 Subject: Why is there a space leak here? Message-ID: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs Nov = '99) foo1 eats cells (and eventually runs out) where foo2 doesn't. = That is, if I do (length (foo1 1000000)) I eventually run out of cells = but (length (foo2 1000000)) runs fine (every GC returns basically the = same amount of space). Something must be wrong in flatten but it = follows the pattern of many functions in the prelude (which I'm trying = to learn from). I have been puzzling over this for nearly a full day (getting this = reduced version from my own code which wasn't working). In general, how = can I either a) analyze code looking for a space leak or b) experiment = (e.g., using Hugs) to find a space leak? Thanks! -- Dave -- This has a space leak, e.g., when reducing (length (foo1 1000000)) foo1 m=20 =3D take m v where v =3D 1 : flatten (map triple v) triple x =3D [x,x,x] -- This has no space leak, e.g., when reducing (length (foo2 1000000)) foo2 m=20 =3D take m v where v =3D 1 : flatten (map single v) single x =3D [x] -- flatten a list-of-lists flatten :: [[a]] -> [a] flatten [] =3D [] flatten ([]:xxs) =3D flatten xxs flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs flatten' [] xxs =3D flatten xxs flatten' (x':xs') xxs =3D x': flatten' xs' xxs ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is there a space leak in foo1 but not in = foo2? =20 (I.e., in Hugs Nov '99) foo1 eats cells (and eventually runs out) where = foo2=20 doesn't. That is, if I do (length (foo1 1000000)) I = eventually run=20 out of cells but (length (foo2 1000000)) runs fine (every GC returns = basically=20 the same amount of space). Something must be wrong in flatten but = it=20 follows the pattern of many functions in the prelude (which I'm trying = to learn=20 from). I have been puzzling over this for nearly a full day = (getting=20 this reduced version from my own code which wasn't working). In = general,=20 how can I either a) analyze code looking for a space leak or b) = experiment=20 (e.g., using Hugs) to find a space leak? Thanks! --=20 Dave -- This has a space leak, e.g., = when=20 reducing (length (foo1 1000000)) foo1 m =3D take m=20 v where v =3D 1 = : flatten=20 (map triple v) triple x =3D = [x,x,x] -- This has no space leak, = e.g., when=20 reducing (length (foo2 1000000)) foo2 m =3D take m=20 v where v =3D 1 = : flatten=20 (map single v) single x =3D = [x] -- flatten a = list-of-lists flatten ::=20 [[a]] -> [a] flatten=20 [] = ; =3D=20 [] flatten ([]:xxs) =3D flatten=20 xxs flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs flatten' []=20 xxs =3D flatten = xxs flatten' (x':xs')=20 xxs =3D x': flatten' xs' xxs ------=_NextPart_000_0063_01C0E779.A61E3330-- From jcab@roningames.com Tue May 29 02:02:09 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 18:02:09 -0700 Subject: Notation question In-Reply-To: References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Just a very naive question, because I'm really curious. I've seen in previous messages here discussions about type systems using this kind of notation: > G |- f :: all x::S . T G |- s :: S >-------------------------------------- > G |- f s :: [s/x]T I'd never seen it before, and a few searches I've launched over the net have turned up just a couple more examples of this notation, but without a single reference to how it works or what it means, or even what it's called, for that matter. I'd appreciate any pointers. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From mark@chaos.x-philes.com Tue May 29 02:24:04 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Mon, 28 May 2001 21:24:04 -0400 (EDT) Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: On Mon, 28 May 2001, Juan Carlos Arevalo Baeza wrote: > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. (snip) I'm far from the right person to have a go, but while we're waiting for someone who knows what they're talking about: I bet that |- is 'entails'. My impression of it is rather like 'implies', but clearly that's not quite right or we wouldn't need a different term for it. The . might be 'such that'. The thing below the ----- might be a consequence of the two things above it. The [s/x]T means, probably, "T with s substituted for any occurrence of x". (Did I get that the right way around?) I hope that's a start. -- Mark From jcab@roningames.com Tue May 29 03:18:11 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 19:18:11 -0700 Subject: Notation question In-Reply-To: References: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <4.3.2.7.2.20010528190819.03795668@207.33.235.243> At 09:24 PM 5/28/2001 -0400, Mark Carroll wrote: > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > >I'm far from the right person to have a go, but while we're waiting for >someone who knows what they're talking about: :) Thanx. >"I bet ...", "My impression of it is rather like ...", "..., but clearly >that's not quite right or ...", "... might be ...", "... means, probably, ..." > >I hope that's a start. Ufff... O:-) Sorry for pointing this out, but I couldn't resist. No offense intended. I actually appreciate your response. Really, I mean it. But it's not quite what I was looking for O:-) Anyway, I just saw that I had another reply (this on direct email, not posted to the list) with more info, so if you (or anyone) wants it just ask. Anyway, as the helpful person said about the expression above, "It's a theorem, really". Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From dscarlett@optushome.com.au Tue May 29 04:53:44 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Tue, 29 May 2001 13:53:44 +1000 Subject: Notation question References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <00c401c0e7f2$f4f87780$0100a8c0@CO3003288A> ----- Original Message ----- From: "Juan Carlos Arevalo Baeza" To: Sent: Tuesday, May 29, 2001 11:02 AM Subject: Notation question > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > I think I've seen it (or something similar) in an imperative language called "Imp". From rjmh@cs.chalmers.se Tue May 29 08:13:37 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Tue, 29 May 2001 09:13:37 +0200 (MET DST) Subject: Notation question Message-ID: <200105290713.JAA22503@muppet30.cs.chalmers.se> > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. This is a standard notation for describing type systems in articles on the subject -- so standard that it's hard to think of a good reference that actually explains it! However, I'd suggest looking at Michael Schwartzbach's lecture notes on Polymorphic Type Inference, which are on the web at http://www.daimi.aau.dk/~mis/typeinf.ps The typing rule notation is explained in the first couple of pages, and then used to explain many variants on type systems, show how inference works, etc. I have a collection of links to such articles at http://www.md.chalmers.se/~rjmh/tutorials.html which you might find useful. John Hughes From Andrew.Pitts@cl.cam.ac.uk Tue May 29 08:53:31 2001 From: Andrew.Pitts@cl.cam.ac.uk (Andrew Pitts) Date: Tue, 29 May 2001 08:53:31 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 09:13:37 +0200." <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: John Hughes said > > > > G |- f :: all x::S . T G |- s :: S > > > >-------------------------------------- > > > > G |- f s :: [s/x]T > > > Any more takers? I still don't have any pointers to literature where > this theorem notation is explained more fully, and I'd really like to have > some. > This is a standard notation for describing type systems in articles on the > subject -- so standard that it's hard to think of a good reference that > actually explains it! and not just type systems but also other aspects of operational semantics. What we have here is a single rule from a rule-based inductive definition of a certain relation G |- s :: S between typing environments G, expressions s and types S. I seem to spend half my life using such inductive definitions and the other half teaching them to undergraduates (and the third half doing university administration, hey ho). Casting modesty aside, to read about such things let me recommend lecture notes on operational semantics (esp section 2.3) Andy Pitts From franka@cs.uu.nl Tue May 29 11:39:56 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Tue, 29 May 2001 12:39:56 +0200 Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243>; from jcab@roningames.com on Mon, May 28, 2001 at 06:02:09PM -0700 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <20010529123956.B5078@cs.uu.nl> Juan Carlos Arevalo Baeza wrote (on 28-05-01 18:02 -0700): > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. May I also recommend my PL theory references page?: http://www.cs.uu.nl/people/franka/ref.html BTW, here is the quick version: It says: Suppose term f has type all x::S.T in free variable environment G. Suppose further that term s has type S in environment G. Then the term f s has type [s/x]T (T with s substituted for x) in environment G. But this in itself is really not very meaningful unless you assume some standard definitions. For example, there should be rules for introducing variables, introducing/eliminating "all" types, manipulating environments, a definition for substitution, etc. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From Jon.Fairbairn@cl.cam.ac.uk Tue May 29 11:44:08 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Tue, 29 May 2001 11:44:08 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 08:53:31 BST." Message-ID: <23944.991133048@cl.cam.ac.uk> > and not just type systems but also other aspects of operational > semantics. What we have here is a single rule from a rule-based > inductive definition of a certain relation G |- s :: S between typing > environments G, expressions s and types S. It's probably worth mentioning here that this notation originated (I think) in mathematical logic, as a way of presenting formal systems. Try "Gentzen", "Natural Deduction" and "Sequent Calculus" as search terms. J=F3n From Phil Trinder Tue May 29 15:24:35 2001 From: Phil Trinder (Phil Trinder) Date: Tue, 29 May 2001 15:24:35 +0100 (GMT Daylight Time) Subject: SFP Call for Participation Message-ID: CALL FOR PARTICIPATION 3rd Scottish Functional Programming Workshop University of Stirling Aug 22nd-24th, 2001 You are invited to participate in the 3rd Scottish Functional Programming Workshop. The draft programme is below, and both registration form and additional information are available at: http://www.cee.hw.ac.uk/~greg/sfp3/ SFP'3 Draft Programme ===================== Parallelism ----------- A Comparative Study of Skeleton-based Parallel Programming Environments Allowing Arbitrary Nesting Remi Coudarcher, Jocelyn Serot, Jean-Pierre Derutin Universite Blaise Pascal - Clermont II, France BSP in a Lazy Functional Context Quentin Miller Universite d'Orleans, France Parallel Functional Genetic Programming Graeme McHale and Greg Michaelson Heriot-Watt University, Scotland Introduction of Pipelining into Gaussian Elimination Joy Goodman Glasgow University, Scotland The Efficiency of Parallel Graph Reduction on a Loosely-coupled Multiprocessor Hans Wolfgang Loidl An SPMD environment machine for functional BSP programs Armelle Merlin, Gaetan Hains Universite d'Orleans, France Implementing and Measuring GdH Skeletons Phil Trinder Heriot-Watt University, Scotland Distribution ------------ Distributed Programming with Dynamic Reply Channels Rita Loogen, Steffen Priebe Philips-Universitat Marburg, Germany Distributed Applications in GdH Robert Pointon Heriot-Watt University, Scotland Applications ------------ Haskell: Language for Business Systems Dominic Steinitz, British Airways Chris Reade, Dan Russell, Phil Molyneux, Barry Avery Kingston Business School, England Functional programming languages for verification tools: experiences with ML and Haskell Martin Leucker, Thomas Noll, Perdita Stevens, Michael Weber RWTCH Aachen, Germany/University of Edinburgh, Scotland Infinite Pretty Printing in eXene Allen Stoughton Kansas State University, USA Derivation and Transformation ----------------------------- Extending Higher-Order Deforestation: Transforming Programs to Eliminate Even More Trees Geoff Hamilton, Dublin City University, Ireland Deriving Non-heirarchical Process Topologies Ricardo Pena, Fernando Rubio, Clara Segura Universidad Complutense de Madrid, Spain Language Design and Implementation ---------------------------------- Some Experiences Connecting Functional Languages and Java Andre Rauber Du Bois, Antonio Carlos da Rocha Costa Universidade Federal do Rio Grande do Sul/ Universidade Catolica de Pelotas, Brazil Paging Behaviour of List-based Memory in a Distributed Virtual Memory System for Pure Functional Languages Marco T. Morazan and Douglas R. Troeger City University of New York, USA Types ----- How to Fix Type Errors Automatically Bruce J. McAdam University of Edinburgh, Scotland Function Types and Complete type Inference Manfred Widera, Christoph Bierle Fern Universitat Hagen, Germany Human-like Explanations of Polymorphic Types Yang Jun, Greg Michaelson, Phil Trinder Heriot-Watt University, Scotland Theory ------ The dual of grafting is decoration Tarmo Uustalu, Varmo Vene Universidade do Minho, Portugal University of Tartu, Estonia Towards a Denotational semantics for Eden Mercedes Hidalgo-Herrero, Yolanda Ortega-Mallen Universidad Complutense de Madrid, Spain From thor-list-haskell@banyan.moertel.com Tue May 29 16:35:41 2001 From: thor-list-haskell@banyan.moertel.com (Tom Moertel) Date: Tue, 29 May 2001 11:35:41 -0400 Subject: Notation question References: <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: <3B13C1CD.2AC0CEBA@banyan.moertel.com> Another introduction, with emphasis on the historical development: Philip Wadler, "Proofs are Programs: 19th Century Logic and 21st Century Computing." http://www.cs.bell-labs.com/who/wadler/topics/history.html It's a fun read, too. Cheers, Tom From tullsen@cs.yale.edu Tue May 29 17:48:52 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Tue, 29 May 2001 12:48:52 -0400 Subject: Recursive types? References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> <15113.52727.506242.598828@waytogo.peace.co.nz> Message-ID: <3B13D2F4.F525CFDC@cs.yale.edu> Tom Pledger wrote: > I don't know whether this is a shining example of an advantage, > and am keen to see other comments. For what it's worth, I've pulled some snippets from some code I wrote. I wanted three recursive types which were nearly identical (Exp,ExpQv,ExpPr). Rather than write three different type declarations data Exp = ... data ExpQv = ... data ExpPr = ... I was able to abstract out the commonality into one non-recursive type data FctrExp a = ... Note how concise some of my "Sample Functions" can be. These would have been very long and ugly to write were I to use the first approach. At the expense of now using a "two-level" type, I've gained some expressiveness. - Mark ---- Fix Type ----------------------------------------------------------------- data Fix f = In (f (Fix f)) class FixEq f where fixEq :: Eq a => (f a -> f a -> Bool) class FixShow f where fixShowsPrec :: Show a => (Int -> f a -> ShowS) instance FixEq f => Eq (Fix f) where (==) (In x) (In y) = fixEq x y instance FixShow f => Show (Fix f) where showsPrec p (In x) = showString "In (" . fixShowsPrec p x . showChar ')' ---- Types for Documentation -------------------------------------------------- type Var = String type Env x = [(Var,x)] type Pat = Exp type Type = Exp ---- Form & FormPr Related Types --------------------------------------------- type Qv = (Exp,Exp) data Pr = Pstep (ExpPr,Justifier,ExpPr) | Pletu (Var, Type, ExpPr) deriving(Show,Eq) data Justifier = Stub1 deriving (Show,Eq) ---- Exp,ExpPr,ExpQv Types ---------------------------------------------------- data Ftype = Stub2 deriving (Show,Eq) data Ltype = Stub3 deriving (Show,Eq) data Const = Stub4 deriving (Show,Eq) data FctrExp a = Econ Const | Evar Var | Eapp (Ftype, a, a) | Elet (Ltype, Pat, Type, a, a) -- let x:t=e1 in e2 | Elam (Ftype, Pat, Type, a) -- \x:t=>e | Eqnt (Ftype, Pat, Type, a) -- |~|x:t=>e | Etup [a] -- | Emu a | Ecase a -- case e | Ein (a,a) -- In i e deriving (Show,Eq) data FctrExpQv a = ExpQvExp (FctrExp a) | ExpQvQv Qv deriving (Show,Eq) data FctrExpPr a = ExpPrExp (FctrExp a) | ExpPrPr Pr deriving (Show,Eq) type Exp = Fix FctrExp type ExpQv = Fix FctrExpQv type ExpPr = Fix FctrExpPr ---- Define Appropriate Functors ---------------------------------------------- instance Functor FctrExp where fmap = fmapFctrExp fmapFctrExp :: (a->b) -> (FctrExp a -> FctrExp b) fmapFctrExp f e = case e of Econ x -> Econ x Evar x -> Evar x Eapp (x,e1,e2) -> Eapp (x,f e1, f e2) Elet (x,v,t,y,z) -> Elet (x,v,t,f y,f z) Elam (x,v,t,e) -> Elam (x,v,t,f e) Eqnt (x,v,t,e) -> Eqnt (x,v,t,f e) Etup es -> Etup (map f es) Emu e -> Emu (f e) Ecase e -> Ecase (f e) Ein (i,e) -> Ein (f i,f e) ---- Make Exp,ExpQv,ExpPr instances of Show and Eq ---------------------------- instance FixEq FctrExp where fixEq = (==) instance FixShow FctrExp where fixShowsPrec = showsPrec instance FixEq FctrExpQv where fixEq = (==) instance FixShow FctrExpQv where fixShowsPrec = showsPrec instance FixEq FctrExpPr where fixEq = (==) instance FixShow FctrExpPr where fixShowsPrec = showsPrec ---- Sample Functions --------------------------------------------------------- expToExpPr :: Exp -> ExpPr expToExpPr (In x) = In (ExpPrExp (fmap expToExpPr x)) firstExpPr, finalExpPr :: ExpPr -> Exp firstExpPr (In x) = case x of ExpPrExp e -> In $ fmap firstExpPr e ExpPrPr (Pstep (p,_,_)) -> firstExpPr p ExpPrPr (Pletu _) -> error "firstExpPr" finalExpPr (In x) = case x of ExpPrExp e -> In $ fmap finalExpPr e ExpPrPr (Pstep (_,_,p)) -> finalExpPr p ExpPrPr (Pletu _) -> error "finalExpPr" From awfurtado@uol.com.br Wed May 30 02:04:02 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 29 May 2001 22:04:02 -0300 Subject: Announcement: new HOpenGL Tutorial Message-ID: <00a401c0e8a4$7101d540$bd30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there. I've just released the first version of my HOpenGL (Haskell = Open Graphics Library) tutorial. I hope it will encourage (and help) = people around the world to use this great library/binding. I also would = like to hear some feedback from you. You can visit the tutorial at: www.cin.ufpe.br/~haskell/hopengl/ Thank you, Andre W B Furtado ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there. I've just released the = first version=20 of my HOpenGL (Haskell Open Graphics Library) tutorial. I hope it = will=20 encourage (and help) people around the world to use this great = library/binding.=20 I also would like to hear some feedback from you. You can visit the = tutorial=20 at: www.cin.ufpe.br/~haskel= l/hopengl/ Thank you, Andre W B = Furtado ------=_NextPart_000_009C_01C0E88B.44EDB0A0-- From simonpj@microsoft.com Wed May 30 11:37:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 03:37:10 -0700 Subject: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Folks, I'm about to put out (what I hope is) the final revised Haskell98 report. Here, though, is one good point I propose to clarify. I propose to say that every H98 impl must support tuples up to size 7 and their instances for Eq, Ord, Bounded, Read, Show [Of course, one might hope that impls would do better, but the report should be conservative.] Simon | -----Original Message----- | From: Olaf Chitil [mailto:olaf@cs.york.ac.uk]=20 | Sent: 23 April 2001 12:11 | To: nhc-users@cs.york.ac.uk | Cc: haskell@haskell.org; Simon Peyton-Jones | Subject: Re: Eq instance for (a,b,c,d,e) and upwards |=20 |=20 |=20 | I think that this discussion about tuples shows that there is=20 | a problem with the Haskell 98 report which should be=20 | corrected. I hope Simon accepts it as a minor bug fix. |=20 | 1) The current wording of paragraph 6.1.4 is highly ambigious. |=20 | > 6.1.4 Tuples | > =20 | > Tuples are algebraic datatypes with special syntax, as defined | > in Section 3.8. Each tuple type has a single constructor. There | > is no upper bound on the size of a tuple. However, some Haskell | > implementations may restrict the size of tuples and limit the | > instances associated with larger tuples. The Prelude and=20 | libraries | > define tuple functions such as zip for tuples up to a=20 | size of 7. All | > tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes | > defined in the libraries may also supply instances for=20 | tuple types. |=20 | May the limit for the size of tuples and the limit for=20 | instances be different? Do tuples exist at least for a size=20 | up to 7? What is the purpose of the last sentence? |=20 | We should decide what we want and the paragraph should then=20 | state it clearly. |=20 | 2) The arbitrary restrictions that Haskell implementations=20 | are permitted to apply, basically imply that you shouldn't=20 | use tuples at all if you want your code to be portable. Maybe=20 | there isn't even a Show instance for ()? |=20 | So I think the report should demand that tuples and instances=20 | for Eq,Ord,Bounded,Read and Show should be implemented for at=20 | least up to a size of a given number n. |=20 | 3) I propose this number n to be 7. This fits well with the=20 | fact that zip etc are defined for tuples up to a size of 7. I=20 | agree with Martin that you should use a labelled record or at=20 | least an own type instead of large tuples anyway.=20 | Programs that generate code should als generate definitions=20 | for data types, if large product types are needed.=20 |=20 | Olaf |=20 | --=20 | OLAF CHITIL,=20 | Dept. of Computer Science, University of York, York YO10 5DD, UK.=20 | URL: http://www.cs.york.ac.uk/~olaf/ | Tel: +44 1904 434756; Fax: +44 1904 432767 |=20 From simonpj@microsoft.com Wed May 30 12:08:26 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 04:08:26 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Folks I've finished what I hope is the final version of the Haskell 98=20 Language and Library Reports http://research.microsoft.com/~simonpj/haskell98-revised However, experience shows that bug fixes are often themselves buggy, so I urge you, once again, to take a look at your favourite passages and check they are correct. As ever, there's a complete list of changes at the above URL, with the ones I've made since the April release identified for your pleasure. Comments (hopefully vanishingly few) by 15 June please. Thanks very much Simon From rjljr2@yahoo.com Wed May 30 12:27:01 2001 From: rjljr2@yahoo.com (Ronald Legere) Date: Wed, 30 May 2001 04:27:01 -0700 (PDT) Subject: Announcement: new HOpenGL Tutorial In-Reply-To: <00a401c0e8a4$7101d540$bd30e3c8@windows9> Message-ID: <20010530112701.62154.qmail@web10006.mail.yahoo.com> Looks great! I think the community will really appreciate it. I will have to 'give it a whirl' myself, if I can ever get HOpenGL to compile on my solaris sparc. (I keep having trouble with 'test' in the makefiles. I must have a wierd version of test or something. I am no OS guru :) (If anyone has ever seen this problem, let me know ) Cheers! --- Andre W B Furtado wrote: > Hello there. I've just released the first version of > my HOpenGL (Haskell Open Graphics Library) tutorial. > I hope it will encourage (and help) people around > the world to use this great library/binding. I also > would like to hear some feedback from you. You can > visit the tutorial at: > > www.cin.ufpe.br/~haskell/hopengl/ > > Thank you, > Andre W B Furtado > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From tullsen@cs.yale.edu Wed May 30 17:04:49 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 12:04:49 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B151A21.BD5CA994@cs.yale.edu> Simon Peyton-Jones wrote: > > Folks > > I've finished what I hope is the final version of the Haskell 98 > Language and Library Reports > http://research.microsoft.com/~simonpj/haskell98-revised > > However, experience shows that bug fixes are often themselves > buggy, so I urge you, once again, to take a look at your favourite > passages and check they are correct. > > As ever, there's a complete list of changes at the above URL, > with the ones I've made since the April release identified for your > pleasure. > > Comments (hopefully vanishingly few) by 15 June please. Simon, Sorry to get this comment in so late, but it is a small change. In the List module, the type signature for deleteBy is not as general as it could be, given the definition. It could be generalized to the following (no change to the definition): deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] I've found it usefully used at this more general type. Thanks. - Mark From simonpj@microsoft.com Wed May 30 17:46:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 09:46:53 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> | Sorry to get this comment in so late, but it is a small=20 | change. In the List module, the type signature for deleteBy=20 | is not as general as it could be, given the definition. It=20 | could be generalized to the following (no change to the definition): |=20 | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] |=20 | I've found it usefully used at this more general type. Indeed, and=20 deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] I can't see any reason not to do this. Furthermore, the Report omits to export deleteFirstsBy, though GHC and Hugs both remember to do so. Simon From ross@soi.city.ac.uk Wed May 30 17:57:08 2001 From: ross@soi.city.ac.uk (Ross Paterson) Date: Wed, 30 May 2001 17:57:08 +0100 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010530175708.A3688@soi.city.ac.uk> On Wed, May 30, 2001 at 09:46:53AM -0700, Simon Peyton-Jones wrote: > | Sorry to get this comment in so late, but it is a small > | change. In the List module, the type signature for deleteBy > | is not as general as it could be, given the definition. It > | could be generalized to the following (no change to the definition): > | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > | > | I've found it usefully used at this more general type. > > Indeed, and > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] and intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] From zhanyong.wan@yale.edu Wed May 30 18:41:49 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 13:41:49 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3B1530DC.AAC1220D@yale.edu> Hello Simon, Looking at the definition for deleteBy: deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] deleteBy eq x [] = [] deleteBy eq x (y:ys) = if x `eq` y then ys else y : deleteBy eq x ys I can't help wondering why it isn't deleteBy' :: (a -> Bool) -> [a] -> [a] deleteBy' f [] = [] deleteBy' f (y:ys) = if f y then ys else y : deleteBy' f ys The point is that in the definition of deleteBy, all references to eq and x are in the form (eq x), and hence the two parameters can be combined. Is there a reason that the current design was favored when Prelude was designed? Thanks. - Zhanyong -- # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ # Yale University, Dept of Computer Science /\___\ # P.O.Box 208285, New Haven, CT 06520-8285 ||___| From Malcolm.Wallace@cs.york.ac.uk Wed May 30 18:37:47 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Wed, 30 May 2001 18:37:47 +0100 Subject: Haskell 98 Report In-Reply-To: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3FkAAOsvFTt4cwoA@cs.york.ac.uk> > > | It could be generalized to the following (no change to the definition): > > | > > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > > > > Indeed, and > > > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] > > and > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Although curiously, its dual 'unionBy' cannot also take the more general type unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] at least, not with its current specification in terms of 'nubBy'. Regards, Malcolm From Tom.Pledger@peace.com Wed May 30 21:16:44 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 08:16:44 +1200 Subject: Haskell 98 Report In-Reply-To: <3B1530DC.AAC1220D@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <15125.21804.829456.439929@waytogo.peace.co.nz> Zhanyong Wan writes: : | I can't help wondering why it isn't | | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] = [] | deleteBy' f (y:ys) = if f y then ys else | y : deleteBy' f ys deleteBy'' f = filter (not . f) Malcolm Wallace writes: : | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | Although curiously, its dual 'unionBy' cannot also take the more | general type | | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | at least, not with its current specification in terms of 'nubBy'. That suggests a reason to leave the type of intersectBy alone - the generalisation would arbitrarily favour the first list's type over the second list's type. To me, the word "intersect" implies symmetry. - Tom From zhanyong.wan@yale.edu Wed May 30 22:15:48 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 17:15:48 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> Message-ID: <3B156304.BD9F41F8@yale.edu> Tom Pledger wrote: > > Zhanyong Wan writes: > : > | I can't help wondering why it isn't > | > | deleteBy' :: (a -> Bool) -> [a] -> [a] > | deleteBy' f [] = [] > | deleteBy' f (y:ys) = if f y then ys else > | y : deleteBy' f ys > > deleteBy'' f = filter (not . f) No. deleteBy' f only deletes the *first* element that satisfies the predicate f, while filter (not . f) deletes *all* such elements. -- Zhanyong From Tom.Pledger@peace.com Wed May 30 22:25:53 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 09:25:53 +1200 Subject: Haskell 98 Report In-Reply-To: <3B156304.BD9F41F8@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> <3B156304.BD9F41F8@yale.edu> Message-ID: <15125.25953.715929.236763@waytogo.peace.co.nz> Zhanyong Wan writes: | Tom Pledger wrote: : | > deleteBy'' f = filter (not . f) | | No. deleteBy' f only deletes the *first* element that satisfies the | predicate f, while filter (not . f) deletes *all* such elements. Oops. Sorry. I ought to become less SQL-oriented... From tullsen@cs.yale.edu Thu May 31 00:59:44 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 19:59:44 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <3B158970.9C5D11EE@cs.yale.edu> Zhanyong Wan wrote: > > Hello Simon, > > Looking at the definition for deleteBy: > > deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] > deleteBy eq x [] = [] > deleteBy eq x (y:ys) = if x `eq` y then ys else > y : deleteBy eq x ys > > I can't help wondering why it isn't > > deleteBy' :: (a -> Bool) -> [a] -> [a] > deleteBy' f [] = [] > deleteBy' f (y:ys) = if f y then ys else > y : deleteBy' f ys > > The point is that in the definition of deleteBy, all references to eq > and x are in the form (eq x), and hence the two parameters can be > combined. Is there a reason that the current design was favored when > Prelude was designed? Thanks. > > - Zhanyong Zhanyong, I didn't mean to open up a can of worms! Although, when viewed in isolation, it would make sense to change deleteBy as you suggest; but when we look at the conventions of the List module, I think that it would be undesirable, even if we didn't care about breaking programs, because it would break the "xBy" convention described below. Originally we had this: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] And all the functions "x" with a "xBy" form have types which are related in a particular way, for some functor f: x :: Eq a => f a xBy :: (a -> a -> Bool) -> f a Now, if we generalize the type of deleteBy as I previously suggested, we have these two types: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] And it is still the case that functions "x" and "xBy" have types which are related as follows (generalizing the rule): x :: Eq a => f a a xBy :: (a -> b -> Bool) -> f a b (Where we would instantiate 'b' to 'a' for "xBy" functions which have a less general type.) - Mark From nilsson@cs.yale.edu Thu May 31 03:07:29 2001 From: nilsson@cs.yale.edu (Henrik Nilsson) Date: Wed, 30 May 2001 22:07:29 -0400 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B15A761.8C3F418C@cs.yale.edu> Hi, Simon Peyton-Jones wrote: > Folks, > > I'm about to put out (what I hope is) the final revised Haskell98 > report. > > Here, though, is one good point I propose to clarify. I propose to > say that > > every H98 impl must support tuples up to size 7 > and their instances for Eq, Ord, Bounded, Read, Show > > > [Of course, one might hope that impls would do better, but the report > should be conservative.] Clearly, the report has to state the minimal bound. And I agree that 7 is a choice which is consistent with the current Prelude. However, 7 is also a number which is uncomfortably close to what I've seen in real code and used myself. Yes, one might hope that this is a non issue, since all implementations I'm aware of does considerably better anyway. But if one wants to write portable code, it does become an issue. And yes, one could argue that records or user-defined product types should be used anyway. But that is really a matter of taste, and I'd say that there are reasonable examples where forcing the user to introduce a product type just to wrap up a bunch of values would harm rather than improve the readability. So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu From ralf@informatik.uni-bonn.de Thu May 31 08:20:43 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Thu, 31 May 2001 09:20:43 +0200 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> Message-ID: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal > bound cannot be "infinity", could it at least be a great deal > bigger than what reasonably would be used in *hand-written* > code? Say 15. An arbitrary choice, of course, but it is not > excessive from an implementation perspective, yet large enough > that I cannot imagine hand-written code getting close to the > limit. I second Henrik here, 15 is much better than 7. Cheers, Ralf From chak@cse.unsw.edu.au Thu May 31 08:21:52 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 31 May 2001 17:21:52 +1000 Subject: Eq instance for (a,b,c,d,e) and upwards In-Reply-To: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Message-ID: <20010531172152T.chak@cse.unsw.edu.au> Ralf Hinze wrote, > Henrik Nilsson wrote: > > > So, if, in the interest of being conservative, the stated minimal > > bound cannot be "infinity", could it at least be a great deal > > bigger than what reasonably would be used in *hand-written* > > code? Say 15. An arbitrary choice, of course, but it is not > > excessive from an implementation perspective, yet large enough > > that I cannot imagine hand-written code getting close to the > > limit. > > I second Henrik here, 15 is much better than 7. I agree. Manuel From simonpj@microsoft.com Thu May 31 08:58:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:58:58 -0700 Subject: FW: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73004@red-msg-09.redmond.corp.microsoft.com> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal=20 > bound cannot be "infinity", could it at least be a great deal bigger=20 > than what reasonably would be used in *hand-written* code? Say 15. An=20 > arbitrary choice, of course, but it is not excessive from an=20 > implementation perspective, yet large enough that I cannot imagine=20 > hand-written code getting close to the limit. A fair point. If you care either way, send me a note. (Not to the list.) Henrik leaves open the question of which tuple *instances* you can rely on. Up to 7, like zip and friends? Or up to 15? By analogy with the zip functions, I think I'd go for 7. Again, let me know, but don't trouble the list unless you want to raise a new point. Simon From simonpj@microsoft.com Thu May 31 08:53:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:53:50 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] | > |=20 | > | I've found it usefully used at this more general type. | >=20 | > Indeed, and | >=20 | > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] |=20 | and |=20 | intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Indeed. We should either generalise all three deleteBy deleteFirstsBy intersectBy or none. In favour: the more general types are occasionally useful no programs stop working Against it's an unforced change perhaps some error message may get more obscure Tom wrote | That suggests a reason to leave the type of intersectBy alone=20 | - the generalisation would arbitrarily favour the first=20 | list's type over the second list's type. To me, the word=20 | "intersect" implies symmetry. The point is that you can always use it at the symmetrical type too. This isn't a big issue, or I would not be considering it at this point. So I solicit feedback, and will then just decide something. Simon From simonpj@microsoft.com Thu May 31 08:43:13 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:43:13 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73000@red-msg-09.redmond.corp.microsoft.com> I don't think there was a deep reason, but the current story makes it more like the other 'By' functions. Anyway, this is one thing that is not going to change! (Not that you were proposing that it should.) Simon | -----Original Message----- | From: Zhanyong Wan [mailto:zhanyong.wan@yale.edu]=20 | Sent: 30 May 2001 18:42 | To: Simon Peyton-Jones | Cc: haskell@haskell.org | Subject: Re: Haskell 98 Report |=20 |=20 | Hello Simon, |=20 | Looking at the definition for deleteBy: |=20 | deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] | deleteBy eq x [] =3D [] | deleteBy eq x (y:ys) =3D if x `eq` y then ys else | y : deleteBy eq x ys |=20 | I can't help wondering why it isn't |=20 | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] =3D [] | deleteBy' f (y:ys) =3D if f y then ys else | y : deleteBy' f ys |=20 | The point is that in the definition of deleteBy, all=20 | references to eq and x are in the form (eq x), and hence the=20 | two parameters can be combined. Is there a reason that the=20 | current design was favored when Prelude was designed? Thanks. |=20 | - Zhanyong |=20 | --=20 | # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ | # Yale University, Dept of Computer Science /\___\ | # P.O.Box 208285, New Haven, CT 06520-8285 ||___| |=20 From S.J.Thompson@ukc.ac.uk Thu May 31 13:40:54 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Thu, 31 May 2001 13:40:54 +0100 Subject: Teaching Assistantships in the Computing Lab, University of Kent Message-ID: Haskellers welcome! Simon Teaching Assistantships in the Computing Lab, University of Kent Applications are invited for two posts of teaching assistant in the Computing Laboratory at the University of Kent. These posts are for a fixed-term period of four years and are intended to support postgraduate researchers during their period of registration for a part-time PhD in one of the research groups in the Computing Laboratory. The successful applicants will be required to participate in up to eight hours teaching per week during academic terms. Applicants will be expected to provide evidence of their experience in teaching or equivalent activities. Total remuneration is at the rate of 13,231 GBP per annum, made up of 6931 GBP salary and 6300 GBP PhD bursary; PhD fees are paid in addition to this. Application procedure Applications should be sent by email to the professorial secretary, Mrs Jenny Oatley, jao@ukc.ac.uk, with the subject line 'Teaching Assistant Application'. Applications should include - A brief curriculum vitae, detailing - educational history and qualifications; - employment history; - details of teaching experience, if any; - country of residence, native language (if not English please include TOEFL/IELTS score). - A statement of your proposed research project, including the research group in which that research project lies. - Names, addresses and email addresses of two academic referees. The deadline for applications is 21 June 2001, and interviews will take place on 28 June 2001. Applicants who are unable to attend interviews may be asked for telephone interview. From joshuag@ozemail.com.au Thu May 31 17:02:37 2001 From: joshuag@ozemail.com.au (Joshua Ginges) Date: Fri, 01 Jun 2001 02:02:37 +1000 Subject: Dividing floats Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3074205757_1755708 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Can anyone please help me. How can you divide two floats? (and return a float, even if they divide equally) Ie (something like...) div 2.4 1.2 ---> 2.0 Thanks Josh --B_3074205757_1755708 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Dividing floats Can anyone please help me. How can you divide two floats? (and return a float, even if they divide equ= ally) Ie (something like...) div 2.4 1.2 ---> 2.0 Thanks Josh --B_3074205757_1755708-- From djrussell@kingston.ac.uk Thu May 31 17:25:46 2001 From: djrussell@kingston.ac.uk (Daniel Russell) Date: Thu, 31 May 2001 17:25:46 +0100 (BST) Subject: Dividing Floats Message-ID: <200105311625.RAA08117@helios.king.ac.uk> > Can anyone please help me. > How can you divide two floats? (and return a float, even if they divide > equally) > Ie (something like...) div 2.4 1.2 ---> 2.0 The above doesn't work since div can only be applied to integral numbers: div :: Integral a => a -> a -> a What you need is the operator (/) which can only be applied to fractional numbers: (/) :: Fractional a => a -> a -> a For example: 2.4 / 1.2 ---> 2.0 or (/) 2.4 1.2 ---> 2.0 Dan Russell Kingston University From fjh@cs.mu.oz.au Thu May 31 19:19:23 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 04:19:23 +1000 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010601041923.A10308@hg.cs.mu.oz.au> On 31-May-2001, Simon Peyton-Jones wrote: > We should either generalise all three > deleteBy > deleteFirstsBy > intersectBy > or none. > > In favour: > the more general types are occasionally useful > no programs stop working Actually some programs will stop working, because the types will be underconstrained, so the compiler won't know how to satisfy some type class constraint. For example: import List main = print (deleteBy (\x _y -> x > 0) 1 []) With the generalized type, you'd get an unresolved `Show' constraint. The number of real programs for which this is a problem is most likely very small, and the work-around (typically just adding an explicit type qualification) is not hard once you understand what the problem is, but figuring out what the problem is could take some time. Since it does break some obscure programs, and since it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature, my preference would be to leave this out of Haskell 98, but include it in the next version of Haskell. (It would be good for someone, perhaps Simon P-J., to keep a list of issues like this which have been left out of Haskell 98 due to backwards compatibility concerns, so that they don't get forgotten about when it comes to time for the next version.) -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From C.Reinke@ukc.ac.uk Thu May 31 19:48:24 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 31 May 2001 19:48:24 +0100 Subject: Haskell 98 Report In-Reply-To: Message from Fergus Henderson of "Fri, 01 Jun 2001 04:19:23 +1000." <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: "..it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature,.." Fergus Henderson, June 2001 Is this definition of reuse in Haskell quotable?-) Claus From tullsen@cs.yale.edu Thu May 31 20:04:02 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Thu, 31 May 2001 15:04:02 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: <3B1695A2.2318EBC0@cs.yale.edu> So much for my small, innocuous, non controversial suggestion :-). Fergus Henderson wrote: > > On 31-May-2001, Simon Peyton-Jones wrote: > > We should either generalise all three > > deleteBy > > deleteFirstsBy > > intersectBy > > or none. > > > > In favour: > > the more general types are occasionally useful > > no programs stop working > > Actually some programs will stop working, because the types will be > underconstrained, so the compiler won't know how to satisfy some type class > constraint. > > For example: > > import List > main = print (deleteBy (\x _y -> x > 0) 1 []) > > With the generalized type, you'd get an unresolved `Show' constraint. That's a good point Fergus, I hadn't noticed the potential problem here. > The number of real programs for which this is a problem is most likely very > small, and the work-around (typically just adding an explicit type > qualification) is not hard once you understand what the problem is, but > figuring out what the problem is could take some time. My intuition (whatever it's worth) tells me that the real programs that would be affected are close to nil. Would you agree? > Since it does break some obscure programs, and since it's easy enough > for programmers who want a generalized version to just cut and paste > the code from the Haskell report and give it a more general type signature, Sure, it's easy enough, but one of the reasons I like Haskell so much over languages like C is that I almost never have to resort to programming by "cut and paste". I generally prefer to give the most general type signature for each definition. It makes programs more robust. It gives a stronger "free theorem"; in other words, I can tell more about the function by just looking at the type. For instance ... Tom Pledger wrote: > Malcolm Wallace writes: > : > | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | Although curiously, its dual 'unionBy' cannot also take the more > | general type > | > | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | at least, not with its current specification in terms of 'nubBy'. > > That suggests a reason to leave the type of intersectBy alone - the > generalisation would arbitrarily favour the first list's type over the > second list's type. To me, the word "intersect" implies symmetry. But to me it seems a good reason to change the type of intersectBy: the definition isn't really symmetric, so why should the type signature be symmetric? - Mark From fjh@cs.mu.oz.au Thu May 31 22:20:10 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 07:20:10 +1000 Subject: Haskell 98 Report In-Reply-To: References: Message-ID: <20010601072010.A10659@hg.cs.mu.oz.au> On 31-May-2001, C.Reinke wrote: > > "..it's easy enough for programmers who want a generalized version to just cut > and paste the code from the Haskell report and give it a more general type > signature,.." > > Fergus Henderson, June 2001 > > Is this definition of reuse in Haskell quotable?-) Sure, feel free to go ahead and quote it (you just did already ;-). But it's taken a little out of context. Certainly I wouldn't recommend that as a method of code reuse in ordinary cases, let alone posit it as a _definition_ of reuse. However, in this particular case, where the algorithm is fairly trivial, and the code is well tested, the costs of cut-and-paste reuse are not high, and specifically the downside of that approach is comparable to the downside of the other approach, namely the need to diagnose and fix type errors in programs like the one I posted. So we need to consider the likely frequency of these scenarios, and the benefits/costs of keeping the Haskell 98 standard as stable as possible or making minor changes like this that could also cause problems when converting between one "Haskell 98, 2002 revision" compiler and another "classic Haskell 98" implementation. It's all about trade-offs. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Thu May 31 23:10:43 2001 From: reid@cs.utah.edu (Alastair David Reid) Date: 31 May 2001 16:10:43 -0600 Subject: Haskell 98 Report In-Reply-To: <20010601041923.A10308@hg.cs.mu.oz.au> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: Fergus Henderson writes: > (It would be good for someone, perhaps Simon P-J., to keep a > list of issues like this which have been left out of Haskell 98 > due to backwards compatibility concerns, so that they don't get > forgotten about when it comes to time for the next version.) Such a list would indeed be useful but I think it's important that the list should record that there are reasons besides backwards compatability for leaving things as they are. IIRC, at the time that the functions were added to List, someone proposed generalisations like those currently on the table but they were rejected because they made it harder to state the relationship between the By functions and their overloaded brethren. With things as they are now, the relationship between the By functions and their overloaded variants is very, very simple to state: if foo has type foo :: (Eq a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an equivalence relation) and foo = fooBy (==) and if foo has type foo :: (Ord a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an reflexive, transitive relation) and foo = fooBy (<=) Making the types of the By functions as general as possible would break the consistency of this story. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/ From ml_dk@excite.com Tue May 1 13:31:03 2001 From: ml_dk@excite.com (ml_dk@excite.com) Date: Tue, 1 May 2001 14:31:03 +0200 Subject: The Haskell kernel Message-ID: <3AE495BD00012269@cpmail.asap.asp.net> In the report on the Haskell programming language (http://www.haskell.org= /onlinereport/), the Haskell kernel is mentionen in several places. It says in section 1.2= that the Haskell kernel is a slightly sugared form of lambda calculus. Fu= thermore most expression should be possible to translate to the Haskell kernel. But where is this kernel defined (I cannot find it in the report) ? Actually the case-expression(section 3.13) seems more fundamental than th= e lambda-expression in Haskell. Several construct translate to the case-exp= ression instead of lambda-expression as the if-expression(section 3.6). It is als= o shown howto translate the lambda-expression into the case-expression in section 3.3. Am I missing something here ? Grateful for any hint. Mads ________________________________________ Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt! From simonpj@microsoft.com Tue May 1 17:22:19 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 1 May 2001 09:22:19 -0700 Subject: The Haskell kernel Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E6A@red-msg-09.redmond.corp.microsoft.com> I'm afraid the "Haskell kernel" isn't formally defined. The Report describes how to translate complex constructs into simpler ones, but neither specifies *exactly* what these simpler ones are, nor gives their meaning in a formal way. Simon | -----Original Message----- | From: ml_dk@sol.dk [mailto:ml_dk@sol.dk]=20 | Sent: 01 May 2001 13:31 | To: Haskell mailinglist | Subject: The Haskell kernel |=20 |=20 |=20 | In the report on the Haskell programming language=20 | (http://www.haskell.org/onlinereport/), | the Haskell kernel is mentionen in several places. It says in=20 | section 1.2 that the Haskell kernel is a slightly sugared=20 | form of lambda calculus. Futhermore most expression should be=20 | possible to translate to the Haskell kernel. |=20 | But where is this kernel defined (I cannot find it in the report) ? |=20 | Actually the case-expression(section 3.13) seems more=20 | fundamental than the lambda-expression in Haskell. Several=20 | construct translate to the case-expression instead of=20 | lambda-expression as the if-expression(section 3.6). It is=20 | also shown howto translate the lambda-expression into the=20 | case-expression in section 3.3. Am I missing something here ? |=20 | Grateful for any hint. |=20 | Mads |=20 |=20 |=20 | ________________________________________ | F=E5 din egen webmail p=E5 http://mail.sol.dk - gratis og med dig = overalt! |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From senganb@ia.nsc.com Wed May 2 01:58:07 2001 From: senganb@ia.nsc.com (Sengan) Date: Tue, 01 May 2001 20:58:07 -0400 Subject: Interesting: "Lisp as a competitive advantage" Message-ID: <3AEF5B9F.88D92A76@ia.nsc.com> http://www.paulgraham.com/paulgraham/avg.html I wonder how Haskell compares in this regard. Any comment from Haskell startups? (eg Galois Connections) Sengan From matth@mindspring.com Wed May 2 02:42:34 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 01 May 2001 20:42:34 -0500 Subject: User defined Ix instances potentially unsafe Message-ID: <3AEF660A.87AF9D6C@mindspring.com> Sorry if this has been reported before. I shouldn't be able to crash ghc or hugs without using any "unsafe" features, right? Well, here 'tis: > module CrashArray where > > import Array > import Ix > > newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show) > > instance Enum CrashIx where > toEnum x = (CrashIx x) > fromEnum (CrashIx x) = x > > instance Ix CrashIx where > inRange (_,_) _ = True > index (_,_) (CrashIx x) = x > range (x,y) = [x..y] > > myArray = listArray (CrashIx 0, CrashIx 0) [0] > crash = myArray ! (CrashIx maxBound) In ghci-5.00, I get a segfault and hugs-feb-2000 says: INTERNAL ERROR: Error in graph Now, admittedly my Ix instance is broken, but I don't think I should be able to segfault the interpreter. Unfortunately, I think the only way to fix this without changing the Library Report would be to add another layer of range checking to the array implementation. Bleh. Note also that the (inefficient) implementation in the report wouldn't crash, but would get the "wrong" error: "Undefined array element" instead of "Index out of range". I think we might describe this as a bug in the Library Report, rather than in any particular Haskell implementation. Enjoy! Matt Harden From chak@cse.unsw.edu.au Wed May 2 08:21:00 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Wed, 02 May 2001 17:21:00 +1000 Subject: Interesting: "Lisp as a competitive advantage" In-Reply-To: <3AEF5B9F.88D92A76@ia.nsc.com> References: <3AEF5B9F.88D92A76@ia.nsc.com> Message-ID: <20010502172100G.chak@cse.unsw.edu.au> Sengan wrote, > http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. > Any comment from Haskell startups? (eg Galois Connections) I already see John Launchbury asking us not to teach Haskell anymore ;-) Manuel From lordcrucifix@yahoo.com Wed May 2 09:31:54 2001 From: lordcrucifix@yahoo.com (lynn yeong) Date: Wed, 2 May 2001 01:31:54 -0700 (PDT) Subject: List of words Message-ID: <20010502083154.19873.qmail@web14208.mail.yahoo.com> --0-1918502651-988792314=:18992 Content-Type: text/plain; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992 Content-Type: text/html; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992-- From uk1o@rz.uni-karlsruhe.de Wed May 2 09:34:31 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Wed, 2 May 2001 10:34:31 +0200 Subject: List of words In-Reply-To: <20010502083154.19873.qmail@web14208.mail.yahoo.com>; from lordcrucifix@yahoo.com on Wed, May 02, 2001 at 01:31:54AM -0700 References: <20010502083154.19873.qmail@web14208.mail.yahoo.com> Message-ID: <20010502103428.B7733@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:31:54AM -0700, lynn yeong wrote: > Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! [please wrap your lines!] How about this: import Char(toUpper) capitalize :: String -> String capitalize [] = [] capitalize (c:cs) = toUpper c : cs capitalizeList :: [String] -> [String] capitalizeList = map capitalize Kind regards, Hannah. From ashley@semantic.org Wed May 2 09:42:55 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 01:42:55 -0700 Subject: List of words Message-ID: <200105020842.BAA13085@mail4.halcyon.com> At 2001-05-02 01:34, Hannah Schroeter wrote: >How about this: > >import Char(toUpper) > >capitalize :: String -> String >capitalize [] = [] >capitalize (c:cs) = toUpper c : cs > >capitalizeList :: [String] -> [String] >capitalizeList = map capitalize ...or if you prefer... capitalizeList :: [String] -> [String] capitalizeList = map (map toUpper) -- Ashley Yakeley, Seattle WA From rjmh@cs.chalmers.se Wed May 2 09:51:58 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 10:51:58 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105020851.KAA15484@muppet30.cs.chalmers.se> (B) Monomorphism restriction "wins" Bindings that fall under the monomorphism restriction can't be generalised Always generalise over implicit parameters *except* for bindings that fall under the monomorphism restriction Consequences * Inlining isn't valid in general * No unexpected loss of sharing * Simple bindings like z = ?y + 1 accepted (get value of ?y from binding site) (C) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised, EXCEPT for implicit parameters Consequences * Inlining remains valid * Unexpected loss of sharing (from the extra generalisation) * Simple bindings like z = ?y + 1 accepted (get value of ?y from occurrence sites) Discussion ~~~~~~~~~~ None of these choices seems very satisfactory. But at least we should decide which we want to do. It's really not clear what is the Right Thing To Do. If you see z = (x::Int) + ?y would you expect the value of ?y to be got from the *occurrence sites* of 'z', or from the valuue of ?y at the *definition* of 'z'? In the case of function definitions, the answer is clearly the former, but less so in the case of non-fucntion definitions. On the other hand, if we say that we get the value of ?y from the definition site of 'z', then inlining 'z' might change the semantics of the program. Choice (C) really says "the monomorphism restriction doesn't apply to implicit parameters". Which is fine, but remember that every innocent binding 'x = ...' that mentions an implicit parameter in the RHS becomes a *function* of that parameter, called at each use of 'x'. Now, the chances are that there are no intervening 'with' clauses that bind ?y, so a decent compiler should common up all those function calls. So I think I strongly favour (C). Indeed, one could make a similar argument for abolishing the monomorphism restriction altogether. I disagree. I think it's important to have a simple model of how many times expressions are evaluated. Function bodies are clearly evaluated many times, once for each call, but non-function bindings should be evaluated at most once to respect call-by-need semantics. Breaking the monomorphism restriction in ANY case makes both space and time cost of evaluation unpredictable, and brittle when program changes elsewhere introduce or remove an implicit parameter. It isn't good enough to say `the chances are' that a program has, for example, linear time and constant space complexity: the programmer should be able to convince himself of such properties. As far as what one would `expect', it's in the very nature of dynamic binding that it makes the meaning of an expression depend on its context. I for one would certainly not expect that inlining a definition bound to such an expression should preserve its meaning! Inlining changes the context, so `of course' can change the meaning. So I strongly prefer (B)! John Hughes From karczma@info.unicaen.fr Wed May 2 10:51:18 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 02 May 2001 11:51:18 +0200 Subject: List of words References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <3AEFD896.1A168297@info.unicaen.fr> I am relatively new to Haskell. Somebody told me that it is a very good language, because all the people on its mailing list are so nice that they solve all homeworks, even quite silly, of all students around, provided they ask for a solution in Haskell. Is that true, or a little exaggerated? Jerzy Karczmarczuk From rjmh@cs.chalmers.se Wed May 2 12:29:46 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 13:29:46 +0200 (MET DST) Subject: Erlang workshop Message-ID: <200105021129.NAA18088@muppet30.cs.chalmers.se> (apologies if you receive more than one copy of this). Call for abstracts to the Erlang Workshop Firenze, September 2, 2001, in connection with PLI2001=20 (Principles, Logics, and Implementations of high-level=20 programming languages). Scope Contributions are invited on experience with and=20 applications of Erlang, critiques and proposals for=20 extensions, design methods and structuring principles=20 for large functional systems, implementation techniques,=20 programming tools, verification methods, etc. Submitted abstracts should be 2-12 pages, and will be=20 judged on the potential for an interesting presentation. Abstracts should in text, postscript or PDF format and sent to workshop@erix.ericsson.se by May 15, 2001.=20 Authors will be notified of acceptance by June 15, 2001. Authors of accepted abstracts are welcome to submit=20 full papers or additional accompanying materials for=20 inclusion in the informal proceedings by August 15, 2001. Home page of the Erlang workshop http://www.erlang.se/workshop/ Home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome Joe Armstrong, Alteon Websystems Bjarne D=E4cker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee) From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 12:54:38 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 12:54:38 +0100 Subject: List of words In-Reply-To: Message from Jerzy Karczmarczuk of "Wed, 02 May 2001 11:51:18 +0200." <3AEFD896.1A168297@info.unicaen.fr> Message-ID: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Ah, but (i) not all the solutions are correct (sorry Ashley); and (ii) some of the solutions should be recognisable by markers as not the work of a newbie (explicit import lists, map, ...). Essentially, though, your friend is correct. --KW 8-) From ashley@semantic.org Wed May 2 13:19:52 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 05:19:52 -0700 Subject: List of words Message-ID: <200105021219.FAA23304@mail4.halcyon.com> At 2001-05-02 04:54, Keith Wansbrough wrote: >Ah, but (i) not all the solutions are correct (sorry Ashley); That rather depends on what you mean by CAPITALISE, does it not? capitalise, -ize to print or write with capital letters [Chambers] -- Ashley Yakeley, Seattle WA From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 13:27:18 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 13:27:18 +0100 Subject: List of words In-Reply-To: Message from Ashley Yakeley of "Wed, 02 May 2001 05:19:52 PDT." <200105021219.FAA23304@mail4.halcyon.com> Message-ID: > >Ah, but (i) not all the solutions are correct (sorry Ashley); > > That rather depends on what you mean by CAPITALISE, does it not? > > capitalise, -ize to print or write with capital letters [Chambers] I guess so. Maybe someone at Monash University (Australia) would care to enlighten us? >;-> --KW 8-) -- Keith Wansbrough http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory. From jans@numeric-quest.com Wed May 2 08:36:14 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Wed, 2 May 2001 03:36:14 -0400 (EDT) Subject: List of words In-Reply-To: <3AEFD896.1A168297@info.unicaen.fr> Message-ID: On Wed, 2 May 2001, Jerzy Karczmarczuk wrote: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Not really. No one wants to answer my questions. :-) Do you think that this list is the only source of easy solutions? See what people ask Google and what Google sends to our web server: procedural+design+for+a+program+that+accepts+a+string +as+input+and+then+converts+all+upper+case+to+lower+case +and++vice-versa+and+prints+resulting+string+as+output Must be a tough and generic problem. Notice that Haskell is not mentioned here at all, but yet Google happily directed it to one of Haskell pages here. By the way, this is not the longest question that I've seen in the logs. Some are so long and weird that must match any web page out there. Jan From ralf@cs.uu.nl Tue May 1 17:47:11 2001 From: ralf@cs.uu.nl (Ralf Hinze) Date: Tue, 01 May 2001 18:47:11 +0200 Subject: 2001 Haskell Workshop: final call for papers Message-ID: <3AEEE88F.1BA9E9BC@cs.uu.nl> ============================================================================ FINAL CALL FOR PAPERS [Deadline for submission: 1st June 2001] 2001 Haskell Workshop Firenze, Italy, 2nd September 2001 The Haskell Workshop forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/people/ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. Submission details ------------------ Deadline for submission: 1st June 2001 Notification of acceptance: 12th July 2001 Final submission due: 1st August 2001 Haskell Workshop: 2nd September 2001 Authors should submit papers in postscript format, formatted for A4 paper, to Ralf Hinze (ralf@cs.uu.nl) by 1st June 2001. Use of the ENTCS style files is strongly recommended. The length should be restricted to the equivalent of 5000 words (which is approximately 24 pages in ENTCS format, or 12 pages in ACM format). Note that this word limit represents a change from the first call for papers. Application letters and functional pearls should be labeled as such on the first page; they may be any length up to the above limit, though shorter submissions are welcome. The accepted papers will initially appear as a University of Utrecht technical report, and subsequently be published as an issue of Electronic Notes in Theoretical Computer Science. Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================ From rossberg@ps.uni-sb.de Wed May 2 18:07:31 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Wed, 02 May 2001 19:07:31 +0200 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF03ED3.754BD3F3@ps.uni-sb.de> John Hughes wrote: > > I think it's important to have a simple model of how many > times expressions are evaluated. Function bodies are clearly > evaluated many times, once for each call, but non-function > bindings should be evaluated at most once to respect > call-by-need semantics. Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From uk1o@rz.uni-karlsruhe.de Wed May 2 23:44:54 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 3 May 2001 00:44:54 +0200 Subject: List of words In-Reply-To: <200105020842.BAA13085@mail4.halcyon.com>; from ashley@semantic.org on Wed, May 02, 2001 at 01:42:55AM -0700 References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <20010503004453.A14362@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:42:55AM -0700, Ashley Yakeley wrote: > At 2001-05-02 01:34, Hannah Schroeter wrote: > >capitalize (c:cs) = toUpper c : cs > >capitalizeList = map capitalize > ...or if you prefer... > capitalizeList :: [String] -> [String] > capitalizeList = map (map toUpper) I understood "capitalize" as toUpper only the *first* character of a string. Your capitalizeList at least isn't denotationally the same as mine. hannahCapitalizeList ["this", "is", "a", "fox"] === ["This", "Is", "A", "Fox"] ashleyCapitalizeList ["this", "is", "a", "fox"] === ["THIS", "IS", "A", "FOX"] Kind regards, Hannah. From erik@meijcrosoft.com Thu May 3 01:57:34 2001 From: erik@meijcrosoft.com (Erik Meijer) Date: Wed, 2 May 2001 17:57:34 -0700 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <006401c0d36c$0af45f90$34b11eac@redmond.corp.microsoft.com> > [...many lines deleted...] > I think it's important to have a simple model of how many times expressions > are evaluated. Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Breaking the monomorphism restriction in ANY case > makes both space and time cost of evaluation unpredictable, and brittle when > program changes elsewhere introduce or remove an implicit parameter. It isn't > good enough to say `the chances are' that a program has, for example, linear > time and constant space complexity: the programmer should be able to convince > himself of such properties. But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. > As far as what one would `expect', it's in the very nature of dynamic binding > that it makes the meaning of an expression depend on its context. I for one > would certainly not expect that inlining a definition bound to such an > expression should preserve its meaning! Inlining changes the context, so > `of course' can change the meaning. So I strongly prefer (B)! > > John Hughes > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From nikhil@acm.org Thu May 3 02:19:57 2001 From: nikhil@acm.org (Rishiyur S. Nikhil) Date: Wed, 02 May 2001 21:19:57 -0400 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF0B23D.B703F8D4@mediaone.net> John Hughes wrote: > ... Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Isn't this a very fragile distinction? It seems so susceptible to routine program transformations by both programmers and compilers (e.g., lambda lifting/unlifting, which can change a non-function finding into a function binding and vice versa). Also, I agree with Andreas Rossberg's observation: > ... the Haskell Report ... does not even > demand call-by-need evaluation (it only speaks of non-strict > semantics). Nikhil From matth@mindspring.com Thu May 3 03:39:13 2001 From: matth@mindspring.com (Matt Harden) Date: Wed, 02 May 2001 21:39:13 -0500 Subject: User defined Ix instances potentially unsafe References: <3AEF660A.87AF9D6C@mindspring.com> Message-ID: <3AF0C4D1.AB12C703@mindspring.com> Matt Harden wrote: > blah, blah, blah, bug in the Library Report, blah, blah... OK, so I failed to read the Library Report. It clearly states: > An implementation is entitled to assume the following laws about these operations: > > range (l,u) !! index (l,u) i == i -- when i is in range > inRange (l,u) i == i `elem` range (l,u) So my "bug" is only in my mind. Sorry for bothering everyone. Regards, Matt From Critterrathman@aol.com Thu May 3 07:54:26 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 02:54:26 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_da.5caeee1.28225aa2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman --part1_da.5caeee1.28225aa2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman --part1_da.5caeee1.28225aa2_boundary-- From simonpj@microsoft.com Thu May 3 08:13:23 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 00:13:23 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> | As far as what one would `expect', it's in the very nature of=20 | dynamic binding that it makes the meaning of an expression=20 | depend on its context. I for one would certainly not expect=20 | that inlining a definition bound to such an=20 | expression should preserve its meaning! Inlining changes the=20 | context, so `of course' can change the meaning. So I strongly=20 | prefer (B)! John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. (For ordinary type classes, the monomorphism restriction will reject some programs that would otherwise be well typed;=20 for implicit parameters, (B) will accept the program but with --- potentially ---- a different meaning.) b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon From rjmh@cs.chalmers.se Thu May 3 08:48:20 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 09:48:20 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030748.JAA05638@muppet30.cs.chalmers.se> But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. I don't buy that. You could equally well say a term with a free variable is a "function" (of the environment): sure it is, but if it's bound with a let then the function is called only once. John From rjmh@cs.chalmers.se Thu May 3 09:02:10 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:02:10 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030802.KAA05827@muppet30.cs.chalmers.se> Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. Well, the Haskell Report may not require call-by-need semantics, but it permits it at least. Without the MR that would not be the case: some programs would *require* call-by-name. Actually I would prefer the report to be much more explicit about both sharing and evaluation order, to enable compiler-independent reasoning about time and space behaviour. As it stands, compilers do in fact implement call-by-need, and so one can in practice reason fairly safely about time behaviour, but they vary in the choice of evaluation order, which makes space leaks come and go on different compilers. In any case, I don't buy the argument that because reasoning about costs is already problematic in Haskell, it doesn't matter if we make it even harder...! > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. I have no faith in compiler warnings. For one thing, they're irritating. For another, you don't see them when it matters -- when you *read* the code. I'd far rather explicitly distinguish call-by-name and call-by-value in the source code (and made a suggestion along these lines some time ago), so that the semantics is visible to all. Of course, we can't forbid the programmer to write inefficient programs. But we can make gross inefficiencies easier or harder to find. Haskell just can't be used in practice unless one tracks down and fixes space leaks. I don't want to be debugging "time leaks" caused by unexpected call-by-name as well! -- Andreas Rossberg, rossberg@ps.uni-sb.de John Hughes From jeff@nwlewis.com Thu May 3 09:12:02 2001 From: jeff@nwlewis.com (Jeffrey R. Lewis) Date: Thu, 03 May 2001 01:12:02 -0700 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF112D2.B0DEBD9A@nwlewis.com> Simon Peyton-Jones wrote: > | As far as what one would `expect', it's in the very nature of > | dynamic binding that it makes the meaning of an expression > | depend on its context. I for one would certainly not expect > | that inlining a definition bound to such an > | expression should preserve its meaning! Inlining changes the > | context, so `of course' can change the meaning. So I strongly > | prefer (B)! > > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. > Certainly a point well worth thinking about... > > > b) That whether or not a definition is unconditionally inlinable > at the source-language level cannot be determined by looking > at the expression. You have to do something rather like effects > analysis: look to see if it calls any function (transitively) that > uses > an implicit parameter. This apparently esoteric effects analysis is called `type inference' ;-) Oh for better programming environments where it's easy to ask questions about the types of things. But the fun thing is, a) that analysis is way too conservative, and b) it is not even necessary in order to actually do the inlining safely. To do the inlining, you have to be careful to observe any `with' bindings that *statically scope* over the location of the inlining, and do some dynamic variable renaming to avoid capture. Yes, this isssue is well worth thinking about from a design decision point of view, but the situation is not as dire as it seems at first sight. --Jeff From rjmh@cs.chalmers.se Thu May 3 09:22:24 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:22:24 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030822.KAA06145@muppet30.cs.chalmers.se> John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. At present, adding a type signature changes both the static semantics and the cost of running a program -- one should already understand that a type signature with a non-empty context means the expression is evaluated at its uses rather than at its definition. Given that one understands that, and that an expression which uses an implicit parameter will have a type signature which explicitly indicates that, I don't think this is really such a big deal. b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon Are you sure this second one really holds? I claim the effects analysis is just type inference! If the expression has a context referring to an implicit parameter, then it cannot be unconditionally inlined -- it's as simple as that, isn't it? Admittedly, this really only solves the problem for the compiler -- the poor programmer may have more trouble doing type inference in his head. (How much easier life would be with = for call-by-name, := for call-by-need...) So maybe not so dire as you made out! John From ashley@semantic.org Thu May 3 09:57:33 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 3 May 2001 01:57:33 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105030857.BAA20037@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >| In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: >| >| class X a b | a -> b where x :: a; >| class (X a b) => Y a b | a -> b where y :: a; >| instance (X a b) => Y a b where y = x; >| instance (Num a) => X a a where x = 0; -- line A > >Quite right too! The final instance declaration says that the two >arguments of X must always be the same: Hmm... > * the class says a->b Yes. > * the instance matches any first arg I was rather hoping that the instance would match only (Num a => a) rather than (a). > and says that the second must be equal. Yes. -- Ashley Yakeley, Seattle WA From qrczak@knm.org.pl Thu May 3 09:15:06 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 08:15:06 GMT Subject: Existential Type Declarations in Hugs References: Message-ID: Thu, 3 May 2001 02:54:26 EDT, Critterrathman@aol.com pisze: > class Shape a where > getx :: a -> Int > setx :: a -> Int -> a > > data ExistentialShape = > forall a. Shape a => MakeExistentialShape a > > instance Shape ExistentialShape where > getx (MakeExistentialShape a) = getx a > setx (MakeExistentialShape a) newx = setx a newx Should be: setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a newx) The result of setx must have the same type as its first argument. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Thu May 3 09:42:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:42:10 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E99@red-msg-09.redmond.corp.microsoft.com> | In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: |=20 | class X a b | a -> b where x :: a; | class (X a b) =3D> Y a b | a -> b where y :: a; | instance (X a b) =3D> Y a b where y =3D x; | instance (Num a) =3D> X a a where x =3D 0; -- line A Quite right too! The final instance declaration says that the two arguments of X must always be the same: * the class says a->b * the instance matches any first arg and says that the second must be equal. So when typechecking the instance for Y a b, a and b are forced to be equal, and that's less general than the instance claims to be. Simon From simonpj@microsoft.com Thu May 3 09:37:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:37:22 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> | a) That adding a type signature can change the dynamic semantics | of the program. This would be the first and only=20 | occurrence of | such behaviour. |=20 | At present, adding a type signature changes both the static=20 | semantics and the cost of running a program=20 That's true: but adopting (B) means that adding a type signature may cause the program to print a different answer! That seems qualitiatively different to giving the same answer only slower or faster; or rejecting the program altogether. Type signatures should specialise a type -- which means that efficiency may increase, or that the program may no longer be typable, but surely it shouldn't change the answer! =20 | Are you sure this second one really holds? I claim the=20 | effects analysis is just type inference!=20 Indeed it is. I just don't want programmers to have to do type=20 inference in their heads to figure out the meaning of the program. Simon From lennart@mail.augustsson.net Thu May 3 10:33:40 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 05:33:40 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF125F4.E967A796@mail.augustsson.net> Simon Peyton-Jones wrote: > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. Not so, there are already Haskell program that give a different results with and without type signatures. -- Lennart From lennart@mail.augustsson.net Thu May 3 11:29:35 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 06:29:35 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF1330E.B383F42C@mail.augustsson.net> Simon Peyton-Jones wrote: > | a) That adding a type signature can change the dynamic semantics > | of the program. This would be the first and only > | occurrence of > | such behaviour. > | > | At present, adding a type signature changes both the static > | semantics and the cost of running a program > > That's true: but adopting (B) means that adding a type signature > may cause the program to print a different answer! That seems > qualitiatively different to giving the same answer only slower or > faster; > or rejecting the program altogether. Type signatures should specialise > a type -- which means that efficiency may increase, or that the program > may > no longer be typable, but surely it shouldn't change the answer! Try this program: -- Try commenting out this type signature. fun :: (Num a) => a -> Int fun 0 = if fun 1 == 1 then fun 2 else fun (3::Int) g :: (a -> b) -> b g f = f undefined ii = g fun class C a where m :: a -> String instance C Int where m _ = "You have a type signature" instance C Integer where m _ = "You forgot the type signature" main = putStrLn (m ii) -- Lennart PS. There are better examples, but this was all I could think of right now. From qrczak@knm.org.pl Thu May 3 12:50:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 11:50:47 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > Try this program: > -- Try commenting out this type signature. > fun:: (Num a) => a -> Int Test.hs:7: Ambiguous type variable(s) `a' in the constraint `Num a' arising from use of `fun' at Test.hs:7 In the first argument of `g', namely `fun' In the definition of `ii': g fun Test.hs:18: Ambiguous type variable(s) `a' in the constraint `C a' arising from use of `m' at Test.hs:18 In the first argument of `putStrLn', namely `(m ii)' In the definition of `main': putStrLn (m ii) Defaulting applies only when all classes involved are Haskell 98. hbc, nhc98 and Hugs are not conforming. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From lennart@mail.augustsson.net Thu May 3 13:07:10 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 08:07:10 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: <3AF149EE.3C252258@mail.augustsson.net> Marcin 'Qrczak' Kowalczyk wrote: > Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > > Test.hs:7: > Ambiguous type variable(s) `a' in the constraint `Num a' > arising from use of `fun' at Test.hs:7 > In the first argument of `g', namely `fun' > In the definition of `ii': g fun > > Test.hs:18: > Ambiguous type variable(s) `a' in the constraint `C a' > arising from use of `m' at Test.hs:18 > In the first argument of `putStrLn', namely `(m ii)' > In the definition of `main': putStrLn (m ii) > > Defaulting applies only when all classes involved are Haskell 98. First, I cannot parse that sentence, but I assume you mean when all classes are Prelude classes. Second, I'm pretty sure we all agreed that this was a silly rule and should not be in the Haskell definition. I was certain that that it had been removed from the Haskell report, but I guess not. (hbc used to make this check, but I removed it when everyone seemed to agree that rule was a bad idea). Third, moving ii to a different module might still exhibit this problem. (I'm not sure how ghc defaults exported definitions.) But most importantly, this was a bad example. There was a much better one posted on this mailing list a while ago. Does anyone remember it? -- Lennart > > hbc, nhc98 and Hugs are not conforming. From fst@informatik.uni-kiel.de Thu May 3 13:09:01 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Thu, 3 May 2001 14:09:01 +0200 Subject: WFLP 2001 - Final Call for Papers Message-ID: <200105031209.OAA02408@listrac.informatik.uni-kiel.de> ====================================================================== FINAL CALL FOR PAPERS WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming comprising the 10th International Workshop on Functional and Logic Programming and 16th Workshop on Logic Programming Kiel, Germany September 13-15, 2001 ====================================================================== NEW: * Submission guidelines for electronic submissions * Special issue of ENTCS (Electronic Notes in Theoretical Computer Science) for selected papers ---------------------------------------------------------------------- GENERAL WFLP 2001 is the combination of two workshops of a successful series of annual workshops on declarative programming. The international workshops on functional and logic programming aimed at bringing together researchers interested in functional programming, logic programming, as well as their integration. Previous workshops have been held in Benicassim (Spain), Grenoble (France), Bad Honnef (Germany). The workshops on (constraint) logic programming are the annual meeting of the Society of Logic Programming (GLP e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases and artificial intelligence. Previous workshops have been held in Germany, Austria and Switzerland. In this year both workshops will be jointly organized in order to promote the cross-fertilizing exchange of ideas and experiences among researches and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The technical program of the workshop will include invited talks, presentations of refereed papers and demo presentations. The WWW page of the workshop is: http://www.informatik.uni-kiel.de/~wflp2001 ---------------------------------------------------------------------- TOPICS The topics of interest include (but are not limited to): * Functional programming * Logic programming * Constraint programming * Deductive databases * Extensions of declarative languages, objects * Multi-paradigm declarative programming * Foundations, semantics, nonmonotonic reasoning, dynamics * Parallelism, concurrency * Program analysis, abstract interpretation * Program transformation, partial evaluation, meta-programming * Specification, verification, declarative debugging * Knowledge representation, machine learning * Implementation of declarative languages * Advanced programming environments and tools * Applications The primary focus is on new and original research results but submissions describing innovative products, prototypes under development or interesting experiments (e.g., benchmarks) are also encouraged. ---------------------------------------------------------------------- IMPORTANT DATES Submission of papers: May 15, 2001 Notification of acceptance: June 20, 2001 Camera-ready papers: July 20, 2001 Workshop: September 13 - 15, 2001 ---------------------------------------------------------------------- SUBMISSION Authors are invited to submit an extended abstract (no longer than 10 pages including figures and references) or a system description (no longer than 3 pages) in postscript format (11pt) before May 15, 2001. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. *NEW* The details about the procedure to submit papers electronically are described on the workshop website. If you have any problems with submitting papers, please send an email to wflp2001@informatik.uni-kiel.de. ---------------------------------------------------------------------- BEST NEWCOMER AWARD An award will be given to the best paper exclusively written by one or several young researchers who have not yet obtained their PhD degrees. Papers written in this category should be clearly marked "Student papers" in the submission. ---------------------------------------------------------------------- PROCEEDINGS The proceedings with the full versions of all accepted contributions (no longer than 15 pages for regular contributions and 3 pages for system descriptions) will be published as a Technical Report of the University of Kiel. *NEW* A special issue of ENTCS (Electronic Notes in Theoretical Computer Science) containing revised versions of high-quality contributions will be organized after the workshop. ---------------------------------------------------------------------- PROGRAM The workshop will be a 3-day event including presentations of the accepted papers, system demos, and INVITED TALKS by Peter Van Roy (Catholic University of Louvain) Thomas Arts (Ericsson) ---------------------------------------------------------------------- LOCATION WFLP 2001 will take place at the Christian-Albrechts-University of Kiel. More details about the accomodation, traveling information, etc., will be available at the WFLP 2001 WWW page at http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- CONTACT WFLP 2001 Prof. Michael Hanus Institut fuer Informatik und Praktische Mathematik Christian-Albrechts-Universitaet Kiel Olshausenstr. 40 D-24098 Kiel, Germany Phone: ++49-(0)431-880-7271 or -7270 (Secr.) Fax : ++49-(0)431-880-7613 Email: wflp2001@informatik.uni-kiel.de WWW: http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- PROGRAM COMMITTEE Slim Abdennadher (LMU Muenchen) Maria Alpuente (UP Valencia) Sergio Antoy (Portland State University) Christoph Beierle (FernUniv. Hagen) Alexander Bockmayr (Univ. Henri Poincare, Nancy) Harold Boley (DFKI Kaiserslautern) François Bry (LMU Muenchen) Juergen Dix (Univ. Koblenz) Rachid Echahed (IMAG, Grenoble) Uwe Egly (TU Wien) Moreno Falaschi (Univ. Udine) Burkhard Freitag (Univ. Passau) Thom Fruehwirth (LMU Muenchen) Norbert E. Fuchs (Univ. Zuerich) Ulrich Geske (GMD-FIRST Berlin) Michael Hanus (CAU Kiel) Herbert Kuchen (Univ. Muenster) Juan Jose Moreno Navarro (UP Madrid) Mario Rodriguez-Artalejo (UC Madrid) Dietmar Seipel (Univ. Wuerzburg) ---------------------------------------------------------------------- LOCAL ORGANIZING COMMITTEE Wolfgang Goerigk Michael Hanus Klaus Hoeppner Ulrike Pollakowski-Geuther Friedemann Simon Frank Steiner ---------------------------------------------------------------------- From C.Reinke@ukc.ac.uk Thu May 3 13:19:49 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:19:49 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from "Marcin 'Qrczak' Kowalczyk" of "03 May 2001 11:50:47 GMT." Message-ID: > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > Defaulting applies only when all classes involved are Haskell 98. > hbc, nhc98 and Hugs are not conforming. Seems you're right (all classes for the ambiguous type variable need to be from prelude or standard libraries). Okay, so let's try the good old boring show: -- ii :: Double ii = 1 main = case length (show ii) of { 1 -> putStrLn "type signature excluded" ; _ -> putStrLn "type signature included" } Still, I liked Lennart's "magic" version;-) Claus From rossberg@ps.uni-sb.de Thu May 3 13:23:27 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Thu, 03 May 2001 14:23:27 +0200 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: <3AF14DBF.24C85EF1@ps.uni-sb.de> Lennart Augustsson wrote: > > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? No, but this should do it: data T = T Int instance Show T where show (T n) = show n instance Eq instance Num T where fromInteger n = T n (+) (T _) (T _) = T 0 x :: T -- try removing this type signature x = 1 + 2 main = putStr (show x) - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From C.Reinke@ukc.ac.uk Thu May 3 13:31:01 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:31:01 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > > > Try this program: > > > -- Try commenting out this type signature. > > > fun:: (Num a) => a -> Int > > Defaulting applies only when all classes involved are Haskell 98. > > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. (hbc used > to make this check, but I removed it when everyone seemed to > agree that rule was a bad idea). http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-bugs.html (Could it be made more prominent on www.haskell.org that this Haskell98 bugs list is indeed part of Simon's ongoing, soon to be completed revision of the two reports? Just so that people like me notice that the revised reports take priority over whatever the current ones say..) Page 49, Section 4.3.4, Ambiguous Types... In the third paragraph from the end of Section 4.3.4, replace "...an ambiguous type variable is defaultable if at least one of its classes is a numeric class..." by "...an ambiguous type variable, v, is defaultable if v appears only in constraints of the form (C v), where C is a class, and if at least one of its classes is a numeric class...". The new phrase is "if v appears only in constraints of the form (C v) where C is a class". Without this condition the rest of the sentence does not make sense. Claus From qrczak@knm.org.pl Thu May 3 13:48:39 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 12:48:39 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: Thu, 03 May 2001 08:07:10 -0400, Lennart Augustsson pisze: > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. Not only Prelude but the whole Haskell 98 standard library. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. It was not removed, it's still in . So probably it should be removed now: SimonPJ wanted to freeze the revised report in May. > Third, moving ii to a different module might still exhibit this problem. Indeed. > (I'm not sure how ghc defaults exported definitions.) I'm sure that it works as it should: they are defaulted according to visible definitions, to Int or Integer here, and from another module it is not known that the types have been ambiguous, so constraints from non-Haskell-98 classes can't stop the defaulting. This is an argument for removing that part of the defaulting rule. Or for removing the monomorphism restriction. Or both. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From C.Reinke@ukc.ac.uk Thu May 3 14:46:44 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 14:46:44 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? > > -- Lennart Perhaps I should mention a useful application of this game, somewhat unhelpfully named "Representative thingies" in my Haskell corner: http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/ Load the file R.hs in your favourite Hugs (Hugs mode), and you'll see things like this (see comments in R.hs for more examples): Main> foldl (+) 0 [1..4] :: Int 10 Main> foldr (+) 0 [1..4] :: Int 10 Main> foldl (+) 0 [1..4] ((((0 + 1) + 2) + 3) + 4) Main> foldr (+) 0 [1..4] (1 + (2 + (3 + (4 + 0)))) Well, I found it useful (and fun; just a pity that you can't overload (implicit) application in Haskell;-).. Claus From augustss@augustsson.net Thu May 3 15:24:22 2001 From: augustss@augustsson.net (Lennart Augustsson) Date: Thu, 3 May 2001 10:24:22 -0400 (EDT) Subject: Implict parameters and monomorphism Message-ID: <200105031424.f43EOMq11179@hobbessandburst.com> OK, so since noone liked my original example here's another one. It involves no defaulting and no classes in the funny function definition. -- Here's the type signature that makes a difference. --fun :: a -> Char fun x = const (fun x) (fun True) fix f = let x = f x in x class C a where m :: a -> String instance C Char where m _ = "has signature" instance C Bool where m _ = "no signature" main = putStrLn (m (fix fun)) It is not at all surprising that you can write this. Originally type signatures only allowed you to put a signature that was more specific. Polymorhic recursion on the other hand allows you to make the type more general by putting a type signature on a definition. Combining these you can make the signature be incomparable to the deduced type. Using the class system you can then dispatch on the type and get different behaviour. -- Lennart From qrczak@knm.org.pl Thu May 3 16:04:17 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 15:04:17 GMT Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: Wed, 2 May 2001 10:51:58 +0200 (MET DST), John Hughes pisze: > Breaking the monomorphism restriction in ANY case makes both space > and time cost of evaluation unpredictable, and brittle when program > changes elsewhere introduce or remove an implicit parameter. You can always use 'case' instead of 'let' for variable bindings. I would remove the monomorphism restriction, leaving 'let' mostly for function-like bindings, which can be optimized to value bindings in some cases. Perhaps it would be good to introduce strictness annotations in 'let' and 'where'. Clean has 'let!'. It would allow increasing strictness yet more than 'case' does, without the need of transforming 'let' into 'case' or adding `seq`. I would attach '!' to individual variables (or patterns) rather than to 'let', so it's usable in 'where', 'case' and function arguments, with some bindings strict and others lazy. The semantics would insert var `seq` at the start of the appropriate body or rhs for each strict-marked var, in unspecified order (it doesn't matter in what order they are evaluated, it matters that all are evaluated). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 (EDT) Subject: FINAL CFP: SAIG'01 In-Reply-To: References: Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 Subject: FINAL CFP: SAIG'01 In-Reply-To: References: Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From Critterrathman@aol.com Thu May 3 22:20:06 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 17:20:06 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_cd.61a8300.28232586_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time, qrczak@knm.org.pl writes: > Should be: > setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a > newx) > The result of setx must have the same type as its first argument. > Thanks. That solves my problem. BTW, what is this "Skolem constant" that's referred to in the error message that I received? Chris Rathman --part1_cd.61a8300.28232586_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time, qrczak@knm.org.pl writes: Should be: setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a newx) The result of setx must have the same type as its first argument. Thanks. That solves my problem. BTW, what is this "Skolem constant" that's referred to in the error message that I received? Chris Rathman --part1_cd.61a8300.28232586_boundary-- From reid@cs.utah.edu Thu May 3 22:26:38 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Thu, 3 May 2001 15:26:38 -0600 Subject: Implict parameters and monomorphism In-Reply-To: Message-ID: > You can always use 'case' instead of 'let' for variable bindings. Except, of course, for top level bindings which is where the monomorphism restriction is usually most noticable. > I would remove the monomorphism restriction, [...] This seems to be a pretty common sentiment but I don't see anyone pointing out that the monomorphism restriction is there for _two_ reasons: 1) The performance issues that are currently getting all the attention. 2) Preventing ambiguity in examples like: [(n,s)] = reads t where the value of "s" (whose type is String) is determined by the type of "n". This example comes from the H'98 report, section 4.5.5 "The Monomorphism Restriction". Unless I missed something, reason (2) prevents us from completely getting rid of the restriction even if we are willing to ignore (1). (Though if our only goal was to solve (2), it may be that the rule could be a lot less restrictive.) -- Alastair Reid From mark@chaos.x-philes.com Thu May 3 22:33:32 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Thu, 3 May 2001 17:33:32 -0400 (EDT) Subject: Existential Type Declarations in Hugs In-Reply-To: Message-ID: On Thu, 3 May 2001 Critterrathman@aol.com wrote: (snip) > BTW, what is this "Skolem constant" that's referred to in the error message > that I received? A combination of http://www.sdsc.edu/~tbailey/teaching/cse151/lectures/chap09a.html and http://cs.wwc.edu/~aabyan/Logic/normal.html may answer that for you. (-: (It was too long ago now for me to remember much, and I'm not sure where my notes are, so I daren't attempt an explanation myself!) -- Mark From qrczak@knm.org.pl Thu May 3 23:23:19 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 22:23:19 GMT Subject: Implict parameters and monomorphism References: Message-ID: Thu, 3 May 2001 15:26:38 -0600, Alastair Reid pisze: >> You can always use 'case' instead of 'let' for variable bindings. > > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. > Unless I missed something, reason (2) prevents us from completely > getting rid of the restriction even if we are willing to ignore (1). Ok. Let's keep (2) and remove (1). ghc -fno-monomorphism-restriction allows polymorphis cases like (2) and they do create ambiguous types like Read a => String. I would treat it as a bug: removing monomorphism restriction should not go that far. Haskell 98 doesn't allow removing it for pattern bindings by supplying a type signature. Here is a crazy idea: either of these ~x = ... x@_ = ... creates a pattern binding, so it's a way of writing it without a type signature if there was no monomorphic restriction :-) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@launchbury.org Thu May 3 22:33:44 2001 From: john@launchbury.org (John Launchbury) Date: Thu, 03 May 2001 14:33:44 -0700 Subject: Implict parameters and monomorphism References: <200105030802.KAA05827@muppet30.cs.chalmers.se> Message-ID: <3AF1CEB8.A992F053@launchbury.org> This whole monomorphism-restriction debate was one that we had when we were writing the implicit parameters paper. We noted the dire impact of the monomorphism restriction, and commented upon it. On reviewing the whole issue again I am forced again to conclude: There Is No Satisfactory Solution. At least not in Haskell as it is at the moment. Again and again I have been forced to conclude, the only thing worse than having the monomorphism restriction is not having the monomorphism restriction. John's point about evaluation sharing is absolutely critical. We have to be able to distinguish between linear and exponential code, and not have the compiler switch from one to the other unpredictably. On the other hand, as Simon points out, having the MR changing program behavior silently is just as bad. And despite Lennart's comment, the situation is Much Worse with implicit parameters than with type classes. Aaarghh!! So what to do? As a quick fix we should just pick one of A, B or C. Maybe A is the right one, prohibiting the problematical situation from arising at all. For the long term, this issue provides strong supporting evidence for John H's suggestion of having two kinds of binding: the by-name binding has generalization (polymorphism, type classes, implicit parameters etc); and by need, without generalization (monomorphic). As a meta comment: it would be good to hear from people who have made extensive use of implicit parameters, to find out how they are really used in practice. This can often provide quite surprising input. For example, in the original paper we argued that implicit bindings should not be recursive, because we expected a certain style of use would be quite common. Now is seems that other usage styles are more common, for which recursive bindings may be better. Oh well. John From rjmh@cs.chalmers.se Fri May 4 08:27:51 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Fri, 4 May 2001 09:27:51 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105040727.JAA26061@muppet30.cs.chalmers.se> > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. This is a matter of taste, and Haskell deliberately supports both a style with and without type signatures on top-level bindings. I'd be sorry to see that change. One good reason for NOT giving inferrable type signatures is that including them makes programs less modifiable: a small local change, such as adding a parameter to a type, may force a large number of consequential changes to type signatures. I've seen cases where programmers refrained from a significant improvement, because of the labour required to update type signatures (which had been included, ironically, to disable the monomorphism restriction!). I'm not saying it's bad to give type signatures, just that there are arguments for both styles, and the language ought not to make either one difficult to use. John From qrczak@knm.org.pl Fri May 4 11:40:34 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 10:40:34 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, > such as adding a parameter to a type, may force a large number of > consequential changes to type signatures. Type synonyms should make this easier. Maybe the language should be improved somewhere here: class context synonyms? unbound type variables on the rhs of type synonyms? specifying parts of a type leaving the rest inferred? These problems shouldn't arise for ensuring evaluation once, where the type is usually monomorphic! It's the other way around which can cause trouble (e.g. there are no class context synonyms). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Fri May 4 11:40:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 4 May 2001 03:40:53 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Now that is a *really* amazing example. I had no idea that polymorphic recursion would do this. =20 I withdraw my claim that a type signature can't change the answer. But I'm worried. Simon | -----Original Message----- | From: Lennart Augustsson [mailto:augustss@augustsson.net]=20 | Sent: 03 May 2001 15:24 | To: C.Reinke@ukc.ac.uk; qrczak@knm.org.pl | Cc: haskell@haskell.org | Subject: Re: Implict parameters and monomorphism |=20 |=20 | OK, so since noone liked my original example here's another=20 | one. It involves no defaulting and no classes in the funny=20 | function definition. |=20 | -- Here's the type signature that makes a difference. | --fun :: a -> Char | fun x =3D const (fun x) (fun True) |=20 | fix f =3D let x =3D f x in x |=20 | class C a where | m :: a -> String |=20 | instance C Char where | m _ =3D "has signature" |=20 | instance C Bool where | m _ =3D "no signature" |=20 | main =3D putStrLn (m (fix fun)) |=20 |=20 | It is not at all surprising that you can write this. =20 | Originally type signatures only allowed you to put a=20 | signature that was=20 | more specific. | Polymorhic recursion on the other hand allows you to make the=20 | type more general by putting a type signature on a=20 | definition. Combining these you can make the signature be=20 | incomparable to the deduced type. Using the class system you=20 | can then dispatch on the type and get different behaviour. |=20 | -- Lennart |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From igloo@earth.li Fri May 4 15:20:02 2001 From: igloo@earth.li (Ian Lynagh) Date: Fri, 4 May 2001 15:20:02 +0100 Subject: Unicode and is* Message-ID: <20010504152002.A14500@stu163.keble.ox.ac.uk> Hi all Is there a reason why isUpper and isLower include all unicode characters of the appropriate class but isDigit is only 0..9? Are there any Haskell unicode libraries around? And is the implementation of unicode support for GHC being discussed/developed anywhere? BTW, The comments in the report (primUnicodeIsUpper -- 'A'..'Z') are also misleading. Thanks Ian From qrczak@knm.org.pl Fri May 4 16:50:37 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 15:50:37 GMT Subject: Unicode and is* References: <20010504152002.A14500@stu163.keble.ox.ac.uk> Message-ID: Fri, 4 May 2001 15:20:02 +0100, Ian Lynagh pisze: > Is there a reason why isUpper and isLower include all unicode > characters of the appropriate class but isDigit is only 0..9? There are also other weirdnesses, e.g. isSpace is specified to work only on ISO-8859-1 spacing characters, and caseless letters are considered uppercase. > Are there any Haskell unicode libraries around? http://www.sourceforge.net/projects/qforeign/ It provides module Char replacement with more full character properties, charset conversion framework, and inefficient IO wrapper with transparent conversion of Handle data. It also provides FFI support, but it's almost the same as in ghc-5.00 now, except that string conversion between C and Haskell takes character encoding into account. It's undocumented except some comments, sorry. QForeign works with ghc >= 4.08 and nhc98 >= 1.01, but depends on Unicode support in the compiler: some bits are disabled when the compiler doesn't support character literals above '\255' (i.e. nhc98 compiled with ghc < 5.00 and probably with itself), the whole Unicode story is disabled when Char has 8 bits (i.e. ghc < 5.00). > And is the implementation of unicode support for GHC being > discussed/developed anywhere? I'm afraid they are not discussed. I received no feedback on Unicode features in qforeign. They are experimental; nobody told me that they are good or wrong, or how to design them better. They are changing very slowly now. I think they will find their way to ghc when they are finished (with total reimplementation of IO, integrating the conversion with buffering, and also using the new FFI), but it would be great if they represented some consensus rather than my thoughts alone. For example I don't like the HsAndC variant of implmenetation of a conversion (ConvBase), but some tests suggest that it's really best to use a Haskell implementation of UTF-32 when called from Haskell and a C implementation when called to work on character arrays, so I don't know how to do it more clearly. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From elf@sandburst.com Fri May 4 19:12:13 2001 From: elf@sandburst.com (Mieszko Lis) Date: Fri, 4 May 2001 14:12:13 -0400 Subject: Implict parameters and monomorphism In-Reply-To: <200105040727.JAA26061@muppet30.cs.chalmers.se>; from rjmh@cs.chalmers.se on Fri, May 04, 2001 at 09:27:51AM +0200 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504141213.E12269@sandburst.com> On Fri, May 04, 2001 at 09:27:51AM +0200, John Hughes wrote: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, such as > adding a parameter to a type, may force a large number of consequential > changes to type signatures. Absolutely -- suppose you add a `trace' somewhere in your program, which conjures up a Show constraint everywhere... -- Mieszko From john@foo.net Fri May 4 19:27:07 2001 From: john@foo.net (John Meacham) Date: Fri, 4 May 2001 11:27:07 -0700 Subject: Implict parameters and monomorphism In-Reply-To: ; from qrczak@knm.org.pl on Fri, May 04, 2001 at 10:40:34AM +0000 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504112707.A474@mark.ugcs.caltech.edu> I have thought about this too. omission of type signatures seems to be an effective catalyst for code re-use yet this benefit is rarely emphasised. I was thinking about ways to make it easier and toyed around with allowing 'unkowns' in type declarations to allow you to specify only the important part of what you want in a type signature without having to over-specify the types. My idea was to allow '_' to be used in type signatures and represent any type. foo s = 4 foo :: _ foo :: _ -> Int foo :: String -> _ foo :: String -> Int would all be valid types (with different meanings) for 'foo'. This would be useful if say, you had to specify a function returned a plain Int to resolve ambiguity but you didn't want to specify the type of the input argument, perhaps because you are in the process of writing/debugging code and know the type will change. this has the nice generalization that all undeclared types are taken to be ':: _' note that this is not universal quantification because that would imply any type will work, where in actuality we just want to use the specific type infered via standard type inference for part of the declaration and specify exactly another part. The reason I didn't make the proposal was because I am not sure how useful such a thing would be in production code, even though there have been many times during the development/discovery process when such a feature would have signifigantly eased incremental development. John On Fri, May 04, 2001 at 10:40:34AM +0000, Marcin 'Qrczak' Kowalczyk wrote: > Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > > > One good reason for NOT giving inferrable type signatures is that > > including them makes programs less modifiable: a small local change, > > such as adding a parameter to a type, may force a large number of > > consequential changes to type signatures. > > Type synonyms should make this easier. Maybe the language should > be improved somewhere here: class context synonyms? unbound type > variables on the rhs of type synonyms? specifying parts of a type > leaving the rest inferred? > > These problems shouldn't arise for ensuring evaluation once, where > the type is usually monomorphic! It's the other way around which can > cause trouble (e.g. there are no class context synonyms). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 4 19:50:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 18:50:30 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: Fri, 4 May 2001 11:27:07 -0700, John Meacham pisze: > My idea was to allow '_' to be used in type signatures and represent > any type. I like it. There were also proposals for '..'. It would be useful in cases analogous to this: import IArray import MArray f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do marr <- thaw arr do some stateful operations on marr freeze marr) where the type of thaw and freeze make the mutable array type ambiguous. A type signature to disambiguate it would have to mention element and index types, which are type variables bound outside, and the state token, which is eaten by runST. So you have to either use a ghc/Hugs extension of pattern or result type signatures, to bind all these types to names, and move the body to a separate function, so the state token is visible - or specify a polymorphic function type signature on freeze alone or use a specialized variant of freeze. It would be nice to write just (marr :: STArray _ _ _) without having to invent types for the state, index and element. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From nr@eecs.harvard.edu Fri May 4 20:02:25 2001 From: nr@eecs.harvard.edu (Norman Ramsey) Date: Fri, 4 May 2001 15:02:25 -0400 Subject: Help wanted with hugs error message Message-ID: <200105041902.PAA06505@labrador.eecs.harvard.edu> I am compiling the following inoffensive source file, dubbed finterp.lhs: '''Interpreter for factors''' > module FactorInterp where > import Ast (Sym) > import Value () > import Factor > result = "*" > exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Hugs reports: ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import But there is no explicit `exp' in any of my other modules: : nr@labrador 1337 ; grep -w exp *.lhs finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Can anyone help me to find an expunge this error? Thanks, Norman From Robert.Ennals@cl.cam.ac.uk Fri May 4 20:06:23 2001 From: Robert.Ennals@cl.cam.ac.uk (Robert Ennals) Date: Fri, 04 May 2001 20:06:23 +0100 Subject: Help wanted with hugs error message In-Reply-To: Your message of Fri, 04 May 2001 15:02:25 -0400. <200105041902.PAA06505@labrador.eecs.harvard.edu> Message-ID: [snip] > Hugs reports: > > ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import > > > But there is no explicit `exp' in any of my other modules: > > : nr@labrador 1337 ; grep -w exp *.lhs > finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] > > > Can anyone help me to find an expunge this error? [snip] "exp" is defined as exponentiation, as part of the "Floating" type class in the standard Prelude - which is imported by default. -Rob From qrczak@knm.org.pl Fri May 4 20:56:24 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 19:56:24 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: 4 May 2001 18:50:30 GMT, Marcin 'Qrczak' Kowalczyk pisze: > f :: (IArray a e, Ix i) => a i e -> a i e > f arr = runST (do > marr <- thaw arr > do some stateful operations on marr > freeze marr) Actually using pattern type signatures alone is almost enough here: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) except that ghc has a small bug: pattern type signatures don't introduce type variables in the 'do' notation, as they do in lambda arguments. Rewriting it to use '>>=' and lambdas instead of 'do' helps: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST ( thaw arr >>= \(marr :: STArray s i e) -> do some stateful operations on marr >> freeze marr) But doesn't solve completely. There is a strange error message "Could not deduce `MArray (STArray s1) e (ST s)' from the context (IArray a e, Ix i)" with two suggested resolutions, both bogus. The problem is with 's': it's not bound by lambda but eaten by runST. I have to move the argument of runST to a separate function, to bind 's' in its result type signature, to be able to use it in the pattern type signature of marr. This situation can be improved. There was a discussion three months ago about making pattern and result type signatures one-way matching. Currently if a part of the type of an argument is not a type variable bound at the given place, I can't write a type variable in the appropriate pattern type signature, but must spell the inferred type. Except that its context is not written. For example changing 'e' in the type of f above into 'Int' makes the type signature on marr illegal: I must write 'STArray s i Int' too. This is especially tricky in the presence of fundeps, because whether a type is fully determined is not necessarily obvious if it's deduced from fundeps. Ghc requires the programmer to manually follow fundeps to infer the same amount that ghc knows, instead of specifying just the part of the type I am interested in. Another bad case is above. The problematic type is not bound by the given lambda, it's not a constant, and it's not bound by a pattern outside either. It's a free type variable of the argument of runST, eaten by runST. There is no way to write it except by moving the body of runST to a separate function with a result type signature. I would like to make pattern and result type signatures one-way matching, like in OCaml: a type variable just gives a name to the given part of the type, without constraining it any way - especially without "negative constraining", i.e. without yielding an error if it will be known more than that it's a possibly constrained type variable... SimonPJ sais he agreed and asked Hugs people what they think, and they didn't reply. This reminds me the 'with' story :-( This change, together with fixing pattern type signatures in 'do', would make the function at the top legal. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Fri May 4 21:10:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 20:10:30 GMT Subject: Help wanted with hugs error message References: Message-ID: Fri, 04 May 2001 20:06:23 +0100, Robert Ennals pisze: > "exp" is defined as exponentiation, as part of the "Floating" > type class in the standard Prelude - which is imported by default. And to fix the problem you may do either of these: * import Prelude hiding (exp) * Use FactorInterp.exp everywhere except the definition. * Choose a different name. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jans@numeric-quest.com Fri May 4 17:10:03 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Fri, 4 May 2001 12:10:03 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer Message-ID: Hoping to get some early feedback I am posting this very preliminary version: http://www.numeric-quest.com/haskell/QuantumComputer.html Jan From Michael.Fliegner@hansenet.de Fri May 4 23:51:41 2001 From: Michael.Fliegner@hansenet.de (Michae Fliegner) Date: Sat, 5 May 2001 00:51:41 +0200 Subject: Question: Hugs as Browser Plug In Message-ID: <01C0D4FD.B0E165F0@GATEWAY> I have - or at least dreamt I had - read about using Hugs as a Netscape Plug In, but can't find that anymore. Any hints - positive or negative? thanks in advance Michael FLiegner From Erik Meijer" Message-ID: <000a01c0d521$a2f9f0a0$0100a8c0@mshome.net> In the good old days, you could use Hugs as a IE scripting engine, but that is not supported anymore. ----- Original Message ----- From: "Michae Fliegner" To: Sent: Friday, May 04, 2001 3:51 PM Subject: Question: Hugs as Browser Plug In > I have - or at least dreamt I had - read about using Hugs as a Netscape > Plug In, but can't find that anymore. Any hints - positive or negative? > > thanks in advance > Michael FLiegner > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From ashley@semantic.org Sat May 5 07:52:40 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Fri, 4 May 2001 23:52:40 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105050652.XAA19806@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >Quite right too! OK, I understand it a bit better now. This code does not compile: -- class X a instance X Bool instance (Num a) => X a -- Can someone explain why the two instances overlap, given that Bool is not an instance of Num? Would it be possible for Haskell to figure out this sort of thing and not complain about it, or would that lead to nasty problems? -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 09:48:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 5 May 2001 18:48:18 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <3AF0C4D1.AB12C703@mindspring.com> References: <3AEF660A.87AF9D6C@mindspring.com> <3AF0C4D1.AB12C703@mindspring.com> Message-ID: <20010505184818.A6194@hg.cs.mu.oz.au> On 02-May-2001, Matt Harden wrote: > Matt Harden wrote: > > > blah, blah, blah, bug in the Library Report, blah, blah... > > OK, so I failed to read the Library Report. It clearly states: > > > An implementation is entitled to assume the following laws about these operations: > > > > range (l,u) !! index (l,u) i == i -- when i is in range > > inRange (l,u) i == i `elem` range (l,u) > > So my "bug" is only in my mind. Sorry for bothering everyone. I don't think it's quite as straight-forward as that. Hugs and ghc may conform to the Library Report, but the behaviour is still undesirable, and IMHO should be fixed. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From Jon.Fairbairn@cl.cam.ac.uk Sat May 5 11:21:10 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Sat, 05 May 2001 11:21:10 +0100 Subject: Anomalous Class Fundep Inference In-Reply-To: Your message of "Fri, 04 May 2001 23:52:40 PDT." <200105050652.XAA19806@mail4.halcyon.com> Message-ID: <29591.989058070@cl.cam.ac.uk> Ashley Yakeley wrote > OK, I understand it a bit better now. This code does not compile: > -- > class X a > instance X Bool > instance (Num a) =3D> X a > -- > Can someone explain why the two instances overlap, given that Bool is n= ot = > an instance of Num? > = > Would it be possible for Haskell to figure out this sort of thing and n= ot = > complain about it, or would that lead to nasty problems? Think what would happen if someone had a module that did define Bool as an instance of Num and imported the class X. -- = J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u= k 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) From msk@post.tepkom.ru Sat May 5 11:46:10 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Sat, 5 May 2001 14:46:10 +0400 (MSD) Subject: Anomalous Class Fundep Inference In-Reply-To: <29591.989058070@cl.cam.ac.uk> Message-ID: On Sat, 5 May 2001, Jon Fairbairn wrote: > Ashley Yakeley wrote > > OK, I understand it a bit better now. This code does not compile: > > -- > > class X a > > instance X Bool > > instance (Num a) => X a > > -- > > Can someone explain why the two instances overlap, given that Bool is not > > an instance of Num? > > > > Would it be possible for Haskell to figure out this sort of thing and not > > complain about it, or would that lead to nasty problems? > > Think what would happen if someone had a module that did define > Bool as an instance of Num and imported the class X. Program will be rejected at point of such import (or instance declaration)? More simple example: importing two different modules with the exactly same instance declarations for some type. Anton Moscal From ashley@semantic.org Sat May 5 12:03:06 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sat, 5 May 2001 04:03:06 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105051103.EAA02114@mail4.halcyon.com> At 2001-05-05 03:21, Jon Fairbairn wrote: >Ashley Yakeley wrote >> OK, I understand it a bit better now. This code does not compile: >> -- >> class X a >> instance X Bool >> instance (Num a) => X a >> -- >> Can someone explain why the two instances overlap, given that Bool is not >> an instance of Num? >> >> Would it be possible for Haskell to figure out this sort of thing and not >> complain about it, or would that lead to nasty problems? > >Think what would happen if someone had a module that did define >Bool as an instance of Num Should give an error. >and imported the class X. Curiously, whereas Hugs -98 rejects this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x instance (Num a) => X a a where x = 0 -- line A -- ...it accepts this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x module P where import M instance (Num a) => X a a where x = 0 -- line A -- i.e., simply moving line A to a different module. In the latter case it claims these: x :: X a a => a y :: Y a a => a -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 15:16:11 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sun, 6 May 2001 00:16:11 +1000 Subject: Implict parameters and monomorphism In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010506001611.B6194@hg.cs.mu.oz.au> On 04-May-2001, Simon Peyton-Jones wrote: > Lennart Augustsson [mailto:augustss@augustsson.net] wrote: > | It is not at all surprising that you can write this. > | Originally type signatures only allowed you to put a > | signature that was more specific. > | Polymorhic recursion on the other hand allows you to make the > | type more general by putting a type signature on a > | definition. Combining these you can make the signature be > | incomparable to the deduced type. Using the class system you > | can then dispatch on the type and get different behaviour. > > Now that is a *really* amazing example. I had no > idea that polymorphic recursion would do this. Blaming polymorphic recursion is not really fair, IMHO. In particular, Mercury allows polymorphic recursion, but does not suffer from this problem, because it's type inference is capable of inferring the correct most general types even for examples that use polymorphic recursion. In contrast, Haskell uses a type inference algorithm which sometimes infers what I would call wrong answers: types which are less general that can be obtained with an explicit type declaration. These types might not be what the programmer had intended, and this can affect a program's meaning and result. The advantage of Haskell's approach is of course that the type inference process is guaranteed to terminate. In contrast, Mercury's type inference process may fail to terminate for certain ill-typed programs. The Mercury compiler uses a user-configurable iteration limit, and rejects programs for which type inference exceeds this limit. In practice this is very very rare. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jans@numeric-quest.com Sat May 5 22:22:06 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Sat, 5 May 2001 17:22:06 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer In-Reply-To: Message-ID: > Hoping to get some early feedback I am posting this > very preliminary version: > http://www.numeric-quest.com/haskell/QuantumComputer.html > > Jan The bug mentioned in the write-up has been fixed and QFT behaves well now. New versions of both files (module and html page) are ready at the same location. Sorry for talking to myself, but the thought of having posted something buggy (in hope of getting some help) really bothered me. Jan From bjpop@cs.mu.OZ.AU Sun May 6 07:58:02 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Sun, 6 May 2001 16:58:02 +1000 (EST) Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <20010506001611.B6194@hg.cs.mu.oz.au> from Fergus Henderson at "May 6, 2001 00:16:11 am" Message-ID: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> > Fergus Henderson wrote: > In contrast, Haskell uses a type inference algorithm > which sometimes infers what I would call wrong answers: > types which are less general that can be obtained with an explicit > type declaration. These types might not be what the programmer had > intended, and this can affect a program's meaning and result. As you have noted there are advantages and disadvantages of both schemes. I will say that the Haskell requirement of type annotations does sometimes catch accidental (and unintended) uses of polymorphic recursion, thus making compile-time errors out of possible run-time errors (I have seen this happen on dozens of occassions with first year students). Granted that this favourable side-effect was probably never a goal of the Haskell scheme, and it does not always work (in the case that a type scheme is provided which is (accidentally) an acceptable solution to the typing problem of a polymorphically recursive binding group). In the case of the Mercury algorithm, I think that it may be useful for some very verbose mode of the compiler to issue a warning that a function/procedure/predicate is used in a polymorphically recursive manner, if only for the occasional circumstance when it results from a typo in the program. > The advantage of Haskell's approach is of course that the type > inference process is guaranteed to terminate. In contrast, > Mercury's type inference process may fail to terminate for > certain ill-typed programs. The Mercury compiler uses > a user-configurable iteration limit, and rejects programs > for which type inference exceeds this limit. If you applied the Mercury algorithm to Haskell (ie used fixed point iteration to search for a type, rather than requiring a type annotation), would the new type inference algorithm accept/reject the same programs as the existing Haskell algorithm? (assuming an arbitrary user-defined iteration limit, and suitable type annotations for the existing Haskell algorithm). >In practice this is very very rare. I would guess that this is very rare because the (intentional) use of polymorphic recursion is rare (for the predominant case of monomorphic recursion the solution to the fixed point iteration would be almost immediate). Regards, Bernie. From fjh@cs.mu.oz.au Mon May 7 02:57:29 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Mon, 7 May 2001 11:57:29 +1000 Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> References: <20010506001611.B6194@hg.cs.mu.oz.au> <200105060658.QAA20373@mulga.cs.mu.OZ.AU> Message-ID: <20010507115728.A18321@hg.cs.mu.oz.au> On 06-May-2001, Bernard James POPE wrote: > > If you applied the Mercury algorithm to Haskell (ie used fixed point iteration > to search for a type, rather than requiring a type annotation), would > the new type inference algorithm accept/reject the same programs as the > existing Haskell algorithm? (assuming an arbitrary user-defined iteration > limit, and suitable type annotations for the existing Haskell algorithm). Yes, I believe so. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Mon May 7 11:04:57 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:04:57 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC8@red-msg-09.redmond.corp.microsoft.com> There's a design space about how vigorous one is about checking for "unsatisfiable" instances when doing overlap things. It's quite a complicated design space that I don't fully understand, which is why GHC at least implements a conservative rule. For example, does one complain about overlap when the instance declarations are defined, or when they are used? Does one assume that new instances can be added "later"? and there is more I think. =20 Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org]=20 | Sent: 05 May 2001 07:53 | To: Haskell List | Subject: RE: Anomalous Class Fundep Inference |=20 |=20 | At 2001-05-03 01:42, Simon Peyton-Jones wrote: |=20 | >Quite right too! |=20 | OK, I understand it a bit better now. This code does not compile: | -- | class X a | instance X Bool | instance (Num a) =3D> X a | -- | Can someone explain why the two instances overlap, given that=20 | Bool is not=20 | an instance of Num? |=20 | Would it be possible for Haskell to figure out this sort of=20 | thing and not=20 | complain about it, or would that lead to nasty problems? |=20 | --=20 | Ashley Yakeley, Seattle WA |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From simonpj@microsoft.com Mon May 7 11:15:16 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:15:16 -0700 Subject: User defined Ix instances potentially unsafe Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> [Here's a possible Haskell 98 Library Ix "typo"] | > > An implementation is entitled to assume the following laws about=20 | > > these operations: | > >=20 | > > range (l,u) !! index (l,u) i =3D=3D i -- when i is in = range | > > inRange (l,u) i =3D=3D i `elem` range (l,u) | >=20 | > So my "bug" is only in my mind. Sorry for bothering everyone. |=20 | I don't think it's quite as straight-forward as that. | Hugs and ghc may conform to the Library Report, but the=20 | behaviour is still undesirable, and IMHO should be fixed. I rather agree with this. But I'm not sure what the fix is. In thinking about this I've realised that there's an assumption in=20 the Ix interface that (*) map index (range (l,u)) =3D [0..rangeSize (l,u)-1] That is, index maps an index densely into the range 0..N where N is the size of the array. Without this assumption, an array implementation would need to store the Int bounds of the array as well as the ix bounds. I bet that no Haskell implementation does this. If this were not so, the implementation of rangeSize in Section 5.2=20 would be utterly wrong rangeSize b@(l,u) =3D index b h + 1 The constraint (*) also specifies that 'range' returns subscripts in increasing order of index. That seems reasonable, but perhaps less important. One could alternatively say=20 (*a) index (l,u) l =3D 0 (*b) index (l,u) u =3D rangeSize (l,u) - 1 In the spirit of making minimal changes/additions to H98, perhaps (*a) and (*b) would be better. Any thoughts? Simon PS: none of this answers Matt's original question which I can rephrase thus: if a user provides implementations of index, range etc that do not obey the specified invariants, can that crash the system? I would rather the answer were 'no'. But that means the implementation would have to check the output of 'index' against the size of the array allocated from the supplied bounds. Which means that in the common case that 'index' also makes such a check there'd be two checks. Unless the compiler was clever enough=20 to eliminate one of them, which isn't easy since one is at the 'ix' type and the other at 'Int'. From R.Crole@mcs.le.ac.uk Fri May 4 17:49:24 2001 From: R.Crole@mcs.le.ac.uk (Roy L. Crole) Date: Fri, 04 May 2001 17:49:24 +0100 Subject: MERLIN Call for Participation Message-ID: CALL FOR PARTICIPATION Workshop on MEchanized Reasoning about Languages with variable bINding (MERLIN 2001) Siena, Italy, June 18-19, 2001 in connection with IJCAR 2001 ********************************** * http://www.mcs.le.ac.uk/merlin * ********************************** **** Early registration: May 15, 2001 **** ********************************** Currently, there is considerable interest in the use of computers to encode (operational) semantic descriptions of programming languages. Such encodings are often done within the metalanguage of a theorem prover or related system. The encodings may require the use of variable binding constructs, inductive definitions, coinductive definitions, and associated schemes of (co)recursion. The aim of this workshop is to provide researchers with a forum to review state of the art results and techniques, and to present recent and new progress in the areas of: + The automation of the metatheory of programming languages, particularly work which involves variable binding. + Theoretical and practical problems of encoding variable binding, especially the representation of, and reasoning about, datatypes defined from binding signatures. IMPORTANT DATES Early registration: **** May 15, 2001 **** MERLIN workshop: June 18, 2001 IJCAR 2001: June 20-23, 2001 REGISTRATION For details of registration, please see the IJCAR 2001 website at http://www.dii.unisi.it/~ijcar/ INVITED TALK Andrew Pitts, University of Cambridge, has agreed to give an invited talk on "A First Order Theory of Names and Binding". ACCEPTED PAPERS Andreas Abel (Carnegie Mellon, USA). A Third-Order Encoding of the Lambda-Mu-Calculus. Gilles Dowek (INRIA, France), Therese Hardin (LIP6, UPMC, France) and Claude Kirchner (LORIA & INRIA, France). A Completeness Theorem for an Extension of First-Order Logic with Binders. Marino Miculan (Udine, Italy). Developing (Meta)Theory of Lambda-Calculus in the Theory of Contexts. Dale Miller (Pennsylvania State, USA). Encoding Generic Judgements. Christine Roeckl (LAMP-DI-EPFL, Switzerland). A First-Order Syntax for the Pi-Calculus in Isabelle/HOL using Permutations. Carsten Schurmann, Dachuan Yu and Zhaozhong Ni (Yale, USA). Case Study: Formal Development of Safe Intermediate Languages. Rene Vestergaard (CNRS-IML, France) and James Brotherston (Edinburgh, UK). The Mechanisation of Barendregt-Style Equational Proofs (the Residual Perspective). PROGRAMME COMMITTEE Simon Ambler (University of Leicester) Roy Crole (Chair; University of Leicester) Amy Felty (University of Ottawa) Andrew Gordon (Microsoft Research, Cambridge) Furio Honsell (University of Udine) Tom Melham (University of Glasgow) Frank Pfenning (Carnegie Mellon University) FURTHER DETAILS For further details about the Workshop, please contact one of + Roy L. Crole, email: R.Crole@mcs.le.ac.uk + Simon J. Ambler, email: S.Ambler@mcs.le.ac.uk + Alberto Momigliano (Local Organizer), email: A.Momigliano@mcs.le.ac.uk at postal address: Department of Mathematics and Computer Science, University of Leicester, University Road, LEICESTER, LE1 7RH, United Kingdom. From simonpj@microsoft.com Mon May 7 12:55:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 04:55:22 -0700 Subject: FW: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> This is the message that Marcin referred to, proposing a change in the semantics of scoped type variables. I may just go ahead and implement it in GHC. (The implementation is easy: delete a couple of lines; and I guess the same is so for Hugs. The question is whether it's a desirable change.) Simon -----Original Message----- From: Simon Peyton-Jones=20 Sent: 08 February 2001 02:32 Cc: Simon Peyton-Jones; qrczak@knm.org.pl Subject: Scoped type variables Dear Huggy people | But for pattern and result type signatures changing the rules makes=20 | sense. | f (x::a) =3D ... | does not mean that x has type "forall a. a" anyway. It should actually | only give the type a name, no matter what it is. |=20 | Similarly, | f (x :: (a,b)) =3D ... | should unify the appropriate type variable with (,), and give names to | monomorphic arguments of (,) used in the call we are in. I must say that I agree with Marcin's point. When we write f x =3D e we mean that x is a name for whatever argument f is given. Marcin argues that the same should apply for=20 f (x :: (a,b)) =3D e Namely, that x is a name for the argument, a is a name for the type of the fst of x, and slly b. Arguments in favour: - It's more like term-variable pattern matching - In the present system, saying (x::a) doesn't mean x's type is really universally quantified -- it may have a type constraint. And there's really a continuum between saying=20 forall a. C a =3D> t[a] and t[Int] because the Int amounts to a rather strong constraint on a. Indeed, when we have functional dependencies, forall a. C Int a =3D> t[a] may indeed be the same as C Int Int =3D> t[Int] - It's simpler; less to explain to the programmer (quite a bit of the GHC documentation on this stuff is to explain what about the universal quantification) Arguments against - It's not what GHC and Hugs do now. It would be an easy change to make, but I'd prefer it if GHC and Hugs stayed in sync over this (modulo release schedules), so I'd be interested in your views. Simon Someone (Jeff?) wrote: | Could you clarify what you are proposing? Is it | something like "let me name that type `a' even tho I know=20 | it's really something more specific"? (i.e. similar to the=20 | current hugs extension, but without the "can't be more=20 | specific than inferred" restriction) Exactly so. For example f (x::a) =3D let y::a =3D x+1 in h x y would be legal even if=20 h :: Int -> Int -> Int The point is that 'a' simply names the type of x, even if that type isn't a type variable. From qrczak@knm.org.pl Mon May 7 16:22:08 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 7 May 2001 15:22:08 GMT Subject: User defined Ix instances potentially unsafe References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: Mon, 7 May 2001 03:15:16 -0700, Simon Peyton-Jones pisze: > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. It is important if elems should return elements in the same order as indices returns indices, and as listArray accepts. I'm afraid that making arrays robust wrt. bogus Ix instances at the cost of further overheads means a larger pressure to avoid Ix at all in other contexts. It's already avoided in Manuel's parallel arrays, and it was a trouble for me for making ghc's Array/UArray/IArray/MArray operations faster - for example there is an better implementation of compare which works only for index types with particular properties, including Int but not (Int,Int), and sticking to 0-based Ints would make this much simpler, as well as making packed strings implemented in terms of UArrays more efficient. There are other problems. The report says that repeated indices in array construction is an error. Ghc doesn't check that and lets later values win. To implement what the report says it would have to be less efficient: avoiding a separate array for marking which elements are initialized would need unsafePtrEq on each store and probably a loop after the construction which would replace missing elements with bottoms which are not unsafePtrEq, so initialization of another array can distinguish absent elements from elements taken from this array. I'm not sure whether I should still use Ix-based arrays in my unified collection experiments etc., which don't fit there well, or say STOP at some point, concentrate on 0-based Int-indexed dynamic vectors with the interface of sequences, optionally adding Array support as a Haskell 98 compatibility kludge. Having mutable arrays with immutable bounds is also a small problem. Generally Ix-based Arrays may become a larger trouble to support than they are really worth. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From fjh@cs.mu.oz.au Mon May 7 17:15:26 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 8 May 2001 02:15:26 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010508021526.A20463@hg.cs.mu.oz.au> On 07-May-2001, Simon Peyton-Jones wrote: > In thinking about this I've realised that there's an assumption in > the Ix interface that > > (*) map index (range (l,u)) = [0..rangeSize (l,u)-1] ... > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. One could alternatively say > > (*a) index (l,u) l = 0 > (*b) index (l,u) u = rangeSize (l,u) - 1 > > In the spirit of making minimal changes/additions to H98, perhaps (*a) > and (*b) would be better. Given that (*a)+(*b) already pin the end-points, I *think* you might as well go all the way and use (*); I don't *think* the extra flexibility of (*a)+(*b) would be useful. Given a type T which satisfies (*a)+(*b) one can defined a new range function which sorts the elements by index range' b@(l,u) = sortBy compareIndex range b where compareIndex x y = compare (index b x) (index b y) and then after renaming range as e.g. unsortedRange and range' as range, the type will now satisfy (*). So for Haskell 200X, (*) would certainly be preferable, IMHO. For Haskell 98, I'm not sure; perhaps it is best to be conservative. > PS: none of this answers Matt's original question which I can rephrase > thus: > if a user provides implementations of index, range etc that do not obey > the specified invariants, can that crash the system? I would rather the > answer were 'no'. I think the answer should be "no, unless the user specified the appropriate compiler option to disable array bounds checking". > But that means the implementation would have to check the output of > 'index' against the size of the array allocated from the supplied bounds. > Which means that in the common case that 'index' also makes such a > check there'd be two checks. If you really want to squeeze the last drops of performance out, then there's always that compiler option to disable array bounds checking... > Unless the compiler was clever enough > to eliminate one of them, which isn't easy since one is at the 'ix' > type and the other at 'Int'. One possible way to eliminate them would be to add an extra method called unchecked_index or __unchecked_index to the Ix class. By default this would do the same as index class Ix t where ... __unchecked_index = index but you could define the instances for the standard library types such as Int, Char, etc. so that they just skip the check and return an out-of-range Int; for array operations such as (!) where you're going to do a range check on the value returned from index, you can safely use __unchecked_index instead. The reason for using a name such as __unchecked_index rather than just unchecked_index would be for strict compatibility with Haskell 98: to avoid clashing with user-defined identifiers, you need to use a name that is reserved for use by the implementation, Unfortunately, unless I missed something, Haskell 98 does seem to reserved any identifiers at all for use by the implementation, other than the standard reserved words, so I think even using a name like `__unchecked_index' here would not be 100% strictly Haskell 98 compatible. I think it would be good enough in practice, though. For Haskell 200X, where strict backwards compatibility is not required, unchecked_index should be introduced as a documented new method for the Ix class. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Mon May 7 20:31:57 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Mon, 7 May 2001 13:31:57 -0600 Subject: User defined Ix instances potentially unsafe In-Reply-To: <20010508021526.A20463@hg.cs.mu.oz.au> Message-ID: > If you really want to squeeze the last drops of performance out, then > there's always that compiler option to disable array bounds checking... If you mean: "disable array bounds checking" == assume that the (possibly user-supplied) Ix instance is correct but still perform the Ix-based range check. [This is the status quo.] "enable array bounds checking" == perform a possibly redundant range check because the Ix instance may be broken then this sounds like an excellent idea. Especially given that Pascal compilers (not exactly new technology) used to do a pretty good job of eliminating redundant bounds checks so I imagine that that redundant check could be eliminated from all the easy cases without too much work. > For Haskell 200X, where strict backwards compatibility is not required, > unchecked_index should be introduced as a documented new method for the > Ix class. Is this enough? Most of the array code I write uses the higher-level operations like fmap and ixmap. Do I need unchecked versions of them too? Can the higher-level operations amortise the cost of those extra bounds checks? I think fmap can but ixmap can't and I haven't considered the others. -- Alastair Reid From mpj@cse.ogi.edu Tue May 8 06:41:27 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Mon, 7 May 2001 22:41:27 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon! | This is the message that Marcin referred to, proposing a change in | the semantics of scoped type variables. I may just go ahead and | implement it in GHC. (The implementation is easy: delete a couple | of lines; and I guess the same is so for Hugs. The question is = whether | it's a desirable change.) I think that it is an undesirable change. For example, the type theoretic and practical implications of the current semantics are known quantities. I'm not aware of similar foundations to support the new semantics. Nor have I seen any believable motivation for the change. For example: | I must say that I agree with Marcin's point. When we write | f x =3D e | we mean that x is a name for whatever argument f is given. Marcin | argues that the same should apply for=20 | f (x :: (a,b)) =3D e | Namely, that x is a name for the argument, a is a name for the type of | the fst of x, and slly b. |=20 | Arguments in favour: | - It's more like term-variable pattern matching Term variables in a pattern are binding occurrences, but type variables are not. Making the latter look more like the former would appear to be a recipe for unnecessary confusion given that that they are actually different. (As an aside, pushing an argument like the above, you might also argue that when we write "f x =3D e" we mean that "f" is a name for whatever function "x" is passed to as an argument. I'm sure we can all agree here: that would definitely be "slly"!) There's good precedent for the current semantics, both in practice (e.g., Standard ML) and in theory (e.g., typed lambda-calculi). It would be a mistake to switch to an untested and unusual semantics, especially without compelling motivating examples. All the best, Mark From simonpj@microsoft.com Tue May 8 08:47:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 00:47:58 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Hi Mark,=20 Thanks for your reply. | | Arguments in favour: | | - It's more like term-variable pattern matching |=20 | Term variables in a pattern are binding occurrences, but type=20 | variables are not. Making the latter look more like the=20 | former would appear to be a recipe for unnecessary confusion=20 | given that that they are actually different. Why do you say "type variables are not"?. When I say f x =3D e I mean "inside e, use x as the name for whatever value is=20 passed as argument to f". Under what Marcin proposes=20 f (x::a) =3D e would mean "inside (type signatures in) e, use a as the name for whatever type is the type of the argument passed to f". When you say there's a good theoretical foundation (typed lambda calcului) I think you are imagining that when we say f (x::a) =3D e we are saying "There's a /\a as well as a \x::a in this definition". In which case it would certainly be wrong to allow f :: Int -> Int f (x::a) =3D e But I'm suggesting something different * Place the big lambdas wherever they would be now (i.e. not influenced by the position of (x::a) type signatures. * Explain the pattern type signatures as let-bindings for types. Thus we might translate f to system-F like this: f =3D \x::T -> let-type a =3D T in e I've use let-type here, but one could equally well say (/\a -> e) T. This (admittedly informal) translation works fine if T happens to be Int, for exampe; i.e. x's type is not universally quantified. =20 In short, the pattern type signature is used solely to bind names to types, and not for universal quantification. I want to have a slightly more elaborate let-type, thus: g :: (Int,Bool) -> Int g (x::(a,b)) =3D e translates to g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e But notice that the RHS of a pattern-matching let-type is statically guaranteed to have the right shape. So I don't allow let-type (a,b) =3D c in ... (where c is a type variable). So it's just syntactic sugar, like let-type itself, and I could equally well write g =3D \x::(Int,Bool) -> let-type a =3D Int; b =3D Bool in e OK, so there are two questions a) does that answer the question about the techincal foundation b) is it a good design from a software engineering point of view I hope the answer to (a) is yes, but I realise that opinions may differ about (b). I thought this might be of general enough interest to be worth continuing to cc the Haskell list. Simon From Gnzgncrls@netscape.net Mon May 7 21:53:52 2001 From: Gnzgncrls@netscape.net (Gian) Date: Tue, 08 May 2001 06:53:52 +1000 Subject: making plurals Message-ID: <3AF70B60.3000205@netscape.net> i was wandering if you would be able to show me how to implement a function which converts a list of words into the plurals say maybe to convert "shelf" into "shelves". I thought maybe with using some kind of recursion, tupples and the prelude function isSuffixOf. but im not sure how to implement it can you help. From Markus Lauer Tue May 8 11:07:48 2001 From: Markus Lauer (Markus Lauer) Date: Tue, 8 May 2001 12:07:48 +0200 (MEST) Subject: question on type classes Message-ID: Is it possible in Haskell to define a type class like Show, which has a generic implementation for Lists and a special one for [Char], but (in contrast to Show) where Char is not in this Class I'd like to have something like the following, but this example doesn't work: ------------------------------------------- module Test where class Foo a where foo :: a -> a .... .... instance FooList a => Foo [a] where foo lst = fooList lst .... .... class FooList a where fooList :: [a] -> [a] .... .... genericImpl :: Foo a => [a] -> [a] genericImpl = ... specialImpl :: String -> String specialImpl = .... instance FooList Char where fooList s = specialImpl s ..... instance Foo a => FooList a where fooList lst = genericImpl lst ..... --------------------------------------------- Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor expected) ghc (5.00) sais Test.hs:20: Illegal instance declaration for `FooList a' (the instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) is there a better way, than to copy the instance declaration of FooList for every a in that is in class Foo? Thanks for any hint, Markus -- Markus Lauer From ashley@semantic.org Tue May 8 11:38:25 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 8 May 2001 03:38:25 -0700 Subject: question on type classes Message-ID: <200105081038.DAA25076@mail4.halcyon.com> At 2001-05-08 03:07, Markus Lauer wrote: >Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor > expected) Invoke as 'hugs -98' to switch on extensions. Hugs will then complain of overlapping instances: instance FooList Char instance Foo a => FooList a Yes, I know Char is not an instance of Foo. See the "Anomalous Class Fundep Inference" thread. -- Ashley Yakeley, Seattle WA From bdhumb@students.cs.mu.OZ.AU Tue May 8 13:44:24 2001 From: bdhumb@students.cs.mu.OZ.AU (Bryn Humberstone) Date: Tue, 8 May 2001 22:44:24 +1000 Subject: making plurals In-Reply-To: <3AF70B60.3000205@netscape.net>; from Gian on Tue, May 08, 2001 at 06:53:52AM +1000 References: <3AF70B60.3000205@netscape.net> Message-ID: <20010508224424.A11969@holly.cs.mu.OZ.AU> Gian, > i was wandering if you would be able to show me how to > implement a function which converts a list of words into the plurals > say maybe to convert "shelf" into "shelves". I thought maybe with using > some kind of recursion, tupples and the prelude function isSuffixOf. but > im not sure how to implement it can you help. I can't help noticing your question sounds remarkably like the sort of assignment question that gets set in a first year university course. Most universities don't allow students to solicit help from mailing lists so you probably should look away now before I reveal the answer. I'm sure that your tutors, lab demonstrators and lecturers will be happy to help you since you sound as though you're quite close to the solution. Nevertheless, I've devised a solution that seems to meet most of your requirements. It is quite inefficient on most words, but it should be a good place to start looking (apart from, say, your lecture notes). import List overallProgram = map makePlural makePlural word = case word of "shelf" -> "shelves" _ -> fst (makePlural word, let foo = "heating" in isSuffixOf foo ('c':foo)) And to the people on the list, please try to resist giving any answers to this or similar problems for the next few weeks as it just makes life more difficult for the students who invariably get caught. I think that the map (map toUpper)/capitalise controversy was originally sparked as a result of a question pertaining to this project as well. Cheers, Bryn From qrczak@knm.org.pl Tue May 8 15:59:20 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 14:59:20 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 00:47:58 -0700, Simon Peyton-Jones pisze: > g = \x::(Int,Bool) -> let-type (a,b) = (Int,Bool) in e > > But notice that the RHS of a pattern-matching let-type is statically > guaranteed to have the right shape. So I don't allow > > let-type (a,b) = c in ... > > (where c is a type variable). Really? I disagree. Making pattern type sygnatures perform unification of the variable with the supplied signature is useful for resolving ambiguities, and backward-compatible (valid programs will remain valid), and doesn't allow "unwanted generality" to cause trouble (when an expression has a more general type than needed). Currently ghc does not accept: (\(x::a) -> x) :: Int->Int but accepts this: (let f = \(x::a) -> x in f) :: Int->Int Hugs accepts both! But it doesn't like (\(x::a) -> (x::Int)) I would make all three legal. Unfortunately it doesn't help for my example: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) unless the type inference could deduce that the constraint MArray (STArray s') e (ST s) in the presence of instance MArray (STArray s) e (ST s) unifies s' with s. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Tue May 8 16:25:39 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 08:25:39 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> | > g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e | >=20 | > But notice that the RHS of a pattern-matching let-type is=20 | statically=20 | > guaranteed to have the right shape. So I don't allow | >=20 | > let-type (a,b) =3D c in ... | >=20 | > (where c is a type variable). |=20 | Really? I disagree. Making pattern type sygnatures perform=20 | unification of the variable with the supplied signature is=20 | useful for resolving ambiguities, and backward-compatible=20 | (valid programs will remain valid), and doesn't allow=20 | "unwanted generality" to cause trouble (when an expression=20 | has a more general type than needed). I was meaning in the translation into System F of the program. Under my proposal (=3D yours) if one writes f (x::(a,b)) =3D e then f is forced to have type f :: (T1, T2) -> ... for some T1, T2. In saying that let-type can't pattern-match against a type variable c, I'm just saying that f cannot have type f :: forall c. c -> .... I think I just didn't express myself well enough. Simon From jefu@cs20.eou.edu Tue May 8 17:33:10 2001 From: jefu@cs20.eou.edu (jefu) Date: Tue, 08 May 2001 09:33:10 -0700 Subject: cross product of lists Message-ID: <200105081633.f48GXAi20714@cs20.eou.edu> This is not a class assignment - indeed I'm a professor who has used haskell in classes (and is currently being fired for having done so - it seems teaching anything other than c++ is questionable). I'd like to have a program that will take a description of a regular language and produce a list of strings in that language in order of size. If the lists are infinite (a* and the like) things work fine, but when the lists are finite, things dont work. I have two programs that I've tried to use and both have been hacked a bit in my process of experimentation so they're not the nicely honed final product I'd like to have. The first is based on my original ideas but with some attempt to cajole the finite/infinite list problem - it still seems to me that this would be a good way to go if possible, but I'm stumped. It is at : http://cs.eou.edu/jefu/reglang.hs The second is built on the idea of remembering if a list is finite or infinite and handling it accordingly. This one manages to segfault hugs and ghci also just quits about half the time (linux, redhat 7). This one is at : http://cs.eou.edu/jefu/nreglang.hs Any suggestions ? jefu -- jeff putnam -- jefu@eou.edu -- http://cs.eou.edu/~jefu From qrczak@knm.org.pl Tue May 8 17:32:53 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 16:32:53 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 08:25:39 -0700, Simon Peyton-Jones pisze: > I was meaning in the translation into System F of the program. [...] Ah, OK, sorry. More strange behavior of Hugs (none of this is allowed by ghc): \(x :: a) (y :: b) -> x+y -- not allowed \(x :: a) -> \(y :: b) -> x+y -- allowed f :: Int->Int->Int; f x = \(y::a) -> x+y -- not allowed f :: Int->Int->Int; f = \x (y::a) -> x+y -- allowed I guess that the constraint that a type is not more specific than a pattern type signature tells is checked once at some point of time. It is rejected only when the type inference determined the more specific type before this check was performed, but it might be determined later which is not caught. I would remove the check altogether. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From ham@cs.utexas.edu Tue May 8 19:01:41 2001 From: ham@cs.utexas.edu (Hamilton Richards) Date: Tue, 8 May 2001 13:01:41 -0500 Subject: cross product of lists In-Reply-To: <200105081633.f48GXAi20714@cs20.eou.edu> Message-ID: At 11:33 AM -0500 5/8/01, jefu wrote: [...] >I'd like to have a program that will take a description of a regular >language and produce a list of strings in that language in order >of size. [...] > > >Any suggestions ? Have a look at http://www.cs.utexas.edu/users/pete/research/enumeration.html. --Ham ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu ------------------------------------------------------------------ From rjchaaft@cs.uu.nl Wed May 9 13:05:56 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 09 May 2001 14:05:56 +0200 Subject: Class RealFrac: round Message-ID: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Hello, While I were writing a RealFrac implementation for BigDouble's (for high-precision computations) I found a strange implementation of round in the standard prelude (from the haskell definition): round x = let (n,r) = properFraction x m = if r < 0 then n - 1 else n + 1 in case signum (abs r - 0.5) of -1 -> n 0 -> if even n then n else m 1 -> m The strange case is if signum (abs r - 0.5) is 0: such numbers are round to the nearest EVEN integer. In mathematics, computer science (the studies I'm doing) and physics, as far as I know, it is usual to round such numbers up, rather than to the nearest integer. For example: Number Hugs Math 0.5 0 1 1.5 2 2 -3.5 -4 -4 6.5 6 7 Why did the Haskell designers choose this behaviour? Thanks in advance, Rijk-Jan van Haaften From lennart@mail.augustsson.net Wed May 9 13:14:11 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Wed, 09 May 2001 08:14:11 -0400 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Message-ID: <3AF93493.A46D22D3@mail.augustsson.net> Rijk-Jan van Haaften wrote: > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): > > round x = > let (n,r) = > properFraction x > m = if r < 0 then n - 1 else n + 1 > in case signum (abs r - 0.5) of > -1 -> n > 0 -> if even n then n else m > 1 -> m > > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: Rounding to the nearest even number is considered the best practice by people doing numerical analysis. Even when I went to school (25 - 30 years ago) we were taught to round to the nearest even number, so it's not exactly new. -- Lennart From karczma@info.unicaen.fr Wed May 9 16:07:21 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 09 May 2001 17:07:21 +0200 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> <3AF93493.A46D22D3@mail.augustsson.net> Message-ID: <3AF95D29.6068FA5@info.unicaen.fr> Lennart Augustsson comment to : > Rijk-Jan van Haaften wrote: ... > > The strange case is if signum (abs r - 0.5) is 0: > > such numbers are round to the nearest EVEN integer. In mathematics, > > computer science (the studies I'm doing) and physics, as far as I > > know, it is usual to round such numbers up, rather than to the nearest > > integer. For example: > ... > Rounding to the nearest even number is considered the best practice by > people doing numerical analysis. Even when I went to school (25 - 30 > years ago) we were taught to round to the nearest even number, so it's > not exactly new. > > -- Lennart I wonder whether it has anything to do with the "best practice". I suppose that this is the natural way to get rid of one more bit of mantissa. Anyway, there is the standard IEEE 754 (with its 4 rounding modes...) and it is good to have a published standard, even if it results in some hangover of some people. The reported behaviour is also visible in Clean, and I spent 2 days on debugging because of that "round-ties-to-even rule"... It is not very "natural" psychologically, and from time to time I do some mistakes, although I know the stuff. Look here: (among 100 other references I could give you) http://www.validgh.com/goldberg/addendum.html http://developer.intel.com/technology/itj/q41999/articles/art_6.htm http://www.cs.umass.edu/~weems/CmpSci535/535lecture6.html Jerzy Karczmarczuk Caen, France From Joe.Bowers@CanopySystems.com Wed May 9 14:09:46 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Wed, 9 May 2001 09:09:46 -0400 Subject: Class RealFrac: round Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/plain I'm not one of the implementors, but this sort of behavior can reduce error in fields where X.5 is a common result- a rule like "The nearest even integer" moves upward half the time and downward half the time- hopefully cancelling itself out. Or maybe they had other reasons... Joe > -----Original Message----- > From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl] > Sent: Wednesday, May 09, 2001 8:06 AM > To: haskell@haskell.org > Subject: Class RealFrac: round > > > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): ... > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: > > Number Hugs Math > 0.5 0 1 > 1.5 2 2 > -3.5 -4 -4 > 6.5 6 7 > > Why did the Haskell designers choose this behaviour? > > Thanks in advance, > > Rijk-Jan van Haaften > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Class RealFrac: round I'm not one of the implementors, but this sort of = behavior can reduce error in fields where X.5 is a common = result- a rule like "The nearest even integer" = moves upward half the time and downward half the time- hopefully = cancelling itself out. Or maybe they had other reasons... Joe > -----Original Message----- > From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl] > Sent: Wednesday, May 09, 2001 8:06 AM > To: haskell@haskell.org > Subject: Class RealFrac: round > > > Hello, > > While I were writing a RealFrac implementation = for BigDouble's (for > high-precision computations) I found a strange = implementation of > round in the standard prelude (from the haskell = definition): ... > The strange case is if signum (abs r - 0.5) is = 0: > such numbers are round to the nearest EVEN = integer. In mathematics, > computer science (the studies I'm doing) and = physics, as far as I > know, it is usual to round such numbers up, = rather than to the nearest > integer. For example: > > Number Hugs = Math > 0.5 = 0 1 > 1.5 = 2 2 > -3.5 = -4 -4 > 6.5 = 6 7 > > Why did the Haskell designers choose this = behaviour? > > Thanks in advance, > > Rijk-Jan van Haaften > > > = _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ------_=_NextPart_001_01C0D889.5242C2C0-- From jbw@izanami.cee.hw.ac.uk Wed May 9 13:28:30 2001 From: jbw@izanami.cee.hw.ac.uk (Joe Wells) Date: 09 May 2001 13:28:30 +0100 Subject: RA position @ Heriot-Watt Univ. in program analysis Message-ID: --=-=-= Content-Disposition: inline Research Assistant Position Useful Logics, Types, Rewriting, and Applications (ULTRA) Group Computing and Electrical Engineering Department Heriot-Watt University Edinburgh, Scotland, UK A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland. The RA should either already have skills in some of the following areas and be interested and able to learn about several others: * type systems, especially those with intersection and union types, * static analysis of computer programs, * constraint solving, * higher-order programming languages, * programming language semantics, design, and/or implementation. The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done. The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science. To formally apply for this position, please do the following: * Arrange for 3 letters of reference to be sent. * Send the following yourself: + your complete curriculum vitae, + a brief statement of your research accomplishments and interests and why you think you would be a good match for the job, + web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and + contact details for the people writing your letters of reference. If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected. Applications or inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw@cee.hw.ac.uk fax: +44 131 449 3834 post: Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN --=-=-= Content-Type: text/html Content-Disposition: inline Research Assistant Position Research Assistant Position Useful Logics, Types, Rewriting, and Applications (ULTRA) Group Computing and Electrical Engineering Department Heriot-Watt University Edinburgh, Scotland, UK A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland. The RA should either already have skills in some of the following areas and be interested and able to learn about several others: type systems, especially those with intersection and union types, static analysis of computer programs, constraint solving, higher-order programming languages, programming language semantics, design, and/or implementation. The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done. The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science. To formally apply for this position, please do the following: Arrange for 3 letters of reference to be sent. Send the following yourself: your complete curriculum vitae, a brief statement of your research accomplishments and interests and why you think you would be a good match for the job, web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and contact details for the people writing your letters of reference. If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected. Applications or inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw@cee.hw.ac.uk fax: +44 131 449 3834 post: Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN --=-=-=-- From chak@cse.unsw.edu.au Thu May 10 10:26:59 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 10 May 2001 19:26:59 +1000 Subject: ANNOUNCE: Happy 1.10 released In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510192659H.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell An RPM package for x86 RedHat Linux[1] is now available at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm Happy LALRing, Manuel [1] The binary has been build on RH7.0 with glibc2.2. From ml_dk@excite.com Thu May 10 10:56:00 2001 From: ml_dk@excite.com (=?iso-8859-1?Q?Mads_Lindstr=F8m?=) Date: Thu, 10 May 2001 02:56:00 -0700 (PDT) Subject: The definition of lhsfun in the report Message-ID: <24443469.989488562297.JavaMail.imail@ringo.excite.com> I'am confused about the "funlhs" production, in "Report on the programming Language Haskell 98" of the 1st February 1999. In the report one of the "funlhs"-productions is (see page 127): funlhs -> var apat {apat} That is a followed by one to many . But you can have functions like this: fun :: Int fun = 17 That is without any patterns to match, so why is the rule not ? funlhs -> var {apat} That is a followed by zero to many . I will be very happy for an answer to my question. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From franka@cs.uu.nl Thu May 10 12:12:30 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Thu, 10 May 2001 13:12:30 +0200 Subject: The definition of lhsfun in the report In-Reply-To: <24443469.989488562297.JavaMail.imail@ringo.excite.com> Message-ID: > I'am confused about the "funlhs" production, in "Report on the programming > Language Haskell 98" of the 1st February 1999. > > In the report one of the "funlhs"-productions is (see page 127): > > funlhs -> var apat {apat} > > That is a followed by one to many . But you can have functions > like this: > > fun :: Int > fun = 17 This does not declare a function. If you look at the decl production, you will see that there is another possibility, namely pat^0, which provides this syntax. OTOH it is possible to declare a function using pat, e.g.: fun = \x -> x+1 In other words, funlhs is redundant. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791 From luc.taesch@csfb.com Thu May 10 14:07:43 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Thu, 10 May 2001 15:07:43 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. what is the best organisation ? -import module P everywhere - isolate this datatype in a module, which would be imported everywhere ?(very "include like") - merging the module around this datatype ? this last option is not a good option here as : - this would be too big - P is generated by Happy. this look very much like a OO/non OO debate, which I dont want to spawn again. I can suppose its a FAQ like question. any good pointer ? whats the best practice around ? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From alex@shop.com Thu May 10 15:24:51 2001 From: alex@shop.com (S. Alexander Jacobson) Date: Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time) Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: Combining two threads... Like macros and preprocessors, Happy generates code. I assume the justification for this is that hand-coding a parser in Haskell is presumed to be too difficult or that it is too hard to get the right level of abstraction (and therefore a macro-like facility is required). However, I've also used Hutton & Meijer style monadic parsers and found them extremely elegant, clean, and easy to use in both Haskell and Python (though in Python they were too slow for my xml application -- function call overhead is _very_ high in Python). I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? And generalizing from the above, since Monads/Arrows are types that describe a computation declaratively and Macros are functions that describe a computation procedurally, is it possible that, for any application of Macros, you can find a suitable Monad/Arrow? Or am I not understanding either well enough? -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) From kort@science.uva.nl Thu May 10 15:36:25 2001 From: kort@science.uva.nl (Jan Kort) Date: Thu, 10 May 2001 16:36:25 +0200 Subject: sharing datatypes : best practice ? References: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> Message-ID: <3AFAA769.D699EE5F@wins.uva.nl> "Taesch, Luc" wrote: > > i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. > > what is the best organisation ? > > -import module P everywhere > - isolate this datatype in a module, which would be imported everywhere ?(very "include like") > - merging the module around this datatype ? > > this last option is not a good option here as : > - this would be too big > - P is generated by Happy. Hi Luc, Isolating the datatype in a module is what I always do. Only "Main.hs" calls the happy parser and just about every module uses the datatype, so it makes sense to separate them. Jan From simonmar@microsoft.com Thu May 10 15:42:00 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 10 May 2001 15:42:00 +0100 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) Message-ID: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on=20 > macros, I > have to ask: why use happy rather than monadic parsing? =20 > Monadic parsing > allows you to avoid a whole additional language/compilation=20 > step and work > in Hugs (where you don't have a makefile). What does Happy=20 > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon From cwitty@newtonlabs.com Thu May 10 18:48:52 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 10 May 2001 10:48:52 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "S. Alexander Jacobson"'s message of "Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)" References: Message-ID: "S. Alexander Jacobson" writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? I've used Happy instead of parser combinators because I wanted the additional global error-checking. I believe that the standard implementations of parser combinators will allow you to specify an ambiguous grammar, and return one of the multiple possible parses, without warning. Carl Witty From qrczak@knm.org.pl Thu May 10 20:13:05 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 10 May 2001 19:13:05 GMT Subject: Fundeps and class contexts Message-ID: Would allowing this make sense? class C a b | a -> b class C a b => S a I want to simulate a particular "class synonym" (with four superclasses instead of one C here) where the type 'b' is uninteresting for its users. Currently I have to write class C a b | a -> b class C a b => S a b | a -> b and use f :: S a b => T(a) instead of f :: S a => T(a) even though T(a) usually doesn't contain b. If it does, I would write f :: (S a, C a b) => T(a) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@foo.net Thu May 10 22:22:04 2001 From: john@foo.net (John Meacham) Date: Thu, 10 May 2001 14:22:04 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Thu, May 10, 2001 at 03:42:00PM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510142203.A16027@mark.ugcs.caltech.edu> Just out of curiosity, has anyone done any work at benchmarking the various parsers? I use Parsec pretty exclusivly since it comes with ghc and is pretty straightforward and lightweight to use. I am wondering what I am giving up in terms of speed by going that route, rather than Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm... John On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote: > > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From johnsson@crt.se Fri May 11 08:01:04 2001 From: johnsson@crt.se (Thomas Johnsson) Date: Fri, 11 May 2001 09:01:04 +0200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: <15099.36400.547112.275888@spitfire.crt.se> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? Happy and others like it generate an LR parser, which is a well-established technology since the late 60's (Knuth): efficient, deterministic, and checks the grammar for you. Parser combinators are usually nondeterministic ie backtracking (pre-Knuth!:-) though Cleverly Disguised in Haskell Higher Order clothes.... LR parsers gives you greated freedom in expressing the grammar, with the LR parser generator leaning over your shoulder. Grammars possible with parsing combinators are more constrained: cannot use left recursion, order of rules matters, etc. On the other hand, one has the whole abstraction machinery of Haskell or whatever at hand for writing the grammar rules. The analogy that comes to mind is statically typed languages vs runtime typed ones. --Thomas PS would be cool to try to marry the two approaches.... From chak@cse.unsw.edu.au Fri May 11 08:09:44 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Fri, 11 May 2001 17:09:44 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010511170944K.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). I don't think, the point is the test for non-ambiguity. At least, Doitse's and my self-optimising parser combinator library will detect that a grammar is ambigious when you parse a sentence involving the ambiguous productions. So, you can check that by parsing a file involving all grammar constructs of the language. The point is much more the level of help that you get if your grammar happens to be ambiguous. My combinators at the moment just tell you that the grammar is ambiguous, but provide no help as to where and why. I think, this is similar for Doitse's combinators. Happy helps you much more in this situation. Cheers, Manuel From luc.taesch@csfb.com Fri May 11 08:53:00 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:53:00 +0200 Subject: haskell wiki wiped ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CD@szrh00313.tszrh.csfb.com> i tried to acces the hasakell wiki ? it s just all blank. has it been purged ? i remember having seen some idioms ... This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From luc.taesch@csfb.com Fri May 11 08:56:37 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:56:37 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CF@szrh00313.tszrh.csfb.com> do u isolate just the datatype, or a few related with, in a very small file (header like, i would say) or some basic accessor function with it ? isnt it leading to massiv quantities of small files ? > -----Original Message----- > From: Jan Kort [mailto:kort@science.uva.nl] > Sent: Donnerstag, 10. Mai 2001 16:36 > To: Taesch, Luc > Cc: 'haskell@haskell.org' > Subject: Re: sharing datatypes : best practice ? > > > "Taesch, Luc" wrote: > > > > i ve developped a datatype in a module P, and another > module will use it, and most probably a few others, and its > quite central to the apps Im building. > > > > what is the best organisation ? > > > > -import module P everywhere > > - isolate this datatype in a module, which would be > imported everywhere ?(very "include like") > > - merging the module around this datatype ? > > > > this last option is not a good option here as : > > - this would be too big > > - P is generated by Happy. > > Hi Luc, > Isolating the datatype in a module is what I always do. > Only "Main.hs" calls the happy parser and just about > every module uses the datatype, so it makes sense to > separate them. > > Jan > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From dongen@cs.ucc.ie Fri May 11 10:52:55 2001 From: dongen@cs.ucc.ie (Marc van Dongen) Date: Fri, 11 May 2001 10:52:55 +0100 Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)] In-Reply-To: <20010511170944K.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Fri, May 11, 2001 at 05:09:44PM +1000 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010511105255.S12168@cs.ucc.ie> Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote: [received message twice] Am I just the only one or does everybody receive messages posted to haskell@haskell.org and glasgow-haskell-users@haskell.org twice? I find it a bit (I know I am exaggerating) annoying. Is there a way to avoid this? Regards, Marc From cwitty@newtonlabs.com Fri May 11 18:13:49 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 11 May 2001 10:13:49 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Fri, 11 May 2001 17:09:44 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I don't think, the point is the test for non-ambiguity. At > least, Doitse's and my self-optimising parser combinator > library will detect that a grammar is ambigious when you > parse a sentence involving the ambiguous productions. So, > you can check that by parsing a file involving all grammar > constructs of the language. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty From brian@boutel.co.nz Sat May 12 05:57:34 2001 From: brian@boutel.co.nz (Brian Boutel) Date: Sat, 12 May 2001 16:57:34 +1200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <3AFCC2BE.B75CB113@boutel.co.nz> "Carl R. Witty" wrote: > > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. > This illustrates the difference between generality and usefulness. Often, one is less interested in learning that a grammar is ambiguous than learning that it is not. If you have a parser generator for a class of grammars, it will tell you if (and probably why) a candidate grammar you feed to it is not a member of that class. If it is accepted by, for example, a parser generator for LR(1) grammars, then it is a DCFG and therefore unambiguous. If you start with a "natural" grammar for the language, i.e. one that corresponds to the abstract syntax, and use a generator for a broad class of grammars (e.g LR(1)) then failure will give a good hint that the only way to get an unambiguous grammar in that class is to restrict the language, and you can use that information to make design decisions. For example, although Haskell has both 'let' and 'where' for introducing local definitions, thereby reflecting the typical committee decision when there are varying stylistic preferences, 'where' is not part of the expression syntax. If you write a grammar which includes the "natural" productions exp -> let defs in exp exp -> exp where defs and put this through a suitable generator, you will see why not. Of course, it is possible that an unambiguous grammar will fail to be LR(1) - by being non-deterministic, so the proper conclusion is that "G is ambiguous or non-deterministic". But that is close enough for most purposes. Early versions of Hope had both 'let' and 'where' as expressions, and had three different forms of condtional. Most combinations of these constructs would interract to create ambiguity. The hand-coded parsers in use had not picked this up. That shows the advantage of using a generator - you get a constructive proof that the grammar is in the desired class. --brian From chak@cse.unsw.edu.au Sun May 13 07:51:38 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 16:51:38 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010513165138B.chak@cse.unsw.edu.au> cwitty@newtonlabs.com (Carl R. Witty) wrote, > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. I didn't say that this works for any kind of parser combinator, I merely said that it works Doitse's and mine. Both implement SLL(1) parsers for which - as I am sure, you know - there exists a decision procedure for testing ambiguity. More precisely, whenever the library can build the parse table, the grammar must be non-ambigious. As the parse table construction is lazy, this covers only the productions exercised in that particular run, which is why I said that you need a "file involving all grammar constructs of the language." Nothing magic here. Cheers, Manuel PS: AFAIK Doitse recently made his combinators a bit more general, and I am not entirely sure how that affects the ambiguity check. From chak@cse.unsw.edu.au Sun May 13 08:40:26 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 17:40:26 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <15099.36400.547112.275888@spitfire.crt.se> References: <20010510192659H.chak@cse.unsw.edu.au> <15099.36400.547112.275888@spitfire.crt.se> Message-ID: <20010513174026V.chak@cse.unsw.edu.au> Thomas Johnsson wrote, > Happy and others like it generate an LR parser, which is a well-established > technology since the late 60's (Knuth): efficient, > deterministic, and checks the grammar for you. > Parser combinators are usually nondeterministic ie > backtracking (pre-Knuth!:-) > though Cleverly Disguised in Haskell Higher Order clothes.... [..] > PS would be cool to try to marry the two approaches.... Doaitse Swierstra et al have done this to a certain extent: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/ Parser combinators that are efficient, deterministic, and handle errors much better than the classic form of parser combinators. Manuel From ltaesch@europemail.com Sun May 13 10:22:05 2001 From: ltaesch@europemail.com (luc) Date: Sun, 13 May 2001 11:22:05 +0200 Subject: io monad question Message-ID: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , mainly String -> [String], or similar = with types, plus some more complex datatypes. Up to now; i was testing them on a basic database I was creating in the = core main, "by hand". Then i added a basic parser with happy; and bingo; my test database is = now loaded from a file... as IO String..; huh! after a second though; this makes sense, except that i have to change = all the type of my functions; now IO String.. plus a few that just dont compile; and i cant understand why... my question: I had to change most of my type of the functions.as is propagated = through the code. (i.e. f need g; that need h; etc...) to add IO. is that kind of propagation normal, or can i Stop it somewhere ? how? is that because my functions just uses string as type ? and not data (ie = type relation =3Dstring; instead data Relation String) can i design a function that will do IO String-> String, or IO String -> = Data X, that will stop that IO propagation , through my code ? how can i handle function when my database is not IO, then ? i suppose im not the first to ask. any link ? thread ? faq example would = be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , = mainly String=20 -> [String], or similar with types, plus some more complex=20 datatypes. Up to now; i was testing them on a = basic database I=20 was creating in the core main, "by hand". Then i added a basic parser with happy; = and bingo;=20 my test database is now loaded from a file... as IO String..; = huh! after a second though; this makes = sense, except=20 that i have to change all the type of my functions; now IO = String.. plus a few that just dont compile; and = i cant=20 understand why... my question: I had to change most of my type of the = functions.as=20 is propagated through the code. (i.e. f need g; that need h; etc...) to = add=20 IO. is that kind of propagation normal, or = can i Stop=20 it somewhere ? how? is that because my functions just uses = string as=20 type ? and not data (ie type relation =3Dstring; instead data Relation=20 String) can i design a function that will do IO = String->=20 String, or IO String -> Data X, that will stop that IO propagation , = through=20 my code ? how can i handle function when my = database is not=20 IO, then ? i suppose im not the first to ask. any = link ?=20 thread ? faq example would be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0-- From khaliff@astercity.net Sun May 13 10:07:54 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Sun, 13 May 2001 11:07:54 +0200 (CEST) Subject: io monad question In-Reply-To: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> Message-ID: On Sun, 13 May 2001, luc wrote: > i designed some basic functions, , mainly String -> [String], or similar with types, plus some more complex datatypes. > > Up to now; i was testing them on a basic database I was creating in the core main, "by hand". > Then i added a basic parser with happy; and bingo; my test database is now loaded from a file... as IO String..; huh! > > after a second though; this makes sense, except that i have to change all the type of my functions; now IO String.. > > plus a few that just dont compile; and i cant understand why... > > my question: > I had to change most of my type of the functions.as is propagated through the code. (i.e. f need g; that need h; etc...) to add IO. > is that kind of propagation normal, or can i Stop it somewhere ? how? You can stop it at the very beginning: f :: String -> String g :: [A] -> [B] -- etc, any functions without IO parse :: [String] -> [ A ] main = do h <- openFile "sampleFile" ReadMode contents <- hGetContents h -- and now you have file contents binded to contents and you can apply your --functions any way you want, i. e. let result = g (parse contents) putStrLn (show result) Wojciech Moczydlowski, Jr From Ben Mon May 14 03:43:31 2001 From: Ben (Ben) Date: Sun, 13 May 2001 21:43:31 -0500 Subject: typing question Message-ID: <20010513214331.A16503@one.net> Hello, I hope that a question here wont be too much of a bother. Yesterday I wrote a library for polynomial manipulation. Everything is fine except for the composition operator. Which I having problems with, probably trivial, but as I don't program in Haskell everyday a solution isn't clear. I have my polynomials defined as: newtype Polynomial a = Polynomial [a] deriving (Eq) with toPolynomial :: (Num a) => [a] -> Polynomial a toPolynomial x = Polynomial x fromPolynomial :: Polynomial a -> [a] fromPolynomial (Polynomial x) = x instance Show a => Show (Polynomial a) where instance Num a => Num (Polynomial a) where... and defined appropriately I also have a function, degree :: Polynomial a -> Int but to be more pointed my question is related to, (@@) :: (Num a) => Polynomial a -> a -> a f @@ g = applyrec (fromPolynomial f) g 0 where applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 This was originally written to evaluate f at value, ie n \mapsto f(n). But I realized that this should also work for overloading, as my Polynomials are Nums. In hugs the following works fine, t = Polynomial [1,2,3] @@ Polynomial [3,2,1] but I suspect that there is a type conversion happening for me which I should be aware of as something like the following doesn't work, [ f @@ g | f <- poly, g <- poly, f /= g ] where poly is a list of polynomials gives me, *** Expression : f @@ g *** Term : f *** Type : Polynomial Integer *** Does not match : Polynomial (Polynomial Integer) so my question boils down to, how do I tell hugs/Haskell that Polynomials over Polynomials of Integers are just Polynomials of Integers or at least that this kind of composition is ok? I am not on this mailing list so please CC me any responses. Thank you. Ben. From Ben Mon May 14 04:02:47 2001 From: Ben (Ben) Date: Sun, 13 May 2001 22:02:47 -0500 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net>; from neb@one.net on Sun, May 13, 2001 at 09:43:31PM -0500 References: <20010513214331.A16503@one.net> Message-ID: <20010513220247.A16641@one.net> The following appears to work, (@\@) :: (Num a) => Polynomial a -> Polynomial a -> Polynomial a f @\@ g = applyrec pp g 0 where pp = map (\x -> toPolynomial [x]) (fromPolynomial f) applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 Sorry for the original email, although I would be interested in a better solution if there is any commentary. Ben. On Sun, May 13, 2001 at 09:43:31PM -0500, Ben wrote: > Hello, I hope that a question here wont be too much of a bother. > > Yesterday I wrote a library for polynomial manipulation. Everything is fine > except for the composition operator. Which I having problems with, probably > trivial, but as I don't program in Haskell everyday a solution isn't clear. ...etc. From Tom.Pledger@peace.com Mon May 14 03:35:14 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Mon, 14 May 2001 14:35:14 +1200 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net> References: <20010513214331.A16503@one.net> Message-ID: <15103.17506.714186.42965@waytogo.peace.co.nz> Ben writes: : | (@@) :: (Num a) => Polynomial a -> a -> a : | the following doesn't work, | [ f @@ g | f <- poly, g <- poly, f /= g ] | where poly is a list of polynomials gives me, | | *** Expression : f @@ g | *** Term : f | *** Type : Polynomial Integer | *** Does not match : Polynomial (Polynomial Integer) | | so my question boils down to, how do I tell hugs/Haskell that | Polynomials over Polynomials of Integers are just Polynomials of | Integers or at least that this kind of composition is ok? Your definition of (@@) looks OK. The only problem is that you've applied it to two arguments of the same type (f, g :: Polynomial Integer), which don't unify with the parameter types (Polynomial a and a). Hugs has compared the type of the second parameter (a) with the type of the second argument (Polynomial Integer), and applied the Most General Unifier (the substitution of Polynomial Integer for a). The details of the error message refer to what happened when it compared the types of the first argument and the first parameter. It's worth checking whether [ f @@ g | f <- poly, g <- poly, f /= g ] really means what you intended. From andyfugard@eircom.net Mon May 14 12:06:24 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 12:06:24 +0100 Subject: Permutations of a list Message-ID: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Hi all, I'm currently teaching myself a little Haskell. This morning I coded the following, the main function of which, permutate, returns all the permutations of a list. (Well it seems to at least!) insertAt :: a -> Int -> [a] -> [a] insertAt x i xs | i < 0 || i > length xs = error "invalid position" | otherwise = front ++ x:back where (front,back) = splitAt i xs insertAtAll :: a -> (Int,Int) -> [a] -> [[a]] insertAtAll x (i,j) xs | i > j = error "PRE: i <= j" | i == j = [insertAt x i xs] | otherwise = (insertAt x i xs):(insertAtAll x (i+1,j) xs) buildPermList :: a -> [[a]] -> [[a]] buildPermList x xs | length xs == 0 = [] | otherwise = list ++ buildPermList x (tail xs) where list = insertAtAll x (0, length curr) curr; curr = head xs permutate :: [a] -> [[a]] permutate xs | length xs == 0 = [[]] | otherwise = buildPermList (last xs) (permutate (init xs)) and some test runs.... Main> permutate "" [""] Main> permutate "a" ["a"] Main> permutate "ab" ["ba","ab"] Main> permutate "abc" ["cba","bca","bac","cab","acb","abc"] My main question is really what facilities of the language I should be looking at to make this code more elegant! As you can see I currently know only the basics of currying, and some list operations. Also regarding the method of generating the permutations; is there a better way? The current is just "Method 1" from Knuth's TAOCP, volume 1 (3rd edition), p45-46. Thanks in advance, Andy -- [ Andy Fugard /'andi fju:ga:d/ ] [ Phone: +44 (0)7901 603075 ] From ralf@informatik.uni-bonn.de Mon May 14 12:43:14 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Mon, 14 May 2001 13:43:14 +0200 Subject: Permutations of a list References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <3AFFC4D2.2114F872@informatik.uni-bonn.de> Andy Fugard wrote: > My main question is really what facilities of the language I should be > looking at to make this code more elegant! As you can see I currently know > only the basics of currying, and some list operations. Definitely list comprehensions! I digged out some old code: > module Perms where Permutations. > perms :: [a] -> [[a]] > perms [] = [ [] ] > perms (a : x) = [ z | y <- perms x, z <- insertions a y ] > > insertions :: a -> [a] -> [[a]] > insertions a [] = [ [a] ] > insertions a x@(b : y) = (a : x) : [ b : z | z <- insertions a y ] Using deletions instead of insertions; generates the permutations in lexicographic order, but is a bit slower. > perms' :: [a] -> [[a]] > perms' [] = [ [] ] > perms' x = [ a : z | (a, y) <- deletions x, z <- perms' y ] > deletions :: [a] -> [(a, [a])] > deletions [] = [] > deletions (a : x) = (a, x) : [ (b, a : y) | (b, y) <- deletions x ] Cheers, Ralf From andyfugard@eircom.net Mon May 14 13:02:14 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 13:02:14 +0100 Subject: Permutations of a list In-Reply-To: <3AFFC4D2.2114F872@informatik.uni-bonn.de> References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <5.1.0.14.0.20010514125913.00a78670@mail1.eircom.net> At 13:43 14/05/01 +0200, Ralf Hinze wrote: >Andy Fugard wrote: > > > My main question is really what facilities of the language I should be > > looking at to make this code more elegant! As you can see I currently know > > only the basics of currying, and some list operations. > >Definitely list comprehensions! I digged out some old code: [ ... ] Thanks for the quick response; that's much nicer! I think I'll have a look at list comprehensions.... Cheers, Andy From mechvel@math.botik.ru Mon May 14 13:05:13 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 16:05:13 +0400 Subject: permutations. Reply Message-ID: Andy Fugard writes > Hi all, > > I'm currently teaching myself a little Haskell. This morning I coded the > following, the main function of which, permutate, returns all the > permutations of a list. (Well it seems to at least!) > > [..] The BAL library implements several operations with permutations. In particular, it can list permutations by applying nextPermutation. You may look into the source and demonstration example: http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ ----------------- Serge Mechveliani mechvel@botik.ru From mechvel@math.botik.ru Mon May 14 14:44:15 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 17:44:15 +0400 Subject: CA proposal by D.Thurston Message-ID: I was said that there exists an algebraic library proposal for Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. Who could, please, tell me where to download this document from? For I could not find it from http://haskell.org Thanks in advance for the help. ----------------- Serge Mechveliani mechvel@botik.ru From herrmann@infosun.fmi.uni-passau.de Mon May 14 15:42:27 2001 From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann) Date: Mon, 14 May 2001 16:42:27 +0200 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <15103.61139.512952.903922@reger.fmi.uni-passau.de> Hi Haskellers, >>>>> "S" == S D Mechveliani writes: S> I was said that there exists an algebraic library proposal for S> Haskell (version 0.02) dated by February (2001?), by Dylan S> Thurston. that sounds interesting for me. Sorry, that I don't have an answer to your question, but I like to state some points about an algebraic library. A standard algebraic library has several advantages to many different tools developed by individual programmers: (1) One can benefit from the knowledge and experience of others (and of their work also, of course) (2) An open discussion process will help to avoid errors or difficulties in use (3) Programs written by others that use the library functions are more comprehensible I've got no impression of how such a library may look like and if the library is meant to be updated from time to time. Anyway, an algebraic library is important: it is nice that Haskell has the rational numbers but recently, it appeared useful for me also to have the algebraic numbers, e.g., to evaluate expressions containing roots exactly. The problem is that I'm not an expert in this stuff and thus, be very glad if such things are added by an expert. On the other hand, I'd like to add things like a linear equation solver for a non-invertible system which may help to convince people that Haskell provides more features than other programming languages do. Cheers Christoph From fjh@cs.mu.oz.au Mon May 14 18:01:32 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 15 May 2001 03:01:32 +1000 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <20010515030132.A4701@hg.cs.mu.oz.au> On 14-May-2001, S.D.Mechveliani wrote: > I was said that there exists an algebraic library proposal for > Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. > > Who could, please, tell me where to download this document from? > For I could not find it from http://haskell.org It was posted to the haskell-cafe list, and is available from the archives of that list: . -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From cwitty@newtonlabs.com Mon May 14 20:31:43 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 14 May 2001 12:31:43 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Sun, 13 May 2001 16:51:38 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010513165138B.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I didn't say that this works for any kind of parser > combinator, I merely said that it works Doitse's and mine. > Both implement SLL(1) parsers for which - as I am sure, you > know - there exists a decision procedure for testing > ambiguity. More precisely, whenever the library can build > the parse table, the grammar must be non-ambigious. As the > parse table construction is lazy, this covers only the > productions exercised in that particular run, which is why I > said that you need a "file involving all grammar constructs > of the language." Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty From mechvel@math.botik.ru Tue May 15 05:45:25 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 08:45:25 +0400 Subject: standard library. Reply Message-ID: Ch. A. Herrmann writes > [..] > Anyway, an algebraic library is important: > it is nice that Haskell has the rational numbers but recently, it > appeared useful for me also to have the algebraic numbers, e.g., > to evaluate expressions containing roots exactly. The problem is > that I'm not an expert in this stuff and thus, be very glad if > such things are added by an expert. > > On the other hand, I'd like to add things like a linear equation solver > for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. The BAL library http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ provides such linear solver, as well as operations with roots. For example, the root of x^5 - x + 1 can be handled (in many respects) in BAL as only a residue of polynomials modulo this equation - a data like (Rse ...(x^5-x+1))). But BAL is not a standard library. And there is another point: > [..] for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. In any case, we have to distinguish between a standard library and an application. A standard library should be small. I think, for Haskell, it should be something that you mention now. But, for example, the true algebraic number theory algorithms are too complex, it is for the non-standard application writers. And if a language is good, there should come many special applications (non-standard ones). Haskell's www page does reveal some. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mpj@cse.ogi.edu Tue May 15 08:16:10 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Tue, 15 May 2001 00:16:10 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon, | When you say there's a good theoretical foundation (typed lambda | calcului) I think you are imagining that when we say |=20 | f (x::a) =3D e |=20 | we are saying "There's a /\a as well as a \x::a in this definition". No, that's not what I'm thinking. When you say "f (x::a) =3D e", I'm reading it as meaning something like: "f =3D \(x::a).e". This is the typed lambda-calculus perspective that I was referring to. And, in such systems (whether simply typed or polymorphicly typed) the type annotation on the lambda bound variable x does not bind any type variables appearing in a. (And note that the type annotation may not contain any variables, or it could contain repeated uses of the same variable, etc...) Binding of type variables is a separate matter. It may be done by some kind of /\, either explicit or implicit. For the binding above, those variables would have to be bound somewhere, either added, implicitly to the binding of f, or else to some enclosing function. | But I'm suggesting something different |=20 | * Place the big lambdas wherever they would be now (i.e. not = influenced | by the position of (x::a) type signatures. |=20 | * Explain the pattern type signatures as let-bindings for types. Thus | we might translate f to system-F like this: |=20 | f =3D \x::T -> let-type a =3D T in e |=20 | I've use let-type here, but one could equally well say (/\a -> e) T. This is a different interpretation of type annotations than the one you'll find in many typed lambda-calculi. (That's a statement of fact rather than a judgment of merits.) In fact I'm not aware of any work on type systems like this. The simple translation that you give for let-type looks ok from the perspective of System-F, say. However, in the context of Haskell, I think it would be prudent to determine how it extends to and interacts with things like type inference, polymorphism, and overloading. Perhaps it would be worth considering a new language construct, such as: let-type expr :: type in expr with the intention that the first expr is not evaluated, but used to guide the binding of type variables in the "type" part, which would then be in scope in the second expression. This is a little more powerful than your let-type because it allows a kind of pattern matching on type expressions. But I don't know if this would be a well-behaved construct, or if it would be useful ... | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may = differ | about (b). I'm not persuaded about (a), I can't comment on (b), and I think there should be a third question: c) when is it useful? what holes does it fill? All the best, Mark PS. Aside ... if you'd like type variables in type annotations to be binding, then perhaps you'd also like them to work more like regular pattern bindings and to see functions like the following: f :: a -> b -> String f (x::a) (y::a) =3D "Yes, the arguments are the same type" f _ _ =3D "No, the arguments have different types" showList :: [a] -> String showList (xs::[Char]) =3D ... show a string enclosed in "'s ... showList xs =3D ... show list enclosed in [ ... ]s ... Who needs overloading anyway? :-) From mechvel@math.botik.ru Tue May 15 13:10:20 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 16:10:20 +0400 Subject: BAL paper available Message-ID: Paper announcement ------------------ The file http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip contains more expanded explanations on the BAL (Basic Algebra Library) project (previous variant was haskellInCA.ps.zip). My real intention in whole this line of business was always not just to propose a standard but rather to discuss and to find, what may be an appropriate way to program mathematics in Haskell. The matter was always in parametric domains ... Whoever tried to program real CA in Haskell, would agree that such a problem exists. ----------------- Serge Mechveliani mechvel@botik.ru From karczma@info.unicaen.fr Tue May 15 17:33:41 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Tue, 15 May 2001 18:33:41 +0200 Subject: BAL paper available References: Message-ID: <3B015A65.C87801F5@info.unicaen.fr> Serge Mechveliani : > > Paper announcement > ------------------ > > The file > http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip > > contains more expanded explanations on the BAL (Basic Algebra Library) > project > (previous variant was haskellInCA.ps.zip). > > My real intention in whole this line of business was always not just > to propose a standard but rather to discuss and to find, what may be > an appropriate way to program mathematics in Haskell. > The matter was always in parametric domains ... > Whoever tried to program real CA in Haskell, would agree that such a > problem exists. Absolutely. The point is that this seems - for various, perfectly understandable reasons - not to be the priority of the implementors. Graphics/imagery neither. Nor hard numeric work (efficient, easy to manipulate arrays). And now I will say something horrible. Despite my extremely deep respect for all people contributing to Haskell, despite my love for the language etc. I begin to suspect that it has been standardized too early, and if we (Sergey, other people interested in math, as Dylan Thurston, myself, etc., as well as people who want to do *serious* graphics in a functional way) want an adapted functional language, either we will have to wait quite long, or perhaps it is the time to invent another language, with a more dynamic type system, with intrinsic graphic utilities, and other goodies. For the moment - this is my personal viewpoint - it might be better to write concrete applications, and papers describing those applications. Then we shall perhaps know better what kind of structures, algorithms, representations, genericities, etc. we REALLY need for practical purposes. Anyway, Sergey did a formidable work, and this should be acknowledged even by those who on this list criticized his presentation. Thanks. Jerzy Karczmarczuk Caen, France From dpt@math.harvard.edu Tue May 15 19:14:02 2001 From: dpt@math.harvard.edu (Dylan Thurston) Date: Tue, 15 May 2001 21:14:02 +0300 Subject: BAL paper available In-Reply-To: <3B015A65.C87801F5@info.unicaen.fr>; from karczma@info.unicaen.fr on Tue, May 15, 2001 at 06:33:41PM +0200 References: <3B015A65.C87801F5@info.unicaen.fr> Message-ID: <20010515211402.B24804@math.harvard.edu> On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > Serge Mechveliani : > > ... > > My real intention in whole this line of business was always not just > > to propose a standard but rather to discuss and to find, what may be > > an appropriate way to program mathematics in Haskell. > > The matter was always in parametric domains ... > > Whoever tried to program real CA in Haskell, would agree that such a > > problem exists. Can you be more precise what the problem is? One problem I see is that referred to in Section 3 of the paper: you really need types that depend on parameters (in particular, integer parameters). This is, indeed, a problem--currently, you have to do runtime checks. Full-fledged dependent types à la Cayenne are undecidable, but there are weaker variants that are likely to be good enough. > The point is that this seems - for various, perfectly understandable > reasons - not to be the priority of the implementors. > Graphics/imagery neither. > Nor hard numeric work (efficient, easy to manipulate arrays). If I understand correctly, Marcin Kowalczyk is working on exactly this last point... > Despite my extremely deep respect for all people contributing to > Haskell, despite my love for the language etc. I begin to suspect > that it has been standardized too early, and if we [...] want an > adapted functional language, either we will have to wait quite long, > or perhaps it is the time to invent another language, with a more > dynamic type system, with intrinsic graphic utilities, and other > goodies. For myself, I don't see a problem here. For "intrinsic graphic utilities", someone has to write the graphic libraries. (You don't mean they should be built into the language, do you?) The type system is about as strong as anyone knows how to make a static type system; and it's not too hard to fall back on run-time type checking when necessary (as Sergey does in BAL). > Anyway, Sergey did a formidable work, and this should be acknowledged even > by those who on this list criticized his presentation. Thanks. Yes, absolutely. I think perhaps some things could be done better (for instance, I see that all Sergey's classes derive from Eq, which is one of my principal complaints with the Haskell 98 classes), but I appreciate the work and want to study it more. Best, Dylan Thurston From qrczak@knm.org.pl Tue May 15 20:11:49 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 19:11:49 GMT Subject: BAL paper available References: Message-ID: Tue, 15 May 2001 16:10:20 +0400, S.D.Mechveliani pisze: > The matter was always in parametric domains ... The solution is simple: don't model domains as types. Model them as values (records with operations). Some simple domains can be also modelled as types for convenience. But it doesn't work in general. Similarly as standard sort :: (Ord a) => [a] -> [a] is not as expressive as soryBy :: (a -> a -> Ordering) -> [a] -> [a] even though it's more convenient in case it works. It doesn't work when various instances of the same kind of algebraic structure over the same carrier set are considered. And it doesn't work when a domain should be parametrized by something which is hard to express by a type. And it constrains programs which want to choose the domain dynamically. Carrier sets are modelled as types, OK. But it won't work for all algebraic structures. About program transformation possibility: I don't see how it would be applied in practice. There is no use of associativity of (+) for the compiler. It can do many optimizations, but it won't rewrite x+(y+z) to (x+y)+z nor vice versa. Sample arguments are ugly, almost always unnecessary, and constrain interfaces (functions like 'sum :: Num a => [a] -> a' would have to have a different intreface). They are a solution to a wrong problem: some domains should not have been modelled as types in the first place. Algebraic operations don't belong to elements of algebras; they belong to algebras. In simple cases they can be deduced from the types of elements if the given carrier has a reasonable default interpretation of these operations (e.g. (+) on Integers), but it's not general. I don't believe that dependent types would come into Haskell in the near future. And they are unnecessary for the discussed purpose: domains which would require them should not be modelled as types. Don't abuse types to model values. Haskell's types are too static for that. The class hierarchy is unacceptable for me as standard Haskell. It's way too complex. Currently I have to define instances of Eq, Show, Num and Fractional to have field operations. With BAL I would have to define instances of Eq, Show, Set, Additive, AddSemigroup, AddGroup, Multiplicative, MulSemigroup, Ring, CommutativeRing, GCDRing, EuclideanRing, FactorizationRing and Field. They require such things as specifying an arbitrarily chosen set of properties of the domain and partially defined versions of most operations... The hierarchy contains many unnecessary superclass relationships. For example Show, specifying bounds and conversion from 'Expression String' are not necessary for Ord, where your classes artificially require them. There are no class synonyms in Haskell, so classes like OrdAddGroup can't be treated as implicit. Later parts are too heavy for me to understand them well, but I see some ugly points, like abusing Char arguments to virtually extend the function name, or requirement to provide reflection capabilities at the very beginning by every type wanting to use overloading of basic operations, or requirement that the programmer knows more advanced math than should be necessary to use Haskell. I hope that a similar proposal won't go into standard Haskell. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Tue May 15 21:05:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 20:05:47 GMT Subject: BAL paper available References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: >> Nor hard numeric work (efficient, easy to manipulate arrays). > > If I understand correctly, Marcin Kowalczyk is working on exactly > this last point... Well, I improved efficiency of ghc's arrays by removing various unnecessary overheads and I'm working on a generic interface of collections, but I don't have any deeper plans about arrays. What should be improved compared to existing STUArray Int Double and similar? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From conal@microsoft.com Tue May 15 21:44:03 2001 From: conal@microsoft.com (Conal Elliott) Date: Tue, 15 May 2001 13:44:03 -0700 Subject: BAL paper available Message-ID: Small comment. Marcin wrote: > About program transformation possibility: I don't see how it would > be applied in practice. There is no use of associativity of (+) for > the compiler. It can do many optimizations, but it won't rewrite > x+(y+z) to (x+y)+z nor vice versa. Associativity and commutativity (AC) are not optimizations in themselves, but rather enable optimizations if you have an AC matcher in your rewriting system (as, for instance, in Mathematica). - Conal From khaliff@astercity.net Tue May 15 21:31:40 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Tue, 15 May 2001 22:31:40 +0200 (CEST) Subject: BAL paper available In-Reply-To: Message-ID: On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: > > >> Nor hard numeric work (efficient, easy to manipulate arrays). > > > > If I understand correctly, Marcin Kowalczyk is working on exactly > > this last point... > > Well, I improved efficiency of ghc's arrays by removing various > unnecessary overheads and I'm working on a generic interface > of collections, but I don't have any deeper plans about arrays. > > What should be improved compared to existing STUArray Int Double > and similar? > > QRCZAK A simple standard proposal, not using ST and multiparameter type classes, so that it would be possible to implement it in other compilers (namely nhc), would be a great improvement for me. Wojciech Moczydlowski, Jr From matth@mindspring.com Wed May 16 00:43:28 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 15 May 2001 18:43:28 -0500 Subject: Ix class Message-ID: <3B01BF20.952F55FE@mindspring.com> Hello, I am working on an Ix instance for one of my types and finding it rather restrictive. For me it would be useful to have rangeSize be defined in the Ix class (with a default definition of course), so that it can be overridden. Also, does anybody know why Ix derives from Ord? It seems to me this is an unnecessary limitation on the types that can be instances of Ix. I cannot think of a reason why the implementation of anything in the Ix or Array modules would require that every Ix be an Ord (with a minor exception -- see below). If an implementation is using a comparison on an Ix type, chances are it should be using inRange or comparing (index bnds x) with (index bnds y) instead. One change would have to be made in the Array module if Ord is removed from Ix: instance (Ix a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' would become: instance (Ix a, Eq a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' As I said, I think this is a very minor issue. I believe that making these changes in the standard would not impact existing programs in any way. Could these changes be considered as a possible "typo" to be fixed in the Library Report? P.S. In case anybody's interested, here's why I want to override rangeSize: > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) > > indexError = error "Index out of range" > > instance Ix Honeycomb where > range (Hx b1, Hx b2) = > [Hx x | x <- range (b1,b2), isHexIx x] > inRange (Hx b1, Hx b2) (Hx x) = > inRange (b1,b2) x && isHexIx x > index (Hx b1, Hx b2) (Hx x) = > let i = index (b1,b2) x in > if isHexIx x then i `div` 2 else indexError > > isHexIx :: (Int,Int) -> Bool > isHexIx (x,y) = x `mod` 2 == y `mod` 2 This implements a honeycomb or hexagonal tiling for a maze generating program. The honeycomb is superimposed on a grid such that only every other square is "active", corresponding to a particular hexagon in the honeycomb. It's similar to a checkers game, where only the dark squares are used. I would like _any_ pair of Ints to be an acceptable boundary for the honeycomb, not just the ones that represent valid indexes. For example, (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current definition of rangeSize makes this impossible, which is why I would like to override it. By the way, the Library Report does not explicitly say that the bounds have to both be valid indexes, though it does imply this with the sample definition of rangeSize. Thanks, Matt Harden From jans@numeric-quest.com Tue May 15 20:08:38 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Tue, 15 May 2001 15:08:38 -0400 (EDT) Subject: Ix class In-Reply-To: <3B01BF20.952F55FE@mindspring.com> Message-ID: On Tue, 15 May 2001, Matt Harden wrote: [..] > I would like _any_ pair of Ints to be an acceptable boundary for the > honeycomb, not just the ones that represent valid indexes. For example, > (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current > definition of rangeSize makes this impossible, which is why I would like > to override it. By the way, the Library Report does not explicitly say > that the bounds have to both be valid indexes, though it does imply this > with the sample definition of rangeSize. There is an old article [1], that is somehow related to what you do. Looks like it could add some extra fuel to your arguments if re-examined in terms of current Haskell. [It might be also interesting to those discussing arrays in the other thread.] Jan [1] D.B. Carpenter, Some Lattice-based Scientific Problems, Expressed in Haskell, http://citeseer.nj.nec.com/157672.html From sk@mathematik.uni-ulm.de Wed May 16 06:38:06 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 16 May 2001 07:38:06 +0200 Subject: BAL paper available In-Reply-To: <20010515211402.B24804@math.harvard.edu>; from dpt@math.harvard.edu on Tue, May 15, 2001 at 09:14:02PM +0300 References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > Serge Mechveliani : > > > ... > > > The matter was always in parametric domains ... > > > Whoever tried to program real CA in Haskell, would agree that such a > > > problem exists. > > Can you be more precise what the problem is? One problem I see is > that referred to in Section 3 of the paper: you really need types that > depend on parameters (in particular, integer parameters). This is, > indeed, a problem--currently, you have to do runtime checks. > > Full-fledged dependent types à la Cayenne are undecidable, but there > are weaker variants that are likely to be good enough. What are the weaker variants? Do you know some references? Are they still decidable? That surprises me. If you allow integer arithmetic you can do already all computations (Church). -- Stefan Karrmann From fjh@cs.mu.oz.au Wed May 16 07:16:08 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 16:16:08 +1000 Subject: BAL paper available In-Reply-To: References: Message-ID: <20010516161608.A22442@hg.cs.mu.oz.au> On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > What should be improved compared to existing STUArray Int Double > > and similar? > > A simple standard proposal, not using ST and multiparameter type classes, > so that it would be possible to implement it in other compilers (namely nhc), > would be a great improvement for me. I think multiparameter type classes or other extensions to Haskell 98 are really needed to solve these kinds of problems in a simple and elegant way. The right solution, IMHO, is to extend nhc and other Haskell compilers to support multiparameter type classes, not to try to shoehorn things that don't fit into Haskell 98. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From khaliff@astercity.net Wed May 16 08:18:01 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Wed, 16 May 2001 09:18:01 +0200 (CEST) Subject: BAL paper available In-Reply-To: <20010516161608.A22442@hg.cs.mu.oz.au> Message-ID: On Wed, 16 May 2001, Fergus Henderson wrote: > On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > > What should be improved compared to existing STUArray Int Double > > > and similar? > > > > A simple standard proposal, not using ST and multiparameter type classes, > > so that it would be possible to implement it in other compilers (namely nhc), > > would be a great improvement for me. > > I think multiparameter type classes or other extensions to Haskell 98 are > really needed to solve these kinds of problems in a simple and elegant way. > > The right solution, IMHO, is to extend nhc and other Haskell compilers > to support multiparameter type classes, not to try to shoehorn things > that don't fit into Haskell 98. > > Fergus Henderson | "I have always known that the pursuit I don't like the idea of a program working which compiles only under compilers which have certain language extensions built in. If I understand things correctly, there is a list of language extensions (FFI for example), which has been accepted by all Haskell compilers developers. If multiparameter type classes were in that list, I would agree. Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification. I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps. By the way, I'm really surprised by the lack of time complexity information in MArray. I mean, that's the most important thing in arrays - that one can update/read a data in O(1). Wojciech Moczydlowski, Jr From fst@informatik.uni-kiel.de Wed May 16 09:30:57 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Wed, 16 May 2001 10:30:57 +0200 Subject: WFLP 2001 deadline extension to May 22, 2001 Message-ID: <200105160830.KAA02124@listrac.informatik.uni-kiel.de> Due to various requests, the DEADLINE FOR SUBMISSIONS to WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming Kiel, Germany, September 13-15, 2001 http://www.informatik.uni-kiel.de/~wflp2001 has been EXTENDED TO MAY 22, 2001. From ashley@semantic.org Wed May 16 09:39:08 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 16 May 2001 01:39:08 -0700 Subject: BAL paper available Message-ID: <200105160839.BAA01875@mail4.halcyon.com> At 2001-05-16 00:18, Wojciech Moczydlowski, Jr wrote: >> I think multiparameter type classes or other extensions to Haskell 98 are >> really needed to solve these kinds of problems in a simple and elegant way. >> >> The right solution, IMHO, is to extend nhc and other Haskell compilers >> to support multiparameter type classes, not to try to shoehorn things >> that don't fit into Haskell 98. >I don't like the idea of a program working which compiles only under >compilers which have certain language extensions built in. > >If I understand things correctly, there is a list of language extensions >(FFI for example), which has been accepted by all Haskell compilers >developers. If >multiparameter type classes were in that list, I would agree. I tend to share Fergus Henderson's viewpoint. I see a Haskell with multiparameter type classes as a language I want to work with, and it would be great to have libraries written for that. I'm less interested in Haskell 98, since it means muckier solutions to the same problems. -- Ashley Yakeley, Seattle WA From simonmar@microsoft.com Wed May 16 09:36:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Wed, 16 May 2001 09:36:56 +0100 Subject: BAL paper available Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> >=20 > I don't like the idea of a program working which compiles only under > compilers which have certain language extensions built in.=20 >=20 > If I understand things correctly, there is a list of language=20 > extensions > (FFI for example), which has been accepted by all Haskell=20 > compilers developers. If > multiparameter type classes were in that list, I would agree. >=20 > Besides, MArray.lhs uses ST and ST requires not only=20 > multiparameter type > classes, but also explicit universal quantification. ST doesn't require multiparameter type classes (although MArray does). It also doesn't require full support for explicit universal quantification, if runST is known to the compiler. Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types. > I don't like ST and the idea that someone who wants to use arrays > outside of IO has to use ST gives me creeps.=20 What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?). > By the way, I'm really surprised by the lack of time=20 > complexity information > in MArray. I mean, that's the most important thing in arrays=20 > - that one can > update/read a data in O(1).=20 Point taken, I'll update the documentation to include more of this info. Cheers, Simon From S.J.Thompson@ukc.ac.uk Wed May 16 11:32:01 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Wed, 16 May 2001 11:32:01 +0100 Subject: Book reviewers for Journal of Functional Programming Message-ID: I am looking for book reviewers for the Journal of Functional Programming. Book reviews provide a service to the functional programming community by critically appraising many of the key books coming out in the field. If you are interested in becoming a reviewer, please send me an email with - A two sentence biography. - Your particular reviewing interests (e.g. teaching texts, books on ML, etc.) Current books up for review include Trends in Functional Programming edited by Greg Michaelson, et al Intellect Books, 1999 Trends in Functional Programming vol 2 edited by Stephen Gilmore Intellect Books, 2000 How to Design Programs by Felleisen et al MIT Press, 2001 Objective Caml Pascal Manoury and Bruno Pagano O'Reilly, 2000 Principles of Programming Languages Bruce Maclennan Oxford University Press, 1999 so let me know if you are interested in reviewing one of these, or indeed please make any suggestions about books you would like to see reviewed. You can find guidelines for writing JFP book reviews at http://www.dcs.gla.ac.uk/jfp/guidelines.html Thanks very much, Simon Thompson s.j.thompson@ukc.ac.uk From Dominic.J.Steinitz@BritishAirways.com Wed May 16 11:42:22 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 16 May 2001 10:42:22 Z Subject: Integers to Ints Message-ID: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can someone explain the following behaviour? Or is it a bug in hugs? X690v5> (fromIntegral(toInteger(minBound::Int))::Int) Program error: {primIntegerToInt (-2147483648)} (15 reductions, 70 cells) X690v5> (fromIntegral(toInteger((minBound::Int)+1))::Int) -2147483647 (21 reductions, 29 cells) X690v5> minBound::Int -2147483648 (9 reductions, 19 cells) Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From rjchaaft@cs.uu.nl Wed May 16 11:54:12 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 16 May 2001 12:54:12 +0200 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <4.3.0.20010516125151.00b2f3c8@pop.students.cs.uu.nl> Hello, >Can someone explain the following behaviour? Or is it a bug in hugs? I can not explain it. Rather strange is that even this is allowed: (fromIntegral (toInteger (minBound::Int) + 1) -1) :: Int yielding -2147483648 > > (fromIntegral(toInteger(minBound::Int))::Int) > >Program error: {primIntegerToInt (-2147483648)} >(15 reductions, 70 cells) > > > (fromIntegral(toInteger((minBound::Int)+1))::Int) >-2147483647 >(21 reductions, 29 cells) > > > minBound::Int >-2147483648 >(9 reductions, 19 cells) From C.T.McBride@durham.ac.uk Wed May 16 13:03:25 2001 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Wed, 16 May 2001 13:03:25 +0100 (BST) Subject: BAL paper available In-Reply-To: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: On Wed, 16 May 2001, Stefan Karrmann wrote: > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > Serge Mechveliani : > > > > ... > > > > The matter was always in parametric domains ... > > > > Whoever tried to program real CA in Haskell, would agree that such = a > > > > problem exists. > >=20 > > Can you be more precise what the problem is? One problem I see is > > that referred to in Section 3 of the paper: you really need types that > > depend on parameters (in particular, integer parameters). This is, > > indeed, a problem--currently, you have to do runtime checks. > >=20 > > Full-fledged dependent types =E0 la Cayenne are undecidable, but there > > are weaker variants that are likely to be good enough. >=20 > What are the weaker variants? Do you know some references? > Are they still decidable? That surprises me. If you allow integer > arithmetic you can do already all computations (Church). The idea that `dependent types are undecidable' is a popular but understandable misconception arising from a particular design decision in a particular system---Cayenne. Dependent types as found in proof systems such as Coq and Lego do have decidable typechecking: programs may only use structural recursion, and hence all the evaluation which takes place during typechecking is guaranteed to terminate. However, in order to support real programming, Cayenne allows general recursion: as it makes no distinction between the programs which are executed at compile-time and those only executed at run-time, undecidability creeps in. Understandably, neither horn of this dilemma is particularly attractive to programmers who want to combine flexibility at run-time with a genuinely static notion of typechecking.=20 (Of course, post-98 Haskell with certain type class options selected has a type-level language containing non-terminating programs, making typechecking undecidable for exactly the same reason as in Cayenne.) However, there is a middle way: we can distinguish compile-time programs from run-time programs and restrict the former to the structurally recursive fragment, leaving general recursion available in the latter.=20 In this way, all the programs we know and love remain available at run-time, whilst the type system acquires a large yet decidable extension to its expressive power. The key is the application rule, for it is here that programs leak into types. G |- f :: all x::S . T G |- s :: S -------------------------------------- G |- f s :: [s/x]T If s is potentially non-terminating, typechecking becomes undecidable: [s/x]T may not have a normal form.=20 Now let's separate compile-time programs (typed with `|-') from run-time programs (typed with `/-', say). Restricting the compile-time language to structural recursion, the above rule poses no threat. We can add G |- t :: T ------------- (a compile-time program is a run-time program) G /- t :: T G /- f :: all x::S . T G |- s :: S -------------------------------------- x free in T G /- f s :: [s/x]T G /- f :: S -> T G /- s :: S -------------------------------- (S -> T abbreviates all x::S. T G /- f s :: T when x is not free in T) G /- f :: T -> T -------------------- (fixpoint) G /- Y f :: T -> T compile-time structurally recursive programs, extending with general recursion only at run-time. Typechecking is thus decidable, with all your old code intact.=20 Structural recursion is a syntactically checkable notion which allows a large, but obviously not complete language of terminating programs to be recognized as such. How large? Well, first-order unification is structurally recursive, and so is normalization for simply-typed lambda-calculus. As decidable type systems go, this one is better than a poke in the eye.=20 I respectfully suggest that dependent types are worth a second look. Cheers Conor From fjh@cs.mu.oz.au Wed May 16 13:27:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 22:27:18 +1000 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> References: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <20010516222718.A23867@hg.cs.mu.oz.au> On 16-May-2001, Steinitz, Dominic J wrote: > Can someone explain the following behaviour? Or is it a bug in hugs? It looks to me very much like it is a bug in Hugs. ghc 4.04 does not suffer from this bug. It's easy to make mistakes like this, which can often arise from forgetting the assymetric nature of twos-complement signed integers, which have more negative numbers than positive numbers. We once had a similar kind of bug in the Mercury standard library implementation, where string__to_int was not handling the most negative integer correctly. We fixed that one in March 1998. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Wed May 16 11:35:24 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 03:35:24 -0700 Subject: BAL paper available Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F2E@red-msg-09.redmond.corp.microsoft.com> | Despite my extremely deep respect for all people contributing=20 | to Haskell, despite my love for the language etc. I begin to=20 | suspect that it has been standardized too early, and if we=20 | (Sergey, other people interested in math,=20 | as Dylan Thurston, myself, etc., as well as people who want=20 | to do *serious* graphics in a functional way) want an adapted=20 | functional language, either we will have to wait quite long,=20 | or perhaps it is the time to invent another language, with a=20 | more dynamic type system, with intrinsic graphic utilities,=20 | and other goodies. For the moment - this is my personal=20 | viewpoint - it might be better to write concrete=20 | applications, and papers describing those applications. Then=20 | we shall perhaps know better what kind of structures,=20 | algorithms, representations, genericities, etc. we REALLY=20 | need for practical purposes. H98 is standardised, but Haskell certainly isn't. GHC and Hugs both have numerous extensions. So I don't think standardisation is a difficulty. The availability of implemention effort certainly is. But even before that, to implement something one needs a good clear specification, and preferably one that several people subscribe to (i.e. agree with the need and the design of the extension to meet that need). My guess is that the lacks you allude are due not to standardisation, nor to implementation effort, but rather to the lack of design/specfication. If there are things you want, perhaps you can contribute to a design for that thing? (Of course, the existence of a design doesn't guarantee an implementation; implementation effort is certainly an issue. But the absence of a design more or less guarantees the absence of an implementation.) I too have a great respect for the work that Sergey, Jerzy and others=20 have been doing. Indeed I don't understand the half of it. I hope I don't even need to understand it because it's a Haskell library. But not understanding it leaves me badly placed to know what the language difficulties are and maybe there are others in my position. Simon From simonpj@microsoft.com Wed May 16 15:26:42 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 07:26:42 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F3A@red-msg-09.redmond.corp.microsoft.com> | | When you say there's a good theoretical foundation (typed lambda | | calcului) I think you are imagining that when we say | |=20 | | f (x::a) =3D e | |=20 | | we are saying "There's a /\a as well as a \x::a in this definition". |=20 | No, that's not what I'm thinking.=20 OK, let me try to give some type rules for what I have in mind. In these rules, I'm going to have an environment, T, that binds user type variables to types. (A "user type variable" is a type variable that appears in the program text.) There is still a conventional type environment, G (usually written=20 Greek Gamma), that associates user term variables with their types. I'll just deal with type variables in lambda patterns, like \ (x::a) -> E Here's the rule: x_i =3D free-term-vars(pat) a_i =3D free-type-vars(pat) \ T (T, a_i=3Dtaua_i); (G, x_i:taux_i) |- pat : tau_1 (T, a_i=3Dtaua_i); (G, x_i:taux_i) |-- E : tau_2 ------------------------------------------------------- T;G |- \pat -> E : tau_1 -> tau_2 The a_i are the type variables brought into scope by the pattern; namely the free type variable of the pattern which are not already in scope (hence the \ T). The T environment is extended by binding each user type variable a_i to a type taua_i that is gotten out of thin air (as is common in type rules). This new T env is used when typechecking the pattern itself and the body E. The intereesting bit is how to typecheck patterns, and type inside them: T;G |- pat : tau T |- ty : tau ----------------- T;G |- pat::ty : tau That is, to typecheck the pattern (pat::ty), typecheck pat and typecheck ty. The judgement T |- ty : tau checks that the user type ty is well formed with type tau. The key rule of this judgement looks up a type variable in T: ----------------- T |- a : T(a) OK, that's it. The point is simply that the user type variables are regarded as the name of a type; the programmer doesn't specify just what that type is. The type rules just 'inline' the type wherever the name is used. All this translates into completely unmodified System F. =20 | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may=20 | differ about (b). This message is really just a second attempt at (a) Simon From khaliff@astercity.net Wed May 16 23:19:23 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Thu, 17 May 2001 00:19:23 +0200 (CEST) Subject: BAL paper available In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: On Wed, 16 May 2001, Simon Marlow wrote: > > Besides, MArray.lhs uses ST and ST requires not only > > multiparameter type > > classes, but also explicit universal quantification. > > ST doesn't require multiparameter type classes (although MArray does). You're of course right. > It also doesn't require full support for explicit universal > quantification, if runST is known to the compiler. So it's another thing to put inside a compiler? > Also, the ST array types are really an optional part of the MArray > interface - it works perfectly well with just the IO array types. Perhaps. It just shows that the module was created specifically for ghc. > > I don't like ST and the idea that someone who wants to use arrays > > outside of IO has to use ST gives me creeps. > > What would you suggest as an alternative? I suppose you could have a > monad which just supported a single array, but special-purpose monads > tend to be a pain in practice (eg. what happens when you want two > arrays?). I'd rather have a monad which just supports a single array as a standard and IO/STArray as a language extension, than the other way. You could tell the same about MonadState. And I've never needed to use ST - somehow MonadState was always enough. And I vaguely remember some problems with typing when I tried to use ST once. IOArray is better - though it is unnatural to be forced to use IO whenever one wants to do something on arrays. So, in the end, if I were to choose between STArray, IOArray and a monad with a single array, I'd choose the monad. Though the best solution probably would be to support all of them. I don't know how the TODO list of nhc developers looks like, but if they aren't implementing multiparameter type classes now, it probably (disclaimer: I am not a Haskell compiler developer) would be easier to implement a simple monad, than type classes + ST. > Simon Wojciech Moczydlowski, Jr From karczma@info.unicaen.fr Thu May 17 07:49:48 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 08:49:48 +0200 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <3B03748C.D65FDD19@info.unicaen.fr> Dylan Thurston cites : > > ... if we [...] want an > > adapted functional language, either we will have to wait quite long, > > or perhaps it is the time to invent another language, with a more > > dynamic type system, with intrinsic graphic utilities, and other > > goodies. > > For myself, I don't see a problem here. For "intrinsic graphic > utilities", someone has to write the graphic libraries. (You don't > mean they should be built into the language, do you?) The type system > is about as strong as anyone knows how to make a static type system; > and it's not too hard to fall back on run-time type checking when > necessary (as Sergey does in BAL). Look what happens with functional graphics. Dozens of really good papers, I could mention many names here. (Some bad papers as well, some people formalize and formalize without any contact with reality...) So, one may want to check all this. You take Alastair Reid's Hugs graphic library, and you discover that: The IO monadic framework is so rigid that you program imperatively, and after a few minutes you ask yourself why for goodness sake do it in Haskell? The programming style is not functional at all. In C++ or Java you do it faster and without more pain. (From the syntactic point of view this is a step backward wrt. the Henderson's book showing how to compose graphics objects in Scheme...) You can't draw individual pixels. (OK, lines with length 1 work). So, impossible to create complicated textures. Impossible to generate complex geometric models rendered pixel by pixel. Try, please, to fill a rectangle with a texture. The graphic updates by the Draw monad will explode the memory quite fast. No relation between bitmaps and arrays. (If the bitmaps work at all.) Similar problems are visible in the Clean library. Both, Hugs and Clean libraries have been added ad hoc to the language environment. Plenty of horrible Windows quirks squeezed into a functional interface. What I mean by *intrinsic* graphics: The graphic primitives should be WELL integrated with the underlying virtual machine. No silly "external" bitmaps impossible to garbage-collect, and impossible to process (thresholding, transfer curves, algebra). No pixels drawn using "line". True, fast access to primitive data. Efficient 2dim and 3dim vectors, with optimized processing thereof. Mapped arrays, easy passage from screen to bitmap DContext. Possibility to have decent functional binding of OpenGL calls. And mind you, OpenGL is not just a bunch of graphic calls, but a "state machine". Some graphic data must be processed by strict algorithms, laziness may deteriorate the efficiency considerably. No, this is not JUST the problem of external libraries. It would be, if the language were at the level of, say, C. But if the runtime is complex with plenty of dynamical data to protect and to recover, and if the internal control transfer is non-trivial (continuations, private stacks, etc.) then adding efficient and powerful graphics <> is not easy. === In my opinion one of best decisions taken by the Rice mafia was to base the DrScheme interface on WxWindows. What a pleasure to produce graphic exercises for students under Linux, test it under Solaris, and work with them under W2000 without a single incompatibility. I am still unhappy, because it is too slow to generate textures at a respectable rate, but no comparison with Hugs which bombs. But perhaps the next version (if ...) will optimize a few things. === And, if you want to have *interactive* graphics, then obviously you must provide some kind of event-processing functionalities. Is this just an external library question? ****************************** No place to discuss type systems here, but "falling back" into run-time checks is not enough in this context, we know that we need a genuine object-oriented genericity for graphical entities. Perhaps even with multiple inheritance or the java-style "interfaces". So, again, a bit more than just "graphic library". Jerzy Karczmarczuk Caen, France From timd@macquarie.com.au Thu May 17 08:42:14 2001 From: timd@macquarie.com.au (Timothy Docker) Date: Thu, 17 May 2001 17:42:14 +1000 (EST) Subject: BAL paper available >> graphic libraries In-Reply-To: <3B03748C.D65FDD19@info.unicaen.fr> References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> Message-ID: <15107.31057.395890.996366@tcc2> Jerzy Karczmarczuk writes: [Some interesting points on functional wrappings of graphics libraries] Has anyone considered writing a haskell wrapper for SDL - Simple Directmedia Layer at http://www.libsdl.org ? This is a cross platform library intended for writing games, and aims for a high performance, low level API. It would be interesting to see how clean a functional API could be built around such an imperative framework. Tim From holzmueller@ics-ag.de Thu May 17 09:06:55 2001 From: holzmueller@ics-ag.de (Bernd =?iso-8859-2?Q?Holzm=FCller?=) Date: Thu, 17 May 2001 10:06:55 +0200 Subject: Proposal for generalized function partition in List-library Message-ID: <3B03869F.88D5EF9D@ics-ag.de> Hi all, knowing that the Haskell library report is currently being rewritten, I would like to propose a new function for module List that generalizes the current function partition :: (a -> Bool) -> [a] -> [[a]] in the following way: partition :: Eq b => (a -> b) -> [a] -> [[a]] partition _ [] = [] partition f (a:as) = let (as',as'') = foldr (select (f a)) ([],[]) as in (a:as'):partition f as'' where select b x (ts,fs) | f x == b = (x:ts,fs) | otherwise = (ts,x:fs) This partitioning function builds equivalence classes from the list argument, where each element list within the result list consists of elements that all map to the same value when applying f to it. Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] This is much more general than the existing partitioning function and applicable in many practical cases. Cheers, Bernd Holzmüller From bedloose@hotmail.com Thu May 17 09:25:10 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:25:10 +0200 (CEST) Subject: Monads Message-ID: <20010517082510.32473.qmail@web14306.mail.yahoo.com> Hi I'v currently working on a school-project where I have to describe the Haskell programming language. I've been looking through Monads and especially the IO monad, the Maybe monad and the list monad My question is why are monads necessary in the language ? Is it not possible to construct the features provided by Monads using basic functional constructs ? What do I gain using Monads ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From ashley@semantic.org Thu May 17 09:41:11 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 01:41:11 -0700 Subject: Monads Message-ID: <200105170841.BAA08310@mail4.halcyon.com> At 2001-05-17 01:25, Mads Skagen wrote: >My question is why are monads necessary in the >language ? > >Is it not possible to construct the features provided >by Monads using basic functional constructs ? Monads themselves are made purely out of basic functional constructs. >What do I gain using Monads ? They happen to be a very convenient pattern. Mostly they're used to model imperative actions: while a purely functional language cannot actually execute actions as part of its evaluation, it can compose them, along the lines of "AB is the action of doing A, and then doing B with its result". Monads happen to be a useful pattern for such things. -- Ashley Yakeley, Seattle WA From bedloose@hotmail.com Thu May 17 09:47:50 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:47:50 +0200 (CEST) Subject: Monads Message-ID: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Thank you for your reply. So what you are saying is that I actually don't need Monads to perform the tasks Monads supports ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From karczma@info.unicaen.fr Thu May 17 10:03:22 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 11:03:22 +0200 Subject: Monads References: <200105170841.BAA08310@mail4.halcyon.com> Message-ID: <3B0393DA.8A105FD7@info.unicaen.fr> Ashley Yakeley answer to Mads Skagen: > >My question is why are monads necessary in the > >language ? > > > >Is it not possible to construct the features provided > >by Monads using basic functional constructs ? > > Monads themselves are made purely out of basic functional constructs. > > >What do I gain using Monads ? > > They happen to be a very convenient pattern. Mostly they're used to model > imperative actions: while a purely functional language cannot actually > execute actions as part of its evaluation, it can compose them, along the > lines of "AB is the action of doing A, and then doing B with its result". > Monads happen to be a useful pattern for such things. PLEASE!!! I disagree quite strongly with such severely limited answers addressed to people who don't know about monads. Monads are *much* more universal than that. They are "convenient patterns" to code the non-determinism (lazy list monads), to generalize the concept of continuations, to add tracing, exceptions, and all stuff called "computation" by the followers of Moggi. They are natural thus to construct parsers. Imperative programming is just one facet of the true story. Mads Skagen: please read the paper by Wadler on the essence of functional programming, and other stuff picked, say, from here: http://hypatia.dcs.qmw.ac.uk/SEL-HPC/Articles/FuncArchive.html That's right you don't really NEED monads (unless you are forced to do IO...), but when you learn them you will feel better and older. Jerzy Karczmarczuk Caen, France From ashley@semantic.org Thu May 17 10:12:16 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 02:12:16 -0700 Subject: Monads Message-ID: <200105170912.CAA09737@mail4.halcyon.com> At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: >Monads are *much* more universal than that. They are "convenient patterns" >to code the non-determinism (lazy list monads), to generalize the concept >of continuations, to add tracing, exceptions, and all stuff called >"computation" by the followers of Moggi. They are natural thus to construct >parsers. Imperative programming is just one facet of the true story. Perhaps, but mostly monads are used to model imperative actions. And their use in imperative programming is the obvious starting point to learning about them. -- Ashley Yakeley, Seattle WA From rjchaaft@cs.uu.nl Thu May 17 10:57:45 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Thu, 17 May 2001 11:57:45 +0200 Subject: Monads In-Reply-To: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Message-ID: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> >So what you are saying is that I actually don't need >Monads to perform the tasks Monads supports ? Indeed. However, not using the Monadic do syntax results in hardly-readible code. For an explanation of how monads can be written in a functional way, see http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm From mg169780@students.mimuw.edu.pl Thu May 17 11:36:39 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Thu, 17 May 2001 12:36:39 +0200 (CEST) Subject: Proposal for generalized function partition in List-library In-Reply-To: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: On Thu, 17 May 2001, Bernd [iso-8859-2] Holzm=FCller wrote: > This partitioning function builds equivalence classes from the list > argument, where each element list within the result list consists of > elements that all map to the same value when applying f to it. > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] >=20 > This is much more general than the existing partitioning function and > applicable in many practical cases. But here generality comes at the expense of speed I think. =09Greetings :-) =09=09Michal Gajda =09=09korek@icm.edu.pl From dscarlett@optushome.com.au Thu May 17 12:07:56 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Thu, 17 May 2001 21:07:56 +1000 Subject: HUGS error: Unresolved overloading Message-ID: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Can anyone shed some light on the following error? Thanks in advance. isSorted :: Ord a => [a] -> Bool isSorted [] = True isSorted [x] = True isSorted (x1:x2:xs) | x1 <= x2 = isSorted (x2:xs) | otherwise = False -------- Hugs session for: /usr/local/share/hugs/lib/Prelude.hs haskell/sort.hs Main> isSorted [1] True Main> isSorted [1,2] True Main> isSorted [2,1] False Main> isSorted [] ERROR: Unresolved overloading *** Type : Ord a => Bool *** Expression : isSorted [] -------- From karczma@info.unicaen.fr Thu May 17 12:36:54 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 13:36:54 +0200 Subject: Monads References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <3B03B7D6.AE80F472@info.unicaen.fr> Ashley Yakeley comments: > > Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. They are "convenient patterns" > >to code the non-determinism (lazy list monads), to generalize the concept > >of continuations, to add tracing, exceptions, and all stuff called > >"computation" by the followers of Moggi. They are natural thus to construct > >parsers. Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. "Mostly" is very relative. The real power of monads is their universality. This "modelling of imperative actions" is just a way to hide the State, which in IO is rather unavoidable. But in my opinion it is rather antipedagogic to introduce monads in such a way to beginners. "Obvious starting point"? My goodness, but this is selling a black, closed box, which smells badly (imperatively) to innocent souls. People see then just do rubbish <- rubbish more_rubbish and don't know anything about the true sense of return, of the relation of <- to >>=, and finally they can use ONLY the IO Monad, nothing else. They start posing questions what is the difference between a <- b and let a = b ... and they get often ungodly answers to that, answers which say that the main difference is that <- "executes side-effects", and let doesn't. It choked me a bit. (Was it on comp.lang.functional, or on one of Haskell lists?) My philosophy is completely opposite. Introduce Monads as a natural way of chaining complex data transfer and hiding useless information, and when the idea is assimilated, then pass to IO. I begin usually with Maybe, then with backtrack Monad, and some simple State Transformers. Then, the students can grasp the Wadler's style slogan "Monads can Change the World". Oh, well, all teaching approaches are imperfect. Jerzy Karczmarczuk Caen, France From rkrueger@TechFak.Uni-Bielefeld.DE Thu May 17 12:56:20 2001 From: rkrueger@TechFak.Uni-Bielefeld.DE (Ralf Krueger) Date: Thu, 17 May 2001 13:56:20 +0200 Subject: HUGS error: Unresolved overloading References: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Message-ID: <3B03BC64.7745016C@uni-bielefeld.de> David Scarlett wrote: > > Can anyone shed some light on the following error? Thanks in advance. > > isSorted :: Ord a => [a] -> Bool > isSorted [] = True > isSorted [x] = True > isSorted (x1:x2:xs) > | x1 <= x2 = isSorted (x2:xs) > | otherwise = False > > -------- [...] > Main> isSorted [] > ERROR: Unresolved overloading > *** Type : Ord a => Bool > *** Expression : isSorted [] > -------- The list constructor [] is overloaded, so it's type cannot be infered inambigously. The empty list can be of any list type, HUGS cannot check if it's parameter's type is an instance of Ord. -- Ralf Krueger E-Mail: rkrueger@TechFak.Uni-Bielefeld.DE URL: http://www.Ralf-Krueger.DE Bielefeld University Center for Interdisciplinary Research (ZiF) WWW Administration Wellenberg 1 33615 Bielefeld Germany Tel: ++49 521 106-2777 From peterd@availant.com Thu May 17 14:25:43 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 09:25:43 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5910@smail01.clam.com> Monads are used not only for programming IO, state, exceptions etc, but also are the foundation of lists. It is hard to imagine functional programming without this basic datatype. Sets, Bags, trees etc are also monads. Phil Wadler wrote a very useful paper Comprehending Monads which I notice is not found on the Haskell/bookshelf web page. It can be found at http://www.cs.bell-labs.com/who/wadler/topics/monads.html I recommend this page for anyone interested in monads. --PeterD > -----Original Message----- > From: Mads Skagen [mailto:bedloose@yahoo.dk] > Sent: Thursday, May 17, 2001 4:25 AM > To: haskell@haskell.org > Subject: Monads > Hi > I'v currently working on a school-project where I have > to describe the Haskell programming language. > I've been looking through Monads and especially the IO > monad, the Maybe monad and the list monad > > My question is why are monads necessary in the > language ? > Is it not possible to construct the features provided > by Monads using basic functional constructs ? > What do I gain using Monads ? > Thank you very much. > Regards Skagen From Joe.Bowers@CanopySystems.com Thu May 17 14:35:19 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Thu, 17 May 2001 09:35:19 -0400 Subject: Wadler (was RE: Monads) Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/plain There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/html Wadler (was RE: Monads) There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0-- From peterd@availant.com Thu May 17 15:30:23 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 10:30:23 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5914@smail01.clam.com> I should probably mention that one doesn't need to know that a list is a monad in order to use a list. However, understanding that a list obeys the monad laws is a useful way to learn about monads. --PeterD > -----Original Message----- > From: Peter Douglass > Sent: Thursday, May 17, 2001 9:26 AM > To: 'bedloose@hotmail.com'; haskell@haskell.org > Subject: RE: Monads > > > Monads are used not only for programming IO, state, > exceptions etc, but also > are the foundation of lists. It is hard to imagine > functional programming > without this basic datatype. Sets, Bags, trees etc are also > monads. Phil > Wadler wrote a very useful paper Comprehending Monads which I > notice is not > found on the Haskell/bookshelf web page. It can be found at > > http://www.cs.bell-labs.com/who/wadler/topics/monads.html > > I recommend this page for anyone interested in monads. > --PeterD > > > > -----Original Message----- > > From: Mads Skagen [mailto:bedloose@yahoo.dk] > > Sent: Thursday, May 17, 2001 4:25 AM > > To: haskell@haskell.org > > Subject: Monads > > > Hi > > > I'v currently working on a school-project where I have > > to describe the Haskell programming language. > > > I've been looking through Monads and especially the IO > > monad, the Maybe monad and the list monad > > > > My question is why are monads necessary in the > > language ? > > > Is it not possible to construct the features provided > > by Monads using basic functional constructs ? > > > What do I gain using Monads ? > > > Thank you very much. > > > Regards Skagen > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From nick@microsoft.com Thu May 17 16:09:06 2001 From: nick@microsoft.com (Nick Benton) Date: Thu, 17 May 2001 08:09:06 -0700 Subject: Final CfP: BABEL Workshop on Multilanguage Infrastructure and Interoperability Message-ID: <0C682B70CE37BC4EADED9D375809768A48EDD9@red-msg-04.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BABEL'01 FINAL CALL FOR PAPERS =20 First Workshop on Multi-Language Infrastructure and Interoperability =20 http://research.microsoft.com/~nick/babel01.htm =20 Satellite to PLI'01 =20 Firenze, Italy, 8th September 2001 =20 Submission Deadline: 1st June 2001 =20 ** The Submission Site is now open ** http://cmt.research.microsoft.com/BABEL01/ =20 AIMS AND SCOPE =20 Recent years have seen a resurgence of interest in multi-language tools and intermediate languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being able to interoperate easily with code written in existing languages is essential for such an implementation to be useful in practice. This workshop aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not limited to: =20 * Compilation of high level languages to common executable formats such as Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common Language Runtime. =20 * Defining and using bindings for component middleware such as OMG's CORBA or Microsoft's COM. =20 * Language constructs to support interoperability between different languages, particularly from different paradigms (e.g. OO/functional). =20 * Multi-language backends for compilation and/or analysis (e.g. MLRISC, FLINT, C--, TAL, SUIF). =20 * Type theoretic and semantic foundations for multi-language work. =20 * Multi-language development environments and tools (e.g. debuggers, profilers). =20 Submissions may address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors unsure of the appropriateness of a potential submission should email the PC chair (nick@microsoft.com). =20 =20 PROGRAMME COMMITTEE =20 Nick Benton (chair) Microsoft Research Fergus Henderson University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett Cornell University Martin Odersky Ecole Polytechnique Federale de Lausanne=20 John Reppy Bell Labs=20 Andrew Tolmach Portland State University=20 David Wakeling University of Exeter =20 =20 INVITED SPEAKERS =20 Zhong Shao Yale University =20 =20 IMPORTANT DATES =20 Deadline for submission 1st June 2001 Notification of acceptance 9th July 2001 Final version due 10th August 2001 =20 =20 SUBMISSION DETAILS =20 Papers should be at most 14 pages and should be submitted in Ghostscript-compatible PostScript or PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS style files (see http://math.tulane.edu/~entcs/). Papers should be submitted electronically via the submission site at http://cmt.research.microsoft.com/BABEL01/ Submissions should not overlap significantly with work which has already been published or submitted to any other conference or journal. An informal proceedings will be published as a technical report and distributed at the workshop. It is intended that a final proceedings will be published in a volume of ENTCS. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable &= nbsp; &n= bsp; BABEL'01 &= nbsp; &n= bsp; FINAL CALL FOR PAPERS &= nbsp; First Workshop on Multi-Language &= nbsp; Infrastructure and Interoperability http://research.= microsoft.com/~nick/babel01.htm &= nbsp; &n= bsp; Satellite to PLI'01 &= nbsp; Firenze, = Italy, 8th September 2001 &= nbsp; Submission Deadline: 1st June = 2001 &= nbsp; ** The Submission Site is now open ** &= nbsp; http://cmt.research.m= icrosoft.com/BABEL01/ AIMS AND = SCOPE Recent years have = seen a resurgence of interest in multi-language tools and intermediate = languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, = analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being = able to interoperate easily with code written in existing languages is essential = for such an implementation to be useful in practice. This workshop = aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not = limited to: * Compilation of = high level languages to common executable formats such as = Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common = Language Runtime. * Defining and = using bindings for component middleware such as OMG's CORBA or = Microsoft's COM. * Language = constructs to support interoperability between different languages, particularly from different paradigms (e.g. = OO/functional). * Multi-language = backends for compilation and/or analysis (e.g. = MLRISC, FLINT, C--, TAL, = SUIF). * Type theoretic = and semantic foundations for multi-language work. * Multi-language = development environments and tools (e.g. debuggers, = profilers). Submissions may = address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors = unsure of the appropriateness of a potential submission should email the PC = chair (nick@microsoft.com). PROGRAMME = COMMITTEE Nick Benton (chair) Microsoft Research Fergus Henderson &= nbsp; University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett &= nbsp; Cornell = University Martin Odersky &= nbsp; Ecole Polytechnique Federale de Lausanne John Reppy &n= bsp; Bell Labs = Andrew Tolmach &= nbsp; Portland = State University David Wakeling &= nbsp; University of Exeter INVITED = SPEAKERS Zhong Shao &= nbsp; Yale = University IMPORTANT = DATES Deadline for submission 1st June 2001 Notification of acceptance 9th July = 2001 Final version due = 10th August 2001 SUBMISSION = DETAILS Papers should be at = most 14 pages and should be submitted in Ghostscript-compatible PostScript or = PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS = style files (see http://math.tulane.edu/~e= ntcs/). Papers should be submitted electronically via the submission site = at http://cmt.research.m= icrosoft.com/BABEL01/ Submissions should = not overlap significantly with work which has already been published or = submitted to any other conference or journal. An informal proceedings will = be published as a technical report and distributed at the workshop. = It is intended that a final proceedings will be published in a volume of = ENTCS. =00 ------_=_NextPart_001_01C0DEE3.5106F5A1-- From farkinas@cbn.net.id Thu May 17 17:21:26 2001 From: farkinas@cbn.net.id (M. Faisal Fariduddin Attar Nasution) Date: Thu, 17 May 2001 23:21:26 +0700 Subject: Questions about Trie Message-ID: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting, I'm a last year student in a computer science field. I'm = currently trying to code an implementation for a compression using basic = Lempel-zif technique. I use a Trie (retrieval) as a data structure for = the dynamic dictionary aplication. The problem is Trie uses not just an = ordinary binary tree, but it uses a multiple-weighted tree, where one = node has at most 256 children. Most literatures about Haskell show only = binary tree for the example in tree or Abstract Data Structures subject. = So, does anyone know how to code the implementation for trie. Thanks for = paying attention and I'm really hoping for the answer immediately. Aerith Gainsborough (Final Fantasy VII) "All I know is..."=20 "The Cetra were born from the Planet, speak with the Planet, and=20 unlock the Planet."=20 "And....... then......"=20 "The Cetra will return to the Promised Land. A land that promises = supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = Greeting, I'm a=20 last year student in a computer science field. I'm currently trying to = code an=20 implementation for a compression using basic Lempel-zif technique. I use = a Trie=20 (retrieval) as a data structure for the dynamic dictionary = aplication. The=20 problem is Trie uses not just an ordinary binary tree, but it uses a=20 multiple-weighted tree, where one node has at most 256 children. Most=20 literatures about Haskell show only binary tree for the example in tree = or=20 Abstract Data Structures subject. So, does anyone know how to code the=20 implementation for trie. Thanks for paying attention and I'm really = hoping for=20 the answer immediately. Aerith Gainsborough (Final Fantasy = VII) "All I=20 know is..." "The Cetra were born from the Planet, speak with the = Planet, and=20 unlock the Planet." "And....... then......" "The Cetra will = return=20 to the Promised Land. A land that promises supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar=20 Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360-- From uk1o@rz.uni-karlsruhe.de Thu May 17 17:18:13 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 17 May 2001 18:18:13 +0200 Subject: Monads In-Reply-To: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl>; from rjchaaft@cs.uu.nl on Thu, May 17, 2001 at 11:57:45AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> Message-ID: <20010517181811.C14548@rz.uni-karlsruhe.de> Hello! On Thu, May 17, 2001 at 11:57:45AM +0200, Rijk-Jan van Haaften wrote: > >So what you are saying is that I actually don't need > >Monads to perform the tasks Monads supports ? > Indeed. However, not using the Monadic do syntax results in > hardly-readible code. I don't really think so. The operator precedences for >> and >>= are quite okay, especially combined to the precedence of lambda binding. How is main = getLine >>= \line -> let number = read line in let result = number + 42 in print result less readable than main = do line <- getLine let number = read line let result = number + 42 print result ? Or main = putStr "Hello! What's your name?" >> getLine >>= \name -> putStrLn ("Hello, " ++ name ++ "!") compared to main = do putStr "Hello! What's your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!") > [...] Yes, I use do syntax where appropriate (e.g. also for usual parser monads), however, the operator syntax can be written quite readably too. Kind regards, Hannah. From simonpj@microsoft.com Thu May 17 17:52:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 17 May 2001 09:52:10 -0700 Subject: Ix class Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F4C@red-msg-09.redmond.corp.microsoft.com> I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding=20 a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com]=20 | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class |=20 |=20 | Hello, |=20 | I am working on an Ix instance for one of my types and=20 | finding it rather restrictive. For me it would be useful to=20 | have rangeSize be defined in the Ix class (with a default=20 | definition of course), so that it can be overridden. |=20 | Also, does anybody know why Ix derives from Ord? It seems to=20 | me this is an unnecessary limitation on the types that can be=20 | instances of Ix. I cannot think of a reason why the=20 | implementation of anything in the Ix or Array modules would=20 | require that every Ix be an Ord (with a minor exception --=20 | see below). If an implementation is using a comparison on an=20 | Ix type, chances are it should be using inRange or comparing=20 | (index bnds x) with (index bnds y) instead. |=20 | One change would have to be made in the Array module if Ord=20 | is removed from Ix: | instance (Ix a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | would become: | instance (Ix a, Eq a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | As I said, I think this is a very minor issue. |=20 | I believe that making these changes in the standard would not=20 | impact existing programs in any way. Could these changes be=20 | considered as a possible "typo" to be fixed in the Library Report? |=20 |=20 | P.S. In case anybody's interested, here's why I want to override | rangeSize: |=20 | > newtype Honeycomb =3D Hx (Int,Int) deriving (Eq,Show,Ord) | >=20 | > indexError =3D error "Index out of range" | >=20 | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) =3D | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) =3D | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) =3D | > let i =3D index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | >=20 | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) =3D x `mod` 2 =3D=3D y `mod` 2 |=20 | This implements a honeycomb or hexagonal tiling for a maze=20 | generating program. The honeycomb is superimposed on a grid=20 | such that only every other square is "active", corresponding=20 | to a particular hexagon in the honeycomb. It's similar to a=20 | checkers game, where only the dark squares are used. |=20 | I would like _any_ pair of Ints to be an acceptable boundary=20 | for the honeycomb, not just the ones that represent valid=20 | indexes. For example, (Hx (0,0), Hx (15,12)) should be a=20 | valid set of bounds. The current definition of rangeSize=20 | makes this impossible, which is why I would like to override=20 | it. By the way, the Library Report does not explicitly say=20 | that the bounds have to both be valid indexes, though it does=20 | imply this with the sample definition of rangeSize. |=20 | Thanks, | Matt Harden |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From gruenbacher-lists@geoinfo.tuwien.ac.at Thu May 17 19:03:23 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Thu, 17 May 2001 20:03:23 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) Message-ID: Hello, I was trying to write an abstraction for bidirectional communication between two threads. For some reason, MVars seem to break: ----------------------------------------------- class Cords c t u where newCord :: IO (c t u) listen :: c t u -> IO t speak :: c t u -> u -> IO () data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) instance Cords Cord t u where newCord = return (Cord newEmptyMVar newEmptyMVar) speak (Cord _ s) t = do s' <- s ; putMVar s' t listen (Cord h s) = do h' <- h ; takeMVar h' otherEnd (Cord t u) = Cord u t showT :: Cord Int String -> IO () showT cord = do putStrLn "Runnning..." x <- listen cord putStrLn ("Heard " ++ show x) speak cord (show x) putStr ("Said " ++ (show x)) showT cord main :: IO () main = do cord <- newCord forkIO (showT (otherEnd cord)) speak cord 1 str <- listen cord putStrLn str ----------------------------------------------- Hugs writes: Main> main Runnning... Program error: no more threads (deadlock?) (131 reductions, 307 cells) Any ideas? Thanks, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789 From john@repetae.net Thu May 17 19:42:50 2001 From: john@repetae.net (John Meacham) Date: Thu, 17 May 2001 11:42:50 -0700 Subject: Proposal for generalized function partition in List-library In-Reply-To: ; from mg169780@zodiac.mimuw.edu.pl on Thu, May 17, 2001 at 12:36:39PM +0200 References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: <20010517114250.D13591@mark.ugcs.caltech.edu> this is just how I understand things at the moment, if I am wrong or misleading anywhere then please speak up. I am unconvinced that such generalizations must come as speed hits, but perhaps someone can enlighten me. compilers seem to support seperate compilation and polymorphism at the moment by boxing polymorphic types and passing their class-context (term?) as a hidden parameter to the polymorphic function. but it seems that since haskell is strongly type checked at compile time, we already KNOW all of the types with certainty when it comes to compiling the program in the end so this would seem to be unnecisarry. now there are two cases where this breaks down * seperate compilation * code bloat namely that you don't necisarilly know all of the types of polymorphic functions when they are in a module that is compiled seperately from the rest of the program. the solution used by many C++ compilers is to inline all polymorphic code in place (this is why templates are in header files). there is no reason this won't work in haskell and give back all of the speed benefits of base types everwhere (as it would in this example) but has the unfortunate side effect of causing worst case exponential code bloat as every function is re-written for every type combination it is used with. the solution I see (and probably exists) is a hybrid model, one that lets the compiler know to specialize certain polymorphic functions as well as let the compiler utilize such specialized functions. a pragma which lets the compiler know that a certain specialization would be useful such as partition :: (Eq b) => (a -> b) -> [a] -> [[a]] partition fn ls = ... {-# specialize partition :: (a -> Bool) -> [a] [[a]] -} which would let the compiler know to generate code for partition specificially optimized for (a -> Bool) and thus obviating the need for the Eq hidden argument. the fully polymorphic version would of course also have to be generated. specializations would be advertised in the header file and utilized whenever the typechecker determined you were using partition in the specialized case. this seems like a better solution than the current practice of providing seperate general and specific functions, take, genTake, max, genMax and whatnot. you would just specify that specializations for the case of 'Int' should be generated as it would be the most common case. an {-# inline partition -} might also be useful which would actually place the text of the function into the .hi file to be in-line expanded as is done in C++... I imagine there would be some tweaking to determine when this is a win and when it isn't... some of this stuff probably exists in current compilers, but polymorphism need not be at the expense of speed. -John On Thu, May 17, 2001 at 12:36:39PM +0200, Michal Gajda wrote: > On Thu, 17 May 2001, Bernd [iso-8859-2] Holzmüller wrote: > > This partitioning function builds equivalence classes from the list > > argument, where each element list within the result list consists of > > elements that all map to the same value when applying f to it. > > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] > > > > This is much more general than the existing partitioning function and > > applicable in many practical cases. > > But here generality comes at the expense of speed I think. -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Thu May 17 20:36:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:36:44 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: Thu, 17 May 2001 10:06:55 +0200, Bernd Holzmüller pisze: > I would like to propose a new function for module List that generalizes > the current function partition :: (a -> Bool) -> [a] -> [[a]] No, current partition has type (a -> Bool) -> [a] -> ([a], [a]) so your function is not compatible with it, so shouldn't replace such standard function. > partition:: Eq b => (a -> b) -> [a] -> [[a]] > partition _ [] = [] > partition f (a:as) = > let (as',as'') = foldr (select (f a)) ([],[]) as > in (a:as'):partition f as'' > where > select b x (ts,fs) | f x == b = (x:ts,fs) > | otherwise = (ts,x:fs) This function doesn't give a hint which sublists correspond to which results of the function, so I'm afraid it's easy to make errors by assuming that they will come in a different order. And it's inefficient: the cost is the number of elements times the number of different results of the function. I would write it thus: \f xs -> groupBy (\(a, _) (b, _) -> a == b) $ sortBy (\(a, _) (b, _) -> compare a b) [(f x, x) | x <- xs] You can apply 'map (map snd)' to the result to remove the results of f. I don't have a good name for it and I'm not sure it's common enough to put it in the standard library. It can also be more efficiently written using Array.accumArray for particular types of the result of the function. PS. What I would perhaps put into standard library: uniq :: Eq a => [a] -> [a] uniqBy :: (a -> a -> Bool) -> [a] -> [a] so people don't use nub unnecessarily (if elements are adjacent or can be made adjacent by sorting), and takeLastWhile :: (a -> Bool) -> [a] -> [a] dropLastWhile :: (a -> Bool) -> [a] -> [a] spanEnd :: (a -> Bool) -> [a] -> ([a], [a]) (with some better names) which iterate forward and are lazy, to avoid double reversing in case the test is cheap but the list is long, and partitionM :: Monad m => (a -> m Bool) -> [a] -> m ([a], [a]) Here are implementations of some of these: takeLastWhile p xs = case span p xs of (ys, []) -> ys (_, _:zs) -> takeLastWhile p zs dropLastWhile p xs = case span p xs of (_, []) -> [] (ys, z:zs) -> ys ++ z : dropLastWhile p zs spanEnd p xs = case span p xs of (ys, []) -> ([], ys) (ys, z:zs) -> (ys ++ z : ys', zs') where (ys', zs') = spanEnd p zs -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Thu May 17 20:43:46 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:43:46 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: 17 May 2001 19:36:44 GMT, Marcin 'Qrczak' Kowalczyk pisze: > PS. What I would perhaps put into standard library: And also: split :: (a -> Bool) -> [a] -> [[a]] split p c = let (xs, ys) = break p c in xs : case ys of [] -> [] _:zs -> split p zs softSplit :: (a -> Bool) -> [a] -> [[a]] -- softSplit p c = filter (not . null) (split p c) softSplit p c = case dropWhile p c of [] -> [] x:xs -> let (ys, zs) = break p xs in (x:ys) : softSplit p zs It follows that words = softSplit isSpace. Any better name? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jenglish@flightlab.com Thu May 17 22:14:53 2001 From: jenglish@flightlab.com (Joe English) Date: Thu, 17 May 2001 14:14:53 -0700 Subject: Monads In-Reply-To: <200105170912.CAA09737@mail4.halcyon.com> References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <200105172114.OAA07367@dragon.flightlab.com> Ashley Yakeley wrote: > At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. [...] > >[...] Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. I don't know about that; I use monads most often when dealing with container classes (sets, bags, lists). They also provide a useful way to reason about parts of XPath and XSLT. As far as learning about them goes, I don't think I really "got" monads until reading Wadler's aptly-titled "Comprehending Monads", which approaches them from this perspective. --Joe English jenglish@flightlab.com From agold@bga.com Thu May 17 22:21:21 2001 From: agold@bga.com (Arthur H. Gold) Date: Thu, 17 May 2001 16:21:21 -0500 Subject: Questions about Trie References: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> Message-ID: <3B0440D1.2248C105@bga.com> > "M. Faisal Fariduddin Attar Nasution" wrote: > > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using > basic Lempel-zif technique. I use a Trie (retrieval) as a data > structure for the dynamic dictionary aplication. The problem is Trie > uses not just an ordinary binary tree, but it uses a multiple-weighted > tree, where one node has at most 256 children. Most literatures about > Haskell show only binary tree for the example in tree or Abstract Data > Structures subject. So, does anyone know how to code the > implementation for trie. Thanks for paying attention and I'm really > hoping for the answer immediately. > IIRC, there's a trie implementation in Chris Okasaki's "Purely Functional Data Structures" -- that might be a start (there's also his "Edison" library, which contains many of the components you'd need). HTH (and sorry if it doesn't) --ag -- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu -- I am looking for work. Contact me. From ken@digitas.harvard.edu Thu May 17 22:17:49 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Thu, 17 May 2001 17:17:49 -0400 Subject: Wadler (was RE: Monads) In-Reply-To: ; from Joe.Bowers@CanopySystems.com on Thu, May 17, 2001 at 09:35:19AM -0400 References: Message-ID: <20010517171749.A25335@digitas.harvard.edu> --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-17T09:35:19-0400, Joe Bowers wrote: > There have been several references to "a paper by > Wadler" in this thread- some folks (well, at least > one folk :) on this list may not be familiar with > the work surrounding Haskell yet, and (from this context) > This paper seems like a pretty good place to start. > =20 > Would anybody have a detailed citation for it, > or (even better) is it up on the web? Wadler's monad papers, including "Comprehending Monads", are at http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig My god, I've seen heaven. - Flute at Band Camp --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BD/9zjAc4f+uuBURAnmcAJ9M6+wyOg+izO2eQo3GS5ovm55P+ACguuzz 9a35nSAI8w6IuYvSs7+ei7M= =9zoV -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From karczma@info.unicaen.fr Fri May 18 07:56:57 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 08:56:57 +0200 Subject: Monads References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> Message-ID: <3B04C7B9.D14AA827@info.unicaen.fr> Rijk-Jan van Haaften >>= Hannah Schroeter: > > ... However, not using the Monadic do syntax results in > > hardly-readible code. > > I don't really think so. The operator precedences for >> and >>= are > quite okay, especially combined to the precedence of lambda binding. ... > main = do > putStr "Hello! What's your name?" ... > Yes, I use do syntax where appropriate (e.g. also for usual parser > monads), however, the operator syntax can be written quite readably > too. I would add that sometimes you may be interested in Monadic SEMANTICS at a more profound level, trying to hide it completely at the surface. Then, the <> syntax is an abomination. The examples are already in the Wadler's "Essence". Imagine the construction of a small interpreter, a virtual machine which not only evaluates the expressions (belonging to a trivial Monad), but perform some side effects, or provides for exceptions propagated through a chain of Maybes. Then the idea is to * base the machine on the appropriate Monad * "lift" all standard operators so that an innocent user can write (f x) and never x >>= f (or even worse). The <> construct in such a context resembles the programming in assembler, and calling it more readable is hmmmm... not very convincing. (My favourite example is the "time-machine" monad, a counter-clock-wise State Monad proposed once by Wadler, and used by myself to implement the reverse automatic differentiation algorithm. Understanding what's going on is difficult. The <> syntax makes it *worse*.) Jerzy Karczmarczuk Caen, France From josefs@cs.chalmers.se Fri May 18 09:32:54 2001 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Fri, 18 May 2001 10:32:54 +0200 (MET DST) Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: John, On Thu, 17 May 2001, John Meacham wrote: [..] > namely that you don't necisarilly know all of the types of polymorphic > functions when they are in a module that is compiled seperately from the > rest of the program. the solution used by many C++ compilers is to > inline all polymorphic code in place (this is why templates are in > header files). there is no reason this won't work in haskell and give > back all of the speed benefits of base types everwhere (as it would in > this example) but has the unfortunate side effect of causing worst case > exponential code bloat as every function is re-written for every type > combination it is used with. > This is true in ML but not in Haskell. Haskell has polymorphic recursion which makes it impossible to predict statically at what types a function will be called. So trying to inline away polymorphism would lead to infinite unwindings. Cheers, /Josef From Colin.Runciman@cs.york.ac.uk Fri May 18 09:43:10 2001 From: Colin.Runciman@cs.york.ac.uk (Colin.Runciman@cs.york.ac.uk) Date: Fri, 18 May 2001 09:43:10 +0100 Subject: Questions about Trie Message-ID: <200105180843.JAA00498@pc179.cs.york.ac.uk> > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using basic > Lempel-zif technique. I use a Trie (retrieval) as a data structure for > the dynamic dictionary aplication. The problem is Trie uses not just an > ordinary binary tree, but it uses a multiple-weighted tree, where one > node has at most 256 children. Most literatures about Haskell show only > binary tree for the example in tree or Abstract Data Structures subject. > So, does anyone know how to code the implementation for trie. Thanks for > paying attention and I'm really hoping for the answer immediately. There is some relevant material in Chapter 6 (Text compression) of `Applications of Functional Programming', UCL Press, 1995. ISBN: 1-85728-377-5. (With apologies for self-reference, as co-editor of the book.) Colin R From lennart@mail.augustsson.net Fri May 18 10:02:58 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Fri, 18 May 2001 11:02:58 +0200 Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library References: Message-ID: <3B04E542.76BA65A5@mail.augustsson.net> Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. This is true in theory, but in practice most polymorphism can be removed by inlining. I'm sure some pragmatic solution with limited inlining would work quite well. You'd still need to be able to handle polymorphism without inlining, of course, so you could cope with the exceptional cases. Mark Jones did some experiments with this kind of inlining that worked very well. -- Lennart From karczma@info.unicaen.fr Fri May 18 10:25:14 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 11:25:14 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> Message-ID: <3B04EA7A.90D83CFB@info.unicaen.fr> Maestri, Primaballerine, I have a really provocative question. One of my student posed it, and I could not respond in a satisfactory manner, especially for myself it was really unsatisfactory. We know that a good part of "top-down" polymorphism (don't ask me what do I mean by that...) in C++ is emulated using templates. Always when somebody mentions templates in presence of a True Functionalist Sectarian, the reaction is "What!? Abomination!!". Now the question: WHY? Why so many people say "the C++ templates are *wrong*" (and at the same time so many people use it every day...) Is it absolutely senseless to make a functional language with templates? Or it is just out of fashion, and difficult to implement? == This is a sequel to a former discussion about macros, of course... Jerzy Karczmarczuk Caen, France From bjpop@cs.mu.OZ.AU Fri May 18 10:30:38 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Fri, 18 May 2001 19:30:38 +1000 (EST) Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library In-Reply-To: <3B04E542.76BA65A5@mail.augustsson.net> from Lennart Augustsson at "May 18, 2001 11:02:58 am" Message-ID: <200105180930.TAA25290@mulga.cs.mu.OZ.AU> Lennart wrote: > This is true in theory, but in practice most polymorphism can be removed > by inlining. I'm sure some pragmatic solution with limited inlining would > work quite well. You'd still need to be able to handle polymorphism without > inlining, of course, so you could cope with the exceptional cases. > > Mark Jones did some experiments with this kind of inlining that worked very well. > > -- Lennart The MLton compiler (http://www.clairv.com/MLton/) uses whole program compilation and monomorphises ML code (again they do not have to deal with potential polymorhpic recursion, but as Lennart says, it can be treated as a special case in Haskell). I have never used it though, so I can't vouch for its performance. They are motivated to use unboxed representations and so on. The danger with whole program compilation is long compile times. But it might be possible to allow separate compilation for development and put up with the overheads of boxed representations and so on, but get the benefits of the optimisations flowing from whole program compilation when needed (ie released binaries). Sounds like a lot of work to me though. Bernie. From simonpj@microsoft.com Fri May 18 08:28:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 18 May 2001 00:28:50 -0700 Subject: Questions about Trie Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F50@red-msg-09.redmond.corp.microsoft.com> Perhaps this monads discussion might move to haskell-cafe@haskell.org? It's a good discussion, but it's just what haskell-cafe is for. http://www.haskell.org/mailinglist.html Simon | -----Original Message----- | From: Arthur H. Gold [mailto:agold@bga.com]=20 | Sent: 17 May 2001 22:21 | To: haskell@haskell.org | Cc: M. Faisal Fariduddin Attar Nasution | Subject: Re: Questions about Trie |=20 |=20 | > "M. Faisal Fariduddin Attar Nasution" wrote: | >=20 | > Greeting, I'm a last year student in a computer science=20 | field. I'm=20 | > currently trying to code an implementation for a =20 | compression using=20 | > basic Lempel-zif technique. I use a Trie (retrieval)=20 | as a data=20 | > structure for the dynamic dictionary aplication. The=20 | problem is Trie=20 | > uses not just an ordinary binary tree, but it uses a=20 | multiple-weighted=20 | > tree, where one node has at most 256 children. Most=20 | literatures about=20 | > Haskell show only binary tree for the example in tree or=20 | Abstract Data | > Structures subject. So, does anyone know how to =20 | code the | > implementation for trie. Thanks for paying attention and=20 | I'm really=20 | > hoping for the answer immediately. | >=20 |=20 | IIRC, there's a trie implementation in Chris Okasaki's=20 | "Purely Functional Data Structures" -- that might be a start=20 | (there's also his "Edison" library, which contains many of=20 | the components you'd need). |=20 | HTH (and sorry if it doesn't) | --ag |=20 | --=20 | Artie Gold, Austin, TX (finger the cs.utexas.edu account for=20 | more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu | -- | I am looking for work. Contact me. |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From tweed@compsci.bristol.ac.uk Fri May 18 11:22:36 2001 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Fri, 18 May 2001 11:22:36 +0100 (BST) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: (This response comes from the context of someone who like FP but has a day job writing in C++.) On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. Umm... what do you mean by `top down'? The two senses in which I use polymorphism in C++ are: (i) using super classes (in the sence that A is a superclass of B is B inherits from A) to perform operations that only make sense for objects of the semantic type A. My canonical example is working with quadtree nodes, where a there are various types nodes which can hold different kinds of data but the base class qnode holds things like position, etc. (ii) using templates to write generic algorithms which either don't depend on the object type at all (e.g., vectors, lists, etc) or which depend on one or two conceptual operations which are very elementary (e.g., meaningful equality, addition or a `display yourself on stdout' function). In C++ these could _almost_ be done using superclasses but with problems because (A) the standard types (e.g., int) can't have their place in the class hierarchy redefined (e.g., int inherits from debug_show) (B) deep hierarchies are really not handled well by debuggers and it'd be a real pain trying to look at the C++ equivalent of the haskell `data A = ... deriving (Show,Ord,Monad,...)' The almost that I referred to above comes from the fact that (AFAIK) without using something nasty like RTTI you can't create new objects of the true type in a function to which you've passed a pointer to the base class. That's the conceptual overview. In terms of pragmatics __at least for my work in image processing__ I don't write classes that much, seldom use inheritance and I'm 99% sure I don't have any inheritance more than 1 level deep. On the other hand I write a lot of templated code which would be equivalent in haskell to either f :: a -> b -> .... -> a or f :: Eq a => a -> b -> ... -> a (i.e., algorithms that need just one or two low-level ideas such as equality). I much prefer the Haskell way of doing this with superclasses but I just don't feel brave enough to attempt the levels of class hierarchy that this implies in C++. (In some ways this is a shame since, because in template function names member functions used are only matched syntactically -- as there's no superclass to ensure semantic equivalence -- I've made one or two mistakes when I forgot a member function with the same name actually meant something different.) > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) In my experience the C++ idiom `you only pay for what you use' (==> templates are essentially type-checked macros) and the fact most compilers are evolved from C compilers makes working with templates a real pain in practice. Additionally, I think a lot of people who dislike them are old-time C hackers who don't see why it isn't good enough to do polymorphism via void*'s and function pointers. As to why I at least use it, it lets me write polymorphic functions without needing deep class hierarchies (which as noted above aren't nice in C++) or going into the error prone mire of the void* approach. > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? I may be missing something obvious, but given Haskell's well thought out (IMO) prelude class structure and the fact that deep class hierarchies with `multiple inheritance' aren't a problem in Haskell, I don't see that it would buy you anything in Haskell. On the other hand, if the standard prelude didn't have the class hierarchy I think they would be much more useful. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. From heringto@cs.unc.edu Fri May 18 15:30:38 2001 From: heringto@cs.unc.edu (Dean Herington) Date: Fri, 18 May 2001 10:30:38 -0400 Subject: MVar Problem (Concurrent Hugs) References: Message-ID: <3B05320E.6FE477AA@cs.unc.edu> Andreas Gruenbacher wrote: > Hello, > > I was trying to write an abstraction for bidirectional communication > between two threads. For some reason, MVars seem to break: > > ----------------------------------------------- > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > > data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) > > instance Cords Cord t u where > newCord = return (Cord newEmptyMVar newEmptyMVar) > speak (Cord _ s) t = do s' <- s ; putMVar s' t > listen (Cord h s) = do h' <- h ; takeMVar h' > > otherEnd (Cord t u) = Cord u t > > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStr ("Said " ++ (show x)) > showT cord > > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str > ----------------------------------------------- You are creating a new MVar with each listen and speak. As a result, the two threads never agree on an MVar, so deadlock occurs. Instead, you should create the pair of MVars in newCord. Try the code below. > import Concurrent > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > data Cord t u = Cord (MVar t) (MVar u) > instance Cords Cord t u where > newCord = do t <- newEmptyMVar > u <- newEmptyMVar > return (Cord t u) > listen (Cord t _) = takeMVar t > speak (Cord _ u) s = putMVar u s > otherEnd (Cord t u) = Cord u t > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStrLn ("Said " ++ show x) > showT cord > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str Dean From gruenbacher-lists@geoinfo.tuwien.ac.at Fri May 18 16:54:49 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Fri, 18 May 2001 17:54:49 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) In-Reply-To: <3B05320E.6FE477AA@cs.unc.edu> Message-ID: On Fri, 18 May 2001, Dean Herington wrote: > You are creating a new MVar with each listen and speak. As a result, the > two threads never agree on an MVar, so deadlock occurs. Instead, you should > create the pair of MVars in newCord. Try the code below. > > [...] Thanks, this works. Thanks! --Andreas. From ger@tzi.de Fri May 18 17:22:07 2001 From: ger@tzi.de (George Russell) Date: Fri, 18 May 2001 18:22:07 +0200 Subject: Templates in FPL? Message-ID: <3B054C2F.C1BBE335@tzi.de> The MLj compiler from ML to the Java Virtual Machine (which is being actively worked on by the geniuses at Microsoft as we speak) expands out all polymorphism. I helped develop this compiler and I believe this approach to be a good one. There are particular reasons why it's good for this case (1) as has been said before, ML does not have polymorphic recursion; (2) the cost of object creation in Java used at least to be horrendous, so it was well worth working hard to get rid of it. However I think long term it's a good idea for normal Haskell compilers because my guess is you will Win Big on quite a lot of things, because you don't have to carry around and use dictionaries (for method lookup in class instances) and can do a lot more specialisation and inlining. Strict values can also be unboxed. Of course you can control specialisation used unboxed values already in Glasgow Haskell, but it requires special annotations or special types. The minus points are thuswise, so far as I know: (1) the compiled code is bigger. This means the code might indeed run more slowly. But with MLj I think we found that in normal cases it isn't THAT much bigger (maybe about 50%), because the functions which get specialised a lot (like "length" and "map") tend to be pretty small. Of course you can construct artificial cases where the code size will explode. (2) It takes much longer to compile. I'm waiting for Moore's law here, but at present I would be surprised if (say) Glasgow Haskell could compile itself inlining out all polymorphism, without it taking a very long time or a very fast computer or lots of nasty imperative optimisations. (3) You can't inline everything, because of polymorphic recursion, and also because it would be nice to allow Haskell code to be dynamically linked in (see GHCi). Or you can inline everything, but then you need to implement a Haskell Virtual Machine which does the inlining (and the whole compiler backend) on demand at runtime. I don't think you have to inline everything; it should surely be possible to leave polymorphic versions of the functions around, to use for hard cases. From msk@post.tepkom.ru Fri May 18 17:33:46 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Fri, 18 May 2001 20:33:46 +0400 (MSD) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? ordinary FP polymorphish is as strict analogue of the C++ template-functions Haskell type clasess is as close analog for the C++ template classes (studing of the Haskell type classes clarify to me many aspects of the C++ classes templates semantic). Regards, Anton From ken@digitas.harvard.edu Fri May 18 20:08:47 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Fri, 18 May 2001 15:08:47 -0400 Subject: Monads In-Reply-To: <3B04C7B9.D14AA827@info.unicaen.fr>; from karczma@info.unicaen.fr on Fri, May 18, 2001 at 08:56:57AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> <3B04C7B9.D14AA827@info.unicaen.fr> Message-ID: <20010518150847.A6077@digitas.harvard.edu> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-18T08:56:57+0200, Jerzy Karczmarczuk wrote: > The examples are already in the Wadler's "Essence". Imagine the=20 > construction of a small interpreter, a virtual machine which not only > evaluates the expressions (belonging to a trivial Monad), but perform > some side effects, or provides for exceptions propagated through a > chain of Maybes. Then the idea is to >=20 > * base the machine on the appropriate Monad > * "lift" all standard operators so that an innocent user can write (f x) > and never x >>=3D f (or even worse). Perhaps you already know about Filinski's PhD thesis? He seems to have proven that we already have the "small interpreter" you want, inside of any programming language that supports call/cc and storing a function in a single storage cell. ML is such a programming language. You can define your own monads yet rely on implicit evaluation ordering in ML to do the lifting you want! --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Learn Esperanto and make friends around the world http://www.esperanto.net --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BXM/zjAc4f+uuBURAtYcAKCafrEuesrlWUObVdidMDJf5VCzwACfcAQb 9vI2sHi/yei+T2JVHxC/sZE= =fDKP -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From qrczak@knm.org.pl Fri May 18 20:11:21 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 19:11:21 GMT Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Fri, 18 May 2001 11:25:14 +0200, Jerzy Karczmarczuk pisze: > Always when somebody mentions templates in presence of a True > Functionalist Sectarian, the reaction is "What!? Abomination!!". They aren't that wrong, but they have some problems: * It's not specified what interface they require from types to be instantiated to. * The whole implementation must be present in a public header file. Well, there is the 'export' keyword, but no compiler implements it. It follows that all things used by implementation of a template must be included too. And compilation time of a large project is larger than necessary. * They introduce very complex rules about name lookup (environment in which a specialized template is compiled is a weird mix of environments of the point of definition and point of usage of the template), deduction which overloading to use (with choosing the candidate according to partial ordering of better fitting), deduction of template types and what partial specialization to use, complicated by the fact that there are complex rules of implicit conversions. Templates don't obey a Haskell's rule that adding code doesn't change the meaning of previously valid code and can at most introduce an ambiguity which is flagged as error. * Types can't be deduced from the context of usage. For example handling the empty set or monadic 'return' would require either spelling the type at each use or introducing another type and deferring deduction of the real type until an operation is performed with a value of a known type. * Since they are similar to macros, they tend to give horrible error messages which mentions things after expansion. Here is what I once got: mico-c++ -Wall -I. -c serwer.cc -o serwer.o serwer.cc: In method `void Firma_impl::usun(const char *)': serwer.cc:92: `struct __rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *>' has no member named `second' serwer.cc:93: no matching function for call to `map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase (__rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *> &)' /usr/include/g++/stl_map.h:156: candidates are: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>) /usr/include/g++/stl_map.h:157: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(const string &) /usr/include/g++/stl_map.h:158: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>, __rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair, __default_alloc_template >,Katalog *> *>) make: *** [serwer.o] Error 1 They also have some advantages over mechanisms available in Haskell: * A templatized class can contain types, values with arbitrary types, other templates etc. so it's easy to have parametrization of all things by types. Haskell requires fundeps, dummy arguments and local quantifiers to handle these things - sometimes it's not nice. * A template can be parametrized by values of primitive types (by expressions using builtin operations which can be evaluated at compile time). Yes, it's ugly that types and operations don't have equal rights, but it's sometimes useful. * A template is in practice guaranteed to be specialized to used types, so they don't have a performance overheads over non-templatized variants. My not-quite-done-right attempt at inlining dictionary functions in ghc is a step in this direction, as is the proposal of export-unfolding-and-specialize-but-not-necessarily-inline. I hope that SimonPJ will sort this out. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@repetae.net Fri May 18 20:32:11 2001 From: john@repetae.net (John Meacham) Date: Fri, 18 May 2001 12:32:11 -0700 Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: ; from josefs@cs.chalmers.se on Fri, May 18, 2001 at 10:32:54AM +0200 References: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: <20010518123211.E13591@mark.ugcs.caltech.edu> this is interesting, could someone give an example of how polymorphic recursion would disallow specialization of a function? i mean, it seems to me that even if you had recursion, you still have to actually call the function at some point with some real type and at that point you can decide whether to use the specialized version or not. One of the main things i was hopeing was that the seperate 'generic' and 'concrete' functions in the Prelude could be dumped for just the generic ones. the compiler should be able to optimize for the common cases of Nums being Ints and whatnot. (with the help of some pragma annotations.) -John On Fri, May 18, 2001 at 10:32:54AM +0200, Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. > > Cheers, > /Josef -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From mg169780@students.mimuw.edu.pl Fri May 18 22:10:54 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Fri, 18 May 2001 23:10:54 +0200 (CEST) Subject: Templates in FPL? In-Reply-To: <3B054C2F.C1BBE335@tzi.de> Message-ID: On Fri, 18 May 2001, George Russell wrote: > The minus points are thuswise, so far as I know: > (1) the compiled code is bigger. (...) > (2) It takes much longer to compile. (...) As it is very aggressive optimization, I strongly suggest explicit(non-default) compiler switch Greetings :-) Michal Gajda korek@icm.edu.pl From qrczak@knm.org.pl Fri May 18 21:44:52 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 20:44:52 GMT Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library References: <20010517114250.D13591@mark.ugcs.caltech.edu> <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > this is interesting, could someone give an example of how polymorphic > recursion would disallow specialization of a function? test:: Show a => a -> [String] test x = show x : test [x] -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From Jan de Wit" <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: <002a01c0e076$6029f8a0$9505c5d5@yatima> From: "Marcin 'Qrczak' Kowalczyk" > Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > > > this is interesting, could someone give an example of how polymorphic > > recursion would disallow specialization of a function? > > test:: Show a => a -> [String] > test x = show x : test [x] Another source of programs needing polymorphic recursion are non-regular datatypes, which occur frequently in Chris Okasaki's _Purely_Functional_Data_Structures_. A bare-bones example is: | data Perfect a = One a | Two (Perfect (a,a)) | deriving Show | | mkPerfect :: Int -> a -> Perfect a | mkPerfect 1 x = One x | mkPerfect (n+1) x = Two (mkPerfect n (x,x)) mkPerfect will be called with a number of different types for its second argument, depending on the first argument. HTH, Jan de Wit From ml_dk@excite.com Tue May 1 13:31:03 2001 From: ml_dk@excite.com (ml_dk@excite.com) Date: Tue, 1 May 2001 14:31:03 +0200 Subject: The Haskell kernel Message-ID: <3AE495BD00012269@cpmail.asap.asp.net> In the report on the Haskell programming language (http://www.haskell.org= /onlinereport/), the Haskell kernel is mentionen in several places. It says in section 1.2= that the Haskell kernel is a slightly sugared form of lambda calculus. Fu= thermore most expression should be possible to translate to the Haskell kernel. But where is this kernel defined (I cannot find it in the report) ? Actually the case-expression(section 3.13) seems more fundamental than th= e lambda-expression in Haskell. Several construct translate to the case-exp= ression instead of lambda-expression as the if-expression(section 3.6). It is als= o shown howto translate the lambda-expression into the case-expression in section 3.3. Am I missing something here ? Grateful for any hint. Mads ________________________________________ Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt! From simonpj@microsoft.com Tue May 1 17:22:19 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 1 May 2001 09:22:19 -0700 Subject: The Haskell kernel Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E6A@red-msg-09.redmond.corp.microsoft.com> I'm afraid the "Haskell kernel" isn't formally defined. The Report describes how to translate complex constructs into simpler ones, but neither specifies *exactly* what these simpler ones are, nor gives their meaning in a formal way. Simon | -----Original Message----- | From: ml_dk@sol.dk [mailto:ml_dk@sol.dk]=20 | Sent: 01 May 2001 13:31 | To: Haskell mailinglist | Subject: The Haskell kernel |=20 |=20 |=20 | In the report on the Haskell programming language=20 | (http://www.haskell.org/onlinereport/), | the Haskell kernel is mentionen in several places. It says in=20 | section 1.2 that the Haskell kernel is a slightly sugared=20 | form of lambda calculus. Futhermore most expression should be=20 | possible to translate to the Haskell kernel. |=20 | But where is this kernel defined (I cannot find it in the report) ? |=20 | Actually the case-expression(section 3.13) seems more=20 | fundamental than the lambda-expression in Haskell. Several=20 | construct translate to the case-expression instead of=20 | lambda-expression as the if-expression(section 3.6). It is=20 | also shown howto translate the lambda-expression into the=20 | case-expression in section 3.3. Am I missing something here ? |=20 | Grateful for any hint. |=20 | Mads |=20 |=20 |=20 | ________________________________________ | F=E5 din egen webmail p=E5 http://mail.sol.dk - gratis og med dig = overalt! |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From senganb@ia.nsc.com Wed May 2 01:58:07 2001 From: senganb@ia.nsc.com (Sengan) Date: Tue, 01 May 2001 20:58:07 -0400 Subject: Interesting: "Lisp as a competitive advantage" Message-ID: <3AEF5B9F.88D92A76@ia.nsc.com> http://www.paulgraham.com/paulgraham/avg.html I wonder how Haskell compares in this regard. Any comment from Haskell startups? (eg Galois Connections) Sengan From matth@mindspring.com Wed May 2 02:42:34 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 01 May 2001 20:42:34 -0500 Subject: User defined Ix instances potentially unsafe Message-ID: <3AEF660A.87AF9D6C@mindspring.com> Sorry if this has been reported before. I shouldn't be able to crash ghc or hugs without using any "unsafe" features, right? Well, here 'tis: > module CrashArray where > > import Array > import Ix > > newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show) > > instance Enum CrashIx where > toEnum x = (CrashIx x) > fromEnum (CrashIx x) = x > > instance Ix CrashIx where > inRange (_,_) _ = True > index (_,_) (CrashIx x) = x > range (x,y) = [x..y] > > myArray = listArray (CrashIx 0, CrashIx 0) [0] > crash = myArray ! (CrashIx maxBound) In ghci-5.00, I get a segfault and hugs-feb-2000 says: INTERNAL ERROR: Error in graph Now, admittedly my Ix instance is broken, but I don't think I should be able to segfault the interpreter. Unfortunately, I think the only way to fix this without changing the Library Report would be to add another layer of range checking to the array implementation. Bleh. Note also that the (inefficient) implementation in the report wouldn't crash, but would get the "wrong" error: "Undefined array element" instead of "Index out of range". I think we might describe this as a bug in the Library Report, rather than in any particular Haskell implementation. Enjoy! Matt Harden From chak@cse.unsw.edu.au Wed May 2 08:21:00 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Wed, 02 May 2001 17:21:00 +1000 Subject: Interesting: "Lisp as a competitive advantage" In-Reply-To: <3AEF5B9F.88D92A76@ia.nsc.com> References: <3AEF5B9F.88D92A76@ia.nsc.com> Message-ID: <20010502172100G.chak@cse.unsw.edu.au> Sengan wrote, > http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. > Any comment from Haskell startups? (eg Galois Connections) I already see John Launchbury asking us not to teach Haskell anymore ;-) Manuel From lordcrucifix@yahoo.com Wed May 2 09:31:54 2001 From: lordcrucifix@yahoo.com (lynn yeong) Date: Wed, 2 May 2001 01:31:54 -0700 (PDT) Subject: List of words Message-ID: <20010502083154.19873.qmail@web14208.mail.yahoo.com> --0-1918502651-988792314=:18992 Content-Type: text/plain; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! --------------------------------- Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992 Content-Type: text/html; charset=us-ascii Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices --0-1918502651-988792314=:18992-- From uk1o@rz.uni-karlsruhe.de Wed May 2 09:34:31 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Wed, 2 May 2001 10:34:31 +0200 Subject: List of words In-Reply-To: <20010502083154.19873.qmail@web14208.mail.yahoo.com>; from lordcrucifix@yahoo.com on Wed, May 02, 2001 at 01:31:54AM -0700 References: <20010502083154.19873.qmail@web14208.mail.yahoo.com> Message-ID: <20010502103428.B7733@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:31:54AM -0700, lynn yeong wrote: > Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a given list. I haveno idea how to do it, can you help? Thanks! [please wrap your lines!] How about this: import Char(toUpper) capitalize :: String -> String capitalize [] = [] capitalize (c:cs) = toUpper c : cs capitalizeList :: [String] -> [String] capitalizeList = map capitalize Kind regards, Hannah. From ashley@semantic.org Wed May 2 09:42:55 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 01:42:55 -0700 Subject: List of words Message-ID: <200105020842.BAA13085@mail4.halcyon.com> At 2001-05-02 01:34, Hannah Schroeter wrote: >How about this: > >import Char(toUpper) > >capitalize :: String -> String >capitalize [] = [] >capitalize (c:cs) = toUpper c : cs > >capitalizeList :: [String] -> [String] >capitalizeList = map capitalize ...or if you prefer... capitalizeList :: [String] -> [String] capitalizeList = map (map toUpper) -- Ashley Yakeley, Seattle WA From rjmh@cs.chalmers.se Wed May 2 09:51:58 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 10:51:58 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105020851.KAA15484@muppet30.cs.chalmers.se> (B) Monomorphism restriction "wins" Bindings that fall under the monomorphism restriction can't be generalised Always generalise over implicit parameters *except* for bindings that fall under the monomorphism restriction Consequences * Inlining isn't valid in general * No unexpected loss of sharing * Simple bindings like z = ?y + 1 accepted (get value of ?y from binding site) (C) Always generalise over implicit parameters Bindings that fall under the monomorphism restriction can't be generalised, EXCEPT for implicit parameters Consequences * Inlining remains valid * Unexpected loss of sharing (from the extra generalisation) * Simple bindings like z = ?y + 1 accepted (get value of ?y from occurrence sites) Discussion ~~~~~~~~~~ None of these choices seems very satisfactory. But at least we should decide which we want to do. It's really not clear what is the Right Thing To Do. If you see z = (x::Int) + ?y would you expect the value of ?y to be got from the *occurrence sites* of 'z', or from the valuue of ?y at the *definition* of 'z'? In the case of function definitions, the answer is clearly the former, but less so in the case of non-fucntion definitions. On the other hand, if we say that we get the value of ?y from the definition site of 'z', then inlining 'z' might change the semantics of the program. Choice (C) really says "the monomorphism restriction doesn't apply to implicit parameters". Which is fine, but remember that every innocent binding 'x = ...' that mentions an implicit parameter in the RHS becomes a *function* of that parameter, called at each use of 'x'. Now, the chances are that there are no intervening 'with' clauses that bind ?y, so a decent compiler should common up all those function calls. So I think I strongly favour (C). Indeed, one could make a similar argument for abolishing the monomorphism restriction altogether. I disagree. I think it's important to have a simple model of how many times expressions are evaluated. Function bodies are clearly evaluated many times, once for each call, but non-function bindings should be evaluated at most once to respect call-by-need semantics. Breaking the monomorphism restriction in ANY case makes both space and time cost of evaluation unpredictable, and brittle when program changes elsewhere introduce or remove an implicit parameter. It isn't good enough to say `the chances are' that a program has, for example, linear time and constant space complexity: the programmer should be able to convince himself of such properties. As far as what one would `expect', it's in the very nature of dynamic binding that it makes the meaning of an expression depend on its context. I for one would certainly not expect that inlining a definition bound to such an expression should preserve its meaning! Inlining changes the context, so `of course' can change the meaning. So I strongly prefer (B)! John Hughes From karczma@info.unicaen.fr Wed May 2 10:51:18 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 02 May 2001 11:51:18 +0200 Subject: List of words References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <3AEFD896.1A168297@info.unicaen.fr> I am relatively new to Haskell. Somebody told me that it is a very good language, because all the people on its mailing list are so nice that they solve all homeworks, even quite silly, of all students around, provided they ask for a solution in Haskell. Is that true, or a little exaggerated? Jerzy Karczmarczuk From rjmh@cs.chalmers.se Wed May 2 12:29:46 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Wed, 2 May 2001 13:29:46 +0200 (MET DST) Subject: Erlang workshop Message-ID: <200105021129.NAA18088@muppet30.cs.chalmers.se> (apologies if you receive more than one copy of this). Call for abstracts to the Erlang Workshop Firenze, September 2, 2001, in connection with PLI2001=20 (Principles, Logics, and Implementations of high-level=20 programming languages). Scope Contributions are invited on experience with and=20 applications of Erlang, critiques and proposals for=20 extensions, design methods and structuring principles=20 for large functional systems, implementation techniques,=20 programming tools, verification methods, etc. Submitted abstracts should be 2-12 pages, and will be=20 judged on the potential for an interesting presentation. Abstracts should in text, postscript or PDF format and sent to workshop@erix.ericsson.se by May 15, 2001.=20 Authors will be notified of acceptance by June 15, 2001. Authors of accepted abstracts are welcome to submit=20 full papers or additional accompanying materials for=20 inclusion in the informal proceedings by August 15, 2001. Home page of the Erlang workshop http://www.erlang.se/workshop/ Home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome Joe Armstrong, Alteon Websystems Bjarne D=E4cker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee) From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 12:54:38 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 12:54:38 +0100 Subject: List of words In-Reply-To: Message from Jerzy Karczmarczuk of "Wed, 02 May 2001 11:51:18 +0200." <3AEFD896.1A168297@info.unicaen.fr> Message-ID: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Ah, but (i) not all the solutions are correct (sorry Ashley); and (ii) some of the solutions should be recognisable by markers as not the work of a newbie (explicit import lists, map, ...). Essentially, though, your friend is correct. --KW 8-) From ashley@semantic.org Wed May 2 13:19:52 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 2 May 2001 05:19:52 -0700 Subject: List of words Message-ID: <200105021219.FAA23304@mail4.halcyon.com> At 2001-05-02 04:54, Keith Wansbrough wrote: >Ah, but (i) not all the solutions are correct (sorry Ashley); That rather depends on what you mean by CAPITALISE, does it not? capitalise, -ize to print or write with capital letters [Chambers] -- Ashley Yakeley, Seattle WA From Keith.Wansbrough@cl.cam.ac.uk Wed May 2 13:27:18 2001 From: Keith.Wansbrough@cl.cam.ac.uk (Keith Wansbrough) Date: Wed, 02 May 2001 13:27:18 +0100 Subject: List of words In-Reply-To: Message from Ashley Yakeley of "Wed, 02 May 2001 05:19:52 PDT." <200105021219.FAA23304@mail4.halcyon.com> Message-ID: > >Ah, but (i) not all the solutions are correct (sorry Ashley); > > That rather depends on what you mean by CAPITALISE, does it not? > > capitalise, -ize to print or write with capital letters [Chambers] I guess so. Maybe someone at Monash University (Australia) would care to enlighten us? >;-> --KW 8-) -- Keith Wansbrough http://www.cl.cam.ac.uk/users/kw217/ Cambridge University Computer Laboratory. From jans@numeric-quest.com Wed May 2 08:36:14 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Wed, 2 May 2001 03:36:14 -0400 (EDT) Subject: List of words In-Reply-To: <3AEFD896.1A168297@info.unicaen.fr> Message-ID: On Wed, 2 May 2001, Jerzy Karczmarczuk wrote: > I am relatively new to Haskell. > > Somebody told me that it is a very good language, because all the > people on its mailing list are so nice that they solve all > homeworks, even quite silly, of all students around, provided they > ask for a solution in Haskell. > > Is that true, or a little exaggerated? Not really. No one wants to answer my questions. :-) Do you think that this list is the only source of easy solutions? See what people ask Google and what Google sends to our web server: procedural+design+for+a+program+that+accepts+a+string +as+input+and+then+converts+all+upper+case+to+lower+case +and++vice-versa+and+prints+resulting+string+as+output Must be a tough and generic problem. Notice that Haskell is not mentioned here at all, but yet Google happily directed it to one of Haskell pages here. By the way, this is not the longest question that I've seen in the logs. Some are so long and weird that must match any web page out there. Jan From ralf@cs.uu.nl Tue May 1 17:47:11 2001 From: ralf@cs.uu.nl (Ralf Hinze) Date: Tue, 01 May 2001 18:47:11 +0200 Subject: 2001 Haskell Workshop: final call for papers Message-ID: <3AEEE88F.1BA9E9BC@cs.uu.nl> ============================================================================ FINAL CALL FOR PAPERS [Deadline for submission: 1st June 2001] 2001 Haskell Workshop Firenze, Italy, 2nd September 2001 The Haskell Workshop forms part of the PLI 2001 colloquium on Principles, Logics, and Implementations of high-level programming languages, which comprises the ICFP/PPDP conferences and associated workshops. Previous Haskell Workshops have been held in La Jolla (1995), Amsterdam (1997), Paris (1999), and Montreal (2000). http://www.cs.uu.nl/people/ralf/hw2001.{html,pdf,ps,txt} ============================================================================ Scope ----- The purpose of the Haskell Workshop is to discuss experience with Haskell, and possible future developments for the language. The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell. Submissions that discuss limitations of Haskell at present and/or propose new ideas for future versions of Haskell are particularly encouraged. Adopting an idea from ICFP 2000, the workshop also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters ------------------- An application letter describes experience using Haskell to solve real-world problems. Such a paper might typically be about six pages, and may be judged by interest of the application and novel use of Haskell. Functional Pearls ----------------- A functional pearl presents - using Haskell as a vehicle - an idea that is small, rounded, and glows with its own light. Such a paper might typically be about six pages, and may be judged by elegance of development and clarity of expression. Submission details ------------------ Deadline for submission: 1st June 2001 Notification of acceptance: 12th July 2001 Final submission due: 1st August 2001 Haskell Workshop: 2nd September 2001 Authors should submit papers in postscript format, formatted for A4 paper, to Ralf Hinze (ralf@cs.uu.nl) by 1st June 2001. Use of the ENTCS style files is strongly recommended. The length should be restricted to the equivalent of 5000 words (which is approximately 24 pages in ENTCS format, or 12 pages in ACM format). Note that this word limit represents a change from the first call for papers. Application letters and functional pearls should be labeled as such on the first page; they may be any length up to the above limit, though shorter submissions are welcome. The accepted papers will initially appear as a University of Utrecht technical report, and subsequently be published as an issue of Electronic Notes in Theoretical Computer Science. Programme committee ------------------- Manuel Chakravarty University of New South Wales Jeremy Gibbons University of Oxford Ralf Hinze (chair) University of Utrecht Patrik Jansson Chalmers University Mark Jones Oregon Graduate Institute Ross Paterson City University, London Simon Peyton Jones Microsoft Research Stephanie Weirich Cornell University ============================================================================ From rossberg@ps.uni-sb.de Wed May 2 18:07:31 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Wed, 02 May 2001 19:07:31 +0200 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF03ED3.754BD3F3@ps.uni-sb.de> John Hughes wrote: > > I think it's important to have a simple model of how many > times expressions are evaluated. Function bodies are clearly > evaluated many times, once for each call, but non-function > bindings should be evaluated at most once to respect > call-by-need semantics. Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From uk1o@rz.uni-karlsruhe.de Wed May 2 23:44:54 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 3 May 2001 00:44:54 +0200 Subject: List of words In-Reply-To: <200105020842.BAA13085@mail4.halcyon.com>; from ashley@semantic.org on Wed, May 02, 2001 at 01:42:55AM -0700 References: <200105020842.BAA13085@mail4.halcyon.com> Message-ID: <20010503004453.A14362@rz.uni-karlsruhe.de> Hello! On Wed, May 02, 2001 at 01:42:55AM -0700, Ashley Yakeley wrote: > At 2001-05-02 01:34, Hannah Schroeter wrote: > >capitalize (c:cs) = toUpper c : cs > >capitalizeList = map capitalize > ...or if you prefer... > capitalizeList :: [String] -> [String] > capitalizeList = map (map toUpper) I understood "capitalize" as toUpper only the *first* character of a string. Your capitalizeList at least isn't denotationally the same as mine. hannahCapitalizeList ["this", "is", "a", "fox"] === ["This", "Is", "A", "Fox"] ashleyCapitalizeList ["this", "is", "a", "fox"] === ["THIS", "IS", "A", "FOX"] Kind regards, Hannah. From erik@meijcrosoft.com Thu May 3 01:57:34 2001 From: erik@meijcrosoft.com (Erik Meijer) Date: Wed, 2 May 2001 17:57:34 -0700 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <006401c0d36c$0af45f90$34b11eac@redmond.corp.microsoft.com> > [...many lines deleted...] > I think it's important to have a simple model of how many times expressions > are evaluated. Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Breaking the monomorphism restriction in ANY case > makes both space and time cost of evaluation unpredictable, and brittle when > program changes elsewhere introduce or remove an implicit parameter. It isn't > good enough to say `the chances are' that a program has, for example, linear > time and constant space complexity: the programmer should be able to convince > himself of such properties. But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. > As far as what one would `expect', it's in the very nature of dynamic binding > that it makes the meaning of an expression depend on its context. I for one > would certainly not expect that inlining a definition bound to such an > expression should preserve its meaning! Inlining changes the context, so > `of course' can change the meaning. So I strongly prefer (B)! > > John Hughes > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From nikhil@acm.org Thu May 3 02:19:57 2001 From: nikhil@acm.org (Rishiyur S. Nikhil) Date: Wed, 02 May 2001 21:19:57 -0400 Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: <3AF0B23D.B703F8D4@mediaone.net> John Hughes wrote: > ... Function bodies are clearly evaluated many times, once for each > call, but non-function bindings should be evaluated at most once to respect > call-by-need semantics. Isn't this a very fragile distinction? It seems so susceptible to routine program transformations by both programmers and compilers (e.g., lambda lifting/unlifting, which can change a non-function finding into a function binding and vice versa). Also, I agree with Andreas Rossberg's observation: > ... the Haskell Report ... does not even > demand call-by-need evaluation (it only speaks of non-strict > semantics). Nikhil From matth@mindspring.com Thu May 3 03:39:13 2001 From: matth@mindspring.com (Matt Harden) Date: Wed, 02 May 2001 21:39:13 -0500 Subject: User defined Ix instances potentially unsafe References: <3AEF660A.87AF9D6C@mindspring.com> Message-ID: <3AF0C4D1.AB12C703@mindspring.com> Matt Harden wrote: > blah, blah, blah, bug in the Library Report, blah, blah... OK, so I failed to read the Library Report. It clearly states: > An implementation is entitled to assume the following laws about these operations: > > range (l,u) !! index (l,u) i == i -- when i is in range > inRange (l,u) i == i `elem` range (l,u) So my "bug" is only in my mind. Sorry for bothering everyone. Regards, Matt From Critterrathman@aol.com Thu May 3 07:54:26 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 02:54:26 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_da.5caeee1.28225aa2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman --part1_da.5caeee1.28225aa2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit I know just enuf about existential types in Haskell to be dangerous. While trying to learn a little more about how to use them, I keep running into problem. The existential types work great for code that I constructed if the functions take a single argument. However, if the function takes more than one argument, I can't seem to figure out how to get them to work. In the test code below, everything compiles in Hugs (hugs98-Feb2001) except the last line in the instance declaration (setx). Is there something fundamental that I'm missing about how to create an existential instance and/or data declaration - given the listed class definition? module Test where class Shape a where getx :: a -> Int setx :: a -> Int -> a data ExistentialShape = forall a. Shape a => MakeExistentialShape a instance Shape ExistentialShape where getx (MakeExistentialShape a) = getx a setx (MakeExistentialShape a) newx = setx a newx -- here's the error message I get when I try to :load the module ERROR test.hs:14 - Type error in instance member binding *** Term : setx *** Type : ExistentialShape -> Int -> _12 *** Does not match : ExistentialShape -> Int -> ExistentialShape *** Because : cannot instantiate Skolem constant Thanks, Chris Rathman --part1_da.5caeee1.28225aa2_boundary-- From simonpj@microsoft.com Thu May 3 08:13:23 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 00:13:23 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> | As far as what one would `expect', it's in the very nature of=20 | dynamic binding that it makes the meaning of an expression=20 | depend on its context. I for one would certainly not expect=20 | that inlining a definition bound to such an=20 | expression should preserve its meaning! Inlining changes the=20 | context, so `of course' can change the meaning. So I strongly=20 | prefer (B)! John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. (For ordinary type classes, the monomorphism restriction will reject some programs that would otherwise be well typed;=20 for implicit parameters, (B) will accept the program but with --- potentially ---- a different meaning.) b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon From rjmh@cs.chalmers.se Thu May 3 08:48:20 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 09:48:20 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030748.JAA05638@muppet30.cs.chalmers.se> But a term with an "implicit" argument is a function no matter how you turn it, you just don't write the argument explicitely. I don't buy that. You could equally well say a term with a free variable is a "function" (of the environment): sure it is, but if it's bound with a let then the function is called only once. John From rjmh@cs.chalmers.se Thu May 3 09:02:10 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:02:10 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030802.KAA05827@muppet30.cs.chalmers.se> Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. Well, the Haskell Report may not require call-by-need semantics, but it permits it at least. Without the MR that would not be the case: some programs would *require* call-by-name. Actually I would prefer the report to be much more explicit about both sharing and evaluation order, to enable compiler-independent reasoning about time and space behaviour. As it stands, compilers do in fact implement call-by-need, and so one can in practice reason fairly safely about time behaviour, but they vary in the choice of evaluation order, which makes space leaks come and go on different compilers. In any case, I don't buy the argument that because reasoning about costs is already problematic in Haskell, it doesn't matter if we make it even harder...! > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. I have no faith in compiler warnings. For one thing, they're irritating. For another, you don't see them when it matters -- when you *read* the code. I'd far rather explicitly distinguish call-by-name and call-by-value in the source code (and made a suggestion along these lines some time ago), so that the semantics is visible to all. Of course, we can't forbid the programmer to write inefficient programs. But we can make gross inefficiencies easier or harder to find. Haskell just can't be used in practice unless one tracks down and fixes space leaks. I don't want to be debugging "time leaks" caused by unexpected call-by-name as well! -- Andreas Rossberg, rossberg@ps.uni-sb.de John Hughes From jeff@nwlewis.com Thu May 3 09:12:02 2001 From: jeff@nwlewis.com (Jeffrey R. Lewis) Date: Thu, 03 May 2001 01:12:02 -0700 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF112D2.B0DEBD9A@nwlewis.com> Simon Peyton-Jones wrote: > | As far as what one would `expect', it's in the very nature of > | dynamic binding that it makes the meaning of an expression > | depend on its context. I for one would certainly not expect > | that inlining a definition bound to such an > | expression should preserve its meaning! Inlining changes the > | context, so `of course' can change the meaning. So I strongly > | prefer (B)! > > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. > Certainly a point well worth thinking about... > > > b) That whether or not a definition is unconditionally inlinable > at the source-language level cannot be determined by looking > at the expression. You have to do something rather like effects > analysis: look to see if it calls any function (transitively) that > uses > an implicit parameter. This apparently esoteric effects analysis is called `type inference' ;-) Oh for better programming environments where it's easy to ask questions about the types of things. But the fun thing is, a) that analysis is way too conservative, and b) it is not even necessary in order to actually do the inlining safely. To do the inlining, you have to be careful to observe any `with' bindings that *statically scope* over the location of the inlining, and do some dynamic variable renaming to avoid capture. Yes, this isssue is well worth thinking about from a design decision point of view, but the situation is not as dire as it seems at first sight. --Jeff From rjmh@cs.chalmers.se Thu May 3 09:22:24 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Thu, 3 May 2001 10:22:24 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105030822.KAA06145@muppet30.cs.chalmers.se> John: just to check, you do realise that (B) means a) That adding a type signature can change the dynamic semantics of the program. This would be the first and only occurrence of such behaviour. At present, adding a type signature changes both the static semantics and the cost of running a program -- one should already understand that a type signature with a non-empty context means the expression is evaluated at its uses rather than at its definition. Given that one understands that, and that an expression which uses an implicit parameter will have a type signature which explicitly indicates that, I don't think this is really such a big deal. b) That whether or not a definition is unconditionally inlinable at the source-language level cannot be determined by looking at the expression. You have to do something rather like effects analysis: look to see if it calls any function (transitively) that uses an implicit parameter. These seem like pretty dire properties. Are you sure it's worth it? Simon Are you sure this second one really holds? I claim the effects analysis is just type inference! If the expression has a context referring to an implicit parameter, then it cannot be unconditionally inlined -- it's as simple as that, isn't it? Admittedly, this really only solves the problem for the compiler -- the poor programmer may have more trouble doing type inference in his head. (How much easier life would be with = for call-by-name, := for call-by-need...) So maybe not so dire as you made out! John From ashley@semantic.org Thu May 3 09:57:33 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 3 May 2001 01:57:33 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105030857.BAA20037@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >| In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: >| >| class X a b | a -> b where x :: a; >| class (X a b) => Y a b | a -> b where y :: a; >| instance (X a b) => Y a b where y = x; >| instance (Num a) => X a a where x = 0; -- line A > >Quite right too! The final instance declaration says that the two >arguments of X must always be the same: Hmm... > * the class says a->b Yes. > * the instance matches any first arg I was rather hoping that the instance would match only (Num a => a) rather than (a). > and says that the second must be equal. Yes. -- Ashley Yakeley, Seattle WA From qrczak@knm.org.pl Thu May 3 09:15:06 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 08:15:06 GMT Subject: Existential Type Declarations in Hugs References: Message-ID: Thu, 3 May 2001 02:54:26 EDT, Critterrathman@aol.com pisze: > class Shape a where > getx :: a -> Int > setx :: a -> Int -> a > > data ExistentialShape = > forall a. Shape a => MakeExistentialShape a > > instance Shape ExistentialShape where > getx (MakeExistentialShape a) = getx a > setx (MakeExistentialShape a) newx = setx a newx Should be: setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a newx) The result of setx must have the same type as its first argument. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Thu May 3 09:42:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:42:10 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E99@red-msg-09.redmond.corp.microsoft.com> | In Hugs 98 Feb2001 (as hugs -98), this piece of code gives an error: |=20 | class X a b | a -> b where x :: a; | class (X a b) =3D> Y a b | a -> b where y :: a; | instance (X a b) =3D> Y a b where y =3D x; | instance (Num a) =3D> X a a where x =3D 0; -- line A Quite right too! The final instance declaration says that the two arguments of X must always be the same: * the class says a->b * the instance matches any first arg and says that the second must be equal. So when typechecking the instance for Y a b, a and b are forced to be equal, and that's less general than the instance claims to be. Simon From simonpj@microsoft.com Thu May 3 09:37:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 3 May 2001 01:37:22 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> | a) That adding a type signature can change the dynamic semantics | of the program. This would be the first and only=20 | occurrence of | such behaviour. |=20 | At present, adding a type signature changes both the static=20 | semantics and the cost of running a program=20 That's true: but adopting (B) means that adding a type signature may cause the program to print a different answer! That seems qualitiatively different to giving the same answer only slower or faster; or rejecting the program altogether. Type signatures should specialise a type -- which means that efficiency may increase, or that the program may no longer be typable, but surely it shouldn't change the answer! =20 | Are you sure this second one really holds? I claim the=20 | effects analysis is just type inference!=20 Indeed it is. I just don't want programmers to have to do type=20 inference in their heads to figure out the meaning of the program. Simon From lennart@mail.augustsson.net Thu May 3 10:33:40 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 05:33:40 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E8C@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF125F4.E967A796@mail.augustsson.net> Simon Peyton-Jones wrote: > John: just to check, you do realise that (B) means > > a) That adding a type signature can change the dynamic semantics > of the program. This would be the first and only occurrence of > such behaviour. Not so, there are already Haskell program that give a different results with and without type signatures. -- Lennart From lennart@mail.augustsson.net Thu May 3 11:29:35 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 06:29:35 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3AF1330E.B383F42C@mail.augustsson.net> Simon Peyton-Jones wrote: > | a) That adding a type signature can change the dynamic semantics > | of the program. This would be the first and only > | occurrence of > | such behaviour. > | > | At present, adding a type signature changes both the static > | semantics and the cost of running a program > > That's true: but adopting (B) means that adding a type signature > may cause the program to print a different answer! That seems > qualitiatively different to giving the same answer only slower or > faster; > or rejecting the program altogether. Type signatures should specialise > a type -- which means that efficiency may increase, or that the program > may > no longer be typable, but surely it shouldn't change the answer! Try this program: -- Try commenting out this type signature. fun :: (Num a) => a -> Int fun 0 = if fun 1 == 1 then fun 2 else fun (3::Int) g :: (a -> b) -> b g f = f undefined ii = g fun class C a where m :: a -> String instance C Int where m _ = "You have a type signature" instance C Integer where m _ = "You forgot the type signature" main = putStrLn (m ii) -- Lennart PS. There are better examples, but this was all I could think of right now. From qrczak@knm.org.pl Thu May 3 12:50:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 11:50:47 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > Try this program: > -- Try commenting out this type signature. > fun:: (Num a) => a -> Int Test.hs:7: Ambiguous type variable(s) `a' in the constraint `Num a' arising from use of `fun' at Test.hs:7 In the first argument of `g', namely `fun' In the definition of `ii': g fun Test.hs:18: Ambiguous type variable(s) `a' in the constraint `C a' arising from use of `m' at Test.hs:18 In the first argument of `putStrLn', namely `(m ii)' In the definition of `main': putStrLn (m ii) Defaulting applies only when all classes involved are Haskell 98. hbc, nhc98 and Hugs are not conforming. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From lennart@mail.augustsson.net Thu May 3 13:07:10 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Thu, 03 May 2001 08:07:10 -0400 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> Message-ID: <3AF149EE.3C252258@mail.augustsson.net> Marcin 'Qrczak' Kowalczyk wrote: > Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson pisze: > > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > > Test.hs:7: > Ambiguous type variable(s) `a' in the constraint `Num a' > arising from use of `fun' at Test.hs:7 > In the first argument of `g', namely `fun' > In the definition of `ii': g fun > > Test.hs:18: > Ambiguous type variable(s) `a' in the constraint `C a' > arising from use of `m' at Test.hs:18 > In the first argument of `putStrLn', namely `(m ii)' > In the definition of `main': putStrLn (m ii) > > Defaulting applies only when all classes involved are Haskell 98. First, I cannot parse that sentence, but I assume you mean when all classes are Prelude classes. Second, I'm pretty sure we all agreed that this was a silly rule and should not be in the Haskell definition. I was certain that that it had been removed from the Haskell report, but I guess not. (hbc used to make this check, but I removed it when everyone seemed to agree that rule was a bad idea). Third, moving ii to a different module might still exhibit this problem. (I'm not sure how ghc defaults exported definitions.) But most importantly, this was a bad example. There was a much better one posted on this mailing list a while ago. Does anyone remember it? -- Lennart > > hbc, nhc98 and Hugs are not conforming. From fst@informatik.uni-kiel.de Thu May 3 13:09:01 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Thu, 3 May 2001 14:09:01 +0200 Subject: WFLP 2001 - Final Call for Papers Message-ID: <200105031209.OAA02408@listrac.informatik.uni-kiel.de> ====================================================================== FINAL CALL FOR PAPERS WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming comprising the 10th International Workshop on Functional and Logic Programming and 16th Workshop on Logic Programming Kiel, Germany September 13-15, 2001 ====================================================================== NEW: * Submission guidelines for electronic submissions * Special issue of ENTCS (Electronic Notes in Theoretical Computer Science) for selected papers ---------------------------------------------------------------------- GENERAL WFLP 2001 is the combination of two workshops of a successful series of annual workshops on declarative programming. The international workshops on functional and logic programming aimed at bringing together researchers interested in functional programming, logic programming, as well as their integration. Previous workshops have been held in Benicassim (Spain), Grenoble (France), Bad Honnef (Germany). The workshops on (constraint) logic programming are the annual meeting of the Society of Logic Programming (GLP e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases and artificial intelligence. Previous workshops have been held in Germany, Austria and Switzerland. In this year both workshops will be jointly organized in order to promote the cross-fertilizing exchange of ideas and experiences among researches and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The technical program of the workshop will include invited talks, presentations of refereed papers and demo presentations. The WWW page of the workshop is: http://www.informatik.uni-kiel.de/~wflp2001 ---------------------------------------------------------------------- TOPICS The topics of interest include (but are not limited to): * Functional programming * Logic programming * Constraint programming * Deductive databases * Extensions of declarative languages, objects * Multi-paradigm declarative programming * Foundations, semantics, nonmonotonic reasoning, dynamics * Parallelism, concurrency * Program analysis, abstract interpretation * Program transformation, partial evaluation, meta-programming * Specification, verification, declarative debugging * Knowledge representation, machine learning * Implementation of declarative languages * Advanced programming environments and tools * Applications The primary focus is on new and original research results but submissions describing innovative products, prototypes under development or interesting experiments (e.g., benchmarks) are also encouraged. ---------------------------------------------------------------------- IMPORTANT DATES Submission of papers: May 15, 2001 Notification of acceptance: June 20, 2001 Camera-ready papers: July 20, 2001 Workshop: September 13 - 15, 2001 ---------------------------------------------------------------------- SUBMISSION Authors are invited to submit an extended abstract (no longer than 10 pages including figures and references) or a system description (no longer than 3 pages) in postscript format (11pt) before May 15, 2001. Submissions should include the title, authors' names, affiliations, addresses, and e-mail. *NEW* The details about the procedure to submit papers electronically are described on the workshop website. If you have any problems with submitting papers, please send an email to wflp2001@informatik.uni-kiel.de. ---------------------------------------------------------------------- BEST NEWCOMER AWARD An award will be given to the best paper exclusively written by one or several young researchers who have not yet obtained their PhD degrees. Papers written in this category should be clearly marked "Student papers" in the submission. ---------------------------------------------------------------------- PROCEEDINGS The proceedings with the full versions of all accepted contributions (no longer than 15 pages for regular contributions and 3 pages for system descriptions) will be published as a Technical Report of the University of Kiel. *NEW* A special issue of ENTCS (Electronic Notes in Theoretical Computer Science) containing revised versions of high-quality contributions will be organized after the workshop. ---------------------------------------------------------------------- PROGRAM The workshop will be a 3-day event including presentations of the accepted papers, system demos, and INVITED TALKS by Peter Van Roy (Catholic University of Louvain) Thomas Arts (Ericsson) ---------------------------------------------------------------------- LOCATION WFLP 2001 will take place at the Christian-Albrechts-University of Kiel. More details about the accomodation, traveling information, etc., will be available at the WFLP 2001 WWW page at http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- CONTACT WFLP 2001 Prof. Michael Hanus Institut fuer Informatik und Praktische Mathematik Christian-Albrechts-Universitaet Kiel Olshausenstr. 40 D-24098 Kiel, Germany Phone: ++49-(0)431-880-7271 or -7270 (Secr.) Fax : ++49-(0)431-880-7613 Email: wflp2001@informatik.uni-kiel.de WWW: http://www.informatik.uni-kiel.de/~wflp2001/ ---------------------------------------------------------------------- PROGRAM COMMITTEE Slim Abdennadher (LMU Muenchen) Maria Alpuente (UP Valencia) Sergio Antoy (Portland State University) Christoph Beierle (FernUniv. Hagen) Alexander Bockmayr (Univ. Henri Poincare, Nancy) Harold Boley (DFKI Kaiserslautern) François Bry (LMU Muenchen) Juergen Dix (Univ. Koblenz) Rachid Echahed (IMAG, Grenoble) Uwe Egly (TU Wien) Moreno Falaschi (Univ. Udine) Burkhard Freitag (Univ. Passau) Thom Fruehwirth (LMU Muenchen) Norbert E. Fuchs (Univ. Zuerich) Ulrich Geske (GMD-FIRST Berlin) Michael Hanus (CAU Kiel) Herbert Kuchen (Univ. Muenster) Juan Jose Moreno Navarro (UP Madrid) Mario Rodriguez-Artalejo (UC Madrid) Dietmar Seipel (Univ. Wuerzburg) ---------------------------------------------------------------------- LOCAL ORGANIZING COMMITTEE Wolfgang Goerigk Michael Hanus Klaus Hoeppner Ulrike Pollakowski-Geuther Friedemann Simon Frank Steiner ---------------------------------------------------------------------- From C.Reinke@ukc.ac.uk Thu May 3 13:19:49 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:19:49 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from "Marcin 'Qrczak' Kowalczyk" of "03 May 2001 11:50:47 GMT." Message-ID: > > Try this program: > > -- Try commenting out this type signature. > > fun:: (Num a) => a -> Int > Defaulting applies only when all classes involved are Haskell 98. > hbc, nhc98 and Hugs are not conforming. Seems you're right (all classes for the ambiguous type variable need to be from prelude or standard libraries). Okay, so let's try the good old boring show: -- ii :: Double ii = 1 main = case length (show ii) of { 1 -> putStrLn "type signature excluded" ; _ -> putStrLn "type signature included" } Still, I liked Lennart's "magic" version;-) Claus From rossberg@ps.uni-sb.de Thu May 3 13:23:27 2001 From: rossberg@ps.uni-sb.de (Andreas Rossberg) Date: Thu, 03 May 2001 14:23:27 +0200 Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: <3AF14DBF.24C85EF1@ps.uni-sb.de> Lennart Augustsson wrote: > > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? No, but this should do it: data T = T Int instance Show T where show (T n) = show n instance Eq instance Num T where fromInteger n = T n (+) (T _) (T _) = T 0 x :: T -- try removing this type signature x = 1 + 2 main = putStr (show x) - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de "Computer games don't affect kids. If Pac Man affected us as kids, we would all be running around in darkened rooms, munching pills, and listening to repetitive music." From C.Reinke@ukc.ac.uk Thu May 3 13:31:01 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 13:31:01 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > > > Try this program: > > > -- Try commenting out this type signature. > > > fun:: (Num a) => a -> Int > > Defaulting applies only when all classes involved are Haskell 98. > > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. (hbc used > to make this check, but I removed it when everyone seemed to > agree that rule was a bad idea). http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-bugs.html (Could it be made more prominent on www.haskell.org that this Haskell98 bugs list is indeed part of Simon's ongoing, soon to be completed revision of the two reports? Just so that people like me notice that the revised reports take priority over whatever the current ones say..) Page 49, Section 4.3.4, Ambiguous Types... In the third paragraph from the end of Section 4.3.4, replace "...an ambiguous type variable is defaultable if at least one of its classes is a numeric class..." by "...an ambiguous type variable, v, is defaultable if v appears only in constraints of the form (C v), where C is a class, and if at least one of its classes is a numeric class...". The new phrase is "if v appears only in constraints of the form (C v) where C is a class". Without this condition the rest of the sentence does not make sense. Claus From qrczak@knm.org.pl Thu May 3 13:48:39 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 12:48:39 GMT Subject: Implict parameters and monomorphism References: <37DA476A2BC9F64C95379BF66BA26902D72E91@red-msg-09.redmond.corp.microsoft.com> <3AF1330E.B383F42C@mail.augustsson.net> <3AF149EE.3C252258@mail.augustsson.net> Message-ID: Thu, 03 May 2001 08:07:10 -0400, Lennart Augustsson pisze: > First, I cannot parse that sentence, but I assume you mean when all > classes are Prelude classes. Not only Prelude but the whole Haskell 98 standard library. > Second, I'm pretty sure we all agreed that this was a silly rule and > should not be in the Haskell definition. I was certain that that it had > been removed from the Haskell report, but I guess not. It was not removed, it's still in . So probably it should be removed now: SimonPJ wanted to freeze the revised report in May. > Third, moving ii to a different module might still exhibit this problem. Indeed. > (I'm not sure how ghc defaults exported definitions.) I'm sure that it works as it should: they are defaulted according to visible definitions, to Int or Integer here, and from another module it is not known that the types have been ambiguous, so constraints from non-Haskell-98 classes can't stop the defaulting. This is an argument for removing that part of the defaulting rule. Or for removing the monomorphism restriction. Or both. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From C.Reinke@ukc.ac.uk Thu May 3 14:46:44 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 03 May 2001 14:46:44 +0100 Subject: Implict parameters and monomorphism In-Reply-To: Message from Lennart Augustsson of "Thu, 03 May 2001 08:07:10 EDT." <3AF149EE.3C252258@mail.augustsson.net> Message-ID: > But most importantly, this was a bad example. There was a much better > one posted on this mailing list a while ago. Does anyone remember it? > > -- Lennart Perhaps I should mention a useful application of this game, somewhat unhelpfully named "Representative thingies" in my Haskell corner: http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/ Load the file R.hs in your favourite Hugs (Hugs mode), and you'll see things like this (see comments in R.hs for more examples): Main> foldl (+) 0 [1..4] :: Int 10 Main> foldr (+) 0 [1..4] :: Int 10 Main> foldl (+) 0 [1..4] ((((0 + 1) + 2) + 3) + 4) Main> foldr (+) 0 [1..4] (1 + (2 + (3 + (4 + 0)))) Well, I found it useful (and fun; just a pity that you can't overload (implicit) application in Haskell;-).. Claus From augustss@augustsson.net Thu May 3 15:24:22 2001 From: augustss@augustsson.net (Lennart Augustsson) Date: Thu, 3 May 2001 10:24:22 -0400 (EDT) Subject: Implict parameters and monomorphism Message-ID: <200105031424.f43EOMq11179@hobbessandburst.com> OK, so since noone liked my original example here's another one. It involves no defaulting and no classes in the funny function definition. -- Here's the type signature that makes a difference. --fun :: a -> Char fun x = const (fun x) (fun True) fix f = let x = f x in x class C a where m :: a -> String instance C Char where m _ = "has signature" instance C Bool where m _ = "no signature" main = putStrLn (m (fix fun)) It is not at all surprising that you can write this. Originally type signatures only allowed you to put a signature that was more specific. Polymorhic recursion on the other hand allows you to make the type more general by putting a type signature on a definition. Combining these you can make the signature be incomparable to the deduced type. Using the class system you can then dispatch on the type and get different behaviour. -- Lennart From qrczak@knm.org.pl Thu May 3 16:04:17 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 15:04:17 GMT Subject: Implict parameters and monomorphism References: <200105020851.KAA15484@muppet30.cs.chalmers.se> Message-ID: Wed, 2 May 2001 10:51:58 +0200 (MET DST), John Hughes pisze: > Breaking the monomorphism restriction in ANY case makes both space > and time cost of evaluation unpredictable, and brittle when program > changes elsewhere introduce or remove an implicit parameter. You can always use 'case' instead of 'let' for variable bindings. I would remove the monomorphism restriction, leaving 'let' mostly for function-like bindings, which can be optimized to value bindings in some cases. Perhaps it would be good to introduce strictness annotations in 'let' and 'where'. Clean has 'let!'. It would allow increasing strictness yet more than 'case' does, without the need of transforming 'let' into 'case' or adding `seq`. I would attach '!' to individual variables (or patterns) rather than to 'let', so it's usable in 'where', 'case' and function arguments, with some bindings strict and others lazy. The semantics would insert var `seq` at the start of the appropriate body or rhs for each strict-marked var, in unspecified order (it doesn't matter in what order they are evaluated, it matters that all are evaluated). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 (EDT) Subject: FINAL CFP: SAIG'01 In-Reply-To: References: Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From taha@cs.yale.edu Thu May 3 22:13:42 2001 From: taha@cs.yale.edu (Walid Taha) Date: Thu, 3 May 2001 17:13:42 -0400 Subject: FINAL CFP: SAIG'01 In-Reply-To: References: Message-ID: FINAL CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (Deadline: May 20, 2001) http://www.cs.yale.edu/~taha/saig/cfp01.html Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) In addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by May 20th, 2001. This deadline is not extensible. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha, Yale (PC Chair) From Critterrathman@aol.com Thu May 3 22:20:06 2001 From: Critterrathman@aol.com (Critterrathman@aol.com) Date: Thu, 3 May 2001 17:20:06 EDT Subject: Existential Type Declarations in Hugs Message-ID: --part1_cd.61a8300.28232586_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time, qrczak@knm.org.pl writes: > Should be: > setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a > newx) > The result of setx must have the same type as its first argument. > Thanks. That solves my problem. BTW, what is this "Skolem constant" that's referred to in the error message that I received? Chris Rathman --part1_cd.61a8300.28232586_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/3/2001 4:00:18 AM Central Daylight Time, qrczak@knm.org.pl writes: Should be: setx (MakeExistentialShape a) newx = MakeExistentialShape (setx a newx) The result of setx must have the same type as its first argument. Thanks. That solves my problem. BTW, what is this "Skolem constant" that's referred to in the error message that I received? Chris Rathman --part1_cd.61a8300.28232586_boundary-- From reid@cs.utah.edu Thu May 3 22:26:38 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Thu, 3 May 2001 15:26:38 -0600 Subject: Implict parameters and monomorphism In-Reply-To: Message-ID: > You can always use 'case' instead of 'let' for variable bindings. Except, of course, for top level bindings which is where the monomorphism restriction is usually most noticable. > I would remove the monomorphism restriction, [...] This seems to be a pretty common sentiment but I don't see anyone pointing out that the monomorphism restriction is there for _two_ reasons: 1) The performance issues that are currently getting all the attention. 2) Preventing ambiguity in examples like: [(n,s)] = reads t where the value of "s" (whose type is String) is determined by the type of "n". This example comes from the H'98 report, section 4.5.5 "The Monomorphism Restriction". Unless I missed something, reason (2) prevents us from completely getting rid of the restriction even if we are willing to ignore (1). (Though if our only goal was to solve (2), it may be that the rule could be a lot less restrictive.) -- Alastair Reid From mark@chaos.x-philes.com Thu May 3 22:33:32 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Thu, 3 May 2001 17:33:32 -0400 (EDT) Subject: Existential Type Declarations in Hugs In-Reply-To: Message-ID: On Thu, 3 May 2001 Critterrathman@aol.com wrote: (snip) > BTW, what is this "Skolem constant" that's referred to in the error message > that I received? A combination of http://www.sdsc.edu/~tbailey/teaching/cse151/lectures/chap09a.html and http://cs.wwc.edu/~aabyan/Logic/normal.html may answer that for you. (-: (It was too long ago now for me to remember much, and I'm not sure where my notes are, so I daren't attempt an explanation myself!) -- Mark From qrczak@knm.org.pl Thu May 3 23:23:19 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 3 May 2001 22:23:19 GMT Subject: Implict parameters and monomorphism References: Message-ID: Thu, 3 May 2001 15:26:38 -0600, Alastair Reid pisze: >> You can always use 'case' instead of 'let' for variable bindings. > > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. > Unless I missed something, reason (2) prevents us from completely > getting rid of the restriction even if we are willing to ignore (1). Ok. Let's keep (2) and remove (1). ghc -fno-monomorphism-restriction allows polymorphis cases like (2) and they do create ambiguous types like Read a => String. I would treat it as a bug: removing monomorphism restriction should not go that far. Haskell 98 doesn't allow removing it for pattern bindings by supplying a type signature. Here is a crazy idea: either of these ~x = ... x@_ = ... creates a pattern binding, so it's a way of writing it without a type signature if there was no monomorphic restriction :-) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@launchbury.org Thu May 3 22:33:44 2001 From: john@launchbury.org (John Launchbury) Date: Thu, 03 May 2001 14:33:44 -0700 Subject: Implict parameters and monomorphism References: <200105030802.KAA05827@muppet30.cs.chalmers.se> Message-ID: <3AF1CEB8.A992F053@launchbury.org> This whole monomorphism-restriction debate was one that we had when we were writing the implicit parameters paper. We noted the dire impact of the monomorphism restriction, and commented upon it. On reviewing the whole issue again I am forced again to conclude: There Is No Satisfactory Solution. At least not in Haskell as it is at the moment. Again and again I have been forced to conclude, the only thing worse than having the monomorphism restriction is not having the monomorphism restriction. John's point about evaluation sharing is absolutely critical. We have to be able to distinguish between linear and exponential code, and not have the compiler switch from one to the other unpredictably. On the other hand, as Simon points out, having the MR changing program behavior silently is just as bad. And despite Lennart's comment, the situation is Much Worse with implicit parameters than with type classes. Aaarghh!! So what to do? As a quick fix we should just pick one of A, B or C. Maybe A is the right one, prohibiting the problematical situation from arising at all. For the long term, this issue provides strong supporting evidence for John H's suggestion of having two kinds of binding: the by-name binding has generalization (polymorphism, type classes, implicit parameters etc); and by need, without generalization (monomorphic). As a meta comment: it would be good to hear from people who have made extensive use of implicit parameters, to find out how they are really used in practice. This can often provide quite surprising input. For example, in the original paper we argued that implicit bindings should not be recursive, because we expected a certain style of use would be quite common. Now is seems that other usage styles are more common, for which recursive bindings may be better. Oh well. John From rjmh@cs.chalmers.se Fri May 4 08:27:51 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Fri, 4 May 2001 09:27:51 +0200 (MET DST) Subject: Implict parameters and monomorphism Message-ID: <200105040727.JAA26061@muppet30.cs.chalmers.se> > Except, of course, for top level bindings which is where the > monomorphism restriction is usually most noticable. Right, but an explicit monomorphic type signature would ensure that it's computed once. Type signatures on toplevel bindings are a good idea anyway, and there is no ambiguity for implicit parameters which must yield a function-like binding. This is a matter of taste, and Haskell deliberately supports both a style with and without type signatures on top-level bindings. I'd be sorry to see that change. One good reason for NOT giving inferrable type signatures is that including them makes programs less modifiable: a small local change, such as adding a parameter to a type, may force a large number of consequential changes to type signatures. I've seen cases where programmers refrained from a significant improvement, because of the labour required to update type signatures (which had been included, ironically, to disable the monomorphism restriction!). I'm not saying it's bad to give type signatures, just that there are arguments for both styles, and the language ought not to make either one difficult to use. John From qrczak@knm.org.pl Fri May 4 11:40:34 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 10:40:34 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, > such as adding a parameter to a type, may force a large number of > consequential changes to type signatures. Type synonyms should make this easier. Maybe the language should be improved somewhere here: class context synonyms? unbound type variables on the rhs of type synonyms? specifying parts of a type leaving the rest inferred? These problems shouldn't arise for ensuring evaluation once, where the type is usually monomorphic! It's the other way around which can cause trouble (e.g. there are no class context synonyms). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Fri May 4 11:40:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 4 May 2001 03:40:53 -0700 Subject: Implict parameters and monomorphism Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Now that is a *really* amazing example. I had no idea that polymorphic recursion would do this. =20 I withdraw my claim that a type signature can't change the answer. But I'm worried. Simon | -----Original Message----- | From: Lennart Augustsson [mailto:augustss@augustsson.net]=20 | Sent: 03 May 2001 15:24 | To: C.Reinke@ukc.ac.uk; qrczak@knm.org.pl | Cc: haskell@haskell.org | Subject: Re: Implict parameters and monomorphism |=20 |=20 | OK, so since noone liked my original example here's another=20 | one. It involves no defaulting and no classes in the funny=20 | function definition. |=20 | -- Here's the type signature that makes a difference. | --fun :: a -> Char | fun x =3D const (fun x) (fun True) |=20 | fix f =3D let x =3D f x in x |=20 | class C a where | m :: a -> String |=20 | instance C Char where | m _ =3D "has signature" |=20 | instance C Bool where | m _ =3D "no signature" |=20 | main =3D putStrLn (m (fix fun)) |=20 |=20 | It is not at all surprising that you can write this. =20 | Originally type signatures only allowed you to put a=20 | signature that was=20 | more specific. | Polymorhic recursion on the other hand allows you to make the=20 | type more general by putting a type signature on a=20 | definition. Combining these you can make the signature be=20 | incomparable to the deduced type. Using the class system you=20 | can then dispatch on the type and get different behaviour. |=20 | -- Lennart |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From igloo@earth.li Fri May 4 15:20:02 2001 From: igloo@earth.li (Ian Lynagh) Date: Fri, 4 May 2001 15:20:02 +0100 Subject: Unicode and is* Message-ID: <20010504152002.A14500@stu163.keble.ox.ac.uk> Hi all Is there a reason why isUpper and isLower include all unicode characters of the appropriate class but isDigit is only 0..9? Are there any Haskell unicode libraries around? And is the implementation of unicode support for GHC being discussed/developed anywhere? BTW, The comments in the report (primUnicodeIsUpper -- 'A'..'Z') are also misleading. Thanks Ian From qrczak@knm.org.pl Fri May 4 16:50:37 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 15:50:37 GMT Subject: Unicode and is* References: <20010504152002.A14500@stu163.keble.ox.ac.uk> Message-ID: Fri, 4 May 2001 15:20:02 +0100, Ian Lynagh pisze: > Is there a reason why isUpper and isLower include all unicode > characters of the appropriate class but isDigit is only 0..9? There are also other weirdnesses, e.g. isSpace is specified to work only on ISO-8859-1 spacing characters, and caseless letters are considered uppercase. > Are there any Haskell unicode libraries around? http://www.sourceforge.net/projects/qforeign/ It provides module Char replacement with more full character properties, charset conversion framework, and inefficient IO wrapper with transparent conversion of Handle data. It also provides FFI support, but it's almost the same as in ghc-5.00 now, except that string conversion between C and Haskell takes character encoding into account. It's undocumented except some comments, sorry. QForeign works with ghc >= 4.08 and nhc98 >= 1.01, but depends on Unicode support in the compiler: some bits are disabled when the compiler doesn't support character literals above '\255' (i.e. nhc98 compiled with ghc < 5.00 and probably with itself), the whole Unicode story is disabled when Char has 8 bits (i.e. ghc < 5.00). > And is the implementation of unicode support for GHC being > discussed/developed anywhere? I'm afraid they are not discussed. I received no feedback on Unicode features in qforeign. They are experimental; nobody told me that they are good or wrong, or how to design them better. They are changing very slowly now. I think they will find their way to ghc when they are finished (with total reimplementation of IO, integrating the conversion with buffering, and also using the new FFI), but it would be great if they represented some consensus rather than my thoughts alone. For example I don't like the HsAndC variant of implmenetation of a conversion (ConvBase), but some tests suggest that it's really best to use a Haskell implementation of UTF-32 when called from Haskell and a C implementation when called to work on character arrays, so I don't know how to do it more clearly. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From elf@sandburst.com Fri May 4 19:12:13 2001 From: elf@sandburst.com (Mieszko Lis) Date: Fri, 4 May 2001 14:12:13 -0400 Subject: Implict parameters and monomorphism In-Reply-To: <200105040727.JAA26061@muppet30.cs.chalmers.se>; from rjmh@cs.chalmers.se on Fri, May 04, 2001 at 09:27:51AM +0200 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504141213.E12269@sandburst.com> On Fri, May 04, 2001 at 09:27:51AM +0200, John Hughes wrote: > One good reason for NOT giving inferrable type signatures is that > including them makes programs less modifiable: a small local change, such as > adding a parameter to a type, may force a large number of consequential > changes to type signatures. Absolutely -- suppose you add a `trace' somewhere in your program, which conjures up a Show constraint everywhere... -- Mieszko From john@foo.net Fri May 4 19:27:07 2001 From: john@foo.net (John Meacham) Date: Fri, 4 May 2001 11:27:07 -0700 Subject: Implict parameters and monomorphism In-Reply-To: ; from qrczak@knm.org.pl on Fri, May 04, 2001 at 10:40:34AM +0000 References: <200105040727.JAA26061@muppet30.cs.chalmers.se> Message-ID: <20010504112707.A474@mark.ugcs.caltech.edu> I have thought about this too. omission of type signatures seems to be an effective catalyst for code re-use yet this benefit is rarely emphasised. I was thinking about ways to make it easier and toyed around with allowing 'unkowns' in type declarations to allow you to specify only the important part of what you want in a type signature without having to over-specify the types. My idea was to allow '_' to be used in type signatures and represent any type. foo s = 4 foo :: _ foo :: _ -> Int foo :: String -> _ foo :: String -> Int would all be valid types (with different meanings) for 'foo'. This would be useful if say, you had to specify a function returned a plain Int to resolve ambiguity but you didn't want to specify the type of the input argument, perhaps because you are in the process of writing/debugging code and know the type will change. this has the nice generalization that all undeclared types are taken to be ':: _' note that this is not universal quantification because that would imply any type will work, where in actuality we just want to use the specific type infered via standard type inference for part of the declaration and specify exactly another part. The reason I didn't make the proposal was because I am not sure how useful such a thing would be in production code, even though there have been many times during the development/discovery process when such a feature would have signifigantly eased incremental development. John On Fri, May 04, 2001 at 10:40:34AM +0000, Marcin 'Qrczak' Kowalczyk wrote: > Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes pisze: > > > One good reason for NOT giving inferrable type signatures is that > > including them makes programs less modifiable: a small local change, > > such as adding a parameter to a type, may force a large number of > > consequential changes to type signatures. > > Type synonyms should make this easier. Maybe the language should > be improved somewhere here: class context synonyms? unbound type > variables on the rhs of type synonyms? specifying parts of a type > leaving the rest inferred? > > These problems shouldn't arise for ensuring evaluation once, where > the type is usually monomorphic! It's the other way around which can > cause trouble (e.g. there are no class context synonyms). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 4 19:50:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 18:50:30 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: Fri, 4 May 2001 11:27:07 -0700, John Meacham pisze: > My idea was to allow '_' to be used in type signatures and represent > any type. I like it. There were also proposals for '..'. It would be useful in cases analogous to this: import IArray import MArray f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do marr <- thaw arr do some stateful operations on marr freeze marr) where the type of thaw and freeze make the mutable array type ambiguous. A type signature to disambiguate it would have to mention element and index types, which are type variables bound outside, and the state token, which is eaten by runST. So you have to either use a ghc/Hugs extension of pattern or result type signatures, to bind all these types to names, and move the body to a separate function, so the state token is visible - or specify a polymorphic function type signature on freeze alone or use a specialized variant of freeze. It would be nice to write just (marr :: STArray _ _ _) without having to invent types for the state, index and element. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From nr@eecs.harvard.edu Fri May 4 20:02:25 2001 From: nr@eecs.harvard.edu (Norman Ramsey) Date: Fri, 4 May 2001 15:02:25 -0400 Subject: Help wanted with hugs error message Message-ID: <200105041902.PAA06505@labrador.eecs.harvard.edu> I am compiling the following inoffensive source file, dubbed finterp.lhs: '''Interpreter for factors''' > module FactorInterp where > import Ast (Sym) > import Value () > import Factor > result = "*" > exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Hugs reports: ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import But there is no explicit `exp' in any of my other modules: : nr@labrador 1337 ; grep -w exp *.lhs finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] Can anyone help me to find an expunge this error? Thanks, Norman From Robert.Ennals@cl.cam.ac.uk Fri May 4 20:06:23 2001 From: Robert.Ennals@cl.cam.ac.uk (Robert Ennals) Date: Fri, 04 May 2001 20:06:23 +0100 Subject: Help wanted with hugs error message In-Reply-To: Your message of Fri, 04 May 2001 15:02:25 -0400. <200105041902.PAA06505@labrador.eecs.harvard.edu> Message-ID: [snip] > Hugs reports: > > ERROR "finterp.lhs" (line 10): Definition of variable "exp" clashes with import > > > But there is no explicit `exp' in any of my other modules: > > : nr@labrador 1337 ; grep -w exp *.lhs > finterp.lhs:> exp (Sym s) = Vee [result `eq` Value.Sym s :@: 1.0] > > > Can anyone help me to find an expunge this error? [snip] "exp" is defined as exponentiation, as part of the "Floating" type class in the standard Prelude - which is imported by default. -Rob From qrczak@knm.org.pl Fri May 4 20:56:24 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 19:56:24 GMT Subject: Implict parameters and monomorphism References: <200105040727.JAA26061@muppet30.cs.chalmers.se> <20010504112707.A474@mark.ugcs.caltech.edu> Message-ID: 4 May 2001 18:50:30 GMT, Marcin 'Qrczak' Kowalczyk pisze: > f :: (IArray a e, Ix i) => a i e -> a i e > f arr = runST (do > marr <- thaw arr > do some stateful operations on marr > freeze marr) Actually using pattern type signatures alone is almost enough here: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) except that ghc has a small bug: pattern type signatures don't introduce type variables in the 'do' notation, as they do in lambda arguments. Rewriting it to use '>>=' and lambdas instead of 'do' helps: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST ( thaw arr >>= \(marr :: STArray s i e) -> do some stateful operations on marr >> freeze marr) But doesn't solve completely. There is a strange error message "Could not deduce `MArray (STArray s1) e (ST s)' from the context (IArray a e, Ix i)" with two suggested resolutions, both bogus. The problem is with 's': it's not bound by lambda but eaten by runST. I have to move the argument of runST to a separate function, to bind 's' in its result type signature, to be able to use it in the pattern type signature of marr. This situation can be improved. There was a discussion three months ago about making pattern and result type signatures one-way matching. Currently if a part of the type of an argument is not a type variable bound at the given place, I can't write a type variable in the appropriate pattern type signature, but must spell the inferred type. Except that its context is not written. For example changing 'e' in the type of f above into 'Int' makes the type signature on marr illegal: I must write 'STArray s i Int' too. This is especially tricky in the presence of fundeps, because whether a type is fully determined is not necessarily obvious if it's deduced from fundeps. Ghc requires the programmer to manually follow fundeps to infer the same amount that ghc knows, instead of specifying just the part of the type I am interested in. Another bad case is above. The problematic type is not bound by the given lambda, it's not a constant, and it's not bound by a pattern outside either. It's a free type variable of the argument of runST, eaten by runST. There is no way to write it except by moving the body of runST to a separate function with a result type signature. I would like to make pattern and result type signatures one-way matching, like in OCaml: a type variable just gives a name to the given part of the type, without constraining it any way - especially without "negative constraining", i.e. without yielding an error if it will be known more than that it's a possibly constrained type variable... SimonPJ sais he agreed and asked Hugs people what they think, and they didn't reply. This reminds me the 'with' story :-( This change, together with fixing pattern type signatures in 'do', would make the function at the top legal. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Fri May 4 21:10:30 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 4 May 2001 20:10:30 GMT Subject: Help wanted with hugs error message References: Message-ID: Fri, 04 May 2001 20:06:23 +0100, Robert Ennals pisze: > "exp" is defined as exponentiation, as part of the "Floating" > type class in the standard Prelude - which is imported by default. And to fix the problem you may do either of these: * import Prelude hiding (exp) * Use FactorInterp.exp everywhere except the definition. * Choose a different name. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jans@numeric-quest.com Fri May 4 17:10:03 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Fri, 4 May 2001 12:10:03 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer Message-ID: Hoping to get some early feedback I am posting this very preliminary version: http://www.numeric-quest.com/haskell/QuantumComputer.html Jan From Michael.Fliegner@hansenet.de Fri May 4 23:51:41 2001 From: Michael.Fliegner@hansenet.de (Michae Fliegner) Date: Sat, 5 May 2001 00:51:41 +0200 Subject: Question: Hugs as Browser Plug In Message-ID: <01C0D4FD.B0E165F0@GATEWAY> I have - or at least dreamt I had - read about using Hugs as a Netscape Plug In, but can't find that anymore. Any hints - positive or negative? thanks in advance Michael FLiegner From Erik Meijer" Message-ID: <000a01c0d521$a2f9f0a0$0100a8c0@mshome.net> In the good old days, you could use Hugs as a IE scripting engine, but that is not supported anymore. ----- Original Message ----- From: "Michae Fliegner" To: Sent: Friday, May 04, 2001 3:51 PM Subject: Question: Hugs as Browser Plug In > I have - or at least dreamt I had - read about using Hugs as a Netscape > Plug In, but can't find that anymore. Any hints - positive or negative? > > thanks in advance > Michael FLiegner > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From ashley@semantic.org Sat May 5 07:52:40 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Fri, 4 May 2001 23:52:40 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105050652.XAA19806@mail4.halcyon.com> At 2001-05-03 01:42, Simon Peyton-Jones wrote: >Quite right too! OK, I understand it a bit better now. This code does not compile: -- class X a instance X Bool instance (Num a) => X a -- Can someone explain why the two instances overlap, given that Bool is not an instance of Num? Would it be possible for Haskell to figure out this sort of thing and not complain about it, or would that lead to nasty problems? -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 09:48:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 5 May 2001 18:48:18 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <3AF0C4D1.AB12C703@mindspring.com> References: <3AEF660A.87AF9D6C@mindspring.com> <3AF0C4D1.AB12C703@mindspring.com> Message-ID: <20010505184818.A6194@hg.cs.mu.oz.au> On 02-May-2001, Matt Harden wrote: > Matt Harden wrote: > > > blah, blah, blah, bug in the Library Report, blah, blah... > > OK, so I failed to read the Library Report. It clearly states: > > > An implementation is entitled to assume the following laws about these operations: > > > > range (l,u) !! index (l,u) i == i -- when i is in range > > inRange (l,u) i == i `elem` range (l,u) > > So my "bug" is only in my mind. Sorry for bothering everyone. I don't think it's quite as straight-forward as that. Hugs and ghc may conform to the Library Report, but the behaviour is still undesirable, and IMHO should be fixed. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From Jon.Fairbairn@cl.cam.ac.uk Sat May 5 11:21:10 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Sat, 05 May 2001 11:21:10 +0100 Subject: Anomalous Class Fundep Inference In-Reply-To: Your message of "Fri, 04 May 2001 23:52:40 PDT." <200105050652.XAA19806@mail4.halcyon.com> Message-ID: <29591.989058070@cl.cam.ac.uk> Ashley Yakeley wrote > OK, I understand it a bit better now. This code does not compile: > -- > class X a > instance X Bool > instance (Num a) =3D> X a > -- > Can someone explain why the two instances overlap, given that Bool is n= ot = > an instance of Num? > = > Would it be possible for Haskell to figure out this sort of thing and n= ot = > complain about it, or would that lead to nasty problems? Think what would happen if someone had a module that did define Bool as an instance of Num and imported the class X. -- = J=F3n Fairbairn Jon.Fairbairn@cl.cam.ac.u= k 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) From msk@post.tepkom.ru Sat May 5 11:46:10 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Sat, 5 May 2001 14:46:10 +0400 (MSD) Subject: Anomalous Class Fundep Inference In-Reply-To: <29591.989058070@cl.cam.ac.uk> Message-ID: On Sat, 5 May 2001, Jon Fairbairn wrote: > Ashley Yakeley wrote > > OK, I understand it a bit better now. This code does not compile: > > -- > > class X a > > instance X Bool > > instance (Num a) => X a > > -- > > Can someone explain why the two instances overlap, given that Bool is not > > an instance of Num? > > > > Would it be possible for Haskell to figure out this sort of thing and not > > complain about it, or would that lead to nasty problems? > > Think what would happen if someone had a module that did define > Bool as an instance of Num and imported the class X. Program will be rejected at point of such import (or instance declaration)? More simple example: importing two different modules with the exactly same instance declarations for some type. Anton Moscal From ashley@semantic.org Sat May 5 12:03:06 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sat, 5 May 2001 04:03:06 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <200105051103.EAA02114@mail4.halcyon.com> At 2001-05-05 03:21, Jon Fairbairn wrote: >Ashley Yakeley wrote >> OK, I understand it a bit better now. This code does not compile: >> -- >> class X a >> instance X Bool >> instance (Num a) => X a >> -- >> Can someone explain why the two instances overlap, given that Bool is not >> an instance of Num? >> >> Would it be possible for Haskell to figure out this sort of thing and not >> complain about it, or would that lead to nasty problems? > >Think what would happen if someone had a module that did define >Bool as an instance of Num Should give an error. >and imported the class X. Curiously, whereas Hugs -98 rejects this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x instance (Num a) => X a a where x = 0 -- line A -- ...it accepts this: -- module M where class X a b | a -> b where x :: a class (X a b) => Y a b | a -> b where y :: a instance (X a b) => Y a b where y = x module P where import M instance (Num a) => X a a where x = 0 -- line A -- i.e., simply moving line A to a different module. In the latter case it claims these: x :: X a a => a y :: Y a a => a -- Ashley Yakeley, Seattle WA From fjh@cs.mu.oz.au Sat May 5 15:16:11 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sun, 6 May 2001 00:16:11 +1000 Subject: Implict parameters and monomorphism In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EB2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010506001611.B6194@hg.cs.mu.oz.au> On 04-May-2001, Simon Peyton-Jones wrote: > Lennart Augustsson [mailto:augustss@augustsson.net] wrote: > | It is not at all surprising that you can write this. > | Originally type signatures only allowed you to put a > | signature that was more specific. > | Polymorhic recursion on the other hand allows you to make the > | type more general by putting a type signature on a > | definition. Combining these you can make the signature be > | incomparable to the deduced type. Using the class system you > | can then dispatch on the type and get different behaviour. > > Now that is a *really* amazing example. I had no > idea that polymorphic recursion would do this. Blaming polymorphic recursion is not really fair, IMHO. In particular, Mercury allows polymorphic recursion, but does not suffer from this problem, because it's type inference is capable of inferring the correct most general types even for examples that use polymorphic recursion. In contrast, Haskell uses a type inference algorithm which sometimes infers what I would call wrong answers: types which are less general that can be obtained with an explicit type declaration. These types might not be what the programmer had intended, and this can affect a program's meaning and result. The advantage of Haskell's approach is of course that the type inference process is guaranteed to terminate. In contrast, Mercury's type inference process may fail to terminate for certain ill-typed programs. The Mercury compiler uses a user-configurable iteration limit, and rejects programs for which type inference exceeds this limit. In practice this is very very rare. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jans@numeric-quest.com Sat May 5 22:22:06 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Sat, 5 May 2001 17:22:06 -0400 (EDT) Subject: Haskell Simulator of Quantum Computer In-Reply-To: Message-ID: > Hoping to get some early feedback I am posting this > very preliminary version: > http://www.numeric-quest.com/haskell/QuantumComputer.html > > Jan The bug mentioned in the write-up has been fixed and QFT behaves well now. New versions of both files (module and html page) are ready at the same location. Sorry for talking to myself, but the thought of having posted something buggy (in hope of getting some help) really bothered me. Jan From bjpop@cs.mu.OZ.AU Sun May 6 07:58:02 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Sun, 6 May 2001 16:58:02 +1000 (EST) Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <20010506001611.B6194@hg.cs.mu.oz.au> from Fergus Henderson at "May 6, 2001 00:16:11 am" Message-ID: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> > Fergus Henderson wrote: > In contrast, Haskell uses a type inference algorithm > which sometimes infers what I would call wrong answers: > types which are less general that can be obtained with an explicit > type declaration. These types might not be what the programmer had > intended, and this can affect a program's meaning and result. As you have noted there are advantages and disadvantages of both schemes. I will say that the Haskell requirement of type annotations does sometimes catch accidental (and unintended) uses of polymorphic recursion, thus making compile-time errors out of possible run-time errors (I have seen this happen on dozens of occassions with first year students). Granted that this favourable side-effect was probably never a goal of the Haskell scheme, and it does not always work (in the case that a type scheme is provided which is (accidentally) an acceptable solution to the typing problem of a polymorphically recursive binding group). In the case of the Mercury algorithm, I think that it may be useful for some very verbose mode of the compiler to issue a warning that a function/procedure/predicate is used in a polymorphically recursive manner, if only for the occasional circumstance when it results from a typo in the program. > The advantage of Haskell's approach is of course that the type > inference process is guaranteed to terminate. In contrast, > Mercury's type inference process may fail to terminate for > certain ill-typed programs. The Mercury compiler uses > a user-configurable iteration limit, and rejects programs > for which type inference exceeds this limit. If you applied the Mercury algorithm to Haskell (ie used fixed point iteration to search for a type, rather than requiring a type annotation), would the new type inference algorithm accept/reject the same programs as the existing Haskell algorithm? (assuming an arbitrary user-defined iteration limit, and suitable type annotations for the existing Haskell algorithm). >In practice this is very very rare. I would guess that this is very rare because the (intentional) use of polymorphic recursion is rare (for the predominant case of monomorphic recursion the solution to the fixed point iteration would be almost immediate). Regards, Bernie. From fjh@cs.mu.oz.au Mon May 7 02:57:29 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Mon, 7 May 2001 11:57:29 +1000 Subject: polymorphic recursion (was: Re: Implict parameters and monomorphism) In-Reply-To: <200105060658.QAA20373@mulga.cs.mu.OZ.AU> References: <20010506001611.B6194@hg.cs.mu.oz.au> <200105060658.QAA20373@mulga.cs.mu.OZ.AU> Message-ID: <20010507115728.A18321@hg.cs.mu.oz.au> On 06-May-2001, Bernard James POPE wrote: > > If you applied the Mercury algorithm to Haskell (ie used fixed point iteration > to search for a type, rather than requiring a type annotation), would > the new type inference algorithm accept/reject the same programs as the > existing Haskell algorithm? (assuming an arbitrary user-defined iteration > limit, and suitable type annotations for the existing Haskell algorithm). Yes, I believe so. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Mon May 7 11:04:57 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:04:57 -0700 Subject: Anomalous Class Fundep Inference Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC8@red-msg-09.redmond.corp.microsoft.com> There's a design space about how vigorous one is about checking for "unsatisfiable" instances when doing overlap things. It's quite a complicated design space that I don't fully understand, which is why GHC at least implements a conservative rule. For example, does one complain about overlap when the instance declarations are defined, or when they are used? Does one assume that new instances can be added "later"? and there is more I think. =20 Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org]=20 | Sent: 05 May 2001 07:53 | To: Haskell List | Subject: RE: Anomalous Class Fundep Inference |=20 |=20 | At 2001-05-03 01:42, Simon Peyton-Jones wrote: |=20 | >Quite right too! |=20 | OK, I understand it a bit better now. This code does not compile: | -- | class X a | instance X Bool | instance (Num a) =3D> X a | -- | Can someone explain why the two instances overlap, given that=20 | Bool is not=20 | an instance of Num? |=20 | Would it be possible for Haskell to figure out this sort of=20 | thing and not=20 | complain about it, or would that lead to nasty problems? |=20 | --=20 | Ashley Yakeley, Seattle WA |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From simonpj@microsoft.com Mon May 7 11:15:16 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 03:15:16 -0700 Subject: User defined Ix instances potentially unsafe Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> [Here's a possible Haskell 98 Library Ix "typo"] | > > An implementation is entitled to assume the following laws about=20 | > > these operations: | > >=20 | > > range (l,u) !! index (l,u) i =3D=3D i -- when i is in = range | > > inRange (l,u) i =3D=3D i `elem` range (l,u) | >=20 | > So my "bug" is only in my mind. Sorry for bothering everyone. |=20 | I don't think it's quite as straight-forward as that. | Hugs and ghc may conform to the Library Report, but the=20 | behaviour is still undesirable, and IMHO should be fixed. I rather agree with this. But I'm not sure what the fix is. In thinking about this I've realised that there's an assumption in=20 the Ix interface that (*) map index (range (l,u)) =3D [0..rangeSize (l,u)-1] That is, index maps an index densely into the range 0..N where N is the size of the array. Without this assumption, an array implementation would need to store the Int bounds of the array as well as the ix bounds. I bet that no Haskell implementation does this. If this were not so, the implementation of rangeSize in Section 5.2=20 would be utterly wrong rangeSize b@(l,u) =3D index b h + 1 The constraint (*) also specifies that 'range' returns subscripts in increasing order of index. That seems reasonable, but perhaps less important. One could alternatively say=20 (*a) index (l,u) l =3D 0 (*b) index (l,u) u =3D rangeSize (l,u) - 1 In the spirit of making minimal changes/additions to H98, perhaps (*a) and (*b) would be better. Any thoughts? Simon PS: none of this answers Matt's original question which I can rephrase thus: if a user provides implementations of index, range etc that do not obey the specified invariants, can that crash the system? I would rather the answer were 'no'. But that means the implementation would have to check the output of 'index' against the size of the array allocated from the supplied bounds. Which means that in the common case that 'index' also makes such a check there'd be two checks. Unless the compiler was clever enough=20 to eliminate one of them, which isn't easy since one is at the 'ix' type and the other at 'Int'. From R.Crole@mcs.le.ac.uk Fri May 4 17:49:24 2001 From: R.Crole@mcs.le.ac.uk (Roy L. Crole) Date: Fri, 04 May 2001 17:49:24 +0100 Subject: MERLIN Call for Participation Message-ID: CALL FOR PARTICIPATION Workshop on MEchanized Reasoning about Languages with variable bINding (MERLIN 2001) Siena, Italy, June 18-19, 2001 in connection with IJCAR 2001 ********************************** * http://www.mcs.le.ac.uk/merlin * ********************************** **** Early registration: May 15, 2001 **** ********************************** Currently, there is considerable interest in the use of computers to encode (operational) semantic descriptions of programming languages. Such encodings are often done within the metalanguage of a theorem prover or related system. The encodings may require the use of variable binding constructs, inductive definitions, coinductive definitions, and associated schemes of (co)recursion. The aim of this workshop is to provide researchers with a forum to review state of the art results and techniques, and to present recent and new progress in the areas of: + The automation of the metatheory of programming languages, particularly work which involves variable binding. + Theoretical and practical problems of encoding variable binding, especially the representation of, and reasoning about, datatypes defined from binding signatures. IMPORTANT DATES Early registration: **** May 15, 2001 **** MERLIN workshop: June 18, 2001 IJCAR 2001: June 20-23, 2001 REGISTRATION For details of registration, please see the IJCAR 2001 website at http://www.dii.unisi.it/~ijcar/ INVITED TALK Andrew Pitts, University of Cambridge, has agreed to give an invited talk on "A First Order Theory of Names and Binding". ACCEPTED PAPERS Andreas Abel (Carnegie Mellon, USA). A Third-Order Encoding of the Lambda-Mu-Calculus. Gilles Dowek (INRIA, France), Therese Hardin (LIP6, UPMC, France) and Claude Kirchner (LORIA & INRIA, France). A Completeness Theorem for an Extension of First-Order Logic with Binders. Marino Miculan (Udine, Italy). Developing (Meta)Theory of Lambda-Calculus in the Theory of Contexts. Dale Miller (Pennsylvania State, USA). Encoding Generic Judgements. Christine Roeckl (LAMP-DI-EPFL, Switzerland). A First-Order Syntax for the Pi-Calculus in Isabelle/HOL using Permutations. Carsten Schurmann, Dachuan Yu and Zhaozhong Ni (Yale, USA). Case Study: Formal Development of Safe Intermediate Languages. Rene Vestergaard (CNRS-IML, France) and James Brotherston (Edinburgh, UK). The Mechanisation of Barendregt-Style Equational Proofs (the Residual Perspective). PROGRAMME COMMITTEE Simon Ambler (University of Leicester) Roy Crole (Chair; University of Leicester) Amy Felty (University of Ottawa) Andrew Gordon (Microsoft Research, Cambridge) Furio Honsell (University of Udine) Tom Melham (University of Glasgow) Frank Pfenning (Carnegie Mellon University) FURTHER DETAILS For further details about the Workshop, please contact one of + Roy L. Crole, email: R.Crole@mcs.le.ac.uk + Simon J. Ambler, email: S.Ambler@mcs.le.ac.uk + Alberto Momigliano (Local Organizer), email: A.Momigliano@mcs.le.ac.uk at postal address: Department of Mathematics and Computer Science, University of Leicester, University Road, LEICESTER, LE1 7RH, United Kingdom. From simonpj@microsoft.com Mon May 7 12:55:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 7 May 2001 04:55:22 -0700 Subject: FW: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> This is the message that Marcin referred to, proposing a change in the semantics of scoped type variables. I may just go ahead and implement it in GHC. (The implementation is easy: delete a couple of lines; and I guess the same is so for Hugs. The question is whether it's a desirable change.) Simon -----Original Message----- From: Simon Peyton-Jones=20 Sent: 08 February 2001 02:32 Cc: Simon Peyton-Jones; qrczak@knm.org.pl Subject: Scoped type variables Dear Huggy people | But for pattern and result type signatures changing the rules makes=20 | sense. | f (x::a) =3D ... | does not mean that x has type "forall a. a" anyway. It should actually | only give the type a name, no matter what it is. |=20 | Similarly, | f (x :: (a,b)) =3D ... | should unify the appropriate type variable with (,), and give names to | monomorphic arguments of (,) used in the call we are in. I must say that I agree with Marcin's point. When we write f x =3D e we mean that x is a name for whatever argument f is given. Marcin argues that the same should apply for=20 f (x :: (a,b)) =3D e Namely, that x is a name for the argument, a is a name for the type of the fst of x, and slly b. Arguments in favour: - It's more like term-variable pattern matching - In the present system, saying (x::a) doesn't mean x's type is really universally quantified -- it may have a type constraint. And there's really a continuum between saying=20 forall a. C a =3D> t[a] and t[Int] because the Int amounts to a rather strong constraint on a. Indeed, when we have functional dependencies, forall a. C Int a =3D> t[a] may indeed be the same as C Int Int =3D> t[Int] - It's simpler; less to explain to the programmer (quite a bit of the GHC documentation on this stuff is to explain what about the universal quantification) Arguments against - It's not what GHC and Hugs do now. It would be an easy change to make, but I'd prefer it if GHC and Hugs stayed in sync over this (modulo release schedules), so I'd be interested in your views. Simon Someone (Jeff?) wrote: | Could you clarify what you are proposing? Is it | something like "let me name that type `a' even tho I know=20 | it's really something more specific"? (i.e. similar to the=20 | current hugs extension, but without the "can't be more=20 | specific than inferred" restriction) Exactly so. For example f (x::a) =3D let y::a =3D x+1 in h x y would be legal even if=20 h :: Int -> Int -> Int The point is that 'a' simply names the type of x, even if that type isn't a type variable. From qrczak@knm.org.pl Mon May 7 16:22:08 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 7 May 2001 15:22:08 GMT Subject: User defined Ix instances potentially unsafe References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: Mon, 7 May 2001 03:15:16 -0700, Simon Peyton-Jones pisze: > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. It is important if elems should return elements in the same order as indices returns indices, and as listArray accepts. I'm afraid that making arrays robust wrt. bogus Ix instances at the cost of further overheads means a larger pressure to avoid Ix at all in other contexts. It's already avoided in Manuel's parallel arrays, and it was a trouble for me for making ghc's Array/UArray/IArray/MArray operations faster - for example there is an better implementation of compare which works only for index types with particular properties, including Int but not (Int,Int), and sticking to 0-based Ints would make this much simpler, as well as making packed strings implemented in terms of UArrays more efficient. There are other problems. The report says that repeated indices in array construction is an error. Ghc doesn't check that and lets later values win. To implement what the report says it would have to be less efficient: avoiding a separate array for marking which elements are initialized would need unsafePtrEq on each store and probably a loop after the construction which would replace missing elements with bottoms which are not unsafePtrEq, so initialization of another array can distinguish absent elements from elements taken from this array. I'm not sure whether I should still use Ix-based arrays in my unified collection experiments etc., which don't fit there well, or say STOP at some point, concentrate on 0-based Int-indexed dynamic vectors with the interface of sequences, optionally adding Array support as a Haskell 98 compatibility kludge. Having mutable arrays with immutable bounds is also a small problem. Generally Ix-based Arrays may become a larger trouble to support than they are really worth. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From fjh@cs.mu.oz.au Mon May 7 17:15:26 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 8 May 2001 02:15:26 +1000 Subject: User defined Ix instances potentially unsafe In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72EC9@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010508021526.A20463@hg.cs.mu.oz.au> On 07-May-2001, Simon Peyton-Jones wrote: > In thinking about this I've realised that there's an assumption in > the Ix interface that > > (*) map index (range (l,u)) = [0..rangeSize (l,u)-1] ... > The constraint (*) also specifies that 'range' returns subscripts > in increasing order of index. That seems reasonable, but perhaps > less important. One could alternatively say > > (*a) index (l,u) l = 0 > (*b) index (l,u) u = rangeSize (l,u) - 1 > > In the spirit of making minimal changes/additions to H98, perhaps (*a) > and (*b) would be better. Given that (*a)+(*b) already pin the end-points, I *think* you might as well go all the way and use (*); I don't *think* the extra flexibility of (*a)+(*b) would be useful. Given a type T which satisfies (*a)+(*b) one can defined a new range function which sorts the elements by index range' b@(l,u) = sortBy compareIndex range b where compareIndex x y = compare (index b x) (index b y) and then after renaming range as e.g. unsortedRange and range' as range, the type will now satisfy (*). So for Haskell 200X, (*) would certainly be preferable, IMHO. For Haskell 98, I'm not sure; perhaps it is best to be conservative. > PS: none of this answers Matt's original question which I can rephrase > thus: > if a user provides implementations of index, range etc that do not obey > the specified invariants, can that crash the system? I would rather the > answer were 'no'. I think the answer should be "no, unless the user specified the appropriate compiler option to disable array bounds checking". > But that means the implementation would have to check the output of > 'index' against the size of the array allocated from the supplied bounds. > Which means that in the common case that 'index' also makes such a > check there'd be two checks. If you really want to squeeze the last drops of performance out, then there's always that compiler option to disable array bounds checking... > Unless the compiler was clever enough > to eliminate one of them, which isn't easy since one is at the 'ix' > type and the other at 'Int'. One possible way to eliminate them would be to add an extra method called unchecked_index or __unchecked_index to the Ix class. By default this would do the same as index class Ix t where ... __unchecked_index = index but you could define the instances for the standard library types such as Int, Char, etc. so that they just skip the check and return an out-of-range Int; for array operations such as (!) where you're going to do a range check on the value returned from index, you can safely use __unchecked_index instead. The reason for using a name such as __unchecked_index rather than just unchecked_index would be for strict compatibility with Haskell 98: to avoid clashing with user-defined identifiers, you need to use a name that is reserved for use by the implementation, Unfortunately, unless I missed something, Haskell 98 does seem to reserved any identifiers at all for use by the implementation, other than the standard reserved words, so I think even using a name like `__unchecked_index' here would not be 100% strictly Haskell 98 compatible. I think it would be good enough in practice, though. For Haskell 200X, where strict backwards compatibility is not required, unchecked_index should be introduced as a documented new method for the Ix class. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Mon May 7 20:31:57 2001 From: reid@cs.utah.edu (Alastair Reid) Date: Mon, 7 May 2001 13:31:57 -0600 Subject: User defined Ix instances potentially unsafe In-Reply-To: <20010508021526.A20463@hg.cs.mu.oz.au> Message-ID: > If you really want to squeeze the last drops of performance out, then > there's always that compiler option to disable array bounds checking... If you mean: "disable array bounds checking" == assume that the (possibly user-supplied) Ix instance is correct but still perform the Ix-based range check. [This is the status quo.] "enable array bounds checking" == perform a possibly redundant range check because the Ix instance may be broken then this sounds like an excellent idea. Especially given that Pascal compilers (not exactly new technology) used to do a pretty good job of eliminating redundant bounds checks so I imagine that that redundant check could be eliminated from all the easy cases without too much work. > For Haskell 200X, where strict backwards compatibility is not required, > unchecked_index should be introduced as a documented new method for the > Ix class. Is this enough? Most of the array code I write uses the higher-level operations like fmap and ixmap. Do I need unchecked versions of them too? Can the higher-level operations amortise the cost of those extra bounds checks? I think fmap can but ixmap can't and I haven't considered the others. -- Alastair Reid From mpj@cse.ogi.edu Tue May 8 06:41:27 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Mon, 7 May 2001 22:41:27 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72ECF@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon! | This is the message that Marcin referred to, proposing a change in | the semantics of scoped type variables. I may just go ahead and | implement it in GHC. (The implementation is easy: delete a couple | of lines; and I guess the same is so for Hugs. The question is = whether | it's a desirable change.) I think that it is an undesirable change. For example, the type theoretic and practical implications of the current semantics are known quantities. I'm not aware of similar foundations to support the new semantics. Nor have I seen any believable motivation for the change. For example: | I must say that I agree with Marcin's point. When we write | f x =3D e | we mean that x is a name for whatever argument f is given. Marcin | argues that the same should apply for=20 | f (x :: (a,b)) =3D e | Namely, that x is a name for the argument, a is a name for the type of | the fst of x, and slly b. |=20 | Arguments in favour: | - It's more like term-variable pattern matching Term variables in a pattern are binding occurrences, but type variables are not. Making the latter look more like the former would appear to be a recipe for unnecessary confusion given that that they are actually different. (As an aside, pushing an argument like the above, you might also argue that when we write "f x =3D e" we mean that "f" is a name for whatever function "x" is passed to as an argument. I'm sure we can all agree here: that would definitely be "slly"!) There's good precedent for the current semantics, both in practice (e.g., Standard ML) and in theory (e.g., typed lambda-calculi). It would be a mistake to switch to an untested and unusual semantics, especially without compelling motivating examples. All the best, Mark From simonpj@microsoft.com Tue May 8 08:47:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 00:47:58 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Hi Mark,=20 Thanks for your reply. | | Arguments in favour: | | - It's more like term-variable pattern matching |=20 | Term variables in a pattern are binding occurrences, but type=20 | variables are not. Making the latter look more like the=20 | former would appear to be a recipe for unnecessary confusion=20 | given that that they are actually different. Why do you say "type variables are not"?. When I say f x =3D e I mean "inside e, use x as the name for whatever value is=20 passed as argument to f". Under what Marcin proposes=20 f (x::a) =3D e would mean "inside (type signatures in) e, use a as the name for whatever type is the type of the argument passed to f". When you say there's a good theoretical foundation (typed lambda calcului) I think you are imagining that when we say f (x::a) =3D e we are saying "There's a /\a as well as a \x::a in this definition". In which case it would certainly be wrong to allow f :: Int -> Int f (x::a) =3D e But I'm suggesting something different * Place the big lambdas wherever they would be now (i.e. not influenced by the position of (x::a) type signatures. * Explain the pattern type signatures as let-bindings for types. Thus we might translate f to system-F like this: f =3D \x::T -> let-type a =3D T in e I've use let-type here, but one could equally well say (/\a -> e) T. This (admittedly informal) translation works fine if T happens to be Int, for exampe; i.e. x's type is not universally quantified. =20 In short, the pattern type signature is used solely to bind names to types, and not for universal quantification. I want to have a slightly more elaborate let-type, thus: g :: (Int,Bool) -> Int g (x::(a,b)) =3D e translates to g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e But notice that the RHS of a pattern-matching let-type is statically guaranteed to have the right shape. So I don't allow let-type (a,b) =3D c in ... (where c is a type variable). So it's just syntactic sugar, like let-type itself, and I could equally well write g =3D \x::(Int,Bool) -> let-type a =3D Int; b =3D Bool in e OK, so there are two questions a) does that answer the question about the techincal foundation b) is it a good design from a software engineering point of view I hope the answer to (a) is yes, but I realise that opinions may differ about (b). I thought this might be of general enough interest to be worth continuing to cc the Haskell list. Simon From Gnzgncrls@netscape.net Mon May 7 21:53:52 2001 From: Gnzgncrls@netscape.net (Gian) Date: Tue, 08 May 2001 06:53:52 +1000 Subject: making plurals Message-ID: <3AF70B60.3000205@netscape.net> i was wandering if you would be able to show me how to implement a function which converts a list of words into the plurals say maybe to convert "shelf" into "shelves". I thought maybe with using some kind of recursion, tupples and the prelude function isSuffixOf. but im not sure how to implement it can you help. From Markus Lauer Tue May 8 11:07:48 2001 From: Markus Lauer (Markus Lauer) Date: Tue, 8 May 2001 12:07:48 +0200 (MEST) Subject: question on type classes Message-ID: Is it possible in Haskell to define a type class like Show, which has a generic implementation for Lists and a special one for [Char], but (in contrast to Show) where Char is not in this Class I'd like to have something like the following, but this example doesn't work: ------------------------------------------- module Test where class Foo a where foo :: a -> a .... .... instance FooList a => Foo [a] where foo lst = fooList lst .... .... class FooList a where fooList :: [a] -> [a] .... .... genericImpl :: Foo a => [a] -> [a] genericImpl = ... specialImpl :: String -> String specialImpl = .... instance FooList Char where fooList s = specialImpl s ..... instance Foo a => FooList a where fooList lst = genericImpl lst ..... --------------------------------------------- Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor expected) ghc (5.00) sais Test.hs:20: Illegal instance declaration for `FooList a' (the instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) is there a better way, than to copy the instance declaration of FooList for every a in that is in class Foo? Thanks for any hint, Markus -- Markus Lauer From ashley@semantic.org Tue May 8 11:38:25 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Tue, 8 May 2001 03:38:25 -0700 Subject: question on type classes Message-ID: <200105081038.DAA25076@mail4.halcyon.com> At 2001-05-08 03:07, Markus Lauer wrote: >Hugs sais ERROR Test.hs:20 - syntax error in instance head (constructor > expected) Invoke as 'hugs -98' to switch on extensions. Hugs will then complain of overlapping instances: instance FooList Char instance Foo a => FooList a Yes, I know Char is not an instance of Foo. See the "Anomalous Class Fundep Inference" thread. -- Ashley Yakeley, Seattle WA From bdhumb@students.cs.mu.OZ.AU Tue May 8 13:44:24 2001 From: bdhumb@students.cs.mu.OZ.AU (Bryn Humberstone) Date: Tue, 8 May 2001 22:44:24 +1000 Subject: making plurals In-Reply-To: <3AF70B60.3000205@netscape.net>; from Gian on Tue, May 08, 2001 at 06:53:52AM +1000 References: <3AF70B60.3000205@netscape.net> Message-ID: <20010508224424.A11969@holly.cs.mu.OZ.AU> Gian, > i was wandering if you would be able to show me how to > implement a function which converts a list of words into the plurals > say maybe to convert "shelf" into "shelves". I thought maybe with using > some kind of recursion, tupples and the prelude function isSuffixOf. but > im not sure how to implement it can you help. I can't help noticing your question sounds remarkably like the sort of assignment question that gets set in a first year university course. Most universities don't allow students to solicit help from mailing lists so you probably should look away now before I reveal the answer. I'm sure that your tutors, lab demonstrators and lecturers will be happy to help you since you sound as though you're quite close to the solution. Nevertheless, I've devised a solution that seems to meet most of your requirements. It is quite inefficient on most words, but it should be a good place to start looking (apart from, say, your lecture notes). import List overallProgram = map makePlural makePlural word = case word of "shelf" -> "shelves" _ -> fst (makePlural word, let foo = "heating" in isSuffixOf foo ('c':foo)) And to the people on the list, please try to resist giving any answers to this or similar problems for the next few weeks as it just makes life more difficult for the students who invariably get caught. I think that the map (map toUpper)/capitalise controversy was originally sparked as a result of a question pertaining to this project as well. Cheers, Bryn From qrczak@knm.org.pl Tue May 8 15:59:20 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 14:59:20 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 00:47:58 -0700, Simon Peyton-Jones pisze: > g = \x::(Int,Bool) -> let-type (a,b) = (Int,Bool) in e > > But notice that the RHS of a pattern-matching let-type is statically > guaranteed to have the right shape. So I don't allow > > let-type (a,b) = c in ... > > (where c is a type variable). Really? I disagree. Making pattern type sygnatures perform unification of the variable with the supplied signature is useful for resolving ambiguities, and backward-compatible (valid programs will remain valid), and doesn't allow "unwanted generality" to cause trouble (when an expression has a more general type than needed). Currently ghc does not accept: (\(x::a) -> x) :: Int->Int but accepts this: (let f = \(x::a) -> x in f) :: Int->Int Hugs accepts both! But it doesn't like (\(x::a) -> (x::Int)) I would make all three legal. Unfortunately it doesn't help for my example: f:: (IArray a e, Ix i) => a i e -> a i e f arr = runST (do (marr :: STArray s i e) <- thaw arr do some stateful operations on marr freeze marr) unless the type inference could deduce that the constraint MArray (STArray s') e (ST s) in the presence of instance MArray (STArray s) e (ST s) unifies s' with s. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From simonpj@microsoft.com Tue May 8 16:25:39 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Tue, 8 May 2001 08:25:39 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> | > g =3D \x::(Int,Bool) -> let-type (a,b) =3D (Int,Bool) in e | >=20 | > But notice that the RHS of a pattern-matching let-type is=20 | statically=20 | > guaranteed to have the right shape. So I don't allow | >=20 | > let-type (a,b) =3D c in ... | >=20 | > (where c is a type variable). |=20 | Really? I disagree. Making pattern type sygnatures perform=20 | unification of the variable with the supplied signature is=20 | useful for resolving ambiguities, and backward-compatible=20 | (valid programs will remain valid), and doesn't allow=20 | "unwanted generality" to cause trouble (when an expression=20 | has a more general type than needed). I was meaning in the translation into System F of the program. Under my proposal (=3D yours) if one writes f (x::(a,b)) =3D e then f is forced to have type f :: (T1, T2) -> ... for some T1, T2. In saying that let-type can't pattern-match against a type variable c, I'm just saying that f cannot have type f :: forall c. c -> .... I think I just didn't express myself well enough. Simon From jefu@cs20.eou.edu Tue May 8 17:33:10 2001 From: jefu@cs20.eou.edu (jefu) Date: Tue, 08 May 2001 09:33:10 -0700 Subject: cross product of lists Message-ID: <200105081633.f48GXAi20714@cs20.eou.edu> This is not a class assignment - indeed I'm a professor who has used haskell in classes (and is currently being fired for having done so - it seems teaching anything other than c++ is questionable). I'd like to have a program that will take a description of a regular language and produce a list of strings in that language in order of size. If the lists are infinite (a* and the like) things work fine, but when the lists are finite, things dont work. I have two programs that I've tried to use and both have been hacked a bit in my process of experimentation so they're not the nicely honed final product I'd like to have. The first is based on my original ideas but with some attempt to cajole the finite/infinite list problem - it still seems to me that this would be a good way to go if possible, but I'm stumped. It is at : http://cs.eou.edu/jefu/reglang.hs The second is built on the idea of remembering if a list is finite or infinite and handling it accordingly. This one manages to segfault hugs and ghci also just quits about half the time (linux, redhat 7). This one is at : http://cs.eou.edu/jefu/nreglang.hs Any suggestions ? jefu -- jeff putnam -- jefu@eou.edu -- http://cs.eou.edu/~jefu From qrczak@knm.org.pl Tue May 8 17:32:53 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 8 May 2001 16:32:53 GMT Subject: Scoped type variables References: <37DA476A2BC9F64C95379BF66BA26902D72EE3@red-msg-09.redmond.corp.microsoft.com> Message-ID: Tue, 8 May 2001 08:25:39 -0700, Simon Peyton-Jones pisze: > I was meaning in the translation into System F of the program. [...] Ah, OK, sorry. More strange behavior of Hugs (none of this is allowed by ghc): \(x :: a) (y :: b) -> x+y -- not allowed \(x :: a) -> \(y :: b) -> x+y -- allowed f :: Int->Int->Int; f x = \(y::a) -> x+y -- not allowed f :: Int->Int->Int; f = \x (y::a) -> x+y -- allowed I guess that the constraint that a type is not more specific than a pattern type signature tells is checked once at some point of time. It is rejected only when the type inference determined the more specific type before this check was performed, but it might be determined later which is not caught. I would remove the check altogether. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From ham@cs.utexas.edu Tue May 8 19:01:41 2001 From: ham@cs.utexas.edu (Hamilton Richards) Date: Tue, 8 May 2001 13:01:41 -0500 Subject: cross product of lists In-Reply-To: <200105081633.f48GXAi20714@cs20.eou.edu> Message-ID: At 11:33 AM -0500 5/8/01, jefu wrote: [...] >I'd like to have a program that will take a description of a regular >language and produce a list of strings in that language in order >of size. [...] > > >Any suggestions ? Have a look at http://www.cs.utexas.edu/users/pete/research/enumeration.html. --Ham ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu ------------------------------------------------------------------ From rjchaaft@cs.uu.nl Wed May 9 13:05:56 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 09 May 2001 14:05:56 +0200 Subject: Class RealFrac: round Message-ID: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Hello, While I were writing a RealFrac implementation for BigDouble's (for high-precision computations) I found a strange implementation of round in the standard prelude (from the haskell definition): round x = let (n,r) = properFraction x m = if r < 0 then n - 1 else n + 1 in case signum (abs r - 0.5) of -1 -> n 0 -> if even n then n else m 1 -> m The strange case is if signum (abs r - 0.5) is 0: such numbers are round to the nearest EVEN integer. In mathematics, computer science (the studies I'm doing) and physics, as far as I know, it is usual to round such numbers up, rather than to the nearest integer. For example: Number Hugs Math 0.5 0 1 1.5 2 2 -3.5 -4 -4 6.5 6 7 Why did the Haskell designers choose this behaviour? Thanks in advance, Rijk-Jan van Haaften From lennart@mail.augustsson.net Wed May 9 13:14:11 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Wed, 09 May 2001 08:14:11 -0400 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> Message-ID: <3AF93493.A46D22D3@mail.augustsson.net> Rijk-Jan van Haaften wrote: > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): > > round x = > let (n,r) = > properFraction x > m = if r < 0 then n - 1 else n + 1 > in case signum (abs r - 0.5) of > -1 -> n > 0 -> if even n then n else m > 1 -> m > > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: Rounding to the nearest even number is considered the best practice by people doing numerical analysis. Even when I went to school (25 - 30 years ago) we were taught to round to the nearest even number, so it's not exactly new. -- Lennart From karczma@info.unicaen.fr Wed May 9 16:07:21 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 09 May 2001 17:07:21 +0200 Subject: Class RealFrac: round References: <4.3.0.20010509140231.00b2f410@pop.students.cs.uu.nl> <3AF93493.A46D22D3@mail.augustsson.net> Message-ID: <3AF95D29.6068FA5@info.unicaen.fr> Lennart Augustsson comment to : > Rijk-Jan van Haaften wrote: ... > > The strange case is if signum (abs r - 0.5) is 0: > > such numbers are round to the nearest EVEN integer. In mathematics, > > computer science (the studies I'm doing) and physics, as far as I > > know, it is usual to round such numbers up, rather than to the nearest > > integer. For example: > ... > Rounding to the nearest even number is considered the best practice by > people doing numerical analysis. Even when I went to school (25 - 30 > years ago) we were taught to round to the nearest even number, so it's > not exactly new. > > -- Lennart I wonder whether it has anything to do with the "best practice". I suppose that this is the natural way to get rid of one more bit of mantissa. Anyway, there is the standard IEEE 754 (with its 4 rounding modes...) and it is good to have a published standard, even if it results in some hangover of some people. The reported behaviour is also visible in Clean, and I spent 2 days on debugging because of that "round-ties-to-even rule"... It is not very "natural" psychologically, and from time to time I do some mistakes, although I know the stuff. Look here: (among 100 other references I could give you) http://www.validgh.com/goldberg/addendum.html http://developer.intel.com/technology/itj/q41999/articles/art_6.htm http://www.cs.umass.edu/~weems/CmpSci535/535lecture6.html Jerzy Karczmarczuk Caen, France From Joe.Bowers@CanopySystems.com Wed May 9 14:09:46 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Wed, 9 May 2001 09:09:46 -0400 Subject: Class RealFrac: round Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/plain I'm not one of the implementors, but this sort of behavior can reduce error in fields where X.5 is a common result- a rule like "The nearest even integer" moves upward half the time and downward half the time- hopefully cancelling itself out. Or maybe they had other reasons... Joe > -----Original Message----- > From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl] > Sent: Wednesday, May 09, 2001 8:06 AM > To: haskell@haskell.org > Subject: Class RealFrac: round > > > Hello, > > While I were writing a RealFrac implementation for BigDouble's (for > high-precision computations) I found a strange implementation of > round in the standard prelude (from the haskell definition): ... > The strange case is if signum (abs r - 0.5) is 0: > such numbers are round to the nearest EVEN integer. In mathematics, > computer science (the studies I'm doing) and physics, as far as I > know, it is usual to round such numbers up, rather than to the nearest > integer. For example: > > Number Hugs Math > 0.5 0 1 > 1.5 2 2 > -3.5 -4 -4 > 6.5 6 7 > > Why did the Haskell designers choose this behaviour? > > Thanks in advance, > > Rijk-Jan van Haaften > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ------_=_NextPart_001_01C0D889.5242C2C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Class RealFrac: round I'm not one of the implementors, but this sort of = behavior can reduce error in fields where X.5 is a common = result- a rule like "The nearest even integer" = moves upward half the time and downward half the time- hopefully = cancelling itself out. Or maybe they had other reasons... Joe > -----Original Message----- > From: Rijk-Jan van Haaften [mailto:rjchaaft@cs.uu.nl] > Sent: Wednesday, May 09, 2001 8:06 AM > To: haskell@haskell.org > Subject: Class RealFrac: round > > > Hello, > > While I were writing a RealFrac implementation = for BigDouble's (for > high-precision computations) I found a strange = implementation of > round in the standard prelude (from the haskell = definition): ... > The strange case is if signum (abs r - 0.5) is = 0: > such numbers are round to the nearest EVEN = integer. In mathematics, > computer science (the studies I'm doing) and = physics, as far as I > know, it is usual to round such numbers up, = rather than to the nearest > integer. For example: > > Number Hugs = Math > 0.5 = 0 1 > 1.5 = 2 2 > -3.5 = -4 -4 > 6.5 = 6 7 > > Why did the Haskell designers choose this = behaviour? > > Thanks in advance, > > Rijk-Jan van Haaften > > > = _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > ------_=_NextPart_001_01C0D889.5242C2C0-- From jbw@izanami.cee.hw.ac.uk Wed May 9 13:28:30 2001 From: jbw@izanami.cee.hw.ac.uk (Joe Wells) Date: 09 May 2001 13:28:30 +0100 Subject: RA position @ Heriot-Watt Univ. in program analysis Message-ID: --=-=-= Content-Disposition: inline Research Assistant Position Useful Logics, Types, Rewriting, and Applications (ULTRA) Group Computing and Electrical Engineering Department Heriot-Watt University Edinburgh, Scotland, UK A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland. The RA should either already have skills in some of the following areas and be interested and able to learn about several others: * type systems, especially those with intersection and union types, * static analysis of computer programs, * constraint solving, * higher-order programming languages, * programming language semantics, design, and/or implementation. The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done. The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science. To formally apply for this position, please do the following: * Arrange for 3 letters of reference to be sent. * Send the following yourself: + your complete curriculum vitae, + a brief statement of your research accomplishments and interests and why you think you would be a good match for the job, + web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and + contact details for the people writing your letters of reference. If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected. Applications or inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw@cee.hw.ac.uk fax: +44 131 449 3834 post: Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN --=-=-= Content-Type: text/html Content-Disposition: inline Research Assistant Position Research Assistant Position Useful Logics, Types, Rewriting, and Applications (ULTRA) Group Computing and Electrical Engineering Department Heriot-Watt University Edinburgh, Scotland, UK A research assistant (RA) position is available on an EPSRC-funded project directed by Joe Wells. The position is in the ULTRA (Useful Logics, Types, Rewriting, and Applications) group in the Department of Computing and Electrical Engineering at Heriot-Watt University in Edinburgh, the capital of Scotland. The RA should either already have skills in some of the following areas and be interested and able to learn about several others: type systems, especially those with intersection and union types, static analysis of computer programs, constraint solving, higher-order programming languages, programming language semantics, design, and/or implementation. The RA will be expected to help build, document, test, maintain, distribute, and support significant software components for performing modular program analysis. The RA will also be expected to aid in writing scientific reports on the work done. The position is initially for 1 year, with possible extensions depending on performance and funding. The salary will be commensurate with qualifications and experience. It is preferred that the RA already has or is just about to complete a Ph.D. in a relevant discipline within Computer Science. To formally apply for this position, please do the following: Arrange for 3 letters of reference to be sent. Send the following yourself: your complete curriculum vitae, a brief statement of your research accomplishments and interests and why you think you would be a good match for the job, web pointers to or paper copies of at most 3 publications of yours which you think are relevant, and contact details for the people writing your letters of reference. If you send documents electronically, please use public, standard, and non-proprietary formats. Microsoft Word documents will be rejected. Applications or inquiries should be directed to Joe Wells at: web: http://www.cee.hw.ac.uk/~jbw/ e-mail: jbw@cee.hw.ac.uk fax: +44 131 449 3834 post: Computing and Electrical Engineering Department Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN --=-=-=-- From chak@cse.unsw.edu.au Thu May 10 10:26:59 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 10 May 2001 19:26:59 +1000 Subject: ANNOUNCE: Happy 1.10 released In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510192659H.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell An RPM package for x86 RedHat Linux[1] is now available at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm Happy LALRing, Manuel [1] The binary has been build on RH7.0 with glibc2.2. From ml_dk@excite.com Thu May 10 10:56:00 2001 From: ml_dk@excite.com (=?iso-8859-1?Q?Mads_Lindstr=F8m?=) Date: Thu, 10 May 2001 02:56:00 -0700 (PDT) Subject: The definition of lhsfun in the report Message-ID: <24443469.989488562297.JavaMail.imail@ringo.excite.com> I'am confused about the "funlhs" production, in "Report on the programming Language Haskell 98" of the 1st February 1999. In the report one of the "funlhs"-productions is (see page 127): funlhs -> var apat {apat} That is a followed by one to many . But you can have functions like this: fun :: Int fun = 17 That is without any patterns to match, so why is the rule not ? funlhs -> var {apat} That is a followed by zero to many . I will be very happy for an answer to my question. _______________________________________________________ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ From franka@cs.uu.nl Thu May 10 12:12:30 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Thu, 10 May 2001 13:12:30 +0200 Subject: The definition of lhsfun in the report In-Reply-To: <24443469.989488562297.JavaMail.imail@ringo.excite.com> Message-ID: > I'am confused about the "funlhs" production, in "Report on the programming > Language Haskell 98" of the 1st February 1999. > > In the report one of the "funlhs"-productions is (see page 127): > > funlhs -> var apat {apat} > > That is a followed by one to many . But you can have functions > like this: > > fun :: Int > fun = 17 This does not declare a function. If you look at the decl production, you will see that there is another possibility, namely pat^0, which provides this syntax. OTOH it is possible to declare a function using pat, e.g.: fun = \x -> x+1 In other words, funlhs is redundant. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791 From luc.taesch@csfb.com Thu May 10 14:07:43 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Thu, 10 May 2001 15:07:43 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. what is the best organisation ? -import module P everywhere - isolate this datatype in a module, which would be imported everywhere ?(very "include like") - merging the module around this datatype ? this last option is not a good option here as : - this would be too big - P is generated by Happy. this look very much like a OO/non OO debate, which I dont want to spawn again. I can suppose its a FAQ like question. any good pointer ? whats the best practice around ? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From alex@shop.com Thu May 10 15:24:51 2001 From: alex@shop.com (S. Alexander Jacobson) Date: Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time) Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: Combining two threads... Like macros and preprocessors, Happy generates code. I assume the justification for this is that hand-coding a parser in Haskell is presumed to be too difficult or that it is too hard to get the right level of abstraction (and therefore a macro-like facility is required). However, I've also used Hutton & Meijer style monadic parsers and found them extremely elegant, clean, and easy to use in both Haskell and Python (though in Python they were too slow for my xml application -- function call overhead is _very_ high in Python). I am not a parsing expert, but given the recent discussion on macros, I have to ask: why use happy rather than monadic parsing? Monadic parsing allows you to avoid a whole additional language/compilation step and work in Hugs (where you don't have a makefile). What does Happy buy you here? And generalizing from the above, since Monads/Arrows are types that describe a computation declaratively and Macros are functions that describe a computation procedurally, is it possible that, for any application of Macros, you can find a suitable Monad/Arrow? Or am I not understanding either well enough? -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm) From kort@science.uva.nl Thu May 10 15:36:25 2001 From: kort@science.uva.nl (Jan Kort) Date: Thu, 10 May 2001 16:36:25 +0200 Subject: sharing datatypes : best practice ? References: <9818339E731AD311AE5C00902715779C0371A6C8@szrh00313.tszrh.csfb.com> Message-ID: <3AFAA769.D699EE5F@wins.uva.nl> "Taesch, Luc" wrote: > > i ve developped a datatype in a module P, and another module will use it, and most probably a few others, and its quite central to the apps Im building. > > what is the best organisation ? > > -import module P everywhere > - isolate this datatype in a module, which would be imported everywhere ?(very "include like") > - merging the module around this datatype ? > > this last option is not a good option here as : > - this would be too big > - P is generated by Happy. Hi Luc, Isolating the datatype in a module is what I always do. Only "Main.hs" calls the happy parser and just about every module uses the datatype, so it makes sense to separate them. Jan From simonmar@microsoft.com Thu May 10 15:42:00 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 10 May 2001 15:42:00 +0100 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) Message-ID: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on=20 > macros, I > have to ask: why use happy rather than monadic parsing? =20 > Monadic parsing > allows you to avoid a whole additional language/compilation=20 > step and work > in Hugs (where you don't have a makefile). What does Happy=20 > buy you here? It buys you (a) speed, (b) confidence that your grammar is non-ambiguous, and (c) familiar BNF notation. On the down side, as you point out, you lose Haskell's abstraction facilities. I'd be willing to sacrifice (c) in order to write parsers in Haskell, but I don't think there's a combinator library that matches Happy in terms of speed (disclaimer: I haven't exhaustively tested them all, but given the tricks Happy does I'd be surprised). AFAIK none of the combinator libraries gives you (b). Cheers, Simon From cwitty@newtonlabs.com Thu May 10 18:48:52 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 10 May 2001 10:48:52 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "S. Alexander Jacobson"'s message of "Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)" References: Message-ID: "S. Alexander Jacobson" writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? I've used Happy instead of parser combinators because I wanted the additional global error-checking. I believe that the standard implementations of parser combinators will allow you to specify an ambiguous grammar, and return one of the multiple possible parses, without warning. Carl Witty From qrczak@knm.org.pl Thu May 10 20:13:05 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 10 May 2001 19:13:05 GMT Subject: Fundeps and class contexts Message-ID: Would allowing this make sense? class C a b | a -> b class C a b => S a I want to simulate a particular "class synonym" (with four superclasses instead of one C here) where the type 'b' is uninteresting for its users. Currently I have to write class C a b | a -> b class C a b => S a b | a -> b and use f :: S a b => T(a) instead of f :: S a => T(a) even though T(a) usually doesn't contain b. If it does, I would write f :: (S a, C a b) => T(a) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@foo.net Thu May 10 22:22:04 2001 From: john@foo.net (John Meacham) Date: Thu, 10 May 2001 14:22:04 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Thu, May 10, 2001 at 03:42:00PM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010510142203.A16027@mark.ugcs.caltech.edu> Just out of curiosity, has anyone done any work at benchmarking the various parsers? I use Parsec pretty exclusivly since it comes with ghc and is pretty straightforward and lightweight to use. I am wondering what I am giving up in terms of speed by going that route, rather than Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm... John On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote: > > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net -------------------------------------------------------------- From johnsson@crt.se Fri May 11 08:01:04 2001 From: johnsson@crt.se (Thomas Johnsson) Date: Fri, 11 May 2001 09:01:04 +0200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <20010510192659H.chak@cse.unsw.edu.au> Message-ID: <15099.36400.547112.275888@spitfire.crt.se> S. Alexander Jacobson writes: > I am not a parsing expert, but given the recent discussion on macros, I > have to ask: why use happy rather than monadic parsing? Monadic parsing > allows you to avoid a whole additional language/compilation step and work > in Hugs (where you don't have a makefile). What does Happy buy you here? Happy and others like it generate an LR parser, which is a well-established technology since the late 60's (Knuth): efficient, deterministic, and checks the grammar for you. Parser combinators are usually nondeterministic ie backtracking (pre-Knuth!:-) though Cleverly Disguised in Haskell Higher Order clothes.... LR parsers gives you greated freedom in expressing the grammar, with the LR parser generator leaning over your shoulder. Grammars possible with parsing combinators are more constrained: cannot use left recursion, order of rules matters, etc. On the other hand, one has the whole abstraction machinery of Haskell or whatever at hand for writing the grammar rules. The analogy that comes to mind is statically typed languages vs runtime typed ones. --Thomas PS would be cool to try to marry the two approaches.... From chak@cse.unsw.edu.au Fri May 11 08:09:44 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Fri, 11 May 2001 17:09:44 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010511170944K.chak@cse.unsw.edu.au> "Simon Marlow" wrote, > S. Alexander Jacobson writes: > > > I am not a parsing expert, but given the recent discussion on > > macros, I > > have to ask: why use happy rather than monadic parsing? > > Monadic parsing > > allows you to avoid a whole additional language/compilation > > step and work > > in Hugs (where you don't have a makefile). What does Happy > > buy you here? > > It buys you (a) speed, (b) confidence that your grammar is > non-ambiguous, and (c) familiar BNF notation. On the down side, as you > point out, you lose Haskell's abstraction facilities. > > I'd be willing to sacrifice (c) in order to write parsers in Haskell, > but I don't think there's a combinator library that matches Happy in > terms of speed (disclaimer: I haven't exhaustively tested them all, but > given the tricks Happy does I'd be surprised). AFAIK none of the > combinator libraries gives you (b). I don't think, the point is the test for non-ambiguity. At least, Doitse's and my self-optimising parser combinator library will detect that a grammar is ambigious when you parse a sentence involving the ambiguous productions. So, you can check that by parsing a file involving all grammar constructs of the language. The point is much more the level of help that you get if your grammar happens to be ambiguous. My combinators at the moment just tell you that the grammar is ambiguous, but provide no help as to where and why. I think, this is similar for Doitse's combinators. Happy helps you much more in this situation. Cheers, Manuel From luc.taesch@csfb.com Fri May 11 08:53:00 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:53:00 +0200 Subject: haskell wiki wiped ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CD@szrh00313.tszrh.csfb.com> i tried to acces the hasakell wiki ? it s just all blank. has it been purged ? i remember having seen some idioms ... This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From luc.taesch@csfb.com Fri May 11 08:56:37 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Fri, 11 May 2001 09:56:37 +0200 Subject: sharing datatypes : best practice ? Message-ID: <9818339E731AD311AE5C00902715779C0371A6CF@szrh00313.tszrh.csfb.com> do u isolate just the datatype, or a few related with, in a very small file (header like, i would say) or some basic accessor function with it ? isnt it leading to massiv quantities of small files ? > -----Original Message----- > From: Jan Kort [mailto:kort@science.uva.nl] > Sent: Donnerstag, 10. Mai 2001 16:36 > To: Taesch, Luc > Cc: 'haskell@haskell.org' > Subject: Re: sharing datatypes : best practice ? > > > "Taesch, Luc" wrote: > > > > i ve developped a datatype in a module P, and another > module will use it, and most probably a few others, and its > quite central to the apps Im building. > > > > what is the best organisation ? > > > > -import module P everywhere > > - isolate this datatype in a module, which would be > imported everywhere ?(very "include like") > > - merging the module around this datatype ? > > > > this last option is not a good option here as : > > - this would be too big > > - P is generated by Happy. > > Hi Luc, > Isolating the datatype in a module is what I always do. > Only "Main.hs" calls the happy parser and just about > every module uses the datatype, so it makes sense to > separate them. > > Jan > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From dongen@cs.ucc.ie Fri May 11 10:52:55 2001 From: dongen@cs.ucc.ie (Marc van Dongen) Date: Fri, 11 May 2001 10:52:55 +0100 Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)] In-Reply-To: <20010511170944K.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Fri, May 11, 2001 at 05:09:44PM +1000 References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010511105255.S12168@cs.ucc.ie> Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote: [received message twice] Am I just the only one or does everybody receive messages posted to haskell@haskell.org and glasgow-haskell-users@haskell.org twice? I find it a bit (I know I am exaggerating) annoying. Is there a way to avoid this? Regards, Marc From cwitty@newtonlabs.com Fri May 11 18:13:49 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 11 May 2001 10:13:49 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Fri, 11 May 2001 17:09:44 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I don't think, the point is the test for non-ambiguity. At > least, Doitse's and my self-optimising parser combinator > library will detect that a grammar is ambigious when you > parse a sentence involving the ambiguous productions. So, > you can check that by parsing a file involving all grammar > constructs of the language. Sorry, doesn't work. Where do you get this "file involving all grammar constructs of the language"? If such an approach worked, you could use it to determine whether an arbitrary context-free grammar was ambiguous; but this problem is undecidable. Carl Witty From brian@boutel.co.nz Sat May 12 05:57:34 2001 From: brian@boutel.co.nz (Brian Boutel) Date: Sat, 12 May 2001 16:57:34 +1200 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <3AFCC2BE.B75CB113@boutel.co.nz> "Carl R. Witty" wrote: > > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. > This illustrates the difference between generality and usefulness. Often, one is less interested in learning that a grammar is ambiguous than learning that it is not. If you have a parser generator for a class of grammars, it will tell you if (and probably why) a candidate grammar you feed to it is not a member of that class. If it is accepted by, for example, a parser generator for LR(1) grammars, then it is a DCFG and therefore unambiguous. If you start with a "natural" grammar for the language, i.e. one that corresponds to the abstract syntax, and use a generator for a broad class of grammars (e.g LR(1)) then failure will give a good hint that the only way to get an unambiguous grammar in that class is to restrict the language, and you can use that information to make design decisions. For example, although Haskell has both 'let' and 'where' for introducing local definitions, thereby reflecting the typical committee decision when there are varying stylistic preferences, 'where' is not part of the expression syntax. If you write a grammar which includes the "natural" productions exp -> let defs in exp exp -> exp where defs and put this through a suitable generator, you will see why not. Of course, it is possible that an unambiguous grammar will fail to be LR(1) - by being non-deterministic, so the proper conclusion is that "G is ambiguous or non-deterministic". But that is close enough for most purposes. Early versions of Hope had both 'let' and 'where' as expressions, and had three different forms of condtional. Most combinations of these constructs would interract to create ambiguity. The hand-coded parsers in use had not picked this up. That shows the advantage of using a generator - you get a constructive proof that the grammar is in the desired class. --brian From chak@cse.unsw.edu.au Sun May 13 07:51:38 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 16:51:38 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> Message-ID: <20010513165138B.chak@cse.unsw.edu.au> cwitty@newtonlabs.com (Carl R. Witty) wrote, > "Manuel M. T. Chakravarty" writes: > > > I don't think, the point is the test for non-ambiguity. At > > least, Doitse's and my self-optimising parser combinator > > library will detect that a grammar is ambigious when you > > parse a sentence involving the ambiguous productions. So, > > you can check that by parsing a file involving all grammar > > constructs of the language. > > Sorry, doesn't work. Where do you get this "file involving all > grammar constructs of the language"? > > If such an approach worked, you could use it to determine whether an > arbitrary context-free grammar was ambiguous; but this problem is > undecidable. I didn't say that this works for any kind of parser combinator, I merely said that it works Doitse's and mine. Both implement SLL(1) parsers for which - as I am sure, you know - there exists a decision procedure for testing ambiguity. More precisely, whenever the library can build the parse table, the grammar must be non-ambigious. As the parse table construction is lazy, this covers only the productions exercised in that particular run, which is why I said that you need a "file involving all grammar constructs of the language." Nothing magic here. Cheers, Manuel PS: AFAIK Doitse recently made his combinators a bit more general, and I am not entirely sure how that affects the ambiguity check. From chak@cse.unsw.edu.au Sun May 13 08:40:26 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sun, 13 May 2001 17:40:26 +1000 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: <15099.36400.547112.275888@spitfire.crt.se> References: <20010510192659H.chak@cse.unsw.edu.au> <15099.36400.547112.275888@spitfire.crt.se> Message-ID: <20010513174026V.chak@cse.unsw.edu.au> Thomas Johnsson wrote, > Happy and others like it generate an LR parser, which is a well-established > technology since the late 60's (Knuth): efficient, > deterministic, and checks the grammar for you. > Parser combinators are usually nondeterministic ie > backtracking (pre-Knuth!:-) > though Cleverly Disguised in Haskell Higher Order clothes.... [..] > PS would be cool to try to marry the two approaches.... Doaitse Swierstra et al have done this to a certain extent: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/ Parser combinators that are efficient, deterministic, and handle errors much better than the classic form of parser combinators. Manuel From ltaesch@europemail.com Sun May 13 10:22:05 2001 From: ltaesch@europemail.com (luc) Date: Sun, 13 May 2001 11:22:05 +0200 Subject: io monad question Message-ID: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , mainly String -> [String], or similar = with types, plus some more complex datatypes. Up to now; i was testing them on a basic database I was creating in the = core main, "by hand". Then i added a basic parser with happy; and bingo; my test database is = now loaded from a file... as IO String..; huh! after a second though; this makes sense, except that i have to change = all the type of my functions; now IO String.. plus a few that just dont compile; and i cant understand why... my question: I had to change most of my type of the functions.as is propagated = through the code. (i.e. f need g; that need h; etc...) to add IO. is that kind of propagation normal, or can i Stop it somewhere ? how? is that because my functions just uses string as type ? and not data (ie = type relation =3Dstring; instead data Relation String) can i design a function that will do IO String-> String, or IO String -> = Data X, that will stop that IO propagation , through my code ? how can i handle function when my database is not IO, then ? i suppose im not the first to ask. any link ? thread ? faq example would = be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i designed some basic functions, , = mainly String=20 -> [String], or similar with types, plus some more complex=20 datatypes. Up to now; i was testing them on a = basic database I=20 was creating in the core main, "by hand". Then i added a basic parser with happy; = and bingo;=20 my test database is now loaded from a file... as IO String..; = huh! after a second though; this makes = sense, except=20 that i have to change all the type of my functions; now IO = String.. plus a few that just dont compile; and = i cant=20 understand why... my question: I had to change most of my type of the = functions.as=20 is propagated through the code. (i.e. f need g; that need h; etc...) to = add=20 IO. is that kind of propagation normal, or = can i Stop=20 it somewhere ? how? is that because my functions just uses = string as=20 type ? and not data (ie type relation =3Dstring; instead data Relation=20 String) can i design a function that will do IO = String->=20 String, or IO String -> Data X, that will stop that IO propagation , = through=20 my code ? how can i handle function when my = database is not=20 IO, then ? i suppose im not the first to ask. any = link ?=20 thread ? faq example would be welcomed... ------=_NextPart_000_001B_01C0DB9E.F09842C0-- From khaliff@astercity.net Sun May 13 10:07:54 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Sun, 13 May 2001 11:07:54 +0200 (CEST) Subject: io monad question In-Reply-To: <001e01c0db8e$2d9d5ae0$bdc1f8c1@JeanTaesch> Message-ID: On Sun, 13 May 2001, luc wrote: > i designed some basic functions, , mainly String -> [String], or similar with types, plus some more complex datatypes. > > Up to now; i was testing them on a basic database I was creating in the core main, "by hand". > Then i added a basic parser with happy; and bingo; my test database is now loaded from a file... as IO String..; huh! > > after a second though; this makes sense, except that i have to change all the type of my functions; now IO String.. > > plus a few that just dont compile; and i cant understand why... > > my question: > I had to change most of my type of the functions.as is propagated through the code. (i.e. f need g; that need h; etc...) to add IO. > is that kind of propagation normal, or can i Stop it somewhere ? how? You can stop it at the very beginning: f :: String -> String g :: [A] -> [B] -- etc, any functions without IO parse :: [String] -> [ A ] main = do h <- openFile "sampleFile" ReadMode contents <- hGetContents h -- and now you have file contents binded to contents and you can apply your --functions any way you want, i. e. let result = g (parse contents) putStrLn (show result) Wojciech Moczydlowski, Jr From Ben Mon May 14 03:43:31 2001 From: Ben (Ben) Date: Sun, 13 May 2001 21:43:31 -0500 Subject: typing question Message-ID: <20010513214331.A16503@one.net> Hello, I hope that a question here wont be too much of a bother. Yesterday I wrote a library for polynomial manipulation. Everything is fine except for the composition operator. Which I having problems with, probably trivial, but as I don't program in Haskell everyday a solution isn't clear. I have my polynomials defined as: newtype Polynomial a = Polynomial [a] deriving (Eq) with toPolynomial :: (Num a) => [a] -> Polynomial a toPolynomial x = Polynomial x fromPolynomial :: Polynomial a -> [a] fromPolynomial (Polynomial x) = x instance Show a => Show (Polynomial a) where instance Num a => Num (Polynomial a) where... and defined appropriately I also have a function, degree :: Polynomial a -> Int but to be more pointed my question is related to, (@@) :: (Num a) => Polynomial a -> a -> a f @@ g = applyrec (fromPolynomial f) g 0 where applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 This was originally written to evaluate f at value, ie n \mapsto f(n). But I realized that this should also work for overloading, as my Polynomials are Nums. In hugs the following works fine, t = Polynomial [1,2,3] @@ Polynomial [3,2,1] but I suspect that there is a type conversion happening for me which I should be aware of as something like the following doesn't work, [ f @@ g | f <- poly, g <- poly, f /= g ] where poly is a list of polynomials gives me, *** Expression : f @@ g *** Term : f *** Type : Polynomial Integer *** Does not match : Polynomial (Polynomial Integer) so my question boils down to, how do I tell hugs/Haskell that Polynomials over Polynomials of Integers are just Polynomials of Integers or at least that this kind of composition is ok? I am not on this mailing list so please CC me any responses. Thank you. Ben. From Ben Mon May 14 04:02:47 2001 From: Ben (Ben) Date: Sun, 13 May 2001 22:02:47 -0500 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net>; from neb@one.net on Sun, May 13, 2001 at 09:43:31PM -0500 References: <20010513214331.A16503@one.net> Message-ID: <20010513220247.A16641@one.net> The following appears to work, (@\@) :: (Num a) => Polynomial a -> Polynomial a -> Polynomial a f @\@ g = applyrec pp g 0 where pp = map (\x -> toPolynomial [x]) (fromPolynomial f) applyrec (f:fs) g m = f * g^m + applyrec fs g (m+1) applyrec [] _ _ = 0 Sorry for the original email, although I would be interested in a better solution if there is any commentary. Ben. On Sun, May 13, 2001 at 09:43:31PM -0500, Ben wrote: > Hello, I hope that a question here wont be too much of a bother. > > Yesterday I wrote a library for polynomial manipulation. Everything is fine > except for the composition operator. Which I having problems with, probably > trivial, but as I don't program in Haskell everyday a solution isn't clear. ...etc. From Tom.Pledger@peace.com Mon May 14 03:35:14 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Mon, 14 May 2001 14:35:14 +1200 Subject: typing question In-Reply-To: <20010513214331.A16503@one.net> References: <20010513214331.A16503@one.net> Message-ID: <15103.17506.714186.42965@waytogo.peace.co.nz> Ben writes: : | (@@) :: (Num a) => Polynomial a -> a -> a : | the following doesn't work, | [ f @@ g | f <- poly, g <- poly, f /= g ] | where poly is a list of polynomials gives me, | | *** Expression : f @@ g | *** Term : f | *** Type : Polynomial Integer | *** Does not match : Polynomial (Polynomial Integer) | | so my question boils down to, how do I tell hugs/Haskell that | Polynomials over Polynomials of Integers are just Polynomials of | Integers or at least that this kind of composition is ok? Your definition of (@@) looks OK. The only problem is that you've applied it to two arguments of the same type (f, g :: Polynomial Integer), which don't unify with the parameter types (Polynomial a and a). Hugs has compared the type of the second parameter (a) with the type of the second argument (Polynomial Integer), and applied the Most General Unifier (the substitution of Polynomial Integer for a). The details of the error message refer to what happened when it compared the types of the first argument and the first parameter. It's worth checking whether [ f @@ g | f <- poly, g <- poly, f /= g ] really means what you intended. From andyfugard@eircom.net Mon May 14 12:06:24 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 12:06:24 +0100 Subject: Permutations of a list Message-ID: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Hi all, I'm currently teaching myself a little Haskell. This morning I coded the following, the main function of which, permutate, returns all the permutations of a list. (Well it seems to at least!) insertAt :: a -> Int -> [a] -> [a] insertAt x i xs | i < 0 || i > length xs = error "invalid position" | otherwise = front ++ x:back where (front,back) = splitAt i xs insertAtAll :: a -> (Int,Int) -> [a] -> [[a]] insertAtAll x (i,j) xs | i > j = error "PRE: i <= j" | i == j = [insertAt x i xs] | otherwise = (insertAt x i xs):(insertAtAll x (i+1,j) xs) buildPermList :: a -> [[a]] -> [[a]] buildPermList x xs | length xs == 0 = [] | otherwise = list ++ buildPermList x (tail xs) where list = insertAtAll x (0, length curr) curr; curr = head xs permutate :: [a] -> [[a]] permutate xs | length xs == 0 = [[]] | otherwise = buildPermList (last xs) (permutate (init xs)) and some test runs.... Main> permutate "" [""] Main> permutate "a" ["a"] Main> permutate "ab" ["ba","ab"] Main> permutate "abc" ["cba","bca","bac","cab","acb","abc"] My main question is really what facilities of the language I should be looking at to make this code more elegant! As you can see I currently know only the basics of currying, and some list operations. Also regarding the method of generating the permutations; is there a better way? The current is just "Method 1" from Knuth's TAOCP, volume 1 (3rd edition), p45-46. Thanks in advance, Andy -- [ Andy Fugard /'andi fju:ga:d/ ] [ Phone: +44 (0)7901 603075 ] From ralf@informatik.uni-bonn.de Mon May 14 12:43:14 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Mon, 14 May 2001 13:43:14 +0200 Subject: Permutations of a list References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <3AFFC4D2.2114F872@informatik.uni-bonn.de> Andy Fugard wrote: > My main question is really what facilities of the language I should be > looking at to make this code more elegant! As you can see I currently know > only the basics of currying, and some list operations. Definitely list comprehensions! I digged out some old code: > module Perms where Permutations. > perms :: [a] -> [[a]] > perms [] = [ [] ] > perms (a : x) = [ z | y <- perms x, z <- insertions a y ] > > insertions :: a -> [a] -> [[a]] > insertions a [] = [ [a] ] > insertions a x@(b : y) = (a : x) : [ b : z | z <- insertions a y ] Using deletions instead of insertions; generates the permutations in lexicographic order, but is a bit slower. > perms' :: [a] -> [[a]] > perms' [] = [ [] ] > perms' x = [ a : z | (a, y) <- deletions x, z <- perms' y ] > deletions :: [a] -> [(a, [a])] > deletions [] = [] > deletions (a : x) = (a, x) : [ (b, a : y) | (b, y) <- deletions x ] Cheers, Ralf From andyfugard@eircom.net Mon May 14 13:02:14 2001 From: andyfugard@eircom.net (Andy Fugard) Date: Mon, 14 May 2001 13:02:14 +0100 Subject: Permutations of a list In-Reply-To: <3AFFC4D2.2114F872@informatik.uni-bonn.de> References: <5.1.0.14.0.20010514113326.00a7e300@mail1.eircom.net> Message-ID: <5.1.0.14.0.20010514125913.00a78670@mail1.eircom.net> At 13:43 14/05/01 +0200, Ralf Hinze wrote: >Andy Fugard wrote: > > > My main question is really what facilities of the language I should be > > looking at to make this code more elegant! As you can see I currently know > > only the basics of currying, and some list operations. > >Definitely list comprehensions! I digged out some old code: [ ... ] Thanks for the quick response; that's much nicer! I think I'll have a look at list comprehensions.... Cheers, Andy From mechvel@math.botik.ru Mon May 14 13:05:13 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 16:05:13 +0400 Subject: permutations. Reply Message-ID: Andy Fugard writes > Hi all, > > I'm currently teaching myself a little Haskell. This morning I coded the > following, the main function of which, permutate, returns all the > permutations of a list. (Well it seems to at least!) > > [..] The BAL library implements several operations with permutations. In particular, it can list permutations by applying nextPermutation. You may look into the source and demonstration example: http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ ----------------- Serge Mechveliani mechvel@botik.ru From mechvel@math.botik.ru Mon May 14 14:44:15 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Mon, 14 May 2001 17:44:15 +0400 Subject: CA proposal by D.Thurston Message-ID: I was said that there exists an algebraic library proposal for Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. Who could, please, tell me where to download this document from? For I could not find it from http://haskell.org Thanks in advance for the help. ----------------- Serge Mechveliani mechvel@botik.ru From herrmann@infosun.fmi.uni-passau.de Mon May 14 15:42:27 2001 From: herrmann@infosun.fmi.uni-passau.de (Ch. A. Herrmann) Date: Mon, 14 May 2001 16:42:27 +0200 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <15103.61139.512952.903922@reger.fmi.uni-passau.de> Hi Haskellers, >>>>> "S" == S D Mechveliani writes: S> I was said that there exists an algebraic library proposal for S> Haskell (version 0.02) dated by February (2001?), by Dylan S> Thurston. that sounds interesting for me. Sorry, that I don't have an answer to your question, but I like to state some points about an algebraic library. A standard algebraic library has several advantages to many different tools developed by individual programmers: (1) One can benefit from the knowledge and experience of others (and of their work also, of course) (2) An open discussion process will help to avoid errors or difficulties in use (3) Programs written by others that use the library functions are more comprehensible I've got no impression of how such a library may look like and if the library is meant to be updated from time to time. Anyway, an algebraic library is important: it is nice that Haskell has the rational numbers but recently, it appeared useful for me also to have the algebraic numbers, e.g., to evaluate expressions containing roots exactly. The problem is that I'm not an expert in this stuff and thus, be very glad if such things are added by an expert. On the other hand, I'd like to add things like a linear equation solver for a non-invertible system which may help to convince people that Haskell provides more features than other programming languages do. Cheers Christoph From fjh@cs.mu.oz.au Mon May 14 18:01:32 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 15 May 2001 03:01:32 +1000 Subject: CA proposal by D.Thurston In-Reply-To: References: Message-ID: <20010515030132.A4701@hg.cs.mu.oz.au> On 14-May-2001, S.D.Mechveliani wrote: > I was said that there exists an algebraic library proposal for > Haskell (version 0.02) dated by February (2001?), by Dylan Thurston. > > Who could, please, tell me where to download this document from? > For I could not find it from http://haskell.org It was posted to the haskell-cafe list, and is available from the archives of that list: . -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From cwitty@newtonlabs.com Mon May 14 20:31:43 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 14 May 2001 12:31:43 -0700 Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released) In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Sun, 13 May 2001 16:51:38 +1000" References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010513165138B.chak@cse.unsw.edu.au> Message-ID: "Manuel M. T. Chakravarty" writes: > I didn't say that this works for any kind of parser > combinator, I merely said that it works Doitse's and mine. > Both implement SLL(1) parsers for which - as I am sure, you > know - there exists a decision procedure for testing > ambiguity. More precisely, whenever the library can build > the parse table, the grammar must be non-ambigious. As the > parse table construction is lazy, this covers only the > productions exercised in that particular run, which is why I > said that you need a "file involving all grammar constructs > of the language." Nothing magic here. Wow. Clearly I haven't spent enough time looking at your parser systems. I apologize for my incorrect assumptions and statements. Carl Witty From mechvel@math.botik.ru Tue May 15 05:45:25 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 08:45:25 +0400 Subject: standard library. Reply Message-ID: Ch. A. Herrmann writes > [..] > Anyway, an algebraic library is important: > it is nice that Haskell has the rational numbers but recently, it > appeared useful for me also to have the algebraic numbers, e.g., > to evaluate expressions containing roots exactly. The problem is > that I'm not an expert in this stuff and thus, be very glad if > such things are added by an expert. > > On the other hand, I'd like to add things like a linear equation solver > for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. The BAL library http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/ provides such linear solver, as well as operations with roots. For example, the root of x^5 - x + 1 can be handled (in many respects) in BAL as only a residue of polynomials modulo this equation - a data like (Rse ...(x^5-x+1))). But BAL is not a standard library. And there is another point: > [..] for a non-invertible system which may help to convince people that > Haskell provides more features than other programming languages do. In any case, we have to distinguish between a standard library and an application. A standard library should be small. I think, for Haskell, it should be something that you mention now. But, for example, the true algebraic number theory algorithms are too complex, it is for the non-standard application writers. And if a language is good, there should come many special applications (non-standard ones). Haskell's www page does reveal some. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From mpj@cse.ogi.edu Tue May 15 08:16:10 2001 From: mpj@cse.ogi.edu (Mark P Jones) Date: Tue, 15 May 2001 00:16:10 -0700 Subject: Scoped type variables In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72EDB@red-msg-09.redmond.corp.microsoft.com> Message-ID: Hi Simon, | When you say there's a good theoretical foundation (typed lambda | calcului) I think you are imagining that when we say |=20 | f (x::a) =3D e |=20 | we are saying "There's a /\a as well as a \x::a in this definition". No, that's not what I'm thinking. When you say "f (x::a) =3D e", I'm reading it as meaning something like: "f =3D \(x::a).e". This is the typed lambda-calculus perspective that I was referring to. And, in such systems (whether simply typed or polymorphicly typed) the type annotation on the lambda bound variable x does not bind any type variables appearing in a. (And note that the type annotation may not contain any variables, or it could contain repeated uses of the same variable, etc...) Binding of type variables is a separate matter. It may be done by some kind of /\, either explicit or implicit. For the binding above, those variables would have to be bound somewhere, either added, implicitly to the binding of f, or else to some enclosing function. | But I'm suggesting something different |=20 | * Place the big lambdas wherever they would be now (i.e. not = influenced | by the position of (x::a) type signatures. |=20 | * Explain the pattern type signatures as let-bindings for types. Thus | we might translate f to system-F like this: |=20 | f =3D \x::T -> let-type a =3D T in e |=20 | I've use let-type here, but one could equally well say (/\a -> e) T. This is a different interpretation of type annotations than the one you'll find in many typed lambda-calculi. (That's a statement of fact rather than a judgment of merits.) In fact I'm not aware of any work on type systems like this. The simple translation that you give for let-type looks ok from the perspective of System-F, say. However, in the context of Haskell, I think it would be prudent to determine how it extends to and interacts with things like type inference, polymorphism, and overloading. Perhaps it would be worth considering a new language construct, such as: let-type expr :: type in expr with the intention that the first expr is not evaluated, but used to guide the binding of type variables in the "type" part, which would then be in scope in the second expression. This is a little more powerful than your let-type because it allows a kind of pattern matching on type expressions. But I don't know if this would be a well-behaved construct, or if it would be useful ... | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may = differ | about (b). I'm not persuaded about (a), I can't comment on (b), and I think there should be a third question: c) when is it useful? what holes does it fill? All the best, Mark PS. Aside ... if you'd like type variables in type annotations to be binding, then perhaps you'd also like them to work more like regular pattern bindings and to see functions like the following: f :: a -> b -> String f (x::a) (y::a) =3D "Yes, the arguments are the same type" f _ _ =3D "No, the arguments have different types" showList :: [a] -> String showList (xs::[Char]) =3D ... show a string enclosed in "'s ... showList xs =3D ... show list enclosed in [ ... ]s ... Who needs overloading anyway? :-) From mechvel@math.botik.ru Tue May 15 13:10:20 2001 From: mechvel@math.botik.ru (S.D.Mechveliani) Date: Tue, 15 May 2001 16:10:20 +0400 Subject: BAL paper available Message-ID: Paper announcement ------------------ The file http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip contains more expanded explanations on the BAL (Basic Algebra Library) project (previous variant was haskellInCA.ps.zip). My real intention in whole this line of business was always not just to propose a standard but rather to discuss and to find, what may be an appropriate way to program mathematics in Haskell. The matter was always in parametric domains ... Whoever tried to program real CA in Haskell, would agree that such a problem exists. ----------------- Serge Mechveliani mechvel@botik.ru From karczma@info.unicaen.fr Tue May 15 17:33:41 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Tue, 15 May 2001 18:33:41 +0200 Subject: BAL paper available References: Message-ID: <3B015A65.C87801F5@info.unicaen.fr> Serge Mechveliani : > > Paper announcement > ------------------ > > The file > http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/haskellInCA1.ps.zip > > contains more expanded explanations on the BAL (Basic Algebra Library) > project > (previous variant was haskellInCA.ps.zip). > > My real intention in whole this line of business was always not just > to propose a standard but rather to discuss and to find, what may be > an appropriate way to program mathematics in Haskell. > The matter was always in parametric domains ... > Whoever tried to program real CA in Haskell, would agree that such a > problem exists. Absolutely. The point is that this seems - for various, perfectly understandable reasons - not to be the priority of the implementors. Graphics/imagery neither. Nor hard numeric work (efficient, easy to manipulate arrays). And now I will say something horrible. Despite my extremely deep respect for all people contributing to Haskell, despite my love for the language etc. I begin to suspect that it has been standardized too early, and if we (Sergey, other people interested in math, as Dylan Thurston, myself, etc., as well as people who want to do *serious* graphics in a functional way) want an adapted functional language, either we will have to wait quite long, or perhaps it is the time to invent another language, with a more dynamic type system, with intrinsic graphic utilities, and other goodies. For the moment - this is my personal viewpoint - it might be better to write concrete applications, and papers describing those applications. Then we shall perhaps know better what kind of structures, algorithms, representations, genericities, etc. we REALLY need for practical purposes. Anyway, Sergey did a formidable work, and this should be acknowledged even by those who on this list criticized his presentation. Thanks. Jerzy Karczmarczuk Caen, France From dpt@math.harvard.edu Tue May 15 19:14:02 2001 From: dpt@math.harvard.edu (Dylan Thurston) Date: Tue, 15 May 2001 21:14:02 +0300 Subject: BAL paper available In-Reply-To: <3B015A65.C87801F5@info.unicaen.fr>; from karczma@info.unicaen.fr on Tue, May 15, 2001 at 06:33:41PM +0200 References: <3B015A65.C87801F5@info.unicaen.fr> Message-ID: <20010515211402.B24804@math.harvard.edu> On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > Serge Mechveliani : > > ... > > My real intention in whole this line of business was always not just > > to propose a standard but rather to discuss and to find, what may be > > an appropriate way to program mathematics in Haskell. > > The matter was always in parametric domains ... > > Whoever tried to program real CA in Haskell, would agree that such a > > problem exists. Can you be more precise what the problem is? One problem I see is that referred to in Section 3 of the paper: you really need types that depend on parameters (in particular, integer parameters). This is, indeed, a problem--currently, you have to do runtime checks. Full-fledged dependent types à la Cayenne are undecidable, but there are weaker variants that are likely to be good enough. > The point is that this seems - for various, perfectly understandable > reasons - not to be the priority of the implementors. > Graphics/imagery neither. > Nor hard numeric work (efficient, easy to manipulate arrays). If I understand correctly, Marcin Kowalczyk is working on exactly this last point... > Despite my extremely deep respect for all people contributing to > Haskell, despite my love for the language etc. I begin to suspect > that it has been standardized too early, and if we [...] want an > adapted functional language, either we will have to wait quite long, > or perhaps it is the time to invent another language, with a more > dynamic type system, with intrinsic graphic utilities, and other > goodies. For myself, I don't see a problem here. For "intrinsic graphic utilities", someone has to write the graphic libraries. (You don't mean they should be built into the language, do you?) The type system is about as strong as anyone knows how to make a static type system; and it's not too hard to fall back on run-time type checking when necessary (as Sergey does in BAL). > Anyway, Sergey did a formidable work, and this should be acknowledged even > by those who on this list criticized his presentation. Thanks. Yes, absolutely. I think perhaps some things could be done better (for instance, I see that all Sergey's classes derive from Eq, which is one of my principal complaints with the Haskell 98 classes), but I appreciate the work and want to study it more. Best, Dylan Thurston From qrczak@knm.org.pl Tue May 15 20:11:49 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 19:11:49 GMT Subject: BAL paper available References: Message-ID: Tue, 15 May 2001 16:10:20 +0400, S.D.Mechveliani pisze: > The matter was always in parametric domains ... The solution is simple: don't model domains as types. Model them as values (records with operations). Some simple domains can be also modelled as types for convenience. But it doesn't work in general. Similarly as standard sort :: (Ord a) => [a] -> [a] is not as expressive as soryBy :: (a -> a -> Ordering) -> [a] -> [a] even though it's more convenient in case it works. It doesn't work when various instances of the same kind of algebraic structure over the same carrier set are considered. And it doesn't work when a domain should be parametrized by something which is hard to express by a type. And it constrains programs which want to choose the domain dynamically. Carrier sets are modelled as types, OK. But it won't work for all algebraic structures. About program transformation possibility: I don't see how it would be applied in practice. There is no use of associativity of (+) for the compiler. It can do many optimizations, but it won't rewrite x+(y+z) to (x+y)+z nor vice versa. Sample arguments are ugly, almost always unnecessary, and constrain interfaces (functions like 'sum :: Num a => [a] -> a' would have to have a different intreface). They are a solution to a wrong problem: some domains should not have been modelled as types in the first place. Algebraic operations don't belong to elements of algebras; they belong to algebras. In simple cases they can be deduced from the types of elements if the given carrier has a reasonable default interpretation of these operations (e.g. (+) on Integers), but it's not general. I don't believe that dependent types would come into Haskell in the near future. And they are unnecessary for the discussed purpose: domains which would require them should not be modelled as types. Don't abuse types to model values. Haskell's types are too static for that. The class hierarchy is unacceptable for me as standard Haskell. It's way too complex. Currently I have to define instances of Eq, Show, Num and Fractional to have field operations. With BAL I would have to define instances of Eq, Show, Set, Additive, AddSemigroup, AddGroup, Multiplicative, MulSemigroup, Ring, CommutativeRing, GCDRing, EuclideanRing, FactorizationRing and Field. They require such things as specifying an arbitrarily chosen set of properties of the domain and partially defined versions of most operations... The hierarchy contains many unnecessary superclass relationships. For example Show, specifying bounds and conversion from 'Expression String' are not necessary for Ord, where your classes artificially require them. There are no class synonyms in Haskell, so classes like OrdAddGroup can't be treated as implicit. Later parts are too heavy for me to understand them well, but I see some ugly points, like abusing Char arguments to virtually extend the function name, or requirement to provide reflection capabilities at the very beginning by every type wanting to use overloading of basic operations, or requirement that the programmer knows more advanced math than should be necessary to use Haskell. I hope that a similar proposal won't go into standard Haskell. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Tue May 15 21:05:47 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 15 May 2001 20:05:47 GMT Subject: BAL paper available References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: >> Nor hard numeric work (efficient, easy to manipulate arrays). > > If I understand correctly, Marcin Kowalczyk is working on exactly > this last point... Well, I improved efficiency of ghc's arrays by removing various unnecessary overheads and I'm working on a generic interface of collections, but I don't have any deeper plans about arrays. What should be improved compared to existing STUArray Int Double and similar? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From conal@microsoft.com Tue May 15 21:44:03 2001 From: conal@microsoft.com (Conal Elliott) Date: Tue, 15 May 2001 13:44:03 -0700 Subject: BAL paper available Message-ID: Small comment. Marcin wrote: > About program transformation possibility: I don't see how it would > be applied in practice. There is no use of associativity of (+) for > the compiler. It can do many optimizations, but it won't rewrite > x+(y+z) to (x+y)+z nor vice versa. Associativity and commutativity (AC) are not optimizations in themselves, but rather enable optimizations if you have an AC matcher in your rewriting system (as, for instance, in Mathematica). - Conal From khaliff@astercity.net Tue May 15 21:31:40 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Tue, 15 May 2001 22:31:40 +0200 (CEST) Subject: BAL paper available In-Reply-To: Message-ID: On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > Tue, 15 May 2001 21:14:02 +0300, Dylan Thurston pisze: > > >> Nor hard numeric work (efficient, easy to manipulate arrays). > > > > If I understand correctly, Marcin Kowalczyk is working on exactly > > this last point... > > Well, I improved efficiency of ghc's arrays by removing various > unnecessary overheads and I'm working on a generic interface > of collections, but I don't have any deeper plans about arrays. > > What should be improved compared to existing STUArray Int Double > and similar? > > QRCZAK A simple standard proposal, not using ST and multiparameter type classes, so that it would be possible to implement it in other compilers (namely nhc), would be a great improvement for me. Wojciech Moczydlowski, Jr From matth@mindspring.com Wed May 16 00:43:28 2001 From: matth@mindspring.com (Matt Harden) Date: Tue, 15 May 2001 18:43:28 -0500 Subject: Ix class Message-ID: <3B01BF20.952F55FE@mindspring.com> Hello, I am working on an Ix instance for one of my types and finding it rather restrictive. For me it would be useful to have rangeSize be defined in the Ix class (with a default definition of course), so that it can be overridden. Also, does anybody know why Ix derives from Ord? It seems to me this is an unnecessary limitation on the types that can be instances of Ix. I cannot think of a reason why the implementation of anything in the Ix or Array modules would require that every Ix be an Ord (with a minor exception -- see below). If an implementation is using a comparison on an Ix type, chances are it should be using inRange or comparing (index bnds x) with (index bnds y) instead. One change would have to be made in the Array module if Ord is removed from Ix: instance (Ix a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' would become: instance (Ix a, Eq a, Eq b) => Eq (Array a b) where a == a' = assocs a == assocs a' instance (Ix a, Ord a, Ord b) => Ord (Array a b) where a <= a' = assocs a <= assocs a' As I said, I think this is a very minor issue. I believe that making these changes in the standard would not impact existing programs in any way. Could these changes be considered as a possible "typo" to be fixed in the Library Report? P.S. In case anybody's interested, here's why I want to override rangeSize: > newtype Honeycomb = Hx (Int,Int) deriving (Eq,Show,Ord) > > indexError = error "Index out of range" > > instance Ix Honeycomb where > range (Hx b1, Hx b2) = > [Hx x | x <- range (b1,b2), isHexIx x] > inRange (Hx b1, Hx b2) (Hx x) = > inRange (b1,b2) x && isHexIx x > index (Hx b1, Hx b2) (Hx x) = > let i = index (b1,b2) x in > if isHexIx x then i `div` 2 else indexError > > isHexIx :: (Int,Int) -> Bool > isHexIx (x,y) = x `mod` 2 == y `mod` 2 This implements a honeycomb or hexagonal tiling for a maze generating program. The honeycomb is superimposed on a grid such that only every other square is "active", corresponding to a particular hexagon in the honeycomb. It's similar to a checkers game, where only the dark squares are used. I would like _any_ pair of Ints to be an acceptable boundary for the honeycomb, not just the ones that represent valid indexes. For example, (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current definition of rangeSize makes this impossible, which is why I would like to override it. By the way, the Library Report does not explicitly say that the bounds have to both be valid indexes, though it does imply this with the sample definition of rangeSize. Thanks, Matt Harden From jans@numeric-quest.com Tue May 15 20:08:38 2001 From: jans@numeric-quest.com (Jan Skibinski) Date: Tue, 15 May 2001 15:08:38 -0400 (EDT) Subject: Ix class In-Reply-To: <3B01BF20.952F55FE@mindspring.com> Message-ID: On Tue, 15 May 2001, Matt Harden wrote: [..] > I would like _any_ pair of Ints to be an acceptable boundary for the > honeycomb, not just the ones that represent valid indexes. For example, > (Hx (0,0), Hx (15,12)) should be a valid set of bounds. The current > definition of rangeSize makes this impossible, which is why I would like > to override it. By the way, the Library Report does not explicitly say > that the bounds have to both be valid indexes, though it does imply this > with the sample definition of rangeSize. There is an old article [1], that is somehow related to what you do. Looks like it could add some extra fuel to your arguments if re-examined in terms of current Haskell. [It might be also interesting to those discussing arrays in the other thread.] Jan [1] D.B. Carpenter, Some Lattice-based Scientific Problems, Expressed in Haskell, http://citeseer.nj.nec.com/157672.html From sk@mathematik.uni-ulm.de Wed May 16 06:38:06 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 16 May 2001 07:38:06 +0200 Subject: BAL paper available In-Reply-To: <20010515211402.B24804@math.harvard.edu>; from dpt@math.harvard.edu on Tue, May 15, 2001 at 09:14:02PM +0300 References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > Serge Mechveliani : > > > ... > > > The matter was always in parametric domains ... > > > Whoever tried to program real CA in Haskell, would agree that such a > > > problem exists. > > Can you be more precise what the problem is? One problem I see is > that referred to in Section 3 of the paper: you really need types that > depend on parameters (in particular, integer parameters). This is, > indeed, a problem--currently, you have to do runtime checks. > > Full-fledged dependent types à la Cayenne are undecidable, but there > are weaker variants that are likely to be good enough. What are the weaker variants? Do you know some references? Are they still decidable? That surprises me. If you allow integer arithmetic you can do already all computations (Church). -- Stefan Karrmann From fjh@cs.mu.oz.au Wed May 16 07:16:08 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 16:16:08 +1000 Subject: BAL paper available In-Reply-To: References: Message-ID: <20010516161608.A22442@hg.cs.mu.oz.au> On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > What should be improved compared to existing STUArray Int Double > > and similar? > > A simple standard proposal, not using ST and multiparameter type classes, > so that it would be possible to implement it in other compilers (namely nhc), > would be a great improvement for me. I think multiparameter type classes or other extensions to Haskell 98 are really needed to solve these kinds of problems in a simple and elegant way. The right solution, IMHO, is to extend nhc and other Haskell compilers to support multiparameter type classes, not to try to shoehorn things that don't fit into Haskell 98. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From khaliff@astercity.net Wed May 16 08:18:01 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Wed, 16 May 2001 09:18:01 +0200 (CEST) Subject: BAL paper available In-Reply-To: <20010516161608.A22442@hg.cs.mu.oz.au> Message-ID: On Wed, 16 May 2001, Fergus Henderson wrote: > On 15-May-2001, Wojciech Moczydlowski, Jr wrote: > > On 15 May 2001, Marcin 'Qrczak' Kowalczyk wrote: > > > What should be improved compared to existing STUArray Int Double > > > and similar? > > > > A simple standard proposal, not using ST and multiparameter type classes, > > so that it would be possible to implement it in other compilers (namely nhc), > > would be a great improvement for me. > > I think multiparameter type classes or other extensions to Haskell 98 are > really needed to solve these kinds of problems in a simple and elegant way. > > The right solution, IMHO, is to extend nhc and other Haskell compilers > to support multiparameter type classes, not to try to shoehorn things > that don't fit into Haskell 98. > > Fergus Henderson | "I have always known that the pursuit I don't like the idea of a program working which compiles only under compilers which have certain language extensions built in. If I understand things correctly, there is a list of language extensions (FFI for example), which has been accepted by all Haskell compilers developers. If multiparameter type classes were in that list, I would agree. Besides, MArray.lhs uses ST and ST requires not only multiparameter type classes, but also explicit universal quantification. I don't like ST and the idea that someone who wants to use arrays outside of IO has to use ST gives me creeps. By the way, I'm really surprised by the lack of time complexity information in MArray. I mean, that's the most important thing in arrays - that one can update/read a data in O(1). Wojciech Moczydlowski, Jr From fst@informatik.uni-kiel.de Wed May 16 09:30:57 2001 From: fst@informatik.uni-kiel.de (Frank Steiner) Date: Wed, 16 May 2001 10:30:57 +0200 Subject: WFLP 2001 deadline extension to May 22, 2001 Message-ID: <200105160830.KAA02124@listrac.informatik.uni-kiel.de> Due to various requests, the DEADLINE FOR SUBMISSIONS to WFLP 2001 International Workshop on Functional and (Constraint) Logic Programming Kiel, Germany, September 13-15, 2001 http://www.informatik.uni-kiel.de/~wflp2001 has been EXTENDED TO MAY 22, 2001. From ashley@semantic.org Wed May 16 09:39:08 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Wed, 16 May 2001 01:39:08 -0700 Subject: BAL paper available Message-ID: <200105160839.BAA01875@mail4.halcyon.com> At 2001-05-16 00:18, Wojciech Moczydlowski, Jr wrote: >> I think multiparameter type classes or other extensions to Haskell 98 are >> really needed to solve these kinds of problems in a simple and elegant way. >> >> The right solution, IMHO, is to extend nhc and other Haskell compilers >> to support multiparameter type classes, not to try to shoehorn things >> that don't fit into Haskell 98. >I don't like the idea of a program working which compiles only under >compilers which have certain language extensions built in. > >If I understand things correctly, there is a list of language extensions >(FFI for example), which has been accepted by all Haskell compilers >developers. If >multiparameter type classes were in that list, I would agree. I tend to share Fergus Henderson's viewpoint. I see a Haskell with multiparameter type classes as a language I want to work with, and it would be great to have libraries written for that. I'm less interested in Haskell 98, since it means muckier solutions to the same problems. -- Ashley Yakeley, Seattle WA From simonmar@microsoft.com Wed May 16 09:36:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Wed, 16 May 2001 09:36:56 +0100 Subject: BAL paper available Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> >=20 > I don't like the idea of a program working which compiles only under > compilers which have certain language extensions built in.=20 >=20 > If I understand things correctly, there is a list of language=20 > extensions > (FFI for example), which has been accepted by all Haskell=20 > compilers developers. If > multiparameter type classes were in that list, I would agree. >=20 > Besides, MArray.lhs uses ST and ST requires not only=20 > multiparameter type > classes, but also explicit universal quantification. ST doesn't require multiparameter type classes (although MArray does). It also doesn't require full support for explicit universal quantification, if runST is known to the compiler. Also, the ST array types are really an optional part of the MArray interface - it works perfectly well with just the IO array types. > I don't like ST and the idea that someone who wants to use arrays > outside of IO has to use ST gives me creeps.=20 What would you suggest as an alternative? I suppose you could have a monad which just supported a single array, but special-purpose monads tend to be a pain in practice (eg. what happens when you want two arrays?). > By the way, I'm really surprised by the lack of time=20 > complexity information > in MArray. I mean, that's the most important thing in arrays=20 > - that one can > update/read a data in O(1).=20 Point taken, I'll update the documentation to include more of this info. Cheers, Simon From S.J.Thompson@ukc.ac.uk Wed May 16 11:32:01 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Wed, 16 May 2001 11:32:01 +0100 Subject: Book reviewers for Journal of Functional Programming Message-ID: I am looking for book reviewers for the Journal of Functional Programming. Book reviews provide a service to the functional programming community by critically appraising many of the key books coming out in the field. If you are interested in becoming a reviewer, please send me an email with - A two sentence biography. - Your particular reviewing interests (e.g. teaching texts, books on ML, etc.) Current books up for review include Trends in Functional Programming edited by Greg Michaelson, et al Intellect Books, 1999 Trends in Functional Programming vol 2 edited by Stephen Gilmore Intellect Books, 2000 How to Design Programs by Felleisen et al MIT Press, 2001 Objective Caml Pascal Manoury and Bruno Pagano O'Reilly, 2000 Principles of Programming Languages Bruce Maclennan Oxford University Press, 1999 so let me know if you are interested in reviewing one of these, or indeed please make any suggestions about books you would like to see reviewed. You can find guidelines for writing JFP book reviews at http://www.dcs.gla.ac.uk/jfp/guidelines.html Thanks very much, Simon Thompson s.j.thompson@ukc.ac.uk From Dominic.J.Steinitz@BritishAirways.com Wed May 16 11:42:22 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 16 May 2001 10:42:22 Z Subject: Integers to Ints Message-ID: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can someone explain the following behaviour? Or is it a bug in hugs? X690v5> (fromIntegral(toInteger(minBound::Int))::Int) Program error: {primIntegerToInt (-2147483648)} (15 reductions, 70 cells) X690v5> (fromIntegral(toInteger((minBound::Int)+1))::Int) -2147483647 (21 reductions, 29 cells) X690v5> minBound::Int -2147483648 (9 reductions, 19 cells) Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From rjchaaft@cs.uu.nl Wed May 16 11:54:12 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Wed, 16 May 2001 12:54:12 +0200 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <4.3.0.20010516125151.00b2f3c8@pop.students.cs.uu.nl> Hello, >Can someone explain the following behaviour? Or is it a bug in hugs? I can not explain it. Rather strange is that even this is allowed: (fromIntegral (toInteger (minBound::Int) + 1) -1) :: Int yielding -2147483648 > > (fromIntegral(toInteger(minBound::Int))::Int) > >Program error: {primIntegerToInt (-2147483648)} >(15 reductions, 70 cells) > > > (fromIntegral(toInteger((minBound::Int)+1))::Int) >-2147483647 >(21 reductions, 29 cells) > > > minBound::Int >-2147483648 >(9 reductions, 19 cells) From C.T.McBride@durham.ac.uk Wed May 16 13:03:25 2001 From: C.T.McBride@durham.ac.uk (C T McBride) Date: Wed, 16 May 2001 13:03:25 +0100 (BST) Subject: BAL paper available In-Reply-To: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: On Wed, 16 May 2001, Stefan Karrmann wrote: > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > Serge Mechveliani : > > > > ... > > > > The matter was always in parametric domains ... > > > > Whoever tried to program real CA in Haskell, would agree that such = a > > > > problem exists. > >=20 > > Can you be more precise what the problem is? One problem I see is > > that referred to in Section 3 of the paper: you really need types that > > depend on parameters (in particular, integer parameters). This is, > > indeed, a problem--currently, you have to do runtime checks. > >=20 > > Full-fledged dependent types =E0 la Cayenne are undecidable, but there > > are weaker variants that are likely to be good enough. >=20 > What are the weaker variants? Do you know some references? > Are they still decidable? That surprises me. If you allow integer > arithmetic you can do already all computations (Church). The idea that `dependent types are undecidable' is a popular but understandable misconception arising from a particular design decision in a particular system---Cayenne. Dependent types as found in proof systems such as Coq and Lego do have decidable typechecking: programs may only use structural recursion, and hence all the evaluation which takes place during typechecking is guaranteed to terminate. However, in order to support real programming, Cayenne allows general recursion: as it makes no distinction between the programs which are executed at compile-time and those only executed at run-time, undecidability creeps in. Understandably, neither horn of this dilemma is particularly attractive to programmers who want to combine flexibility at run-time with a genuinely static notion of typechecking.=20 (Of course, post-98 Haskell with certain type class options selected has a type-level language containing non-terminating programs, making typechecking undecidable for exactly the same reason as in Cayenne.) However, there is a middle way: we can distinguish compile-time programs from run-time programs and restrict the former to the structurally recursive fragment, leaving general recursion available in the latter.=20 In this way, all the programs we know and love remain available at run-time, whilst the type system acquires a large yet decidable extension to its expressive power. The key is the application rule, for it is here that programs leak into types. G |- f :: all x::S . T G |- s :: S -------------------------------------- G |- f s :: [s/x]T If s is potentially non-terminating, typechecking becomes undecidable: [s/x]T may not have a normal form.=20 Now let's separate compile-time programs (typed with `|-') from run-time programs (typed with `/-', say). Restricting the compile-time language to structural recursion, the above rule poses no threat. We can add G |- t :: T ------------- (a compile-time program is a run-time program) G /- t :: T G /- f :: all x::S . T G |- s :: S -------------------------------------- x free in T G /- f s :: [s/x]T G /- f :: S -> T G /- s :: S -------------------------------- (S -> T abbreviates all x::S. T G /- f s :: T when x is not free in T) G /- f :: T -> T -------------------- (fixpoint) G /- Y f :: T -> T compile-time structurally recursive programs, extending with general recursion only at run-time. Typechecking is thus decidable, with all your old code intact.=20 Structural recursion is a syntactically checkable notion which allows a large, but obviously not complete language of terminating programs to be recognized as such. How large? Well, first-order unification is structurally recursive, and so is normalization for simply-typed lambda-calculus. As decidable type systems go, this one is better than a poke in the eye.=20 I respectfully suggest that dependent types are worth a second look. Cheers Conor From fjh@cs.mu.oz.au Wed May 16 13:27:18 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 16 May 2001 22:27:18 +1000 Subject: Integers to Ints In-Reply-To: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> References: <"042013B02598E01B*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Message-ID: <20010516222718.A23867@hg.cs.mu.oz.au> On 16-May-2001, Steinitz, Dominic J wrote: > Can someone explain the following behaviour? Or is it a bug in hugs? It looks to me very much like it is a bug in Hugs. ghc 4.04 does not suffer from this bug. It's easy to make mistakes like this, which can often arise from forgetting the assymetric nature of twos-complement signed integers, which have more negative numbers than positive numbers. We once had a similar kind of bug in the Mercury standard library implementation, where string__to_int was not handling the most negative integer correctly. We fixed that one in March 1998. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From simonpj@microsoft.com Wed May 16 11:35:24 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 03:35:24 -0700 Subject: BAL paper available Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F2E@red-msg-09.redmond.corp.microsoft.com> | Despite my extremely deep respect for all people contributing=20 | to Haskell, despite my love for the language etc. I begin to=20 | suspect that it has been standardized too early, and if we=20 | (Sergey, other people interested in math,=20 | as Dylan Thurston, myself, etc., as well as people who want=20 | to do *serious* graphics in a functional way) want an adapted=20 | functional language, either we will have to wait quite long,=20 | or perhaps it is the time to invent another language, with a=20 | more dynamic type system, with intrinsic graphic utilities,=20 | and other goodies. For the moment - this is my personal=20 | viewpoint - it might be better to write concrete=20 | applications, and papers describing those applications. Then=20 | we shall perhaps know better what kind of structures,=20 | algorithms, representations, genericities, etc. we REALLY=20 | need for practical purposes. H98 is standardised, but Haskell certainly isn't. GHC and Hugs both have numerous extensions. So I don't think standardisation is a difficulty. The availability of implemention effort certainly is. But even before that, to implement something one needs a good clear specification, and preferably one that several people subscribe to (i.e. agree with the need and the design of the extension to meet that need). My guess is that the lacks you allude are due not to standardisation, nor to implementation effort, but rather to the lack of design/specfication. If there are things you want, perhaps you can contribute to a design for that thing? (Of course, the existence of a design doesn't guarantee an implementation; implementation effort is certainly an issue. But the absence of a design more or less guarantees the absence of an implementation.) I too have a great respect for the work that Sergey, Jerzy and others=20 have been doing. Indeed I don't understand the half of it. I hope I don't even need to understand it because it's a Haskell library. But not understanding it leaves me badly placed to know what the language difficulties are and maybe there are others in my position. Simon From simonpj@microsoft.com Wed May 16 15:26:42 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 16 May 2001 07:26:42 -0700 Subject: Scoped type variables Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F3A@red-msg-09.redmond.corp.microsoft.com> | | When you say there's a good theoretical foundation (typed lambda | | calcului) I think you are imagining that when we say | |=20 | | f (x::a) =3D e | |=20 | | we are saying "There's a /\a as well as a \x::a in this definition". |=20 | No, that's not what I'm thinking.=20 OK, let me try to give some type rules for what I have in mind. In these rules, I'm going to have an environment, T, that binds user type variables to types. (A "user type variable" is a type variable that appears in the program text.) There is still a conventional type environment, G (usually written=20 Greek Gamma), that associates user term variables with their types. I'll just deal with type variables in lambda patterns, like \ (x::a) -> E Here's the rule: x_i =3D free-term-vars(pat) a_i =3D free-type-vars(pat) \ T (T, a_i=3Dtaua_i); (G, x_i:taux_i) |- pat : tau_1 (T, a_i=3Dtaua_i); (G, x_i:taux_i) |-- E : tau_2 ------------------------------------------------------- T;G |- \pat -> E : tau_1 -> tau_2 The a_i are the type variables brought into scope by the pattern; namely the free type variable of the pattern which are not already in scope (hence the \ T). The T environment is extended by binding each user type variable a_i to a type taua_i that is gotten out of thin air (as is common in type rules). This new T env is used when typechecking the pattern itself and the body E. The intereesting bit is how to typecheck patterns, and type inside them: T;G |- pat : tau T |- ty : tau ----------------- T;G |- pat::ty : tau That is, to typecheck the pattern (pat::ty), typecheck pat and typecheck ty. The judgement T |- ty : tau checks that the user type ty is well formed with type tau. The key rule of this judgement looks up a type variable in T: ----------------- T |- a : T(a) OK, that's it. The point is simply that the user type variables are regarded as the name of a type; the programmer doesn't specify just what that type is. The type rules just 'inline' the type wherever the name is used. All this translates into completely unmodified System F. =20 | OK, so there are two questions | a) does that answer the question about the techincal foundation | b) is it a good design from a software engineering point of view |=20 | I hope the answer to (a) is yes, but I realise that opinions may=20 | differ about (b). This message is really just a second attempt at (a) Simon From khaliff@astercity.net Wed May 16 23:19:23 2001 From: khaliff@astercity.net (Wojciech Moczydlowski, Jr) Date: Thu, 17 May 2001 00:19:23 +0200 (CEST) Subject: BAL paper available In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115884@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: On Wed, 16 May 2001, Simon Marlow wrote: > > Besides, MArray.lhs uses ST and ST requires not only > > multiparameter type > > classes, but also explicit universal quantification. > > ST doesn't require multiparameter type classes (although MArray does). You're of course right. > It also doesn't require full support for explicit universal > quantification, if runST is known to the compiler. So it's another thing to put inside a compiler? > Also, the ST array types are really an optional part of the MArray > interface - it works perfectly well with just the IO array types. Perhaps. It just shows that the module was created specifically for ghc. > > I don't like ST and the idea that someone who wants to use arrays > > outside of IO has to use ST gives me creeps. > > What would you suggest as an alternative? I suppose you could have a > monad which just supported a single array, but special-purpose monads > tend to be a pain in practice (eg. what happens when you want two > arrays?). I'd rather have a monad which just supports a single array as a standard and IO/STArray as a language extension, than the other way. You could tell the same about MonadState. And I've never needed to use ST - somehow MonadState was always enough. And I vaguely remember some problems with typing when I tried to use ST once. IOArray is better - though it is unnatural to be forced to use IO whenever one wants to do something on arrays. So, in the end, if I were to choose between STArray, IOArray and a monad with a single array, I'd choose the monad. Though the best solution probably would be to support all of them. I don't know how the TODO list of nhc developers looks like, but if they aren't implementing multiparameter type classes now, it probably (disclaimer: I am not a Haskell compiler developer) would be easier to implement a simple monad, than type classes + ST. > Simon Wojciech Moczydlowski, Jr From karczma@info.unicaen.fr Thu May 17 07:49:48 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 08:49:48 +0200 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> Message-ID: <3B03748C.D65FDD19@info.unicaen.fr> Dylan Thurston cites : > > ... if we [...] want an > > adapted functional language, either we will have to wait quite long, > > or perhaps it is the time to invent another language, with a more > > dynamic type system, with intrinsic graphic utilities, and other > > goodies. > > For myself, I don't see a problem here. For "intrinsic graphic > utilities", someone has to write the graphic libraries. (You don't > mean they should be built into the language, do you?) The type system > is about as strong as anyone knows how to make a static type system; > and it's not too hard to fall back on run-time type checking when > necessary (as Sergey does in BAL). Look what happens with functional graphics. Dozens of really good papers, I could mention many names here. (Some bad papers as well, some people formalize and formalize without any contact with reality...) So, one may want to check all this. You take Alastair Reid's Hugs graphic library, and you discover that: The IO monadic framework is so rigid that you program imperatively, and after a few minutes you ask yourself why for goodness sake do it in Haskell? The programming style is not functional at all. In C++ or Java you do it faster and without more pain. (From the syntactic point of view this is a step backward wrt. the Henderson's book showing how to compose graphics objects in Scheme...) You can't draw individual pixels. (OK, lines with length 1 work). So, impossible to create complicated textures. Impossible to generate complex geometric models rendered pixel by pixel. Try, please, to fill a rectangle with a texture. The graphic updates by the Draw monad will explode the memory quite fast. No relation between bitmaps and arrays. (If the bitmaps work at all.) Similar problems are visible in the Clean library. Both, Hugs and Clean libraries have been added ad hoc to the language environment. Plenty of horrible Windows quirks squeezed into a functional interface. What I mean by *intrinsic* graphics: The graphic primitives should be WELL integrated with the underlying virtual machine. No silly "external" bitmaps impossible to garbage-collect, and impossible to process (thresholding, transfer curves, algebra). No pixels drawn using "line". True, fast access to primitive data. Efficient 2dim and 3dim vectors, with optimized processing thereof. Mapped arrays, easy passage from screen to bitmap DContext. Possibility to have decent functional binding of OpenGL calls. And mind you, OpenGL is not just a bunch of graphic calls, but a "state machine". Some graphic data must be processed by strict algorithms, laziness may deteriorate the efficiency considerably. No, this is not JUST the problem of external libraries. It would be, if the language were at the level of, say, C. But if the runtime is complex with plenty of dynamical data to protect and to recover, and if the internal control transfer is non-trivial (continuations, private stacks, etc.) then adding efficient and powerful graphics <> is not easy. === In my opinion one of best decisions taken by the Rice mafia was to base the DrScheme interface on WxWindows. What a pleasure to produce graphic exercises for students under Linux, test it under Solaris, and work with them under W2000 without a single incompatibility. I am still unhappy, because it is too slow to generate textures at a respectable rate, but no comparison with Hugs which bombs. But perhaps the next version (if ...) will optimize a few things. === And, if you want to have *interactive* graphics, then obviously you must provide some kind of event-processing functionalities. Is this just an external library question? ****************************** No place to discuss type systems here, but "falling back" into run-time checks is not enough in this context, we know that we need a genuine object-oriented genericity for graphical entities. Perhaps even with multiple inheritance or the java-style "interfaces". So, again, a bit more than just "graphic library". Jerzy Karczmarczuk Caen, France From timd@macquarie.com.au Thu May 17 08:42:14 2001 From: timd@macquarie.com.au (Timothy Docker) Date: Thu, 17 May 2001 17:42:14 +1000 (EST) Subject: BAL paper available >> graphic libraries In-Reply-To: <3B03748C.D65FDD19@info.unicaen.fr> References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> Message-ID: <15107.31057.395890.996366@tcc2> Jerzy Karczmarczuk writes: [Some interesting points on functional wrappings of graphics libraries] Has anyone considered writing a haskell wrapper for SDL - Simple Directmedia Layer at http://www.libsdl.org ? This is a cross platform library intended for writing games, and aims for a high performance, low level API. It would be interesting to see how clean a functional API could be built around such an imperative framework. Tim From holzmueller@ics-ag.de Thu May 17 09:06:55 2001 From: holzmueller@ics-ag.de (Bernd =?iso-8859-2?Q?Holzm=FCller?=) Date: Thu, 17 May 2001 10:06:55 +0200 Subject: Proposal for generalized function partition in List-library Message-ID: <3B03869F.88D5EF9D@ics-ag.de> Hi all, knowing that the Haskell library report is currently being rewritten, I would like to propose a new function for module List that generalizes the current function partition :: (a -> Bool) -> [a] -> [[a]] in the following way: partition :: Eq b => (a -> b) -> [a] -> [[a]] partition _ [] = [] partition f (a:as) = let (as',as'') = foldr (select (f a)) ([],[]) as in (a:as'):partition f as'' where select b x (ts,fs) | f x == b = (x:ts,fs) | otherwise = (ts,x:fs) This partitioning function builds equivalence classes from the list argument, where each element list within the result list consists of elements that all map to the same value when applying f to it. Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] This is much more general than the existing partitioning function and applicable in many practical cases. Cheers, Bernd Holzmüller From bedloose@hotmail.com Thu May 17 09:25:10 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:25:10 +0200 (CEST) Subject: Monads Message-ID: <20010517082510.32473.qmail@web14306.mail.yahoo.com> Hi I'v currently working on a school-project where I have to describe the Haskell programming language. I've been looking through Monads and especially the IO monad, the Maybe monad and the list monad My question is why are monads necessary in the language ? Is it not possible to construct the features provided by Monads using basic functional constructs ? What do I gain using Monads ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From ashley@semantic.org Thu May 17 09:41:11 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 01:41:11 -0700 Subject: Monads Message-ID: <200105170841.BAA08310@mail4.halcyon.com> At 2001-05-17 01:25, Mads Skagen wrote: >My question is why are monads necessary in the >language ? > >Is it not possible to construct the features provided >by Monads using basic functional constructs ? Monads themselves are made purely out of basic functional constructs. >What do I gain using Monads ? They happen to be a very convenient pattern. Mostly they're used to model imperative actions: while a purely functional language cannot actually execute actions as part of its evaluation, it can compose them, along the lines of "AB is the action of doing A, and then doing B with its result". Monads happen to be a useful pattern for such things. -- Ashley Yakeley, Seattle WA From bedloose@hotmail.com Thu May 17 09:47:50 2001 From: bedloose@hotmail.com (=?iso-8859-1?q?Mads=20Skagen?=) Date: Thu, 17 May 2001 10:47:50 +0200 (CEST) Subject: Monads Message-ID: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Thank you for your reply. So what you are saying is that I actually don't need Monads to perform the tasks Monads supports ? Thank you very much. Regards Skagen ______________________________________________________ Går mail for langsomt for dig? Så prøv Yahoo! Messenger - her kan du i løbet af få sekunder udveksle beskeder med de venner, der er online. Messenger finder du på adressen: http://dk.messenger.yahoo.com From karczma@info.unicaen.fr Thu May 17 10:03:22 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 11:03:22 +0200 Subject: Monads References: <200105170841.BAA08310@mail4.halcyon.com> Message-ID: <3B0393DA.8A105FD7@info.unicaen.fr> Ashley Yakeley answer to Mads Skagen: > >My question is why are monads necessary in the > >language ? > > > >Is it not possible to construct the features provided > >by Monads using basic functional constructs ? > > Monads themselves are made purely out of basic functional constructs. > > >What do I gain using Monads ? > > They happen to be a very convenient pattern. Mostly they're used to model > imperative actions: while a purely functional language cannot actually > execute actions as part of its evaluation, it can compose them, along the > lines of "AB is the action of doing A, and then doing B with its result". > Monads happen to be a useful pattern for such things. PLEASE!!! I disagree quite strongly with such severely limited answers addressed to people who don't know about monads. Monads are *much* more universal than that. They are "convenient patterns" to code the non-determinism (lazy list monads), to generalize the concept of continuations, to add tracing, exceptions, and all stuff called "computation" by the followers of Moggi. They are natural thus to construct parsers. Imperative programming is just one facet of the true story. Mads Skagen: please read the paper by Wadler on the essence of functional programming, and other stuff picked, say, from here: http://hypatia.dcs.qmw.ac.uk/SEL-HPC/Articles/FuncArchive.html That's right you don't really NEED monads (unless you are forced to do IO...), but when you learn them you will feel better and older. Jerzy Karczmarczuk Caen, France From ashley@semantic.org Thu May 17 10:12:16 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 17 May 2001 02:12:16 -0700 Subject: Monads Message-ID: <200105170912.CAA09737@mail4.halcyon.com> At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: >Monads are *much* more universal than that. They are "convenient patterns" >to code the non-determinism (lazy list monads), to generalize the concept >of continuations, to add tracing, exceptions, and all stuff called >"computation" by the followers of Moggi. They are natural thus to construct >parsers. Imperative programming is just one facet of the true story. Perhaps, but mostly monads are used to model imperative actions. And their use in imperative programming is the obvious starting point to learning about them. -- Ashley Yakeley, Seattle WA From rjchaaft@cs.uu.nl Thu May 17 10:57:45 2001 From: rjchaaft@cs.uu.nl (Rijk-Jan van Haaften) Date: Thu, 17 May 2001 11:57:45 +0200 Subject: Monads In-Reply-To: <20010517084750.23684.qmail@web14308.mail.yahoo.com> Message-ID: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> >So what you are saying is that I actually don't need >Monads to perform the tasks Monads supports ? Indeed. However, not using the Monadic do syntax results in hardly-readible code. For an explanation of how monads can be written in a functional way, see http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm From mg169780@students.mimuw.edu.pl Thu May 17 11:36:39 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Thu, 17 May 2001 12:36:39 +0200 (CEST) Subject: Proposal for generalized function partition in List-library In-Reply-To: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: On Thu, 17 May 2001, Bernd [iso-8859-2] Holzm=FCller wrote: > This partitioning function builds equivalence classes from the list > argument, where each element list within the result list consists of > elements that all map to the same value when applying f to it. > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] >=20 > This is much more general than the existing partitioning function and > applicable in many practical cases. But here generality comes at the expense of speed I think. =09Greetings :-) =09=09Michal Gajda =09=09korek@icm.edu.pl From dscarlett@optushome.com.au Thu May 17 12:07:56 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Thu, 17 May 2001 21:07:56 +1000 Subject: HUGS error: Unresolved overloading Message-ID: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Can anyone shed some light on the following error? Thanks in advance. isSorted :: Ord a => [a] -> Bool isSorted [] = True isSorted [x] = True isSorted (x1:x2:xs) | x1 <= x2 = isSorted (x2:xs) | otherwise = False -------- Hugs session for: /usr/local/share/hugs/lib/Prelude.hs haskell/sort.hs Main> isSorted [1] True Main> isSorted [1,2] True Main> isSorted [2,1] False Main> isSorted [] ERROR: Unresolved overloading *** Type : Ord a => Bool *** Expression : isSorted [] -------- From karczma@info.unicaen.fr Thu May 17 12:36:54 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 17 May 2001 13:36:54 +0200 Subject: Monads References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <3B03B7D6.AE80F472@info.unicaen.fr> Ashley Yakeley comments: > > Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. They are "convenient patterns" > >to code the non-determinism (lazy list monads), to generalize the concept > >of continuations, to add tracing, exceptions, and all stuff called > >"computation" by the followers of Moggi. They are natural thus to construct > >parsers. Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. "Mostly" is very relative. The real power of monads is their universality. This "modelling of imperative actions" is just a way to hide the State, which in IO is rather unavoidable. But in my opinion it is rather antipedagogic to introduce monads in such a way to beginners. "Obvious starting point"? My goodness, but this is selling a black, closed box, which smells badly (imperatively) to innocent souls. People see then just do rubbish <- rubbish more_rubbish and don't know anything about the true sense of return, of the relation of <- to >>=, and finally they can use ONLY the IO Monad, nothing else. They start posing questions what is the difference between a <- b and let a = b ... and they get often ungodly answers to that, answers which say that the main difference is that <- "executes side-effects", and let doesn't. It choked me a bit. (Was it on comp.lang.functional, or on one of Haskell lists?) My philosophy is completely opposite. Introduce Monads as a natural way of chaining complex data transfer and hiding useless information, and when the idea is assimilated, then pass to IO. I begin usually with Maybe, then with backtrack Monad, and some simple State Transformers. Then, the students can grasp the Wadler's style slogan "Monads can Change the World". Oh, well, all teaching approaches are imperfect. Jerzy Karczmarczuk Caen, France From rkrueger@TechFak.Uni-Bielefeld.DE Thu May 17 12:56:20 2001 From: rkrueger@TechFak.Uni-Bielefeld.DE (Ralf Krueger) Date: Thu, 17 May 2001 13:56:20 +0200 Subject: HUGS error: Unresolved overloading References: <000f01c0dec1$a01ca4a0$0100a8c0@CO3003288A> Message-ID: <3B03BC64.7745016C@uni-bielefeld.de> David Scarlett wrote: > > Can anyone shed some light on the following error? Thanks in advance. > > isSorted :: Ord a => [a] -> Bool > isSorted [] = True > isSorted [x] = True > isSorted (x1:x2:xs) > | x1 <= x2 = isSorted (x2:xs) > | otherwise = False > > -------- [...] > Main> isSorted [] > ERROR: Unresolved overloading > *** Type : Ord a => Bool > *** Expression : isSorted [] > -------- The list constructor [] is overloaded, so it's type cannot be infered inambigously. The empty list can be of any list type, HUGS cannot check if it's parameter's type is an instance of Ord. -- Ralf Krueger E-Mail: rkrueger@TechFak.Uni-Bielefeld.DE URL: http://www.Ralf-Krueger.DE Bielefeld University Center for Interdisciplinary Research (ZiF) WWW Administration Wellenberg 1 33615 Bielefeld Germany Tel: ++49 521 106-2777 From peterd@availant.com Thu May 17 14:25:43 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 09:25:43 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5910@smail01.clam.com> Monads are used not only for programming IO, state, exceptions etc, but also are the foundation of lists. It is hard to imagine functional programming without this basic datatype. Sets, Bags, trees etc are also monads. Phil Wadler wrote a very useful paper Comprehending Monads which I notice is not found on the Haskell/bookshelf web page. It can be found at http://www.cs.bell-labs.com/who/wadler/topics/monads.html I recommend this page for anyone interested in monads. --PeterD > -----Original Message----- > From: Mads Skagen [mailto:bedloose@yahoo.dk] > Sent: Thursday, May 17, 2001 4:25 AM > To: haskell@haskell.org > Subject: Monads > Hi > I'v currently working on a school-project where I have > to describe the Haskell programming language. > I've been looking through Monads and especially the IO > monad, the Maybe monad and the list monad > > My question is why are monads necessary in the > language ? > Is it not possible to construct the features provided > by Monads using basic functional constructs ? > What do I gain using Monads ? > Thank you very much. > Regards Skagen From Joe.Bowers@CanopySystems.com Thu May 17 14:35:19 2001 From: Joe.Bowers@CanopySystems.com (Joe Bowers) Date: Thu, 17 May 2001 09:35:19 -0400 Subject: Wadler (was RE: Monads) Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/plain There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0 Content-Type: text/html Wadler (was RE: Monads) There have been several references to "a paper by Wadler" in this thread- some folks (well, at least one folk :) on this list may not be familiar with the work surrounding Haskell yet, and (from this context) This paper seems like a pretty good place to start. Would anybody have a detailed citation for it, or (even better) is it up on the web? Joe ------_=_NextPart_001_01C0DED6.376298B0-- From peterd@availant.com Thu May 17 15:30:23 2001 From: peterd@availant.com (Peter Douglass) Date: Thu, 17 May 2001 10:30:23 -0400 Subject: Monads Message-ID: <8BDAB3CD0E67D411B02400D0B79EA49ADF5914@smail01.clam.com> I should probably mention that one doesn't need to know that a list is a monad in order to use a list. However, understanding that a list obeys the monad laws is a useful way to learn about monads. --PeterD > -----Original Message----- > From: Peter Douglass > Sent: Thursday, May 17, 2001 9:26 AM > To: 'bedloose@hotmail.com'; haskell@haskell.org > Subject: RE: Monads > > > Monads are used not only for programming IO, state, > exceptions etc, but also > are the foundation of lists. It is hard to imagine > functional programming > without this basic datatype. Sets, Bags, trees etc are also > monads. Phil > Wadler wrote a very useful paper Comprehending Monads which I > notice is not > found on the Haskell/bookshelf web page. It can be found at > > http://www.cs.bell-labs.com/who/wadler/topics/monads.html > > I recommend this page for anyone interested in monads. > --PeterD > > > > -----Original Message----- > > From: Mads Skagen [mailto:bedloose@yahoo.dk] > > Sent: Thursday, May 17, 2001 4:25 AM > > To: haskell@haskell.org > > Subject: Monads > > > Hi > > > I'v currently working on a school-project where I have > > to describe the Haskell programming language. > > > I've been looking through Monads and especially the IO > > monad, the Maybe monad and the list monad > > > > My question is why are monads necessary in the > > language ? > > > Is it not possible to construct the features provided > > by Monads using basic functional constructs ? > > > What do I gain using Monads ? > > > Thank you very much. > > > Regards Skagen > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From nick@microsoft.com Thu May 17 16:09:06 2001 From: nick@microsoft.com (Nick Benton) Date: Thu, 17 May 2001 08:09:06 -0700 Subject: Final CfP: BABEL Workshop on Multilanguage Infrastructure and Interoperability Message-ID: <0C682B70CE37BC4EADED9D375809768A48EDD9@red-msg-04.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable BABEL'01 FINAL CALL FOR PAPERS =20 First Workshop on Multi-Language Infrastructure and Interoperability =20 http://research.microsoft.com/~nick/babel01.htm =20 Satellite to PLI'01 =20 Firenze, Italy, 8th September 2001 =20 Submission Deadline: 1st June 2001 =20 ** The Submission Site is now open ** http://cmt.research.microsoft.com/BABEL01/ =20 AIMS AND SCOPE =20 Recent years have seen a resurgence of interest in multi-language tools and intermediate languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being able to interoperate easily with code written in existing languages is essential for such an implementation to be useful in practice. This workshop aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not limited to: =20 * Compilation of high level languages to common executable formats such as Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common Language Runtime. =20 * Defining and using bindings for component middleware such as OMG's CORBA or Microsoft's COM. =20 * Language constructs to support interoperability between different languages, particularly from different paradigms (e.g. OO/functional). =20 * Multi-language backends for compilation and/or analysis (e.g. MLRISC, FLINT, C--, TAL, SUIF). =20 * Type theoretic and semantic foundations for multi-language work. =20 * Multi-language development environments and tools (e.g. debuggers, profilers). =20 Submissions may address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors unsure of the appropriateness of a potential submission should email the PC chair (nick@microsoft.com). =20 =20 PROGRAMME COMMITTEE =20 Nick Benton (chair) Microsoft Research Fergus Henderson University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett Cornell University Martin Odersky Ecole Polytechnique Federale de Lausanne=20 John Reppy Bell Labs=20 Andrew Tolmach Portland State University=20 David Wakeling University of Exeter =20 =20 INVITED SPEAKERS =20 Zhong Shao Yale University =20 =20 IMPORTANT DATES =20 Deadline for submission 1st June 2001 Notification of acceptance 9th July 2001 Final version due 10th August 2001 =20 =20 SUBMISSION DETAILS =20 Papers should be at most 14 pages and should be submitted in Ghostscript-compatible PostScript or PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS style files (see http://math.tulane.edu/~entcs/). Papers should be submitted electronically via the submission site at http://cmt.research.microsoft.com/BABEL01/ Submissions should not overlap significantly with work which has already been published or submitted to any other conference or journal. An informal proceedings will be published as a technical report and distributed at the workshop. It is intended that a final proceedings will be published in a volume of ENTCS. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C0DEE3.5106F5A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable &= nbsp; &n= bsp; BABEL'01 &= nbsp; &n= bsp; FINAL CALL FOR PAPERS &= nbsp; First Workshop on Multi-Language &= nbsp; Infrastructure and Interoperability http://research.= microsoft.com/~nick/babel01.htm &= nbsp; &n= bsp; Satellite to PLI'01 &= nbsp; Firenze, = Italy, 8th September 2001 &= nbsp; Submission Deadline: 1st June = 2001 &= nbsp; ** The Submission Site is now open ** &= nbsp; http://cmt.research.m= icrosoft.com/BABEL01/ AIMS AND = SCOPE Recent years have = seen a resurgence of interest in multi-language tools and intermediate = languages, and in interoperability between programs and components written in different programming languages. Shared infrastructure such as code generators, = analysis tools and garbage collectors can greatly ease the task of producing a high-quality implementation of a new programming language, whilst being = able to interoperate easily with code written in existing languages is essential = for such an implementation to be useful in practice. This workshop = aims to bring together researchers and developers working on multi-language integration. Contributions are welcome on topics including, but not = limited to: * Compilation of = high level languages to common executable formats such as = Sun's Java Virtual Machine, the DRA's ANDF or Microsoft's .NET Common = Language Runtime. * Defining and = using bindings for component middleware such as OMG's CORBA or = Microsoft's COM. * Language = constructs to support interoperability between different languages, particularly from different paradigms (e.g. = OO/functional). * Multi-language = backends for compilation and/or analysis (e.g. = MLRISC, FLINT, C--, TAL, = SUIF). * Type theoretic = and semantic foundations for multi-language work. * Multi-language = development environments and tools (e.g. debuggers, = profilers). Submissions may = address any programming paradigm. Experience papers which describe the use of multiple languages in application development are also welcome. Authors = unsure of the appropriateness of a potential submission should email the PC = chair (nick@microsoft.com). PROGRAMME = COMMITTEE Nick Benton (chair) Microsoft Research Fergus Henderson &= nbsp; University of Melbourne Andrew Kennedy (organiser) Microsoft Research Greg Morrisett &= nbsp; Cornell = University Martin Odersky &= nbsp; Ecole Polytechnique Federale de Lausanne John Reppy &n= bsp; Bell Labs = Andrew Tolmach &= nbsp; Portland = State University David Wakeling &= nbsp; University of Exeter INVITED = SPEAKERS Zhong Shao &= nbsp; Yale = University IMPORTANT = DATES Deadline for submission 1st June 2001 Notification of acceptance 9th July = 2001 Final version due = 10th August 2001 SUBMISSION = DETAILS Papers should be at = most 14 pages and should be submitted in Ghostscript-compatible PostScript or = PDF format and be printable on both US letter and A4 paper. Authors are strongly encouraged to use ENTCS = style files (see http://math.tulane.edu/~e= ntcs/). Papers should be submitted electronically via the submission site = at http://cmt.research.m= icrosoft.com/BABEL01/ Submissions should = not overlap significantly with work which has already been published or = submitted to any other conference or journal. An informal proceedings will = be published as a technical report and distributed at the workshop. = It is intended that a final proceedings will be published in a volume of = ENTCS. =00 ------_=_NextPart_001_01C0DEE3.5106F5A1-- From farkinas@cbn.net.id Thu May 17 17:21:26 2001 From: farkinas@cbn.net.id (M. Faisal Fariduddin Attar Nasution) Date: Thu, 17 May 2001 23:21:26 +0700 Subject: Questions about Trie Message-ID: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting, I'm a last year student in a computer science field. I'm = currently trying to code an implementation for a compression using basic = Lempel-zif technique. I use a Trie (retrieval) as a data structure for = the dynamic dictionary aplication. The problem is Trie uses not just an = ordinary binary tree, but it uses a multiple-weighted tree, where one = node has at most 256 children. Most literatures about Haskell show only = binary tree for the example in tree or Abstract Data Structures subject. = So, does anyone know how to code the implementation for trie. Thanks for = paying attention and I'm really hoping for the answer immediately. Aerith Gainsborough (Final Fantasy VII) "All I know is..."=20 "The Cetra were born from the Planet, speak with the Planet, and=20 unlock the Planet."=20 "And....... then......"=20 "The Cetra will return to the Promised Land. A land that promises = supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = Greeting, I'm a=20 last year student in a computer science field. I'm currently trying to = code an=20 implementation for a compression using basic Lempel-zif technique. I use = a Trie=20 (retrieval) as a data structure for the dynamic dictionary = aplication. The=20 problem is Trie uses not just an ordinary binary tree, but it uses a=20 multiple-weighted tree, where one node has at most 256 children. Most=20 literatures about Haskell show only binary tree for the example in tree = or=20 Abstract Data Structures subject. So, does anyone know how to code the=20 implementation for trie. Thanks for paying attention and I'm really = hoping for=20 the answer immediately. Aerith Gainsborough (Final Fantasy = VII) "All I=20 know is..." "The Cetra were born from the Planet, speak with the = Planet, and=20 unlock the Planet." "And....... then......" "The Cetra will = return=20 to the Promised Land. A land that promises supreme happiness."=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D M. Faisal Fariduddin Attar=20 Nasution ----------------------------------- farkinas@cbn.net.id ------=_NextPart_000_0007_01C0DF28.18AAB360-- From uk1o@rz.uni-karlsruhe.de Thu May 17 17:18:13 2001 From: uk1o@rz.uni-karlsruhe.de (Hannah Schroeter) Date: Thu, 17 May 2001 18:18:13 +0200 Subject: Monads In-Reply-To: <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl>; from rjchaaft@cs.uu.nl on Thu, May 17, 2001 at 11:57:45AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> Message-ID: <20010517181811.C14548@rz.uni-karlsruhe.de> Hello! On Thu, May 17, 2001 at 11:57:45AM +0200, Rijk-Jan van Haaften wrote: > >So what you are saying is that I actually don't need > >Monads to perform the tasks Monads supports ? > Indeed. However, not using the Monadic do syntax results in > hardly-readible code. I don't really think so. The operator precedences for >> and >>= are quite okay, especially combined to the precedence of lambda binding. How is main = getLine >>= \line -> let number = read line in let result = number + 42 in print result less readable than main = do line <- getLine let number = read line let result = number + 42 print result ? Or main = putStr "Hello! What's your name?" >> getLine >>= \name -> putStrLn ("Hello, " ++ name ++ "!") compared to main = do putStr "Hello! What's your name?" name <- getLine putStrLn ("Hello, " ++ name ++ "!") > [...] Yes, I use do syntax where appropriate (e.g. also for usual parser monads), however, the operator syntax can be written quite readably too. Kind regards, Hannah. From simonpj@microsoft.com Thu May 17 17:52:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 17 May 2001 09:52:10 -0700 Subject: Ix class Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F4C@red-msg-09.redmond.corp.microsoft.com> I rather agree with Matt's message below. I'm desperately trying NOT to change the H98 libraries, but this is a very non-disruptive change, as he points out, and it does lift two apparently-unnecessary restrictions. a) Remove Ord from Ix's superclasses b) Add rangeSize to Ix's methods Does anyone have any thoughts about this. (We made a similar change to Random, adding=20 a method.) Simon | -----Original Message----- | From: Matt Harden [mailto:matth@mindspring.com]=20 | Sent: 16 May 2001 00:43 | To: Haskell list | Subject: Ix class |=20 |=20 | Hello, |=20 | I am working on an Ix instance for one of my types and=20 | finding it rather restrictive. For me it would be useful to=20 | have rangeSize be defined in the Ix class (with a default=20 | definition of course), so that it can be overridden. |=20 | Also, does anybody know why Ix derives from Ord? It seems to=20 | me this is an unnecessary limitation on the types that can be=20 | instances of Ix. I cannot think of a reason why the=20 | implementation of anything in the Ix or Array modules would=20 | require that every Ix be an Ord (with a minor exception --=20 | see below). If an implementation is using a comparison on an=20 | Ix type, chances are it should be using inRange or comparing=20 | (index bnds x) with (index bnds y) instead. |=20 | One change would have to be made in the Array module if Ord=20 | is removed from Ix: | instance (Ix a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | would become: | instance (Ix a, Eq a, Eq b) =3D> Eq (Array a b) where | a =3D=3D a' =3D assocs a =3D=3D assocs a' | instance (Ix a, Ord a, Ord b) =3D> Ord (Array a b) where | a <=3D a' =3D assocs a <=3D assocs a' |=20 | As I said, I think this is a very minor issue. |=20 | I believe that making these changes in the standard would not=20 | impact existing programs in any way. Could these changes be=20 | considered as a possible "typo" to be fixed in the Library Report? |=20 |=20 | P.S. In case anybody's interested, here's why I want to override | rangeSize: |=20 | > newtype Honeycomb =3D Hx (Int,Int) deriving (Eq,Show,Ord) | >=20 | > indexError =3D error "Index out of range" | >=20 | > instance Ix Honeycomb where | > range (Hx b1, Hx b2) =3D | > [Hx x | x <- range (b1,b2), isHexIx x] | > inRange (Hx b1, Hx b2) (Hx x) =3D | > inRange (b1,b2) x && isHexIx x | > index (Hx b1, Hx b2) (Hx x) =3D | > let i =3D index (b1,b2) x in | > if isHexIx x then i `div` 2 else indexError | >=20 | > isHexIx :: (Int,Int) -> Bool | > isHexIx (x,y) =3D x `mod` 2 =3D=3D y `mod` 2 |=20 | This implements a honeycomb or hexagonal tiling for a maze=20 | generating program. The honeycomb is superimposed on a grid=20 | such that only every other square is "active", corresponding=20 | to a particular hexagon in the honeycomb. It's similar to a=20 | checkers game, where only the dark squares are used. |=20 | I would like _any_ pair of Ints to be an acceptable boundary=20 | for the honeycomb, not just the ones that represent valid=20 | indexes. For example, (Hx (0,0), Hx (15,12)) should be a=20 | valid set of bounds. The current definition of rangeSize=20 | makes this impossible, which is why I would like to override=20 | it. By the way, the Library Report does not explicitly say=20 | that the bounds have to both be valid indexes, though it does=20 | imply this with the sample definition of rangeSize. |=20 | Thanks, | Matt Harden |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From gruenbacher-lists@geoinfo.tuwien.ac.at Thu May 17 19:03:23 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Thu, 17 May 2001 20:03:23 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) Message-ID: Hello, I was trying to write an abstraction for bidirectional communication between two threads. For some reason, MVars seem to break: ----------------------------------------------- class Cords c t u where newCord :: IO (c t u) listen :: c t u -> IO t speak :: c t u -> u -> IO () data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) instance Cords Cord t u where newCord = return (Cord newEmptyMVar newEmptyMVar) speak (Cord _ s) t = do s' <- s ; putMVar s' t listen (Cord h s) = do h' <- h ; takeMVar h' otherEnd (Cord t u) = Cord u t showT :: Cord Int String -> IO () showT cord = do putStrLn "Runnning..." x <- listen cord putStrLn ("Heard " ++ show x) speak cord (show x) putStr ("Said " ++ (show x)) showT cord main :: IO () main = do cord <- newCord forkIO (showT (otherEnd cord)) speak cord 1 str <- listen cord putStrLn str ----------------------------------------------- Hugs writes: Main> main Runnning... Program error: no more threads (deadlock?) (131 reductions, 307 cells) Any ideas? Thanks, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher gruenbacher@geoinfo.tuwien.ac.at Research Assistant Phone +43(1)58801-12723 Institute for Geoinformation Fax +43(1)58801-12799 Technical University of Vienna Cell phone +43(664)4064789 From john@repetae.net Thu May 17 19:42:50 2001 From: john@repetae.net (John Meacham) Date: Thu, 17 May 2001 11:42:50 -0700 Subject: Proposal for generalized function partition in List-library In-Reply-To: ; from mg169780@zodiac.mimuw.edu.pl on Thu, May 17, 2001 at 12:36:39PM +0200 References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: <20010517114250.D13591@mark.ugcs.caltech.edu> this is just how I understand things at the moment, if I am wrong or misleading anywhere then please speak up. I am unconvinced that such generalizations must come as speed hits, but perhaps someone can enlighten me. compilers seem to support seperate compilation and polymorphism at the moment by boxing polymorphic types and passing their class-context (term?) as a hidden parameter to the polymorphic function. but it seems that since haskell is strongly type checked at compile time, we already KNOW all of the types with certainty when it comes to compiling the program in the end so this would seem to be unnecisarry. now there are two cases where this breaks down * seperate compilation * code bloat namely that you don't necisarilly know all of the types of polymorphic functions when they are in a module that is compiled seperately from the rest of the program. the solution used by many C++ compilers is to inline all polymorphic code in place (this is why templates are in header files). there is no reason this won't work in haskell and give back all of the speed benefits of base types everwhere (as it would in this example) but has the unfortunate side effect of causing worst case exponential code bloat as every function is re-written for every type combination it is used with. the solution I see (and probably exists) is a hybrid model, one that lets the compiler know to specialize certain polymorphic functions as well as let the compiler utilize such specialized functions. a pragma which lets the compiler know that a certain specialization would be useful such as partition :: (Eq b) => (a -> b) -> [a] -> [[a]] partition fn ls = ... {-# specialize partition :: (a -> Bool) -> [a] [[a]] -} which would let the compiler know to generate code for partition specificially optimized for (a -> Bool) and thus obviating the need for the Eq hidden argument. the fully polymorphic version would of course also have to be generated. specializations would be advertised in the header file and utilized whenever the typechecker determined you were using partition in the specialized case. this seems like a better solution than the current practice of providing seperate general and specific functions, take, genTake, max, genMax and whatnot. you would just specify that specializations for the case of 'Int' should be generated as it would be the most common case. an {-# inline partition -} might also be useful which would actually place the text of the function into the .hi file to be in-line expanded as is done in C++... I imagine there would be some tweaking to determine when this is a win and when it isn't... some of this stuff probably exists in current compilers, but polymorphism need not be at the expense of speed. -John On Thu, May 17, 2001 at 12:36:39PM +0200, Michal Gajda wrote: > On Thu, 17 May 2001, Bernd [iso-8859-2] Holzmüller wrote: > > This partitioning function builds equivalence classes from the list > > argument, where each element list within the result list consists of > > elements that all map to the same value when applying f to it. > > Thus: partition (`div` 2) [1..5] yields [[1],[2,3],[4,5]] > > > > This is much more general than the existing partitioning function and > > applicable in many practical cases. > > But here generality comes at the expense of speed I think. -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Thu May 17 20:36:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:36:44 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: Thu, 17 May 2001 10:06:55 +0200, Bernd Holzmüller pisze: > I would like to propose a new function for module List that generalizes > the current function partition :: (a -> Bool) -> [a] -> [[a]] No, current partition has type (a -> Bool) -> [a] -> ([a], [a]) so your function is not compatible with it, so shouldn't replace such standard function. > partition:: Eq b => (a -> b) -> [a] -> [[a]] > partition _ [] = [] > partition f (a:as) = > let (as',as'') = foldr (select (f a)) ([],[]) as > in (a:as'):partition f as'' > where > select b x (ts,fs) | f x == b = (x:ts,fs) > | otherwise = (ts,x:fs) This function doesn't give a hint which sublists correspond to which results of the function, so I'm afraid it's easy to make errors by assuming that they will come in a different order. And it's inefficient: the cost is the number of elements times the number of different results of the function. I would write it thus: \f xs -> groupBy (\(a, _) (b, _) -> a == b) $ sortBy (\(a, _) (b, _) -> compare a b) [(f x, x) | x <- xs] You can apply 'map (map snd)' to the result to remove the results of f. I don't have a good name for it and I'm not sure it's common enough to put it in the standard library. It can also be more efficiently written using Array.accumArray for particular types of the result of the function. PS. What I would perhaps put into standard library: uniq :: Eq a => [a] -> [a] uniqBy :: (a -> a -> Bool) -> [a] -> [a] so people don't use nub unnecessarily (if elements are adjacent or can be made adjacent by sorting), and takeLastWhile :: (a -> Bool) -> [a] -> [a] dropLastWhile :: (a -> Bool) -> [a] -> [a] spanEnd :: (a -> Bool) -> [a] -> ([a], [a]) (with some better names) which iterate forward and are lazy, to avoid double reversing in case the test is cheap but the list is long, and partitionM :: Monad m => (a -> m Bool) -> [a] -> m ([a], [a]) Here are implementations of some of these: takeLastWhile p xs = case span p xs of (ys, []) -> ys (_, _:zs) -> takeLastWhile p zs dropLastWhile p xs = case span p xs of (_, []) -> [] (ys, z:zs) -> ys ++ z : dropLastWhile p zs spanEnd p xs = case span p xs of (ys, []) -> ([], ys) (ys, z:zs) -> (ys ++ z : ys', zs') where (ys', zs') = spanEnd p zs -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From qrczak@knm.org.pl Thu May 17 20:43:46 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 17 May 2001 19:43:46 GMT Subject: Proposal for generalized function partition in List-library References: <3B03869F.88D5EF9D@ics-ag.de> Message-ID: 17 May 2001 19:36:44 GMT, Marcin 'Qrczak' Kowalczyk pisze: > PS. What I would perhaps put into standard library: And also: split :: (a -> Bool) -> [a] -> [[a]] split p c = let (xs, ys) = break p c in xs : case ys of [] -> [] _:zs -> split p zs softSplit :: (a -> Bool) -> [a] -> [[a]] -- softSplit p c = filter (not . null) (split p c) softSplit p c = case dropWhile p c of [] -> [] x:xs -> let (ys, zs) = break p xs in (x:ys) : softSplit p zs It follows that words = softSplit isSpace. Any better name? -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From jenglish@flightlab.com Thu May 17 22:14:53 2001 From: jenglish@flightlab.com (Joe English) Date: Thu, 17 May 2001 14:14:53 -0700 Subject: Monads In-Reply-To: <200105170912.CAA09737@mail4.halcyon.com> References: <200105170912.CAA09737@mail4.halcyon.com> Message-ID: <200105172114.OAA07367@dragon.flightlab.com> Ashley Yakeley wrote: > At 2001-05-17 02:03, Jerzy Karczmarczuk wrote: > > >Monads are *much* more universal than that. [...] > >[...] Imperative programming is just one facet of the true story. > > Perhaps, but mostly monads are used to model imperative actions. And > their use in imperative programming is the obvious starting point to > learning about them. I don't know about that; I use monads most often when dealing with container classes (sets, bags, lists). They also provide a useful way to reason about parts of XPath and XSLT. As far as learning about them goes, I don't think I really "got" monads until reading Wadler's aptly-titled "Comprehending Monads", which approaches them from this perspective. --Joe English jenglish@flightlab.com From agold@bga.com Thu May 17 22:21:21 2001 From: agold@bga.com (Arthur H. Gold) Date: Thu, 17 May 2001 16:21:21 -0500 Subject: Questions about Trie References: <000a01c0deed$9896a9c0$6e3c9eca@farkinas> Message-ID: <3B0440D1.2248C105@bga.com> > "M. Faisal Fariduddin Attar Nasution" wrote: > > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using > basic Lempel-zif technique. I use a Trie (retrieval) as a data > structure for the dynamic dictionary aplication. The problem is Trie > uses not just an ordinary binary tree, but it uses a multiple-weighted > tree, where one node has at most 256 children. Most literatures about > Haskell show only binary tree for the example in tree or Abstract Data > Structures subject. So, does anyone know how to code the > implementation for trie. Thanks for paying attention and I'm really > hoping for the answer immediately. > IIRC, there's a trie implementation in Chris Okasaki's "Purely Functional Data Structures" -- that might be a start (there's also his "Edison" library, which contains many of the components you'd need). HTH (and sorry if it doesn't) --ag -- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu -- I am looking for work. Contact me. From ken@digitas.harvard.edu Thu May 17 22:17:49 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Thu, 17 May 2001 17:17:49 -0400 Subject: Wadler (was RE: Monads) In-Reply-To: ; from Joe.Bowers@CanopySystems.com on Thu, May 17, 2001 at 09:35:19AM -0400 References: Message-ID: <20010517171749.A25335@digitas.harvard.edu> --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-17T09:35:19-0400, Joe Bowers wrote: > There have been several references to "a paper by > Wadler" in this thread- some folks (well, at least > one folk :) on this list may not be familiar with > the work surrounding Haskell yet, and (from this context) > This paper seems like a pretty good place to start. > =20 > Would anybody have a detailed citation for it, > or (even better) is it up on the web? Wadler's monad papers, including "Comprehending Monads", are at http://cm.bell-labs.com/cm/cs/who/wadler/topics/monads.html --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig My god, I've seen heaven. - Flute at Band Camp --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BD/9zjAc4f+uuBURAnmcAJ9M6+wyOg+izO2eQo3GS5ovm55P+ACguuzz 9a35nSAI8w6IuYvSs7+ei7M= =9zoV -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From karczma@info.unicaen.fr Fri May 18 07:56:57 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 08:56:57 +0200 Subject: Monads References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> Message-ID: <3B04C7B9.D14AA827@info.unicaen.fr> Rijk-Jan van Haaften >>= Hannah Schroeter: > > ... However, not using the Monadic do syntax results in > > hardly-readible code. > > I don't really think so. The operator precedences for >> and >>= are > quite okay, especially combined to the precedence of lambda binding. ... > main = do > putStr "Hello! What's your name?" ... > Yes, I use do syntax where appropriate (e.g. also for usual parser > monads), however, the operator syntax can be written quite readably > too. I would add that sometimes you may be interested in Monadic SEMANTICS at a more profound level, trying to hide it completely at the surface. Then, the <> syntax is an abomination. The examples are already in the Wadler's "Essence". Imagine the construction of a small interpreter, a virtual machine which not only evaluates the expressions (belonging to a trivial Monad), but perform some side effects, or provides for exceptions propagated through a chain of Maybes. Then the idea is to * base the machine on the appropriate Monad * "lift" all standard operators so that an innocent user can write (f x) and never x >>= f (or even worse). The <> construct in such a context resembles the programming in assembler, and calling it more readable is hmmmm... not very convincing. (My favourite example is the "time-machine" monad, a counter-clock-wise State Monad proposed once by Wadler, and used by myself to implement the reverse automatic differentiation algorithm. Understanding what's going on is difficult. The <> syntax makes it *worse*.) Jerzy Karczmarczuk Caen, France From josefs@cs.chalmers.se Fri May 18 09:32:54 2001 From: josefs@cs.chalmers.se (Josef Svenningsson) Date: Fri, 18 May 2001 10:32:54 +0200 (MET DST) Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: John, On Thu, 17 May 2001, John Meacham wrote: [..] > namely that you don't necisarilly know all of the types of polymorphic > functions when they are in a module that is compiled seperately from the > rest of the program. the solution used by many C++ compilers is to > inline all polymorphic code in place (this is why templates are in > header files). there is no reason this won't work in haskell and give > back all of the speed benefits of base types everwhere (as it would in > this example) but has the unfortunate side effect of causing worst case > exponential code bloat as every function is re-written for every type > combination it is used with. > This is true in ML but not in Haskell. Haskell has polymorphic recursion which makes it impossible to predict statically at what types a function will be called. So trying to inline away polymorphism would lead to infinite unwindings. Cheers, /Josef From Colin.Runciman@cs.york.ac.uk Fri May 18 09:43:10 2001 From: Colin.Runciman@cs.york.ac.uk (Colin.Runciman@cs.york.ac.uk) Date: Fri, 18 May 2001 09:43:10 +0100 Subject: Questions about Trie Message-ID: <200105180843.JAA00498@pc179.cs.york.ac.uk> > Greeting, I'm a last year student in a computer science field. I'm > currently trying to code an implementation for a compression using basic > Lempel-zif technique. I use a Trie (retrieval) as a data structure for > the dynamic dictionary aplication. The problem is Trie uses not just an > ordinary binary tree, but it uses a multiple-weighted tree, where one > node has at most 256 children. Most literatures about Haskell show only > binary tree for the example in tree or Abstract Data Structures subject. > So, does anyone know how to code the implementation for trie. Thanks for > paying attention and I'm really hoping for the answer immediately. There is some relevant material in Chapter 6 (Text compression) of `Applications of Functional Programming', UCL Press, 1995. ISBN: 1-85728-377-5. (With apologies for self-reference, as co-editor of the book.) Colin R From lennart@mail.augustsson.net Fri May 18 10:02:58 2001 From: lennart@mail.augustsson.net (Lennart Augustsson) Date: Fri, 18 May 2001 11:02:58 +0200 Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library References: Message-ID: <3B04E542.76BA65A5@mail.augustsson.net> Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. This is true in theory, but in practice most polymorphism can be removed by inlining. I'm sure some pragmatic solution with limited inlining would work quite well. You'd still need to be able to handle polymorphism without inlining, of course, so you could cope with the exceptional cases. Mark Jones did some experiments with this kind of inlining that worked very well. -- Lennart From karczma@info.unicaen.fr Fri May 18 10:25:14 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Fri, 18 May 2001 11:25:14 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> Message-ID: <3B04EA7A.90D83CFB@info.unicaen.fr> Maestri, Primaballerine, I have a really provocative question. One of my student posed it, and I could not respond in a satisfactory manner, especially for myself it was really unsatisfactory. We know that a good part of "top-down" polymorphism (don't ask me what do I mean by that...) in C++ is emulated using templates. Always when somebody mentions templates in presence of a True Functionalist Sectarian, the reaction is "What!? Abomination!!". Now the question: WHY? Why so many people say "the C++ templates are *wrong*" (and at the same time so many people use it every day...) Is it absolutely senseless to make a functional language with templates? Or it is just out of fashion, and difficult to implement? == This is a sequel to a former discussion about macros, of course... Jerzy Karczmarczuk Caen, France From bjpop@cs.mu.OZ.AU Fri May 18 10:30:38 2001 From: bjpop@cs.mu.OZ.AU (Bernard James POPE) Date: Fri, 18 May 2001 19:30:38 +1000 (EST) Subject: Monomorphize, was: Re: Proposal for generalized function partitionin List-library In-Reply-To: <3B04E542.76BA65A5@mail.augustsson.net> from Lennart Augustsson at "May 18, 2001 11:02:58 am" Message-ID: <200105180930.TAA25290@mulga.cs.mu.OZ.AU> Lennart wrote: > This is true in theory, but in practice most polymorphism can be removed > by inlining. I'm sure some pragmatic solution with limited inlining would > work quite well. You'd still need to be able to handle polymorphism without > inlining, of course, so you could cope with the exceptional cases. > > Mark Jones did some experiments with this kind of inlining that worked very well. > > -- Lennart The MLton compiler (http://www.clairv.com/MLton/) uses whole program compilation and monomorphises ML code (again they do not have to deal with potential polymorhpic recursion, but as Lennart says, it can be treated as a special case in Haskell). I have never used it though, so I can't vouch for its performance. They are motivated to use unboxed representations and so on. The danger with whole program compilation is long compile times. But it might be possible to allow separate compilation for development and put up with the overheads of boxed representations and so on, but get the benefits of the optimisations flowing from whole program compilation when needed (ie released binaries). Sounds like a lot of work to me though. Bernie. From simonpj@microsoft.com Fri May 18 08:28:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 18 May 2001 00:28:50 -0700 Subject: Questions about Trie Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F50@red-msg-09.redmond.corp.microsoft.com> Perhaps this monads discussion might move to haskell-cafe@haskell.org? It's a good discussion, but it's just what haskell-cafe is for. http://www.haskell.org/mailinglist.html Simon | -----Original Message----- | From: Arthur H. Gold [mailto:agold@bga.com]=20 | Sent: 17 May 2001 22:21 | To: haskell@haskell.org | Cc: M. Faisal Fariduddin Attar Nasution | Subject: Re: Questions about Trie |=20 |=20 | > "M. Faisal Fariduddin Attar Nasution" wrote: | >=20 | > Greeting, I'm a last year student in a computer science=20 | field. I'm=20 | > currently trying to code an implementation for a =20 | compression using=20 | > basic Lempel-zif technique. I use a Trie (retrieval)=20 | as a data=20 | > structure for the dynamic dictionary aplication. The=20 | problem is Trie=20 | > uses not just an ordinary binary tree, but it uses a=20 | multiple-weighted=20 | > tree, where one node has at most 256 children. Most=20 | literatures about=20 | > Haskell show only binary tree for the example in tree or=20 | Abstract Data | > Structures subject. So, does anyone know how to =20 | code the | > implementation for trie. Thanks for paying attention and=20 | I'm really=20 | > hoping for the answer immediately. | >=20 |=20 | IIRC, there's a trie implementation in Chris Okasaki's=20 | "Purely Functional Data Structures" -- that might be a start=20 | (there's also his "Edison" library, which contains many of=20 | the components you'd need). |=20 | HTH (and sorry if it doesn't) | --ag |=20 | --=20 | Artie Gold, Austin, TX (finger the cs.utexas.edu account for=20 | more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu | -- | I am looking for work. Contact me. |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From tweed@compsci.bristol.ac.uk Fri May 18 11:22:36 2001 From: tweed@compsci.bristol.ac.uk (D. Tweed) Date: Fri, 18 May 2001 11:22:36 +0100 (BST) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: (This response comes from the context of someone who like FP but has a day job writing in C++.) On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. Umm... what do you mean by `top down'? The two senses in which I use polymorphism in C++ are: (i) using super classes (in the sence that A is a superclass of B is B inherits from A) to perform operations that only make sense for objects of the semantic type A. My canonical example is working with quadtree nodes, where a there are various types nodes which can hold different kinds of data but the base class qnode holds things like position, etc. (ii) using templates to write generic algorithms which either don't depend on the object type at all (e.g., vectors, lists, etc) or which depend on one or two conceptual operations which are very elementary (e.g., meaningful equality, addition or a `display yourself on stdout' function). In C++ these could _almost_ be done using superclasses but with problems because (A) the standard types (e.g., int) can't have their place in the class hierarchy redefined (e.g., int inherits from debug_show) (B) deep hierarchies are really not handled well by debuggers and it'd be a real pain trying to look at the C++ equivalent of the haskell `data A = ... deriving (Show,Ord,Monad,...)' The almost that I referred to above comes from the fact that (AFAIK) without using something nasty like RTTI you can't create new objects of the true type in a function to which you've passed a pointer to the base class. That's the conceptual overview. In terms of pragmatics __at least for my work in image processing__ I don't write classes that much, seldom use inheritance and I'm 99% sure I don't have any inheritance more than 1 level deep. On the other hand I write a lot of templated code which would be equivalent in haskell to either f :: a -> b -> .... -> a or f :: Eq a => a -> b -> ... -> a (i.e., algorithms that need just one or two low-level ideas such as equality). I much prefer the Haskell way of doing this with superclasses but I just don't feel brave enough to attempt the levels of class hierarchy that this implies in C++. (In some ways this is a shame since, because in template function names member functions used are only matched syntactically -- as there's no superclass to ensure semantic equivalence -- I've made one or two mistakes when I forgot a member function with the same name actually meant something different.) > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) In my experience the C++ idiom `you only pay for what you use' (==> templates are essentially type-checked macros) and the fact most compilers are evolved from C compilers makes working with templates a real pain in practice. Additionally, I think a lot of people who dislike them are old-time C hackers who don't see why it isn't good enough to do polymorphism via void*'s and function pointers. As to why I at least use it, it lets me write polymorphic functions without needing deep class hierarchies (which as noted above aren't nice in C++) or going into the error prone mire of the void* approach. > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? I may be missing something obvious, but given Haskell's well thought out (IMO) prelude class structure and the fact that deep class hierarchies with `multiple inheritance' aren't a problem in Haskell, I don't see that it would buy you anything in Haskell. On the other hand, if the standard prelude didn't have the class hierarchy I think they would be much more useful. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. From heringto@cs.unc.edu Fri May 18 15:30:38 2001 From: heringto@cs.unc.edu (Dean Herington) Date: Fri, 18 May 2001 10:30:38 -0400 Subject: MVar Problem (Concurrent Hugs) References: Message-ID: <3B05320E.6FE477AA@cs.unc.edu> Andreas Gruenbacher wrote: > Hello, > > I was trying to write an abstraction for bidirectional communication > between two threads. For some reason, MVars seem to break: > > ----------------------------------------------- > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > > data Cord t u = Cord (IO (MVar t)) (IO (MVar u)) > > instance Cords Cord t u where > newCord = return (Cord newEmptyMVar newEmptyMVar) > speak (Cord _ s) t = do s' <- s ; putMVar s' t > listen (Cord h s) = do h' <- h ; takeMVar h' > > otherEnd (Cord t u) = Cord u t > > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStr ("Said " ++ (show x)) > showT cord > > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str > ----------------------------------------------- You are creating a new MVar with each listen and speak. As a result, the two threads never agree on an MVar, so deadlock occurs. Instead, you should create the pair of MVars in newCord. Try the code below. > import Concurrent > class Cords c t u where > newCord :: IO (c t u) > listen :: c t u -> IO t > speak :: c t u -> u -> IO () > data Cord t u = Cord (MVar t) (MVar u) > instance Cords Cord t u where > newCord = do t <- newEmptyMVar > u <- newEmptyMVar > return (Cord t u) > listen (Cord t _) = takeMVar t > speak (Cord _ u) s = putMVar u s > otherEnd (Cord t u) = Cord u t > showT :: Cord Int String -> IO () > showT cord = do > putStrLn "Runnning..." > x <- listen cord > putStrLn ("Heard " ++ show x) > speak cord (show x) > putStrLn ("Said " ++ show x) > showT cord > main :: IO () > main = do > cord <- newCord > forkIO (showT (otherEnd cord)) > speak cord 1 > str <- listen cord > putStrLn str Dean From gruenbacher-lists@geoinfo.tuwien.ac.at Fri May 18 16:54:49 2001 From: gruenbacher-lists@geoinfo.tuwien.ac.at (Andreas Gruenbacher) Date: Fri, 18 May 2001 17:54:49 +0200 (CEST) Subject: MVar Problem (Concurrent Hugs) In-Reply-To: <3B05320E.6FE477AA@cs.unc.edu> Message-ID: On Fri, 18 May 2001, Dean Herington wrote: > You are creating a new MVar with each listen and speak. As a result, the > two threads never agree on an MVar, so deadlock occurs. Instead, you should > create the pair of MVars in newCord. Try the code below. > > [...] Thanks, this works. Thanks! --Andreas. From ger@tzi.de Fri May 18 17:22:07 2001 From: ger@tzi.de (George Russell) Date: Fri, 18 May 2001 18:22:07 +0200 Subject: Templates in FPL? Message-ID: <3B054C2F.C1BBE335@tzi.de> The MLj compiler from ML to the Java Virtual Machine (which is being actively worked on by the geniuses at Microsoft as we speak) expands out all polymorphism. I helped develop this compiler and I believe this approach to be a good one. There are particular reasons why it's good for this case (1) as has been said before, ML does not have polymorphic recursion; (2) the cost of object creation in Java used at least to be horrendous, so it was well worth working hard to get rid of it. However I think long term it's a good idea for normal Haskell compilers because my guess is you will Win Big on quite a lot of things, because you don't have to carry around and use dictionaries (for method lookup in class instances) and can do a lot more specialisation and inlining. Strict values can also be unboxed. Of course you can control specialisation used unboxed values already in Glasgow Haskell, but it requires special annotations or special types. The minus points are thuswise, so far as I know: (1) the compiled code is bigger. This means the code might indeed run more slowly. But with MLj I think we found that in normal cases it isn't THAT much bigger (maybe about 50%), because the functions which get specialised a lot (like "length" and "map") tend to be pretty small. Of course you can construct artificial cases where the code size will explode. (2) It takes much longer to compile. I'm waiting for Moore's law here, but at present I would be surprised if (say) Glasgow Haskell could compile itself inlining out all polymorphism, without it taking a very long time or a very fast computer or lots of nasty imperative optimisations. (3) You can't inline everything, because of polymorphic recursion, and also because it would be nice to allow Haskell code to be dynamically linked in (see GHCi). Or you can inline everything, but then you need to implement a Haskell Virtual Machine which does the inlining (and the whole compiler backend) on demand at runtime. I don't think you have to inline everything; it should surely be possible to leave polymorphic versions of the functions around, to use for hard cases. From msk@post.tepkom.ru Fri May 18 17:33:46 2001 From: msk@post.tepkom.ru (Anton Moscal) Date: Fri, 18 May 2001 20:33:46 +0400 (MSD) Subject: Templates in FPL? In-Reply-To: <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: On Fri, 18 May 2001, Jerzy Karczmarczuk wrote: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? ordinary FP polymorphish is as strict analogue of the C++ template-functions Haskell type clasess is as close analog for the C++ template classes (studing of the Haskell type classes clarify to me many aspects of the C++ classes templates semantic). Regards, Anton From ken@digitas.harvard.edu Fri May 18 20:08:47 2001 From: ken@digitas.harvard.edu (Ken Shan) Date: Fri, 18 May 2001 15:08:47 -0400 Subject: Monads In-Reply-To: <3B04C7B9.D14AA827@info.unicaen.fr>; from karczma@info.unicaen.fr on Fri, May 18, 2001 at 08:56:57AM +0200 References: <20010517084750.23684.qmail@web14308.mail.yahoo.com> <4.3.0.20010517105145.00b48a60@pop.students.cs.uu.nl> <20010517181811.C14548@rz.uni-karlsruhe.de> <3B04C7B9.D14AA827@info.unicaen.fr> Message-ID: <20010518150847.A6077@digitas.harvard.edu> --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2001-05-18T08:56:57+0200, Jerzy Karczmarczuk wrote: > The examples are already in the Wadler's "Essence". Imagine the=20 > construction of a small interpreter, a virtual machine which not only > evaluates the expressions (belonging to a trivial Monad), but perform > some side effects, or provides for exceptions propagated through a > chain of Maybes. Then the idea is to >=20 > * base the machine on the appropriate Monad > * "lift" all standard operators so that an innocent user can write (f x) > and never x >>=3D f (or even worse). Perhaps you already know about Filinski's PhD thesis? He seems to have proven that we already have the "small interpreter" you want, inside of any programming language that supports call/cc and storing a function in a single storage cell. ML is such a programming language. You can define your own monads yet rely on implicit evaluation ordering in ML to do the lifting you want! --=20 Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Learn Esperanto and make friends around the world http://www.esperanto.net --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7BXM/zjAc4f+uuBURAtYcAKCafrEuesrlWUObVdidMDJf5VCzwACfcAQb 9vI2sHi/yei+T2JVHxC/sZE= =fDKP -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From qrczak@knm.org.pl Fri May 18 20:11:21 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 19:11:21 GMT Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Fri, 18 May 2001 11:25:14 +0200, Jerzy Karczmarczuk pisze: > Always when somebody mentions templates in presence of a True > Functionalist Sectarian, the reaction is "What!? Abomination!!". They aren't that wrong, but they have some problems: * It's not specified what interface they require from types to be instantiated to. * The whole implementation must be present in a public header file. Well, there is the 'export' keyword, but no compiler implements it. It follows that all things used by implementation of a template must be included too. And compilation time of a large project is larger than necessary. * They introduce very complex rules about name lookup (environment in which a specialized template is compiled is a weird mix of environments of the point of definition and point of usage of the template), deduction which overloading to use (with choosing the candidate according to partial ordering of better fitting), deduction of template types and what partial specialization to use, complicated by the fact that there are complex rules of implicit conversions. Templates don't obey a Haskell's rule that adding code doesn't change the meaning of previously valid code and can at most introduce an ambiguity which is flagged as error. * Types can't be deduced from the context of usage. For example handling the empty set or monadic 'return' would require either spelling the type at each use or introducing another type and deferring deduction of the real type until an operation is performed with a value of a known type. * Since they are similar to macros, they tend to give horrible error messages which mentions things after expansion. Here is what I once got: mico-c++ -Wall -I. -c serwer.cc -o serwer.o serwer.cc: In method `void Firma_impl::usun(const char *)': serwer.cc:92: `struct __rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *>' has no member named `second' serwer.cc:93: no matching function for call to `map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase (__rb_tree_iterator,__default_alloc_template >,Katalog *>,const pair,__default_alloc_template >,Katalog *> &,const pair,__default_alloc_template >,Katalog *> *> &)' /usr/include/g++/stl_map.h:156: candidates are: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>) /usr/include/g++/stl_map.h:157: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(const string &) /usr/include/g++/stl_map.h:158: map,__default_alloc_template >,Katalog *,less,__default_alloc_template > >,__default_alloc_template >::erase,__default_alloc_template > >, alloc>(__rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair,__default_alloc_template >,Katalog *> *>, __rb_tree_iterator,__default_alloc_template >,Katalog *>,pair,__default_alloc_template >,Katalog *> &,pair, __default_alloc_template >,Katalog *> *>) make: *** [serwer.o] Error 1 They also have some advantages over mechanisms available in Haskell: * A templatized class can contain types, values with arbitrary types, other templates etc. so it's easy to have parametrization of all things by types. Haskell requires fundeps, dummy arguments and local quantifiers to handle these things - sometimes it's not nice. * A template can be parametrized by values of primitive types (by expressions using builtin operations which can be evaluated at compile time). Yes, it's ugly that types and operations don't have equal rights, but it's sometimes useful. * A template is in practice guaranteed to be specialized to used types, so they don't have a performance overheads over non-templatized variants. My not-quite-done-right attempt at inlining dictionary functions in ghc is a step in this direction, as is the proposal of export-unfolding-and-specialize-but-not-necessarily-inline. I hope that SimonPJ will sort this out. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From john@repetae.net Fri May 18 20:32:11 2001 From: john@repetae.net (John Meacham) Date: Fri, 18 May 2001 12:32:11 -0700 Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library In-Reply-To: ; from josefs@cs.chalmers.se on Fri, May 18, 2001 at 10:32:54AM +0200 References: <20010517114250.D13591@mark.ugcs.caltech.edu> Message-ID: <20010518123211.E13591@mark.ugcs.caltech.edu> this is interesting, could someone give an example of how polymorphic recursion would disallow specialization of a function? i mean, it seems to me that even if you had recursion, you still have to actually call the function at some point with some real type and at that point you can decide whether to use the specialized version or not. One of the main things i was hopeing was that the seperate 'generic' and 'concrete' functions in the Prelude could be dumped for just the generic ones. the compiler should be able to optimize for the common cases of Nums being Ints and whatnot. (with the help of some pragma annotations.) -John On Fri, May 18, 2001 at 10:32:54AM +0200, Josef Svenningsson wrote: > John, > > On Thu, 17 May 2001, John Meacham wrote: > > [..] > > namely that you don't necisarilly know all of the types of polymorphic > > functions when they are in a module that is compiled seperately from the > > rest of the program. the solution used by many C++ compilers is to > > inline all polymorphic code in place (this is why templates are in > > header files). there is no reason this won't work in haskell and give > > back all of the speed benefits of base types everwhere (as it would in > > this example) but has the unfortunate side effect of causing worst case > > exponential code bloat as every function is re-written for every type > > combination it is used with. > > > This is true in ML but not in Haskell. Haskell has polymorphic recursion > which makes it impossible to predict statically at what types a function > will be called. So trying to inline away polymorphism would lead to > infinite unwindings. > > Cheers, > /Josef -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From mg169780@students.mimuw.edu.pl Fri May 18 22:10:54 2001 From: mg169780@students.mimuw.edu.pl (Michal Gajda) Date: Fri, 18 May 2001 23:10:54 +0200 (CEST) Subject: Templates in FPL? In-Reply-To: <3B054C2F.C1BBE335@tzi.de> Message-ID: On Fri, 18 May 2001, George Russell wrote: > The minus points are thuswise, so far as I know: > (1) the compiled code is bigger. (...) > (2) It takes much longer to compile. (...) As it is very aggressive optimization, I strongly suggest explicit(non-default) compiler switch Greetings :-) Michal Gajda korek@icm.edu.pl From qrczak@knm.org.pl Fri May 18 21:44:52 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 18 May 2001 20:44:52 GMT Subject: Monomorphize, was: Re: Proposal for generalized function partition in List-library References: <20010517114250.D13591@mark.ugcs.caltech.edu> <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > this is interesting, could someone give an example of how polymorphic > recursion would disallow specialization of a function? test:: Show a => a -> [String] test x = show x : test [x] -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From Jan de Wit" <20010518123211.E13591@mark.ugcs.caltech.edu> Message-ID: <002a01c0e076$6029f8a0$9505c5d5@yatima> From: "Marcin 'Qrczak' Kowalczyk" > Fri, 18 May 2001 12:32:11 -0700, John Meacham pisze: > > > this is interesting, could someone give an example of how polymorphic > > recursion would disallow specialization of a function? > > test:: Show a => a -> [String] > test x = show x : test [x] Another source of programs needing polymorphic recursion are non-regular datatypes, which occur frequently in Chris Okasaki's _Purely_Functional_Data_Structures_. A bare-bones example is: | data Perfect a = One a | Two (Perfect (a,a)) | deriving Show | | mkPerfect :: Int -> a -> Perfect a | mkPerfect 1 x = One x | mkPerfect (n+1) x = Two (mkPerfect n (x,x)) mkPerfect will be called with a number of different types for its second argument, depending on the first argument. HTH, Jan de Wit From luc.taesch@csfb.com Mon May 21 12:48:22 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Mon, 21 May 2001 13:48:22 +0200 Subject: PP with HaXml 1.02 Message-ID: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Im proceeding with basic exploratory tests witrh HaXml (1.02, winhugs feb 2001) the pretty print return the closing < on the next line, like what am i doing wrong ? ( the call is like import qualified XmlPP as PP ... main = do content <- readFile "subjdb.xml" (putStrLn . render . PP.document . parse) content (btw, thanks malcolm for packaging a specific hugs distribution) This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ketil@ii.uib.no Mon May 21 13:48:36 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 21 May 2001 14:48:36 +0200 Subject: PP with HaXml 1.02 In-Reply-To: "Taesch, Luc"'s message of "Mon, 21 May 2001 13:48:22 +0200" References: <9818339E731AD311AE5C00902715779C0371A76D@szrh00313.tszrh.csfb.com> Message-ID: "Taesch, Luc" writes: > the pretty print return the closing < on the next line, like > > > where i expect > > > My guess is that HaXML doesn't validate (using the DTD) or simply ignores it for pretty printing purposes. If the "Person-XML" element were defined to hold #PCDATA as well as (a) "Name" element(s), the two examples above are not equivalent, since you've added white space characters to the contents. Adding whitespace within the tag is okay, though, since it doesn't change the semantics of the document. > This message is for the named person's use only. It may contain [...] (Jeez! Has CSFB hear of mailing lists?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants From taha@cs.yale.edu Mon May 21 16:17:26 2001 From: taha@cs.yale.edu (Walid Taha) Date: Mon, 21 May 2001 11:17:26 -0400 (EDT) Subject: SAIG'01 Extended Deadline In-Reply-To: References: Message-ID: CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (EXTENDED DEADLINE: June 1st, 2001) Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and system= s address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice= =2E The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) I= n addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by June 1st, 2001. This extended deadline is final. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha,Yale (PC Chair) URL: http://cs-www.cs.yale.edu/homes/taha/saig/cfp01.html From taha@cs.yale.edu Mon May 21 16:17:26 2001 From: taha@cs.yale.edu (Walid Taha) Date: Mon, 21 May 2001 11:17:26 -0400 Subject: SAIG'01 Extended Deadline In-Reply-To: References: Message-ID: CALL FOR PAPERS Semantics, Applications and Implementation of Program Generation (SAIG'01) PLI Workshop, September 6th, 2001. (EXTENDED DEADLINE: June 1st, 2001) Program generation has the prospect of being an integral part of a wide range of software development processes. Many recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and system= s address both high-level (source) language and low-level (machine) language generation. A number of programming languages now supports program generation and manipulation, with different goals, implementation techniques, and targeted at different applications. The goal of this workshop is to provide a meeting place for researchers and practitioners interested in this research area, and in program generation in general. Scope: The workshop solicits submissions related to theoretical and practical models and tools for building program generators systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Program synthesis from high-level specifications. * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice= =2E The program committee is happy to advise on the appropriateness of a particular subject. Format: The one-day workshop will contain slots for technical papers (30 minutes) and position papers (20 minutes. Both times include discussion.) I= n addition, there will be one hour allocated for open discussions at the end of the workshop. Proceedings will be published as an LNCS volume. Invited Speakers: * Krzysztof Czarnecki, University of Ilmenau and Daimler Chrysler * Tim Sheard, Oregon Graduate Institute of Science and Technology * Mitch Wand, Northeastern University Submission Details: Authors are invited to submit papers of at most 5000 words (excluding figures), in postscript format (letter or A4), using the electronic submission form by June 1st, 2001. This extended deadline is final. Both position and technical papers are welcome. Please indicate at time of submission. Position papers are expected to describe ongoing work, future directions, and/or survey previous results. Technical papers are expected to contain novel results. All papers will be reviewed by the program committee for the above mentioned criteria, in addition to correctness and clarity. Authors will be notified of acceptance by June 17th, 2001. Final version of the papers must be submitted by July 15th, 2001. Program Committee: * Gilles Barthe, INRIA * David Basin, Freiburg * Don Batory, Texas * Robert Gl=FCck, DIKU * Nevin Heintze, Bell-Labs * Eugenio Moggi, DISI * Greg Morrisett, Cornell * Flemming Nielson, Aarhus * David Sands, Chalmers * Walid Taha,Yale (PC Chair) URL: http://cs-www.cs.yale.edu/homes/taha/saig/cfp01.html From Malcolm.Wallace@cs.york.ac.uk Mon May 21 19:01:01 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Mon, 21 May 2001 19:01:01 +0100 Subject: ANNOUNCE: nhc98 1.04 and Hat 1.04 Message-ID: We are pleased to announce a new release of the nhc98 compiler, and in particular its facilities (both brand new and improved old stuff) for tracing and debugging Haskell programs - the Hat system. The basic nhc98 compiler version 1.04 is mostly a bugfix release (details listed at the bottom of this announcement). http://www.cs.york.ac.uk/fp/nhc98/ However, the stuff we are really excited about is Hat - our Haskell tracer. A full user guide to these new tools is available on the website. http://www.cs.york.ac.uk/fp/hat/ Hat 1.04 ======== * Lots more tools for tracing! hat-stack - Displays a "virtual" stack-trace for any program that failed with a runtime error. hat-detect - Algorithmic bug detection, based on a textual question-and-answer session. hat-trail - The original graphical trail browser, now with several presentation enhancements. hat-observe - Examine the inputs and outputs of any named function, in the style of HOOD. * Tracing with Hat is now based on a completely new architecture (although still within the nhc98 compilation system). A program compiled for tracing now builds its "redex trails" in file, not in the heap. This has some performance consequences: (1) you no longer need to allocate large amounts of heap memory for tracing; (2) but you will probably need large amounts of disk space instead - remember disk space is cheap; (3) and traced programs still run somewhat slowly. * However, there are a couple of major benefits in return: (1) A trace is persistent, so after running your program once, you can examine many different aspects of the trace without re-computation. (2) Traces are now first-class objects, so you can examine and manipulate them in far more detail - hence the variety of new tracing tools. * Greater Haskell'98 compatibility. Almost all language features are now supported: named fields and better handling of pattern bindings are the main additions. All standard libraries except Time and Locale are now supported. nhc98 1.04 ========== * New: Improved (more accurate) time profiling now provided. * New: Support for extended module namespaces of the form Long.Hierarchical.Module.Name is now provided in both nhc98 and hmake. * Bugfix: An identifier hidden on import and redefined in the current module, then exported, but also imported qualified and used qualified in the current module, led to an incorrect interface file being generated. * Bugfix: hmake issued an unnecessary -cpp flag on some literate files. * Bugfix: Type of IO.hSetPosn :: Handle -> HandlePosn -> IO () was incorrect. * Bugfix: Compile-time error in src/tracer/runtime/ident.c on RedHat 7 and other systems using the new ISO C standard for fpos_t. * Bugfix: A file opened in ReadMode or WriteMode was actually opened in ReadWriteMode, so if the file had strict permissions the correct opening command would fail. Conversely, opening in ReadWriteMode actually gave ReadMode instead, and file updates silently failed. * Bugfix: Operator sections suffered from priority inversion, for example (^2*3) was incorrectly parsed as (^(2*3)), even though ^ binds more tightly than *. * Bugfix: The library function Directory.createDirectory gave strange permissions to the new directory. (Mode was in hex, but should have been octal!) * New: Improved printing of I/O error messages. Happy tracing! The Hat team at York (Colin Runciman, Olaf Chitil, Malcolm Wallace, Thorsten Brehm, Phil Hassall) From mikg@free.fr Mon May 21 19:51:37 2001 From: mikg@free.fr (=?iso-8859-1?Q?Micka=EBl_GAUTIER?=) Date: Mon, 21 May 2001 20:51:37 +0200 Subject: Problem to load the file Stack.hs with Hugs98 Message-ID: <00c901c0e227$74411c80$3406e4d5@machinegun> This is a multi-part message in MIME format. ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to use the file stack.hs wich is provided with Hugs 98 but = the following message errors display: "Haskell98 does not support restricted type synonyms" Can you explain me why and how I can load stack.hs ? Thanks in advance ------=_NextPart_000_00BA_01C0E237.D4539520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to use the file stack.hs wich is = provided=20 with Hugs 98 but the following message errors display: "Haskell98 does not support restricted type=20 synonyms" Can you explain me why and how I can load stack.hs=20 ? Thanks in advance ------=_NextPart_000_00BA_01C0E237.D4539520-- From qrczak@knm.org.pl Mon May 21 21:30:44 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 21 May 2001 20:30:44 GMT Subject: Problem to load the file Stack.hs with Hugs98 References: <00c901c0e227$74411c80$3406e4d5@machinegun> Message-ID: Mon, 21 May 2001 20:51:37 +0200, Mickaël GAUTIER pisze: > I would like to use the file stack.hs wich is provided with Hugs 98 but > the following message errors display: > "Haskell98 does not support restricted type synonyms" > Can you explain me why and how I can load stack.hs ? hugs -98 Stack.hs This command line flag enables non-Haskell-98 extensions. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From davidbak@microsoft.com Tue May 22 02:23:31 2001 From: davidbak@microsoft.com (David Bakin) Date: Mon, 21 May 2001 18:23:31 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm having trouble understanding recursive types (e.g., as described in Functional Programming with Overloading and Higher-Order Polymorphism by Jones. =20 He gives as an example =20 =20 > data Mu f =3D In (f (Mu f)) =20 > data NatF s =3D Zero | Succ s > type Nat =3D Mu NatF =20 Among the things I don't get are: =20 1. Comparing this to the non-higher-order type: =20 > data NatX =3D Zero | Succ NatX =20 What are the advantages of the higher-order type? What are the disadvantages (incl. runtime costs)? =20 2. How are values of type Nat represented? (It helps me to think about these things concretely.) =20 Thanks! -- Dave =20 =20 ------_=_NextPart_001_01C0E25D.CFC0BA65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm = having trouble=20 understanding recursive types (e.g., as described in Functional = Programming=20 with Overloading and Higher-Order Polymorphism by=20 Jones. He = gives as an=20 example > = data Mu f =3D In=20 (f (Mu f)) > = data NatF s =3D=20 Zero | Succ s > = type Nat =3D Mu=20 NatF Among = the things I=20 don't get are: 1. Comparing=20 this to the non-higher-order type: > = data NatX =3D=20 Zero | Succ NatX What = are the=20 advantages of the higher-order type? What are the disadvantages = (incl.=20 runtime costs)? 2. How are=20 values of type Nat represented? (It helps me to think about these things = concretely.) Thanks! --=20 Dave ------_=_NextPart_001_01C0E25D.CFC0BA65-- From Tom.Pledger@peace.com Tue May 22 03:24:55 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Tue, 22 May 2001 14:24:55 +1200 Subject: Recursive types? In-Reply-To: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> Message-ID: <15113.52727.506242.598828@waytogo.peace.co.nz> David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | | He gives as an example | | | > data Mu f = In (f (Mu f)) | | > data NatF s = Zero | Succ s | > type Nat = Mu NatF | | Among the things I don't get are: | | 1. Comparing this to the non-higher-order type: | | > data NatX = Zero | Succ NatX | | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e = c k (Tree c k e) -- Contained Tree, container, key, element data Tree c k e = Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t = Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom From luc.taesch@csfb.com Tue May 22 11:19:01 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Tue, 22 May 2001 12:19:01 +0200 Subject: using haxml dynamically Message-ID: <9818339E731AD311AE5C00902715779C0371A779@szrh00313.tszrh.csfb.com> How can i use HaXml to produce xml, but in a dynamic way? i mean : 1) what i understand from the example is - u have a type H in haskell - u derive (manally or with drift) an instance Haskell2xml out of it (defines tocontenst, from contents) - u use it, say with to xml, from xml 2) id like to generate an xml structure computed from some schema works, which means that the structure will be build "dynamically" at run time, ie I wont build the structure from an haskell type, not wont i have an haskell2xml instance at hand. (and i dont want to generate an intermediate haskell file and load/compile it) are there a way to create/fill/describe an xml structure "dynamically", ie as a result of some computation (with haxml, i mean) ? a bit like the example 4 from the paper , fixed with the recent names ? This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From ltaesch@europemail.com Tue May 22 22:25:05 2001 From: ltaesch@europemail.com (luc) Date: Tue, 22 May 2001 21:25:05 +0000 Subject: BAL paper available >> graphic libraries References: <3B015A65.C87801F5@info.unicaen.fr> <20010515211402.B24804@math.harvard.edu> <3B03748C.D65FDD19@info.unicaen.fr> <15107.31057.395890.996366@tcc2> Message-ID: <3B0AD931.190DCF22@europemail.com> Timothy Docker wrote: for info, there is a gui lib on top of sdl (then portable to linux, win) at http://www.bms-austria.com/projects/paragui/ > Jerzy Karczmarczuk writes: > > [Some interesting points on functional wrappings of graphics libraries] > > Has anyone considered writing a haskell wrapper for SDL - Simple > Directmedia Layer at http://www.libsdl.org ? > > This is a cross platform library intended for writing games, and aims > for a high performance, low level API. It would be interesting to see > how clean a functional API could be built around such an imperative > framework. > > Tim > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From davidbak@microsoft.com Tue May 22 21:16:15 2001 From: davidbak@microsoft.com (David Bakin) Date: Tue, 22 May 2001 13:16:15 -0700 Subject: Recursive types? Message-ID: <6605DE4621E5934593474F620A14D700190C19@red-msg-07.redmond.corp.microsoft.com> Thank you. Now, on seeing your Tree example I tried to use it by defining height using structural recursion. But I couldn't find a valid syntax to pattern match - or otherwise define the function - on the type CT. Is there one? Or, maybe, are constructor classes the only way to use these types? If that's the case - is that inherent in these types or just the way Haskell does it? Because I was thinking that although you don't know much about these types (e.g., the operations you can perform on k) you should be able to compute height (& size) and leaves :: Tree c k e -> [e] and even replMin on the information that's there in the type. -- Dave -----Original Message----- From: Tom Pledger [mailto:Tom.Pledger@peace.com] Sent: Monday, May 21, 2001 7:25 PM To: haskell@haskell.org Subject: Recursive types? David Bakin writes: | I'm having trouble understanding recursive types (e.g., as described in | Functional Programming with Overloading and Higher-Order Polymorphism by | Jones. | =20 | He gives as an example | =20 | =20 | > data Mu f =3D In (f (Mu f)) | =20 | > data NatF s =3D Zero | Succ s | > type Nat =3D Mu NatF | =20 | Among the things I don't get are: | =20 | 1. Comparing this to the non-higher-order type: | =20 | > data NatX =3D Zero | Succ NatX | =20 | What are the advantages of the higher-order type? What are the | disadvantages (incl. runtime costs)? | =20 | 2. How are values of type Nat represented? (It helps me to think about | these things concretely.) _|_ In _|_ In Zero In (Succ _|_) In (Succ (In _|_)) In (Succ (In Zero)) In (Succ (In (Succ _|_))) In (Succ (In (Succ (In _|_)))) In (Succ (In (Succ (In Zero)))) and so on. If you never care about distinguishing In _|_ from _|_, you can save space and time by declaring `newtype Mu ...' instead of `data Mu ...', in which case Nat's run-time representation is the same size as NatX's. One advantage of such higher-order types is reusability. For example, this type CT c k e =3D c k (Tree c k e) -- Contained Tree, container, key, = element data Tree c k e =3D Empty | Node (CT c k e) e (CT c k e) can be used with no frills newtype Plain k t =3D Plain t ... :: Tree Plain () e or with every subtree labelled ... :: Tree (,) String e or with every subtree inside the ST monad import ST ... :: Tree STRef s e etc. I don't know whether this is a shining example of an advantage, and am keen to see other comments. Regards, Tom _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From bhalchin@hotmail.com Tue May 22 22:08:56 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Tue, 22 May 2001 21:08:56 Subject: Haskell & .NET CLR Message-ID: Hello, Are any of the various Haskell implm., e.g. ghc, being targeted for the .NET CLR? Also can anybody point in the direction of any projects to implement the .NET CLR on anything other than Win32 platforms, e.g. that evil Free Software Foundation :^)?? Let's make .NET open source! hehehehhee Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ndalton@ics.uci.edu Tue May 22 22:14:29 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 14:14:29 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: Hi, > Are any of the various Haskell implm., e.g. ghc, being > targeted for the .NET CLR? There is a beta haskell compiler, based on ghc-4.08.1 I believe, at http://www.mondrian-script.org/ I haven't used it, so I can't comment further. > Also can anybody point in the > direction of any projects to implement the .NET CLR on anything > other than Win32 platforms I haven't seen any public projects like that. Would be interesting though.. Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From cwitty@newtonlabs.com Wed May 23 01:19:50 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 17:19:50 -0700 Subject: Templates in FPL? In-Reply-To: "D. Tweed"'s message of "Fri, 18 May 2001 11:22:36 +0100 (BST)" References: Message-ID: "D. Tweed" writes: > In my experience the C++ idiom `you only pay for what you use' (==> > templates are essentially type-checked macros) and the fact most compilers > are evolved from C compilers makes working with templates a real pain in > practice. I'm not sure what you mean by type-checked here. Templates are not type-checked at definition time, but are type-checked when they are used; the same is true of ordinary macros. Carl Witty From trd@cs.mu.OZ.AU Wed May 23 01:22:38 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Wed, 23 May 2001 10:22:38 +1000 Subject: Haskell & .NET CLR In-Reply-To: ; from ndalton@ics.uci.edu on Tue, May 22, 2001 at 02:14:29PM -0700 References: Message-ID: <20010523102238.A2949@cs.mu.oz.au> > > Also can anybody point in the > > direction of any projects to implement the .NET CLR on anything > > other than Win32 platforms > I haven't seen any public projects like that. Would be > interesting though.. Well, there is: http://www.southern-storm.com.au/ Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working on a C# compiler. See: http://primates.helixcode.com/~miguel/activity-log.html Finally, there was recently an article in Linux Magazine (??? not Linux Journal) about targetting gcc at the .NET CLR. I'm afraid I have no information more than that, since I don't think I can get the magazine in Australia. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From cwitty@newtonlabs.com Wed May 23 02:25:15 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 May 2001 18:25:15 -0700 Subject: Templates in FPL? In-Reply-To: Jerzy Karczmarczuk's message of "Fri, 18 May 2001 11:25:14 +0200" References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: Jerzy Karczmarczuk writes: > We know that a good part of "top-down" polymorphism (don't ask me what > do I mean by that...) in C++ is emulated using templates. > > Always when somebody mentions templates in presence of a True Functionalist > Sectarian, the reaction is "What!? Abomination!!". > > Now the question: WHY? > > Why so many people say "the C++ templates are *wrong*" (and at the same time > so many people use it every day...) I agree with Marcin about the bad points of templates. (I'd like to point out, though, that the idea that "adding new code can't change the meaning of a program" no longer holds in Haskell extended with overlapping type classes.) > Is it absolutely senseless to make a functional language with templates? > Or it is just out of fashion, and difficult to implement? There are some very cool things about C++ templates; they are more powerful than you might suspect. (Note: the following summarizes and paraphrases several papers I've read on the topic; let me know if you want more information and I'll look up references for you.) Basically, templates let you extend the compiler. You get a primitive functional programming language, with which you can do basically arbitrary computations on types and on integers; this language can be used to generate special-purpose code. One way to look at this is as a form of partial evaluation (although there's nothing which automatically decides which computation to do at compile time and which at run time). In the functional programming language, you have conditionals, the usual arithmetic operations, pairing, recursion, etc.; basically, it's a real programming language (although a very annoying one -- the syntax is atrocious). Here are a few examples of the kind of thing you can do with C++ templates: * Compute log base 2 at compile time. You can write a template such that if n is a compile-time constant, Log2::val is its log base 2. * Generate FFT routines. You can write a template such that if n is a compile-time constant which is a power of 2, then FFT::do_fft() is a routine which computes an FFT on an array of size n, as a single chunk of straight-line code (no loops). (Not necessarily useful -- it generates a lot of code for reasonable-sized arrays, and cache effects probably mean that something with loops is more efficient -- but cool nonetheless.) * Implement lambda (over a subset of full C++). You can make lambda(X, a*(X+b)) do "the right thing" (basically by arranging for the expression a*(X+b) to have a type like Times > and then writing a function using recursion over this type). These techniques are useful when you're going for speed and generality; I would certainly imagine that such things could be useful in a functional programming language as well. In fact, over the past few weeks, people on the Haskell mailing lists have been trying to do vaguely similar kinds of compile-time computation at the type level, using type classes and functional dependencies. On the other hand, C++ templates have huge flaws for this kind of thing. As I mentioned, the syntax is atrocious; also, there are lots of things you would like to do which are apparently just out of reach (the template language is not quite powerful enough). I'd like to see somebody make a serious effort to add this kind of compile-time processing to Haskell. It might not look anything like templates; something like OpenC++ and OpenJava might be better. (These are C++ and Java compilers which are extensible; you can write compiler extension modules using a standard API, and the compiler dynamically loads your extensions.) There is a big reason why C++ templates (or any other form of compile-time arbitrary computation on types) would be hard to add to Haskell: type inference and polymorphism. For C++ templates, you need to know the argument types before you can do the template processing, and you cannot know the type of the result until the processing is done. Probably this facility would only be useful for monomorphic parts of your program, which might mean it's not appropriate for Haskell at all. Carl Witty From ndalton@ics.uci.edu Wed May 23 04:09:23 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 20:09:23 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: <20010523102238.A2949@cs.mu.oz.au> Message-ID: On Wed, 23 May 2001, Tyson Dowd wrote: > Well, there is: > http://www.southern-storm.com.au/ Interesting, I wish them well. > Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working > on a C# compiler. Well I see from: http://primates.ximian.com/~miguel/cs-compiler.html that his experiment has finished, and I do not think that there is a complete compiler? From the activity log it looks like he got as far as a syntax checker. > Finally, there was recently an article in Linux Magazine (??? not Linux > Journal) about targetting gcc at the .NET CLR. I'm afraid I have no > information more than that, since I don't think I can get the magazine > in Australia. As far as I know, that article was speculating on whether this would be a good idea or not, not reporting on a port of gcc. Regards, Niall -- ---------------------------------------------------------------------- Niall Dalton ndalton@ics.uci.edu University of California, Irvine http://www.ics.uci.edu/~ndalton From bhalchin@hotmail.com Wed May 23 05:27:44 2001 From: bhalchin@hotmail.com (Bill Halchin) Date: Wed, 23 May 2001 04:27:44 Subject: Haskell & .NET CLR Message-ID: Hello Everybody, The second part of my question pertained only to have a working version of the .NET CLR running on non-win32 platforms, e.g. Linux.It won't do any good to only having compilers targeted for .NET CLR if this run-time system and it's libraries only run on win32. Then darth vadar wins.... Bill >From: Tyson Dowd >To: Niall Dalton >CC: Bill Halchin , haskell@haskell.org >Subject: Re: Haskell & .NET CLR >Date: Wed, 23 May 2001 10:22:38 +1000 > > > > Also can anybody point in the > > > direction of any projects to implement the .NET CLR on anything > > > other than Win32 platforms > > I haven't seen any public projects like that. Would be > > interesting though.. > >Well, there is: >http://www.southern-storm.com.au/ > >Also, Miguel de Icaza (of GNOME fame, co-founder of Ximian) has been working >on a C# compiler. > >See: >http://primates.helixcode.com/~miguel/activity-log.html > >Finally, there was recently an article in Linux Magazine (??? not Linux >Journal) about targetting gcc at the .NET CLR. I'm afraid I have no >information more than that, since I don't think I can get the magazine >in Australia. > >-- > Tyson Dowd # > # Surreal humour isn't everyone's cup of fur. > trd@cs.mu.oz.au # >http://www.cs.mu.oz.au/~trd # Get your FREE download of MSN Explorer at http://explorer.msn.com From ndalton@ics.uci.edu Wed May 23 05:35:03 2001 From: ndalton@ics.uci.edu (Niall Dalton) Date: Tue, 22 May 2001 21:35:03 -0700 (PDT) Subject: Haskell & .NET CLR In-Reply-To: Message-ID: > The second part of my question pertained only to have a working version > of the .NET CLR running on non-win32 platforms, e.g. Linux.It won't do Well you will need compilers as part of that to convert the MSIL into executable code. As I understand it there are several compilers in Microsoft's .NET implementation. A 'pre-jit' that is used as an install time compiler, a typical jit used at runtime and perhaps an optimizing compiler as well. Unfortunately I don't know much about the optimizing compiler plans, nor how things like the ssa stuff in the IL will be safely used. Perhaps we should move this conversation off the haskell list, as we drifted rather far off topic.. niall From simonpj@microsoft.com Wed May 23 08:53:55 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 23 May 2001 00:53:55 -0700 Subject: Haskell & .NET CLR Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond.corp.microsoft.com> | Are any of the various Haskell implm., e.g. ghc, being=20 | targeted for the .NET CLR?=20 Yes, we are, here in Cambridge. We've run some Haskell programs on the CLR already, but it's not nearly ready for release. =20 Simon From Jbkim1078@aol.com Wed May 23 10:59:15 2001 From: Jbkim1078@aol.com (Jbkim1078@aol.com) Date: Wed, 23 May 2001 05:59:15 EDT Subject: Tutor for Haskell is Wanted Message-ID: Hello, I am Yoon, a student of UNSW in Sydney,Australia. I am learning Haskell but need a lot of help for the course. Is there any way that I can get a private tutor? Thanks very much. From sk@mathematik.uni-ulm.de Wed May 23 13:55:16 2001 From: sk@mathematik.uni-ulm.de (Stefan Karrmann) Date: Wed, 23 May 2001 14:55:16 +0200 Subject: Dependent types (Was: Re: BAL paper available) In-Reply-To: ; from C.T.McBride@durham.ac.uk on Wed, May 16, 2001 at 01:03:25PM +0100 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <20010523125516.21796.qmail@thales.mathematik.uni-ulm.de> C T McBride schrieb folgendes am Wed, May 16, 2001 at 01:03:25PM +0100: > On Wed, 16 May 2001, Stefan Karrmann wrote: > > On Tue, May 15, 2001 at 09:14:02PM +0300, Dylan Thurston wrote: > > > On Tue, May 15, 2001 at 06:33:41PM +0200, Jerzy Karczmarczuk wrote: > > > ... you really need types that > > > depend on parameters (in particular, integer parameters). This is, > > > indeed, a problem--currently, you have to do runtime checks. > > > > > > Full-fledged dependent types à la Cayenne are undecidable, but there > > > are weaker variants that are likely to be good enough. > > > > What are the weaker variants? Do you know some references? > > Are they still decidable? That surprises me. If you allow integer > > arithmetic you can do already all computations (Church). > > The idea that `dependent types are undecidable' is a popular but > understandable misconception arising from a particular design decision in > a particular system---Cayenne. > > Dependent types as found in proof systems such as Coq and Lego do have > decidable typechecking: programs may only use structural recursion, and > hence all the evaluation which takes place during typechecking is > guaranteed to terminate. However, in order to support real programming, > Cayenne allows general recursion: as it makes no distinction between the > programs which are executed at compile-time and those only executed at > run-time, undecidability creeps in. Understandably, neither horn of this > dilemma is particularly attractive to programmers who want to combine > flexibility at run-time with a genuinely static notion of typechecking. With constructor type we can do dimension checking, as shown earlier on this list. Can't we check in a similiar way an integer paramter? But is this general enough? You may compute some integer n and then do some calculations in Z/n. How can this be done? Do you need to do the calculation only with structural recursion? > (Of course, post-98 Haskell with certain type class options selected has a > type-level language containing non-terminating programs, making > typechecking undecidable for exactly the same reason as in Cayenne.) If possibly non-terminating type analysis creeps into Haskell, why don't we choose the Cayenne style? > However, there is a middle way: we can distinguish compile-time programs > from run-time programs and restrict the former to the structurally > recursive fragment, leaving general recursion available in the latter. Is there any (syntactical) proposal somewhere? -- Stefan Karrmann From luc.taesch@csfb.com Wed May 23 17:08:49 2001 From: luc.taesch@csfb.com (Taesch, Luc) Date: Wed, 23 May 2001 18:08:49 +0200 Subject: creating xml doc with haxml Message-ID: <9818339E731AD311AE5C00902715779C0371A7AC@szrh00313.tszrh.csfb.com> i understand now how to filter existing xml doc with haxml. but what about creation from scratch ? if i have myCFel = mkElem "tag" [(literal "value")] myel is a CFilter, not an element so i i want to create a effective element ( to pass to putStrLn . render $ ppContent for instance), i should give it something to filter, like emptyContent = CString False "" to finally do myel = mylit emptyContent . are there any other way to use combinator for creating a structure ( as opposed to "operate on an existing structure")? thanks Luc This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. From fjh@cs.mu.oz.au Wed May 23 17:35:07 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 24 May 2001 02:35:07 +1000 Subject: Templates in FPL? In-Reply-To: References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <20010524023506.A14295@hg.cs.mu.oz.au> On 22-May-2001, Carl R. Witty wrote: > > I agree with Marcin about the bad points of templates. Me too. Marcin summed it up very well. Of the five disadvantages that he mentioned, I think at least three (lack of explicit interfaces, incredibly complicated rules about name lookup, and very poor error messages) are very serious problems. For an example of the problems caused by the lack of explicit interfaces, the C++ standards committee has still not agreed on what the interface to vector is. The standard is contradictory, because the vector specialization doesn't obey the rules specified for vector, and as yet there's no concensus about which should be changed. For an example of the problems caused by the complicated rules about name lookup, just today someone posted a bug report for gcc 2.95.* to gcc@gcc.gnu.org, reporting a problem where one of the standard library templates didn't work when they had a typedef named `destroy' in their code. My guess is that it was probably because the standard library code was using the function std::destroy(), but the standard library implementor didn't realize that it had to be explicitly namespace qualified; in other words, the rules were too complex and/or too cumbersome for the standard library developer to understand and/or apply. Marcin already posted a good example of a poor error message ;-) > (I'd like to > point out, though, that the idea that "adding new code can't change > the meaning of a program" no longer holds in Haskell extended with > overlapping type classes.) Yes... hence overlapping type classes are EVIL! ;-) ;-) ;-) ;-) > There are some very cool things about C++ templates; they are more > powerful than you might suspect. > > Basically, templates let you extend the compiler. You get a primitive > functional programming language, with which you can do basically > arbitrary computations on types and on integers; > In the functional programming language, you have conditionals, the > usual arithmetic operations, pairing, recursion, etc.; basically, it's > a real programming language (although a very annoying one -- the > syntax is atrocious). Right. It wasn't designed for that purpose, it just turned out that it could be used for it. It's a bit like that simulation of Conway's game of life in vi macros! Makes for a very impressive demo, but there are serious drawbacks to using such techniques in day-to-day work. I agree that it would be very nice if Haskell and other FPLs had some equivalent feature, with a nicer syntax. I think you might be able to do a lot of it using ordinary Haskell syntax with just some additional annotation that directs the compiler to evaluate part of the program at compile time. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From karczma@info.unicaen.fr Wed May 23 17:46:02 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Wed, 23 May 2001 18:46:02 +0200 Subject: Templates in FPL? References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> <20010524023506.A14295@hg.cs.mu.oz.au> Message-ID: <3B0BE94A.76CB56FE@info.unicaen.fr> Fergus Henderson : > I agree that it would be very nice if Haskell and other FPLs had some > equivalent feature, with a nicer syntax. I think you might be able to > do a lot of it using ordinary Haskell syntax with just some additional > annotation that directs the compiler to evaluate part of the program at > compile time. Actually, whole my posting was driven by that. (And by Clean macros which are not macros, but not yet templates, and by the fact that you can parameterize templates with constants, and Haskell classes not). Yours anwers, very thorough, concentrated sometimes on the realization of templates in C++, and I am the last to defend them, or to want to see them implemented in Haskell. But, as a - not too run-time-expensive way to deal with some facets of polymorphism by compiling specialized functions, it is a possible option. The syntactic issues, and the relation of these "macros" to class system is another story. Thanks. Jerzy Karczmarczuk Caen, France From brent.fulgham@xpsystems.com Wed May 23 22:56:19 2001 From: brent.fulgham@xpsystems.com (Brent Fulgham) Date: Wed, 23 May 2001 14:56:19 -0700 Subject: Cygwin Build Bug (Probably Affects other GNU GLIBC Builds) Message-ID: For thread-safety reasons, the GNU C Library (2.2+) defines "errno" as a macro that calls a function to get the errno of the current thread. Consequently, the source file "src/runtime/Builtin/cIOExtras.c" needs to include the header file, rather than declaring an extern variable. Diff: ========================================================================== *** cIOExtras.old.c Wed May 23 14:54:58 2001 --- cIOExtras.c Wed May 23 14:26:54 2001 *************** *** 1,10 **** /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! extern int errno; int getErrNo (void) { return errno; } --- 1,11 ---- /* basic unsafe utilities, defined in IOExtras */ #include "cinterface.h" #include "mk.h" + #include "errno.h" void performGC () { C_GC(0); } int unsafePtrEq (void* a, void* b) { return (a==b); } /* basic error handling via C's errno */ ! /*extern int errno;*/ int getErrNo (void) { return errno; } From jcab@roningames.com Thu May 24 03:18:32 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Wed, 23 May 2001 19:18:32 -0700 Subject: Templates in FPL? In-Reply-To: <20010524023506.A14295@hg.cs.mu.oz.au> References: <3B04E542.76BA65A5@mail.augustsson.net> <3B04EA7A.90D83CFB@info.unicaen.fr> Message-ID: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: > > Basically, templates let you extend the compiler. You get a primitive > > functional programming language, with which you can do basically > > arbitrary computations on types and on integers; > > In the functional programming language, you have conditionals, the > > usual arithmetic operations, pairing, recursion, etc.; basically, it's > > a real programming language (although a very annoying one -- the > > syntax is atrocious). > >Right. It wasn't designed for that purpose, it just turned out >that it could be used for it. It's a bit like that simulation of >Conway's game of life in vi macros! Makes for a very impressive >demo, but there are serious drawbacks to using such techniques in >day-to-day work. :) So true. In some ways, it sounds great: here we have a useful general-purpose feature that you can use for all kinds of things (a programming Swiss army knife, so to speak), and then build all kinds of _concrete_ useful things with it. Problem is that it doesn't allow you to redefine the syntax in any way. Thus, you can do compile-time assertions, computations, things like that, but the meaning of what you want to do often gets quite obfuscated by this syntax and by the contrived compiler error messages. I must say, though, that the beta compiler of MSVC 7 does a MUCH improved work on it. >I agree that it would be very nice if Haskell and other FPLs had some >equivalent feature, with a nicer syntax. I think you might be able to >do a lot of it using ordinary Haskell syntax with just some additional >annotation that directs the compiler to evaluate part of the program at >compile time. This is close to my personal vision. That is, a language that handles both run-time and compile-time computations seamlessly. Thus, the compiler would evaluate as much as it can, and then what's left is put in the executable. I assume that's something optimizing compilers for Haskell already do, at least in part. Problem is that, ideally, the language should allow the programmer to be explicit about things that should be done at compile-time and things that should be done at run-time, which Haskell doesn't quite have. Let's see how this could work: - IO actions must be executed at run-time, evidently. - We might be able to define another action monad (let's call it "CT", for compile-time) which defines just the opposite: an action that must be executed by the compiler. - We'd need a new primitive function: executeCompilerAction :: CT a -> a - And we'd need another: compilerEval :: a -> CT a So, let's say we want to force this program: main = print (fact 1000) to evaluate the factorial expression at compile-time. Then, we'd write something like: main = print (executeCompilerAction (compilerEval (fact 1000))) Of course, we'd eventually define any useful recurring patterns as new functions, as in here: eval a = executeCompilerAction (compilerEval a) Anyway, I don't know if I'm making much sense here. Just letting my brains fly on their own. Then, there's the explicit handling of types which templates allow and Haskell doesn't. I think that, the hardest part of Haskell that I'm having trouble with here is the way overloading is defined, using classes. I still have problems with that. Some times it is really obvious that it's best. Some other times, it really doesn't seem to fit (finding about the multi-parameter class extension was a very gratifying moment there). I can think of something that I don't know how to do in Haskell. Suppose that I have two classes, which I'll call Class1 and Class2: class Class1 a where func1 :: a -> Bool class Class2 a where ... (doesn't matter what goes here) And say that I want to express the fact that ALL types that are instances of Class2 will ALWAYS be instances of Class1, and will always return "False" from "func1". So, is there any way to express this kind of class-relationship in Haskell? It's not definitely inheritance, I think. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From simonmar@microsoft.com Thu May 24 10:02:43 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Thu, 24 May 2001 10:02:43 +0100 Subject: I/O buffering (was: Endangered I/O operations) Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115893@TVP-MSG-01.europe.corp.microsoft.com> [ moved from glasgow-haskell-users to haskell@haskell.org ] Carl Witty writes: > If the report does not allow the implementation to flush buffers at > any time, I would call that a bug in the report. Indeed, perhaps the report should be clarified on this issue. Currently, in section 11.4.2 the report specifies the conditions under which a buffer is flushed, and conditions under which input is available from a buffered read handle. GHC deviates from the report in a few ways: - we don't adhere strictly to block buffering for hPutStr: we may occasionally flush the buffer early. - a line-buffered input handle doesn't wait for the newline to be available before releasing the input, unless you use hGetLine of course. However, since the report doesn't specify the *size* of a line buffer, we can't really be accused of deviating here. - a read/write handle (files only) has a single buffer which contains either pending read or write items, never both. A read from a read/write handle will cause any pending writes to be flushed, and vice versa. IMHO, the report should state that additional buffer flushes may be performed at the discretion of the implementation, but an application should not rely on any additional flushing happening. The report doesn't state whether, when discarding a read buffer, the data should be "returned to the file" (ie. the underlying file pointer moved backwards) if possible. GHC does this if possible. One other point that I noticed while re-implementing I/O: the description for hLookAhead states that "Computation hLookAhead hdl returns the next character from handle hdl without removing it from the input buffer". What if the handle is unbuffered? A working hLookAhead is more or less required in order to implement hIsEOF (at least on a stream: for a file you can check EOF without attempting to read). So for GHC I had to ensure that even an unbuffered handle has a 1-character buffer; this turned out to be not as painful as I thought. Cheers, Simon > I would much rather > use an implementation where stdout and stderr came out in the right > order, and reading from stdin flushed stdout. (As another example, an > implementation might want to flush all buffers before doing a fork(), > to avoid duplicated output.) >=20 > The only caveat is that if such flushing is allowed but not required, > it might encourage writing sloppy, nonportable code. >=20 >=20 >=20 From Dominic.J.Steinitz@BritishAirways.com Thu May 24 10:45:54 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 09:45:54 Z Subject: Building Programs Message-ID: <"04B7D3B0CD852002*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> What's the recommended way of building a system consisting of many Haskell modules? Should I use hmake, make or is there some other preferred mechanism in the Haskell world? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonpj@microsoft.com Thu May 24 11:06:41 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 24 May 2001 03:06:41 -0700 Subject: Building Programs Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> It depends on which implementation you have.=20 hmake is good, and is independent of implementation. ghc 5.0 has a make system built in, so you can say ghc --make Main to build your program. Or=20 ghc --interactive Main to run it interactively. Hugs also follows module dependencies automatically. hbc had a similar mechanism I think. =20 Simon | -----Original Message----- | From: Steinitz, Dominic J=20 | [mailto:Dominic.J.Steinitz@BritishAirways.com]=20 | Sent: 24 May 2001 10:46 | To: haskell | Subject: Building Programs |=20 |=20 | What's the recommended way of building a system consisting of=20 | many Haskell modules? Should I use hmake, make or is there=20 | some other preferred mechanism in the Haskell world? |=20 | Dominic. |=20 | -------------------------------------------------------------- | ----------------------------------- | 21st century air travel http://www.britishairways.com |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From v-julsew@microsoft.com Thu May 24 13:57:06 2001 From: v-julsew@microsoft.com (Julian Seward (Intl Vendor)) Date: Thu, 24 May 2001 05:57:06 -0700 Subject: ghc-5.00.1 is available Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.00.1. The source distribution is freely available via the World-Wide Web and through anon. FTP, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, and Solaris(sparc) are also available. Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.00.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is a bug-fix release. Most reported bugs in 5.00 have been fixed, including a substantial number of show-stopping bugs. The system should be much more usable for more people. Upgrading to 5.00.1 is recommended. To all those who tried out 5.00 and reported bugs, we thank you for your feedback and patience. At the moment there is no Win32 build of 5.00 or 5.00.1 available. We decided to push Win32 support to the 5.02 release, so as not to delay 5.00.1 any further. What's new in 5.00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.00 has been majorly revamped since the previous stable version, 4.08.2. This should be a stable release. Major changes since 4.08.2 are: - An interactive system, similar in style to Hugs. You can interactively load and unload modules, run expressions, ask the types of things. Module dependencies are tracked and chased automatically. Combinations of compiled and interpreted modules may be used. All the GHC libraries are available in interactive mode, as are most of the Glasgow extensions to Haskell 98. Compilation in interactive mode (to bytecode) is about three times faster than compiling to object code. - Batch compilation of multiple modules at once, with automatic dependency chasing. For large programs this can halve compilation times, and removes the need for Makefiles. - Enhanced package (library) management system. Packages may be installed and removed from an installation using the ghc-pkg tool. - Initial Unicode support - the Char type is now 31 bits. - Sparc native code generator, giving much faster compilation on sparcs. (Native code generation for x86s has been available for a while). - Improved heap profiling - you can restrict heap profiles by type, closure description, cost centre, and module. - Support for the latest Foreign Function Interface (FFI) proposals. Marcin Kowalczyk's hsc2hs tool is included. - Language extensions: parallel list comprehensions and functional dependencies. - The usual huge collection of bug fixes. Most reported bugs have been fixed. For full details see the release notes: http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html How to get it =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in .rpm/.deb form for all you Linux junkies out there, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To compile programs with GHC, you need a machine with 32+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * alpha-dec-osf{2,3} * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/5.00/building/building-guide.html Mailing lists =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please send bug reports about GHC to glasgow-haskell-bugs@haskell.org; GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding edge CVS users party on cvs-ghc@haskell.org. From Malcolm.Wallace@cs.york.ac.uk Thu May 24 15:34:08 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Thu, 24 May 2001 15:34:08 +0100 Subject: Building Programs In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F9C@red-msg-09.redmond.corp.microsoft.com> Message-ID: > What's the recommended way of building a system consisting of > many Haskell modules? Should I use hmake, make or is there > some other preferred mechanism in the Haskell world? As Simon PJ already mentioned, hmake is entirely platform independent, so if there is any likelihood that you may need to change between Haskell compilers, or to distribute your software in a portable source form, it is probably the top option. But for quick hacking, or non-portable software using language extensions, individual compiler mechanisms such as Hugs' import chasing, ghc --make, and hbcmake, are just as good. Writing Makefiles is the least attractive option, even though they have good portability, because they are clunky and it is tricky to keep them synchronised with the true source dependencies. However, I think even when using hmake or ghc --make, you are likely to end up writing a small and simple Makefile anyway. Regards, Malcolm From Dominic.J.Steinitz@BritishAirways.com Thu May 24 18:47:42 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 17:47:42 Z Subject: ghc-5.00.1 is available Message-ID: <"04CAB3B0D493E00E*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From avv@quasar.ipa.nw.ru Thu May 24 19:11:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 11:11:41 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <3B0D4EDD.968E297C@quasar.ipa.nw.ru> Hi All, Do anybody have one? I failed to recompile it with ghc 4.08.x. Thank you in advance Alexander From ashley@semantic.org Thu May 24 22:41:21 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Thu, 24 May 2001 14:41:21 -0700 Subject: Unicode Message-ID: <200105242141.OAA15819@mail4.halcyon.com> At 2001-05-24 05:57, Julian Seward (Intl Vendor) wrote: > - Initial Unicode support - the Char type is now 31 bits. It might be appropriate to have two types for Unicode, a UCS2 type (16 bits) and a UCS4 type (31 bits). For instance, something like: -- newtype UCS2CodePoint = MkUCS2CodePoint Word16 newtype UCS4CodePoint = MkUCS4CodePoint Word31 type Char = UCS4CodePoint toUCS4 :: UCS2CodePoint -> UCS4CodePoint fromUCS4 :: UCS4CodePoint -> Maybe UCS2CodePoint encodeUTF16 :: [UCS4CodePoint] -> Maybe [UCS2CodePoint] decodeUTF16 :: [UCS2CodePoint] -> Maybe [UCS4CodePoint] -- -- Ashley Yakeley, Seattle WA From Dominic.J.Steinitz@BritishAirways.com Thu May 24 22:48:11 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 24 May 2001 21:48:11 Z Subject: ghc-5.00.1 is available Message-ID: <"046603B0D819B004*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Of course I meant hPutStr handle (map (chr .word8ToInt) protocolElement) Dominic J Steinitz@baexternal 24/05/2001 18:47 To: v-julsew cc: glasgow-haskell-users haskell bcc: Dominic Steinitz Subject: Re: ghc-5.00.1 is available Will this - Initial Unicode support - the Char type is now 31 bit cause me a problem? I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do hPutStr (map (ord .word8ToInt) protocolElement) essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise. Dominic. -------------------------------------------------------------------------------- ----------------- 21st century air travel http://www.britishairways.com _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From qrczak@knm.org.pl Thu May 24 23:04:22 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 24 May 2001 22:04:22 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: >> - Initial Unicode support - the Char type is now 31 bits. > > It might be appropriate to have two types for Unicode, a UCS2 type > (16 bits) and a UCS4 type (31 bits). Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char is '\x10FFFF' now. Among encodings of Unicode in a stream of bytes there are UTF-8, UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and UCS4 are obsolete: there is a single code space 0..0x10FFFF and various ways to serialize characters. Ghc is going to support conversion between internal Unicode and some encodings for external byte streams. Among them there will be UTF-{8,16,32} (with endianness variants), all treated as streams of bytes. There is no point in storing characters in UTF-16 internally. Especially in ghc where characters are boxed objects, and Word16 is represented as a full machine word (32 or 64 bits). UTF-16 will be supported as an external encoding, parallel to ISO-8859-x etc. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From miketh@brisbane.paradigmgeo.com Fri May 25 03:36:19 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 12:36:19 +1000 Subject: a cygwin binary package of ghc-5.00.x References: Message-ID: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Hi. > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > Thank you in advance > > > > Alexander I have one, which uses the Mingw standalone GCC compiler for Windows. It seems to be capable of compiling itself. Problems: 1. It is not in an installer - you would have to hand patch the package file and install by hand. 2. It is not supported by anyone and is non-standard in the way it uses Mingw32. 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 though). 4. I haven't bootstrapped GHCi, yet (maybe by next week). 5. It is only GHC 5.00, not 5.00.1. (maybe next week). 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) yourself. 7. It is very big, mainly because of the profiled libraries. 8. I don't have an FTP site to put it. 9. It doesn't do dynamic libraries, only static. etc. Unless you're desperate, I suggest waiting for the official release. Cheers Mike Thomas. From avv@quasar.ipa.nw.ru Fri May 25 04:10:15 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Thu, 24 May 2001 20:10:15 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> Message-ID: <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Hi Mike, Thank you very much for the reply. After having asked I managed to build ghc-5.00.1, and almost succeeded in the rest, till the place where it failed to invoke ghc-asm (or so, I don't remember, it's on a different machine). It's not impossible that I understand how to fix it (it was just before I went home). I use normal latest cygwin installation, binary installation of ghc-4.08, and tell i686-pc-mingw32 to the configure of ghc. Looks like it's impossible to build it for the full cygwin (but does anybody care?) and also I failed to --enable-win32-dlls (that is _it_ failed, not me :-); it stopped at something like Main.dll_o. During the build I was really scared looking at the resident sizes of the compiler process, which is an ordinary haskell application, with its most adequate application domain. Does it mean that my _real_ programs would expose the same? Alexander Mike Thomas wrote: > > Hi. > > > > Do anybody have one? I failed to recompile it with ghc 4.08.x. > > > > > > Thank you in advance > > > > > > Alexander > > I have one, which uses the Mingw standalone GCC compiler for Windows. It > seems to be capable of compiling itself. > > Problems: > > 1. It is not in an installer - you would have to hand patch the package file > and install by hand. > > 2. It is not supported by anyone and is non-standard in the way it uses > Mingw32. > > 3. The Win32 demo program hangs on exit under Win98 (works OK on NT4 > though). > > 4. I haven't bootstrapped GHCi, yet (maybe by next week). > > 5. It is only GHC 5.00, not 5.00.1. (maybe next week). > > 6. You would have to install Mingw32 (and maybe Cygwin for it's shell) > yourself. > > 7. It is very big, mainly because of the profiled libraries. > > 8. I don't have an FTP site to put it. > > 9. It doesn't do dynamic libraries, only static. > > etc. > > Unless you're desperate, I suggest waiting for the official release. > > Cheers > > Mike Thomas. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From miketh@brisbane.paradigmgeo.com Fri May 25 07:09:13 2001 From: miketh@brisbane.paradigmgeo.com (Mike Thomas) Date: Fri, 25 May 2001 16:09:13 +1000 Subject: a cygwin binary package of ghc-5.00.x References: <004d01c0e4c3$7e3f57d0$0cb4a8c0@brisbane.paradigmgeo.com> <3B0DCD17.DE2ECF48@quasar.ipa.nw.ru> Message-ID: <005801c0e4e1$3c061520$0cb4a8c0@brisbane.paradigmgeo.com> Hi there. > I use normal latest cygwin installation, > binary installation of ghc-4.08, and tell i686-pc-mingw32 to the > configure of ghc. Same here, except I used the standalone Mingw, which meant that I had to alter certain parts of the makefile which relied on Cygwin links (in the gmp library), and alter the parameters sent to GCC. > Looks like it's impossible to build it for the full > cygwin (but does anybody care?) I certainly don't ! > and also I failed to --enable-win32-dlls > (that is _it_ failed, not me :-); it stopped at something like > Main.dll_o. I haven't tried that option yet, as there is apparently a bug in Mingw for large heaps when linked dynamically. > During the build I was really scared looking at the resident sizes of > the compiler process, which is an ordinary haskell application, with its > most adequate application domain. Does it mean that my _real_ programs > would expose the same? Yeah, it's pretty big, but I guess that not all programs use as much memory as a compiler. Good luck. Mike Thomas. From simonpj@microsoft.com Fri May 25 08:01:22 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Fri, 25 May 2001 00:01:22 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 working here, but we are trying to get the packaging right so that it doesn't require Cygwin etc.=20 If you want to build it from source, you might want to wait for Reuben to put up the 4.08 download he's about to distribute. I have myself used this download to compile the head from source yesterday, so I know it works! Simon | -----Original Message----- | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 | Sent: 24 May 2001 19:12 | To: haskell@haskell.org | Subject: a cygwin binary package of ghc-5.00.x |=20 |=20 | Hi All, |=20 | Do anybody have one? I failed to recompile it with ghc 4.08.x. |=20 | Thank you in advance |=20 | Alexander |=20 |=20 |=20 | _______________________________________________ | Haskell mailing list | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell |=20 From Dominic.J.Steinitz@BritishAirways.com Fri May 25 11:35:06 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 10:35:06 Z Subject: IO Errors Message-ID: <"03C413B0E355A011*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Can anyone tell me why this behaves as it does? In Hugs, I get C:\My Documents\functional\ldapsck1\buffer.hs Main> main Illegal operation (561 reductions, 1029 cells) Main> If the input file is the one line: 1234567812345678 the output file is: Starting logging 1234567812345678 Error In ghc, the program hangs without even creating a file. Dominic import IO main :: IO () main = do ofh <- openFile "log.txt" WriteMode logMessage ofh "Starting logging" ifh <- openFile "tst.txt" ReadMode let loop = do b <- try (getBuffer ifh 16) case b of Right msg -> do logMessage ofh msg loop Left e -> if isEOFError e then do logMessage ofh "Finishing logging" hClose ofh else do logMessage ofh "Error" ioError e in loop logMessage :: Handle -> String -> IO () logMessage hd msg = do hPutStrLn hd msg hFlush hd getBuffer :: Handle -> Int -> IO String getBuffer h n = if (n <= 0) then return "" else do c <- hGetChar h cs <- getBuffer h (n-1) return (c:cs) ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From ltaesch@europemail.com Fri May 25 14:34:22 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 13:34:22 +0000 Subject: combinators Message-ID: <3B0E5F5E.4541CF5@europemail.com> beyond specific combinator tutorial, are there any generic combinator paper, or introductory ones ? thks Luc From joe@isun.informatik.uni-leipzig.de Fri May 25 12:56:39 2001 From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann) Date: Fri, 25 May 2001 13:56:39 +0200 (MET DST) Subject: combinators In-Reply-To: <3B0E5F5E.4541CF5@europemail.com> from luc at "May 25, 2001 01:34:22 pm" Message-ID: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> > beyond specific combinator tutorial, are there any generic combinator > paper, or introductory ones ? what exactly do you mean by "combinator". there's the recent area of parser combinators and such, but there's also Combinatory Logic in itself, which is a formal system closely related to the lambda calculus. a nice introduction is here: http://uq.net.au/~zzdkeena/Lambda/index.htm which is based on the "ornithology" from here: Smullyan, R.M. (1985) To mock a mockingbird. Alfred A. Knopf, New York. of course, the definitive references on Comb. L. and Lambda Calc. are the books by Curry, Feys, Hindley, Seldin, Barendregt (check your library). beware that the classical theory (as expressed in these books) is mostly un-typed (you can apply anything to anything). enjoy, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 -- From simonmar@microsoft.com Fri May 25 12:49:16 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Fri, 25 May 2001 12:49:16 +0100 Subject: IO Errors Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD709@TVP-MSG-01.europe.corp.microsoft.com> > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon From action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee Fri May 25 12:47:30 2001 From: action-semantics@brics.dk, AG-list@uni-mb.si, alp-diffusion@univ-lille1.fr, amast@cs.utwente.nl, bra-types@cs.chalmers.se, calculemus-ig@dist.unige.it, cofi-list@brics.dk, comp.compilers@alpham.uni-mb.si, concurrency@cwi.nl, coq-club@pauillac.inria.fr, eacsl@dimi.uniud.it, EAPLS@JISCMAIL.AC.UK, eatcs-it@cs.unibo.it, ecoop-info@ecoop.org, formal-methods@cs.uidaho.edu, fsdm@it.u, q.edu.au@alpham.uni-mb.si, ftp@logic.at, haskell@haskell.org, info-hol@jaguar.cs.byu.edu, ipalist@win.tue.nl, isabelle-users@cl.cam.ac.uk, logic-ml@logic.jaist.ac.jp, lpca@loria.fr, nwpt-info@sool.ioc.ee (Marjan Mernik) Date: Fri, 25 May 2001 13:47:30 +0200 Subject: CFP: LDTA'2002 Message-ID: <3B0E4652.3F402DE1@uni-mb.si> [apologies if you receive multiple copies of this message] ----------------------------------------------------------- 2nd Workshop on Language Descriptions, Tools and Applications LDTA'2002 Affiliated with ETAPS'2002 April 13, 2002 Grenoble, France The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications of these language definitions and tools developed for or with these language definitions. For call for papers and additional information please check the following URL: http://www.cwi.nl/conferences/LDTA2002 Schedule Submission of full paper December 15, 2001 Notification January 31, 2002 Final version due February 28, 2002 From ltaesch@europemail.com Fri May 25 15:17:14 2001 From: ltaesch@europemail.com (luc) Date: Fri, 25 May 2001 14:17:14 +0000 Subject: combinators References: <200105251156.NAA16090@isun11.informatik.uni-leipzig.de> Message-ID: <3B0E696A.7BCF46A0@europemail.com> Johannes Waldmann wrote: > > beyond specific combinator tutorial, are there any generic combinator > > paper, or introductory ones ? > > what exactly do you mean by "combinator". > there's the recent area of parser combinators and such, well, i didnt knew it was new, but , yes, that's it. ive read some paper on parser combinator, and as im working with haxml, id like to have some of my stuuf done in the same style, then i realize i had a tendency to design function that reacted on data (itself), rather than combinators. (probably too mucj of "old stuff in my head ;-) so i would like to backstep , and look at combinator as such , and not applied in a given context (liker parser or haxml)) which example i can understand, but not easily change my style of programming accordingly. so, reformulation : has anyone know a paper like : "change ure mindset from data oriented programming to combinators one " ? > > > but there's also Combinatory Logic in itself, > which is a formal system closely related to the lambda calculus. is this then relevnt for me to look t that, in the light of my previous explanation ? From ketil@ii.uib.no Fri May 25 15:34:41 2001 From: ketil@ii.uib.no (Ketil Malde) Date: 25 May 2001 16:34:41 +0200 Subject: Templates in FPL? In-Reply-To: Juan Carlos Arevalo Baeza's message of "Wed, 23 May 2001 19:18:32 -0700" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Juan Carlos Arevalo Baeza writes: > At 02:35 AM 5/24/2001 +1000, Fergus Henderson wrote: >> I agree that it would be very nice if Haskell and other FPLs had some >> equivalent feature, with a nicer syntax. I think you might be able to >> do a lot of it using ordinary Haskell syntax with just some additional >> annotation that directs the compiler to evaluate part of the program at >> compile time. > This is close to my personal vision. That is, a language that handles both > run-time and compile-time computations seamlessly. Thus, the compiler would > evaluate as much as it can, and then what's left is put in the > executable. I must be missing something crucial here - I thought that was exactly what GHC did? I've certainly had it optimize toy benchmarks completely away... Could somebody elucidate, please? Of course, having annotations to hint about specialization might be a good thing. Perhaps this could be profiled and fed back to the compiler? ISTR this is common for the SPEC benchmarks (in C or Fortran, I presume) > Problem is that, ideally, the language should allow the programmer to > be explicit about things that should be done at compile-time and things that > should be done at run-time, which Haskell doesn't quite have. Why/when do you need this? I would go for -O implying optimizing away as much as possible (i.e all constant expressions), and else no optimization (for compilation speed). -kzm -- If I haven't seen further, it is by standing in the footprints of giants From Dominic.J.Steinitz@BritishAirways.com Fri May 25 17:09:05 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 25 May 2001 16:09:05 Z Subject: IO Errors Message-ID: <"019E13B0E83A103F*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> Simon, I (stupidly) called the executable logger and then presumably invoked something on linux of the same name. Giving it a different name gave the same result as you got. I assume this is a bug in hugs and I will refer it to that mailing list. Dominic. simonmar@microsoft.com on 25/05/2001 13:03:00 To: Dominic Steinitz haskell cc: bcc: Subject: RE: IO Errors > In ghc, the program hangs without even creating a file. With GHC 5.00.1 here it creates the output file containing: Starting logging 1234567812345678 Finishing logging which GHC version was hanging for you? Cheers, Simon _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From fjh@cs.mu.oz.au Fri May 25 18:17:40 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Sat, 26 May 2001 03:17:40 +1000 Subject: Unicode In-Reply-To: References: <200105242141.OAA15819@mail4.halcyon.com> Message-ID: <20010526031740.A27447@hg.cs.mu.oz.au> On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > (16 bits) and a UCS4 type (31 bits). > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > is '\x10FFFF' now. > > Among encodings of Unicode in a stream of bytes there are UTF-8, > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > various ways to serialize characters. > > Ghc is going to support conversion between internal Unicode and > some encodings for external byte streams. Among them there will be > UTF-{8,16,32} (with endianness variants), all treated as streams > of bytes. > > There is no point in storing characters in UTF-16 internally. > Especially in ghc where characters are boxed objects, and Word16 is > represented as a full machine word (32 or 64 bits). UTF-16 will be > supported as an external encoding, parallel to ISO-8859-x etc. What about for interfacing with Win32, MacOS X, or Java? Your talk about "external" versus "internal" worries me a bit, since the distinction between these is not always clear. Is there a way to convert a Haskell String into a UTF-16 encoded byte stream without writing to a file and then reading the file back in? -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From jcab@roningames.com Fri May 25 18:45:59 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Fri, 25 May 2001 10:45:59 -0700 Subject: Templates in FPL? In-Reply-To: References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: <4.3.2.7.2.20010525104210.02f0cfd8@207.33.235.243> At 04:34 PM 5/25/2001 +0200, Ketil Malde wrote: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > >I must be missing something crucial here - I thought that was exactly >what GHC did? I don't presume to know what GHC does. After all, Haskell was completely unknown to me three months ago. O:-) I did hope that was the case, though: "I assume that's something optimizing compilers for Haskell already do, at least in part". > > Problem is that, ideally, the language should allow the programmer to > > be explicit about things that should be done at compile-time and things > that > > should be done at run-time, which Haskell doesn't quite have. > >Why/when do you need this? I would go for -O implying optimizing away >as much as possible (i.e all constant expressions), and else no >optimization (for compilation speed). Oh, there are several reasons for the programmer to make her wishes clear to the compiler. Especially when having something NOT calculated at compile time is not acceptable. In that case, you want the compiler to return an error, instead of emitting the runtime calculations. A silly example of this that comes to mind is non-converging calculations. Say we have a wrong factorial function: tcaf 0 = 1 tcaf n = n * tcaf (n+1) Pass this program through GHC: main = print (tcaf 3) Will it evaluate "tcaf 3" at compile-time? Will it error-out at compile-time? I don't have the compiler here (I'm writing from work, but I'm trying Haskell out at home). My guess would be that GHC will evaluate as much as it can, and leave the rest for the run-time program. Specifically, the best I'd expect it to do is to lessen the recursion by expanding several levels of it. For example, for two levels, it'd be reduced to: tcaf = (\n -> case n of 0 = 1; -1 = -1; _ = n * (n+1) * tcaf (n+2)) Of course, I might be completely wrong here. I don't think it'd be terribly hard for the compiler to deduce that a function like this, called with a positive argument, is never going to finish evaluating. But in more complex cases, it might not be possible for the compiler to know. Then again, GHC might actually be evaluating EVERYTHING that doesn't depend on IO actions... without exception... This brings me to a question. What would a good optimizing compiler (GHC) do in this case: main = do num <- return 3 print (tcaf num) I'll be trying all these things tonight. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From avv@quasar.ipa.nw.ru Fri May 25 19:14:41 2001 From: avv@quasar.ipa.nw.ru (Alexander V. Voinov) Date: Fri, 25 May 2001 11:14:41 -0700 Subject: a cygwin binary package of ghc-5.00.x References: <37DA476A2BC9F64C95379BF66BA26902D72FA0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B0EA111.A4A2821@quasar.ipa.nw.ru> Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >= 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one > working here, but we are trying to get the packaging right > so that it doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for > Reuben to put up the 4.08 download he's about to distribute. > I have myself used this download to compile the head from > source yesterday, so I know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From taha@cs.yale.edu Fri May 25 19:29:44 2001 From: taha@cs.yale.edu (Walid Taha) Date: Fri, 25 May 2001 14:29:44 -0400 (EDT) Subject: NEPLS In-Reply-To: <200105251821.OAA16140@bosch.cs.brown.edu> Message-ID: Dear all, If you want to be added to the NEPLS page, please send ME your email and I'll forward it to Shriram. Cheers, Walid. On Fri, 25 May 2001, Shriram Krishnamurthi wrote: |Hi Walid, | |You were never on the mailing list (for reasons that escape me). You |are now. | |Do me a favor. Send mail around to the programming languages people |at Yale asking whether they'd like to be on the list. Find someone to |collect all these names and send them to me in a single message, |line-at-a-time (usual mail alias file format). I'll take care of |including y'all. If the name's not obvious from the email address, |please also include the full name in the usual mail format: | | "Walid Taha" | |Btw, the only cs.yale.edu addresses currently on the list are | | Walid Taha | hudak@cs.yale.edu | shao-zhong@cs.yale.edu | carsten@cs.yale.edu | |League and Courtney are on through other hostnames. Maybe I'm missing |a few others. | |Thanks. | |Shriram | From Roger McKenssy" We are looking for new faces for TV & Movie productions. All ages and looks. All countries. If you are interested, Please email or fax us your: ---------------------------------------------- -Name: -Age: -Country: -City: -email address: ---------------------------------------------- If your email reply gives you a delivery error, please use Fax nr 1-309-276-9964 to ensure that we get your message. Please reply only if TV, movie or modeling is of an interest to you. We hope you understand that we are trying to get ONLY serious people who really want to try and like the camera. Feel free to pass this email to a friend or a family member who maybe interested. There is absolutely no payment of any form required from your side. On the oposite, all jobs we offers are well paid. You'll be contacted for an online interview as soon as we can. Best Regards, Roger McKenssy Fax nr 1-309-276-9964 ------------------------------- This email is sent to you in full compliance with all existing and proposed email legislation. Note: You are not on a mailing list, and this is a one-time email. If we don't get an answer, you'll never hear from us any more. You are removed by default. You can still reply with the word Remove in the subject. This right is yours by law. Use Fax nr 1-309-276-9964 From cwitty@newtonlabs.com Fri May 25 19:33:37 2001 From: cwitty@newtonlabs.com (Carl R. Witty) Date: 25 May 2001 11:33:37 -0700 Subject: Templates in FPL? In-Reply-To: Ketil Malde's message of "25 May 2001 16:34:41 +0200" References: <4.3.2.7.2.20010523153217.02ed5478@207.33.235.243> Message-ID: Ketil Malde writes: > > This is close to my personal vision. That is, a language that handles both > > run-time and compile-time computations seamlessly. Thus, the compiler would > > evaluate as much as it can, and then what's left is put in the > > executable. > > I must be missing something crucial here - I thought that was exactly > what GHC did? I've certainly had it optimize toy benchmarks > completely away... Could somebody elucidate, please? I don't know what GHC does, but there are certainly reasons why you might not want to evaluate everything possible at compile time. For instance, there may be some sort of lookup table which is very large, but is fast to compute at runtime; you might not want to store the large table on disk in your executable. Carl Witty From john@repetae.net Fri May 25 21:12:49 2001 From: john@repetae.net (John Meacham) Date: Fri, 25 May 2001 13:12:49 -0700 Subject: Unicode In-Reply-To: <20010526031740.A27447@hg.cs.mu.oz.au>; from fjh@cs.mu.oz.au on Sat, May 26, 2001 at 03:17:40AM +1000 References: <200105242141.OAA15819@mail4.halcyon.com> <20010526031740.A27447@hg.cs.mu.oz.au> Message-ID: <20010525131249.C18660@mark.ugcs.caltech.edu> The algorithms for encoding unicode characters into the various transport formats, UTF16,UTF8,UTF32 are well defined, they can trivially be implemented in Haskell, for instance encodeUTF8 :: String -> [Byte] decodeUTF8 :: [Byte] -> Maybe String would be easily definable. BTW, since a char is no longer a byte, how about making a standard type Byte = Word8 declaration in a readily accesable and standard place. then we can start revamping the large amounts of legacy code which assume a Char is 8 bits. in particular the POSIX APIs are no good in this respect, as well as many of the example programs out there on the web... John On Sat, May 26, 2001 at 03:17:40AM +1000, Fergus Henderson wrote: > On 24-May-2001, Marcin 'Qrczak' Kowalczyk wrote: > > Thu, 24 May 2001 14:41:21 -0700, Ashley Yakeley pisze: > > > > >> - Initial Unicode support - the Char type is now 31 bits. > > > > > > It might be appropriate to have two types for Unicode, a UCS2 type > > > (16 bits) and a UCS4 type (31 bits). > > > > Actually it's 20.087462841250343 bits. Unicode 3.1 extends to U+10FFFF, > > ISO-10646-1 is said to shrink to U+10FFFF in future, so maxBound::Char > > is '\x10FFFF' now. > > > > Among encodings of Unicode in a stream of bytes there are UTF-8, > > UTF-16 and UTF-32 (with endianness variants). AFAIK terms UCS2 and > > UCS4 are obsolete: there is a single code space 0..0x10FFFF and > > various ways to serialize characters. > > > > Ghc is going to support conversion between internal Unicode and > > some encodings for external byte streams. Among them there will be > > UTF-{8,16,32} (with endianness variants), all treated as streams > > of bytes. > > > > There is no point in storing characters in UTF-16 internally. > > Especially in ghc where characters are boxed objects, and Word16 is > > represented as a full machine word (32 or 64 bits). UTF-16 will be > > supported as an external encoding, parallel to ISO-8859-x etc. > > What about for interfacing with Win32, MacOS X, or Java? > Your talk about "external" versus "internal" worries me a bit, > since the distinction between these is not always clear. > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? > > -- > Fergus Henderson | "I have always known that the pursuit > | of excellence is a lethal habit" > WWW: | -- the last words of T. S. Garp. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@repetae.net -------------------------------------------------------------- From qrczak@knm.org.pl Fri May 25 21:07:25 2001 From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) Date: 25 May 2001 20:07:25 GMT Subject: Unicode References: <200105242141.OAA15819@mail4.halcyon.com> <9emde2$kcv$1@qrnik.zagroda> Message-ID: Sat, 26 May 2001 03:17:40 +1000, Fergus Henderson pisze: > Is there a way to convert a Haskell String into a UTF-16 > encoded byte stream without writing to a file and then > reading the file back in? Sure: all conversions are available as memory to memory conversions for direct use. My conversion type is parametrized by input and output character types, so you can even define UTF-16 as giving [Word16]. But [Word8] must be used for handles, so I think that in practice conversions are generally between [Char] and [Word8]. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK From konsu@microsoft.com Fri May 25 23:47:00 2001 From: konsu@microsoft.com (Konst Sushenko) Date: Fri, 25 May 2001 15:47:00 -0700 Subject: a cygwin binary package of ghc-5.00.x Message-ID: <0FA38CF91938AC4F8FDC4960E389D76315D2FF@red-msg-10.redmond.corp.microsoft.com> Alexander, It looks like I had a similar problem with ghc script not being recognised by cygwin, and I assume that ghc-asm is also a perl script. I ended up invoking perl explicitly thus perl -S ghc ... I guess if you do the same with ghc-asm, it will work. Hope this helps Konst -----Original Message----- From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru]=20 Sent: Friday, May 25, 2001 11:15 AM To: Simon Peyton-Jones Cc: haskell@haskell.org Subject: Re: a cygwin binary package of ghc-5.00.x Hi Simon et al. I see. My concern is the following. Before I stick to haskell I have to make sure that I can connect some necessary windows-specific C stuff to my programs - both mine and external. I can start developing with Hugs, but finally I would need a compiled speed. Do I understand correctly, that Hugs allows to make C extensions on windows? Can I then use the same interfaces once ghc for windows is ready? My last obstacle with recompiling ghc is ../../ghc/compiler/ghc-inplace -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static -c Exception.hc -o Exception.o 'c:/avv/soft/ghc-5.00.1/ghc/compiler/../driver/mangler/ghc-asm' is not recognized as an internal or external command, operable program or batch file. where c:/avv/soft/ghc-5.00.1 is evidently the root of the source tree, and this ghc-asm is present at the specified location. I tried to change the prefix to /cygwin/c/... in Config.hs, but this didn't help. Besides, I'd be much more interested in making extensions with VC N, where N >=3D 5 or 6. If the words 'doesn't require Cygwin ' below mean exactly this, I'd better wait. Thank you in advance Alexander Simon Peyton-Jones wrote: > I'm afraid there isn't a Windows port of 5.00.1 yet. We have one=20 > working here, but we are trying to get the packaging right so that it=20 > doesn't require Cygwin etc. > > If you want to build it from source, you might want to wait for Reuben > to put up the 4.08 download he's about to distribute. I have myself=20 > used this download to compile the head from source yesterday, so I=20 > know it works! > > Simon > > | -----Original Message----- > | From: Alexander V. Voinov [mailto:avv@quasar.ipa.nw.ru] > | Sent: 24 May 2001 19:12 > | To: haskell@haskell.org > | Subject: a cygwin binary package of ghc-5.00.x > | > | > | Hi All, > | > | Do anybody have one? I failed to recompile it with ghc 4.08.x. > | > | Thank you in advance > | > | Alexander > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From leelati@yahoo.com Sat May 26 07:52:31 2001 From: leelati@yahoo.com (Rab Lee) Date: Fri, 25 May 2001 23:52:31 -0700 (PDT) Subject: can anyone help? Message-ID: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Dear Experts, I would appreciate any help that anyone can give me. I'm having a bit of trouble with Haskell, my question is pretty simple and i was wonder if anyone could please tell me how to change a string into a list??? Thank you in advance Leat __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From dscarlett@optushome.com.au Sat May 26 08:05:17 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Sat, 26 May 2001 17:05:17 +1000 Subject: can anyone help? References: <20010526065231.91533.qmail@web9501.mail.yahoo.com> Message-ID: <000701c0e5b2$38140770$0100a8c0@CO3003288A> ----- Original Message ----- From: "Rab Lee" To: Sent: Saturday, May 26, 2001 4:52 PM Subject: can anyone help? > Dear Experts, > I would appreciate any help that anyone can give me. > I'm having a bit of trouble with Haskell, my question > is pretty simple and i was wonder if anyone could > please tell me how to change a string into a list??? > Thank you in advance > Leat > A String is a type of list already........ It is a list of Chars. Could you be a bit more specific as to what you want to do? Do you mean (for example), change a String of digits into a list of Ints? ie. "12345" -> [1,2,3,4,5] From leelati@yahoo.com Sat May 26 08:47:21 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:21 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074721.75623.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From leelati@yahoo.com Sat May 26 08:47:56 2001 From: leelati@yahoo.com (Rab Lee) Date: Sat, 26 May 2001 00:47:56 -0700 (PDT) Subject: (no subject) Message-ID: <20010526074756.75644.qmail@web9506.mail.yahoo.com> hi, i'm having a bit more touble, can anyone help me or give me any hints on how to do this : "x 2 3 4" = ("x", [2, 3, 4]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From N.Perry@massey.ac.nz Sat May 26 11:33:07 2001 From: N.Perry@massey.ac.nz (Nigel Perry) Date: Sat, 26 May 2001 22:33:07 +1200 Subject: Haskell & .NET CLR In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D72F88@red-msg-09.redmond .corp.microsoft.com> Message-ID: At 12:53 am -0700 23/5/01 you wrote: >| Are any of the various Haskell implm., e.g. ghc, being >| targeted for the .NET CLR? You can get a beta version of ghc for .NET from www.mondrian-script.org. A lot, but far from all, or the standard libraries are provided. There is no floating point support (use the Mondrian compiler ;-)). This version of ghc will be superceded by another from a different source... Cheers, Nigel -- Nigel Perry, New Zealand From chak@cse.unsw.edu.au Sat May 26 13:53:43 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Sat, 26 May 2001 22:53:43 +1000 Subject: ghc-5.00.1 is available In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> Message-ID: <20010526225343M.chak@cse.unsw.edu.au> "Julian Seward (Intl Vendor)" wrote, > The (Interactive) Glasgow Haskell Compiler -- version 5.00.1 > ============================================================== > > We are pleased to announce a new patchlevel release of the Glasgow > Haskell Compiler (GHC), version 5.00.1. There are rpm packages for x86 GNU/Linux now. For glibc 2.2 systems, build on RedHat 7.0, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.1-1.i386.rpm For RedHat 6.2, we have ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.1-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.1-1.i386.rpm The matching source rpm is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.1-1.src.rpm The RedHat 6.2 packages have been kindly contributed by Tom Moertel. Cheers, Manuel PS: The problems with the documentation in the 5.00 rpms have been resolved (at least in the RH7.0 packages, I didn't check the others). From ashley@semantic.org Sun May 27 22:18:13 2001 From: ashley@semantic.org (Ashley Yakeley) Date: Sun, 27 May 2001 14:18:13 -0700 Subject: (no subject) Message-ID: <200105272118.OAA09091@mail4.halcyon.com> At 2001-05-26 00:47, Rab Lee wrote: >hi, i'm having a bit more touble, can anyone help me >or give me any hints on how to do this : >"x 2 3 4" = ("x", [2, 3, 4]) Generally we don't solve homework for people. Unless they're studying under Prof. Karczmarczuk, of course. -- Ashley Yakeley, Seattle WA From karczma@info.unicaen.fr Mon May 28 09:21:25 2001 From: karczma@info.unicaen.fr (Jerzy Karczmarczuk) Date: Mon, 28 May 2001 10:21:25 +0200 Subject: Homeworks and art of flying. References: <200105272118.OAA09091@mail4.halcyon.com> Message-ID: <3B120A85.1CCD25F0@info.unicaen.fr> Ashley Yakeley answers the query of Rab Lee: > > >hi, i'm having a bit more touble, can anyone help me > >or give me any hints on how to do this : > >"x 2 3 4" = ("x", [2, 3, 4]) > > Generally we don't solve homework for people. Unless they're studying > under Prof. Karczmarczuk, of course. > > -- > Ashley Yakeley, Seattle WA Now, now, this is cruel and ati-pedagogical. I changed my mind, we should all be friends, and help each other. Here is the ideal solution, very fast, and protected against viral contamination homework "x 2 3 4" = ("x", [2, 3, 4]) homework _ = error "You can't" Note the cleverness and universalness of the solution. Jerzy Karczmarczuk Caen, France PS. A deep philosophical quotation seems appropriate here. Here is one from Douglas Adams: Flying is an art, or rather a knack. The knack consists in throwing oneself to ground, and miss. From simonpj@microsoft.com Mon May 28 09:31:56 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Mon, 28 May 2001 01:31:56 -0700 Subject: (no subject) Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FAD@red-msg-09.redmond.corp.microsoft.com> This looks like a good thread to move to haskell-cafe@haskell.org http://haskell.org/mailinglist.html Simon | -----Original Message----- | From: Rab Lee [mailto:leelati@yahoo.com]=20 | Sent: 26 May 2001 08:48 | To: haskell@haskell.org | Subject: (no subject) |=20 |=20 | hi, i'm having a bit more touble, can anyone help me | or give me any hints on how to do this : | "x 2 3 4" =3D ("x", [2, 3, 4]) |=20 | __________________________________________________ | Do You Yahoo!? | Yahoo! Auctions - buy the things you want at great prices=20 http://auctions.yahoo.com/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell From Dominic.J.Steinitz@BritishAirways.com Mon May 28 14:05:48 2001 From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J) Date: 28 May 2001 13:05:48 Z Subject: Building Programs Again Message-ID: <"035493B124D2C001*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS> I am going to install hmake and upgrade to ghc 5 but in the meantime I decided to use make. I am puzzled however. Presumably building a module that imports a module needs the .hi file and therefore the makefile should be something like this: Tagsv1.o : Tagsv1.hs ghc -c Tagsv1.hs -package lang Basev1.o : Tagsv1.hi Basev1.hs ghc -c Basev1.hs -package lang But if I do this then make complains if I want to see what it will generate [dom@lhrtba8fd85 maketest]$ make -n ghc -c Tagsv1.hs -package lang make: *** No rule to make target `Tagsv1.hi', needed by `Basev1.o'. Stop. Running make works as by the time the rule gets executed the .hi file exists. Can anyone suggest something better? Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com From simonmar@microsoft.com Mon May 28 14:46:56 2001 From: simonmar@microsoft.com (Simon Marlow) Date: Mon, 28 May 2001 14:46:56 +0100 Subject: Building Programs Again Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD713@TVP-MSG-01.europe.corp.microsoft.com> > I am going to install hmake and upgrade to ghc 5 but in the=20 > meantime I decided to use make. >=20 > I am puzzled however. Presumably building a module that=20 > imports a module needs the .hi file and therefore the=20 > makefile should be something like this: >=20 > Tagsv1.o : Tagsv1.hs > ghc -c Tagsv1.hs -package lang >=20 > Basev1.o : Tagsv1.hi Basev1.hs > ghc -c Basev1.hs -package lang >=20 > But if I do this then make complains if I want to see what it=20 > will generate >=20 > [dom@lhrtba8fd85 maketest]$ make -n > ghc -c Tagsv1.hs -package lang > make: *** No rule to make target `Tagsv1.hi', needed by=20 > `Basev1.o'. Stop. =20 >=20 > Running make works as by the time the rule gets executed the=20 > .hi file exists. >=20 > Can anyone suggest something better? GHC's documentation has some useful tips on using make with Haskell: =09 http://www.haskell.org/ghc/docs/latest/set/separate-compilation.html#USI NG-MAKE Chees, Simon From franka@cs.uu.nl Mon May 28 15:49:31 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Mon, 28 May 2001 16:49:31 +0200 Subject: The next step In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Mon, May 28, 2001 at 10:17:03AM +0100 References: <9584A4A864BD8548932F2F88EB30D1C611589D@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: <20010528164931.B4803@cs.uu.nl> Simon Marlow wrote (on 28-05-01 10:17 +0100): > It's not propaganda. The fact is if any of the standard libraries use > the LGPL, then some people will be prevented from using them. That's > the last thing we want, right? Now you might argue from a moral > standpoint that the companies that these people work for are basing > their business models on intellectual property and therefore deserve > everything they get, but we're not trying to do open source advocacy > here, we're just trying to put together a set of libraries that everyone > can use. Some people don't see it that way. They would say that the GPL is the _less_ restrictive license because it ensures that everybody benefits (equally) from everybody else's improvements. From that perspective, companies benefit also since they may use and improve the code, provided they "publish" it. Will they lose some potential revenue that way? Possibly. But as you suggested, the idea is to make the audience as _wide_ as possible, not as _rich_ as possible. ;) -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From davidbak@cablespeed.com Mon May 28 21:25:22 2001 From: davidbak@cablespeed.com (David Bakin) Date: Mon, 28 May 2001 13:25:22 -0700 Subject: Why is there a space leak here? Message-ID: <006901c0e7b4$792c9bb0$5900a8c0@girlsprout> This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is there a space leak in foo1 but not in foo2? (I.e., in Hugs Nov = '99) foo1 eats cells (and eventually runs out) where foo2 doesn't. = That is, if I do (length (foo1 1000000)) I eventually run out of cells = but (length (foo2 1000000)) runs fine (every GC returns basically the = same amount of space). Something must be wrong in flatten but it = follows the pattern of many functions in the prelude (which I'm trying = to learn from). I have been puzzling over this for nearly a full day (getting this = reduced version from my own code which wasn't working). In general, how = can I either a) analyze code looking for a space leak or b) experiment = (e.g., using Hugs) to find a space leak? Thanks! -- Dave -- This has a space leak, e.g., when reducing (length (foo1 1000000)) foo1 m=20 =3D take m v where v =3D 1 : flatten (map triple v) triple x =3D [x,x,x] -- This has no space leak, e.g., when reducing (length (foo2 1000000)) foo2 m=20 =3D take m v where v =3D 1 : flatten (map single v) single x =3D [x] -- flatten a list-of-lists flatten :: [[a]] -> [a] flatten [] =3D [] flatten ([]:xxs) =3D flatten xxs flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs flatten' [] xxs =3D flatten xxs flatten' (x':xs') xxs =3D x': flatten' xs' xxs ------=_NextPart_000_0063_01C0E779.A61E3330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why is there a space leak in foo1 but not in = foo2? =20 (I.e., in Hugs Nov '99) foo1 eats cells (and eventually runs out) where = foo2=20 doesn't. That is, if I do (length (foo1 1000000)) I = eventually run=20 out of cells but (length (foo2 1000000)) runs fine (every GC returns = basically=20 the same amount of space). Something must be wrong in flatten but = it=20 follows the pattern of many functions in the prelude (which I'm trying = to learn=20 from). I have been puzzling over this for nearly a full day = (getting=20 this reduced version from my own code which wasn't working). In = general,=20 how can I either a) analyze code looking for a space leak or b) = experiment=20 (e.g., using Hugs) to find a space leak? Thanks! --=20 Dave -- This has a space leak, e.g., = when=20 reducing (length (foo1 1000000)) foo1 m =3D take m=20 v where v =3D 1 = : flatten=20 (map triple v) triple x =3D = [x,x,x] -- This has no space leak, = e.g., when=20 reducing (length (foo2 1000000)) foo2 m =3D take m=20 v where v =3D 1 = : flatten=20 (map single v) single x =3D = [x] -- flatten a = list-of-lists flatten ::=20 [[a]] -> [a] flatten=20 [] = ; =3D=20 [] flatten ([]:xxs) =3D flatten=20 xxs flatten ((x':xs'):xxs) =3D x' : flatten' xs' xxs flatten' []=20 xxs =3D flatten = xxs flatten' (x':xs')=20 xxs =3D x': flatten' xs' xxs ------=_NextPart_000_0063_01C0E779.A61E3330-- From jcab@roningames.com Tue May 29 02:02:09 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 18:02:09 -0700 Subject: Notation question In-Reply-To: References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> Message-ID: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Just a very naive question, because I'm really curious. I've seen in previous messages here discussions about type systems using this kind of notation: > G |- f :: all x::S . T G |- s :: S >-------------------------------------- > G |- f s :: [s/x]T I'd never seen it before, and a few searches I've launched over the net have turned up just a couple more examples of this notation, but without a single reference to how it works or what it means, or even what it's called, for that matter. I'd appreciate any pointers. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From mark@chaos.x-philes.com Tue May 29 02:24:04 2001 From: mark@chaos.x-philes.com (Mark Carroll) Date: Mon, 28 May 2001 21:24:04 -0400 (EDT) Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: On Mon, 28 May 2001, Juan Carlos Arevalo Baeza wrote: > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. (snip) I'm far from the right person to have a go, but while we're waiting for someone who knows what they're talking about: I bet that |- is 'entails'. My impression of it is rather like 'implies', but clearly that's not quite right or we wouldn't need a different term for it. The . might be 'such that'. The thing below the ----- might be a consequence of the two things above it. The [s/x]T means, probably, "T with s substituted for any occurrence of x". (Did I get that the right way around?) I hope that's a start. -- Mark From jcab@roningames.com Tue May 29 03:18:11 2001 From: jcab@roningames.com (Juan Carlos Arevalo Baeza) Date: Mon, 28 May 2001 19:18:11 -0700 Subject: Notation question In-Reply-To: References: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <4.3.2.7.2.20010528190819.03795668@207.33.235.243> At 09:24 PM 5/28/2001 -0400, Mark Carroll wrote: > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > >I'm far from the right person to have a go, but while we're waiting for >someone who knows what they're talking about: :) Thanx. >"I bet ...", "My impression of it is rather like ...", "..., but clearly >that's not quite right or ...", "... might be ...", "... means, probably, ..." > >I hope that's a start. Ufff... O:-) Sorry for pointing this out, but I couldn't resist. No offense intended. I actually appreciate your response. Really, I mean it. But it's not quite what I was looking for O:-) Anyway, I just saw that I had another reply (this on direct email, not posted to the list) with more info, so if you (or anyone) wants it just ask. Anyway, as the helpful person said about the expression above, "It's a theorem, really". Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html From dscarlett@optushome.com.au Tue May 29 04:53:44 2001 From: dscarlett@optushome.com.au (David Scarlett) Date: Tue, 29 May 2001 13:53:44 +1000 Subject: Notation question References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <00c401c0e7f2$f4f87780$0100a8c0@CO3003288A> ----- Original Message ----- From: "Juan Carlos Arevalo Baeza" To: Sent: Tuesday, May 29, 2001 11:02 AM Subject: Notation question > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > I think I've seen it (or something similar) in an imperative language called "Imp". From rjmh@cs.chalmers.se Tue May 29 08:13:37 2001 From: rjmh@cs.chalmers.se (John Hughes) Date: Tue, 29 May 2001 09:13:37 +0200 (MET DST) Subject: Notation question Message-ID: <200105290713.JAA22503@muppet30.cs.chalmers.se> > > > G |- f :: all x::S . T G |- s :: S > > >-------------------------------------- > > > G |- f s :: [s/x]T > Any more takers? I still don't have any pointers to literature where this theorem notation is explained more fully, and I'd really like to have some. This is a standard notation for describing type systems in articles on the subject -- so standard that it's hard to think of a good reference that actually explains it! However, I'd suggest looking at Michael Schwartzbach's lecture notes on Polymorphic Type Inference, which are on the web at http://www.daimi.aau.dk/~mis/typeinf.ps The typing rule notation is explained in the first couple of pages, and then used to explain many variants on type systems, show how inference works, etc. I have a collection of links to such articles at http://www.md.chalmers.se/~rjmh/tutorials.html which you might find useful. John Hughes From Andrew.Pitts@cl.cam.ac.uk Tue May 29 08:53:31 2001 From: Andrew.Pitts@cl.cam.ac.uk (Andrew Pitts) Date: Tue, 29 May 2001 08:53:31 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 09:13:37 +0200." <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: John Hughes said > > > > G |- f :: all x::S . T G |- s :: S > > > >-------------------------------------- > > > > G |- f s :: [s/x]T > > > Any more takers? I still don't have any pointers to literature where > this theorem notation is explained more fully, and I'd really like to have > some. > This is a standard notation for describing type systems in articles on the > subject -- so standard that it's hard to think of a good reference that > actually explains it! and not just type systems but also other aspects of operational semantics. What we have here is a single rule from a rule-based inductive definition of a certain relation G |- s :: S between typing environments G, expressions s and types S. I seem to spend half my life using such inductive definitions and the other half teaching them to undergraduates (and the third half doing university administration, hey ho). Casting modesty aside, to read about such things let me recommend lecture notes on operational semantics (esp section 2.3) Andy Pitts From franka@cs.uu.nl Tue May 29 11:39:56 2001 From: franka@cs.uu.nl (Frank Atanassow) Date: Tue, 29 May 2001 12:39:56 +0200 Subject: Notation question In-Reply-To: <4.3.2.7.2.20010528175808.037514f8@207.33.235.243>; from jcab@roningames.com on Mon, May 28, 2001 at 06:02:09PM -0700 References: <20010516073806.A29103@theseus.mathematik.uni-ulm.de> <4.3.2.7.2.20010528175808.037514f8@207.33.235.243> Message-ID: <20010529123956.B5078@cs.uu.nl> Juan Carlos Arevalo Baeza wrote (on 28-05-01 18:02 -0700): > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-------------------------------------- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > > I'd appreciate any pointers. May I also recommend my PL theory references page?: http://www.cs.uu.nl/people/franka/ref.html BTW, here is the quick version: It says: Suppose term f has type all x::S.T in free variable environment G. Suppose further that term s has type S in environment G. Then the term f s has type [s/x]T (T with s substituted for x) in environment G. But this in itself is really not very meaningful unless you assume some standard definitions. For example, there should be rules for introducing variables, introducing/eliminating "all" types, manipulating environments, a definition for substitution, etc. -- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 From Jon.Fairbairn@cl.cam.ac.uk Tue May 29 11:44:08 2001 From: Jon.Fairbairn@cl.cam.ac.uk (Jon Fairbairn) Date: Tue, 29 May 2001 11:44:08 +0100 Subject: Notation question In-Reply-To: Your message of "Tue, 29 May 2001 08:53:31 BST." Message-ID: <23944.991133048@cl.cam.ac.uk> > and not just type systems but also other aspects of operational > semantics. What we have here is a single rule from a rule-based > inductive definition of a certain relation G |- s :: S between typing > environments G, expressions s and types S. It's probably worth mentioning here that this notation originated (I think) in mathematical logic, as a way of presenting formal systems. Try "Gentzen", "Natural Deduction" and "Sequent Calculus" as search terms. J=F3n From Phil Trinder Tue May 29 15:24:35 2001 From: Phil Trinder (Phil Trinder) Date: Tue, 29 May 2001 15:24:35 +0100 (GMT Daylight Time) Subject: SFP Call for Participation Message-ID: CALL FOR PARTICIPATION 3rd Scottish Functional Programming Workshop University of Stirling Aug 22nd-24th, 2001 You are invited to participate in the 3rd Scottish Functional Programming Workshop. The draft programme is below, and both registration form and additional information are available at: http://www.cee.hw.ac.uk/~greg/sfp3/ SFP'3 Draft Programme ===================== Parallelism ----------- A Comparative Study of Skeleton-based Parallel Programming Environments Allowing Arbitrary Nesting Remi Coudarcher, Jocelyn Serot, Jean-Pierre Derutin Universite Blaise Pascal - Clermont II, France BSP in a Lazy Functional Context Quentin Miller Universite d'Orleans, France Parallel Functional Genetic Programming Graeme McHale and Greg Michaelson Heriot-Watt University, Scotland Introduction of Pipelining into Gaussian Elimination Joy Goodman Glasgow University, Scotland The Efficiency of Parallel Graph Reduction on a Loosely-coupled Multiprocessor Hans Wolfgang Loidl An SPMD environment machine for functional BSP programs Armelle Merlin, Gaetan Hains Universite d'Orleans, France Implementing and Measuring GdH Skeletons Phil Trinder Heriot-Watt University, Scotland Distribution ------------ Distributed Programming with Dynamic Reply Channels Rita Loogen, Steffen Priebe Philips-Universitat Marburg, Germany Distributed Applications in GdH Robert Pointon Heriot-Watt University, Scotland Applications ------------ Haskell: Language for Business Systems Dominic Steinitz, British Airways Chris Reade, Dan Russell, Phil Molyneux, Barry Avery Kingston Business School, England Functional programming languages for verification tools: experiences with ML and Haskell Martin Leucker, Thomas Noll, Perdita Stevens, Michael Weber RWTCH Aachen, Germany/University of Edinburgh, Scotland Infinite Pretty Printing in eXene Allen Stoughton Kansas State University, USA Derivation and Transformation ----------------------------- Extending Higher-Order Deforestation: Transforming Programs to Eliminate Even More Trees Geoff Hamilton, Dublin City University, Ireland Deriving Non-heirarchical Process Topologies Ricardo Pena, Fernando Rubio, Clara Segura Universidad Complutense de Madrid, Spain Language Design and Implementation ---------------------------------- Some Experiences Connecting Functional Languages and Java Andre Rauber Du Bois, Antonio Carlos da Rocha Costa Universidade Federal do Rio Grande do Sul/ Universidade Catolica de Pelotas, Brazil Paging Behaviour of List-based Memory in a Distributed Virtual Memory System for Pure Functional Languages Marco T. Morazan and Douglas R. Troeger City University of New York, USA Types ----- How to Fix Type Errors Automatically Bruce J. McAdam University of Edinburgh, Scotland Function Types and Complete type Inference Manfred Widera, Christoph Bierle Fern Universitat Hagen, Germany Human-like Explanations of Polymorphic Types Yang Jun, Greg Michaelson, Phil Trinder Heriot-Watt University, Scotland Theory ------ The dual of grafting is decoration Tarmo Uustalu, Varmo Vene Universidade do Minho, Portugal University of Tartu, Estonia Towards a Denotational semantics for Eden Mercedes Hidalgo-Herrero, Yolanda Ortega-Mallen Universidad Complutense de Madrid, Spain From thor-list-haskell@banyan.moertel.com Tue May 29 16:35:41 2001 From: thor-list-haskell@banyan.moertel.com (Tom Moertel) Date: Tue, 29 May 2001 11:35:41 -0400 Subject: Notation question References: <200105290713.JAA22503@muppet30.cs.chalmers.se> Message-ID: <3B13C1CD.2AC0CEBA@banyan.moertel.com> Another introduction, with emphasis on the historical development: Philip Wadler, "Proofs are Programs: 19th Century Logic and 21st Century Computing." http://www.cs.bell-labs.com/who/wadler/topics/history.html It's a fun read, too. Cheers, Tom From tullsen@cs.yale.edu Tue May 29 17:48:52 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Tue, 29 May 2001 12:48:52 -0400 Subject: Recursive types? References: <6605DE4621E5934593474F620A14D70001EDEB3A@red-msg-07.redmond.corp.microsoft.com> <15113.52727.506242.598828@waytogo.peace.co.nz> Message-ID: <3B13D2F4.F525CFDC@cs.yale.edu> Tom Pledger wrote: > I don't know whether this is a shining example of an advantage, > and am keen to see other comments. For what it's worth, I've pulled some snippets from some code I wrote. I wanted three recursive types which were nearly identical (Exp,ExpQv,ExpPr). Rather than write three different type declarations data Exp = ... data ExpQv = ... data ExpPr = ... I was able to abstract out the commonality into one non-recursive type data FctrExp a = ... Note how concise some of my "Sample Functions" can be. These would have been very long and ugly to write were I to use the first approach. At the expense of now using a "two-level" type, I've gained some expressiveness. - Mark ---- Fix Type ----------------------------------------------------------------- data Fix f = In (f (Fix f)) class FixEq f where fixEq :: Eq a => (f a -> f a -> Bool) class FixShow f where fixShowsPrec :: Show a => (Int -> f a -> ShowS) instance FixEq f => Eq (Fix f) where (==) (In x) (In y) = fixEq x y instance FixShow f => Show (Fix f) where showsPrec p (In x) = showString "In (" . fixShowsPrec p x . showChar ')' ---- Types for Documentation -------------------------------------------------- type Var = String type Env x = [(Var,x)] type Pat = Exp type Type = Exp ---- Form & FormPr Related Types --------------------------------------------- type Qv = (Exp,Exp) data Pr = Pstep (ExpPr,Justifier,ExpPr) | Pletu (Var, Type, ExpPr) deriving(Show,Eq) data Justifier = Stub1 deriving (Show,Eq) ---- Exp,ExpPr,ExpQv Types ---------------------------------------------------- data Ftype = Stub2 deriving (Show,Eq) data Ltype = Stub3 deriving (Show,Eq) data Const = Stub4 deriving (Show,Eq) data FctrExp a = Econ Const | Evar Var | Eapp (Ftype, a, a) | Elet (Ltype, Pat, Type, a, a) -- let x:t=e1 in e2 | Elam (Ftype, Pat, Type, a) -- \x:t=>e | Eqnt (Ftype, Pat, Type, a) -- |~|x:t=>e | Etup [a] -- | Emu a | Ecase a -- case e | Ein (a,a) -- In i e deriving (Show,Eq) data FctrExpQv a = ExpQvExp (FctrExp a) | ExpQvQv Qv deriving (Show,Eq) data FctrExpPr a = ExpPrExp (FctrExp a) | ExpPrPr Pr deriving (Show,Eq) type Exp = Fix FctrExp type ExpQv = Fix FctrExpQv type ExpPr = Fix FctrExpPr ---- Define Appropriate Functors ---------------------------------------------- instance Functor FctrExp where fmap = fmapFctrExp fmapFctrExp :: (a->b) -> (FctrExp a -> FctrExp b) fmapFctrExp f e = case e of Econ x -> Econ x Evar x -> Evar x Eapp (x,e1,e2) -> Eapp (x,f e1, f e2) Elet (x,v,t,y,z) -> Elet (x,v,t,f y,f z) Elam (x,v,t,e) -> Elam (x,v,t,f e) Eqnt (x,v,t,e) -> Eqnt (x,v,t,f e) Etup es -> Etup (map f es) Emu e -> Emu (f e) Ecase e -> Ecase (f e) Ein (i,e) -> Ein (f i,f e) ---- Make Exp,ExpQv,ExpPr instances of Show and Eq ---------------------------- instance FixEq FctrExp where fixEq = (==) instance FixShow FctrExp where fixShowsPrec = showsPrec instance FixEq FctrExpQv where fixEq = (==) instance FixShow FctrExpQv where fixShowsPrec = showsPrec instance FixEq FctrExpPr where fixEq = (==) instance FixShow FctrExpPr where fixShowsPrec = showsPrec ---- Sample Functions --------------------------------------------------------- expToExpPr :: Exp -> ExpPr expToExpPr (In x) = In (ExpPrExp (fmap expToExpPr x)) firstExpPr, finalExpPr :: ExpPr -> Exp firstExpPr (In x) = case x of ExpPrExp e -> In $ fmap firstExpPr e ExpPrPr (Pstep (p,_,_)) -> firstExpPr p ExpPrPr (Pletu _) -> error "firstExpPr" finalExpPr (In x) = case x of ExpPrExp e -> In $ fmap finalExpPr e ExpPrPr (Pstep (_,_,p)) -> finalExpPr p ExpPrPr (Pletu _) -> error "finalExpPr" From awfurtado@uol.com.br Wed May 30 02:04:02 2001 From: awfurtado@uol.com.br (Andre W B Furtado) Date: Tue, 29 May 2001 22:04:02 -0300 Subject: Announcement: new HOpenGL Tutorial Message-ID: <00a401c0e8a4$7101d540$bd30e3c8@windows9> This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there. I've just released the first version of my HOpenGL (Haskell = Open Graphics Library) tutorial. I hope it will encourage (and help) = people around the world to use this great library/binding. I also would = like to hear some feedback from you. You can visit the tutorial at: www.cin.ufpe.br/~haskell/hopengl/ Thank you, Andre W B Furtado ------=_NextPart_000_009C_01C0E88B.44EDB0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there. I've just released the = first version=20 of my HOpenGL (Haskell Open Graphics Library) tutorial. I hope it = will=20 encourage (and help) people around the world to use this great = library/binding.=20 I also would like to hear some feedback from you. You can visit the = tutorial=20 at: www.cin.ufpe.br/~haskel= l/hopengl/ Thank you, Andre W B = Furtado ------=_NextPart_000_009C_01C0E88B.44EDB0A0-- From simonpj@microsoft.com Wed May 30 11:37:10 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 03:37:10 -0700 Subject: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Folks, I'm about to put out (what I hope is) the final revised Haskell98 report. Here, though, is one good point I propose to clarify. I propose to say that every H98 impl must support tuples up to size 7 and their instances for Eq, Ord, Bounded, Read, Show [Of course, one might hope that impls would do better, but the report should be conservative.] Simon | -----Original Message----- | From: Olaf Chitil [mailto:olaf@cs.york.ac.uk]=20 | Sent: 23 April 2001 12:11 | To: nhc-users@cs.york.ac.uk | Cc: haskell@haskell.org; Simon Peyton-Jones | Subject: Re: Eq instance for (a,b,c,d,e) and upwards |=20 |=20 |=20 | I think that this discussion about tuples shows that there is=20 | a problem with the Haskell 98 report which should be=20 | corrected. I hope Simon accepts it as a minor bug fix. |=20 | 1) The current wording of paragraph 6.1.4 is highly ambigious. |=20 | > 6.1.4 Tuples | > =20 | > Tuples are algebraic datatypes with special syntax, as defined | > in Section 3.8. Each tuple type has a single constructor. There | > is no upper bound on the size of a tuple. However, some Haskell | > implementations may restrict the size of tuples and limit the | > instances associated with larger tuples. The Prelude and=20 | libraries | > define tuple functions such as zip for tuples up to a=20 | size of 7. All | > tuples are instances of Eq, Ord, Bounded, Read, and Show. Classes | > defined in the libraries may also supply instances for=20 | tuple types. |=20 | May the limit for the size of tuples and the limit for=20 | instances be different? Do tuples exist at least for a size=20 | up to 7? What is the purpose of the last sentence? |=20 | We should decide what we want and the paragraph should then=20 | state it clearly. |=20 | 2) The arbitrary restrictions that Haskell implementations=20 | are permitted to apply, basically imply that you shouldn't=20 | use tuples at all if you want your code to be portable. Maybe=20 | there isn't even a Show instance for ()? |=20 | So I think the report should demand that tuples and instances=20 | for Eq,Ord,Bounded,Read and Show should be implemented for at=20 | least up to a size of a given number n. |=20 | 3) I propose this number n to be 7. This fits well with the=20 | fact that zip etc are defined for tuples up to a size of 7. I=20 | agree with Martin that you should use a labelled record or at=20 | least an own type instead of large tuples anyway.=20 | Programs that generate code should als generate definitions=20 | for data types, if large product types are needed.=20 |=20 | Olaf |=20 | --=20 | OLAF CHITIL,=20 | Dept. of Computer Science, University of York, York YO10 5DD, UK.=20 | URL: http://www.cs.york.ac.uk/~olaf/ | Tel: +44 1904 434756; Fax: +44 1904 432767 |=20 From simonpj@microsoft.com Wed May 30 12:08:26 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 04:08:26 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Folks I've finished what I hope is the final version of the Haskell 98=20 Language and Library Reports http://research.microsoft.com/~simonpj/haskell98-revised However, experience shows that bug fixes are often themselves buggy, so I urge you, once again, to take a look at your favourite passages and check they are correct. As ever, there's a complete list of changes at the above URL, with the ones I've made since the April release identified for your pleasure. Comments (hopefully vanishingly few) by 15 June please. Thanks very much Simon From rjljr2@yahoo.com Wed May 30 12:27:01 2001 From: rjljr2@yahoo.com (Ronald Legere) Date: Wed, 30 May 2001 04:27:01 -0700 (PDT) Subject: Announcement: new HOpenGL Tutorial In-Reply-To: <00a401c0e8a4$7101d540$bd30e3c8@windows9> Message-ID: <20010530112701.62154.qmail@web10006.mail.yahoo.com> Looks great! I think the community will really appreciate it. I will have to 'give it a whirl' myself, if I can ever get HOpenGL to compile on my solaris sparc. (I keep having trouble with 'test' in the makefiles. I must have a wierd version of test or something. I am no OS guru :) (If anyone has ever seen this problem, let me know ) Cheers! --- Andre W B Furtado wrote: > Hello there. I've just released the first version of > my HOpenGL (Haskell Open Graphics Library) tutorial. > I hope it will encourage (and help) people around > the world to use this great library/binding. I also > would like to hear some feedback from you. You can > visit the tutorial at: > > www.cin.ufpe.br/~haskell/hopengl/ > > Thank you, > Andre W B Furtado > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From tullsen@cs.yale.edu Wed May 30 17:04:49 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 12:04:49 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D72FF2@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B151A21.BD5CA994@cs.yale.edu> Simon Peyton-Jones wrote: > > Folks > > I've finished what I hope is the final version of the Haskell 98 > Language and Library Reports > http://research.microsoft.com/~simonpj/haskell98-revised > > However, experience shows that bug fixes are often themselves > buggy, so I urge you, once again, to take a look at your favourite > passages and check they are correct. > > As ever, there's a complete list of changes at the above URL, > with the ones I've made since the April release identified for your > pleasure. > > Comments (hopefully vanishingly few) by 15 June please. Simon, Sorry to get this comment in so late, but it is a small change. In the List module, the type signature for deleteBy is not as general as it could be, given the definition. It could be generalized to the following (no change to the definition): deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] I've found it usefully used at this more general type. Thanks. - Mark From simonpj@microsoft.com Wed May 30 17:46:53 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Wed, 30 May 2001 09:46:53 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> | Sorry to get this comment in so late, but it is a small=20 | change. In the List module, the type signature for deleteBy=20 | is not as general as it could be, given the definition. It=20 | could be generalized to the following (no change to the definition): |=20 | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] |=20 | I've found it usefully used at this more general type. Indeed, and=20 deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] I can't see any reason not to do this. Furthermore, the Report omits to export deleteFirstsBy, though GHC and Hugs both remember to do so. Simon From ross@soi.city.ac.uk Wed May 30 17:57:08 2001 From: ross@soi.city.ac.uk (Ross Paterson) Date: Wed, 30 May 2001 17:57:08 +0100 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FFC@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010530175708.A3688@soi.city.ac.uk> On Wed, May 30, 2001 at 09:46:53AM -0700, Simon Peyton-Jones wrote: > | Sorry to get this comment in so late, but it is a small > | change. In the List module, the type signature for deleteBy > | is not as general as it could be, given the definition. It > | could be generalized to the following (no change to the definition): > | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > | > | I've found it usefully used at this more general type. > > Indeed, and > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] and intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] From zhanyong.wan@yale.edu Wed May 30 18:41:49 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 13:41:49 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3B1530DC.AAC1220D@yale.edu> Hello Simon, Looking at the definition for deleteBy: deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] deleteBy eq x [] = [] deleteBy eq x (y:ys) = if x `eq` y then ys else y : deleteBy eq x ys I can't help wondering why it isn't deleteBy' :: (a -> Bool) -> [a] -> [a] deleteBy' f [] = [] deleteBy' f (y:ys) = if f y then ys else y : deleteBy' f ys The point is that in the definition of deleteBy, all references to eq and x are in the form (eq x), and hence the two parameters can be combined. Is there a reason that the current design was favored when Prelude was designed? Thanks. - Zhanyong -- # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ # Yale University, Dept of Computer Science /\___\ # P.O.Box 208285, New Haven, CT 06520-8285 ||___| From Malcolm.Wallace@cs.york.ac.uk Wed May 30 18:37:47 2001 From: Malcolm.Wallace@cs.york.ac.uk (Malcolm Wallace) Date: Wed, 30 May 2001 18:37:47 +0100 Subject: Haskell 98 Report In-Reply-To: <20010530175708.A3688@soi.city.ac.uk> Message-ID: <3FkAAOsvFTt4cwoA@cs.york.ac.uk> > > | It could be generalized to the following (no change to the definition): > > | > > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] > > > > Indeed, and > > > > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] > > and > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Although curiously, its dual 'unionBy' cannot also take the more general type unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] at least, not with its current specification in terms of 'nubBy'. Regards, Malcolm From Tom.Pledger@peace.com Wed May 30 21:16:44 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 08:16:44 +1200 Subject: Haskell 98 Report In-Reply-To: <3B1530DC.AAC1220D@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <15125.21804.829456.439929@waytogo.peace.co.nz> Zhanyong Wan writes: : | I can't help wondering why it isn't | | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] = [] | deleteBy' f (y:ys) = if f y then ys else | y : deleteBy' f ys deleteBy'' f = filter (not . f) Malcolm Wallace writes: : | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | Although curiously, its dual 'unionBy' cannot also take the more | general type | | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] | | at least, not with its current specification in terms of 'nubBy'. That suggests a reason to leave the type of intersectBy alone - the generalisation would arbitrarily favour the first list's type over the second list's type. To me, the word "intersect" implies symmetry. - Tom From zhanyong.wan@yale.edu Wed May 30 22:15:48 2001 From: zhanyong.wan@yale.edu (Zhanyong Wan) Date: Wed, 30 May 2001 17:15:48 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> Message-ID: <3B156304.BD9F41F8@yale.edu> Tom Pledger wrote: > > Zhanyong Wan writes: > : > | I can't help wondering why it isn't > | > | deleteBy' :: (a -> Bool) -> [a] -> [a] > | deleteBy' f [] = [] > | deleteBy' f (y:ys) = if f y then ys else > | y : deleteBy' f ys > > deleteBy'' f = filter (not . f) No. deleteBy' f only deletes the *first* element that satisfies the predicate f, while filter (not . f) deletes *all* such elements. -- Zhanyong From Tom.Pledger@peace.com Wed May 30 22:25:53 2001 From: Tom.Pledger@peace.com (Tom Pledger) Date: Thu, 31 May 2001 09:25:53 +1200 Subject: Haskell 98 Report In-Reply-To: <3B156304.BD9F41F8@yale.edu> References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> <15125.21804.829456.439929@waytogo.peace.co.nz> <3B156304.BD9F41F8@yale.edu> Message-ID: <15125.25953.715929.236763@waytogo.peace.co.nz> Zhanyong Wan writes: | Tom Pledger wrote: : | > deleteBy'' f = filter (not . f) | | No. deleteBy' f only deletes the *first* element that satisfies the | predicate f, while filter (not . f) deletes *all* such elements. Oops. Sorry. I ought to become less SQL-oriented... From tullsen@cs.yale.edu Thu May 31 00:59:44 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Wed, 30 May 2001 19:59:44 -0400 Subject: Haskell 98 Report References: <20010530175708.A3688@soi.city.ac.uk> <3B1530DC.AAC1220D@yale.edu> Message-ID: <3B158970.9C5D11EE@cs.yale.edu> Zhanyong Wan wrote: > > Hello Simon, > > Looking at the definition for deleteBy: > > deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] > deleteBy eq x [] = [] > deleteBy eq x (y:ys) = if x `eq` y then ys else > y : deleteBy eq x ys > > I can't help wondering why it isn't > > deleteBy' :: (a -> Bool) -> [a] -> [a] > deleteBy' f [] = [] > deleteBy' f (y:ys) = if f y then ys else > y : deleteBy' f ys > > The point is that in the definition of deleteBy, all references to eq > and x are in the form (eq x), and hence the two parameters can be > combined. Is there a reason that the current design was favored when > Prelude was designed? Thanks. > > - Zhanyong Zhanyong, I didn't mean to open up a can of worms! Although, when viewed in isolation, it would make sense to change deleteBy as you suggest; but when we look at the conventions of the List module, I think that it would be undesirable, even if we didn't care about breaking programs, because it would break the "xBy" convention described below. Originally we had this: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] And all the functions "x" with a "xBy" form have types which are related in a particular way, for some functor f: x :: Eq a => f a xBy :: (a -> a -> Bool) -> f a Now, if we generalize the type of deleteBy as I previously suggested, we have these two types: delete :: Eq a => a -> [a] -> [a] deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] And it is still the case that functions "x" and "xBy" have types which are related as follows (generalizing the rule): x :: Eq a => f a a xBy :: (a -> b -> Bool) -> f a b (Where we would instantiate 'b' to 'a' for "xBy" functions which have a less general type.) - Mark From nilsson@cs.yale.edu Thu May 31 03:07:29 2001 From: nilsson@cs.yale.edu (Henrik Nilsson) Date: Wed, 30 May 2001 22:07:29 -0400 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> Message-ID: <3B15A761.8C3F418C@cs.yale.edu> Hi, Simon Peyton-Jones wrote: > Folks, > > I'm about to put out (what I hope is) the final revised Haskell98 > report. > > Here, though, is one good point I propose to clarify. I propose to > say that > > every H98 impl must support tuples up to size 7 > and their instances for Eq, Ord, Bounded, Read, Show > > > [Of course, one might hope that impls would do better, but the report > should be conservative.] Clearly, the report has to state the minimal bound. And I agree that 7 is a choice which is consistent with the current Prelude. However, 7 is also a number which is uncomfortably close to what I've seen in real code and used myself. Yes, one might hope that this is a non issue, since all implementations I'm aware of does considerably better anyway. But if one wants to write portable code, it does become an issue. And yes, one could argue that records or user-defined product types should be used anyway. But that is really a matter of taste, and I'd say that there are reasonable examples where forcing the user to introduce a product type just to wrap up a bunch of values would harm rather than improve the readability. So, if, in the interest of being conservative, the stated minimal bound cannot be "infinity", could it at least be a great deal bigger than what reasonably would be used in *hand-written* code? Say 15. An arbitrary choice, of course, but it is not excessive from an implementation perspective, yet large enough that I cannot imagine hand-written code getting close to the limit. Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu From ralf@informatik.uni-bonn.de Thu May 31 08:20:43 2001 From: ralf@informatik.uni-bonn.de (Ralf Hinze) Date: Thu, 31 May 2001 09:20:43 +0200 Subject: Eq instance for (a,b,c,d,e) and upwards References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> Message-ID: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal > bound cannot be "infinity", could it at least be a great deal > bigger than what reasonably would be used in *hand-written* > code? Say 15. An arbitrary choice, of course, but it is not > excessive from an implementation perspective, yet large enough > that I cannot imagine hand-written code getting close to the > limit. I second Henrik here, 15 is much better than 7. Cheers, Ralf From chak@cse.unsw.edu.au Thu May 31 08:21:52 2001 From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty) Date: Thu, 31 May 2001 17:21:52 +1000 Subject: Eq instance for (a,b,c,d,e) and upwards In-Reply-To: <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> References: <37DA476A2BC9F64C95379BF66BA26902D72FF0@red-msg-09.redmond.corp.microsoft.com> <3B15A761.8C3F418C@cs.yale.edu> <3B15F0CB.2AA67E5B@informatik.uni-bonn.de> Message-ID: <20010531172152T.chak@cse.unsw.edu.au> Ralf Hinze wrote, > Henrik Nilsson wrote: > > > So, if, in the interest of being conservative, the stated minimal > > bound cannot be "infinity", could it at least be a great deal > > bigger than what reasonably would be used in *hand-written* > > code? Say 15. An arbitrary choice, of course, but it is not > > excessive from an implementation perspective, yet large enough > > that I cannot imagine hand-written code getting close to the > > limit. > > I second Henrik here, 15 is much better than 7. I agree. Manuel From simonpj@microsoft.com Thu May 31 08:58:58 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:58:58 -0700 Subject: FW: Eq instance for (a,b,c,d,e) and upwards Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73004@red-msg-09.redmond.corp.microsoft.com> Henrik Nilsson wrote: > So, if, in the interest of being conservative, the stated minimal=20 > bound cannot be "infinity", could it at least be a great deal bigger=20 > than what reasonably would be used in *hand-written* code? Say 15. An=20 > arbitrary choice, of course, but it is not excessive from an=20 > implementation perspective, yet large enough that I cannot imagine=20 > hand-written code getting close to the limit. A fair point. If you care either way, send me a note. (Not to the list.) Henrik leaves open the question of which tuple *instances* you can rely on. Up to 7, like zip and friends? Or up to 15? By analogy with the zip functions, I think I'd go for 7. Again, let me know, but don't trouble the list unless you want to raise a new point. Simon From simonpj@microsoft.com Thu May 31 08:53:50 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:53:50 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> | > | deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] | > |=20 | > | I've found it usefully used at this more general type. | >=20 | > Indeed, and | >=20 | > deleteFirstsBy :: (a -> b -> Bool) -> [b] -> [a] -> [b] |=20 | and |=20 | intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] Indeed. We should either generalise all three deleteBy deleteFirstsBy intersectBy or none. In favour: the more general types are occasionally useful no programs stop working Against it's an unforced change perhaps some error message may get more obscure Tom wrote | That suggests a reason to leave the type of intersectBy alone=20 | - the generalisation would arbitrarily favour the first=20 | list's type over the second list's type. To me, the word=20 | "intersect" implies symmetry. The point is that you can always use it at the symmetrical type too. This isn't a big issue, or I would not be considering it at this point. So I solicit feedback, and will then just decide something. Simon From simonpj@microsoft.com Thu May 31 08:43:13 2001 From: simonpj@microsoft.com (Simon Peyton-Jones) Date: Thu, 31 May 2001 00:43:13 -0700 Subject: Haskell 98 Report Message-ID: <37DA476A2BC9F64C95379BF66BA26902D73000@red-msg-09.redmond.corp.microsoft.com> I don't think there was a deep reason, but the current story makes it more like the other 'By' functions. Anyway, this is one thing that is not going to change! (Not that you were proposing that it should.) Simon | -----Original Message----- | From: Zhanyong Wan [mailto:zhanyong.wan@yale.edu]=20 | Sent: 30 May 2001 18:42 | To: Simon Peyton-Jones | Cc: haskell@haskell.org | Subject: Re: Haskell 98 Report |=20 |=20 | Hello Simon, |=20 | Looking at the definition for deleteBy: |=20 | deleteBy :: (x -> a -> Bool) -> x -> [a] -> [a] | deleteBy eq x [] =3D [] | deleteBy eq x (y:ys) =3D if x `eq` y then ys else | y : deleteBy eq x ys |=20 | I can't help wondering why it isn't |=20 | deleteBy' :: (a -> Bool) -> [a] -> [a] | deleteBy' f [] =3D [] | deleteBy' f (y:ys) =3D if f y then ys else | y : deleteBy' f ys |=20 | The point is that in the definition of deleteBy, all=20 | references to eq and x are in the form (eq x), and hence the=20 | two parameters can be combined. Is there a reason that the=20 | current design was favored when Prelude was designed? Thanks. |=20 | - Zhanyong |=20 | --=20 | # Zhanyong Wan http://pantheon.yale.edu/~zw23/ ____ | # Yale University, Dept of Computer Science /\___\ | # P.O.Box 208285, New Haven, CT 06520-8285 ||___| |=20 From S.J.Thompson@ukc.ac.uk Thu May 31 13:40:54 2001 From: S.J.Thompson@ukc.ac.uk (S.J.Thompson) Date: Thu, 31 May 2001 13:40:54 +0100 Subject: Teaching Assistantships in the Computing Lab, University of Kent Message-ID: Haskellers welcome! Simon Teaching Assistantships in the Computing Lab, University of Kent Applications are invited for two posts of teaching assistant in the Computing Laboratory at the University of Kent. These posts are for a fixed-term period of four years and are intended to support postgraduate researchers during their period of registration for a part-time PhD in one of the research groups in the Computing Laboratory. The successful applicants will be required to participate in up to eight hours teaching per week during academic terms. Applicants will be expected to provide evidence of their experience in teaching or equivalent activities. Total remuneration is at the rate of 13,231 GBP per annum, made up of 6931 GBP salary and 6300 GBP PhD bursary; PhD fees are paid in addition to this. Application procedure Applications should be sent by email to the professorial secretary, Mrs Jenny Oatley, jao@ukc.ac.uk, with the subject line 'Teaching Assistant Application'. Applications should include - A brief curriculum vitae, detailing - educational history and qualifications; - employment history; - details of teaching experience, if any; - country of residence, native language (if not English please include TOEFL/IELTS score). - A statement of your proposed research project, including the research group in which that research project lies. - Names, addresses and email addresses of two academic referees. The deadline for applications is 21 June 2001, and interviews will take place on 28 June 2001. Applicants who are unable to attend interviews may be asked for telephone interview. From joshuag@ozemail.com.au Thu May 31 17:02:37 2001 From: joshuag@ozemail.com.au (Joshua Ginges) Date: Fri, 01 Jun 2001 02:02:37 +1000 Subject: Dividing floats Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3074205757_1755708 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Can anyone please help me. How can you divide two floats? (and return a float, even if they divide equally) Ie (something like...) div 2.4 1.2 ---> 2.0 Thanks Josh --B_3074205757_1755708 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Dividing floats Can anyone please help me. How can you divide two floats? (and return a float, even if they divide equ= ally) Ie (something like...) div 2.4 1.2 ---> 2.0 Thanks Josh --B_3074205757_1755708-- From djrussell@kingston.ac.uk Thu May 31 17:25:46 2001 From: djrussell@kingston.ac.uk (Daniel Russell) Date: Thu, 31 May 2001 17:25:46 +0100 (BST) Subject: Dividing Floats Message-ID: <200105311625.RAA08117@helios.king.ac.uk> > Can anyone please help me. > How can you divide two floats? (and return a float, even if they divide > equally) > Ie (something like...) div 2.4 1.2 ---> 2.0 The above doesn't work since div can only be applied to integral numbers: div :: Integral a => a -> a -> a What you need is the operator (/) which can only be applied to fractional numbers: (/) :: Fractional a => a -> a -> a For example: 2.4 / 1.2 ---> 2.0 or (/) 2.4 1.2 ---> 2.0 Dan Russell Kingston University From fjh@cs.mu.oz.au Thu May 31 19:19:23 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 04:19:23 +1000 Subject: Haskell 98 Report In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> Message-ID: <20010601041923.A10308@hg.cs.mu.oz.au> On 31-May-2001, Simon Peyton-Jones wrote: > We should either generalise all three > deleteBy > deleteFirstsBy > intersectBy > or none. > > In favour: > the more general types are occasionally useful > no programs stop working Actually some programs will stop working, because the types will be underconstrained, so the compiler won't know how to satisfy some type class constraint. For example: import List main = print (deleteBy (\x _y -> x > 0) 1 []) With the generalized type, you'd get an unresolved `Show' constraint. The number of real programs for which this is a problem is most likely very small, and the work-around (typically just adding an explicit type qualification) is not hard once you understand what the problem is, but figuring out what the problem is could take some time. Since it does break some obscure programs, and since it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature, my preference would be to leave this out of Haskell 98, but include it in the next version of Haskell. (It would be good for someone, perhaps Simon P-J., to keep a list of issues like this which have been left out of Haskell 98 due to backwards compatibility concerns, so that they don't get forgotten about when it comes to time for the next version.) -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From C.Reinke@ukc.ac.uk Thu May 31 19:48:24 2001 From: C.Reinke@ukc.ac.uk (C.Reinke) Date: Thu, 31 May 2001 19:48:24 +0100 Subject: Haskell 98 Report In-Reply-To: Message from Fergus Henderson of "Fri, 01 Jun 2001 04:19:23 +1000." <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: "..it's easy enough for programmers who want a generalized version to just cut and paste the code from the Haskell report and give it a more general type signature,.." Fergus Henderson, June 2001 Is this definition of reuse in Haskell quotable?-) Claus From tullsen@cs.yale.edu Thu May 31 20:04:02 2001 From: tullsen@cs.yale.edu (Mark Tullsen) Date: Thu, 31 May 2001 15:04:02 -0400 Subject: Haskell 98 Report References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: <3B1695A2.2318EBC0@cs.yale.edu> So much for my small, innocuous, non controversial suggestion :-). Fergus Henderson wrote: > > On 31-May-2001, Simon Peyton-Jones wrote: > > We should either generalise all three > > deleteBy > > deleteFirstsBy > > intersectBy > > or none. > > > > In favour: > > the more general types are occasionally useful > > no programs stop working > > Actually some programs will stop working, because the types will be > underconstrained, so the compiler won't know how to satisfy some type class > constraint. > > For example: > > import List > main = print (deleteBy (\x _y -> x > 0) 1 []) > > With the generalized type, you'd get an unresolved `Show' constraint. That's a good point Fergus, I hadn't noticed the potential problem here. > The number of real programs for which this is a problem is most likely very > small, and the work-around (typically just adding an explicit type > qualification) is not hard once you understand what the problem is, but > figuring out what the problem is could take some time. My intuition (whatever it's worth) tells me that the real programs that would be affected are close to nil. Would you agree? > Since it does break some obscure programs, and since it's easy enough > for programmers who want a generalized version to just cut and paste > the code from the Haskell report and give it a more general type signature, Sure, it's easy enough, but one of the reasons I like Haskell so much over languages like C is that I almost never have to resort to programming by "cut and paste". I generally prefer to give the most general type signature for each definition. It makes programs more robust. It gives a stronger "free theorem"; in other words, I can tell more about the function by just looking at the type. For instance ... Tom Pledger wrote: > Malcolm Wallace writes: > : > | > intersectBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | Although curiously, its dual 'unionBy' cannot also take the more > | general type > | > | unionBy :: (a -> b -> Bool) -> [a] -> [b] -> [a] > | > | at least, not with its current specification in terms of 'nubBy'. > > That suggests a reason to leave the type of intersectBy alone - the > generalisation would arbitrarily favour the first list's type over the > second list's type. To me, the word "intersect" implies symmetry. But to me it seems a good reason to change the type of intersectBy: the definition isn't really symmetric, so why should the type signature be symmetric? - Mark From fjh@cs.mu.oz.au Thu May 31 22:20:10 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 1 Jun 2001 07:20:10 +1000 Subject: Haskell 98 Report In-Reply-To: References: Message-ID: <20010601072010.A10659@hg.cs.mu.oz.au> On 31-May-2001, C.Reinke wrote: > > "..it's easy enough for programmers who want a generalized version to just cut > and paste the code from the Haskell report and give it a more general type > signature,.." > > Fergus Henderson, June 2001 > > Is this definition of reuse in Haskell quotable?-) Sure, feel free to go ahead and quote it (you just did already ;-). But it's taken a little out of context. Certainly I wouldn't recommend that as a method of code reuse in ordinary cases, let alone posit it as a _definition_ of reuse. However, in this particular case, where the algorithm is fairly trivial, and the code is well tested, the costs of cut-and-paste reuse are not high, and specifically the downside of that approach is comparable to the downside of the other approach, namely the need to diagnose and fix type errors in programs like the one I posted. So we need to consider the likely frequency of these scenarios, and the benefits/costs of keeping the Haskell 98 standard as stable as possible or making minor changes like this that could also cause problems when converting between one "Haskell 98, 2002 revision" compiler and another "classic Haskell 98" implementation. It's all about trade-offs. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From reid@cs.utah.edu Thu May 31 23:10:43 2001 From: reid@cs.utah.edu (Alastair David Reid) Date: 31 May 2001 16:10:43 -0600 Subject: Haskell 98 Report In-Reply-To: <20010601041923.A10308@hg.cs.mu.oz.au> References: <37DA476A2BC9F64C95379BF66BA26902D73003@red-msg-09.redmond.corp.microsoft.com> <20010601041923.A10308@hg.cs.mu.oz.au> Message-ID: Fergus Henderson writes: > (It would be good for someone, perhaps Simon P-J., to keep a > list of issues like this which have been left out of Haskell 98 > due to backwards compatibility concerns, so that they don't get > forgotten about when it comes to time for the next version.) Such a list would indeed be useful but I think it's important that the list should record that there are reasons besides backwards compatability for leaving things as they are. IIRC, at the time that the functions were added to List, someone proposed generalisations like those currently on the table but they were rejected because they made it harder to state the relationship between the By functions and their overloaded brethren. With things as they are now, the relationship between the By functions and their overloaded variants is very, very simple to state: if foo has type foo :: (Eq a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an equivalence relation) and foo = fooBy (==) and if foo has type foo :: (Ord a) => ty then fooBy has type fooBy :: (a -> a -> Bool) -> ty (where the additional argument is expected to be an reflexive, transitive relation) and foo = fooBy (<=) Making the types of the By functions as general as possible would break the consistency of this story. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/