Re: [Haskell-cafe] Why monoids will abide...

[minh thu]

2009/1/21 Don Stewart :
> http://apfelmus.nfshost.com/monoid-fingertree.html
>
> Thanks Apfelmus for this inspiring contribution!
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

And for an introduction :

http://sigfpe.blogspot.com/2009/01/haskell-monoids-and-their-uses.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: HTTP-4000.0.4 released

[Sigbjorn Finne]

Hi,

a new release of HTTP, version 4000.0.4,  is now available

 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP

It is also pointed at via the updated HTTP web page --

 http://projects.haskell.org/http/

The main change is the addition of registering a Browser event handler
for capturing state changes to the request-response processing pipeline.
An experimental change, see Network.Browser.setEventHandler
(Feature suggested by Yuval Kogman in order to accommodate
load testing.)

enjoy
--sigbjorn

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

Re: [Haskell-cafe] ANN: HTTPbis / HTTP-4000.x package available

[Sigbjorn Finne]

On 1/17/2009 08:21, Tim Newsham wrote:

There's however still no framework which supports both HTTP client and
server functions using the same Request and Response data type, right? I
don't know whether I am the only one who needs this (e.g. for the Real
Monad Transformer). E.g. a proxy would need this, too.


I've wanted this for a while now.  "Me Too."

Tim Newsham
http://www.thenewsh.com/~newsham/

There's the basic receiveHTTP and respondHTTP that

  Network.HTTP.Stream
  Network.HTTP.HandleStream

exports. But that is probably not enough for your uses, I suspect.

To ensure that this feature request isn't dropped or forgotten about, 
please add

a ticket for it via the (new-homed) HTTP web pages --

http://projects.haskell.org/http/

Or, better still :-), contribute the code...to HTTP or some existing web 
server

framework.

thanks
--sigbjorn

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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Aaron Tomb]

On Jan 20, 2009, at 7:35 PM, wren ng thornton wrote:


Jim Burton wrote:

Hi, I will be a TA on a comparative PL course and I'm looking for
small examples (ammunition) which motivate the use of Haskell and
functional programming generally. The course is for 1st year Software
Engineers, none of whom are likely to have used a functional
language. They will all have experience programming Java and a little
C++, with a few of them knowing Python, Ruby, PHP etc etc too.


It's getting to be something of an old hat these days, but one of  
the most powerful selling points I've seen for purity (and strong  
types) is QuickCheck (and SmallCheck, LazySmallCheck,...). This  
entire paradigm of testing makes writing tests trivial and can only  
work right for pure functions.


I don't know if your students are just students or if they have some  
real software engineering experience, but anyone who's hacked on  
Perl, Python, Ruby, Java, or C++ enough to earn the title would be  
immensely impressed by how purity eases debugging.


I second this! For all of the wonderful benefits Haskell has, this is  
the one I miss most when programming in another language.


For an example of how hard it is to accomplish something like this in  
Java, check out JCrasher: http://ranger.uta.edu/~csallner/jcrasher/.  
Much less powerful, and much more work.


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

Re: [Haskell-cafe] Quite confused by simple transformations on this code not working

[Alexander Dunlap]

Instead of declaring (/\) :: Eq a => Sentence a -> Sentence a ->
Sentence a, you could say (/\) :: Eq a -> [a] -> [a] -> [a]. Then it
would work in both places. ([a] -> [a] -> [a] is a more general type
than [[Term a]] -> [[Term a]] -> [[Term a]], so functions with the
former type can be used in place of functions of the latter type but
not vice versa.)

Alex

2009/1/20 Andrew Wagner :
> So...there's just no good way to avoid the duplication?
>
> On Tue, Jan 20, 2009 at 11:10 PM, wren ng thornton 
> wrote:
>>
>> Andrew Wagner wrote:
>>>
>>> Strange little bit of code:
>>> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=829#a829
>>>
>>> If I do any of the following, all of which seem natural to me, it fails
>>> to
>>> typecheck:
>>>
>>>   1. move f out of the 'where' clause (with or without a type signature)
>>>   2. put the same type signature on f as is on (/\)
>>>   3. replace f with (/\) completely
>>>
>>> What's going on here?
>>
>>> :t (nub .) . (++)
>>(nub .) . (++) :: (Eq a) => [a] -> [a] -> [a]
>>
>>> :t foldr (map . (nub .) . (++))
>>foldr (map . (nub .) . (++)) :: (Eq a) => [[a]] -> [[a]] -> [[a]]
>>
>> The type you give to (/\) is more restrictive than the type of the
>> expression, and f uses the generality of the expression.
>>
>> --
>> Live well,
>> ~wren
>> ___
>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Quite confused by simple transformations on this code not working

[Andrew Wagner]

So...there's just no good way to avoid the duplication?

On Tue, Jan 20, 2009 at 11:10 PM, wren ng thornton wrote:

> Andrew Wagner wrote:
>
>> Strange little bit of code:
>> http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=829#a829
>>
>> If I do any of the following, all of which seem natural to me, it fails to
>> typecheck:
>>
>>   1. move f out of the 'where' clause (with or without a type signature)
>>   2. put the same type signature on f as is on (/\)
>>   3. replace f with (/\) completely
>>
>> What's going on here?
>>
>
>> :t (nub .) . (++)
>(nub .) . (++) :: (Eq a) => [a] -> [a] -> [a]
>
>> :t foldr (map . (nub .) . (++))
>foldr (map . (nub .) . (++)) :: (Eq a) => [[a]] -> [[a]] -> [[a]]
>
> The type you give to (/\) is more restrictive than the type of the
> expression, and f uses the generality of the expression.
>
> --
> Live well,
> ~wren
> ___
> 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] Quite confused by simple transformations on this code not working

[wren ng thornton]

Andrew Wagner wrote:

Strange little bit of code:
http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=829#a829

If I do any of the following, all of which seem natural to me, it fails to
typecheck:

   1. move f out of the 'where' clause (with or without a type signature)
   2. put the same type signature on f as is on (/\)
   3. replace f with (/\) completely

What's going on here?


> :t (nub .) . (++)
(nub .) . (++) :: (Eq a) => [a] -> [a] -> [a]

> :t foldr (map . (nub .) . (++))
foldr (map . (nub .) . (++)) :: (Eq a) => [[a]] -> [[a]] -> [[a]]

The type you give to (/\) is more restrictive than the type of the 
expression, and f uses the generality of the expression.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Quite confused by simple transformations on this code not working

[Andrew Wagner]

Strange little bit of code:
http://moonpatio.com:8080/fastcgi/hpaste.fcgi/view?id=829#a829

If I do any of the following, all of which seem natural to me, it fails to
typecheck:

   1. move f out of the 'where' clause (with or without a type signature)
   2. put the same type signature on f as is on (/\)
   3. replace f with (/\) completely

What's going on here?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Elevator pitch for functional programming

[wren ng thornton]

Jim Burton wrote:

Hi, I will be a TA on a comparative PL course and I'm looking for
small examples (ammunition) which motivate the use of Haskell and
functional programming generally. The course is for 1st year Software
Engineers, none of whom are likely to have used a functional
language. They will all have experience programming Java and a little
C++, with a few of them knowing Python, Ruby, PHP etc etc too.


It's getting to be something of an old hat these days, but one of the 
most powerful selling points I've seen for purity (and strong types) is 
QuickCheck (and SmallCheck, LazySmallCheck,...). This entire paradigm of 
testing makes writing tests trivial and can only work right for pure 
functions.


I don't know if your students are just students or if they have some 
real software engineering experience, but anyone who's hacked on Perl, 
Python, Ruby, Java, or C++ enough to earn the title would be immensely 
impressed by how purity eases debugging.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Why monoids will abide...

[Andrzej Jaworski]

Monads are monoids in categories of functors C -> C 
Arrows are monoids in subcategories of bifunctors (C^op) x C -> C 
  Trees are a playing ground for functors in general:-)


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

Re: [Haskell-cafe] some ideas for Haskell', from Python

[George Pollard]

On Wed, 2009-01-14 at 15:59 +0100, Manlio Perillo wrote:
> 1) In a Python string it is available the \U{name} escape, where name is
> a character name in the Unicode database.
> 
> As an example:
> foo = u"abc\N{VULGAR FRACTION ONE HALF}"

This is possible via QuasiQuotation, you can write a parser that will
let you do it like this:

foo = [$s|abc\N{VULGAR FRACTION ONE HALF}|]

I started to write one but got stuck :P By working from the wiki page
[1] I ended up with some code that will let you do:

let e = 3 in [$s|h\V{e}llo\U{32}world|] == "h3llo world"

I got stuck on a few things:
- how best to allow arbitrary expressions (requires additional parsing
to allow braces inside strings and so on, e.g. [$s|hello \E{"}"}
world|])
- can't figure out how to write the quoting function for the patterns...
this would be awesome if it worked:

everythingAfterFirstK [$s|\V{before}k\V{after}|] = after

- there's no library for looking up characters by name. 'unicode-names'
has getCharacterName but not the inverse.

Code follows:

StringSplicer.hs
> {-# LANGUAGE DeriveDataTypeable #-}
> 
> module StringSplicer 
> where
> 
> import Data.Generics
> import Text.ParserCombinators.Parsec
> import Control.Monad
> 
> data Exp = StringLit String
>   | Unicode Int
>   | Variable String
>   | Backslash
>   deriving (Show, Typeable, Data)
> 
> interp = do
>   char '\\'
>   c <- choice [char 'U', char 'V', char '\\']
>   case c of
>   'U' -> do
>   char '{'
>   n <- many1 digit
>   char '}'
>   return $ Unicode (read n)
>   'V' -> do
>   char '{'
>   s <- manyTill anyChar (try $ char '}')
>   return $ Variable s
>   '\\' -> return Backslash
> 
> str = do
>   s <- many1 $ noneOf ['\\']
>   return $ StringLit s
> 
> expr = many $ interp <|> str
> 
> parseString :: Monad m => (String, Int, Int) -> String -> m [Exp]
> parseString (file, line, col) s =
>   case runParser p () "" s of
>   Left err -> fail $ show err
>   Right e -> return e
>   where
>   p = do
>   pos <- getPosition
>   setPosition $
>   (flip setSourceName) file $
>   (flip setSourceLine) line $
>   (flip setSourceColumn) col $
>   pos
>   e <- expr
>   eof
>   return e

StringSplicer.Quote.hs
> module StringSplicer.Quote
> where
> 
> import Data.Generics
> import qualified Language.Haskell.TH as TH
> import Language.Haskell.TH.Quote
> import Data.Char (chr)
> import StringSplicer
> 
> quoteExprExp :: String -> TH.ExpQ
> quoteExprPat :: String -> TH.PatQ
> 
> s :: QuasiQuoter
> s = QuasiQuoter quoteExprExp quoteExprPat
> 
> parseIt x = do
>   loc <- TH.location
>   let pos =
>   (TH.loc_filename loc,
>   fst (TH.loc_start loc),
>   snd (TH.loc_start loc))
>   parseString pos x
> 
> quoteExprExp x = do
>   expr <- parseIt x
>   it <- dataToExpQ (const Nothing `extQ` antiExprExp) expr
>   return $ TH.AppE (TH.VarE (TH.mkName "concat")) it
> 
> quoteExprPat x = do
>   expr <- parseIt x
>   it <- dataToPatQ (const Nothing `extQ` antiExprPat) expr
>   error "help!"
> 
> antiExprExp :: Exp -> Maybe (TH.Q TH.Exp)
> antiExprExp (StringLit s) = Just $ TH.litE (TH.stringL s)
> antiExprExp (Backslash) = Just $ TH.litE (TH.stringL "\\")
> antiExprExp (Unicode n) = Just $ TH.litE (TH.stringL [chr n])
> antiExprExp (Variable v) = Just $ TH.appE
>   (TH.varE (TH.mkName "show"))
>   (TH.varE (TH.mkName v))
> 
> antiExprPat :: Exp -> Maybe (TH.Q TH.Pat)
> antiExprPat (Unicode n) = Just $ TH.litP (TH.stringL [chr n])
> antiExprPat (Backslash) = Just $ TH.litP (TH.stringL "\\")
> antiExprPat (StringLit s) = Just $ TH.litP (TH.stringL s)
> antiExprPat (Variable v) = Just $ TH.varP (TH.mkName v)

[1]: http://haskell.org/haskellwiki/Quasiquotation



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Factoring into type classes

[wren ng thornton]

Patai Gergely wrote:

Hi everyone,

I have a general program design question, but I can't really think of
good examples so it will be a bit vague. There was a discussion on Show
not long ago which brought up the problem that there are several ways to
"show" a data structure, and it depends on the context (or should I call
it a use case?) which of these we actually want, e.g. human readable
form, debug information, serialisation for later reading and so on, and
one of the solutions was to propose a family of show functions that
carry the intended use in their name.

However, there are other type classes that are too general to assign
such concrete uses to. For instance, if a data structure can have more
than one meaningful (and useful) Functor or Monoid instance, what should
one do? Should one refrain from instantiating these classes altogether
and just use the names of operations directly? If one still decides to
pick a certain set of operations as an instance, what are the factors
that should guide this decision? What about designing libraries, how
much should one prefer standard classes for their interfaces?

It seems to me that there is practically no literature on design issues
like these, and it would be nice to hear some opinions from experienced
Haskellers.


As others have mentioned or alluded to, I think that if you're designing 
general functions where you anticipate running into these issues then 
you should avoid the instance-selection mechanism of type classes. You 
can still use the dictionary-passing idea of type classes, but you must 
pass the dictionaries explicitly. This approach is used by the 
generalized functions in Data.List[1], as well as many other places.


Dictionary passing is, in essence, what higher-order programming is all 
about. Most often we deal with degenerate cases of dictionary passing 
where we only pass a single function (e.g. Data.List), but that's not 
the only way.


Another place where dictionary passing is used extensively is in the 
category-extras package[2] where the dictionaries are called 
"F-(co)algebras". An F-algebra is still degenerate as dictionaries go 
(it's a single function :: f a -> a), but it can be insightful to 
consider it as a dictionary proper, for example with "folding" functions 
like foldr. Normally we look at the type of foldr and think of it as 
taking two arguments, one for each constructor of lists. Instead, we can 
use a case expression to pack those two arguments together into a single 
F-algebra, selecting which argument to return based on the constructor. 
And this can be generalized to the folding functions for any datatype.


Thus, it's helpful to think of dictionaries as algebras (in generic and 
universal terms). A monoid is just one example of an object in universal 
algebra, it is an algebra defined by the underlying type, the operator, 
and the identity. Any type class is also an example of an algebra (e.g. 
Num defines an algebra with addition, multiplication, etc; Show is an 
algebra for showing). We can package any algebra up into a record and 
then pass that record around to the generic functions which need to use 
an instance of the algebra. The same idea can be used for passing around 
"laws" and "proofs" about data types (e.g. any function of type F(G a) 
-> G(F a) is a law that says we can distribute F over G).


The only difference between using type classes and manually passing 
these records around is that Haskell has linguistic and runtime support 
for plucking the records out of the aether based on types. Since the 
compiler knows about type classes it can do smarter things for them than 
just passing dictionaries, so they should be used whenever reasonable. 
Type classes are wonderful, but they're not a silver bullet. Even when 
they're not reasonable, having first-class functions means we're not 
limited by their restrictions.



[1] http://cvs.haskell.org/Hugs/pages/libraries/base/Data-List.html#22
[2] 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Factoring into type classes

[wren ng thornton]

Luke Palmer wrote:

On Mon, Jan 19, 2009 at 3:58 AM, Patai Gergely wrote:


However, there are other type classes that are too general to assign
such concrete uses to. For instance, if a data structure can have more
than one meaningful (and useful) Functor or Monoid instance,



As a side curiosity, I would love to see an example of any data structure
which has more than one Functor instance.  Especially those which have more
than one useful functor instance.


There are plenty of data structures which are multi-functors--- namely 
any type constructor with multiple arguments. The choice of order for 
arguments to the type constructor is arbitrary, so you can trivially 
choose the order you need for the Functor instance you want.


Depending on intensional vs extensional definitions for types, some may 
argue that these are "different" types due to currying and kinding 
issues, but those concerns only highlight the limitations of not having 
type-level functions like `flip`, rather than having any category 
theoretic basis.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: How to make code least strict?

[Conal Elliott]

Lovely reformulation, Ryan!

I think lub [4] is sufficient typeclass hackery for unambPatterns:

   unambPatterns == lubs == foldr lub undefined

[4] http://conal.net/blog/posts/merging-partial-values

I think performance is okay now, if you have very recent versions of unamb
*and* GHC head (containing some concurrency bug fixes).  See
http://haskell.org/haskellwiki/Unamb .  The GHC fix will take a while to get
into common use.

My definitions of zip via (a) 'assuming' & 'unamb' and (b) parAnnihilator
are badly broken.  For one, the unamb arguments are incompatible (since i
didn't check for both non-null args in the third case).  Also, the types
aren't right for parAnnihilator.

I tried out this idea, and it seems to work out very nicely.  See the
brand-new blog post
http://conal.net/blog/posts/lazier-function-definitions-by-merging-partial-values/.
 Blog comments, please!

   - Conal

On Mon, Jan 19, 2009 at 3:01 PM, Ryan Ingram  wrote:

> Actually, I see a nice pattern here for unamb + pattern matching:
>
> > zip xs ys = foldr unamb undefined [p1 xs ys, p2 xs ys, p3 xs ys] where
> > p1 [] _ = []
> > p2 _ [] = []
> > p3 (x:xs) (y:ys) = (x,y) : zip xs ys
>
> Basically, split each pattern out into a separate function (which by
> definition is _|_ if there is no match), then use unamb to combine
> them.
>
> The invariant you need to maintain is that potentially overlapping
> pattern matches (p1 and p2, here) must return the same result.
>
> With a little typeclass hackery you could turn this into
>
> > zip = unambPatterns [p1,p2,p3] where {- p1, p2, p3 as above -}
>
> Sadly, I believe the performance of "parallel-or"-style operations is
> pretty hideous right now.  Conal?
>
>  -- ryan
>
> On Mon, Jan 19, 2009 at 2:42 PM, Conal Elliott  wrote:
> > I second Ryan's recommendation of using unamb [1,2,3] to give you
> unbiased
> > (symmetric) laziness.
> >
> > The zip definition could also be written as
> >
> > zip xs@(x:xs') ys@(y:ys') =
> >   assuming (xs == []) [] `unamb`
> >   assuming (ys == []) [] `unamb`
> >   (x,y) : zip xs' ys'
> >
> > The 'assuming' function yields a value if a condition is true and
> otherwise
> > is bottom:
> >
> > assuming :: Bool -> a -> a
> > assuming True  a = a
> > assuming False _ = undefined
> >
> > This zip definition is a special case of the annihilator pattern, so
> >
> > zip = parAnnihilator (\ (x:xs') (y:ys') -> (x,y) : zip xs' ys') []
> >
> > where 'parAnnihilator' is defined in Data.Unamb (along with other
> goodies)
> > as follows:
> >
> > parAnnihilator :: Eq a => (a -> a -> a) -> a -> (a -> a -> a)
> > parAnnihilator op ann x y =
> >   assuming (x == ann) ann `unamb`
> >   assuming (y == ann) ann `unamb`
> >   (x `op` y)
> >
> > [1] http://haskell.org/haskellwiki/Unamb
> > [2]
> >
> http://hackage.haskell.org/packages/archive/unamb/latest/doc/html/Data-Unamb.html
> > [3] http://conal.net/blog/tag/unamb/
> >
> >- conal
> >
> > On Mon, Jan 19, 2009 at 12:27 PM, Ryan Ingram 
> wrote:
> >>
> >> On Mon, Jan 19, 2009 at 9:10 AM, ChrisK 
> >> wrote:
> >> > Consider that the order of pattern matching can matter as well, the
> >> > simplest
> >> > common case being zip:
> >> >
> >> > zip xs [] = []
> >> > zip [] ys = []
> >> > zip (x:xs) (y:ys) = (x,y) : zip xs ys
> >>
> >> If you are obsessive about least-strictness and performance isn't a
> >> giant concern, this seems like a perfect use for Conal's unamb[1]
> >> operator.
> >>
> >> zipR xs [] = []
> >> zipR [] ys = []
> >> zipR (x:xs) (y:ys) = (x,y) : zip xs ys
> >>
> >> zipL [] ys = []
> >> zipL xs [] = []
> >> zipL (x:xs) (y:ys) = (x,y) : zip xs ys
> >>
> >> zip xs ys = unamb (zipL xs ys) (zipR xs ys)
> >>
> >> This runs both zipL and zipR in parallel until one of them gives a
> >> result; if neither of them is _|_ they are guaranteed to be identical,
> >> so we can "unambiguously choose" whichever one gives a result first.
> >>
> >>  -- ryan
> >>
> >> [1]
> >>
> http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/
> >> ___
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pure Haskell implementation of Float type?

[Lennart Augustsson]

There's the numbers package which contains BigFloat.  You can pick
your own precision, but it's not IEEE.
It's actually base 10 floats which makes it more fun (actually, the
iEEE standard will cover base 10 floats in the future).

  -- Lennart

On Wed, Jan 21, 2009 at 12:44 AM, Tim Chevalier  wrote:
> On 1/20/09, Lennart Augustsson  wrote:
>> Do you have Integer?
>>
>
> Yes (with the integer-simple library -- I was hoping there was some
> analogue of integer-simple for Float, although Don didn't think there
> was one).
>
> -t
>
> --
> Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
> "Having the gumption to live different *and* the sense to let
> everybody else live different. That's the hardest thing, hands down."
> -- Alice Venable Middleton
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pure Haskell implementation of Float type?

[Tim Chevalier]

On 1/20/09, Lennart Augustsson  wrote:
> Do you have Integer?
>

Yes (with the integer-simple library -- I was hoping there was some
analogue of integer-simple for Float, although Don didn't think there
was one).

-t

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Having the gumption to live different *and* the sense to let
everybody else live different. That's the hardest thing, hands down."
-- Alice Venable Middleton
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pure Haskell implementation of Float type?

[Lennart Augustsson]

Do you have Integer?

On Wed, Jan 21, 2009 at 12:23 AM, Tim Chevalier  wrote:
> On 1/20/09, Don Stewart  wrote:
>> catamorphism:
>>
>> > Hello,
>>  > Is there a pure Haskell implementation of Floats, i.e., one that
>>  > (unlike GHC.Float) doesn't use foreign calls for things like
>>  > isFloatNegativeZero? I don't care about performance; I'm just looking
>>  > for something that doesn't use foreign calls.
>>  >
>>
>>
>> Huh, what's the use case?
>>
>
> I'm implementing a compiler that doesn't support foreign calls (yet).
>
> Cheers,
> Tim
>
> --
> Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
> "I cannot remember a time when I did not take it as understood that
> everybody has at least two, if not twenty-two, sides to him." --
> Robertson Davies
> ___
> 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] Why monoids will abide...

[Don Stewart]

http://apfelmus.nfshost.com/monoid-fingertree.html

Thanks Apfelmus for this inspiring contribution!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pure Haskell implementation of Float type?

[Tim Chevalier]

On 1/20/09, Don Stewart  wrote:
> catamorphism:
>
> > Hello,
>  > Is there a pure Haskell implementation of Floats, i.e., one that
>  > (unlike GHC.Float) doesn't use foreign calls for things like
>  > isFloatNegativeZero? I don't care about performance; I'm just looking
>  > for something that doesn't use foreign calls.
>  >
>
>
> Huh, what's the use case?
>

I'm implementing a compiler that doesn't support foreign calls (yet).

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"I cannot remember a time when I did not take it as understood that
everybody has at least two, if not twenty-two, sides to him." --
Robertson Davies
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Pure Haskell implementation of Float type?

[Don Stewart]

catamorphism:
> Hello,
> Is there a pure Haskell implementation of Floats, i.e., one that
> (unlike GHC.Float) doesn't use foreign calls for things like
> isFloatNegativeZero? I don't care about performance; I'm just looking
> for something that doesn't use foreign calls.
> 

Huh, what's the use case?

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

[Haskell-cafe] Pure Haskell implementation of Float type?

[Tim Chevalier]

Hello,
Is there a pure Haskell implementation of Floats, i.e., one that
(unlike GHC.Float) doesn't use foreign calls for things like
isFloatNegativeZero? I don't care about performance; I'm just looking
for something that doesn't use foreign calls.

Thanks,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"It is easy to keep secrets by being honest in an ironic tone of
voice." -- Andrew Solomon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Another Windows question - reading the output from a process

[Günther Schmidt]

Hi all,

I'm using WinXP with 6.8.3. For some reason the windows version of 6.8.3  
ships with a somewhat "castrated" version of package process, one that  
does not contain "readProcess" among other convenient functions.


Is there a way to install the fully fledged version of "process", because  
I tried using those "rawer" functions and just don't manage.


Günther

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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Jim Burton]

At Tue, 20 Jan 2009 14:17:10 -0800,
Ryan Ingram wrote:
> 
> I recommend checking out Don Syme's slides from CUFP 2008.
> 
> http://cufp.galois.com/2008/slides/
> 
> This isn't Haskell directly, it's F#, but it fits the "functional
> programming generally", and the two languages have, relative to the
> universe of programming languages, more in common than they do
> different.
> 
> There's a lot of "would you rather write this?" with a giant chunk of
> C#, followed by "or this?" with a few readable lines of F#.
>

Hi, those slides look useful and inspiring. Thanks a lot.

Jim 

>   -- ryan
> 
> 
> On Tue, Jan 20, 2009 at 2:07 AM, Jim Burton  wrote:
> > Hi, I will be a TA on a comparative PL course and I'm looking for
> > small examples (ammunition) which motivate the use of Haskell and
> > functional programming generally. The course is for 1st year Software
> > Engineers, none of whom are likely to have used a functional
> > language. They will all have experience programming Java and a little
> > C++, with a few of them knowing Python, Ruby, PHP etc etc too.
> >
> > If anyone has code snippets which are the equivalent of an elevator
> > pitch for FP, I would be very grateful to see them. What I want
> > are some small concrete examples of idioms which are natural and
> > powerful in Haskell but difficult or impossible in, say, Java.
> >
> > So I can produce examples of some of the things that make FP powerful,
> > elegant, expressive etc: higher order functions, polymorphism,
> > composition (ask them to write (.)  in Java :-)), partial application
> > and so on. I will point any interested souls to Hughes' great paper
> > [1]. But I have little time and it might be hard to put across why
> > they would want to do these things in the first place. I was looking
> > for something that speaks directly to the kind of problems they face
> > in languages like Java...
> >
> > Types are a good example because Java programmers generally already
> > appreciate the help they get from compiler messages etc, so you can
> > sell a more flexible, enhanced form of this. Purity might appeal to
> > anyone who has longed to be able to reason about nastily complex code
> > with a lot of shared state. Laziness, streams? Hard to do in Java (I
> > presume) but also quite hard to sell the need.
> >
> > The existence of an O'Reilly book will help, especially one that can
> > be sampled online, so I'll point them at RWH for extended concrete
> > examples. They will need to be already sold before they will bother
> > with that though.
> >
> > Thanks,
> >
> > Jim
> >
> > [1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
> > ___
> > 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] Elevator pitch for functional programming

[Jim Burton]

At Tue, 20 Jan 2009 22:08:55 +0100,
Henning Thielemann wrote:
> 
> Jim Burton schrieb:
> 
> > Well, I might but they definitely do not :-) We are talking about some
> > maths-averse people and you would not have got to the final syllable
> > of 'fibonacci' before all hope was lost. But I am sure there are 
> > plenty of examples that rely on laziness which will communicate. I am
> > sure I read a blog post or something on c.l.f/c.l.h recently about
> > lazily sorting a million numbers but can't find it. 
> 
> Maybe they are interested in finding all equal files in a set of files.
> This can be done in an elegant way by sorting the files with respect to
> their content. Practical enough?
>

Indeed, thanks!

Jim 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/equal-files
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Improved documentation for Bool (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt)

[Henning Thielemann]

rocon...@theorem.ca schrieb:
> On Sun, 18 Jan 2009, Ross Paterson wrote:
> 
>> Anyone can check out the darcs repos for the libraries, and post
>> suggested improvements to the documentation to librar...@haskell.org
>> (though you have to subscribe).  It doesn't even have to be a patch.
>>
>> Sure, it could be smoother, but there's hardly a flood of contributions.
> 
> I noticed the Bool datatype isn't well documented.  Since Bool is not a
> common English word, I figured it could use some haddock to help clarify
> it for newcomers.

The type should be named "Truth".
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt

[Henning Thielemann]

Apfelmus, Heinrich schrieb:

> Obviously, those who know what a monoid is have already invested years
> of time practicing mathematics while those that even attack the name
> "monoid" clearly lack this practice. It's like peano virtuosoes compared
> to beginning keyboard pressers.

Aren't all Haskellers some kind of Peano virtuosos? :-)

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

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Jonathan Cast]

On Tue, 2009-01-20 at 23:41 +0100, Henning Thielemann wrote:
> On Thu, 15 Jan 2009, John Goerzen wrote:
> 
> >  One thing that does annoy me about Haskell- naming. Say you've
> >  noticed a common pattern, a lot of data structures are similar to
> >  the difference list I described above, in that they have an empty
> >  state and the ability to append things onto the end. Now, for
> >  various reasons, you want to give this pattern a name using on
> >  Haskell's tools for expressing common idioms as general patterns
> >  (type classes, in this case). What name do you give it? I'd be
> >  inclined to call it something like "Appendable". But no, Haskell
> >  calls this pattern a "Monoid".
> 
> I risk to repeat someones point, since I have not read the entire thread 
> ... What I don't like about the Monoid class is, that its members are 
> named "mempty" and "mappend". It may be either (also respecting 
> qualified import)
>Monoid(identity, op)

+1

If we're going to change any names in the standard library at all, this
is the change we should make.

jcc


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

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Henning Thielemann]

John Goerzen schrieb:

> Though if all we're talking about is naming, I would still maintain that
> newbie-friendly naming is a win.  We can always say "HEY MATHEMETICIANS:
> APPENDABLE MEANS MONOID" in the haddock docs ;-)

We already have a problem with this:
Haskell 98 uses intuitive names for the numeric type classes.
It introduces new names, which do not match the names of common
algebraic structures.
Why is a type Num (numeric?), whenever it supports number literals, (+)
and (*)? Why not just number literals? Why not also division?
The numeric type hierarchy of Haskell must be learned anyway,
but the user learns terms he cannot use outside the Haskell world.
Ring and Field are harder to learn first, but known and precise terms.
(And if you don't like to learn the names, just write functions without
signatures and let GHCi find out the signatures with the appropriate
class constraints.)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Henning Thielemann]

On Thu, 15 Jan 2009, John Goerzen wrote:


 One thing that does annoy me about Haskell- naming. Say you've
 noticed a common pattern, a lot of data structures are similar to
 the difference list I described above, in that they have an empty
 state and the ability to append things onto the end. Now, for
 various reasons, you want to give this pattern a name using on
 Haskell's tools for expressing common idioms as general patterns
 (type classes, in this case). What name do you give it? I'd be
 inclined to call it something like "Appendable". But no, Haskell
 calls this pattern a "Monoid".


I risk to repeat someones point, since I have not read the entire thread 
... What I don't like about the Monoid class is, that its members are 
named "mempty" and "mappend". It may be either (also respecting 
qualified import)

  Monoid(identity, op)
 or
  Appendable(empty, append)
 where only the first one seems reasonable, since the Sum monoid and its 
friends do not append anything.

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

[Haskell-cafe] Type family problem

[Sjoerd Visscher]

Hi all,

When I try this bit of code:

> class C1 a where
>   type F a :: *
>   x :: F a
>   y :: F a
>   x = y

I get this error:

Couldn't match expected type `F a1' against inferred type `F a'
In the expression: y
In the definition of `x': x = y

I can't figure out what is going on or how I should fix this.

--
Sjoerd Visscher
sjo...@w3future.com



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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Ryan Ingram]

I recommend checking out Don Syme's slides from CUFP 2008.

http://cufp.galois.com/2008/slides/

This isn't Haskell directly, it's F#, but it fits the "functional
programming generally", and the two languages have, relative to the
universe of programming languages, more in common than they do
different.

There's a lot of "would you rather write this?" with a giant chunk of
C#, followed by "or this?" with a few readable lines of F#.

  -- ryan


On Tue, Jan 20, 2009 at 2:07 AM, Jim Burton  wrote:
> Hi, I will be a TA on a comparative PL course and I'm looking for
> small examples (ammunition) which motivate the use of Haskell and
> functional programming generally. The course is for 1st year Software
> Engineers, none of whom are likely to have used a functional
> language. They will all have experience programming Java and a little
> C++, with a few of them knowing Python, Ruby, PHP etc etc too.
>
> If anyone has code snippets which are the equivalent of an elevator
> pitch for FP, I would be very grateful to see them. What I want
> are some small concrete examples of idioms which are natural and
> powerful in Haskell but difficult or impossible in, say, Java.
>
> So I can produce examples of some of the things that make FP powerful,
> elegant, expressive etc: higher order functions, polymorphism,
> composition (ask them to write (.)  in Java :-)), partial application
> and so on. I will point any interested souls to Hughes' great paper
> [1]. But I have little time and it might be hard to put across why
> they would want to do these things in the first place. I was looking
> for something that speaks directly to the kind of problems they face
> in languages like Java...
>
> Types are a good example because Java programmers generally already
> appreciate the help they get from compiler messages etc, so you can
> sell a more flexible, enhanced form of this. Purity might appeal to
> anyone who has longed to be able to reason about nastily complex code
> with a lot of shared state. Laziness, streams? Hard to do in Java (I
> presume) but also quite hard to sell the need.
>
> The existence of an O'Reilly book will help, especially one that can
> be sampled online, so I'll point them at RWH for extended concrete
> examples. They will need to be already sold before they will bother
> with that though.
>
> Thanks,
>
> Jim
>
> [1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
> ___
> 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] Elevator pitch for functional programming

[Henning Thielemann]

Jim Burton schrieb:

> Well, I might but they definitely do not :-) We are talking about some
> maths-averse people and you would not have got to the final syllable
> of 'fibonacci' before all hope was lost. But I am sure there are 
> plenty of examples that rely on laziness which will communicate. I am
> sure I read a blog post or something on c.l.f/c.l.h recently about
> lazily sorting a million numbers but can't find it. 

Maybe they are interested in finding all equal files in a set of files.
This can be done in an elegant way by sorting the files with respect to
their content. Practical enough?

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/equal-files
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[Luke Palmer]

On Tue, Jan 20, 2009 at 1:14 PM, David Menendez  wrote:

> On Tue, Jan 20, 2009 at 2:51 PM, Mauricio  wrote:
> >>> But how is this:
> >>> data SomeNum = forall a. SN a
> >>> different from:
> >>> data SomeNum = SN (forall a. a)
> >
> >> At a glance they look the same to me — but only the first is accepted by
> >> ghc.
> >
> > Following the link you pointed in the last
> > message, I found this at 8.8.4.1:
> >
> > data T a = T1 (forall b. b -> b -> b) a
>

The constructor here is irrelevant.  The function here can do anything a
top-level function of type:

something :: b -> b -> b

I like to think about quantification in this regard in terms of
isomorphisms.  Think about what a function of type forall b. b -> b -> b can
do.  It cannot do anything with its arguments, because it must work on all
types, so it only has one choice to make: it can return the first argument,
or it can return the second argument.

So, forall b. b -> b -> b  is isomorphic to Bool.

For symmetry, the constructor T1 has type:

T1 :: (forall b. b -> b -> b) -> a -> T1 a


>
>
> > If I understand properly, it can be activated
> > with -XPolymorphicComponents. It's different
> > from my example, but I would like to know what
> > it does that this can't:
> >
>
> data T a = forall b. T1 (b->b->b) a
>

The constructor T1 here has type:

T1 :: forall b. (b -> b -> b) -> a -> T1 a

See the difference?

You can pass the latter a function of any type you choose, eg. (Int -> Int
-> Int) or ((Bool -> Bool) -> (Bool -> Bool) -> (Bool -> Bool)).  So when
somebody gets a T from you, they have no idea what type the function you
gave it was, so they can only use it in limited ways (in this case, nothing
useful at all can be done with it).

Here's another existential type:

data T' a = forall b. T' (b -> a) b

Here, a T' contains a value of some type b -- who knows what it is -- and a
function to get from that value to an a.  Since we don't know anything about
b, all we can do is to apply the function.

T' a is isomorphic to a.  But it might have different operational behavior;
e.g. maybe a is a huge list which is cheaply generated from some small
generator value (of type b).  Then if you pass a T' around, it's the same as
passing that big list around, except for you don't cache the results of the
list, improving memory performance.  It's like inverse memoization.

Not all existential types are for inverse memoization, this is just one
case.

I found it easiest to reason about these with the types of the constructors,
and thinking about what non-quantified type they are isomorphic to.

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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Jim Burton]

At Tue, 20 Jan 2009 12:25:00 -0800,
Dan Weston wrote:
> 

Hi Dan,

> One of the coolest things about Haskell is the ability to refer to 
> values not yet calculated, without having to work out the timing yourself.
> 
> You want Fibonacci numbers?
> 

Well, I might but they definitely do not :-) We are talking about some
maths-averse people and you would not have got to the final syllable
of 'fibonacci' before all hope was lost. But I am sure there are 
plenty of examples that rely on laziness which will communicate. I am
sure I read a blog post or something on c.l.f/c.l.h recently about
lazily sorting a million numbers but can't find it. 

Jim

> Prelude> let z = zipWith (+) (0:1:z) (0:z) in take 10 z
> [0,1,1,2,3,5,8,13,21,34]
> 
> Try doing that in one line of C++.
> 
> See also e.g.
> 
> http://sigfpe.blogspot.com/2006/12/tying-knots-generically.html
> 
> Dan
> 
> Jim Burton wrote:
> > 
> > Jim Burton wrote:
> >>
> >> Adrian Neumann wrote:
> >>> There was a thread about that:
> >>>
> >>>  > http://www.haskell.org/pipermail/haskell-cafe/2007-September/
> >>> 031402.html
> >> Thanks! I didn't literally mean "elevator pitch" and if I knew that thread
> >> existed would have phrased my post differently, because a list of the
> >> things that are cool about Haskell will not impress them. What I want and
> >> am finding it hard to create are examples where FP shines and, for the
> >> same problem, imperative languages look like more work. 
> >>
> > 
> > Parallelism! Something based on dons' blog
> > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core will be a
> > good start.
> > 
> > 
> > Many will think of
> >> programming solely in terms of developing websites, GUIs, database access,
> >> so I will demonstrate how strongly-typed database access can help them.
> >>
> >> Jim
> >>
> >> [...]
> >>
> >>
> > 
> 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Elevator pitch for functional programming

[Dan Weston]

One of the coolest things about Haskell is the ability to refer to 
values not yet calculated, without having to work out the timing yourself.


You want Fibonacci numbers?

Prelude> let z = zipWith (+) (0:1:z) (0:z) in take 10 z
[0,1,1,2,3,5,8,13,21,34]

Try doing that in one line of C++.

See also e.g.

http://sigfpe.blogspot.com/2006/12/tying-knots-generically.html

Dan

Jim Burton wrote:


Jim Burton wrote:


Adrian Neumann wrote:

There was a thread about that:

 > http://www.haskell.org/pipermail/haskell-cafe/2007-September/
031402.html

Thanks! I didn't literally mean "elevator pitch" and if I knew that thread
existed would have phrased my post differently, because a list of the
things that are cool about Haskell will not impress them. What I want and
am finding it hard to create are examples where FP shines and, for the
same problem, imperative languages look like more work. 



Parallelism! Something based on dons' blog
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core will be a
good start.


Many will think of

programming solely in terms of developing websites, GUIs, database access,
so I will demonstrate how strongly-typed database access can help them.

Jim

[...]







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

Re: [Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[David Menendez]

On Tue, Jan 20, 2009 at 2:51 PM, Mauricio  wrote:
>>> But how is this:
>>> data SomeNum = forall a. SN a
>>> different from:
>>> data SomeNum = SN (forall a. a)
>
>> At a glance they look the same to me — but only the first is accepted by
>> ghc.
>
> Following the link you pointed in the last
> message, I found this at 8.8.4.1:
>
> data T a = T1 (forall b. b -> b -> b) a
>
> If I understand properly, it can be activated
> with -XPolymorphicComponents. It's different
> from my example, but I would like to know what
> it does that this can't:
>
> data T a = forall b. T1 (b->b->b) a

In the first example, T stores a function which works for every type.
In the second example, T stores a function which works on a specific
type.

So with the first definition, you can do something like this:

foo :: T1 a -> (Bool, Int)
foo (T1 f _) = (f True False, f 1 2)

But you can't really do anything useful with the second example.

> (The last one I think I understand well after the
> previous message, although I see no use for this
> particular form, since after pattern match there's
> no other 'b' value to which we could aply that
> function field.)

Here's a more useful example of existential quantification:

data Stream a = forall b. Stream (b -> a) (b -> b) b

head :: Stream a -> a
head (Stream h t b) = h b

tail :: Stream a -> Stream a
tail (Stream h t b) = Stream h t (t b)


-- 
Dave Menendez 

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

Re: [Haskell-cafe] Employment

[Creighton Hogg]

On Tue, Jan 20, 2009 at 1:50 PM, Paul Johnson  wrote:
> Tom Hawkins wrote:
>>
>>  Such a database would help me counter by boss's
>> argument that "it's impossible to find and hire Haskell programmers."
>>
>>
>
> There was a thread last week where someone asked who would be interested in
> a hypothetical Haskell job.  He got about 20 positive responses.  This
> agrees with the experience of Microsoft Research in 2006 when they
> advertised for a third person to help with GHC development.   They also had
> about 20 applicants.
>
> So next time I hear the "you can't get the programmers" line I'm going to
> respond with something like this:
>
>   "If you post an advert for a Haskell developer you will get 20
>   applicants.  All of those people will be the kind of developer who
>   learns new programming languages to improve their own abilities and
>   stretch themselves, because nobody yet learns Haskell just to get a job.
>
>   "If you post an advert for a Java developer you will get 200
>   applicants.  Most of them will be the kind of developer who learned
>   Java because there are lots of Java jobs out there, and as long as
>   they know enough to hold down a job then they see no reason to learn
>   anything."

Also, as an employee, I have to admit that any company that can say it
uses Haskell for even part of its codebase immediately goes up in my
esteem & puts it on the shortlist for where to send my resume.  The
same way that programmers knowing Haskell implies a certain interest
in CS beyond "I want ma money", an employer using Haskell implies
technically interesting software & a stronger commitment to quality
over expediency.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[Mauricio]

But how is this:
data SomeNum = forall a. SN a
different from:
data SomeNum = SN (forall a. a)


At a glance they look the same to me — but only the first is accepted by 
ghc.


Following the link you pointed in the last
message, I found this at 8.8.4.1:

data T a = T1 (forall b. b -> b -> b) a

If I understand properly, it can be activated
with -XPolymorphicComponents. It's different
from my example, but I would like to know what
it does that this can't:

data T a = forall b. T1 (b->b->b) a

(The last one I think I understand well after the
previous message, although I see no use for this
particular form, since after pattern match there's
no other 'b' value to which we could aply that
function field.)

Link for convenience:

http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html

Maurício

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

Re: [Haskell-cafe] Employment

[Paul Johnson]

Tom Hawkins wrote:

 Such a database would help me counter by boss's
argument that "it's impossible to find and hire Haskell programmers."

  
There was a thread last week where someone asked who would be interested 
in a hypothetical Haskell job.  He got about 20 positive responses.  
This agrees with the experience of Microsoft Research in 2006 when they 
advertised for a third person to help with GHC development.   They also 
had about 20 applicants.


So next time I hear the "you can't get the programmers" line I'm going 
to respond with something like this:


   "If you post an advert for a Haskell developer you will get 20
   applicants.  All of those people will be the kind of developer who
   learns new programming languages to improve their own abilities and
   stretch themselves, because nobody yet learns Haskell just to get a job.

   "If you post an advert for a Java developer you will get 200
   applicants.  Most of them will be the kind of developer who learned
   Java because there are lots of Java jobs out there, and as long as
   they know enough to hold down a job then they see no reason to learn
   anything."

Paul.

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

Re: [Haskell-cafe] Factoring into type classes

[Iavor Diatchki]

Hello,

I don't mean to be negative here but I really fail to see how do any
of these ideas help the situation. (I do think it would be cool to
have a generic way to lift functions from one type to another that is
isomorphic to it).  The fundamental problem is that there are multiple
functions of type Int -> Int -> Int   (Int being just an example, for
the sake of concreteness), that can be the binary operation of a
monoid.  Therefore, we cannot use the type system to determine how to
resolve the overloading of symbols like "mappend".  Monoids are
general enough so that many types have multiple monoidal structure,
which is why I wrote that I don't think that they are good match for
the class system.

Defining a newtype and passing around isomorphisms seems more complex
to me than simply passing around the operations directly (i.e., not
using the class system).  By the way, Miguel's preference can be coded
almost verbatim in ML using "local" declarations (I am referring to
the "let"-like construct that allows the definition of local values
that scope over multiple declarations) without any fancy type magic.

-Iavor



On Tue, Jan 20, 2009 at 8:42 AM, Conor McBride
 wrote:
> Hi folks
>
> I have been known to venture the viewpoint that the
> "newtype trick" might benefit from improved library
> support, for example, here
>
>  http://www.mail-archive.com/haskell-cafe@haskell.org/msg37213.html
>
> This is in a similar vein to Derek's approach, if
> accompanied by a little more grotesque whizzbangery.
>
> On 19 Jan 2009, at 21:51, Derek Elkins wrote:
>
>> On Mon, 2009-01-19 at 12:10 -0800, Iavor Diatchki wrote:
>>>
>>> Sure, the point is that you are essentially adding a type annotation,
>>> which is like using a non-overloaded function.  Compare, for example:
>>> "mappend add x y"  and "getSum (mappend (Sum x) (Sum y))".  I think
>>> that the first one is quite a bit more readable but, of course, this
>>> is somewhat subjective.
>>
>> data Iso a b = Iso { to :: a -> b, from :: b -> a }
>>
>> under :: Iso a b -> (b -> b) -> (a -> a)
>> under iso = to iso ~> from iso
>>
>> under2 :: Iso a b -> (b -> b -> b) -> (a -> a -> a)
>> under2 iso = to iso ~> under iso
>>
>> sumIso = Iso Sum getSum
>>
>> (+) = under2 sumIso mappend
>
>
> Perhaps it's worth trying to push in this direction,
> in search of a coherent kit.
>
> After all, there's a lot of structure out there.
>
> All the best
>
> Conor
>
>
> ___
> 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] MonadTrans lift implementation

[Mauro J. Jaskelioff]

Ross Paterson wrote:
> On Mon, Jan 19, 2009 at 01:13:37PM -0800, Jonathan Cast wrote:
>   
>> (On the other hand, your hunch that lift = return is correct --- so you
>> get a cookie for that; it's just that return here is neither the return
>> of the monad for m nor the return of the monad for ReaderT m.  It is,
>> instead, the return of the *applicative functor* --- on the category of
>> monads and monad homomorphisms --- associated to the monad transformer
>> ReaderT.)
>> 
>
> It's also a monad in the category of monads, as are ErrorT, StateT and
> WriteT (see Moggi, An Abstract View of Programming Languages, 1989, s4).
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>   
Monads in the (2-)category of monads correspond to distributive laws
(see Formal theory of Monads by Street, 1972).
StateT does not arise from a distributive law.
In particular, you would need a map

tjoin :: Monad m => StateT (StateT m) a -> StateT m a
:: Monad m = (s -> s -> m ((a,s),s)) ->  s ->  m (a,s)

subject to the monad laws (where
 lift :: Monad m => m a -> StateT m a
is the unit, i.e. return)

All the best

- Mauro

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

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[ChrisK]

Great, thanks! I'm enlightened :)


And no one had to hit you with a stick first!



But how is this:

data SomeNum = forall a. SN a

different from:

data SomeNum = SN (forall a. a)

?


At a glance they look the same to me — but only the first is accepted by ghc.

There is also the GADT syntax:


data SomeNum where SomeNum :: forall a. (Typeable a, Num a) => a -> SomeNum


which is accepted by ghc with the LANGUAGE GADTs extension.

The GADT is more than simple syntactic sugar, it allows for easier use this kind 
of existential type.


--
Chris

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

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Tristan Seligmann]

* Andrew Coppin  [2009-01-16 22:20:35 +]:

> A problem I see a lot of [and other people have mentioned this] is that  
> a lot of documentation presents highly abstracted things, and gives *no  
> hint* of why on earth these might possibly be useful for something.  

I think this is definitely something that should be addressed by better
documentation of some kind. Unfortunately, this is quite possibly the
hardest kind of knowledge to put down into words: before you learn the
concepts, you don't know them, so you can't write about them, but after
you learn them, they seem so obvious that you don't know how to describe
them. (At least, this is typically the problem I have; I can answer
questions about something easily, maybe even walk someone through
understanding it, but I can't draft a document that will describe things
adequately to a newbie).

This problem is worse in Haskell than other languages, simply because
abstractions are used more frequently and pervasively in Haskell. In
many other languages, these abstractions are perfectly applicable, but
actually encoding them in the language is simply too unwieldy. Thus,
while the abstraction may be present as a fuzzy concept at the back of
the programmer's mind, or even as a "design pattern", the code people
actually work with tends to be at a more concrete level, despite the
more limited possibilities of code reuse at this level.

This ties in with the complaint that Haskell variable / parameter names
aren't descriptive enough. You frequently hear things like "why call it
'xs' instead of 'applicableItems'?"; often, the answer to this is simply
that the value in question is something so general that you cannot
describe it more specifically than "a list of something or other".
Haskell code is being written at a higher level of abstraction than the
newcomer is used to, and thus the highly abstract names are mistaken for
vague or imprecise names.

Now, it's all very well to explain the reasons behind this to the
newcomer, but they're still left in a position where they can't find the
tools they need to solve a particular problem. They're used to looking
for the concrete tools they need to do some task or another, which
aren't there; instead, there are all these abstract tools which can
perform the concrete task at hand, but what is really needed is help
finding the abstract tool for the concrete task at hand, or even
abstracting the concrete task at hand, thus making the choice of
abstract tool(s) an obvious one.

Sure, you can pop into #haskell and hopefully find someone to walk you
through the processes until you begin to understand the abstractions
yourself, but I think we (I almost hesitate to include myself, given my
own relatively miniscule Haskell knowledge) can do better than this in
terms of helping people unfamiliar with these concepts. Also, more
importantly, I'm referring specifically to teaching *programmers* the
concepts; I have no problem with *naming* things based on category
theory or abstract algebra or quantum mechanics, but I should not be
required to learn half a dozen fields of mathematics or physics in order
to *use* things. Writing about how Monads in Haskell relate to Monads in
category theory is of interest to category theorists, but isn't
something programmers should be reading.

Hopefully nothing I've said here comes as a surprise to anyone, and I'd
be surprised if there were many serious objections to any of it, but
perhaps it does need to be highlighted more prominently as an important
area to improve if Haskell is to grow as a programming language.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


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

Re: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Tristan Seligmann]

* John Goerzen  [2009-01-15 10:15:36 -0600]:

> If you're learning Haskell, which communicates the idea more clearly:
> 
>  * Appendable
> 
> or
> 
>  * Monoid
> 
> I can immediately figure out what the first one means.

I think that's deceptively misleading. Sure, list1 `mappend` list2 is
concatenation, of which Appendable is suggestive; but what on earth does
it mean to append a number to another number, or append a function to
another function? By doing some research, you can find out the answer,
but if you start off with a name that means nothing to you, I suspect
you'll be less confused than if you start off with a name that seems
like it makes sense, but actually doesn't.

(Of course, the name of mappend itself doesn't exactly help...)

> I guess the bottom line question is: who is Haskell for?  Category
> theorists, programmers, or both?  I'd love it to be for both, but I've
> got to admit that Brian has a point that it is trending to the first in
> some areas.

I don't really understand why Appendable is specifically a
"programmer-friendly" name; it doesn't really have any existing meaning
elsewhere in programming languages, for example.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


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

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[Gleb Alexeyev]

I just thought that the shorter explanation could do better: the 
difference is in the types of the constructor functions.


Code:
> {-# LANGUAGE ExistentialQuantification #-}
> {-# LANGUAGE RankNTypes #-}
> data SomeNum1 = forall a. SN1 a
> data SomeNum2 = SN2 (forall a. a)

ghci session:
*Main> :t SN1
SN1 :: a -> SomeNum1
*Main> :t SN2
SN2 :: (forall a. a) -> SomeNum2

This is not the whole story, types of the bound variables you get on 
pattern matching differ too, but this makes the short explanation a bit 
longer :).


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

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[Gleb Alexeyev]

Mauricio wrote:


But how is this:

data SomeNum = forall a. SN a

different from:

data SomeNum = SN (forall a. a)



In the first case the constructor SN can be applied to the monomorphic 
value of any type, it effectively hides the type of the argument. For 
example, you can have a list like [SN True, SN "foo", SN 42], because 
for all x SN x has type SomeNum.


In the second case, SN can be applied only to polymorphic values, SN 
True or SN "foo" won't compile.


The only thing that both types have in common - they are both useless. 
Polymorphic and existential types must have more structure to be useful 
- you cannot _construct_ SomeNum #2 and you cannot do anything to the 
value you _extract_ from SomeNum #1.


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

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes (actually, components...)

[Mauricio]

4294967296 :: Integer

(...)
In the above you can see the polymorphism of the return type of 
fromInteger, it returns a Int8 or a Int32.


You can see the polymorphism of the argument of "show", it takes an Int8 
or Int32 or Integer.


The latest ghc-6.10.1 also allows avoiding use of SomeNum, see 
impredicative-polymorphism:
http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#impredicative-polymorphism 





Great, thanks! I'm enlightened :)

But how is this:

data SomeNum = forall a. SN a

different from:

data SomeNum = SN (forall a. a)

?

Maurício

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

Re: [Haskell-cafe] Factoring into type classes

[Conor McBride]

Hi folks

I have been known to venture the viewpoint that the
"newtype trick" might benefit from improved library
support, for example, here

  http://www.mail-archive.com/haskell-cafe@haskell.org/msg37213.html

This is in a similar vein to Derek's approach, if
accompanied by a little more grotesque whizzbangery.

On 19 Jan 2009, at 21:51, Derek Elkins wrote:


On Mon, 2009-01-19 at 12:10 -0800, Iavor Diatchki wrote:


Sure, the point is that you are essentially adding a type annotation,
which is like using a non-overloaded function.  Compare, for example:
"mappend add x y"  and "getSum (mappend (Sum x) (Sum y))".  I think
that the first one is quite a bit more readable but, of course, this
is somewhat subjective.


data Iso a b = Iso { to :: a -> b, from :: b -> a }

under :: Iso a b -> (b -> b) -> (a -> a)
under iso = to iso ~> from iso

under2 :: Iso a b -> (b -> b -> b) -> (a -> a -> a)
under2 iso = to iso ~> under iso

sumIso = Iso Sum getSum

(+) = under2 sumIso mappend



Perhaps it's worth trying to push in this direction,
in search of a coherent kit.

After all, there's a lot of structure out there.

All the best

Conor


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

[Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt

[Heinrich Apfelmus]

Lennart Augustsson wrote:
> A very nice writeup about the use of monoid with finger tree.

Thanks :)

> But please, use the names of the monoid operations that the rest of
> the Haskell libraries use.
> By using different names you are just confusing readers (even if you
> don't like the standard names).

True. Unfortunately,  mappend  is no option because it's way too long, I
barely got away with writing out  measure  . There is  ++  but it's
already taken. Alternatively, I could opt for unicode ⊕ and at least
match the paper. Thoughts?

> Also, you can replace Infinity by maxBound.

Good idea, thanks.


Regards,
apfelmus

-- 
http://apfelmus.nfshost.com

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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Jim Burton]

Jim Burton wrote:
> 
> 
> Adrian Neumann wrote:
>> There was a thread about that:
>>
>>  > http://www.haskell.org/pipermail/haskell-cafe/2007-September/
>> 031402.html
> 
> Thanks! I didn't literally mean "elevator pitch" and if I knew that thread
> existed would have phrased my post differently, because a list of the
> things that are cool about Haskell will not impress them. What I want and
> am finding it hard to create are examples where FP shines and, for the
> same problem, imperative languages look like more work. 
> 

Parallelism! Something based on dons' blog
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking-4core will be a
good start.


Many will think of
> programming solely in terms of developing websites, GUIs, database access,
> so I will demonstrate how strongly-typed database access can help them.
> 
> Jim
> 
> [...]
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Elevator-pitch-for-functional-programming-tp21560192p21565826.html
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] Re: Comments from OCaml Hacker Brian Hurt

[Dougal Stanton]

On Tue, Jan 20, 2009 at 3:42 PM, Heinrich Apfelmus
 wrote:

> Let me explain this monoid magic, albeit not in this message which would
> become far too long, but at
>
>  http://apfelmus.nfshost.com/monoid-fingertree.html
>

That is a very nice summary! I did my own investigation of fingertrees
recently [1] and also came to the conclusion that the function names
for Monoid really are the ugliest, impractical things for such a
beautiful, simple concept.

Ah, if only we could go back in time :-)


[1]: 
http://www.dougalstanton.net/blog/index.php/2008/12/12/a-brief-look-at-fingertrees/


Cheers,

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

Re: [Haskell-cafe] Re: Comments from OCaml Hacker Brian Hurt

[Lennart Augustsson]

A very nice writeup about the use of monoid with finger tree.
But please, use the names of the monoid operations that the rest of
the Haskell libraries use.
By using different names you are just confusing readers (even if you
don't like the standard names).

Also, you can replace Infinity by maxBound.

  -- Lennart

On Tue, Jan 20, 2009 at 3:42 PM, Heinrich Apfelmus
 wrote:
> david48 wrote:
>> On the other hand, on page 320 there is a nice explanation of Monoid,
>> and on page 380, which isn't mentionned in the index, there might be
>> the first time one can understand why the writer monad works with
>> monoids instead of lists: to be able to use better suited data types
>> for appending.
>
> (I too usually use the monoid instance mainly for difference lists.)
>
>> All of this is still lacking the great why : why/how an abstraction so
>> generic can be useful.
>> I'm starting to believe that the only reason to make a datatype an
>> instance of Monoid is... why not ! since it's not hard to find an
>> associative operation and a neutral element.
>
> As Bertram Felgenhauer has already mentioned, a very powerful
> application of monoids are 2-3 finger trees
>
>Ralf Hinze and Ross Patterson.
>Finger trees: a simple general-purpose data structure.
>http://www.soi.city.ac.uk/~ross/papers/FingerTree.html
>
> Basically, they allow you write to fast implementations for pretty much
> every abstract data type mentioned in Okasaki's book "Purely Functional
> Data Structures". For example, you can do sequences, priority queues,
> search trees and priority search queues. Moreover, any fancy and custom
> data structures like interval trees or something for stock trading are
> likely to be implementable in this framework as well.
>
> How can one tree be useful for so many different data structures? The
> answer: *monoids*! Namely, the finger tree works with elements that are
> related to a monoid, and all the different data structures mentioned
> above arise by different choices for this monoid.
>
> Let me explain this monoid magic, albeit not in this message which would
> become far too long, but at
>
>  http://apfelmus.nfshost.com/monoid-fingertree.html
>
>
> Regards,
> apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
>
> ___
> 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] Re: Comments from OCaml Hacker Brian Hurt

[Heinrich Apfelmus]

david48 wrote:
> On the other hand, on page 320 there is a nice explanation of Monoid,
> and on page 380, which isn't mentionned in the index, there might be
> the first time one can understand why the writer monad works with
> monoids instead of lists: to be able to use better suited data types
> for appending.

(I too usually use the monoid instance mainly for difference lists.)

> All of this is still lacking the great why : why/how an abstraction so
> generic can be useful.
> I'm starting to believe that the only reason to make a datatype an
> instance of Monoid is... why not ! since it's not hard to find an
> associative operation and a neutral element.

As Bertram Felgenhauer has already mentioned, a very powerful
application of monoids are 2-3 finger trees

Ralf Hinze and Ross Patterson.
Finger trees: a simple general-purpose data structure.
http://www.soi.city.ac.uk/~ross/papers/FingerTree.html

Basically, they allow you write to fast implementations for pretty much
every abstract data type mentioned in Okasaki's book "Purely Functional
Data Structures". For example, you can do sequences, priority queues,
search trees and priority search queues. Moreover, any fancy and custom
data structures like interval trees or something for stock trading are
likely to be implementable in this framework as well.

How can one tree be useful for so many different data structures? The
answer: *monoids*! Namely, the finger tree works with elements that are
related to a monoid, and all the different data structures mentioned
above arise by different choices for this monoid.

Let me explain this monoid magic, albeit not in this message which would
become far too long, but at

  http://apfelmus.nfshost.com/monoid-fingertree.html


Regards,
apfelmus

-- 
http://apfelmus.nfshost.com



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

Re: [Haskell-cafe] some ideas for Haskell', from Python

[Lennart Augustsson]

Yes, the Agda modules remind me of Cayenne. :)

On Tue, Jan 20, 2009 at 12:54 PM, Bas van Dijk  wrote:
> On Wed, Jan 14, 2009 at 3:59 PM, Manlio Perillo
>  wrote:
>> 2) In Python it is possible to import modules inside a function.
>>
>>   In Haskell something like:
>>
>>   joinPath' root name =
>>   joinPath [root, name]
>>   importing System.FilePath (joinPath)
>
> I just like to point out the dependently typed, Haskell-like,
> programming language Agda[1] which has a very nice module system with
> the following features:
>
>  * Modules can contain other modules
>
>  * Modules can be locally opened. For example:
>   mapMaybe f m = let open Maybe in maybe nothing (just . f) m
>
>  * Renaming of important names: For example:
>   open Maybe renaming (Maybe to option; nothing to none; just to some)
>
>  * Parameterized modules: For example:
>
>   module Sort (A : Set) (_<_ : A -> A -> Bool) where
> insert : A -> List A -> List A
> insert y [] = y :: []
> insert y (x :: xs) with x < y
> ... | true  = x :: insert y xs
> ... | false = y :: x :: xs
>
> See section 2.7 of the following Agda tutorial (an open minded Haskell
> hacker should be able to read that section on its own):
>
> http://www.cs.chalmers.se/~ulfn/darcs/AFP08/LectureNotes/AgdaIntro.pdf
>
> Hopefully Haskell can borrow some of these ideas sometime.
>
> regards,
>
> Bas
>
> [1] http://wiki.portal.chalmers.se/agda/
> ___
> 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] Employment

[Jason Dusek]

  At my former employer, I wrote a couple of internal tools in
  Haskell that shipped to Linux, OS X and Windows. The relative
  ease of binary preparation was a selling point of Haskell.

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

Re: [Haskell-cafe] Elevator pitch for functional programming

[Jim Burton]

Adrian Neumann wrote:
> There was a thread about that:
>
>  > http://www.haskell.org/pipermail/haskell-cafe/2007-September/
> 031402.html

Thanks! I didn't literally mean "elevator pitch" and if I knew that thread
existed would have phrased my post differently, because a list of the
things that are cool about Haskell will not impress them. What I want and
am finding it hard to create are examples where FP shines and, for the
same problem, imperative languages look like more work. Many will think of
programming solely in terms of developing websites, GUIs, database access,
so I will demonstrate how strongly-typed database access can help them.

Jim

>
> Am 20.01.2009 um 11:07 schrieb Jim Burton:
>
>> Hi, I will be a TA on a comparative PL course and I'm looking for
>> small examples (ammunition) which motivate the use of Haskell and
>> functional programming generally. The course is for 1st year Software
>> Engineers, none of whom are likely to have used a functional
>> language. They will all have experience programming Java and a little
>> C++, with a few of them knowing Python, Ruby, PHP etc etc too.
>>
>> If anyone has code snippets which are the equivalent of an elevator
>> pitch for FP, I would be very grateful to see them. What I want
>> are some small concrete examples of idioms which are natural and
>> powerful in Haskell but difficult or impossible in, say, Java.
>>
>> So I can produce examples of some of the things that make FP powerful,
>> elegant, expressive etc: higher order functions, polymorphism,
>> composition (ask them to write (.)  in Java :-)), partial application
>> and so on. I will point any interested souls to Hughes' great paper
>> [1]. But I have little time and it might be hard to put across why
>> they would want to do these things in the first place. I was looking
>> for something that speaks directly to the kind of problems they face
>> in languages like Java...
>>
>> Types are a good example because Java programmers generally already
>> appreciate the help they get from compiler messages etc, so you can
>> sell a more flexible, enhanced form of this. Purity might appeal to
>> anyone who has longed to be able to reason about nastily complex code
>> with a lot of shared state. Laziness, streams? Hard to do in Java (I
>> presume) but also quite hard to sell the need.
>>
>> The existence of an O'Reilly book will help, especially one that can
>> be sampled online, so I'll point them at RWH for extended concrete
>> examples. They will need to be already sold before they will bother
>> with that though.
>>
>> Thanks,
>>
>> Jim
>>
>> [1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
>> ___
>> 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
>


-- 
Jim Burton

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

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes

[ChrisK]

Mauricio wrote:

Hi,

I'm trying, without success, to understand the difference
between existencial quantification and polymorphic
datatypes. Can you give me a hint, or an example where
one is valid and the other is not?


The first thing to ensure you know is that Haskell can have functions (usually 
in type classes) that have the Perl-like ability to return different types of 
values depending on the "context".


The usual example for this is "fromInteger :: Num a => Integer -> a".  Every 
integer in your source code is put through this function.  If the number is used 
in an Int context then it makes and Int, if use in a Word8 context then it makes 
a Word8.


The other way we talk about the type of context is that this is the type 
demanded by the user of the value.  Concretely:


x :: forall a. Num a => a
x = fromInteger 1

The type of 'x' is any Num type chosen by the user.  The critical thing here is 
that "fromInteger" does not get to choose the type.  This is bounded or 
constrained polymorphism, the type 'a' is polymorphic but bounded by the Num 
constraint.


Now I can refer to ghc's manual on existential quantification:
http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#existential-quantification

So what about wanting to write a function "myNum" that returns some Num type 
that "myNum" gets to choose instead of the user demanding a type.


We can do this with existential types, which usually is used with a data type 
(often a GADT) and here I call this SomeNum:



{-# LANGUAGE ExistentialQuantification #-}
import Int
import Data.Typeable
data SomeNum = forall a. (Typeable a, Num a) => SomeNum a

myNum :: Integer -> SomeNum
myNum x | abs x < 2^7  = let i :: Int8
 i = fromInteger x
 in SomeNum i
| abs x < 2^31 = let i :: Int32
 i = fromInteger x
 in SomeNum i
| otherwise = SomeNum x

display :: SomeNum -> String
display (SomeNum i) = show i ++ " :: " ++ show (typeOf i)

main = do
  putStrLn (display (myNum (2^0)))
  putStrLn (display (myNum (2^8)))
  putStrLn (display (myNum (2^32)))


In GHCI I see


*Main> main
main
1 :: Int8
256 :: Int32
4294967296 :: Integer


In the above you can see the polymorphism of the return type of fromInteger, it 
returns a Int8 or a Int32.


You can see the polymorphism of the argument of "show", it takes an Int8 or 
Int32 or Integer.


The latest ghc-6.10.1 also allows avoiding use of SomeNum, see 
impredicative-polymorphism:

http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#impredicative-polymorphism

So this next bit is very very new:

{-# LANGUAGE ExistentialQuantification, RankNTypes, ImpredicativeTypes #-}



displayNum :: [forall a. Num a => Integer -> a] -> String
displayNum converts = unlines $ concatMap withF converts
  where withF :: (forall b. Num b => Integer -> b) -> [String]
withF f = [ show (f 1 :: Int8)
  , show (f (2^10) :: Int32)
  , show (f (2^32) :: Integer) ]


The first argument to displayNum is a list of an existential type.  Before 
ImpredicativeType this would have required defining and using a data type like 
SomeNum.  So the latest ghc lets one avoid the extra data type.


displayNum cannot "demand" any (Num b => Integer->b) function.  The list holds 
SOME functions, but which one is unknowable to displayNum.


The first argument of withF is polymorphic and while this requires RankNTypes 
(or Rank2Types) the type of withF is not existential.  In withF the code demands 
three different types of results from the 'f'.  This works because the return 
type of (f 1) is really (Num b => b) and this is polymorphic and any type 'b' 
which is a Num can be demanded.


This can be tested with


  putStr $ displayNum [ fromInteger
  , fromInteger . (2*)
  , fromInteger . (min 1000) ]


which passes in a list of three different conversion functions.  In ghci the 
result is:



1
1024
4294967296
2
2048
8589934592
1
1000
1000


--
Chris

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

Re: [Haskell-cafe] some ideas for Haskell', from Python

[Bas van Dijk]

On Wed, Jan 14, 2009 at 3:59 PM, Manlio Perillo
 wrote:
> 2) In Python it is possible to import modules inside a function.
>
>   In Haskell something like:
>
>   joinPath' root name =
>   joinPath [root, name]
>   importing System.FilePath (joinPath)

I just like to point out the dependently typed, Haskell-like,
programming language Agda[1] which has a very nice module system with
the following features:

 * Modules can contain other modules

 * Modules can be locally opened. For example:
   mapMaybe f m = let open Maybe in maybe nothing (just . f) m

 * Renaming of important names: For example:
   open Maybe renaming (Maybe to option; nothing to none; just to some)

 * Parameterized modules: For example:

   module Sort (A : Set) (_<_ : A -> A -> Bool) where
 insert : A -> List A -> List A
 insert y [] = y :: []
 insert y (x :: xs) with x < y
 ... | true  = x :: insert y xs
 ... | false = y :: x :: xs

See section 2.7 of the following Agda tutorial (an open minded Haskell
hacker should be able to read that section on its own):

http://www.cs.chalmers.se/~ulfn/darcs/AFP08/LectureNotes/AgdaIntro.pdf

Hopefully Haskell can borrow some of these ideas sometime.

regards,

Bas

[1] http://wiki.portal.chalmers.se/agda/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Elevator pitch for functional programming

[Adrian Neumann]

There was a thread about that:

> http://www.haskell.org/pipermail/haskell-cafe/2007-September/ 
031402.html


Am 20.01.2009 um 11:07 schrieb Jim Burton:


Hi, I will be a TA on a comparative PL course and I'm looking for
small examples (ammunition) which motivate the use of Haskell and
functional programming generally. The course is for 1st year Software
Engineers, none of whom are likely to have used a functional
language. They will all have experience programming Java and a little
C++, with a few of them knowing Python, Ruby, PHP etc etc too.

If anyone has code snippets which are the equivalent of an elevator
pitch for FP, I would be very grateful to see them. What I want
are some small concrete examples of idioms which are natural and
powerful in Haskell but difficult or impossible in, say, Java.

So I can produce examples of some of the things that make FP powerful,
elegant, expressive etc: higher order functions, polymorphism,
composition (ask them to write (.)  in Java :-)), partial application
and so on. I will point any interested souls to Hughes' great paper
[1]. But I have little time and it might be hard to put across why
they would want to do these things in the first place. I was looking
for something that speaks directly to the kind of problems they face
in languages like Java...

Types are a good example because Java programmers generally already
appreciate the help they get from compiler messages etc, so you can
sell a more flexible, enhanced form of this. Purity might appeal to
anyone who has longed to be able to reason about nastily complex code
with a lot of shared state. Laziness, streams? Hard to do in Java (I
presume) but also quite hard to sell the need.

The existence of an O'Reilly book will help, especially one that can
be sampled online, so I'll point them at RWH for extended concrete
examples. They will need to be already sold before they will bother
with that though.

Thanks,

Jim

[1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




PGP.sig
Description: Signierter Teil der Nachricht
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Existencial quantification and polymorphic datatypes

[Jon Fairbairn]

Mauricio  writes:

> I'm trying, without success, to understand the difference
> between existencial quantification and polymorphic
> datatypes.

Polymorphic types are universally quantified;

so id:: forall t. t -> t

means that id works for every type t.  If haskell had a
symbol for existential quantification, 

  hid:: exists t. t -> t

would mean that hid only works on some type t, but it
doesn't say what it is (so you could only ever apply hid to
undefined.

> Can you give me a hint

Because being on the left of an arrow works something like
negation, a type like (exists t. t -> t) -> bool can be
written as  forall t . (t -> t) -> bool



-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2008-04-26)

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

Re: [Haskell-cafe] Existencial quantification and polymorphic datatypes

[Lennart Augustsson]

Do you mean difference between
  data A a = A a
and
  data B = B a -- leaving out the forall
?

On Tue, Jan 20, 2009 at 10:02 AM, Mauricio  wrote:
> Hi,
>
> I'm trying, without success, to understand the difference
> between existencial quantification and polymorphic
> datatypes. Can you give me a hint, or an example where
> one is valid and the other is not?
>
> Thanks,
> Maurício
>
> ___
> 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] Cabal dependencies

[Duncan Coutts]

On Thu, 2009-01-15 at 18:38 -0500, Stephen Hicks wrote:
> Hi,
> 
> I'm having some difficulty specifying dependencies in my .cabal file
> for a package I'm looking to upload to hackage soon.  The difficulty
> is as follows.  I basically want to specify
>   parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4)

When we first introduced this kind of version range syntax we were
unsure if it was too general or not. We want to be able to translate
into other systems and they're typically more restrictive.

Internally we can easily represent the above expression as it uses
arbitrary unions and intersections. However the external parser still
only allows two clauses (I think it's two).

Personally I'm all for lifting that restriction. Yes it makes it a bit
harder for translating into some systems but I don't see that as a real
issue. If the package really does require the more complex version range
then forcing the package author to lie by using a less expressive syntax
does not help. We can still make the same choice at the point when we
translate into native packages.

Also, as it happens there is a way of getting around the restriction
anyway, which makes the restriction effectively pointless. That is by
listing the same dependency more than once. All the version constraints
must be satisfied so you can write:

  build-depends:
parsec >= 2.1 && < 4,
parsec < 3.0.0 || > 3.0.0

(have I got that right?)

So I'd be interested to get feedback on lifting the restriction and the
impact that might have on translation into native packages.

> The problem is that 3.0.0 as it exists on hackage is missing a
> constructor that I need (namely, Postfix, in the compatibility
> module).  The bug was fixed and will presumably work fine if a newer
> version of parsec is ever uploaded to hackage, and my package works
> fine with older parsecs as well - I just want to exclude this one
> version.  How can I go about doing that?

Try the above.

> A secondary question is this - I can actually compile with version
> 3.0.0 by just not using this constructor, although it does reduce the
> package's functionality.  I've seen flags in various .cabal files, and
> presumably I could invent a flag to make it work with 3.0.0, but I'm
> confused about how these flags are set.

Yes, if you need compatibility with older versions of Cabal then you'd
need to use a flag. If you're prepared to require Cabal-1.6 or later
then you can use the cpp macro:

#if MIN_VERSION_parsec(3,0,0)

though of course that only gives you >= 3.0.0, you'd need more tricky
combinations to get == 3.0.0, perhaps by assuming >= 3.0.1 is ok.

For older Cabal versions the main option is a flag, like so:

flag parsec3
...

if flag(parsec3)
  build-depends: parsec == 3.0.0
  cpp-options:   -DUSING_BAD_PARSEC
else
  build-depends: parsec > 3.0.0 || < 3.0.0

> Specifically, cabal-install has never asked me anything about flags,
> so what's the point?  Or does it automatically set whichever flags
> satisfy the dependencies?

It tries to work out what flags to set automatically (based on the
platform, the available packages and flag defaults in each package). You
can override them from the command line if you want to or need to.

Duncan

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

[Haskell-cafe] Re: GHCi Memory Leak in Windows Vista

[Gracjan Polak]

Same here:

Vista, GHC 6.8.3

Tested a bit changed scenario: instead of 20 separate compilations it is
worthwhile to run single, longer build, e.g. ghc --make of same package.

Seems like GHCi does not run garbage collection when machine is busy. And then
it accumulates memory. This renders Vista totally unresponsive and even can lead
to automatic reboot (happened once to me).

:)

-- 
Gracjan


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

[Haskell-cafe] Elevator pitch for functional programming

[Jim Burton]

Hi, I will be a TA on a comparative PL course and I'm looking for
small examples (ammunition) which motivate the use of Haskell and
functional programming generally. The course is for 1st year Software
Engineers, none of whom are likely to have used a functional
language. They will all have experience programming Java and a little
C++, with a few of them knowing Python, Ruby, PHP etc etc too.

If anyone has code snippets which are the equivalent of an elevator
pitch for FP, I would be very grateful to see them. What I want
are some small concrete examples of idioms which are natural and
powerful in Haskell but difficult or impossible in, say, Java.

So I can produce examples of some of the things that make FP powerful,
elegant, expressive etc: higher order functions, polymorphism,
composition (ask them to write (.)  in Java :-)), partial application
and so on. I will point any interested souls to Hughes' great paper
[1]. But I have little time and it might be hard to put across why
they would want to do these things in the first place. I was looking
for something that speaks directly to the kind of problems they face
in languages like Java...

Types are a good example because Java programmers generally already
appreciate the help they get from compiler messages etc, so you can
sell a more flexible, enhanced form of this. Purity might appeal to
anyone who has longed to be able to reason about nastily complex code
with a lot of shared state. Laziness, streams? Hard to do in Java (I
presume) but also quite hard to sell the need.

The existence of an O'Reilly book will help, especially one that can
be sampled online, so I'll point them at RWH for extended concrete
examples. They will need to be already sold before they will bother
with that though.

Thanks,

Jim

[1] http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Existencial quantification and polymorphic datatypes

[Mauricio]

Hi,

I'm trying, without success, to understand the difference
between existencial quantification and polymorphic
datatypes. Can you give me a hint, or an example where
one is valid and the other is not?

Thanks,
Maurício

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

Re: [Haskell-cafe] xhtml + bytestring

[Eugene Kirpichov]

Hi,
I improved the implementation of concatMap:

concatMap' :: (Word8 -> L.ByteString) -> L.ByteString -> L.ByteString
concatMap' f s = L.unfoldr p x0
where x0 = (LI.Empty, s)
  p (sf, s) = case L.uncons sf of
  Just (c,sf') -> Just (c, (sf',s))
  Nothing -> case L.uncons s of
  Nothing -> Nothing
  Just (c,s') -> p (f c, s')

I did a test that performs something like escaping in the following fashion:
main = putStrLn . show . L.foldr (+) 0 $ concatMap' f xs
where xs = L.pack $ concat $ replicate 10 [1..10]
  f 1 = esc
  f x = L.pack [x]
  esc = L.pack [1,2,3,4]
So, every 10th character is escaped.

My version works 4x faster than L.concatMap.
However, if 'f' returns larger strings, it quickly becomes dramatically slower.

So, I'd recommend it for escaping and wouldn't recomment it for anything else.

2009/1/20 Joachim Breitner :
> Hi Bjorn, hi list,
>
> the darcswatch instance I'm running is getting quite big, and it
> periodically slows down my server. I managed to get quite an improvement
> with this simple patch to my parsing:
> http://darcs.nomeata.de/cgi-bin/darcsweb.cgi?r=darcswatch;a=commitdiff;h=20090119181919-23c07-140f8deb91a52a423a2984dce2d22f4a48999aaf.gz
>
> Since the new HTTP library, my code runs completely on ByteStrings, only
> the xhtml library expects me to feed strings. I tried to fix this and
> created a patch against xhtml-3000.2.0.1 to work internally with lazy
> ByteStrings. It's API-compatible to the normal xhtml library, it just
> adds showHtml', renderHtml' and prettyHtml' that output lazy
> ByteStrings, and that has Html instances for strict any lazy
> ByteStrings.
>
> There were some speed and space improvements, but none horrific (at
> least for DarcsWatch, most of the time goes into parsing the
> repositories and mails, and into sorting that data). Unfortunately, I
> can't use it in the live installation until I upgrade the machine from
> Debian etch to lenny, as the bundled bytestring library in ghc-6.6' base
> is too old.
>
> Nevertheless, I'm sharing my patch here, maybe it's useful for some, or
> maybe it can be the base for an official xhtml release with bytestrings
> inside.
>
> To speed things up even more one should probably create a type analogous
> to ShowS, i.e. (L.ByteString -> L.ByteString), that allows you to
> concatenate ByteString chunks cheaply.
>
> I also noted that the current version of bytestring implements
> "concatMap" in a way that is guaranteed to rip apart the string into
> very small chunks, even if the mapped function returns the same
> character most times (as it is the case for the Html escaping function).
> Therefore, I wrote this function:
>
> -- | More efficient variant of 'L.concatMap'
> concatMapL' :: (Char -> String) -> L.ByteString -> L.ByteString
> concatMapL' f s = go s
>  where go s = let (unmodified, modified) = L.span (\c -> f c == [c]) s
>   in case L.uncons modified of
> Nothing   -> unmodified
> Just (c,rest) -> L.pack (f c) `L.append` go rest
>
> Does this make sense? Should it maybe replace the function in the
> library?
>
> Greetings,
> Joachim
>
> [1] http://darcswatch.nomeata.de/
>
> --
> Joachim "nomeata" Breitner
>  mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
>  JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
>  Debian Developer: nome...@debian.org
>
> ___
> 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