- Haskell-Cafe - Haskell.org

numerical subtyping
by Derek Elkins 08 Dec '04

08 Dec '04

> Is there a standard Haskell trick for checking run-time assignment to > data types? I'd like a data type of Probability that ensures its > Double argument is between 0 and 1. > > Jim A fairly common technique to achieve this is smart constructors (apparently also called factory functions). http://www.haskell.org/hawiki/FactoryFunction You simply enforce the invariant on construction. For your example, it would look like, newtype Probability = Probability Double probability p | 0.0 <= p && p <= 1.0 = Probability p unProbability (Probability p) = p Simply don't export Probability's constructor and it will be impossible to create a Probability with a value outside of [0,1]. However, you may want to export the constructor, or alternatively, export a function with a name like unsafeProbability (= Probability) for situations where you can statically decide that the invariant will hold if the superfluous checking costs too much, which doesn't seem particularly likely in this case. Providing a function of type Double -> Maybe Probability is also likely a good idea.

3 2

Re: [Haskell-cafe] ghc has problems with 'zipWith' ?
by Tom Pledger 08 Dec '04

08 Dec '04

Daniel Fischer wrote: >Hi, >I have recently come across the curious phenomenon that ghci is sometimes much >slower than hugs. > [...] >ms as = zipWith (+) (zipWith (*) as (1:ms as)) (0:1:ms as) > Hugs has(**) a specific optimisation for the case where the left hand side of the declaration occurs as a subexpression in the right hand side. You can get a similar benefit under ghci if you share the common subexpression by hand: ms' as = let bs = ms' as in zipWith (+) (zipWith (*) as (1:bs)) (0:1:bs) (**) I haven't actually seen the code in question, and am repeating something which was on one of the mailing lists a few years ago. So please don't treat this as authoritative! Regards, Tom

1 0

Is this a useful higher-order function, or should I RTFM?
by Steven Huwig 08 Dec '04

08 Dec '04

I am basically a newbie at Haskell, and have been experimenting with it where typically I would use Python. One source of frustration I had with the standard library is that "words . unwords" is not an identity function. I would like to perform per-word transformations and predicates while preserving whitespace. So I implemented wordsAndSpaces and unwordsAndSpaces, which I believe to be a decent way to get that kind of behavior. In working on this problem, I realized that I was looking for a pair of higher-order functions. My code and an example of usage is below: -- unravel :: (a -> Bool) -> [a] -> ([[a]], [[a]], Int) unravel _ [] = ([], [], 0) unravel p xs = unravel' ([],[], if p (head xs) then 0 else 1) p xs unravel' :: ([[a]], [[a]], Int) -> (a-> Bool) -> [a] -> ([[a]], [[a]], Int) unravel' (sheep, goats, pos) _ [] = (reverse sheep, reverse goats, pos) unravel' acc@(sheep, goats, pos) p rest@(x:xs) | p x = unravel' addSheep p (dropWhile p xs) | otherwise = unravel' addGoat p (dropWhile (not . p) xs) where addSheep = ((takeWhile p rest):sheep, goats, pos) addGoat = (sheep, (takeWhile (not . p) rest):goats, pos) ravel :: [a] -> ([[a]], [[a]], Int) -> [a] ravel zero (sheep, goats, pos) | length sheep > length goats = concat (zipWith (++) sheep (goats ++ repeat zero)) | length sheep < length goats = concat (zipWith (++) goats (sheep ++ repeat zero)) | pos == 0 = concat (zipWith (++) sheep goats) | otherwise = concat (zipWith (++) goats sheep) initcap :: String -> String initcap (c:cs) = toUpper c:[toLower c' | c' <- cs] wordsAndSpaces = unravel (not . isSpace) unwordsAndSpaces = ravel "" teststr = "This is a test\n A very\t\t good\ntest" main = (putStrLn . unwordsAndSpaces) (map initcap words, spaces, pos) where (words, spaces, pos) = wordsAndSpaces teststr -- So unravel takes a predicate and a list, and returns a tuple of two lists -- the first is a list of lists of consecutive elements where predicate is true, and the second where they are false. Its opposite ravel takes a zero element -- to pad out fenceposts -- and the output of unravel, and returns the lists all concatenated together. I have several questions about this: 1) Did I miss something in the Prelude or standard library that gives me this functionality, or something close to it? 2) Do unravel and ravel have any other practical uses on their own? Looking at it, I think they could be used in a single function of type f :: (a->Bool) -> ([a] -> [a]) -> [a] -> [a] that would encapsulate both. E.g. mapWords = f (not . isSpace) main = putStrLn (mapWords initcap "lots \tof\nwhitespace") (syntax not checked for sanity) Can one get that function out of the Prelude in an easier manner than above? Is there a simpler way to get that functionality besides composing ravel and unravel with a map in between? 3) The 3-tuple output of unravel looks ugly to me, but I can't think of an alternative. For the case where there is an equal number of p-groups and not-p-groups, we need to know which side to start the zipWith. Does anyone have a better way? Any comments and criticism are welcome. -- Steven Huwig

3 5

Haskell as data manipulation language?
by Dimitry Golubovsky 08 Dec '04

08 Dec '04

Hi, I am probably not the first to think about this, yet I was unable to find any signs of activities in this direction, so maybe I will be able to know something from this list. First of all, reading multiple messages about global and mutable variables desired in Haskell, I was thinking: isn't the root of the problem in the fact that there are no variables in Haskell at all? Indeed (and my experience of digging in Hugs sources confirms) Haskell program (function) is just a description of some memory structure which being completed by the bindings of its arguments, is further transformed by the evaluator into some other data structure, etc. Now imagine a data storage with structure similar to one of a Haskell program. I. e. a storage having metadata-objects like data constructor functions, data types which are parents to data constructors (like in data X = Foo Int | Bar Float), classes, instances, modules, etc. Also data objects themselves, i. e. precompiled and serialized functions along with their type information. Data objects do not differ from functions i. e. they are stored the same way. Now quoting Graham Klyne Subject was: [HAskell-Cafe] Mutable and persistent values (was: Top Level TWI's again) posted 2004-11-23 05:11:25 PST: (I tried to post reply via Google Groups, but it did not make it back to the list): > It is my view that use a functional language effectively, it is necessary > to think differently about its structure than one would for a conventional > imperative program. Global values become parameters and return > values; mutable values become input values and new (separate) return > values. If you're used to writing imperative programs that do not use > global state, but rather use parameters to pass values, the difference > isn't always quite as great as might be imagined. > > For complex values, this sounds horribly inefficient, but because values > are pure (not mutable), very high levels of sharing can (sometimes, with > good design!) be extensively shared. Thus, a return value may well consist > mostly of a copy of the input value, with differences, rather than actually > being a complete new copy. (Chris Okasaki's book shows well how to design > to obtain these benefits.) > > Also, because Haskell is lazy, complex structures passed between functions > don't necessarily ever exist in their entirety. Sometimes, I think of a > data structure as describing a computational traversal through some data, > rathert than something that actually exists. (This leads to very elegant > expression of things like Prolog search-and-backtrack algorithms.) So, if there is a data object (say, a list) stored with version number N, and another value is cons'ed to the list, then version N+1 will be stored as an application of cons to the value added, and the version N. Thus, via versioning, some kind of mutability may be achieved (and of course these check-in and check-out must belong to IO monad). These stored functions must be visible to the compiler, and when compiling some function f which calls g (compiled earlier and stored as version N), the code of this version of f (say, M) is built to call version N of g further on. So, all the type checks are done during compilation, and are not necessary during runtime, and yet the functions are compiled and stored separately (trying to address the issue with too large monolithic programs). Newer version of f (say M+1) may be compiled against newer (at that time) version of g (N+1). So different versions of the same function may demonstrate different behaviors, but the "history of development" is preserved. Put together, this gives some conceptual image of a "programmable data storage" with queries being calls to stored functions (with externally supplied agruments). All good things of Haskell like static type safety are preserved. I am thinking of implementation of something like this using Hugs runtime as the basis. I realize, this may be very time consuming, so I am wondering, maybe someone already is developing something like this? Or someone already tried, and found this inefficient or in some other way not feasible to implement? Dimitry Golubovsky Middletown, CT

2 2

numerical subtyping
by Jim Apple 08 Dec '04

08 Dec '04

Is there a standard Haskell trick for checking run-time assignment to data types? I'd like a data type of Probability that ensures its Double argument is between 0 and 1. Jim

1 0

Re: [Haskell-cafe] Non-technical Haskell question
by Henning Thielemann 07 Dec '04

07 Dec '04

On Tue, 7 Dec 2004, Brian Smith wrote: > FWIW, I use a directory structure like: > src/ source code > build// intermediate files (.hi, .o) > dist/ deliverables > I execute GHC using: > ghc --make Main -isrc -hidir build -odir build -o dist/program > As a result, I never have any non-source files mixed in with the > source files. So, I think what you want is possible today. The difference is that for Modula-3 the same effect is achieved by e.g. m3build or cm3 that is, I never called the compiler but always used the M3 build system. Would be nice to have this with Haskell, too. Maybe 'hmake' and Cabal can help here?

1 0

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Marlow 07 Dec '04

07 Dec '04

On 06 December 2004 14:39, John Goerzen wrote: > On 2004-12-06, Keith Wansbrough <Keith.Wansbrough(a)cl.cam.ac.uk> wrote: >> The static vs dynamic linking question has been discussed many times. >> The summary is: GHC is a highly-optimising compiler, and the binary >> interface _necessarily_ changes with every minor revision (even >> patchlevel revision) of the compiler and each library. So you can't > > We already have a way to deal with that using sonames. It's not that > hard, and is routinely used. > > BTW, is this a problem even if no -O options are given when building a > library? Certainly it's possible to get a more stable library ABI by not compiling with -O. The question is, do you want to? You certainly don't want to do this for the Prelude and other essential libraries. For example, GHC wouldn't be able to see the definition of 'instance Num Int', and hence (x + 1 :: Int) would be compiled as (+) dNumInt x (I# 1) instead of (after inlining (+) and dNumInt): case x of I# x# -> I# (x# +# 1#) which can then be further optimised: the compiler can see that it is strict in x, so might be able to unbox x, and so on. This is pretty essential to get any kind of reasonable performance, but it might be less important for higher-level libraries, as long as you don't have any important monads that need to be inlined, for example. Dynamic linking is (almost) a separate issue. GHC 6.4 will have some support for dynamic linking in the native code generator thanks to Wolfgang Thaller, but it needs someone to push it the final mile on x86/Linux and Windows. Dynamically linked libraries will work (albeit slightly slower than statically linked ones), but you still have the versioning issue. Since libraries are getting really big nowadays (eg. wxHaskell) making dynamic linking work even without worrying about versioning seems like it would be worthwhile. Cheers, Simon

4 4

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Marlow 07 Dec '04

07 Dec '04

On 06 December 2004 21:54, Sven Panne wrote: > And just a remark: We don't need a new technique for a "no inline > barrier": Just compile the library optimized and use a facade which > re-exports your public API compiled without optimizations. That probably won't work. GHC goes to the .hi file for the module which originally defined a function to get its definition. Cheers, Simon

2 1

RE: [Haskell-cafe] Classes in type declarations in Hugs
by Simon Peyton-Jones 07 Dec '04

07 Dec '04

http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions. html#NEWTYPE-DERIVING | -----Original Message----- | From: Graham Klyne [mailto:GK@ninebynine.org] | Sent: 07 December 2004 10:46 | To: Simon Peyton-Jones; haskell-cafe(a)haskell.org | Subject: RE: [Haskell-cafe] Classes in type declarations in Hugs | | At 10:15 06/12/04 +0000, Simon Peyton-Jones wrote: | >| This is where I find ghc's newtype deriving to be incredibly useful. | >| | >| newtype CPError a = CPError (Either Error a) | >| deriving(Monad,MonadError) | >| | >| now CPError is a monad and an instance of MonadError and you are free | >to | >| override or inherit more interesting instances at will without | >| conflicting with the basic types for Either :) | > | >Aha! I've always wondered whether anyone uses this feature, which I | >implemented at John Hughes's suggestion. I'd be interested to know if | >you are alone, or whether others do so too. | | Not a user, but sounds maybe interesting. Can you point to documentation? | | #g | | | ------------ | Graham Klyne | For email: | http://www.ninebynine.org/#Contact

1 0

RE: [Haskell-cafe] Classes in type declarations in Hugs
by Graham Klyne 07 Dec '04

07 Dec '04

At 10:15 06/12/04 +0000, Simon Peyton-Jones wrote: >| This is where I find ghc's newtype deriving to be incredibly useful. >| >| newtype CPError a = CPError (Either Error a) >| deriving(Monad,MonadError) >| >| now CPError is a monad and an instance of MonadError and you are free >to >| override or inherit more interesting instances at will without >| conflicting with the basic types for Either :) > >Aha! I've always wondered whether anyone uses this feature, which I >implemented at John Hughes's suggestion. I'd be interested to know if >you are alone, or whether others do so too. Not a user, but sounds maybe interesting. Can you point to documentation? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0