Re: [Haskell-cafe] Re: Knot tying vs monads

[John D. Ramsdell]

On Nov 17, 2007 3:04 PM, apfelmus [EMAIL PROTECTED] wrote:


 Unfortunately, I don't have Paulson's book (or any other ML book :) at
 home. I'm too lazy to figure out the specification from the source code,


I guess the code is too opaque, as my colleague claimed.

The layout the algorithm generates condensed indented blocks.  Within a
block, it inserts a newline when the distance to the next break point plus
the current position is greater than the space remaining on the current
line.   Thus if S-Expression lists are rendered as blocks with indent two,
and every element in a list is separated by a break point of length one,
with the proper margin, you would see:

(defthingy name-of-thingy
  (one thing) (two thing)
  (a-big-thing-made-bigger)
  (three thing) (four thing))

As an exercise, the book asks you to implement group indent, where if any
break point in a group inserts a newline, they all do.  So with that layout,
one would get:

(defthingy
  name-of-thingy
  (one thing)
  (two thing)
  (a-big-thing-made-bigger)
  (there thing)
  (four thing))

The C version I wrote supports this layout, but I didn't bother with that
extension for the Haskell version.

On the strictness annotations, my reasons for them are the usual ones,
primarily to prevent memory leaks due to dragging, but a performance boost
is always welcome.  At some point, I plan to profile the code with and
without the annotations, and find out where they are needed.

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

RE: [Haskell-cafe] Stream fusion for Hackage

[Simon Peyton-Jones]

|  Will it eventually replace Data.List in GHC?
|
| That is the plan, yep.

But first we need to solve the concatMap problem, no?

So far as I know, fold/build has the property that if fusion doesn't happen, no 
harm is done. But streams risk making the program *worse* if Good Things do not 
happen to happen.  This makes me anxious.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Stewart
| Sent: 18 November 2007 20:09
| To: Tom Schrijvers
| Cc: haskell-cafe@haskell.org
| Subject: Re: [Haskell-cafe] Stream fusion for Hackage
|
| Tom.Schrijvers:
|  On Sat, 17 Nov 2007, Don Stewart wrote:
| 
|  Just a quick announce: the stream fusion library for lists,
|  that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
|  is now available on Hackage as a standalone package:
|  
| 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.1.1
|  
|  As described in the recent paper:
|  
| Stream Fusion: From Lists to Streams to Nothing at All
| Duncan Coutts, Roman Leshchinskiy and Don Stewart. ICFP 2007
|  
|  This is a drop-in replacement for Data.List.
| 
|  Will it eventually replace Data.List in GHC?
|
| That is the plan, yep.
| ___
| 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

[Haskell-cafe] ANN: The Monad.Reader Issue 9: SoC special

[Wouter Swierstra]

I am pleased to announce that a new issue of The Monad.Reader is now  
available:


  http://www.haskell.org/haskellwiki/The_Monad.Reader

Issue 9 is a Summer of Code Special - it consists of three articles  
from student participants of Google's Summer of Code, describing the  
projects they worked on:


  * Thomas Schilling
Cabal Configurations

  * Jason Dagit
Darcs Patch Theory

  * Mathieu Boespflug
TaiChi: how to check your types with serenity

The Monad.Reader is a quarterly magazine about functional  
programming. It is less formal than a journal, but somehow more  
enduring than a wiki page or blog post.


If you'd like to write something for the next issue of The  
Monad.Reader, please get in touch. I haven't fixed the deadline for  
the next issue just yet. I hope to send out an official call for copy  
fairly soon.


Enjoy!

  Wouter



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

Re: [Haskell-cafe] ANN: The Monad.Reader Issue 9: SoC special

[Dougal Stanton]

On 19/11/2007, Wouter Swierstra [EMAIL PROTECTED] wrote:


 I am pleased to announce that a new issue of The Monad.Reader is now
 available:

http://www.haskell.org/haskellwiki/The_Monad.Reader

Thanks Wouter, the haiku look great! ;-)

-- 
Dougal Stanton
[EMAIL PROTECTED] // http://www.dougalstanton.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What is the role of $!?

[Henning Thielemann]

On Sun, 18 Nov 2007, Andrew Coppin wrote:

 Lauri Alanko wrote:
  Please note that if you're using GHC, bang patterns are often much
  more convenient than $! or seq when you want to enforce strictness:
 
  http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html
 

 Wait, so...

   f x = x + 1; f $! (a + b)

 and

   f !x = x + 1; f (a + b)

 mean the same thing?

 Well, you learn something new every day... (I guess wanting a function's
 arguments to evaluate before the rest of that function is quite a common
 thing to want. Neat!)

For my taste it makes the language more complicated that sometimes 'lazy'
is default and 'strict' must be enforced and in other cases it is the
other way round. Would it be a good idea to make 'lazy' the default and
'strict' optional, and the strictness analyzer handles the obvious cases
where there is no difference?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: The Monad.Reader Issue 9: SoC special

[Yitzchak Gale]

Wouter Swierstra wrote:
 I am pleased to announce that a new issue of The Monad.Reader is now
 available:
http://www.haskell.org/haskellwiki/The_Monad.Reader

Dougal Stanton wrote:
 Thanks Wouter, the haiku look great! ;-)

I agree, they are fantastic! (And they are not short.)

Perhaps you were inspired by the classic 1998 Salon
haiku challenge. In any case, I think a reference is appropriate:

http://archive.salon.com/21st/chal/1998/01/26chal.html
http://archive.salon.com/21st/chal/1998/02/10chal2.html

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

[Haskell-cafe] Re: Knot tying vs monads

[ChrisK]

John D. Ramsdell wrote:
 On Nov 17, 2007 3:04 PM, apfelmus [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Unfortunately, I don't have Paulson's book (or any other ML book :) at
 home. I'm too lazy to figure out the specification from the source code,

 I guess the code is too opaque, as my colleague claimed.

Yes, a bit opaque.  The variable names are not descriptive enough and not
documented.  I have just rewritten your code with mostly trivial changes all of
which clarify what the code is doing in each expression.

For instance, blocksize and space* were both measured relative to margin
instead of simply using the column number.

The file is both att

 {-# LANGUAGE BangPatterns #-}
 
 -- Author: Chris Kuklewicz
 --
 -- This is a rewrite of John D. Ramsdell Pretty.hs code on
 -- haskell-cafe mailing list
 
 -- Changelog from Pretty.hs
 -- All Pretty elements have a length field (lazy at the moment)
 -- Inlined logic of 'blanks' and used new 'prepend' instead
 -- Replaced blocksize by startColumn == margin - blocksize
 -- Replaced space by colunmIn == margin-space
 -- Documented what 'after' means
 module Blocks(Pretty,str,brk,spc,blo,cat,pr) where
 
 -- All of the len's are non-negative, guaranteed by smart constructors
 data Pretty = Str { len :: Int, string :: String}
 | Brk { len :: Int }
 | Blo { len :: Int,  indentBy :: Int, parts :: [Pretty] }
 
 str s = Str (length s) s
 
 brk n | n  0 = error (Cannot have negative width brk! n =  ++ show n)
   | otherwise = Brk n
 
 spc = brk 1
 
 blo indent es | indent  0 = error (Cannot have negative width blo! indent = 
  ++ show indent)
   | otherwise = Blo (sum (map len es)) indent es
 
 cat = blo 0
 
 {-# INLINE pr #-}
 pr :: Int - Pretty - (String-String)
 pr margin e sRest  = let {startColumn = 0; after = 0; columnIn = 0}
  in snd (printing margin startColumn after [e] (columnIn, 
 sRest))
 
 {-# INLINE printing #-}
 printing :: Int - Int - Int - [Pretty] - (Int,String) - (Int,String)
 -- margin is the desired maximum line length and must be non-negative
 -- startColumn, columnIn, column', and columnOut are all non-negative,
 -- but any of them may be greater than margin
 printing margin | margin  0 = error (Cannot have non-positive margin! 
 margin == ++show margin)
 | otherwise = block where
 
   -- startColumn is the current amount of indent after newline
   -- after is how much must be laid after the (e:es) and before the next 
 break, non-negative
   block !startColumn !after = layout where
 
 -- (e:es) are the items to layout before 'sIn'
 -- columnIn is the starting column for laying out 'e'
 -- columnOut is the column after the (e:es) have been laid out
 layout [] columnIn'sIn'pair = columnIn'sIn'pair
 layout (e:es) (!columnIn,sIn) = (columnOut,sOut)  where
 
   (columnOut,s') = layout es (column',sIn)
 
   -- column' is the column to use after when laying out es, after laying 
 out e
   (column',sOut) =
 case e of
   Str n str - (columnIn+n, showString str s')
   Brk n | columnIn + n + breakDist es after = margin - (columnIn+n, 
 prepend n ' ' s')
 | 0 = startColumn - (startColumn, '\n':prepend startColumn 
 ' ' s')
 | otherwise - (0, '\n':s')
   Blo _n  indent es' - let startColumn' = indent + columnIn
 after' = breakDist es after
 in block startColumn' after' es' (columnIn,s')
 
 -- Trivial helper function to prepend 'n' copies of character 'c'
 {-# INLINE prepend #-}
 prepend n c s | n  0 = error (prepend called with ++show n++  0 !)
   | otherwise = loop n where loop 0 = s
  loop n = c : loop (pred n)
 
 -- after =0 implies breakDist _ after = 0
 -- Note that contained Blo's are assumed to layout in one line without using 
 any internal breaks.
 breakDist :: [Pretty] - Int - Int
 breakDist esIn !after = accum esIn 0 where
   accum [] beforeBrk = beforeBrk + after
   accum (Brk {}:_) beforeBrk = beforeBrk
   accum (e : es)   beforeBrk = accum es (beforeBrk + len e)
 
 test1 = putStrLn $
   pr 5 (blo 3 [str Hello,spc,str World!
   ,blo 3 [str Goodbye,spc,str Space!]
   ,spc,cat [str The,spc,str End]]) 
 
 test2 = putStrLn $
   pr 12 (blo 3 [str Hello,spc,str World!,spc
,blo 3 [str Goodbye,spc,str Space!]
,spc,cat [str The,spc,str End]]) 
 
 test3 = putStrLn $
   pr 12 (blo 3 [str Hello,spc,str World!
,blo 3 [str Goodbye,spc,str Space!]
,spc,cat [str The,spc,str End]]) 
 
 
 {-
 *Blocks test1
 Hello
World!Goodbye
 Space!
The
End
 *Blocks test2
 Hello World!
Goodbye
   Space!
The End
 *Blocks test3
 Hello
World!Goodbye
 Space!
The End
 -}

___

Re: [Haskell-cafe] Stream fusion for Hackage

[David Roundy]

On Sat, Nov 17, 2007 at 06:31:08PM -0800, Don Stewart wrote:
 Just a quick announce: the stream fusion library for lists, 
 that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
 is now available on Hackage as a standalone package:

Just to note: I'm excited about one day using this with darcs.  Right now
we're using (in the unstable branch) our own list type so we can use type
witnesses.  I look forward to making this as efficient as the built-in
lists (or more efficient?) one of these days... (and I've no suggestions on
the namespace question).
-- 
David Roundy
Department of Physics
Oregon State University
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Knot tying vs monads

[apfelmus]

John D. Ramsdell wrote:

On Nov 17, 2007 3:04 PM, apfelmus [EMAIL PROTECTED] wrote:


Unfortunately, I don't have Paulson's book (or any other ML book :) at
home. I'm too lazy to figure out the specification from the source code,


I guess the code is too opaque, as my colleague claimed.

The layout the algorithm generates condensed indented blocks.  Within a
block, it inserts a newline when the distance to the next break point plus
the current position is greater than the space remaining on the current
line.   Thus if S-Expression lists are rendered as blocks with indent two,
and every element in a list is separated by a break point of length one,
with the proper margin, you would see:

(defthingy name-of-thingy
  (one thing) (two thing)
  (a-big-thing-made-bigger)
  (three thing) (four thing))

As an exercise, the book asks you to implement group indent, where if any
break point in a group inserts a newline, they all do.  So with that layout,
one would get:

(defthingy
  name-of-thingy
  (one thing)
  (two thing)
  (a-big-thing-made-bigger)
  (there thing)
  (four thing))

The C version I wrote supports this layout, but I didn't bother with that
extension for the Haskell version.


Thanks. The interesting case of nested blocks still needs to be 
specified, but with this description in mind and judging from the code, 
I guess it behaves as follows: either a block fits entirely on the 
remaining line (no line breaks inside), or it begins a new line.


Now, the quest of programming is to make this description executable by 
computers while keeping it understandable by humans.


This is straightforward to do with Wadler's pretty printer combinators 
(package wl-pprint on http://hackage.haskell.org )


  data S = Atom String | List [S]  -- S-expressions

  layout :: Int - [S] - Doc
  layout indent [] = empty
  layout indent (x:xs) = foldr1 () (render x : map f xs)
where
f x@(Atom _) = group line   render x
f x@(List _) = group (line  render x)

render (Atom s ) = text s
render (List xs) = nest indent $ parens $ layout xs

The semantics of  Doc  are (for more, see Wadler's paper):  Doc  is a 
document with a set of different layouts, where the only difference 
between them is that some  line  primitives are rendered as (\n ++ 
replicate currentIndentation ' ') and some are rendered as a single 
space. Now,  group x  adds a new layout to the set  x , namely the 
layout where all  line  in  x  have been flattened to a single space. 
This way, the definition of  f  directly reflects the alternative 
either a block fits entirely on the remaining line or it begins a new 
line.


Your group indent extension is even easier, namely just

  layout2 :: Int - [S] - Doc
  layout2 indent = sep . map render
where
render (Atom s ) = text s
render (List xs) = nest indent $ parens $ layout2 xs

with the functions

  sep = group . foldr ($) empty
  x $ y = x  line  y

from the library.


On the strictness annotations, my reasons for them are the usual ones,
primarily to prevent memory leaks due to dragging, but a performance boost
is always welcome.  At some point, I plan to profile the code with and
without the annotations, and find out where they are needed.


That seems excessive. Can you really prove that this will prevent space 
leaks? I doubt that.


Laziness is still useful (example: early bail-out in your  breakdist ) 
if only the data structures are fully evaluated as opposed to every 
function being strict, so it's an interesting idea. But that doesn't 
guarantee zero space leaks, since


  sumFromTo :: Int - Int - Int
  sumFromTo a b = f a b 0
where f a b k = if a == b then k else f (a+1) b (k+a)

is one. Also, you won't be able to conveniently use lists as suspended 
loops which would be a pity.



Regards,
apfelmus

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

[Haskell-cafe] HDBC-ODBC crashes on ghc 6.8

[Thomas Hartman]

This minimal program below fails in 6.8.1, works for 6.6.1, for up to date 
HDBC-ODBC-1.1.3. (I tried installing both from package and from darcs 
head)

Installed and running from cygwin.

When I run it as runghc fail.hs I get a windows popup error ghc.exe has 
encountered a problem and needs to close, sorry for the inconvenience. 
ghci, same behavior.

When I run it as ghc -e 'main' fail.hs, I don't get a popup window, and no 
error message is output, but it fails all the same. (I know this because 
more complicated, non-minimal programs, fail.)

So this would seem to be a problem with ghc 6.8.1.

$ cat fail.hs

import Database.HDBC
import Database.HDBC.ODBC

main = connectODBC some valid connect string, works when run from 6.6.1, 
not from 6.8.1




---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Knot tying vs monads

[ChrisK]

 The data dependency is circular.  The case e of Str and Brk are not-circular:
 layout examines the input parameters to determine column'.  Then column'
 is used to compute columnOut and s'.  Then the current data is
 prepended to s'.  The Blo case is the circular one.  Pushing the circular
 definitions in to this case (and using the mapSnd helper) results in:

 layout :: [Pretty] - (Int,String) - (Int,String)
 layout [] columnIn'sIn'pair = columnIn'sIn'pair
 layout (e:es) (!columnIn,sIn) =
   case e of
 Str n str - mapSnd (showString str) $ layout es (columnIn+n,sIn)
 Brk n | columnIn + n + breakDist es after = margin -
   mapSnd (prepend n ' ') $ layout es (columnIn+n,sIn)
   | 0 = startColumn -
   mapSnd (('\n':).prepend startColumn ' ') $ layout es 
 (startColumn,sIn)
   | otherwise - mapSnd ('\n':) $ layout es (0,sIn)
 Blo _n  indent es' - let startColumn' = indent + columnIn
   after' = breakDist es after
   (columnOut,s') = layout es (column',sIn)
   (column',sOut) = block startColumn' after' 
 es' (columnIn,s')
   in (columnOut,sOut)

 mapSnd f (a,b) = (a,f b)

The circular usage of column' and s' can be unwound by importing 
Control.Monad.Fix(fix)
and writing a definition with fix that explicitly feeds back the s':

 Blo _n  indent es' - let startColumn' = indent + columnIn
   after' = breakDist es after
   withS ~(_,s') = let (column',sOut) = block 
 startColumn' after' es' (columnIn,s')
   (columnOut,s'') = 
 layout es (column',sIn)
   in ((columnOut,sOut),s'')
   in fst (fix withS)

In withS above, the column' is created by the call to block and consumed by the 
call to layout.
The s'' is fed back to become s' by the use of fix.  The actual answer is the 
fst component.

It is also possible to avoid the lazy '~' matching by using snd:

 Blo _n  indent es' - let startColumn' = indent + columnIn
   after' = breakDist es after
   withS ans's' = let (column',sOut) = block 
 startColumn' after' es' (columnIn,snd ans's')
  (columnOut,s'') = layout 
 es (column',sIn)
  in ((columnOut,sOut),s'')
   in fst (fix withS)


Whether any of these three versions is clearer to the previous message is a 
matter of taste.

Cheers,
  Chris

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

[Haskell-cafe] expanded standard lib

[brad clawsie]

i would categorize myself as a purely practical programmer. i enjoy
using haskell for various practical tasks and it has served me
reliably. one issue i have with the library support for practical
problem domains is the half-finished state of many fundamental
codebases such as networking and database support. 

in the perl world, support for these domains is provided through cpan, 
and this model is viable due to the (once) massive number of perl
coders out there. in the java, c# etc world, a batteries included
approach implies a narrowing of options, but also an immediate
delivery of functionality.

so far the haskell community has taken the cpan route for most
practical libs but i wonder if a batteries included approach might
help get some key libraries to a more complete state. in particular, i
would like to see support for basic internet protocols, database
connectivity, and potentially xml parser support rolled into the ghc
standard libs. there is always a strong debate on where the line is
drawn, but this functionality at least shows up in a plurality of
practical projects. the batteries included approach does imply
choosing preferred solutions when more than one library is available,
this can also be difficult. that said, i think haskell would pick up a
lot of new coders if it was obvious that the functionality they were
looking for came out of the base libs.

i know that people will say they don't use a database or xml, but
there will always be parts of a standard library that any particular 
coder will never touch...but still see value in the inclusion for
others.

comments?


pgpk4lhXIlWSg.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] The Yampa Arcade: source code available?

[Peter Verswyvelen]

I can find the paper, but is the source code for that Space Invaders 
alike game also available somewhere?


Thanks,
Peter

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

Re: [Haskell-cafe] expanded standard lib

[Justin Bailey]

On Nov 19, 2007 10:25 AM, brad clawsie [EMAIL PROTECTED] wrote:
 so far the haskell community has taken the cpan route for most
 practical libs but i wonder if a batteries included approach might
 help get some key libraries to a more complete state. in particular, i
 would like to see support for basic internet protocols, database
 connectivity, and potentially xml parser support rolled into the ghc
 standard libs. there is always a strong debate on where the line is

I agree strongly. I particularly miss a standard HTTP library.

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

Re: [Haskell-cafe] The Yampa Arcade: source code available?

[Stefan Kersten]

On 19.11.2007, at 19:54, Peter Verswyvelen wrote:
I can find the paper, but is the source code for that Space  
Invaders alike game also available somewhere?


it's included here: http://haskell.org/yampa/afrp-0.4-src.tgz

btw, does anybody know what's the current state of affairs with yampa/ 
afrp? is the framework still developed further?


sk

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

Re: [Haskell-cafe] The Yampa Arcade: source code available?

[Don Stewart]

sk:
 On 19.11.2007, at 19:54, Peter Verswyvelen wrote:
 I can find the paper, but is the source code for that Space  
 Invaders alike game also available somewhere?
 
 it's included here: http://haskell.org/yampa/afrp-0.4-src.tgz
 
 btw, does anybody know what's the current state of affairs with yampa/ 
 afrp? is the framework still developed further?

Can we get this uploaded to hackage? 

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

Re: [Haskell-cafe] expanded standard lib

[Thomas Hartman]

Batteries included, I could take it or leave it. 

Where I think hackage could really benefit from copying perl strategy is 
automated testing of *all* packages under hackage darcs, not just blessed 
packages.

If this could be integrated into the buildbot of whatever ghc is under 
development that would be great. You would then have status reports on ghc 
itself, ghc plus extralibs (which the haskell core maintainers feel some 
degree of responsibility for), and hackage universe which the core 
people aren't responsible for, but the haskell community benefits from 
feedback. Better yet would be feedback per ghc version, and per platform 
(ubuntu, red hat, windows, on and on, whoever volunteers a test box for 
the buildbot)

For example, I just found out, it seems that HDBC-ODBC is broken on 
windows for ghc-6.8. It would be great to know this in advance before 
trying to use it. Package maintainers could get automated emails too if 
they want.

testing could be as basic as cabal install runs without errors, but could 
also include additional quickcheck tests or other types of test harness.

That would be nice for the community and the core devs, I think. 

thomas.




Justin Bailey [EMAIL PROTECTED] 
Sent by: [EMAIL PROTECTED]
11/19/2007 02:08 PM

To
brad clawsie [EMAIL PROTECTED]
cc
haskell-cafe@haskell.org
Subject
Re: [Haskell-cafe] expanded standard lib






On Nov 19, 2007 10:25 AM, brad clawsie [EMAIL PROTECTED] wrote:
 so far the haskell community has taken the cpan route for most
 practical libs but i wonder if a batteries included approach might
 help get some key libraries to a more complete state. in particular, i
 would like to see support for basic internet protocols, database
 connectivity, and potentially xml parser support rolled into the ghc
 standard libs. there is always a strong debate on where the line is

I agree strongly. I particularly miss a standard HTTP library.

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



---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] More accessible papers

[Peter Verswyvelen]

Most research papers have the same layout: two columns per A4 page. They 
mostly come as PDF or PS.


Although this is standard, it is not really accessible for people with 
people with bad vision, who prefer larger fonts. When you print this, 
the fonts are rather small. For those people, a reflowable PDF would 
make much more sense, so they can choose how big the fonts are on screen 
 paper.


Also, some of the new epaper devices, such as the Sony Reader or IRex, 
don't really support the format of these research papers (they become 
unreadable).


Do any of you have ideas how to convert a two column per page PDF/PS to 
a single larger column per page, and maybe even reflowable PDF?


Thanks,
Peter


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

Re: [Haskell-cafe] More accessible papers

[Neil Mitchell]

Hi Peter,

  Although this is standard, it is not really accessible for people with
 people with bad vision, who prefer larger fonts. When you print this, the
 fonts are rather small. For those people, a reflowable PDF would make much
 more sense, so they can choose how big the fonts are on screen  paper.

It is the standard for ACM workshops and conferences, which includes
ICFP and Haskell Workshop. All these PDF's are produced from a
standard Latex class file. If you wrote to people expressing this, and
did whatever magic is required to make the class file produce both the
current format and a reflowable PDF, you might get somewhere.

  Do any of you have ideas how to convert a two column per page PDF/PS to a
 single larger column per page, and maybe even reflowable PDF?

For all my papers I have the original source .tex files. If you know
how to convert them into reflowable PDF's (or any other format that is
suitable for people with disabilities) I'm happy to hand them over. I
suspect you'll have more luck going from the original .tex rather than
the PDF.

Thanks

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

Re: [Haskell-cafe] Stream fusion for Hackage

[Don Stewart]

simonpj:
 |  Will it eventually replace Data.List in GHC?
 |
 | That is the plan, yep.
 
 But first we need to solve the concatMap problem, no?
 
 So far as I know, fold/build has the property that if fusion doesn't happen, 
 no harm is done. But streams risk making the program *worse* if Good Things 
 do not happen to happen.  This makes me anxious.
 
 Simon

Yep, me too. We'll be using it in ByteString and other strict arrays
first, where the issues are much simpler, then looking at what can be
done with lists. 

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

Re: [Haskell-cafe] expanded standard lib

[Andrew Coppin]

Justin Bailey wrote:

On Nov 19, 2007 10:25 AM, brad clawsie [EMAIL PROTECTED] wrote:
  

so far the haskell community has taken the cpan route for most
practical libs but i wonder if a batteries included approach might
help get some key libraries to a more complete state. in particular, i
would like to see support for basic internet protocols, database
connectivity, and potentially xml parser support rolled into the ghc
standard libs. there is always a strong debate on where the line is



I agree strongly. I particularly miss a standard HTTP library.
  


Personally, I miss clean binary I/O, configurable character encodings, 
and an easy API for working with bitmapped images (loading them, 
saving them, displaying them, etc.)


I could also reel off a whole bunch of other stuff I'd like to have - 
but that doesn't write the code, does it?


Hackage seems like a nice idea in principle. However,

- The packages seem to be of quite variable quality. Some are excellent, 
some are rather poor (or just not maintained any more).

- Almost all packages seem to require a long list of dependencies.
- There seems to be an awful lot of packages that do the same thing but 
with incompatible interfaces (and varying limitations). It seems we're 
not very coordinated here.
- (And, since I'm on Windows, I can't seem to get anything to install 
with Cabal...)


Unfortunately, while it's very easy to point out failings in a given 
system, it's much harder to propose viable ways to fix things... :-(


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

Re: [Haskell-cafe] expanded standard lib

[Neil Mitchell]

Hi

 - The packages seem to be of quite variable quality. Some are excellent,
 some are rather poor (or just not maintained any more).

The problem is that only one person gets to comment on the quality of
a library, the author, who is about the least objective person.

 - Almost all packages seem to require a long list of dependencies.

Cabal-install will turn this from being a negative to being a
positive, if it ever delivers on its promise.

 - There seems to be an awful lot of packages that do the same thing but
 with incompatible interfaces (and varying limitations). It seems we're
 not very coordinated here.

Variety is good. Hopefully at some point people will start to
standardise. For example, there are at least 4 libraries for working
with HTML (TagSoup, HaXml, HXT, ...brain freeze...) - eventually
someone will write a nice summary tutorial on when to use which one.
In Haskell the interface is usually the most important bit, so making
different libraries use the same interface eliminates their
advantages.

 - (And, since I'm on Windows, I can't seem to get anything to install
 with Cabal...)

Windows, the Operating System no one in the Haskell community loves...
Make sure you point all the bugs and even little annoyances that you
encounter, and hopefully things will head in the right direction.

Thanks

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

Re: [Haskell-cafe] expanded standard lib

[Don Stewart]

andrewcoppin:

 Hackage seems like a nice idea in principle. However,

I think in practice too: we had no central lib archive or dependency
system, now we have 400 libraries, and a package installer, 10 months 
later. Until Hackage, there was a strong pressure not to reuse other 
people's libraries.

 - The packages seem to be of quite variable quality. Some are excellent, 
 some are rather poor (or just not maintained any more).
 
 1. Welcome to the internet.

 - Almost all packages seem to require a long list of dependencies.

 2. Solved with cabal:

cabal install foo

 Resolves package deps. Reusing libraries is a good thing.

 - There seems to be an awful lot of packages that do the same thing but 
 with incompatible interfaces (and varying limitations). It seems we're 
 not very coordinated here.

 See #1.

 - (And, since I'm on Windows, I can't seem to get anything to install 
 with Cabal...)

 3. Report a bug. We need more developers on windows, for window to
 improve.

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

Re: [Haskell-cafe] expanded standard lib

[Don Stewart]

ndmitchell:
 Hi
 
  - The packages seem to be of quite variable quality. Some are excellent,
  some are rather poor (or just not maintained any more).
 
 The problem is that only one person gets to comment on the quality of
 a library, the author, who is about the least objective person.
 
  - Almost all packages seem to require a long list of dependencies.
 
 Cabal-install will turn this from being a negative to being a
 positive, if it ever delivers on its promise.

Works for me here:

cabal install xmonad
or
cabal install stream-fusion

It's beta: needs darcs Cabal (1.3.x), and darcs cabal-install. We're
using it at Galois already though, so I would encourage more
testing/users.

-- Don

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

Re: [Haskell-cafe] expanded standard lib

[brad clawsie]

  The problem is that only one person gets to comment on the quality of
  a library, the author, who is about the least objective person.

i would just like to add that i have had a great deal of success with
hackage and find that most libraries support what they say they will
support, but often there is missing functionality that the original
authors have not attended to for some reason. bugs haven't impacted me
as much as missing/incomplete features.

by rolling certain libraries into a base distribution, i was implying
that there would be more eyeballs focusing on making them
feature-complete. furthermore, by closely associating these libraries
into a base distribution, there will be a sense of urgency associated
with closing major bugs.

in any case, batteries included or not, ghc seems to have reached a
point of stability, high performance, and lots of neat fundamental
features that it can be left alone for a short time. i would love to 
see 2008 be the year we direct time and effort to solve filling holes
in the libraries. 

perhaps an online tool for voting for missing libraries or features
would help us assess where to direct efforts.


pgp7l37JKBLZn.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[Thomas Schilling]

On Mon, 2007-11-19 at 12:17 -0800, Don Stewart wrote:
 andrewcoppin:
 
  Hackage seems like a nice idea in principle. However,
 
 I think in practice too: we had no central lib archive or dependency
 system, now we have 400 libraries, and a package installer, 10 months 
 later. Until Hackage, there was a strong pressure not to reuse other 
 people's libraries.
 
  - The packages seem to be of quite variable quality. Some are excellent, 
  some are rather poor (or just not maintained any more).
  
  1. Welcome to the internet.

Sure, but this doesn't mean we couldn't implement some mechanisms to
improve the situation.  Some things I could think of:

  - Have Hackage display a information of whether a package builds on a
particular platform.  Information could be provided by cabal-install (if
the user agrees, of course.)  

  - Allow uploaded packages receive minor patches, i.e., fixing .cabal
file.  This will probably be a recurring problem, since packages will be
updated and base will be split up further.

  - I don't know if a commenting system on hackage would be more useful
than on a package's homepage.  At least it would be useful to have a
package homepage and bug-tracker for each package.  Both could simply be
a code.google.com site.

Alltogether, I'm quite happy with Hackage.  There's room for
improvement, sure, but I think we're on the right track ...



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

Re: [Haskell-cafe] expanded standard lib

[Radosław Grzanka]

2007/11/19, brad clawsie [EMAIL PROTECTED]:
   The problem is that only one person gets to comment on the quality of
   a library, the author, who is about the least objective person.

 by rolling certain libraries into a base distribution, i was implying
 that there would be more eyeballs focusing on making them
 feature-complete. furthermore, by closely associating these libraries
 into a base distribution, there will be a sense of urgency associated
 with closing major bugs.

If you look at the stability tag of ghc libraries you will see that a
lot of them are marked as provisional (Network.URI for example) or
experimental (Control.Monad.Trans).
Although I would love to see some other standard libraries (MaybeT !),
 I think that current base should be solid first.

Just My $0.02 ,
  Radek.

-- 
Codeside: http://codeside.org/
Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary

[Nicolas Frisby]

I've got a first draft with the newtype and just an instance for list.



If you'd prefer fewer questions, please let me know ;)



0) I've cabalised it (lazy-binary), but I don't have anywhere to host it.
Would it be appropriate to host on darcs.haskell.org or HackageDB (yet?).
Suggestions?

1) The fact that serialisation is fully strict for 32760 bytes but not for
32761 makes the direct application of strictCheck intractable. Do you have
any ideas how to circumvent that?

  ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32760 (repeat ())
++ undefined)
= undefined

  ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32761 (repeat ())
++ undefined)
   = lots of ()s and then undefined

2) Also, any suggestions for other datatypes to provide default instances
for? Tree type structures immediately raise the question of which traversal
should be the default. I'm learning towards providing none since the goal of
constant space usage actually depends on the serialisation order matching
how the deserialised tree will be traversed.

3) I don't think it is applicable in anyway whatsoever to strict types like
Int, Data.Set, and Data.Sequence? Counter-arguments?

4) Perhaps the tight correspondence between serialisation and traversal
necessary for constant space usage does indeed mean that the instance for
the lazy list is the only appropriate one to provide. Perhaps the Chunks
data type and a function splitN :: Int - [a] - Chunks [a] would also be
helpful.

Thanks!

16, 2007 12:45 PM, Don Stewart [EMAIL PROTECTED] wrote:

 dons:
  nicolas.frisby:
   I've noticed a few posts on the cafe, including my own experience,
   where the spine-strictness of the Binary instance for lists caused
   some confusion. I'd like to suggest an approach to preventing this
   confusion in the future, or at least making it easier to resolve.
  
   Having decided that it is indeed appropriate for some standard
   instances to be strict by default [1], I think it would be beneficial
   to standardize an approach for expressing that a lazy instance is
   expected. I propose the following newtype be added to Data.Binary. A
   demonstration immediately follows.
  
newtype Lazily a = Lazily { unLazily :: a }
  
-- example instance
instance Binary a = Binary (Lazily [a]) where
-- lazy get and put
  
   Now
  
[1..] = (unLazily . decode . encode . Lazily) [1..]
  
   instead of
  
_|_ = (decode . encode) [1..]
  
   This email is a request for comments on this concept. I think it is a
   minimal way of expressing the intent that the serialisation be lazy
   [2]. Please share any concerns or suggestions. I'll submit a patch
   once the discussion is complete... or if it becomes inactive ;)
 
  I think this is a good compromise: allowing laziness for those who need
  it, in a clean manner. How about we provie
 
  Data.Binary.Lazy
 
  with the Lazy newtype, and lazy instances for types that make sense to
  be so?
 
  For now, this can be developed as a single module depending on
  Data.Binary . What do you think, Nick?

 I'd like to also use strictCheck, as we did for the stream fusion
 library, to state and check strictness properties for the instances,
 since getting this clear and correct seems to be a common FAQ with
 Binary.

 -- Don

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

[Haskell-cafe] Fun with Cabal on Windows! [Stream fusion for Hackage]

[Andrew Coppin]

Don Stewart wrote:
Just a quick announce: the stream fusion library for lists, 
that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year

is now available on Hackage as a standalone package:


http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.1.1

As described in the recent paper:

Stream Fusion: From Lists to Streams to Nothing at All
Duncan Coutts, Roman Leshchinskiy and Don Stewart. ICFP 2007

This is a drop-in replacement for Data.List.
  


Well, I just tried to install this, and as per usual, Cabal has having 
none of it.


C:\fusion\ runhaskell Setup configure
Configuring stream-fusion-0.1.1...
Setup: ld is required but it could not be found.

Well, no, this is Windoze, we don't have ld here...

On the other hand... hold on, doesn't GHC use GCC and ld?

On closer inspection, it seems that there *is* an LD.EXE on my 
harddrive. Cabal is simply failing to find it. Great.


It turns out, the standard GHC installer automatically adds 
C:\ghc\ghc-6.8.1.\bin to the search path. This contains GHC.EXE (and 
other things), but LD.EXE and friends aren't in there. Those are found 
in C:\ghc\ghc-6.8.1\gcc-lib. If you temporarily add *that* to your path...


C:\fusion\ set PATH=%PATH%;C:\ghc\ghc-6.8.1\gcc-lib
C:\fusion\ runhaskell Setup configure
Configuring stream-fusion-0.1.1...

C:\fusion\ runhaskell Setup build
Preprocessing library stream-fusion-0.1.1...
Building stream-fusion-0.1.1...
[1 of 3] Compiling Data.Stream  ( Data/Stream.hs, 
dist\build/Data/Stream.o )



Data/Stream.hs:585:4:
   Warning: Pattern match(es) are non-exhaustive
In the definition of `next':
Patterns not matched: (_ :!: (Just (L _))) :!: S2
[2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, 
dist\build/Data/List/Stream.o )
[3 of 3] Compiling Control.Monad.Stream ( Control/Monad/Stream.hs, 
dist\build/Control/Monad/Stream.o )

C:\ghc\ghc-6.8.1\bin\ar.exe: creating dist\build\libHSstream-fusion-0.1.1.a

C:\fusion\ runhaskell Cabal install
Installing: C:\Program Files\Haskell\stream-fusion-0.1.1\ghc-6.8.1
Registering stream-fusion-0.1.1...
Reading package info from dist\\installed-pkg-config ... done.
Saving old package config file... done.
Writing new package config file... done.

OH...MY...GOD... I just successfully installed my first *ever* Cabal 
package! o_O


[I haven't tried to compile anything using it yet. But ghc-pkg seems to 
report that it's all in there just fine...]


I'm posting this information just in case any other poor soul on Windows 
wants to try to install stuff with Cabal. It seems that if you simply 
install GHC, it installs Cabal too, and adds GHC to your searchpath, and 
yet Cabal won't find ld out of the box. (Surely that can't be correct?) 
However, just by temporarily altering the search path (you don't even 
have to do it permanently) you can fix it. At least, for this particular 
package it fixes it...


PS. Somebody suggested configure --with-ld=PATH. This didn't work at all...

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

[Haskell-cafe] Sillyness in the standard libs.

[Arthur van Leeuwen]

LS,

here is a puzzle for you: try converting a  
System.Posix.Types.EpochTime into either a
System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going  
through

read . show or a similar detour through strings.

The problem comes up when trying to easily nicely display the access,  
modification
or status change times of a full directory of files, using  
System.Posix.Files.Filestatus

to get at the times.

A closely related issue: fromIntegral is in Integral which also  
requires quotRem. However,
	the two are semantically quite disjoint. I can *easily* see the  
semantics of fromIntegral
	on EpochTime, but not the semantics of quotRem on EpochTime. Having  
fromIntegral

would solve the above puzzle... :)

With kind regards, Arthur.

--

  /\/ |   [EMAIL PROTECTED]   | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/\/__ | you can dare to be yourself   | Dance like there's nobody  
watching




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

Re: [Haskell-cafe] expanded standard lib

[Derek Elkins]

On Mon, 2007-11-19 at 21:47 +0100, Radosław Grzanka wrote:
 2007/11/19, brad clawsie [EMAIL PROTECTED]:
The problem is that only one person gets to comment on the quality of
a library, the author, who is about the least objective person.
 
  by rolling certain libraries into a base distribution, i was implying
  that there would be more eyeballs focusing on making them
  feature-complete. furthermore, by closely associating these libraries
  into a base distribution, there will be a sense of urgency associated
  with closing major bugs.
 
 If you look at the stability tag of ghc libraries you will see that a
 lot of them are marked as provisional (Network.URI for example) or
 experimental (Control.Monad.Trans).
 Although I would love to see some other standard libraries (MaybeT !),
  I think that current base should be solid first.

On the other hand, some of these (Control.Monad.Trans) have been
experimental for several years despite being widely used that whole
time...

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

Re: [Haskell-cafe] Properties of monads

[Radosław Grzanka]

Hi Benja,

 Something like the following might feel cleaner, though:

 maybeT :: Maybe a - MaybeT m a
 maybeT = MaybeT . return

 downloadFile :: String - MaybeT IO String
 downloadFile s = maybeT (parseURI s) = liftIO . httpGet

This is even neater. However, I fail to implement this. It does not
compile and although I spent few hours trying to figure out correct
usage of transformers I still fail to solve this.

Here are types of expressions

parseURI :: String - Maybe URI
httpGet :: URI - IO (Maybe String)
maybeT parseURI :: (Monad m) = String - MaybeT m Network.URI.URI

So far so good. However:

liftIO . httpGet :: (Control.Monad.Trans.MonadIO m) = Network.URI.URI
- m (Maybe String)

so it gives different type than is required here because httpGet
already returns IO Maybe String. So I would need transformation from
IO ( Maybe a) - MaybeT IO a . Is there such possibility?

Thank you for your spent time on this.

Cheers,
  Radek.


-- 
Codeside: http://codeside.org/
Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[Jeremy Shaw]

At Mon, 19 Nov 2007 10:25:40 -0800,
brad clawsie wrote:

 so far the haskell community has taken the cpan route for most
 practical libs but i wonder if a batteries included approach might
 help get some key libraries to a more complete state. in particular, i
 would like to see support for basic internet protocols, database
 connectivity, and potentially xml parser support rolled into the ghc
 standard libs. 

The recent trend has to to roll less into the ghc standard libs. There
are a number of reasons for this. People complain it takes to long to
build all of GHC, it makes it harder to port GHC to embedded platforms
where many of the libraries are not needed or are hard to
support. Libraries tend to only get updated as often as GHC (which is
far to infrequent for many libraries).

What if instead of rolling the libraries into GHC, they were rolled
into task-specific bundles. For example, a bundle of internet
libraries (http, xml, etc), a bundle of unix support libraries, etc.

These bundles could be created and managed by third parties. The
bundles might just be references to specific versions of packages
already in hackage ?

This would give you the power that comes from branding certain
packages as recommended, but with (hopfully) less baggage than putting
them in the GHC distribution itself?

j.

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

Re: [Haskell-cafe] expanded standard lib

[Henning Thielemann]

On Mon, 19 Nov 2007, brad clawsie wrote:

 i would categorize myself as a purely practical programmer. i enjoy
 using haskell for various practical tasks and it has served me
 reliably. one issue i have with the library support for practical
 problem domains is the half-finished state of many fundamental
 codebases such as networking and database support.

 in the perl world, support for these domains is provided through cpan,
 and this model is viable due to the (once) massive number of perl
 coders out there. in the java, c# etc world, a batteries included
 approach implies a narrowing of options, but also an immediate
 delivery of functionality.

Although I liked the battery included approach of GHC so far, I install
more and more interesting additional libraries, and GHC is shipped with
libraries I have never used. A library being shipped with GHC has the aura
of being standardized. However also these standard libraries changed, and
I find the interface of some of them not satisfying. Since I expect that
there will never be a consensus on the definition of relevance or even
right interface I think that the Hackage approach of atomic libraries is
the best solution for the future. It allows me to import libraries
according to my needs, whereas today the decision is often directed by
what is standard?. With this solution we wouldn't have had the FiniteMap
break, we could choose more equally between different data structure
collections (say Edison vs. GHC libs), monad libraries, and so on.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[brad clawsie]

 whereas today the decision is often directed by
 what is standard?. With this solution we wouldn't have had the FiniteMap
 break, we could choose more equally between different data structure
 collections (say Edison vs. GHC libs), monad libraries, and so on.

this is a good point...blessing one library can have a chilling
impact on interesting alternatives.

the exception i would make here is when you are coding to a known
interface or protocol, in which case the matching the spec largely
defines the coding exercise.



pgppsDEWIdhu5.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[Andrew Coppin]

brad clawsie wrote:

in any case, batteries included or not, ghc seems to have reached a
point of stability, high performance, and lots of neat fundamental
features that it can be left alone for a short time. i would love to 
see 2008 be the year we direct time and effort to solve filling holes
in the libraries. 
  


I would love to be skilled enough to actually help fix these holes 
rather than just complaining about them... Sadly, I'm not.


I've got an MD5 library I'm working on, and I've got a thin layer over 
Gtk2hs that should make writing programs that render bitmaps easier. 
(E.g., ray tracers, fractal generators... all the kinds of things I like 
writing!) If I ever manage to mangle those into a working state, I'll 
happily hand 'em over. But that's not going to make a huge difference to 
the HackageDB as a whole...



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

Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary

[Don Stewart]

nicolas.frisby:
I've got a first draft with the newtype and just an instance for list.
 
If you'd prefer fewer questions, please let me know ;)
 
0) I've cabalised it (lazy-binary), but I don't have anywhere to host
it. Would it be appropriate to host on [1]darcs.haskell.org or HackageDB
(yet?). Suggestions?

You can host it on code.haskell.org, ask for an account here:

http://community.haskell.org/admin/account_request.html

and a project:

http://community.haskell.org/admin/

 
1) The fact that serialisation is fully strict for 32760 bytes but not for
32761 makes the direct application of strictCheck intractable. Do you have
any ideas how to circumvent that?
 
  ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32760 (repeat
()) ++ undefined)
= undefined
 
  ((unLazy . decode . encode . Lazy) `asTypeOf` id) (take 32761 (repeat
()) ++ undefined)
   = lots of ()s and then undefined

What's happening here?

2) Also, any suggestions for other datatypes to provide default instances
for? Tree type structures immediately raise the question of which
traversal should be the default. I'm learning towards providing none since
the goal of constant space usage actually depends on the serialisation
order matching how the deserialised tree will be traversed.

Lazy Arrays?
  
3) I don't think it is applicable in anyway whatsoever to strict types
like Int, Data.Set, and Data.Sequence? Counter-arguments?

Well, atomic types like Int, I don't think it makes sense, but Sets and
Sequence are lazy, aren't they?

4) Perhaps the tight correspondence between serialisation and traversal
necessary for constant space usage does indeed mean that the instance for
the lazy list is the only appropriate one to provide. Perhaps the Chunks
data type and a function splitN :: Int - [a] - Chunks [a] would also be
helpful.

Yes, it is probably the only lazy instance anyone cares about, anyway.

 

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

Re: [Haskell-cafe] Sillyness in the standard libs.

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote:

here is a puzzle for you: try converting a  
System.Posix.Types.EpochTime into either a
System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going  
through

read . show or a similar detour through strings.


fromEnum and/or toEnum are helpful for this kind of thing, and I am  
occasionally tempted to bind cast = toEnum . fromEnum because I  
need it so much.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Properties of monads

[Radosław Grzanka]

2007/11/19, Ryan Ingram [EMAIL PROTECTED]:
 I am pretty sure that the constructor MaybeT is exactly what you are looking
 for.

 newtype MaybeT m a = MaybeT (m (Maybe a))

 therefore

 MaybeT :: m (Maybe a) - MaybeT m a


I swear I tried it. I swear.. Why didn't it worked than and it works now?? ;)

Thank you very much for a tip. :)

Thanks,
 Radek (who can go sleep now with clear mind).

-- 
Codeside: http://codeside.org/
Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sillyness in the standard libs.

[Henning Thielemann]

On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote:

 On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote:

  here is a puzzle for you: try converting a
  System.Posix.Types.EpochTime into either a
  System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going
  through
  read . show or a similar detour through strings.

 fromEnum and/or toEnum are helpful for this kind of thing, and I am
 occasionally tempted to bind cast = toEnum . fromEnum because I
 need it so much.

Really? I'd like to know which examples these are. So far I suspected that
'cast' indicates not well chosen types.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sillyness in the standard libs.

[Andrew Coppin]

Arthur van Leeuwen wrote:
A closely related issue: fromIntegral is in Integral which also 
requires quotRem. However,
the two are semantically quite disjoint. I can *easily* see the 
semantics of fromIntegral
on EpochTime, but not the semantics of quotRem on EpochTime. 
Having fromIntegral

would solve the above puzzle... :)


As I understand it, it's widely recognised that Haskell's current 
numeric class hierachy is broken (or at best, not very well chosen), but 
nobody came up with a better suggestion yet.


(By all means, somebody correct me if I'm wrong here...!)

Also, that hierachy is in the Haskell Report, so we'll have to wait for 
Haskell' to fix it for good. (Although you can roll you own right now - 
if you can think of a better design...)


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

Re: [Haskell-cafe] expanded standard lib

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 15:13 , Neil Mitchell wrote:

- The packages seem to be of quite variable quality. Some are  
excellent,

some are rather poor (or just not maintained any more).


The problem is that only one person gets to comment on the quality of
a library, the author, who is about the least objective person.


The ability to vote on packages might be interesting here.  If  
there's 4 HTML libraries and one of them gets lots of votes, it's  
probably the one to look at first.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] expanded standard lib

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote:


If you look at the stability tag of ghc libraries you will see that a
lot of them are marked as provisional (Network.URI for example) or
experimental (Control.Monad.Trans).


This may not refer to what most people care about; the experimental  
stability of Control.Monad.Trans is related to its use of fundeps and  
undecidable instances, and the possibility (likelihood?) of its being  
switched to type families (which shouldn't change its user-visible  
interface, as I understand it).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

[Haskell-cafe] Tetris

[Andrew Coppin]

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make 
a nice example program...)


I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably 
there's some deep trickery with Gtk2hs that can draw free-form stuff 
like this.)


2. How do you implement a program that is fundamentally about state 
mutation in a programming language which abhors state mutation?


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

Re: [Haskell-cafe] More accessible papers

[PR Stanley]

Why don't you typeset the whole thing in Latex. That way you'll 
definitely ensure accessibility.

Cheers
Paul
At 19:43 19/11/2007, you wrote:
Most research papers have the same layout: two columns per A4 page. 
They mostly come as PDF or PS.


Although this is standard, it is not really accessible for people 
with people with bad vision, who prefer larger fonts. When you print 
this, the fonts are rather small. For those people, a reflowable PDF 
would make much more sense, so they can choose how big the fonts are 
on screen  paper.


Also, some of the new epaper devices, such as the Sony Reader or 
IRex, don't really support the format of these research papers (they 
become unreadable).


Do any of you have ideas how to convert a two column per page PDF/PS 
to a single larger column per page, and maybe even reflowable PDF?


Thanks,
Peter


___
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] expanded standard lib

[Mads Lindstrøm]

Brandon S. Allbery KF8NH wrote:
 On Nov 19, 2007, at 15:13 , Neil Mitchell wrote:
 
  - The packages seem to be of quite variable quality. Some are  
  excellent,
  some are rather poor (or just not maintained any more).
 
  The problem is that only one person gets to comment on the quality of
  a library, the author, who is about the least objective person.
 
 The ability to vote on packages might be interesting here.  If  
 there's 4 HTML libraries and one of them gets lots of votes, it's  
 probably the one to look at first.
 

It occurred to me that the voting could be implicit. That is, if 10
libraries/programs use library X, then library X gets 10 votes. Kind of
like Google PageRank for libraries.


Greetings,

Mads Lindstrøm


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

Re: [Haskell-cafe] Sillyness in the standard libs.

[Henning Thielemann]

On Mon, 19 Nov 2007, Andrew Coppin wrote:

 Arthur van Leeuwen wrote:
  A closely related issue: fromIntegral is in Integral which also
  requires quotRem. However,
  the two are semantically quite disjoint. I can *easily* see the
  semantics of fromIntegral
  on EpochTime, but not the semantics of quotRem on EpochTime.
  Having fromIntegral
  would solve the above puzzle... :)

 As I understand it, it's widely recognised that Haskell's current
 numeric class hierachy is broken (or at best, not very well chosen), but
 nobody came up with a better suggestion yet.

 (By all means, somebody correct me if I'm wrong here...!)

http://www.haskell.org/haskellwiki/Mathematical_prelude_discussion
http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics#Type_class_hierarchies
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sillyness in the standard libs.

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 16:50 , Henning Thielemann wrote:


On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote:

fromEnum and/or toEnum are helpful for this kind of thing, and I am
occasionally tempted to bind cast = toEnum . fromEnum because I
need it so much.


Really? I'd like to know which examples these are. So far I  
suspected that

'cast' indicates not well chosen types.



If so, it's not my types...  The specific instance is the one you  
mentioned about times; fromEnum lets me turn a Foreign.C.Types.CTime  
(== System.Posix.Types.EpochTime) to an Int (which is commonly just  
type punning in GHC, since it's the same internal value  
representation in most (all?) cases), from which I can get to another  
Foreign.C.Types type with toEnum or to Integer with fromIntegral.   
(NB:  This involves an assumption about CTime; POSIX allows (or used  
to allow) it to be a floating type in order to allow some non- 
UNIXlikes to represent POSIX times.  But given that CTime is Enum,  
Foreign.C.Types already violates this; so why isn't it also Integral?)


So yes, this is a sign of typing issues in the implementation and  
(toEnum . fromEnum) is a hack around them.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Sillyness in the standard libs.

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 17:10 , Brandon S. Allbery KF8NH wrote:

CTime; POSIX allows (or used to allow) it to be a floating type in  
order to allow some non-UNIXlikes to represent POSIX times.  But  
given that CTime is Enum, Foreign.C.Types already violates this; so  
why isn't it


Hrm, not thinking about that right, Enum works for Floating.  Never  
mind...


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Tetris

[Don Stewart]

andrewcoppin:
 If you were going to implement Tetris in Haskell, how would you do it?
 
 (For that matter, has anybody already *done* it? It would probably make 
 a nice example program...)

http://haskell.org/haskellwiki/Applications_and_libraries/Games

ASCII tetris
http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/Hetris/

OpenGL or Gtk2Hs seem the best options.

 2. How do you implement a program that is fundamentally about state 
 mutation in a programming language which abhors state mutation?

Its not clear games are fundamentally about mutation, anymore than, say,
window managers are. State we do with monads.

Check the thesis on Frag for a pure approach, or just use StateT IO.

-- Don

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

Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary

[Duncan Coutts]

On Mon, 2007-11-19 at 13:39 -0800, Don Stewart wrote:
 nicolas.frisby:
 I've got a first draft with the newtype and just an instance for list.
  
 If you'd prefer fewer questions, please let me know ;)
  
 0) I've cabalised it (lazy-binary), but I don't have anywhere to host
 it. Would it be appropriate to host on [1]darcs.haskell.org or HackageDB
 (yet?). Suggestions?
 
 You can host it on code.haskell.org, ask for an account here:

I think we should consider if a lazier serialisation of lists shouldn't
be the default first before thinking about forking the whole library.

It depends on how much laziness you want. We could certainly make it so
that this is true:

(decode . encode) [1..] = [1..]

rather than giving _|_. However the approach of Data.Binary is lazy
serialisation but in chunks, big chunks. So while the above may be true,
this would not be:

(head . decode . encode) [1, _|_] = 1

because we generate 32k chunks of data when serialising. But do you
really need it to be this lazy? Would it enough for it to be lazy in
chunks.

There is a good argument I think that the current fully strict
serialisation is bad just from a performance perspective, and that
instead we should serialise lists semi-lazily, using a chunked
representation. For example Neil's serialisation library uses length
prefixed chunks with a maximum chunk size of 255. The end of a list is
denoted by a 0 length final chunk. This has the advantage that we only
have to force a limited number of elements (to find the length) before
serialising.

If you want it really lazy then it would have to flush after each
element to create a new lazy bytestring chunk. Note that flushing this
often looses many of the performance advantages of the Data.Binary
stuff.

  
 1) The fact that serialisation is fully strict for 32760 bytes but not 
  for
 32761 makes the direct application of strictCheck intractable. Do you 
  have
 any ideas how to circumvent that?

Test using a much smaller chunk size. I'd test sizes from 1 to something
like one more than the machine word size.

 2) Also, any suggestions for other datatypes to provide default instances
 for? Tree type structures immediately raise the question of which
 traversal should be the default. I'm learning towards providing none 
  since
 the goal of constant space usage actually depends on the serialisation
 order matching how the deserialised tree will be traversed.
 
 Lazy Arrays?
   
 3) I don't think it is applicable in anyway whatsoever to strict types
 like Int, Data.Set, and Data.Sequence? Counter-arguments?
 
 Well, atomic types like Int, I don't think it makes sense, but Sets and
 Sequence are lazy, aren't they?

Sequences are like spine strict lists. Sets are strict in as much as the
element type's (==) function is strict.

 4) Perhaps the tight correspondence between serialisation and traversal
 necessary for constant space usage does indeed mean that the instance for
 the lazy list is the only appropriate one to provide. Perhaps the Chunks
 data type and a function splitN :: Int - [a] - Chunks [a] would also be
 helpful.
 
 Yes, it is probably the only lazy instance anyone cares about, anyway.

Yes. So I think we should be clear about what we want and see if we
can't just fix the default.

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

Re: [Haskell-cafe] expanded standard lib

[Henning Thielemann]

On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote:

 On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote:

  If you look at the stability tag of ghc libraries you will see that a
  lot of them are marked as provisional (Network.URI for example) or
  experimental (Control.Monad.Trans).

 This may not refer to what most people care about; the experimental
 stability of Control.Monad.Trans is related to its use of fundeps and
 undecidable instances, and the possibility (likelihood?) of its being
 switched to type families (which shouldn't change its user-visible
 interface, as I understand it).

I like to see MTL split into a Haskell98 part and an advanced part. I
mostly use functionality which would nicely fit into a Haskell98 interface
and find it annoying that by importing MTL my code becomes less portable.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[Andrew Coppin]

Neil Mitchell wrote:

Hi

  

- The packages seem to be of quite variable quality. Some are excellent,
some are rather poor (or just not maintained any more).



The problem is that only one person gets to comment on the quality of
a library, the author, who is about the least objective person.
  


Yes, perhaps so...


- Almost all packages seem to require a long list of dependencies.



Cabal-install will turn this from being a negative to being a
positive, if it ever delivers on its promise.
  


Here's to hoping. ;-)


- There seems to be an awful lot of packages that do the same thing but
with incompatible interfaces (and varying limitations). It seems we're
not very coordinated here.



Variety is good. Hopefully at some point people will start to
standardise. For example, there are at least 4 libraries for working
with HTML (TagSoup, HaXml, HXT, ...brain freeze...) - eventually
someone will write a nice summary tutorial on when to use which one.
In Haskell the interface is usually the most important bit, so making
different libraries use the same interface eliminates their
advantages.
  


Variety is good. Standardisation is also good (for different reasons). 
Having half a dozen database access libraries (each of which only talks 
to certain databases) is just confusing. I suppose the key is to find a 
balance between having lots of choice and knowing which thing to choose. 
(Also, when somebody writes a library, it's dependencies are going to be 
the author's choice. Not much fun trying to use two libraries that both 
depend on different, incompatible binary packages...)



Windows, the Operating System no one in the Haskell community loves...
Make sure you point all the bugs and even little annoyances that you
encounter, and hopefully things will head in the right direction.
  


Well, I've already filed 4 bugs against GHC. One was already fixed by 
GHC 6.8.1 (yays!), one is trivial and will be fixed in 6.8.2, and the 
other two it seems nobody is keen to work on. (In fairness, one of them 
is fairly nontrivial.) I get the impression that I'd probably be 
regarded as a pest if I just spent all day filing endless bug reports... 
It would be quite nice if rather than just filing reports, I could do 
something useful to help *fix* these bugs. But, unfortunately, that is 
beyond my skill.


(On the other hand, even things that I should theoretically be able to 
do I haven't managed to. You might remember a while back I offered to 
try to spruce up the Haddoc documentation for Parsec. It has a great 
user manual, but the Haddoc reference is Spartan. Well anyway, in the 
end I couldn't figure out how to do that, so nothing got done...)


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

Re: [Haskell-cafe] expanded standard lib

[Brandon S. Allbery KF8NH]

On Nov 19, 2007, at 17:01 , Mads Lindstrøm wrote:


Brandon S. Allbery KF8NH wrote:

The ability to vote on packages might be interesting here.  If
there's 4 HTML libraries and one of them gets lots of votes, it's
probably the one to look at first.


It occurred to me that the voting could be implicit. That is, if 10
libraries/programs use library X, then library X gets 10 votes.  
Kind of

like Google PageRank for libraries.


Only up to a point; not all programs written using such libraries are  
necessarily going to end up on hackage.  (Consider the code written  
by the financials folks that have been mentioned here various times;  
and I have a couple programs which would be quite useless outside of  
CMU ECE because they operate on parts of our site-specific  
infrastructure.)  It would certainly be a start, though.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] expanded standard lib

[Andrew Coppin]

Don Stewart wrote:

andrewcoppin:
  

Hackage seems like a nice idea in principle. However,



I think in practice too: we had no central lib archive or dependency
system, now we have 400 libraries, and a package installer, 10 months 
later.
  


Hackage is that new??

- The packages seem to be of quite variable quality. Some are excellent, 
some are rather poor (or just not maintained any more).

 
 1. Welcome to the internet.
  


Well, yeah, I guess. ;-)

As others have suggested, maybe a rating system or space for comments or 
something... [all very easy for the person who doesn't have to implement 
it.]


- (And, since I'm on Windows, I can't seem to get anything to install 
with Cabal...)



 3. Report a bug. We need more developers on windows, for window to
 improve.
  


Where is the correct place for Cabal bugs?

(And presumably it doesn't work wouldn't be a very helpful bug report. 
How about something more like my email just now regarding how to get the 
new Stream Fusion library built on Windows? Is that useful data to have?)


Who's actually responsible for Cabal? Is it the GHC guys, or someone 
else entirely?


(I still don't have a really clear idea of what Cabal does. When I give 
people Haskell code, they just compile it and use it. I'm not sure 
exactly what functionallity Cabal is supposed to add to the equation.)


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

Re: [Haskell-cafe] expanded standard lib

[Henning Thielemann]

On Mon, 19 Nov 2007, Mads [ISO-8859-1] Lindstrøm wrote:

 It occurred to me that the voting could be implicit. That is, if 10
 libraries/programs use library X, then library X gets 10 votes. Kind of
 like Google PageRank for libraries.

It would be good if users could comment verbally. They could comment like
efficient implementation, but weakly typed interface, very general but
not very well documented. One cannot express everything with a scalar
popularity value.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tetris

[Sebastian Sylvan]

On Nov 19, 2007 9:25 PM, Andrew Coppin [EMAIL PROTECTED] wrote:
 If you were going to implement Tetris in Haskell, how would you do it?

 (For that matter, has anybody already *done* it? It would probably make
 a nice example program...)

 I'm particularly interested to know

 1. How exactly would you do the graphical components? (Presumably
 there's some deep trickery with Gtk2hs that can draw free-form stuff
 like this.)

 2. How do you implement a program that is fundamentally about state
 mutation in a programming language which abhors state mutation?


It's not really fundamentally about state mutation. The only state
you're mutating is when you're actually taking the game board and
rendering it on to the screen, and when you're reading input from the
user to direct the next step in the game. But all of the actual logic
- computing collision detection against the existing grid, computing
the score, rotating blocks, etc. - is completely functional.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] expanded standard lib

[Thomas Hartman]

the php documentation has user contributed notes where people can leave
sniplets of useful code as comments, eg

http://www.php.net/manual/en/introduction.php

I think this is a very nice feature.




Henning Thielemann [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/19/2007 05:21 PM

To
Haskell Cafe haskell-cafe@haskell.org
cc

Subject
Re: [Haskell-cafe] expanded standard lib







On Mon, 19 Nov 2007, Mads [ISO-8859-1] Lindstrøm wrote:

 It occurred to me that the voting could be implicit. That is, if 10
 libraries/programs use library X, then library X gets 10 votes. Kind of
 like Google PageRank for libraries.

It would be good if users could comment verbally. They could comment like
efficient implementation, but weakly typed interface, very general but
not very well documented. One cannot express everything with a scalar
popularity value.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



---

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Tetris

[CW Anderson]

To help learn some Haskell, I implemented a pole-balancing video game in
Haskell, starting with the code for the S.A.R.A.H. road simulator by
Maurício C. Antunes (thanks Maurício) that is included in the Gtk2Hs library
demos.  It demonstrates how to do the graphics, interact with the user via
mouse buttons, and the use of IORef to maintain the state.  You can download
my implementation at

http://www.cs.colostate.edu/~anderson/code/haskell/Pole.hs

Chuck Anderson


Andrew Coppin wrote:
 
 If you were going to implement Tetris in Haskell, how would you do it?
 
 (For that matter, has anybody already *done* it? It would probably make 
 a nice example program...)
 
 I'm particularly interested to know
 
 1. How exactly would you do the graphical components? (Presumably 
 there's some deep trickery with Gtk2hs that can draw free-form stuff 
 like this.)
 
 2. How do you implement a program that is fundamentally about state 
 mutation in a programming language which abhors state mutation?
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 

-- 
View this message in context: 
http://www.nabble.com/Tetris-tf4839853.html#a13846985
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] expanded standard lib

[Bjorn Bringert]

On Nov 19, 2007, at 23:13 , Henning Thielemann wrote:



On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote:


On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote:

If you look at the stability tag of ghc libraries you will see  
that a

lot of them are marked as provisional (Network.URI for example) or
experimental (Control.Monad.Trans).


This may not refer to what most people care about; the experimental
stability of Control.Monad.Trans is related to its use of fundeps and
undecidable instances, and the possibility (likelihood?) of its being
switched to type families (which shouldn't change its user-visible
interface, as I understand it).


I like to see MTL split into a Haskell98 part and an advanced part. I
mostly use functionality which would nicely fit into a Haskell98  
interface
and find it annoying that by importing MTL my code becomes less  
portable.


Yes! Please!

/Björn



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

Re: [Haskell-cafe] expanded standard lib

[brad clawsie]

On Mon, Nov 19, 2007 at 05:27:30PM -0500, Thomas Hartman wrote:
 the php documentation has user contributed notes where people can leave
 sniplets of useful code as comments, eg
 
 http://www.php.net/manual/en/introduction.php
 
 I think this is a very nice feature.

yup, for php it gives users a chance to suggest corrections for
the numerous errors and omissions in the standard docs...:)


pgpms2TfQZ0su.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] user error when using Text.Regex.PCRE

[Olivier Boudry]

Hi all,

I'm getting a strange user error when working with Data.ByteString.Char8 and
Text.Regex.PCRE.

Error I get is:
CustomerMaster: user error (Text.Regex.PCRE.ByteString died: (ReturnCode
0,Ptr
parameter was nullPtr in Text.Regex.PCRE.Wrap.wrapMatch cstr))

The part of the code causing problems is at the end of this e-mail. The
complete code is attached.

I'm working at cleansing customer addresses for a ERP system data migration.
The failing function is supposed to split some bytestrings using a list of
regular expressions (split on words like suite, building, attention, etc...)
stored in the tags binding. I use a foldl' to try each regular expression
on each address (addr is a list of address part, can be seen as a list of
bytestring values).

The funny and weird thing is that when I have only one regular expression in
tags, it works. When I have more than one regular expression in tags it
fails (user error) the first time one of the regular expression matches. A
match replaces the current address part with 3 new parts, before, match,
after. The next regular expression in the tags list will test the new before
and after parts. I presume it's the testing of those newly created parts
that causes the problem.

Any idea about what could go wrong here?

Thanks,

Olivier.

=== code ===

-- | Split unparsed address parts on keywords (suite, building, doors,
etc...)

splitOnTags :: AddressState
splitOnTags = do
  addr - get
  put $ foldl' f addr tags
  where
f a t   = concatMap (split t) a
split (T {partType = p, regex = r}) a@(AP X v)
  | BS.null y= [a]
  | otherwise = [AP X x, AE p, AP X z] -- new address parts
  where
(x, y, z) = match r v
split _ a = [a]

-- | Regex and part type representing tags used for splitting addresses

tags :: [Tag]
tags = [T AT
  (makeRegexOpts compCaseless execBlank
\\b(?:ATTN|ATTENTION|C/O)\\b[[:punct:]]?)
  (BS.pack ATTN: )
   ,T PB
  (makeRegexOpts compCaseless execBlank
\\b(?:(?:P\\.?\\s?O\\.?\\s*)BOX|C\\.P\\.|POSTFACH)\
\[[:punct:]]?\\s+(?:NO.\\s+)?)
  (BS.pack PO BOX: )
   ,T BLDG
  (makeRegexOpts compCaseless execBlank
\\b(?:BLDG|BUILDING|HANGAR)[[:punct:]]?)
  (BS.pack BLDG: )
   ,T DOCK
  (makeRegexOpts compCaseless execBlank
\\bDOCK[[:punct:]]?)
  (BS.pack DOCK: )
   ,T STE
  (makeRegexOpts compCaseless execBlank
\\b(?:SUITE|STE|APT|ROOM)[[:punct:]]?\
\\\s+(?:NO[[:punct:]]?)?)
  (BS.pack STE: )
   ,T UNIT
  (makeRegexOpts compCaseless execBlank
\\bUNIT[[:punct:]]?)
  (BS.pack UNIT: )
   ,T FLOOR
  (makeRegexOpts compCaseless execBlank
FLOOR)
  (BS.pack FLOOR: )
   ,T DOORS
  (makeRegexOpts compCaseless execBlank
\\bDOORS?[[:punct:]]?)
  (BS.pack DOORS: )]
module Main where

import Control.Monad.State
import qualified Data.ByteString.Char8 as BS
import Data.Char (isSpace)
import Data.List
import System.Environment
import System.IO
import Text.Regex.PCRE


-- Data declarations


-- | An address

type Address = [AddressPart]

-- | An address part (Suite, Dock, City, etc...) or a line separator

data AddressPart = AP AddressPartType BS.ByteString
 | AE AddressPartType -- tag found but not linked to text
 | S  AddressPartType -- line separator
 deriving (Show, Eq)

-- | Tags for address parts

data AddressPartType = I  -- Id
 | N  -- Name
 | PF -- Partner function
 | AT -- Attention
 | N2 -- Name 2
 | PB -- P.O. Box
 | BLDG   -- Building
 | DOCK   -- Dock
 | STE-- Suite
 | UNIT   -- Unit
 | FLOOR  -- Floor
 | DOORS  -- Doors
 | ST -- Street
 | CI -- City
 | CO -- Country
 | R  -- Region
 | Z  -- Zip code
 | X  -- Unparsed
 | E  -- Error message
 | L1 -- Start of Line 1
 | L2 -- Start of Line 2
 | L3 -- Start of Line 3
 | L4 -- Start of Line 4 (zip code)
 deriving (Show, Eq)

-- | The address state the program will run in

type AddressState = State Address ()

data Tag = T {partType :: AddressPartType,
  regex:: Regex,
  partName :: BS.ByteString}

[Haskell-cafe] Re: Sillyness in the standard libs.

[Aaron Denney]

On 2007-11-19, Andrew Coppin [EMAIL PROTECTED] wrote:
 Arthur van Leeuwen wrote:
 A closely related issue: fromIntegral is in Integral which also 
 requires quotRem. However,
 the two are semantically quite disjoint. I can *easily* see the 
 semantics of fromIntegral
 on EpochTime, but not the semantics of quotRem on EpochTime. 
 Having fromIntegral
 would solve the above puzzle... :)

 As I understand it, it's widely recognised that Haskell's current 
 numeric class hierachy is broken (or at best, not very well chosen), but 
 nobody came up with a better suggestion yet.

Oh, there are /lots/ of suggestions.  Perhaps too many.  But this is
one area that could really be improved by the use of ATs or MPTCs with
fundeps, and that's stalled some of the concrete proposals, as what
exactly is happening for Haskell' isn't too clear.

-- 
Aaron Denney
--

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

Re: [Haskell-cafe] Fun with Cabal on Windows! [Stream fusion for Hackage]

[Thomas Schilling]

On Mon, 2007-11-19 at 20:29 +, Andrew Coppin wrote:
 Don Stewart wrote:
  Just a quick announce: the stream fusion library for lists, 
  that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year
  is now available on Hackage as a standalone package:
 
  
  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.1.1
 
  As described in the recent paper:
 
  Stream Fusion: From Lists to Streams to Nothing at All
  Duncan Coutts, Roman Leshchinskiy and Don Stewart. ICFP 2007
 
  This is a drop-in replacement for Data.List.

 
 Well, I just tried to install this, and as per usual, Cabal has having 
 none of it.
 
 C:\fusion\ runhaskell Setup configure
 Configuring stream-fusion-0.1.1...
 Setup: ld is required but it could not be found.
 
 Well, no, this is Windoze, we don't have ld here...
 
 On the other hand... hold on, doesn't GHC use GCC and ld?
 
 On closer inspection, it seems that there *is* an LD.EXE on my 
 harddrive. Cabal is simply failing to find it. Great.
 
 It turns out, the standard GHC installer automatically adds 
 C:\ghc\ghc-6.8.1.\bin to the search path. This contains GHC.EXE (and 
 other things), but LD.EXE and friends aren't in there. Those are found 
 in C:\ghc\ghc-6.8.1\gcc-lib. If you temporarily add *that* to your path...
 
 C:\fusion\ set PATH=%PATH%;C:\ghc\ghc-6.8.1\gcc-lib
 C:\fusion\ runhaskell Setup configure
 Configuring stream-fusion-0.1.1...

Hm, this actually is supposed to work.  Could you please re-run this
procedure with the original path and with maximum verbosity?  I.e.:

   runhaskell Setup configure -v3

In any case though, if you have problems with Cabal or cabal-install,
send a bug report -- Windows might not be number one priority (since
most of the developers don't use it (often)) don't expect us to fix bugs
that we don't know about.  (Naturally.)

Thanks,

/ Thomas

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

Re: [Haskell-cafe] expanded standard lib

[Thomas Schilling]

On Mon, 2007-11-19 at 21:22 +, Andrew Coppin wrote:

 Where is the correct place for Cabal bugs?

This and other questions are explained at .. *drumroll* .. the Cabal
Homepage!! -- http://www.haskell.org/cabal/

:)

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

Re: [Haskell-cafe] HTTP actions proxy server

[Stefan Kersten]

On 16.11.2007, at 13:55, Jim Burton wrote:
The docs say Should be of the form http://host:port, host,  
host:port, or
http://host; but none of the variations work. Any ideas where I  
might find

an example of code that does this?


this works for me (modulo error handling):

simpleHTTP' :: Request - IO (Result Response)
simpleHTTP' req = do
proxy - catch
(getEnv HTTP_PROXY = return . (flip Proxy Nothing))
(\_ - return NoProxy)
(_, resp) - browse (setProxy proxy  request req)
return (Right resp)

i.e. run the request in the browser monad.

sk

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

[Haskell-cafe] Translations and Haskell

[Felipe Lessa]

Hello,

I'd like to start a project using Gtk2Hs and one thing is concerning
me: what's the current approach on writing portable and translatable
GUI programs in Haskell?

I couldn't find anything on some quick searchs on haskell.org, hackage
and google. If there aren't any libraries available, are there any
suggestions on how to create one? Would it be too much job for someone
without experience with gettext to write bindings and create and
extractor like xgettext (or modify it)? Maybe TH can help? I don't
know, I'm just throwing out some random ideas =).

Cheers,

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

Re: [Haskell-cafe] binary operator modifiers

[Tim Newsham]

liftM2 (/) sum length.  Anyway, the closest you can get in Haskell is
something like this, using the infix expressions of Ken Shan and Dylan
Thurstonhttp://www.haskell.org/pipermail/haskell-cafe/2002-July/003215.html


Hmm.. that might be decent if you added rules to pretty-print them in 
lhs2tex.  The src code would be slightly messy but the formatted code would 
be very clean.  And it opens the doors for other binop decorators. 
Interesting idea.


I finally get my lhs2tex set up and put together a better example
of what I was talking about:

  http://www.thenewsh.com/%7Enewsham/Hats.pdf

Though I don't know if you can coax lhs2tex into accepting something like

  %format -:liftM2 (+):-   =  \widehat{+}

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary

[Nicolas Frisby]

In light of this discussion, I think the fully spine-strict list instance
does more good than bad argument is starting to sound like a premature
optimization. Consequently, using a newtype to treat the necessarily lazy
instances as special cases is an inappropriate bandaid.

My current opinion: If Data.Binary makes both a fully strict list instance
(not []) and a fully lazy list instance (this would be the default for [])
available, then that will also make available all of the other intermediate
strictness. I'll elaborate that a bit. If the user defines a function
appSpecificSplit :: MyDataType - [StrictList a], then the user can control
the compactness and laziness of the serialisation by tuning that splitting
function. Niel's 255 schema fits as one particular case, the split255 :: [a]
- [StrictList a] function. I would hesitate to hard code a number of
elements, since it certainly depends on the application and only exposing it
as a parameter maximizes the reusability of the code.

Related action: Thus I think that instead of a standard newtype to denote
laziness expectations, there ought to be a standard strict list data type
and Binary instance AND some documentation popularizing this as a possible
optimization whenever the generated bytestrings from []s are too big. Is
Data.Sequence suitable for use as StrictList? Or perhaps something from the
strict library? I'm not fully savvy to the head-strictness/unpacking
differences and trade-offs.

Reaching for the sky idea: Does the Put monad offer enough information
for an instance to be able to recognize when it has filled a lazy
bytestring's first chunk? It could cater its strictness (i.e. vary how much
of the spine is forced before any output is generated) in order to best line
up with the chunks of lazy bytestring it is producing. This might be trying
to fit too much into the interface. And it might even make Put an actual
monad ;)


On Nov 19, 2007 4:16 PM, Duncan Coutts [EMAIL PROTECTED] wrote:

 On Mon, 2007-11-19 at 13:39 -0800, Don Stewart wrote:
  nicolas.frisby:
  I've got a first draft with the newtype and just an instance for
 list.
  
  If you'd prefer fewer questions, please let me know ;)
  
  0) I've cabalised it (lazy-binary), but I don't have anywhere to
 host
  it. Would it be appropriate to host on [1]darcs.haskell.org or
 HackageDB
  (yet?). Suggestions?
 
  You can host it on code.haskell.org, ask for an account here:

 I think we should consider if a lazier serialisation of lists shouldn't
 be the default first before thinking about forking the whole library.

 It depends on how much laziness you want. We could certainly make it so
 that this is true:

 (decode . encode) [1..] = [1..]

 rather than giving _|_. However the approach of Data.Binary is lazy
 serialisation but in chunks, big chunks. So while the above may be true,
 this would not be:

 (head . decode . encode) [1, _|_] = 1

 because we generate 32k chunks of data when serialising. But do you
 really need it to be this lazy? Would it enough for it to be lazy in
 chunks.

 There is a good argument I think that the current fully strict
 serialisation is bad just from a performance perspective, and that
 instead we should serialise lists semi-lazily, using a chunked
 representation. For example Neil's serialisation library uses length
 prefixed chunks with a maximum chunk size of 255. The end of a list is
 denoted by a 0 length final chunk. This has the advantage that we only
 have to force a limited number of elements (to find the length) before
 serialising.

 If you want it really lazy then it would have to flush after each
 element to create a new lazy bytestring chunk. Note that flushing this
 often looses many of the performance advantages of the Data.Binary
 stuff.

  
  1) The fact that serialisation is fully strict for 32760 bytes but
 not for
  32761 makes the direct application of strictCheck intractable. Do
 you have
  any ideas how to circumvent that?

 Test using a much smaller chunk size. I'd test sizes from 1 to something
 like one more than the machine word size.

  2) Also, any suggestions for other datatypes to provide default
 instances
  for? Tree type structures immediately raise the question of which
  traversal should be the default. I'm learning towards providing
 none since
  the goal of constant space usage actually depends on the
 serialisation
  order matching how the deserialised tree will be traversed.
 
  Lazy Arrays?
 
  3) I don't think it is applicable in anyway whatsoever to strict
 types
  like Int, Data.Set, and Data.Sequence? Counter-arguments?
 
  Well, atomic types like Int, I don't think it makes sense, but Sets and
  Sequence are lazy, aren't they?

 Sequences are like spine strict lists. Sets are strict in as much as the
 element type's (==) function is strict.

  4) Perhaps the tight correspondence between serialisation and
 traversal
  necessary for constant 

Re: [Haskell-cafe] Translations and Haskell

[Jeremy Shaw]

At Mon, 19 Nov 2007 23:18:58 -0200,
Felipe Lessa wrote:
 

 If there aren't any libraries available, are there any
 suggestions on how to create one? 

I am not sure if a better way exists already, but here is how I would
do it if nothing better exists.

Creating a binding to the gettext library calls should be pretty
straight forward; I have done it in ocaml before, and I think there
are only two or three functions you need.

 Would it be too much job for someone without experience with gettext
 to write bindings and create and extractor like xgettext (or modify
 it)?

Instead of TH, it might be easier to use:

http://www.haskell.org/ghc/docs/latest/html/libraries/haskell-src-1.0.1.1/Language-Haskell-Parser.html

first you would define a function like:

i18n :: String - String
i18n = id

which you will use to markup strings that should be translated. It
does not actually do anything, and will be optimized out by the
compiler. Also, it means that your code will be portable to hugs, yhc,
etc, which do not have TH.

You would then use Language.Haskell.Parser to parse your source files
and look for the i18n function. That function should only ever be
applied to string literals. If you find that it is applied to
something else, that should trigger an error. Otherwise you just find
all the strings after i18n, and write them out to a .pot file.

You might also allow:

i18n (multine ++
  string)

provided that all the arguments of ++ are string literals. This is
because, AFAIK, there is no other way to split a long string across
multiple source lines in a portable way.

j.

ps. I have never used Language.Haskell.Parser, so I might be imagining
it does something that it does not.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Translations and Haskell

[Stefan O'Rear]

On Mon, Nov 19, 2007 at 05:39:44PM -0800, Jeremy Shaw wrote:
 You might also allow:
 
 i18n (multine ++
   string)
 
 provided that all the arguments of ++ are string literals. This is
 because, AFAIK, there is no other way to split a long string across
 multiple source lines in a portable way.

multiline\
\string

http://haskell.org/onlinereport/lexemes.html#sect2.6

Stefan


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

Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary

[Nicolas Frisby]

On Nov 19, 2007 4:16 PM, Duncan Coutts [EMAIL PROTECTED] wrote:

 On Mon, 2007-11-19 at 13:39 -0800, Don Stewart wrote:
  nicolas.frisby:

*snip*

  
  1) The fact that serialisation is fully strict for 32760 bytes but not 
   for
  32761 makes the direct application of strictCheck intractable. Do you 
   have
  any ideas how to circumvent that?

 Test using a much smaller chunk size. I'd test sizes from 1 to something
 like one more than the machine word size.


Let me clarify circumvent that. strictCheck uses a bounded search
starting at 1 and proceeds to some limit. The Binary instance used in
the example was the fully lazy one for lists: a get/putWord8 for each
constructor. Even so, it was effectively spine-strict up to 32k bytes
(which was 32k elements b/c of the use of unit) because (I think that)
the first chunk of the lazy bytestring wasn't being generated by
encode until it was full. If you asked strictCheck to go from 1 to
32k, I don't think it would finish. So by circumvent, I mean: How can
we apply the essential ideas of strictCheck when our chunks are so
big? Obviously, the iterative search cannot just proceed by one
element at a time; but then we lose the obvious meaning of add one
more _|_. I don't see an obvious candidate for how to alter the
_|_-ridden test vector generation. Moreover, it's proposed output is
wrong when considered from the Big Chunks perspective--we don't
necessarily want Chitil's least strictness.

(more new text below)


  2) Also, any suggestions for other datatypes to provide default 
   instances
  for? Tree type structures immediately raise the question of which
  traversal should be the default. I'm learning towards providing none 
   since
  the goal of constant space usage actually depends on the serialisation
  order matching how the deserialised tree will be traversed.
 
  Lazy Arrays?
 
  3) I don't think it is applicable in anyway whatsoever to strict types
  like Int, Data.Set, and Data.Sequence? Counter-arguments?
 
  Well, atomic types like Int, I don't think it makes sense, but Sets and
  Sequence are lazy, aren't they?

 Sequences are like spine strict lists. Sets are strict in as much as the
 element type's (==) function is strict.



Let me refine how I posed that question. A predicate: if you enter
Package.fromList [1..] at the ghci prompt and you get no
intermediate results, then that was a strict type. I'm assuming that
if the Show instance doesn't produce intermediate results, then the
serialisation technique can't handle intermediate results (i.e.
chunking) either--at least not in a general enough way to include it
in a library.

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

[Haskell-cafe] How to abort a computation within Continuation Monad?

[Dimitry Golubovsky]

Hi,

I have been using plain non-monadic CPS for a while in my web-browser
related stuff. Now I am tempted to switch from plain CPS to
syntactically sweetened monadic style based on Continuation Monad, but
I feel stuck with one important issue that I need an advice on.

In plain CPS, I may write:

type CPS x y = (y - x) - x

a :: x

a = f1 x $ \r -
  case r of
foo1 - bar  -- of type x
foo2 - f2 r $ \p - ...  -- something finally evaluating to a
value of type x

So, if at any time I return a value of a final type (x) instead of
doing something with given continuation,
I abort/suspend the whole computation. This can happen at any function
call depth. I can also save the continuation reference in some
persistent place, to resume the remainder of computation later.

Now, I am trying to do the same with a Continuation Monad. But does
anything similar exist in this monad? callCC is not exactly what I
need because it only helps abort the inner computation, and what is
returned, is a monadic value, not a final value. Besides, callCC
defines a name of the function corresponding to the current
continuation, and in order to use it, this name should be visible.

If I have

callCC $ \exit - do
  foo
...

I cannot jump to `exit' from within foo unless `exit' is given to foo
as an argument.

Any suggestions?

Thanks.

-- 
Dimitry Golubovsky

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

Re: [Haskell-cafe] How to abort a computation within Continuation Monad?

[Derek Elkins]

On Tue, 2007-11-20 at 00:18 -0500, Dimitry Golubovsky wrote:
 Hi,
 
 I have been using plain non-monadic CPS for a while in my web-browser
 related stuff. Now I am tempted to switch from plain CPS to
 syntactically sweetened monadic style based on Continuation Monad, but
 I feel stuck with one important issue that I need an advice on.
 
 In plain CPS, I may write:
 
 type CPS x y = (y - x) - x
 
 a :: x
 
 a = f1 x $ \r -
   case r of
 foo1 - bar  -- of type x
 foo2 - f2 r $ \p - ...  -- something finally evaluating to a
 value of type x
 
 So, if at any time I return a value of a final type (x) instead of
 doing something with given continuation,
 I abort/suspend the whole computation. This can happen at any function
 call depth. I can also save the continuation reference in some
 persistent place, to resume the remainder of computation later.
 
 Now, I am trying to do the same with a Continuation Monad. But does
 anything similar exist in this monad? callCC is not exactly what I
 need because it only helps abort the inner computation, and what is
 returned, is a monadic value, not a final value. Besides, callCC
 defines a name of the function corresponding to the current
 continuation, and in order to use it, this name should be visible.
 
 If I have
 
 callCC $ \exit - do
   foo
 ...
 
 I cannot jump to `exit' from within foo unless `exit' is given to foo
 as an argument.
 
 Any suggestions?

The best approach is probably to write a small variant of callCC usually
called control that does abort if it's continuation isn't used and use
that.  I'm not a big fan of call/cc in general; I much prefer control.
Control.Monad.Cont does export the Cont data constructor so you can
easily add it yourself.

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

Re: [Haskell-cafe] expanded standard lib

[Bryan O'Sullivan]

Neil Mitchell wrote:


- The packages seem to be of quite variable quality. Some are excellent,
some are rather poor (or just not maintained any more).


The problem is that only one person gets to comment on the quality of
a library, the author, who is about the least objective person.


Not necessarily.  CPAN has a nice voting system for packages, which is 
quite widely used.


Another useful proxy for quality that CPAN is missing is download 
statistics.  The maintainers handwave about this being due to the wide 
geographic distribution of mirrors, but  I think that any download 
statistics would be better than none.


Clearly, we can do both of these things with Hackage, and I think they'd 
be very useful (particularly the voting).  Another small but useful 
thing that Hackage is missing is a notion of how fresh a package is. 
You have to hand-construct an URL to get a directory listing from Apache 
to find out how old a particular release a tarball is.


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

Re: [Haskell-cafe] expanded standard lib

[david48]

On Nov 19, 2007 11:27 PM, Thomas Hartman [EMAIL PROTECTED] wrote:

 the php documentation has user contributed notes where people can leave
 sniplets of useful code as comments, eg

 http://www.php.net/manual/en/introduction.php

 I think this is a very nice feature.

I would love to have this on haskell, especially because the
documentation often lack example(s)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe