[Haskell-cafe] QuickCheck properties for Haskell98 Libraries?

[John Meacham]

I was curious if anyone had a collection of QuickCheck rules for testing
the Haskell98 Prelude and libraries? It seems like it would be a useful
thing to exist as a common resource.

In particular, if there were overloaded rules for the various class
properties then it would be easier to test whether the instances one
writes for standard classes were correct.

In fact, it would be nice if the author of every class provided some
quickcheck rules for testing the laws instances should obey.

John


-- 
John Meacham - ârepetae.netâjohnâ 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Sven Panne]

Jules Bean wrote:
[...] You rather want 'zipWith'.  Documentation at:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.List.html
...along with lots of other funky list processing stuff.
Just a small hint: Everything below "GHC" in the hierarchical libraries
is, well, GHC-specific, meant for internal use only and may change without
further notice, see "Stability: internal" in the page you mentioned. Just
use http://haskell.org/ghc/docs/latest/html/libraries/base/Data.List.html
instead.
Cheers,
   S.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] library documentation [was: File path programme]

[Isaac Jones]

"Georg Martius" <[EMAIL PROTECTED]> writes:

> Hi,
>
> I think Isaac's idea is pretty nice, to have an easy way to add documentation 
> in a collaborative manner.
> I have the following in mind:

Well, I've added a much less glorious page than yours on the wiki:

http://www.haskell.org/hawiki/LibraryDocsNeedingHelp

Click "edit text" and add as much information as possible about the
shortcommings of the library documentation you run across.  Extra
points for patches posted to [EMAIL PROTECTED]

It would be nice if there were an easy way to link all the
documentation together or allow people to add collaborative
documentation hooks to CVS or something, but for now, a low-tech
solution will have to do.

peace,

  isaac
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] fastest Fibonacci numbers in the West

[William Lee Irwin III]

Inspired by a discussion on freenode #haskell, I tried to write the
fastest Fibonacci number function possible, i.e. given a natural
number input n to compute F_n.

mlton seems to enjoy substantially better speed despite equivalent
algorithms; it may be enlightening to determine the causes of this,
at least for those concerned about performance and the inner workings
of the Haskell runtime system(s). In general, I am not usually very
concerned about performance, nor am I in this case. But it's something
of a mindless microbenchmark or similar.

The things I'd normally think of to speed this up would be getting
some primitives to find the highest bit of an integer (floor . lg)
and to test a given bit of an integer (something vaguely like
fromEnum . fromIntegral . (`mod` 2) . (/2^k)), both in some lightweight
O(1) with low-hidden-constant manner. This doesn't appear to be a factor
in the testing I did, as they're largely 1:1 translations of each other.
Still, such things would be useful in various other algorithms, of far
greater importance than this one.

For the moment, mlton-generated binaries crash computing fib (10^8-1),
and there is a 6:1 speed difference for fib (10^7-1) between the two,
where mlton-generated binaries take just under 1 minute, and ghc-
generated binaries take just under 6 minutes.

Anyway, thoughts on how to improve all this from the programmer's
point of view, or otherwise explaining what's going on or ameliorating
whatever effect is at work here would be appreciated.


-- wli
module Main where
import System.Environment
import Data.List

fib n = snd . foldl fib' (1, 0) . map (toEnum . fromIntegral) $ unfoldl divs n
where
unfoldl f x = case f x of
Nothing -> []
Just (u, v) -> unfoldl f v ++ [u]
divs 0 = Nothing
divs k = Just (uncurry (flip (,)) (k `divMod` 2))
fib' (f, g) p   | p = (f*(f+2*g), f^2 + g^2)
| otherwise = (f^2+g^2, g*(2*f-g))

main = getArgs >>= mapM_ (print . fib . read)
fun   unfold 0 = []
| unfold n = let val ((q:int), (r:int)) = (n div 2, n mod 2)
 in (unfold q) @ [if r = 1 then true else false]
 end

fun crunch (p, (f, g)) = if p then (f*(f+2*g), f*f+g*g) else (f*f+g*g, 
g*(2*f-g))

fun myfib n = #2 (foldl crunch (1, 0) (unfold n))

val n = valOf(Int.fromString(hd(CommandLine.arguments(
  handle Option =>
(print ("usage: tailfib n\n");
OS.Process.exit(OS.Process.failure))

val _ = print (IntInf.toString (myfib n) ^ "\n")
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[Robert Dockins]

Here is my first cut at this. The unix implementation mostly works, the
windows one just has some datatypes sketched out, but it typechecks.


-- module FilePath where
import Data.Word (Word8)

import Text.ParserCombinators.Parsec
import Text.ParserCombinators.Parsec.Error


import System (getArgs)
main = 
 do [s,t] <- getArgs 
let p  = parsePath s
p' = parsePath t
putStrLn $ unixPathShow (pathExtend p "myextradirectory")
putStrLn $ unixPathShow p'
putStrLn $ unixPathShow $ unixPathCleanup (pathAppend p p')


data CharEncoding 
   = USASCII
   | ISO_8859_1
   | UnknownEncoding
 deriving (Eq,Ord,Show)

class (Show p) => Path p where
  isAbsolute :: p -> Bool
  isRelative  :: p -> Bool
  isRelative = not . isAbsolute
  basename :: p -> String
  parent :: p -> p
  pathAppend :: p -> p -> p
  pathExtend :: p -> String -> p
  pathSeparator :: p -> Char
  pathParser :: Parser p  
  parsePath :: String -> p
  parsePath x = 
 case parse pathParser "" x of
   Left e  -> error $ show e
   Right x -> x

-- unix path segments are arbitrary sequences of 
-- octects EXCEPT that they must not contain
-- any octets with value 0x2F (forward slash char)
type UnixPathSeg = [Word8]

-- path segments are stored stack-like, with
-- the root of the path at the end of the list
-- INVARIANT the path list is not empty
data UnixPath 
   = UnixAbsPath CharEncoding [UnixPathSeg]
   | UnixRelPath CharEncoding [UnixPathSeg]
 deriving (Eq,Ord)

unixPathSeparator :: Char
unixPathSeparator = '/'

unixCurrentDirSeg :: UnixPathSeg
unixCurrentDirSeg = map (fromIntegral . fromEnum) "."

unixParentDirSeg :: UnixPathSeg
unixParentDirSeg = map (fromIntegral . fromEnum) ".."

showUnixPathSeg :: CharEncoding -> UnixPathSeg -> String
showUnixPathSeg USASCII seg= map (toEnum . fromIntegral) seg
showUnixPathSeg ISO_8859_1 seg = map (toEnum . fromIntegral) seg
showUnixPathSeg enc _ = error ("Cannot lineralize a UNIX path with encoding: "++(show enc))

unixPathShow :: UnixPath -> String
unixPathShow (UnixAbsPath enc segs) = foldl (\p s -> unixPathSeparator : (showUnixPathSeg enc s) ++ p) "" segs
unixPathShow (UnixRelPath enc segs) = tail $ foldl (\p s -> (unixPathSeparator : (showUnixPathSeg enc s)) ++ p) "" segs

unixPathIsAbsolute :: UnixPath -> Bool
unixPathIsAbsolute (UnixAbsPath _ _) = True
unixPathIsAbsolute _ = False

unixPathBasename :: UnixPath -> String
unixPathBasename (UnixAbsPath enc (s:_)) = showUnixPathSeg enc s
unixPathBasename (UnixRelPath enc (s:_)) = showUnixPathSeg enc s

unixPathParents :: Int -> UnixPath -> UnixPath

unixPathParents 0 x = x

-- relative paths
unixPathParents n (UnixRelPath enc [x])
| x == unixParentDirSeg  = UnixRelPath enc (take (n+1) $ repeat unixParentDirSeg)
| x == unixCurrentDirSeg = UnixRelPath enc (take n $ repeat unixParentDirSeg)
| n <= 1 = UnixRelPath enc [unixCurrentDirSeg]
| otherwise  = UnixRelPath enc (take (n-1) $ repeat unixParentDirSeg)
unixPathParents n (UnixRelPath enc (x:xs))
| x == unixParentDirSeg  = unixPathParents (n+1) (UnixRelPath enc xs)
| x == unixCurrentDirSeg = unixPathParents n (UnixRelPath enc xs)
| otherwise  = unixPathParents (n-1) (UnixRelPath enc xs)

-- absolute paths
unixPathParents n (UnixAbsPath enc [x]) = UnixRelPath enc [unixCurrentDirSeg]
unixPathParents n (UnixAbsPath enc (x:xs))
| x == unixParentDirSeg  = unixPathParents (n+1) (UnixAbsPath enc xs)
| x == unixCurrentDirSeg = unixPathParents n (UnixAbsPath enc xs)
| otherwise  = unixPathParents (n-1) (UnixAbsPath enc xs) 

unixPathAppend :: UnixPath -> UnixPath -> UnixPath
unixPathAppend (UnixAbsPath xenc xs) (UnixRelPath yenc ys)
  | xenc == yenc = UnixAbsPath xenc (ys++xs)
  | otherwise= error $ "cannot append UNIX  paths with different encodings "++(show xenc)++", "++(show yenc)
unixPathAppend (UnixRelPath xenc xs) (UnixRelPath yenc ys)
  | xenc == yenc = UnixRelPath xenc (ys++xs)
  | otherwise= error $ "cannot append UNIX  paths with different encodings "++(show xenc)++", "++(show yenc)
unixPathAppend _ (UnixAbsPath _ _) = error "cannot append an absolute path on the right"

unixPathParent :: UnixPath -> UnixPath
unixPathParent = unixPathParents 1

unixPathSegClean :: Bool -> Int -> [UnixPathSeg] -> [UnixPathSeg]
unixPathSegClean isAbs n l@(x:xs) =
  let l'  = if x == unixCurrentDirSeg
   then x : clean n xs
   else clean n l
  l'' = if null l' 
   then [unixCurrentDirSeg]
   else l'
  in l''

 where clean n [] = if isAbs 
		   then [] 
		   else take n $ repeat unixParentDirSeg
   clean n (x:xs)
| x == unixCurrentDirSeg  = clean n xs
| x == unixParentDirSeg   = clean (n+1) xs
| n > 0   = clean (n-1) xs
| otherwise   = x : clean n xs


unixPathCleanup :: UnixPath -> UnixPath
unixPathCleanup (UnixAbsPath enc l) = 
UnixAbsPath enc (unixPa

Re: [Haskell-cafe] File path programme

[Robert Dockins]

> I would say that all paths are relative to something, whether it's the 
> Unix root, or the current directory, or whatever. Therefore I would call 
> this something like PathStart, and add:
> 
> | CurrentDirectory
> | CurrentDirectoryOfWindowsDrive Char
> | RootOfCurrentWindowsDrive

This is true in a sense, but I think making the distinction explicit is
helpful for a number of the operations we want to do.  For example, what
is the parent of the relative path "."?  Answer is "..".  What is the
parent of "/." on unix?  Answer is "/.".  I would also argue that it
only makes sense to append a relative path on the right (ie, we can't
append "/tmp/foo" onto "/usr/local", but we can append "tmp/foo").
Relative paths can refer to different things in the filesystem depending
on process-local state, whereas absolute paths will always refer to the
same thing (until the filesystem changes, or if you do something
esoteric like "chroot").  Relative paths are really "path fragments."

> On Unix, there are two nodes we can name directly, the "root" and the 
> "current directory". On Windows, there are 26 roots and 26 current 
> directories which we can name directly; additionally we can name the 
> root or current directory of the current drive, which is one of those 
> 26, and there are an arbitrary number of network share roots, and \\.\, 
> and perhaps some other stuff I don't know about.

There are a few others.  I took a look at MSDN earlier and was
astounded.

> Whether we're talking about the final node or the final edge depends on 
> the OS call; this is the usual pointer-vs-pointee confusion that's also 
> found in most programming languages outside the ML family. Probably we 
> can ignore it, with the exception of the "/foo" vs "/foo/" distinction, 
> which we must preserve.

I've solved that as you suggested where "foo/" goes to "foo/."

>  > class (Show p) => Path p where
> Okay, I'm not convinced that a Path class is the right approach. 

I'm not convinced either, but it feels natural to me.

> I'm tentatively opposed to (B), since I think that the only interesting 
> difference between Win32 and Posix paths is in the set of starting 
> points you can name. (The path separator isn't very interesting.) But 
> maybe it does make sense to have separate starting-point ADTs for each 
> operating system. Then of course there's the issue that Win32 edge 
> labels are Unicode, while Posix edge labels are [Word8]. Hmm.

I think these differences make separate implementations worthwhile.  The
question then is wether to abstract them via a type class, or with a
datatype like:

data FilePath
   = POSIXFilePath POSIXPath
   | WinFilePath   WinPath

Disadvantage here is that the datatype is closed.  Advantage is that
pattern matching tells you what kind of path you have staticly.

>  > pathCleanup :: p -> p   -- remove .. and suchlike
> 
> This can't be done safely except in a few special cases (e.g. "/.." -> 
> "/"). I'm not sure it should be here.

More than you would think, if you follow the conventions of modern unix
shells.  eg, "foo/.." is always equal to ".", and "foo/bar/../../.." is
equal to "..", and "foo///bar" is equal to "foo/bar".  This is the
behavior that "cd" gives on modern posix shells (rather than doing a
chdir on the ".." hardlink, which does strange things in the presence of
symlinks).  The operation is sufficently useful that I think it should
be included.  It lets us know, for example, that "/bar/../foo/tmp" and
"/foo/tmp" refer to the same file, without resorting to any IO
operations.

>  > hasExtension :: p -> String -> Bool

> This is really an operation on a single component of the path. I think 
> it would make more sense to make it an ordinary function with type 
> String -> String -> Bool and use the basename method to get the 
> appropriate path component.

The problem is that String doesn't faithfully capture the representation
of path edges.  For POSIX it is a sequence of Word8 (except for 0x2F).
In my implementation of UnixPaths, each path carries along an encoding
component, which (theoreticly) tells you how to do [Word8] <-> [Char]
translations.  Eventually we will get a real IO layer complete with
character encodings and this will be meaningful.  The comparison needs
to be done with encodings in mind.

>  > pathToForeign :: p -> IO (Ptr CChar)
>  > pathFromForeign :: Ptr CChar -> IO p
> 
> This interface is problematic. Is the pointer returned by pathToForeign 
> a heap pointer which the caller is supposed to free? If so, a Ptr CChar 
> instance would have to copy the pathname every time. And I don't 
> understand exactly what pathFromForeign is supposed to do.

Agree, I like the withCPath interface better.  pathFromForeign takes a
path representation directly from C land, without going through String
first (again with encoding issues in mind).  Although it should perhaps
be:

pathFromForeign :: Ptr () -> IO p
 
instead (might be wide chars).


_

RE: [Haskell-cafe] using Map rather than FiniteMap

[S. Alexander Jacobson]

Ah, ok.  So I ran the code with 10 items, 
5 items, and 25000 items and got total memory 
in use of 28Mb, 15Mb, and 8Mb respectively.  That 
comes to 260-280 bytes per record which is still 
an order of magnitude higher than the 20-30 bytes 
per record we would expect.

On the other hand, I found 10mb, 5mb, and 2.5mb 
maximum residency, but that is still ~100 bytes 
per record.

Lastly, I tried "example +RTS -p -K5M -hc" and 
then looked at the resulting graph (attachment #2) 
and it shows a total of 1.6Mb heap allocated and 
if that data is correct, it does correspond 
roughly to our 20-30 bytes per record estimate.

Regarding stack, I tried "example +RTS -p -K5M -xt 
-hc" and then ran hp2ps and looked at the 
resulting graph (attachment #1) SYSTEM appears to 
use 4mb of stack at the very beginning (presumably 
to create "zipped"), but I don't know why it 
would.  Then this stack is consumed by the rest of 
the program.

Can you provide some guidance on interpreting this 
data?

-Alex-
__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

On Wed, 26 Jan 2005, Simon Marlow wrote:
On 25 January 2005 23:27, S. Alexander Jacobson wrote:
Oops.  It pays to check your checking code before
making posts like this.
After actually running the correct test, I am
still getting semi-ridiculous space behavior
(6k/pair)!
import qualified Map
zipped =zip [1..] [1..10]::[(Int,Int)]
untup f (x,y) = f x y
produce = foldr (untup Map.insert) Map.empty zipped
fm = length  $ Map.keys produce
main = print $ fm
Has this profile:
   example +RTS -p -K5M -RTS
total time  =5.10 secs   (255 ticks @ 20 ms)
total alloc = 612,534,236 bytes  (excludes profiling overheads)
COST CENTREMODULE   %time %alloc
balanceMap   71.8   72.8
insert Map   12.2   10.8
size   Map9.09.7
binMap2.42.2
rotateRMap1.60.3
zipped Main   0.81.9
Notice the 612Mb for storing a mapping from Int
to Int!!
Notice that's 612Mb *allocation* to create the finite map and
deconstruct it into a list.  Not 612Mb of live heap to store the finite
map.  If you make sure everything is evaluated, and examine the heap
profile I'm sure you'll find that the finite map is taking a reasonable
amount of space (perhaps 20-30 bytes per node for storing integers, I
guess).
To get a rough idea of the total live heap without profiling, you can
run the program with +RTS -sstderr and look at the memory "in use"
figure.
Cheers,
Simon


example.ps
Description: PostScript document


example2.ps
Description: PostScript document
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[John Meacham]

On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote:
> On 25 January 2005 19:45, Duncan Coutts wrote:
> 
> > On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote:
> >> My concern here is that someone will actually use the library once it
> >> ships, with the following consequences:
> >> 
> >> 1. Programs using the library will have predictable
> >> (exploitable) bugs in pathname handling. 
> >> 
> >> 2. It will never be possible to change the current weird
> >> behavior, because it might break legacy code. The System.FilePath
> >> library will 
> >> have to remain in GHC forever in its current form, enticing
> >> programmers with its promise of easy pathname handling and then
> >> cruelly breaking its contract. 
> >> 
> >> If no one uses it in production code then we can fix it at our
> >> leisure, and having it out there with "experimental" status isn't
> >> necessarily a bad thing in that case. It just feels like we're
> >> playing a dangerous game. 
> > 
> > That's a sufficiently persuasive argument for me!
> > 
> > Could we just punt this library for this release. After all we can add
> > libraries in a later point release (eg 6.4.1) you just can't change
> > existing APIs.
> 
> We can't add libraries in a point release, because there's no way for
> code to use conditional compilation to test the patchlevel version
> number.
> 
> This seems to be a common misconception, probably brought about by the
> fact that the time between major releases of GHC is getting quite long.
> Perhaps I should stop writing email and get some work done :)


too bad we can't do things like

#if exists(module System.Path) 
import System.Path
#else
...
#endif

I still find it perplexing that there isn't a decent standard haskell
preprocessor 
John

-- 
John Meacham - ârepetae.netâjohnâ 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What are the MonadPlus laws?

[ajb]

G'day all.

Quoting Iavor Diatchki <[EMAIL PROTECTED]>:

> This is not enough, at least in some cases.
> Consider lists, and m being an infinite list, e.g. [1..]
> Then we need that the inifinte concatenation of a empty lists
> gives us the empty list which is not the case.

It also doesn't work for monad transformers (e.g. Ralf Hinze's backtracking
transformer) when stacked over monads like IO.

I say we remove the "law" altogether.  It clearly causes problems, and if
you use the Hughes/Hinze method for deriving the monads, it turns out that
you don't need it anyway.

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[Ben Rudiak-Gould]

robert dockins wrote:
> After the discussion about file paths over the last several days I 
went home and put together a quick trial implementation for unix file 
paths, with the idea of adding windows, SMB and maybe VMS (why not?) paths.

This is great. Comments below.
> data PathRoot
>= UnixFilesystemRoot
>| WindowsDrive Char
>| SMBShare String String
>| VMSDevice String
>| ... -- whatever else we need
I would say that all paths are relative to something, whether it's the 
Unix root, or the current directory, or whatever. Therefore I would call 
this something like PathStart, and add:

   | CurrentDirectory
   | CurrentDirectoryOfWindowsDrive Char
   | RootOfCurrentWindowsDrive
What is a pathname, broadly speaking? Answer: it's a description of a 
path in a directed graph with labeled edges. It consists of a single 
node designator (the starting point) and a sequence of edge designators, 
i.e.

   data Pathname =
 Pathname {
   pathStart :: PathStart,
   pathEdges :: [String]
 }
Most of the time all we care about is either the final node or the final 
edge that we reach by following the path. The only reason we specify the 
rest of the path is that there are only a few nodes that we can name 
directly; to refer to any other location on the graph we have to give 
"driving directions" from one of those nodes.  There's no reason the OS 
couldn't make nodes and edges first-class entities--it would solve a 
multitude of problems--but most don't, so forget that.

On Unix, there are two nodes we can name directly, the "root" and the 
"current directory". On Windows, there are 26 roots and 26 current 
directories which we can name directly; additionally we can name the 
root or current directory of the current drive, which is one of those 
26, and there are an arbitrary number of network share roots, and \\.\, 
and perhaps some other stuff I don't know about.

Symbolic links complicate things a bit, since they are followed like 
edges but are actually paths (so they may be affected by seemingly 
unrelated changes to the graph). They're rather like VPNs, actually, 
though I'm not sure how far I want to push that analogy.

Whether we're talking about the final node or the final edge depends on 
the OS call; this is the usual pointer-vs-pointee confusion that's also 
found in most programming languages outside the ML family. Probably we 
can ignore it, with the exception of the "/foo" vs "/foo/" distinction, 
which we must preserve. This can probably be handled by parsing the 
latter as Pathname { pathStart = UnixFilesystemRoot, pathEdges = 
["foo","."] }.

> class (Show p) => Path p where
Okay, I'm not convinced that a Path class is the right approach. For the 
reasons given above, I think I'd rather have a single Path datatype, 
probably with its data constructors exported. What do we gain with the 
class approach? Well...

 (A) Functions that accept paths can be polymorphic on the path type 
(where String is a path type).
 (B) We can have different datatypes for the paths of different 
operating systems.

It seems like these are two very different problems which should be 
solved with different typeclasses, if they're to be solved with 
typeclasses at all. I think (A) can be solved very simply, and 
independently of the specification of a path-handling library:

   class IsPath a where
 withCPath :: a -> (Ptr CChar -> IO b) -> IO b
   instance IsPath String where
 withCPath = withCString   -- tricky i18n issues!
   instance IsPath [CChar] where
 withCPath = withArray0 0
   instance IsPath PathADT where
 withCPath = withCString . pathToString
   instance IsPath (Ptr CChar) where
 withCPath = flip ($)
   openFile :: (IsPath p) => p -> ...
I'm tentatively opposed to (B), since I think that the only interesting 
difference between Win32 and Posix paths is in the set of starting 
points you can name. (The path separator isn't very interesting.) But 
maybe it does make sense to have separate starting-point ADTs for each 
operating system. Then of course there's the issue that Win32 edge 
labels are Unicode, while Posix edge labels are [Word8]. Hmm.

>isAbsolute :: p -> Bool
Definition: a path is absolute if its meaning is independent of (Posix: 
the current directory) (Win32: all current directories and the current 
drive).

> pathCleanup :: p -> p   -- remove .. and suchlike
This can't be done safely except in a few special cases (e.g. "/.." -> 
"/"). I'm not sure it should be here.

> hasExtension :: p -> String -> Bool
This is really an operation on a single component of the path. I think 
it would make more sense to make it an ordinary function with type 
String -> String -> Bool and use the basename method to get the 
appropriate path component.

> pathToForeign :: p -> IO (Ptr CChar)
> pathFromForeign :: Ptr CChar -> IO p
This interface is problematic. Is the pointer returned by pathToForeign 
a heap pointer which the caller is supposed to free?

Re: [Haskell-cafe] File path programme

[Georg Martius]

Hi,
I think Isaac's idea is pretty nice, to have an easy way to add documentation 
in a collaborative manner.
I have the following in mind:
A separate wiki which supports generating haddock documentation. Ideally one would see 
the haddock documentation as it is and would click to a function or type and change the 
comment for it. However, it would also be enough to see the complete source-code and 
change the comments there. The question is what happens if there is a parse error. 
Furthermore there must be someone who maintains it in the sense that changes are 
committed to cvs at some point and so on. Additionally, it seams to be complicated to 
keep it synchronised with "real" changes of the source code in the cvs.
Probably the most simple, but less "wiki" solution is the do it the traditional 
way. Just use cvs and a normal text editor and ask for a cvs account :-).
Cheers,
 Georg
On Tue, 25 Jan 2005 12:36:54 -0800, Isaac Jones <[EMAIL PROTECTED]> wrote:
Mark Carroll <[EMAIL PROTECTED]> writes:
On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote:
(snip)
If problems are in the implementation but the interface is right, then
the module should be provided. It can be fixed later.
(snip)
A lot of the Haskell libraries are sufficiently poorly documented that I
work out what they do by experiment, or by resorting to reading the
source.
There should be a wiki page or some other list for libraries that need
documentation to be added to them.  I would be happy to add
documentation here & there.
Anyone want to volunteer to create the page and list some libraries
there?
peace,
  isaac
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

--
 Georg Martius,  Tel: (+49 34297) 89434 
--- http://www.flexman.homeip.net -
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] RE: Answers to Exercises in Craft of FP

[Hamilton Richards]

Dear Chris--
Many of us instructors who use (or have used) these textbooks (or 
others that have exercises) in university classes have found from 
experience that

1. Students learn best from exercises when they make a real effort to 
solve them before looking at the instructors' solutions.

b. Students tend not to attempt exercises that don't count towards 
their grade. They don't usually decide consciously not to do the 
exercises, but if the exercises don't count, no deadline means 
anything, and the exercises get put off in favor of homework in other 
classes that actually counts. (I've found a "sweet spot" at 10%-- 
that's enough to induce most students to hand in most of the 
exercises, while minimizing the advantage of those who merely put 
their names on a copy of someone else's paper.)

iii. If homework counts and solutions are available before the 
hand-in deadline, some students will find those solutions 
(particularly easily if they're available on the web) and hand them 
in as their own. They thus gain an advantage (I like to think it's 
only a temporary one) over students who play by the rules. It seems 
to me that a policy that makes folks who follow the rules feel like 
suckers is a not a good policy.

An instructor who is teaching a course for the first time has plenty 
of work just organizing lectures, selecting exercises, overseeing 
their grading, and making up and grading exam questions. After a 
semester or two, when the lectures have stabilized, one typically 
starts making up new homework exercises. The first time around, 
however, it's really nice to have exercises that have already been 
devised, and used in actual classes, by the textbook's author.

So I don't believe your misery is the result of a deliberate plot to 
make your life hard. It's the result of instructors organizing things 
for the benefit of their students, and authors and publishers 
addressing the needs of their largest market.

In my own classes, I hand out suggested homework solutions, but only 
on paper (although they could be scanned and put on the web, I 
haven't yet seen that happen). Exam solutions, however, I make 
available on the web, because all the exam questions are composed by 
me, and used just once (or used again only after a lapse of quite a 
few years). I currently use Haskell in my Programming Languages 
class, and five semesters' worth of exam questions (not all Haskell, 
of course) with solutions are posted on-line at 
http://www.cs.utexas.edu/users/ham/UTCS/CS345/OldTests/cs345OldTests.html 
. These aren't the same as textbook exercise solutions (the context 
is not as explicit as it is for exercises at the end of a chapter), 
but you're welcome to them.

If you use these up --or don't find them useful-- you might reflect 
on the fact that the conference papers and journal articles from 
which many folks learn lots of "interesting stuff" seldom include 
exercises.

With best wishes,
--Ham
At 11:37 PM +0100 2005/1/26, Christian Hofer wrote:
Maybe I am too much rooted in the German university system, where 
the students' autonomy is held high (against all evidence). But I 
never understood, why we - who have to learn the interesting stuff 
completely on our own, because bad luck supplies us only with Java 
teachers (although other professors use Scheme, Lisp, Prolog) - are 
punished for a possible misuse of the exercises' solutions by 
students who would by cheating loose some years of their lifetime 
before failing in the exams.

Regards,
Chris
Am 26.01.2005 um 15:41 schrieb Paul Hudak:
I'm not sure how Simon Thompson feels, or other instructors using 
his or my book, but a downside of posting all of the solutions is 
that the problems cannot be assigned for homework.  I have many of 
the solutions to SOE problems, and could post them, but am 
wondering if it would be better to make them available only to 
instructors, or to those who might convince me that they are not 
reading the book for credit.  Or is that being too draconian?

  -Paul
--
--
Hamilton Richards, PhD   Department of Computer Sciences
Senior Lecturer  The University of Texas at Austin
512-471-9525 1 University Station C0500
Taylor Hall 5.138Austin, Texas 78712-0233
[EMAIL PROTECTED][EMAIL PROTECTED]
http://www.cs.utexas.edu/users/ham/richards
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RE: Answers to Exercises in Craft of FP

[Christian Hofer]

Maybe I am too much rooted in the German university system, where the 
students' autonomy is held high (against all evidence). But I never 
understood, why we - who have to learn the interesting stuff completely 
on our own, because bad luck supplies us only with Java teachers 
(although other professors use Scheme, Lisp, Prolog) - are punished for 
a possible misuse of the exercises' solutions by students who would by 
cheating loose some years of their lifetime before failing in the 
exams.

Regards,
Chris
Am 26.01.2005 um 15:41 schrieb Paul Hudak:
I'm not sure how Simon Thompson feels, or other instructors using his 
or my book, but a downside of posting all of the solutions is that the 
problems cannot be assigned for homework.  I have many of the 
solutions to SOE problems, and could post them, but am wondering if it 
would be better to make them available only to instructors, or to 
those who might convince me that they are not reading the book for 
credit.  Or is that being too draconian?

  -Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem with Hyperlinking Haddock-documentation

[Daniel Fischer]

Am Mittwoch, 26. Januar 2005 21:49 schrieben Sie:
> On Wed, 26 Jan 2005, Daniel Fischer wrote:
> > Maybe somebody can enlighten me.
> >
> > When I run haddock and put the html files e.g. in directory ~/bar/foo,
> > any references to things defined in the Prelude or the libraries are
> > linked to, say ~/bar/foo/Prelude.html#t%3AFractional, which of course
> > does not exist, because the documentation for the Prelude is elsewhere.
> >
> > How can I tell haddock to link such references to where Prelude.html
> > actually is?
>
> I add an option like
>
> -i /usr/local/share/ghc-6.2/html/libraries/base/base.haddock

I have this, and the links are created, but they don't point there, they refer 
to the directory, I put my documentations in.
>
> or more of them, if I need more libraries. Just run
>  locate .haddock
> in a shell to find out what haddock files are available on your machine.

bash: locate :command not found

what now?

Trotzdem danke.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem with Hyperlinking Haddock-documentation

[Henning Thielemann]

On Wed, 26 Jan 2005, Daniel Fischer wrote:

> Maybe somebody can enlighten me.
>
> When I run haddock and put the html files e.g. in directory ~/bar/foo, any
> references to things defined in the Prelude or the libraries are linked to,
> say ~/bar/foo/Prelude.html#t%3AFractional, which of course does not exist,
> because the documentation for the Prelude is elsewhere.
>
> How can I tell haddock to link such references to where Prelude.html actually
> is?

I add an option like

-i /usr/local/share/ghc-6.2/html/libraries/base/base.haddock

or more of them, if I need more libraries. Just run
 locate .haddock
in a shell to find out what haddock files are available on your machine.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Looking for these libraries...

[John Goerzen]

Hi,

I'm looking for libraries / interfaces to these systems from Haskell:

LDAP
ncurses
zlib  (the one in darcs doesn't suit my needs)
bz2lib

Thanks,
John

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Problem with Hyperlinking Haddock-documentation

[Daniel Fischer]

Maybe somebody can enlighten me.

When I run haddock and put the html files e.g. in directory ~/bar/foo, any 
references to things defined in the Prelude or the libraries are linked to, 
say ~/bar/foo/Prelude.html#t%3AFractional, which of course does not exist, 
because the documentation for the Prelude is elsewhere.

How can I tell haddock to link such references to where Prelude.html actually 
is?

Please be aware of the fact that I know ///very/// little about html, 
hyperlinks and such, so be detailed and don't presuppose much.

Thanks,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Jorge Adriano Aires]

> >> How can I convert an Int into a Double?
> >
> > You don't convert to, you convert from :-)
> > The function 'fromIntegral' is probably what you want.
>
> And what function can I use to convert from Double to Int (the inverse of
> fromIntegral) ?

Use the functions in the RealFrac class.
http://www.haskell.org/onlinereport/standard-prelude.html#$tRealFrac

class  (Real a, Fractional a) => RealFrac a  where
 properFraction   :: (Integral b) => a -> (b,a)
 truncate, round  :: (Integral b) => a -> b
 ceiling, floor   :: (Integral b) => a -> b

J.A.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Stefan Holdermans]

Dmitri,
And what function can I use to convert from Double to Int (the inverse 
of
fromIntegral) ?
You should really have a look at the Prelude and the Standard Libraries.
Well, it depends on *how* you want to convert.
truncate :: (RealFrac a, Integral b) => a -> b
round :: (RealFrac a, Integral b) => a -> b
floor :: (RealFrac a, Integral b) => a -> b
ceiling :: (RealFrac a, Integral b) => a -> b
HTH,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Dmitri Pissarenko]

How can I convert an Int into a Double?
You don't convert to, you convert from :-)
The function 'fromIntegral' is probably what you want.
And what function can I use to convert from Double to Int (the inverse of
fromIntegral) ?
TIA
Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Non-blocking I/O (was: Re: Hugs vs GHC)

[Marcin 'Qrczak' Kowalczyk]

Glynn Clements <[EMAIL PROTECTED]> writes:

>> > The point is that the Unix documentation does not consider the short
>> > pause as data is read off your hard drive to be blocking. So that's why
>> > select will always report that data is available when you use it with a
>> > file handle.
>> 
>> Isn't this also for historic reasons?
>
> Partly.
>
> But I think that it's also because this functionality wasn't intended
> for the purpose which is being discussed, i.e. enabling a process to
> obtain maximal CPU utilisation.

I think it's also because if we considered reading from a slow file to
be blocking, we should also consider blocking many other calls which
access a disk. In particular anything which takes or returns a filename;
resolving a filename may involve reading a slow disk.

But in these cases the system doesn't know whether the programmer
really intended to do something else while mkdir() is completing,
because mkdir() is not performed on a file descriptor on which
non-blocking mode could have been set or reset.

It would need quite a different API.

-- 
   __("< Marcin Kowalczyk
   \__/   [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Dmitri Pissarenko]

Thanks all for the help!
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What are the MonadPlus laws?

[Iavor Diatchki]

Hello,

On Tue, 25 Jan 2005 22:49:06 -0500, Paul Hudak <[EMAIL PROTECTED]> wrote:
> Good point; I suppose the constraint m /= _|_
> should be added to the law.

This is not enough, at least in some cases.
Consider lists, and m being an infinite list, e.g. [1..]
Then we need that the inifinte concatenation of a empty lists
gives us the empty list which is not the case.

-Iavor


> 
> [EMAIL PROTECTED] wrote:
> > The problem is this "law":
> >
> > m >>= \k -> mzero === mzero
> >
> > I think this "law" is untrue for _all_ MonadPlus instances, and you can
> > trivially check this by setting m to bottom.
> >
> > Cbheers,
> > Andrew Bromage
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RE: Answers to Exercises in Craft of FP

[Gour]

Paul Hudak ([EMAIL PROTECTED]) wrote:

> I'm not sure how Simon Thompson feels, or other instructors using his or 
> my book, but a downside of posting all of the solutions is that the 
> problems cannot be assigned for homework.  

That's true. Being a self-learner I forgot that your books are used as a
textbooks.

> I have many of the solutions to SOE problems, and could post them, but
> am wondering if it would be better to make them available only to
> instructors, or to those who might convince me that they are not
> reading the book for credit.  Or is that being too draconian?

How to discern self-study from the university sudent?

And this is maybe specific to Haskell-like community, i.e. for other
programming languages there are so many books/materials/mailinglists/...
so it is prety hard to give some specific homework expecting one cannot
find an answer.

At the same time, those who take adavantage of solutions (both students
& self-study guys) won't benefit much from it - they have to pass the
exam at the end or write some real code in a language :-)

So, imho, solutions can be helpful for those who can take advantage of
them.

Let's hear what Simon Thompson thinks in regard.

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] using Map rather than FiniteMap

[S. Alexander Jacobson]

On Tue, 25 Jan 2005, David Menendez wrote:
Does having 'zipped' at the top level mean that the program is keeping
the entire 100,000-element list in memory?
I don't know, but I tested with zipped at the top, 
in the where, and it appears to make no 
performance or memory difference.

Also, would performance improve if you used Map.fromList? How about
Map.fromAscList?
HUGE IMPROVEMENT.  The old code had maximum 
residency of 11Mb and running time of 41s.  The 
code using Map.fromList has max. residency of 
6.4Mb and running time of 5.2s!

I guess foldlStrict is HUGELY more efficient than 
than foldr. (Why isn't it in the prelude?) But 
even using foldrStrict (fromList), we are still 
using 60 bytes per item and have ~30 bytes 
unaccounted for.  Any hints?

  import qualified Map
  main = print $ length  $ Map.keys theMap
where
zipped =zip [1..] [1..10]::[(Int,Int)]
theMap = Map.fromList zipped
-Alex-
__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

S. Alexander Jacobson writes:
After actually running the correct test, I am
still getting semi-ridiculous space behavior
(6k/pair)!
import qualified Map
zipped =zip [1..] [1..10]::[(Int,Int)]
untup f (x,y) = f x y
produce = foldr (untup Map.insert) Map.empty zipped
fm = length  $ Map.keys produce
main = print $ fm
Two questions I'm currently too lazy to investigate myself:
--
David Menendez <[EMAIL PROTECTED]> | "In this house, we obey the laws
  |of thermodynamics!"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Henning Thielemann]

On Wed, 26 Jan 2005, Luca Marchetti wrote:

> Hi
>
> why don't you try something like this:
>
> map (\(x,y) -> x+y) (zip [1,2,100] [2,3,500])
>
> list comprehension would sum every element of the firs list with every
> element of the second.

If 'zipWith (+)' doesn't satisfy you, what about
  map (uncurry (+)) (zip [1,2,100] [2,3,500])
 ?

B-]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Luca Marchetti]

Hi

why don't you try something like this:

map (\(x,y) -> x+y) (zip [1,2,100] [2,3,500])

list comprehension would sum every element of the firs list with every
element of the second.

On Wed, 2005-01-26 at 17:39 +0100, Dmitri Pissarenko wrote:
> Hello!
> 
> I have two lists of Double with equal length and want to create a third one,
> in which each element is the sum of the corresponding element of the first
> list and the second list.
> 
> If list1 is [1, 2, 100] and list2 is [2, 3, 500], then the result of the
> operation I desire is [3, 5, 600].
> 
> I wrote this function
> 
> 
> add2Img :: [Double] -> [Double] -> [Double]
> add2Img summand1 summand2 = sum
>   where sum = [ (x+y) | x <- summand1, y <- summand2 ]
> ,
> 
> but I'm getting
> 
> [3.0,4.0,501.0,4.0,5.0,502.0,102.0,103.0,600.0]
> 
> instead of
> 
> [1, 2, 100].
> 
> What is wrong with the function above?
> 
> TIA
> 
> Dmitri Pissarenko
> --
> Dmitri Pissarenko
> Software Engineer
> http://dapissarenko.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-- 

  Luca Marchetti
  Senior Application Specialist

  Bizmatica S.p.A.
  Via Pietrasanta, 14 - Building 3a
  20141 Milano, Italy

  e-mail:  [EMAIL PROTECTED]


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] using Map rather than FiniteMap

[Simon Marlow]

On 26 January 2005 16:42, S. Alexander Jacobson wrote:

> On Wed, 26 Jan 2005, Simon Marlow wrote:
>> When using the ordinary 2-generation collector, memory in use will
>> tend to be 2-3 times larger than the actual residency, because this
>> is a copying collector.
> 
> Ok. Perhaps you want a different name for
> this item in the reports?

Well, "memory in use" is pretty accurate - it measures the actual amount
of memory that the runtime has allocated from the OS.  "residency" is a
GC term which refers to the amount of live data.   I don't think these
terms are that confusing, but perhaps my explanation was?

>>> On the other hand, I found 10mb, 5mb, and 2.5mb
>>> maximum residency, but that is still ~100 bytes
>>> per record.
> 
> But 100 bytes per record in a (Map Int Int) seems
> awefully high.

That 100 bytes includes stack overhead.  Remember, when you ran the heap
profile which didn't show stack overhead you got a much more reasonable
figure.

>>> Lastly, I tried "example +RTS -p -K5M -hc" and
>>> then looked at the resulting graph (attachment #2)
>>> and it shows a total of 1.6Mb heap allocated and
>>> if that data is correct, it does correspond
>>> roughly to our 20-30 bytes per record estimate.
>> 
>> That profile doesn't include the stack, which sounds reasonable.
> 
> So I guess all the extra memory is actually being
> allocated on the stack rather than the heap which
> is a sign of a spaceleak.  If I solve the
> spaceleak I get the 70 bytes per item back.

Yup.

>> I haven't looked at your code in detail, hopefully someone else can
>> shed some light on why you're building up such a large stack in the
>> first place.
> 
> The code is just this 6 line program:
> 
>   import qualified Map
>   zipped =zip [1..] [1..10]::[(Int,Int)]
>   untup f (x,y) = f x y
>   produce = foldr (untup Map.insert) Map.empty zipped
>   fm = length  $ Map.keys produce
>   main = print $ fm
> 
> Can someone tell me what I can do to make this
> more efficient?

Replace the foldr by a foldl'?

  import Data.List
  produce = foldl' (untup (flip Map.insert)) Map.empty zipped

(untested)

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Jules Bean]

On 26 Jan 2005, at 16:39, Dmitri Pissarenko wrote:
Hello!
Hi Dmitri.
Have a browse around the haskell wiki! There's loads of interesting 
information and example code there...

add2Img summand1 summand2 = sum
where sum = [ (x+y) | x <- summand1, y <- summand2 ]

[3.0,4.0,501.0,4.0,5.0,502.0,102.0,103.0,600.0]
instead of
[1, 2, 100].
[(x+y) | x <- summand1, y <- summand2] means *all* possible sums x+y 
with x taken from the first list and y from the second. This is the 
nature of list comprehensions.

You rather want 'zipWith'.  Documentation at:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.List.html
...along with lots of other funky list processing stuff.
Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Stefan Holdermans]

Dmitri,
You're performing a point-wise addition
Err ... what I meant was: you're *not* performing a point-wise 
addition, but instead ...

Regards,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Stefan Holdermans]

Dmitri,
I have two lists of Double with equal length and want to create a 
third one,
in which each element is the sum of the corresponding element of the 
first
list and the second list.


add2Img :: [Double] -> [Double] -> [Double]
add2Img summand1 summand2 = sum
where sum = [ (x+y) | x <- summand1, y <- summand2 ]
,

What is wrong with the function above?
You're performing a point-wise addition, but instead add each element 
of the second list to each element of the first list, yielding n * m 
sums for list lengths n and m.

The function you're looking for is written
  add2Img = zipWith (+)
HTH,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List manipulation

[Gracjan Polak]

Dmitri Pissarenko wrote:
> Hello!
>
> I have two lists of Double with equal length and want to create a 
third one,
> in which each element is the sum of the corresponding element of the 
first
> list and the second list.
>
> If list1 is [1, 2, 100] and list2 is [2, 3, 500], then the result of the
> operation I desire is [3, 5, 600].

zipWith (+) [1,2,100] [2,3,500]
>
> I wrote this function
>
> 
> add2Img :: [Double] -> [Double] -> [Double]
> add2Img summand1 summand2 = sum
>where sum = [ (x+y) | x <- summand1, y <- summand2 ]
> ,
>
This is intepreted as two nestes "loops": foreach x in summand1 (foreach 
y in summand2: x + y). You need zipWith.

There is GHC extension: parallel list composition to do what you want. 
Lookup GHC documentation for extensions.

--
Gracjan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] using Map rather than FiniteMap

[S. Alexander Jacobson]

On Wed, 26 Jan 2005, Simon Marlow wrote:
When using the ordinary 2-generation collector, memory in use will tend
to be 2-3 times larger than the actual residency, because this is a
copying collector.
Ok. Perhaps you want a different name for 
this item in the reports?

On the other hand, I found 10mb, 5mb, and 2.5mb
maximum residency, but that is still ~100 bytes
per record.
But 100 bytes per record in a (Map Int Int) seems 
awefully high. A 3 record Map would be:

   (Bin 3 2 2
(Bin 1 1 1 Tip Tip)
(Bin 1 3 3 Tip Tip))
Here is how I account for memory:
sizeqty subtotal
Ints4   9   36
Pointers4   7   28
Constructors4   7   28
---
Total   92
Num Pairs3
Bytes/Pair  31
Is this accounting correct? Where do the other 70 
bytes/item go?

Lastly, I tried "example +RTS -p -K5M -hc" and
then looked at the resulting graph (attachment #2)
and it shows a total of 1.6Mb heap allocated and
if that data is correct, it does correspond
roughly to our 20-30 bytes per record estimate.
That profile doesn't include the stack, which sounds reasonable.
So I guess all the extra memory is actually being 
allocated on the stack rather than the heap which 
is a sign of a spaceleak.  If I solve the 
spaceleak I get the 70 bytes per item back.

I haven't looked at your code in detail, hopefully someone else can shed
some light on why you're building up such a large stack in the first
place.
The code is just this 6 line program:
import qualified Map
zipped =zip [1..] [1..10]::[(Int,Int)]
untup f (x,y) = f x y
produce = foldr (untup Map.insert) Map.empty zipped
fm = length  $ Map.keys produce
main = print $ fm
Can someone tell me what I can do to make this 
more efficient?

-Alex-
__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] List manipulation

[Dmitri Pissarenko]

Hello!

I have two lists of Double with equal length and want to create a third one,
in which each element is the sum of the corresponding element of the first
list and the second list.

If list1 is [1, 2, 100] and list2 is [2, 3, 500], then the result of the
operation I desire is [3, 5, 600].

I wrote this function


add2Img :: [Double] -> [Double] -> [Double]
add2Img summand1 summand2 = sum
where sum = [ (x+y) | x <- summand1, y <- summand2 ]
,

but I'm getting

[3.0,4.0,501.0,4.0,5.0,502.0,102.0,103.0,600.0]

instead of

[1, 2, 100].

What is wrong with the function above?

TIA

Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] using Map rather than FiniteMap

[Christian Maeder]

S. Alexander Jacobson wrote:
   zipped =zip [1..] [1..10]::[(Int,Int)]
   untup f (x,y) = f x y
   produce = foldr (untup Map.insert) Map.empty zipped
   fm = length  $ Map.keys produce
   main = print $ fm
Has this profile:
   example +RTS -p -K5M -RTS
total time  =5.10 secs   (255 ticks @ 20 ms)
total alloc = 612,534,236 bytes  (excludes profiling overheads)
   COST CENTREMODULE   %time %alloc
balanceMap   71.8   72.8
insert Map   12.2   10.8
size   Map9.09.7
binMap2.42.2
rotateRMap1.60.3
zipped Main   0.81.9
I get similar results without optimizations and much better ones using 
only about 160MB with -O.

Cheers Christian
-- unoptimized
   testMap +RTS -p -K5m -RTS
total time  =6.34 secs   (317 ticks @ 20 ms)
total alloc = 612,549,684 bytes  (excludes profiling overheads)
COST CENTREMODULE   %time %alloc
balanceCommon.Lib.Map74.1   72.8
insert Common.Lib.Map 9.8   10.8
size   Common.Lib.Map 9.59.7
binCommon.Lib.Map 1.62.2
zipped Main   1.31.9
-- optimized results
ghc --make TestMap.hs -O -prof -auto-all  -o testMap
   testMap +RTS -p -K5m -RTS
total time  =1.22 secs   (61 ticks @ 20 ms)
total alloc = 159,737,668 bytes  (excludes profiling overheads)
COST CENTREMODULE   %time %alloc
insert Common.Lib.Map39.30.5
balanceCommon.Lib.Map24.6   47.4
size   Common.Lib.Map21.3   34.1
foldR  Common.Lib.Map 3.32.5
zipped Main   3.36.5
untup  Main   3.30.8
produceMain   3.30.8
singleRCommon.Lib.Map 1.60.0
toAscList  Common.Lib.Map 0.01.5
single Common.Lib.Map 0.01.5
keys   Common.Lib.Map 0.01.5
binCommon.Lib.Map 0.03.0
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] using Map rather than FiniteMap

[Simon Marlow]

On 26 January 2005 14:29, S. Alexander Jacobson wrote:

> Ah, ok.  So I ran the code with 10 items,
> 5 items, and 25000 items and got total memory
> in use of 28Mb, 15Mb, and 8Mb respectively.  That
> comes to 260-280 bytes per record which is still
> an order of magnitude higher than the 20-30 bytes
> per record we would expect.

When using the ordinary 2-generation collector, memory in use will tend
to be 2-3 times larger than the actual residency, because this is a
copying collector.

> On the other hand, I found 10mb, 5mb, and 2.5mb
> maximum residency, but that is still ~100 bytes
> per record.

Right.

> Lastly, I tried "example +RTS -p -K5M -hc" and
> then looked at the resulting graph (attachment #2)
> and it shows a total of 1.6Mb heap allocated and
> if that data is correct, it does correspond
> roughly to our 20-30 bytes per record estimate.

That profile doesn't include the stack, which sounds reasonable.

> Regarding stack, I tried "example +RTS -p -K5M -xt
> -hc" and then ran hp2ps and looked at the
> resulting graph (attachment #1) SYSTEM appears to
> use 4mb of stack at the very beginning (presumably
> to create "zipped"), but I don't know why it
> would.  Then this stack is consumed by the rest of
> the program.

Stacks never get smaller in GHC, only bigger.  If you need 4Mb of stack
at one point in your program, you will forever have a 4Mb stack after
that (fixing this wouldn't really buy you much; the memory doesn't get
traversed or copied by the GC - but one thing you could do is madvise()
to tell the OS it doesn't have to page the memory, though).

I haven't looked at your code in detail, hopefully someone else can shed
some light on why you're building up such a large stack in the first
place.

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RE: Answers to Exercises in Craft of FP

[Paul Hudak]

I'm not sure how Simon Thompson feels, or other instructors using his or 
my book, but a downside of posting all of the solutions is that the 
problems cannot be assigned for homework.  I have many of the solutions 
to SOE problems, and could post them, but am wondering if it would be 
better to make them available only to instructors, or to those who might 
convince me that they are not reading the book for credit.  Or is that 
being too draconian?

  -Paul
Gour wrote:
Ketil Malde ([EMAIL PROTECTED]) wrote:
Another option is posting the excercise to this list (or perhaps in
comp.lang.functional), along with your current effort at solving it.
I consider it would be useful to have the the whole collection somewhere, 
maybe
on wiki since Thompson's book (beside Hudak's HSOE) very popular one for
learning Haskell and it can bring even more popularity for Haskell language.
Is it only me, but it looks that more & more posts are appearing on this list?
(As this could look like a homework request, don't expect the direct
solution, but I think you will get some hints to nudge you in the
right direction.)
Of course, but, otoh, solving ALL the exercises from the book is 
time-consuming, so to be able to sneak into some would be a nice learning 
experience :-)
Sincerely,
Gour

--
Professor Paul Hudak
Chair, Dept of Computer Science   Office: (203) 432-1235
Yale University   FAX:(203) 432-0593
P.O. Box 208285   email:  [EMAIL PROTECTED]
New Haven, CT 06520-8285  WWW:www.cs.yale.edu/~hudak
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[robert dockins]

After the discussion about file paths over the last several days I went 
home and put together a quick trial implementation for unix file paths, 
with the idea of adding windows, SMB and maybe VMS (why not?) paths.  It 
is based on a Path class.  I'll post it later when I get home.  However, 
I will attempt to recreate the class definition from memory now to see 
if we can get some discussion going about the methods needed/desired, 
and whether or not this is a good approach.

data PathRoot
   = UnixFilesystemRoot
   | WindowsDrive Char
   | SMBShare String String
   | VMSDevice String
   | ... -- whatever else we need
class (Show p) => Path p where
   isAbsolute :: p -> Bool
   isRelative :: p -> Bool
   isRelative = not . isAbsolute
   basename :: p -> String
   parent :: p -> p
   pathAppend :: p -> p -> p  -- 2nd arg must be a relative path
   pathSeparator :: p -> Char
   pathParser :: Parser p -- parsec parser
   parsePath :: String -> p
   parsePath str = case parse pathParser "" str of
   Left e = error (Show e)
   Right p = p
Other operations I think might be worthwhile:
pathRoot :: p -> Maybe PathRoot -- relative paths return Nothing
pathCleanup :: p -> p   -- remove .. and suchlike
commonAncestors :: p -> p -> p
pathFrom :: p -> p -> p   -- returns a relative path from the 1st to 
the 2nd
pathCompare :: p -> p -> ???  -- not sure what this should mean or return
hasExtension :: p -> String -> Bool
pathToForeign :: p -> IO (Ptr CChar)
pathFromForeign :: Ptr CChar -> IO p

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[David Roundy]

On Wed, Jan 26, 2005 at 01:39:01PM -, Simon Marlow wrote:
> We can't add libraries in a point release, because there's no way for
> code to use conditional compilation to test the patchlevel version
> number.

On the other hand, darcs doesn't rely on version numbers when looking for
libraries (instead, it sees if they exist by trying to compile with them),
so this constraint isn't necesary for *all* ghc users.
-- 
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[David Roundy]

On Wed, Jan 26, 2005 at 01:34:39PM -, Simon Marlow wrote:
> ... We can therefore:
> 
>  (a) make System.IO.FilePath be the new type, which is different from,
>  and incompatible with, IO.FilePath.  Similarly for 
>  System.IO.openFile, System.Directory.removeFile, and so on.
> 
>  (b) or just define a new type, and force you to insert read/show
>  to convert where necessary, eg. before calling openFile.
> 
> (a) is kind of the right thing, but (b) is a lot less painful in the
> short term.  Since we'll be migrating to a new IO library at some point,
> (b) is probably fine (the new IO library can use the new FilePaths
> exclusively), but we'll need to migrate System.Directory too.

One thing I've been wishing for some time (as long as we're discussing a
replacement for FilePath) was to have a FilePath class, which would allow
me to use my FastPackedStrings with the IO routines.  It seems silly to
have a byte-oriented filepath, convert it into a String and then have the
IO library convert back again to a byte-oriented string to call the C
library.

I've wished there were a

class FilePath f where
toStringFilePath :: f -> String
withCStringFilePath :: f -> (CString -> IO a) -> IO a

or something like that (where the withCStringFilePath could have a default
written in terms of toStringFilePath).  It's a shame when I use ffi for
some of my IO (which of course always requires CStrings) and haskell IO
libraries which always require Strings to keep having to convert back and
forth.

Alas, darcs does enough "quick" calls to stat (doesFileExist, etc) that the
cost isn't negligible.  Eventually I'll rewrite a lot of this to just use
the ffi (since I want to use lstat anyways, or its windows equivalent), but
it would be nice (eventually) not to have to do this.

But how painful would it be for the System.IO functions to have types such
as

readFile :: FilePath a => a -> String

?
-- 
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] File path programme

[Simon Marlow]

On 25 January 2005 19:45, Duncan Coutts wrote:

> On Tue, 2005-01-25 at 19:12 +, Ben Rudiak-Gould wrote:
>> My concern here is that someone will actually use the library once it
>> ships, with the following consequences:
>> 
>> 1. Programs using the library will have predictable
>> (exploitable) bugs in pathname handling. 
>> 
>> 2. It will never be possible to change the current weird
>> behavior, because it might break legacy code. The System.FilePath
>> library will 
>> have to remain in GHC forever in its current form, enticing
>> programmers with its promise of easy pathname handling and then
>> cruelly breaking its contract. 
>> 
>> If no one uses it in production code then we can fix it at our
>> leisure, and having it out there with "experimental" status isn't
>> necessarily a bad thing in that case. It just feels like we're
>> playing a dangerous game. 
> 
> That's a sufficiently persuasive argument for me!
> 
> Could we just punt this library for this release. After all we can add
> libraries in a later point release (eg 6.4.1) you just can't change
> existing APIs.

We can't add libraries in a point release, because there's no way for
code to use conditional compilation to test the patchlevel version
number.

This seems to be a common misconception, probably brought about by the
fact that the time between major releases of GHC is getting quite long.
Perhaps I should stop writing email and get some work done :)

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] what is a stack overflow?

[Tomasz Zielonka]

On Wed, Jan 26, 2005 at 01:04:29PM -, Simon Marlow wrote:
> On 25 January 2005 16:04, S. Alexander Jacobson wrote:
> > Is there a way to profile stack usage using GHCi
> > (without compiling) to find the problem?
> 
> +RTS -xt -RTS will include the stack in a heap profile.  See
> 
>   http://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html
> 
> It will show you the size of the stack over time, but not the contents
> of the stack.

BTW, has anyone considered making a stackless Haskell implementation?
For example, SML compiler SML/NJ allocates "stack" frames on the heap.

Best regards,
Tomasz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] File path programme

[Simon Marlow]

[ moving to [EMAIL PROTECTED] ]

On 26 January 2005 12:22, Malcolm Wallace wrote:

>> Could we just punt this library for this release. After all we can
>> add libraries in a later point release (eg 6.4.1) you just can't
>> change existing APIs.
> 
> FWIW, I agree with Duncan, Ben, and Peter, that the new
> System.FilePath interface is broken, and the implementation more so. 
> It would be better to redesign FilePaths as an algebraic datatype.

Ok, I'll go with the concensus.  System.FilePath in its current state
will be removed from the base package.

Isaac or Krasimir: can you make the required changes to Cabal?  (the
code is already duplicated in Distribution.Compat.FilePath, just remove
the import for GHC).

So let's aim for 6.6 to do it right, and design an abstract type for
path names.  We have to think about the migration path:  Haskell 98
programs must continue to work, so at least IO.FilePath must still be a
String, and IO.openFile must still take a String.  We can therefore:

 (a) make System.IO.FilePath be the new type, which is different from,
 and incompatible with, IO.FilePath.  Similarly for 
 System.IO.openFile, System.Directory.removeFile, and so on.

 (b) or just define a new type, and force you to insert read/show
 to convert where necessary, eg. before calling openFile.

(a) is kind of the right thing, but (b) is a lot less painful in the
short term.  Since we'll be migrating to a new IO library at some point,
(b) is probably fine (the new IO library can use the new FilePaths
exclusively), but we'll need to migrate System.Directory too.

Would someone like to take up the reigns on the design for the new
library?

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] using Map rather than FiniteMap

[Simon Marlow]

On 25 January 2005 23:27, S. Alexander Jacobson wrote:

> Oops.  It pays to check your checking code before
> making posts like this.
> 
> After actually running the correct test, I am
> still getting semi-ridiculous space behavior
> (6k/pair)!
> 
> import qualified Map
> zipped =zip [1..] [1..10]::[(Int,Int)]
> untup f (x,y) = f x y
> produce = foldr (untup Map.insert) Map.empty zipped
> fm = length  $ Map.keys produce
> main = print $ fm
> 
> Has this profile:
> 
>  example +RTS -p -K5M -RTS
> 
>   total time  =5.10 secs   (255 ticks @ 20 ms)
>   total alloc = 612,534,236 bytes  (excludes profiling overheads)
> 
>   COST CENTREMODULE   %time %alloc
>   balanceMap   71.8   72.8
>   insert Map   12.2   10.8
>   size   Map9.09.7
>   binMap2.42.2
>   rotateRMap1.60.3
>   zipped Main   0.81.9
> 
> Notice the 612Mb for storing a mapping from Int
> to Int!!

Notice that's 612Mb *allocation* to create the finite map and
deconstruct it into a list.  Not 612Mb of live heap to store the finite
map.  If you make sure everything is evaluated, and examine the heap
profile I'm sure you'll find that the finite map is taking a reasonable
amount of space (perhaps 20-30 bytes per node for storing integers, I
guess).  

To get a rough idea of the total live heap without profiling, you can
run the program with +RTS -sstderr and look at the memory "in use"
figure.

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Ketil Malde]

Dmitri Pissarenko <[EMAIL PROTECTED]> writes:

> How can I convert an Int into a Double?

You don't convert to, you convert from :-)
The function 'fromIntegral' is probably what you want.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] what is a stack overflow?

[Simon Marlow]

On 25 January 2005 16:04, S. Alexander Jacobson wrote:

> Ok.  I guessed I was producing a big expression
> of the form
> 
>addToFM (addToFM (addToFM (addToFM (addToFM ...)
> 
> I tried to solve it by doing
> 
>(addToFM $! fm) key val
> 
> But still got an error.  I then tried the same
> with the wrapper code, but still got the error.
> 
> Is there a way to profile stack usage using GHCi
> (without compiling) to find the problem?

+RTS -xt -RTS will include the stack in a heap profile.  See

  http://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html

It will show you the size of the stack over time, but not the contents
of the stack.

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Stefan Holdermans]

Dmitri,
How can I convert an Int into a Double?
fromIntegral :: (Integral a, Num b) => a -> b
HTH,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Dmitri Pissarenko]

Zitat von Henning Thielemann <[EMAIL PROTECTED]>:
On Wed, 26 Jan 2005, Dmitri Pissarenko wrote:
How can I convert an Int into a Double?
fromIntegral
Thanks!
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Converting from Int to Double

[Henning Thielemann]

On Wed, 26 Jan 2005, Dmitri Pissarenko wrote:

> How can I convert an Int into a Double?

fromIntegral

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What are the MonadPlus laws?

[Jules Bean]

On 26 Jan 2005, at 08:41, Keean Schupke wrote:
I cannot find any reference to MonadPlus in category theory. At a 
guess I would say that
it was the same as a Monad except the operators are id and co-product 
(or sum)... That would mean the 'laws' would be exactly the same as a 
Monad, just with (0,+) instead of (1,*)...

I don't know if the categorists have a word for it. It isn't "the same 
as a Monad except", it's rather "the same as a Monad and also...". Note 
that translating between the normal categorical point of view and the 
haskell one is something of a pain since programmers think with Kleisli 
arrows (computations).

A MonadPlus is a Monad T with, in addition, the structure of a monoid 
on all types T a, satisfying the some conditions. I follow Wadler and 
use zero and ++ for the monoid.

Unit conditions: If you apply a monadic computation (that is, Kleisli 
arrow) to the zero object you get zero, that there is a special zero 
computation (that is concretely \x -> zero) which gives you the zero 
object when you apply it to anything.

Compatibility of ++ with computations:
The first condition just says that if you apply a computation to the 
sum of two objects, that should be the same as applying the computation 
twice, once to each object, and adding the results.

(m ++ n) >>= f == (m >>= f) ++ (n >>= f)
The two slightly more subtle conditions observe that it is possible to 
'lift' the monoid operation to Kleisli arrows, i.e. if you can add 
objects, then you can add computations (of the same type):

(+++) : (a -> m b) -> (a -> m b) -> (a -> m b)
\f g x -> f x ++ g x
Then you require that if you first add two computations and apply them 
to a single object, you get the same result as applying the 
computations separately and adding the results..

m >>= (f +++ g) == (m >>= f) ++ (m >>= g)
-
If these are a common categorical notion then I'd expect them to be 
called 'additive monads' or something, but I can't immediately track 
down a reference.

If you translate the notion back to the more standard categorical 
approach, using mu (join) and eta (return), it may be enlightening, but 
off hand I can't quite see what the rules look like.

Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Converting from Int to Double

[Dmitri Pissarenko]

Hello!

I have a list of integer numbers (grayscale values from 0 to 255) and want to
convert them to a list of double numbers, so that each number is 0 <= x <= 1,
where 0 is completely black and 1 is completely white.

Before I convert the numbers, I need to convert them to a list of double
values (then I can use map to re-scale each element from 0..255 to 0..1).

How can I convert an Int into a Double?

TIA

Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] File path programme

[Malcolm Wallace]

> Could we just punt this library for this release. After all we can add
> libraries in a later point release (eg 6.4.1) you just can't change
> existing APIs.

FWIW, I agree with Duncan, Ben, and Peter, that the new System.FilePath
interface is broken, and the implementation more so.  It would be
better to redesign FilePaths as an algebraic datatype.

Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Can't do basic time operations with System.Time

[Simon Marlow]

On 25 January 2005 17:17, John Goerzen wrote:

> On Tue, Jan 25, 2005 at 03:15:38PM -, Simon Marlow wrote:
>> normalizeTimeDiff (and TimeDiff in general) is wrong.  I wouldn't
>> recommend using it.  There's the TimeExts library in the lang
>> package, which might be useful to you.
> 
> I'm curious about that package.  It's in my ghc source tree but not
> documented at
> http://www.haskell.org/ghc/docs/latest/html/libraries/index.html.
> 
> Is it assumed to be portable and available outside ghc?

It's an old non-hierarchical library, unfortunately with no
documentation.  It'll probably disappear in GHC 6.6, but you can always
take the source and use it in your apps.  Hopefully by 6.6 there will be
a decent date/time library that provides this functionality.

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What are the MonadPlus laws?

[Ralf Laemmel]

Jules Bean wrote:
Are there any interesting programming uses of MonadPlus apart from 
'calculations returning multiple values'.. i.e. 
lists/sets/multisets/maybe?
Just a minor point ...
You mention Maybe in the list above but I would like to
wonder whether it is fully appropriate to associate it with
"calculations returning multiple values". Depending on what
you find interesting, I would like to mention *biased binary choice*.
Try the left operand first, if it fails, try the second operand. For
instance, this is a key idiom in strategic programming with Strafunski
(and has been adopted from Stratego). All in all, this more like "try
and catch" or "exception handling" rather than "calculations returning
multiple values".
Ralf
--
Ralf Laemmel
VU & CWI, Amsterdam, The Netherlands
http://www.cs.vu.nl/~ralf/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What are the MonadPlus laws?

[Jules Bean]

On 26 Jan 2005, at 05:57, David Menendez wrote:
Philip Wadler listed those as the laws he "would usually insist on" in 
a
1997 message[1].

[1] 
He also mentions two other possible, but problematic, laws:
m >>= \x -> mzero   == mzero
m >>= \x -> k x `mplus` h x == m >>= k `mplus` m >>= h
The first doesn't hold when m is bottom. The second doesn't hold for
lists.
Well I think the issue with bottom is not too upsetting.
The second holds 'up to reordering of the elements', I think?. If you 
consider lists as representing non-deterministic or multiple-valued 
computation, then it is quite natural to feel comfortable ignoring the 
ordering. (In effect, using lists as a model for multi-sets, which form 
a commutative monad?)

But it certainly looks like the IO instance for MonadPlus is badly 
broken.

Are there any interesting programming uses of MonadPlus apart from 
'calculations returning multiple values'.. i.e. 
lists/sets/multisets/maybe?

Jules
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Visual Programming Languages

[Keean Schupke]

Hmm, can't resist commenting on this one!
Bayley, Alistair wrote:
This was odd...
Some cherry-picked quotes from the manifesto:
 http://alarmingdevelopment.org/index.php?p=5
- Visual languages are not the solution: ... common idea is to replace AST
structures with some form of graphical diagram. ...
 

Agree, point and grunt is much slower than entering commands. Its like 
being stuck in a country where you don't speak the language - all you 
can do is point at things and grunt ('click') and hope they understand you.

- Programming is not Mathematics
 

Disagree strongly... Bad programming seems to have little to do with 
mathematics, good programming often has the elegance of a well thought 
out proof. Beauty in programming is like beauty in mathematics.

- Change is natural: There has been much effort expended to remove the
concept of mutable state from programming, to be replaced by immutable
values as in mathematics. This is entirely misguided. ... Monads are a
reductio ad absurdum.  [ Heresy! :-) ]
 

Change is natural, but that has nothing to do with mutable state.
Parallelism will make mutable state less attractive, as will
hardware/software co-design. Isolating changes within a verifiable
sandbox (like the ST/State monads) reduces errors due to unforseen
interactions.
- Control flow considered harmful:  ... The primary reason for this is to
permit side-effects to be ordered by the programmer. ... [ This appears to
contradict the criticism of monads. ]
 

Agree - control flow causes the possible paths (or corner cases) in the
program to increase exponentially. Program correctness verification becomes
much harder with more possible-paths.
   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to convert from "IO String" to String

[Dmitri Pissarenko]

Thanks for your response!
Now it works!
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Visual Programming Languages

[Stijn De Saeger]

> This was odd...
> 
> Some cherry-picked quotes from the manifesto:
>   http://alarmingdevelopment.org/index.php?p=5
> 
>  - Visual languages are not the solution: ... common idea is to replace AST
> structures with some form of graphical diagram. ...
> 
>  - Programming is not Mathematics
> 
>  - Change is natural: There has been much effort expended to remove the
> concept of mutable state from programming, to be replaced by immutable
> values as in mathematics. This is entirely misguided. ... Monads are a
> reductio ad absurdum.  [ Heresy! :-) ]
> 
>  - Control flow considered harmful:  ... The primary reason for this is to
> permit side-effects to be ordered by the programmer. ... [ This appears to
> contradict the criticism of monads. ]
> 
> But then the demo shows us how to define a Factorial function using an
> editor that (AFAICT) is simply operating on AST structures, in a
> tree-oriented layout. I must be missing something.
> 
> Alistair.

Yes, it is a bit of a twist. I came across this thing a couple of days
ago on the LtU blog, and somehow thought it relevant to the issue of
visual programming. I'm curious why the author himself doesn't
consider this to be a visual programming language, considering that
the language only allows you to program by copying and pasting.

stijn.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Visual Programming Languages

[Bayley, Alistair]

> From: Stijn De Saeger [mailto:[EMAIL PROTECTED] 
> 
> Don't know if this is exactly what you were thinking of, but you may
> want to have a look at
> www.subtextual.org
> 
> if you do, make sure you watch the demo.


This was odd...

Some cherry-picked quotes from the manifesto:
  http://alarmingdevelopment.org/index.php?p=5


 - Visual languages are not the solution: ... common idea is to replace AST
structures with some form of graphical diagram. ...

 - Programming is not Mathematics

 - Change is natural: There has been much effort expended to remove the
concept of mutable state from programming, to be replaced by immutable
values as in mathematics. This is entirely misguided. ... Monads are a
reductio ad absurdum.  [ Heresy! :-) ]

 - Control flow considered harmful:  ... The primary reason for this is to
permit side-effects to be ordered by the programmer. ... [ This appears to
contradict the criticism of monads. ]


But then the demo shows us how to define a Factorial function using an
editor that (AFAICT) is simply operating on AST structures, in a
tree-oriented layout. I must be missing something.


Alistair.

-
*
Confidentiality Note: The information contained in this   message, and any
attachments, may contain confidential   and/or privileged material. It is
intended solely for the   person(s) or entity to which it is addressed. Any
review,   retransmission, dissemination, or taking of any action in
reliance upon this information by persons or entities other   than the
intended recipient(s) is prohibited. If you received  this in error, please
contact the sender and delete the   material from any computer.
*

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: What are the MonadPlus laws?

[Keean Schupke]

David Menendez wrote:
Philip Wadler listed those as the laws he "would usually insist on" in a
1997 message[1].
   [1] 
He also mentions two other possible, but problematic, laws:
   m >>= \x -> mzero   == mzero
   m >>= \x -> k x `mplus` h x == m >>= k `mplus` m >>= h
The first doesn't hold when m is bottom. The second doesn't hold for
lists.
 

I would like to know what category MonadPlus represents... A Monad is a 
category
where the objects are functors and the operators are id and product both 
of which
are natural transformations... Presumably the 'laws' for a monad can be 
derived from this
statement.

I cannot find any reference to MonadPlus in category theory. At a guess 
I would say that
it was the same as a Monad except the operators are id and co-product 
(or sum)... That would mean the 'laws' would be exactly the same as a 
Monad, just with (0,+) instead of (1,*)...

   Keean.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe