June 2003 - Haskell - Haskell.org

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

foldr in terms of map
by Hal Daume 01 Jul '03

01 Jul '03

Kind of a random question for today :). We all know that we can write map in terms of foldr: > map f = foldr ((:) . f) [] as I understand it, this is essentially because foldr encapsulates all primitive recursive functions and since map is primitive recursive, we can implement it in terms of a fold. one thing that is interesting to note is that if we are also given references, a function to sequence monadic actions ('sequence_') and reverse, we can write foldr in terms of map (I do this in the IO monad, but as long as you have refs, it doesn't really matter -- if you used a "better" monad, you could replace the unsafePerformIO with something which doesn't sound so bad, but in this case, the operation is safe): > foldr f z l = unsafePerformIO $ do > v <- newIORef z > sequence_ $ map (modifyIORef v . f) (reverse l) > readIORef v Of course, we can postulate instead of sequence_, rsequence_, defined as: > rsequence_ :: Monad m => [m a] -> m () > rsequence_ [] = return () > rsequence_ (x:xs) = do rsequence_ xs; x; return () it's probably also possible to do it by storing in the reference a function which we compose, but that's not interesting here. now, when we're in the IO monad, the difference between the real foldr and the simulated one is that the simulated one cannot deal with infinite inputs. for instance: > head $ foldr (:) [] [1..] should return 1, which it does for the real version. the simulated one hangs. one might like to attribute this to the fact that IO is a strict monad, but that doesn't seem to be all -- we would also need to be able to read and write references lazily in order to get this to work completely. Q1: is this correct? is there a way to "fix" the above definition or to use a different monad to get laziness? i think not, but can't prove it. now, if we just limit ourselves to finite inputs, things look a lot better. however, this brings up really the main question i have. foldr (in its original form) is in some sense quintessentially(sp?) PR on lists, whereas map is not. however, it seems that the combination map+rsequence_+references is enough to give you full PR power. what more can we say about this? clearly references play the largest role here, but it also seems impossible to remove this dependence on the sequencing operation. clearly there is some class of algorithms weaker that primitive recursive into which both map and rsequence_ fall. these two functions are in some sence counterparts to eachother: map retains list structure and only modifies elements, which rsequence_ destroys list structure and doesn't modify (just "runs") elements. is there some sor tof theory that talks about this relationship? and why is it that when put together, these things are strong enough (plus refs) to subsume primitive recursiveness? - Hal p.s., responses delayed until after ICFP are equally welcome :) -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

2 1

RE: Language extension proposal
by Simon Peyton-Jones 30 Jun '03

30 Jun '03

If you have a class like this class FloatTraits a where mantissa :: Int then the type of mantissa is mantissa :: forall a. FloatTraits a => Int There's nothing wrong with this in principle; the difficulty is that when you say mantissa + 4 you aren't saying which float type to get the mantissa of. Earlier messages have outlined workarounds, but in some ways the "real" solution is to provide a syntax for type application. A polymorphic function should be applied to a type argument; these type arguments are always implicit in Haskell, but are explicit in System F. They are also explicit in O-O languages that support polymorphism. For example, in C++ one might say mantissa<Double> + 4 And in fact that's just what we *want* to say here. (The workarounds in earlier emails all amount to passing a *value* argument as a proxy for a type argument.) If we could only figure out a good syntax for (optional) type application, it would deal rather nicely with many of these cases. Trouble is, '<..>' gets confused with comparisons. And when there are multiple foralls, it's not obvious what order to supply the type parameters. It'd be useful in other situations too. For example, one could have lambdas at the type level, if one was willing to instantiate them explicitly. sequence :: forall (m:*->*) (a:*). [m a] -> m [a] data STB a s = s -> (a,s) -- Oops: got the parameters backwards ....sequence<\b. ST b MyState, Int>... Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Ashley Yakeley | Sent: 28 June 2003 00:25 | To: haskell(a)haskell.org | Subject: Re: Language extension proposal | | In article <20030625041751.GA29774(a)smtp.alicorna.com>, | Andrew J Bromage <ajb(a)spamcop.net> wrote: | | > Another example is floating point format information, like the | > information in C's <float.h>. One might implement this as: | > | > class (Bounded a) => FloatTraits a where | > epsilon :: a -- OK | > mantissaDigits :: Int -- Not OK! | | Oh I do this all the time in HBase. I simply do this: | | data Type a = MkType | | getType :: a -> Type a | getType _ = MkType | | class (Bounded a) => FloatTraits a where | epsilon :: a | mantissaDigits :: Type a -> Int | | The only annoyance is that you frequently have to write (MkType :: Type | MyFloat). Syntactic sugar for _that_ would be useful. | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

3 2

Re: Language extension proposal
by Ashley Yakeley 30 Jun '03

30 Jun '03

At 2003-06-30 01:55, Ralf Hinze wrote: >What about > mantissa (| Double |) + 4 ? This would work perfectly with my method if (| Double |) were syntactic sugar for (mkType :: Type Double) or similar. I really think it's the most straightforward way of doing it and I hazard the easiest to implement. -- Ashley Yakeley, Seattle WA Almost empty page: <http://semantic.org/>

1 0

Re: Language extension proposal
by Ashley Yakeley 28 Jun '03

28 Jun '03

At 2003-06-28 02:51, Ralf Laemmel wrote: >Suffering from persecution mania, >I prefer to know for sure that nobody never ever will >pattern match on those a's. So I prefer to write: I don't understand. Did you mean pattern-match on MkType? I could stop that by hiding it but exposing mkType = MkType. -- Ashley Yakeley, Seattle WA

2 1

Language extension proposal
by Andrew J Bromage 28 Jun '03

28 Jun '03

G'day all. I've been toying with an idea for a small language extension, and I was curious what you all think of this. As a motivating example, consider the following standard typeclass: class Bounded a where min :: a max :: a This is an example of what I refer to as a "traits typeclass" (by analogy to traits classes, well-known to C++ programmers). The idea is that you want to specify certain properties/operations which depend on a _type_, rather than any particular value of that type. Another example is floating point format information, like the information in C's <float.h>. One might implement this as: class (Bounded a) => FloatTraits a where epsilon :: a -- OK mantissaDigits :: Int -- Not OK! For obvious reasons, the declaration of mantissaDigits is not valid Haskell. Instead, you might do something like this: class FloatTraits a where mantissaDigits :: a -> Int instance FloatTraits Float where mantissaDigits _ = 24 instance FloatTraits Double where mantissaDigits _ = 53 and invoke it as, say: mantissaDigits (undefined :: Float) A decent strictness analyser can tell if an argument to some function is always unused (in GHC core terminology, this means its demand is "absent") and thus avoid passing the argument at all. However, it is currently impossible to tell if this is true all instances of a typeclass. What I would like is some annotation that I can use to tell my compiler that this argument of this method is always unused, no matter what instance it resolves to. My proposal is to grab a new punctuation symbol (I will use '~' as an example) to sit alongside the GHC extension use of '!'. Where '!' means that an argument may be evaluated before calling a function, '~' means than an argument may be ignored by the callee. So in the above example, I can write: class FloatTraits a where mantissaDigits :: ~a -> Int Now this marker is not as simple to implement as '!'. The strict marker is advisory; if you stripped all '!'s from your program, it would still have the same static semantics. Not so with '~', which must be statically checked. However, the static analysis is pretty trivial, except for the problem of inference. Basically, if a variable has absent demand, it a) can't be pattern matched on (unless the pattern is a variable, of course), and b) can't be passed as an argument to a function (including a data constructor) which doesn't also treat that argument as having absent demand. I therefore propose that the marker not be inferred for top-level definitions, or at least for exported definitions. If you declare it, it's checked, but otherwise it's not. In addition, any calls that you pass a variable with absent demand to must themselves have the marker declared explicitly in their type signatures. There may also be an argument for extending '~' to data constructors, in the same way that H98 uses '!'. This would allow parameters with absent demand to be stored in data structures. I can't think of a use for this right now, but it shouldn't be too much harder to add. What do you all think? Useful? Not worth the effort? Cheers, Andrew Bromage

6 5

sockets and handles in ghc
by Jurriaan Hage 27 Jun '03

27 Jun '03

Hello, I've been using sockets and handles with ghc-5.04.3. The strange thing is now that when I make a handle out of a socket and ask whether the handle is readable or writable, it returns True for the former and False for the latter, although sockets are bidirectional. And yes, I am able to read from and write the handle notwithstanding. I also got an exception once when working with these things and the debug information I got then, showed that both should have returned True instead. Can anyone enlighten me? thanks, Jur -- http://www.cs.uu.nl/people/jur/progrock.html -- jur(a)cs.uu.nl If e-mail does not work try jurriaanhage(a)hotmail.com

2 1

let (d,k) = (g x y, h x d) ..
by Serge D. Mechveliani 27 Jun '03

27 Jun '03

Dear Haskellers, Once I wrote a function f' :: Int -> Int -> Int -> (Int, Int) f' n m l = let (d,k) = (gcd n m, quot n d) in (k, l*k) (the simplified version of real program), placing erroneousely d to both parts of the pattern matching (d,k) = ... The intended program was f n m l = let {d = gcd n m; k = quot n d} in (k, l*k) But f' gives the intended results, at least in the GHC implementation. So that I did not notice the `error' for a long time. Is really the Haskell pattern matching semantic so that f and f' are equivalent ? Is it an occasional implementation feature that hide the `error'? Thank you in advance for the explanation. Answer, please, to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Open research position in types for security
by Manuel M T Chakravarty 27 Jun '03

27 Jun '03

We are looking for a Senior Research Associate in the area of type theory and its application to programming languages in the School of Computer Science and Engineering at University of New South Wales. The School is one of the largest computing schools in Australia, has an extensive research program and regularly attracts funding from government institutions as well as industry. The successful applicant will contribute to a major research project spanning the areas of programming languages, compilers, and operating systems; for a project description, see http://www.cse.unsw.edu.au/~chak/project/sec/ Essential criteria include: * Strong track record in type theory and programming languages * Experience in one or more of the following: automated theorem proving, functional programming, compiler construction * Demonstrated ability to conduct independent research and record of publications in relevant areas Full details concerning the position are at http://www.hr.unsw.edu.au/employment/27060304.htm Interested? Just send me an email and I'll happily provide further information. Manuel -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Manuel M T Chakravarty chak(a)cse.unsw.edu.au School of Computer Science & Engineering University of New South Wales, Sydney http://www.cse.unsw.edu.au/~chak/

1 0

call for papers TPLP special issue on Multiparadigm Languages and Constraint Programming
by Marco Comini 26 Jun '03

26 Jun '03

Apologies for Multiple Copies of this Message _______________________________________________ CALL FOR PAPERS [please circulate!] Special Issue of Theory and Practice of Logic Programming on Multiparadigm Languages and Constraint Programming Guest Editors: Moreno Falaschi and Michael Maher Following up on a series of 11 workshops (WFLP) on multiparadigm languages and constraint programming, the journal on Theory and Practice of Logic Programming (TPLP) is planning a special issue on multiparadigm languages and constraint programming to appear in 2005. TOPICS In recent years much research and implementation efforts have been devoted both to multiparadigm languages and constraint programming languages. The aim of this special issue is to attract high-quality research papers on all aspects related to multi-paradigm languages and constraint programming, such as semantics, analysis, extensions, implementations and applications. Papers addressing how to use constraints for integrating different paradigms, or extensions of multiparadigm languages with constraints would be particularly welcome, although papers solely on multiparadigm programming or constraint programming are also of interest. Surveys and comparisons of constraint techniques and multiparadigm languages are also solicited. This special issue should hence stimulate the cross-fertilizing exchange of ideas and experiences among researchers from the different communities interested in the foundations, applications, and combinations of high-level, multiparadigm and constraint programming languages and related areas. Submissions Revised and enhanced versions of papers published at conferences that have not appeared in archival journals are eligible for submission. Papers describing important past research in this area which have not been published in archival journal papers are also solicited. For any doubt regarding the appropriateness of the topic of a paper for this special issue please email either to Moreno Falaschi (falaschi(a)dimi.uniud.it) or to Michael Maher (mjm(a)math.luc.edu) Papers should be written in English, and formatted using the LaTeX style files developed by Cambridge University Press for TPLP. To submit and for further information, please look at: http://www.dimi.uniud.it/~wflp2002/tplp/ Important Dates Submission: December 15, 2003 Notification: June 1, 2004 Revised paper due: November 1, 2004 Publication: 2005

1 0