Re: [Haskell-cafe] Introspection on types.

[Gregory Propf]

Thanks, I'll check out Data and Typeable

--- On Thu, 10/1/09, Brandon S. Allbery KF8NH  wrote:

From: Brandon S. Allbery KF8NH 
Subject: Re: [Haskell-cafe] Introspection on types.
To: "Gregory Propf" 
Cc: "Brandon S. Allbery KF8NH" , "Haskell-Cafe" 

Date: Thursday, October 1, 2009, 6:14 PM

On Oct 1, 2009, at 19:22 , Gregory Propf wrote:Is there a way to tell, let's 
say, how many constructors there are for a type?  Or do I need one of the 
haskell extensions I've read about?

If the constructors are nullary (that is:  data MyData = Foo | Bar | Baz) you 
could derive Enum and Bounded, then (maxBound :: MyData) is one less than the 
number of constructors.
Anything more complicated requires deriving Data or Typeable (I've done it with 
the latter but don't recall details off the top of my head).
 -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] 
allb...@kf8nh.comsystem administrator [openafs,heimdal,too many hats] 
allb...@ece.cmu.eduelectrical and computer engineering, carnegie mellon 
university    KF8NH
 



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

[Haskell-cafe] Re: Haskell for Physicists

[Ahn, Ki Yung]

ed...@ymonad.com 쓴 글:

Hi,

I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) 
university and they asked me for a good title, something that can attract 
physicists. Anyone has some suggestions? (Will be
a seminar about the use of Haskell to substitute C or Fortran
in a lot of tasks, and how it can be used in some problems instead of 
Matlab, Mathematica, etc.)


Thanks,
Edgar


You should also see the well known Haskell story in this area:

http://bayern.stanford.edu/~brant/lightning/

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

[Haskell-cafe] ANN: json-b-0.0.4

[Jason Dusek]

  This version fixes defective handling of empty objects and
  arrays.

http://hackage.haskell.org/package/json-b-0.0.4

  Thanks to Dmitry Astapov for this fix.

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

[Haskell-cafe] FP Market Place (was Market Place for Haskell development teams?)

[Max Cantor]

Haskell, and FP languages more broadly, are finding a pretty solid  
niche in small scale, but technically demanding and lucrative  
projects.  Financial modeling and analytics are the first thing that  
comes to mind.  The work of Galois, Atom, etc also sort of fit this  
mold.


While the people on this list are clearly leaning towards Haskell,  
this is a niche that Haskell shares with OCaml, Erlang, and even Scala  
and Clojure.  Perhaps, combining efforts with those communities (call  
it lambdajobs or something) would help get closer to a critical mass  
and aid cross-pollination between communities.  Considering the  
salaries and value-add with skilled FP programmers, and the difficulty  
in finding them, this could even be a profitable venture in the long  
run if employers are charged for successful placements or for ads once  
we get going.


Just my 2¢

Max


On Oct 1, 2009, at 11:56 AM, Curt Sampson wrote:


On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona  wrote:


What is the vehicle that haskell can use to enter the mainstream?.


Actually, I have one more thought on that: wait.

I'd had the impression that Haskell was becoming fairly well known (if
not yet heavily used, in comparison to languages like Java), but I  
just

ran across some hard evidence for this.

In the 32 languages ranked on http://www.langpop.com/ , Haskell
consistently comes down near the bottom in the various rankings of
use. (But hey, we're not so weird we're not in there!) But if you look
down near the bottom, at the chart labeled "Normalized Discussion Site
Results," you'll notice that Haskell comes out sixth. Even trying to  
be

more fair to the mainstream, and changing the weighting to drop Lambda
the Ultimate completely (after all, they're just a bunch of academic
wankers, right?) and bring IRC down to a contribution of 0.5 instead  
of
1 (apparently those academic wankers have lots of time to chat  
online),

Haskell still comes out tenth, with a score over a third that of the
leader, Java, and close to half that of PHP and C (2nd and 3rd place,
respectively).

We've also got at least one undeniably good, production-quality  
compiler

(which is more than PHP or Ruby can say), and have sold many tens of
thousands, perhaps even hundreds of thousands, of books. At this  
point,

I don't think many people (John A. De Goes excepted) are looking at
people writing major applications in Haskell as if they're aliens  
living

on another planet.

Haskell is in the mainstream already as far as being taken seriously;
most of the complaints I'm seeing seem to be grasping at the same  
kinds

of straws that the anti-Java guys were back in the late '90s. ("It's
hopeless if it uses garbage collection.")

We've even got our own over-hyped, under-utilized supposed benefit
("it's good for multicore").

The main whinging seems to be about libraries, of which we have "only"
1585 on hackage.

Compare with RubyForge, which has 2059 projects in "beta" or better
status, or 2961 if we include "alpha" as well. The Ruby Application
Archive has 1768 projects; I have no idea how much overlap there is,  
or

how many of these are real.

I think we just need to sit tight for a couple of years.

cjs
--
Curt Sampson   +81 90 7737 2974
  Functional programming in all senses of the word:
  http://www.starling-software.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

Re: [Haskell-cafe] Re: a boring parser

[Greg Fitzgerald]

Cool, I like how this parser can model the "Look, an Eagle" scenario.  For
reference:
http://www.youtube.com/watch?v=pjh3e198pUQ

The parser can "change focus" (that is, change traversal strategy) in
response to a successful parse.  In the "Look, an Eagle" scenario, the bear
is able to interpret and respond to its input serially and interactively,
but when the bear's input stream is replaced by a new one, the man is able
to capture the prize.

-Greg


On Thu, Oct 1, 2009 at 1:02 PM, Anatoly Yakovenko wrote:

> so whats pretty cool is that I can traverse arbitrary data structures as
>  well:
>
> data Tree a = Tree (Tree a) a (Tree a) | Bottom
>deriving Show
>
> left a = do
>   make $ \ st -> do
>  case(st) of
> (Bottom) -> eos
> (Tree left val right) ->
>case (a < val) of
>   True -> return $ (val, left)
>   False -> noMatch
>
> right a = do
>   make $ \ st -> do
>  case(st) of
> (Bottom) -> eos
> (Tree left val right) ->
>case (a > val) of
>   True -> return $ (val, right)
>   False -> noMatch
>
> eqT a = do
>   make $ \ st -> do
>  case(st) of
> (Bottom) -> eos
> (Tree _ val _) ->
>case (a == val) of
>   True -> return $ (val, st)
>   False -> noMatch
>
> search a = manyTill (left a <|> right a) (eqT a)
>
> > run (search 5) $ Tree (Tree Bottom 1 Bottom) 3 (Tree Bottom 5 Bottom)
> Right (([3],5),Tree Bottom 5 Bottom)
>
>
>
> On Wed, Sep 30, 2009 at 8:04 PM, Anatoly Yakovenko
>  wrote:
> > i got annoyed with Parsec and wrote a much more boring parser which
> > allows me to parse anything with any kind of matching i want.  Its
> > basically a combination of State and Error monads.
> >
> > So i can use a grep like parser that matches via a regular expression
> > over a list of lines
> >
> > grep re = do
> >   vv::B.ByteString <- any
> >   let (_,_,_,rv) = (vv =~
> > re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString])
> >   case (rv) of
> >  [] -> throwError "no match"
> >  _ -> return $ rv
> >
> >> run (grep $ C.pack "(hello)") $ [C.pack "hello world"]
> > Right (["hello"],[])
> >
> > or use the same library to scan over a string by combining regular
> expressions
> >
> > regex re = do
> >   make $ \ st -> do
> >  case (B.null st) of
> > True -> throwError "eos"
> > _ -> do
> >let (_,_,after,rv) = (st =~
> > re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString])
> >case (rv) of
> >   [] -> throwError "no match"
> >   _ -> return $ (rv,after)
> >
> >
> >
> >>  run (do aa <- regex $ C.pack "(hello)"; bb <- regex $ C.pack "
> (world)"; return (aa,bb) ) $ C.pack "hello world"
> > Right ((["hello"],["world"]),"")
> >
> > or simply match integers in a list, or anything that is of type Eq
> >
> >> run (many1 $ eq 1) [1,1,1,2,3,4]
> > Right ([1,1,1],[2,3,4])
> >
> > i can define lt
> >
> > lt cc = do
> >   vv <- any
> >   case (vv < cc) of
> >  True -> return $ vv
> >  _ -> throwError "no match"
> >
> > and do
> >
> >> run (many1 $ lt 5 <|> eq 5) [1..10]
> > Right ([1,2,3,4,5],[6,7,8,9,10])
> >
> > here is the implementation
> >
> > module Parser( ParserM --type alias for the parser ParserM a b is
> > over "stream" a and returns b
> > , make--makes a parser from a matching function of
> > type :: stream -> m (match_data,stream)
> >   --for example any is implemented via:
> >   --any :: ParserM [a] a
> >   --any = make $ \ ll ->
> >   --   case (ll) of
> >   -- (hh:tt) -> return $ (hh,tt)
> >   --   _ -> throwError "eos
> >   --matches and returns an element from a
> > list, which makes any of type :: ParserM [a] a
> > , any --matches any element from [a] type stream
> > , eq  --matches an equal element from [Eq] stream,
> > trivialy implemented in terms of any
> >   --eq :: Eq a => a -> ParserM [a] a
> >   --eq cc = do
> >   --   vv <- any
> >   --   case (vv == cc) of
> >   --  True -> return $ vv
> >   -- _ -> throwError "no match
> > , (<|>)   --or operator, tries the left one then the
> right one
> > , manyTill--collects the results of parser 1 until
> > parser 2 succeeds
> > , many1   --collects the results of the parser, must
> > succeed at least once
> > , many--collects the results of a parser
> > , run --runs the parser
> > ) where
> >
> > import Control.Monad.State.Lazy
> > import Control.Monad.Error
> > import Test.QuickCheck
> > impo

Re: [Haskell-cafe] Introspection on types.

[Brandon S. Allbery KF8NH]

On Oct 1, 2009, at 19:22 , Gregory Propf wrote:
Is there a way to tell, let's say, how many constructors there are  
for a type?  Or do I need one of the haskell extensions I've read  
about?



If the constructors are nullary (that is:  data MyData = Foo | Bar |  
Baz) you could derive Enum and Bounded, then (maxBound :: MyData) is  
one less than the number of constructors.


Anything more complicated requires deriving Data or Typeable (I've  
done it with the latter but don't recall details off the top of my  
head).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Introspection on types.

[Derek Elkins]

On Thu, Oct 1, 2009 at 6:22 PM, Gregory Propf  wrote:
>
> Is there a way to tell, let's say, how many constructors there are for a 
> type?  Or do I need one of the haskell extensions I've read about?

Use Data.Data and derive Data for the types you are interested in or
instance it for pre-existing types that aren't already instances.
Introspection is tedious but trivial.

http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Data.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Introspection on types.

[Gregory Propf]

Is there a way to tell, let's say, how many constructors there are for a type?  
Or do I need one of the haskell extensions I've read about?



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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[John Dorsey]

Andrew Coppin said:
>> Sure. But what is a computer program?

then Richard O'Keefe said:
> A computer program, in short, is *whatever we want it to be*.
> (Within reasonable limits.)

I agree with Richard's conclusion.

>From where I sit, the critical point is that, unless you're breadboarding,
programming is working in the abstract, and we choose our abstractions.
There's a strong tradition of sequential imperative programming, but that's
as far as it goes.

John

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Richard O'Keefe]

On Oct 2, 2009, at 11:14 AM, Richard O'Keefe wrote:


Human *verbalisation* is fundamental, human *thinking* is not.


Sigh.  Accidentally lean on the wrong key and half your text disappears.

Human *verbalisation* is fundamentally sequential.
Human *thinking* is not.

I don't know any sign language myself, but I am aware that since
people have faces and two hands, there is a limited amount of
concurrency in some sign languages.  (E.g., you can give place
and manner at the same time.)

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Richard O'Keefe]

On Oct 1, 2009, at 9:26 PM, Andrew Coppin wrote:
It might be a better argument to say that human thinking is  
fundamentally sequential; parallel computers have been around for a  
little while now...


You've never been talking on the phone while stirring a pot with one  
hand

and wiping down a child with the other?

You've never read (part of) a book while watching a TV program and  
been able

to summarize both afterwards?

You've never played the piano while talking about something else?

Human *verbalisation* is fundamental, human *thinking* is not.

(It's not unboundedly parallel either.)

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Richard O'Keefe]

On Oct 1, 2009, at 8:53 PM, Andrew Coppin wrote:


Sure. But what is a computer program?


It depends on the computer.  Classical machines do one thing,
data flow machines do another, reduction machines another.
I once saw a tiny machine at a UK university where the hardware
was a combinator reduction gadget.  It wasn't combinators on top
of conventional instructions, the hardware did nothing _but_
combinators.

A computer program, in short, is *whatever we want it to be*.
(Within reasonable limits.)

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

[Haskell-cafe] DSL and GUI Toolkits

[Günther Schmidt]

Hi,

I managed to abstract parts of the business logic of my application by  
employing a very naive DSL and it actually worked quite well. I'll  
probably replace that with a "Finally Tagless" version, just for the sake  
of it.


But now I'd really try to abstract the hard part, the GUI logic. I had  
been switching back and forth between wxHaskell and Gtk and eventually  
settled for wxHaskell. And my gui code is a huge mess, it works, for now,  
but it'd be hell if I even had to change the tiniest bit.


So I'm wondering if I could go the same way as with (parts) of the  
business logic, using a DSL here too.



Now I could do with some input on the merits of this approach.


Günther

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

Re: [Haskell-cafe] Can this be done?

[Tim Wawrzynczak]

I was poking around once trying to find something like that and stumbled
across this: http://wiki.cs.pdx.edu/forge/riviera.html

Cheers,
Tim

On Wed, Feb 11, 2009 at 8:22 AM, Cristiano Paris
wrote:

> I wonder whether this can be done in Haskell (see muleherd's comment):
>
>
> http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/
>
> Cristiano
> ___
> 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

Fwd: [Haskell-cafe] Can this be done?

[Alberto G. Corona]

You can do it almost transparently with  the Workflow package::
http://hackage.haskell.org/package/Workflow


2009/2/11 Cristiano Paris 

On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen 
> wrote:
> > I haven't looked at the details, but I think this is what a library like
> > Reactive from Conal Elliott could do, but as far as I understand it, it
> is
> > still work in progress.
>
> I'm interested in the possibility of
> stopping/pickling/unpickling/resuming a computation.
>
> Cristiano
> ___
> 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] parsing error

[ShawnShawn]

Hi there, I am trying to write some code for parsing string in "p==>q" or 
"p&&&q" or "p|||r", something like this.But I have trouble in reading operator 
like"==>""|||"... how can I fix it? I attached my code file with the email.Can 
some one give me some hints to fix the error and run the code?Thank you in 
advance!!!

  
_
上Windows Live 中国首页，下载最新版Messenger！
http://www.windowslive.cn

assi3.lhs
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Roel van Dijk]

> In a short while, the package 'ls-usb' will be released.

I've just uploaded usb-id-database-0.4 and ls-usb-0.1:

http://hackage.haskell.org/package/usb-id-database-0.4
http://hackage.haskell.org/package/ls-usb-0.1

The utility ls-usb uses the usb package to detect all USB devices
connected to you system. It then displays them in a nice list. It
behaves very much like the existing utility lsusb and is meant more as
an example of using the usb package then as an actual program. Be sure
to run with elevated privileges if you want detailed information.

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

[Haskell-cafe] Re: a boring parser

[Anatoly Yakovenko]

so whats pretty cool is that I can traverse arbitrary data structures as  well:

data Tree a = Tree (Tree a) a (Tree a) | Bottom
deriving Show

left a = do
   make $ \ st -> do
  case(st) of
 (Bottom) -> eos
 (Tree left val right) ->
case (a < val) of
   True -> return $ (val, left)
   False -> noMatch

right a = do
   make $ \ st -> do
  case(st) of
 (Bottom) -> eos
 (Tree left val right) ->
case (a > val) of
   True -> return $ (val, right)
   False -> noMatch

eqT a = do
   make $ \ st -> do
  case(st) of
 (Bottom) -> eos
 (Tree _ val _) ->
case (a == val) of
   True -> return $ (val, st)
   False -> noMatch

search a = manyTill (left a <|> right a) (eqT a)

> run (search 5) $ Tree (Tree Bottom 1 Bottom) 3 (Tree Bottom 5 Bottom)
Right (([3],5),Tree Bottom 5 Bottom)



On Wed, Sep 30, 2009 at 8:04 PM, Anatoly Yakovenko
 wrote:
> i got annoyed with Parsec and wrote a much more boring parser which
> allows me to parse anything with any kind of matching i want.  Its
> basically a combination of State and Error monads.
>
> So i can use a grep like parser that matches via a regular expression
> over a list of lines
>
> grep re = do
>   vv::B.ByteString <- any
>   let (_,_,_,rv) = (vv =~
> re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString])
>   case (rv) of
>      [] -> throwError "no match"
>      _ -> return $ rv
>
>> run (grep $ C.pack "(hello)") $ [C.pack "hello world"]
> Right (["hello"],[])
>
> or use the same library to scan over a string by combining regular expressions
>
> regex re = do
>   make $ \ st -> do
>      case (B.null st) of
>         True -> throwError "eos"
>         _ -> do
>            let (_,_,after,rv) = (st =~
> re)::(B.ByteString,B.ByteString,B.ByteString,[B.ByteString])
>            case (rv) of
>               [] -> throwError "no match"
>               _ -> return $ (rv,after)
>
>
>
>>  run (do aa <- regex $ C.pack "(hello)"; bb <- regex $ C.pack " (world)"; 
>> return (aa,bb) ) $ C.pack "hello world"
> Right ((["hello"],["world"]),"")
>
> or simply match integers in a list, or anything that is of type Eq
>
>> run (many1 $ eq 1) [1,1,1,2,3,4]
> Right ([1,1,1],[2,3,4])
>
> i can define lt
>
> lt cc = do
>   vv <- any
>   case (vv < cc) of
>      True -> return $ vv
>      _ -> throwError "no match"
>
> and do
>
>> run (many1 $ lt 5 <|> eq 5) [1..10]
> Right ([1,2,3,4,5],[6,7,8,9,10])
>
> here is the implementation
>
> module Parser( ParserM     --type alias for the parser ParserM a b is
> over "stream" a and returns b
>             , make        --makes a parser from a matching function of
> type :: stream -> m (match_data,stream)
>                           --for example any is implemented via:
>                           --any :: ParserM [a] a
>                           --any = make $ \ ll ->
>                           --   case (ll) of
>                           --         (hh:tt) -> return $ (hh,tt)
>                           --               _ -> throwError "eos
>                           --matches and returns an element from a
> list, which makes any of type :: ParserM [a] a
>             , any         --matches any element from [a] type stream
>             , eq          --matches an equal element from [Eq] stream,
> trivialy implemented in terms of any
>                           --eq :: Eq a => a -> ParserM [a] a
>                           --eq cc = do
>                           --   vv <- any
>                           --   case (vv == cc) of
>                           --      True -> return $ vv
>                           --         _ -> throwError "no match
>             , (<|>)       --or operator, tries the left one then the right one
>             , manyTill    --collects the results of parser 1 until
> parser 2 succeeds
>             , many1       --collects the results of the parser, must
> succeed at least once
>             , many        --collects the results of a parser
>             , run         --runs the parser
>             ) where
>
> import Control.Monad.State.Lazy
> import Control.Monad.Error
> import Test.QuickCheck
> import Control.Monad.Identity
> import Prelude hiding (any)
>
> type ParserM a c = StateT a (ErrorT [Char] Identity) c
>
> make pp = do
>   st <- get
>   (rv,nst) <- pp $ st
>   put $ nst
>   return $ rv
>
> aa <|> bb = aa `catchError` \ _ -> bb
>
> manyTill :: ParserM a c -> ParserM a d -> ParserM a ([c],d)
> manyTill pp ee = do
>   do dd <- ee
>      return $ ([],dd)
>   `catchError` \ _ -> do
>      cc <- pp
>      (ccs,dd) <- manyTill pp ee
>      return $ (cc:ccs,dd)
>
> many1 pp = do
>   rv <- pp
>   rest <- many1 pp `catchError` \ _ -> return $ []
>   return $ rv : rest
>
> many pp = do many1 pp
>         <|> return []
>
>
> any :: ParserM [a] a
> any = make $ \ ll ->
>   case (ll) of
>      (hh:tt) -> return $ (hh,tt)
>      _ -> throw

Re: [Haskell-cafe] New TMR editor

[Gwern Branwen]

On Thu, Oct 1, 2009 at 3:48 PM, Joe Fredette  wrote:
> Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener Pastures...

At least, less-frequently-released pastures!

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

Re: [Haskell-cafe] New TMR editor

[Joe Fredette]

Ah-- so _that's_ why you stopped doing HWN. Moving on to Greener  
Pastures...


:) Congrats Brent!

On Oct 1, 2009, at 3:44 PM, Brent Yorgey wrote:


On Thu, Oct 01, 2009 at 04:33:43PM +0200, Wouter Swierstra wrote:

Dear all,

After several years at the helm, I've decided to step down as  
editor of the

Monad.Reader.

I am happy to announce that Brent Yorgey will take over my role as  
editor.
I'd like to take this opportunity to thank Brent for helping to  
keep the

Monad.Reader alive. I'm sure he'll do a fantastic job.

Finally, I'd like to thank all the people who have contributed to the
Monad.Reader over the last few years – you guys have made this
publication, and my job as an editor, so much fun.


And let me be the first to thank Wouter for the outstanding job he's
done as editor!  I think he deserves much thanks for consistently
putting together such a high-quality publication.

I look forward to continuing the tradition of excellence -- and I hope
YOU, the author of an upcoming Monad.Reader article, do too!  I'll be
sending out a call for copy for the next issue soon.

-Brent
___
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] New TMR editor

[Brent Yorgey]

On Thu, Oct 01, 2009 at 04:33:43PM +0200, Wouter Swierstra wrote:
> Dear all,
>
> After several years at the helm, I've decided to step down as editor of the 
> Monad.Reader.
>
> I am happy to announce that Brent Yorgey will take over my role as editor. 
> I'd like to take this opportunity to thank Brent for helping to keep the 
> Monad.Reader alive. I'm sure he'll do a fantastic job.
>
> Finally, I'd like to thank all the people who have contributed to the 
> Monad.Reader over the last few years – you guys have made this 
> publication, and my job as an editor, so much fun.

And let me be the first to thank Wouter for the outstanding job he's
done as editor!  I think he deserves much thanks for consistently
putting together such a high-quality publication.

I look forward to continuing the tradition of excellence -- and I hope
YOU, the author of an upcoming Monad.Reader article, do too!  I'll be
sending out a call for copy for the next issue soon.

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

Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!

[John Van Enk]

>
> Ohhh, if you're dealing with pointers to CSize then it's easy, c2hs
> supports that directly. See the c2hs user guide section on the pointer
> hook.
>
> {# pointer *size_t as CSizePtr -> CSize #}
>
>
I seriously should have thought of that. I have #pointer's everywhere, but I
didn't think to do it with that. Thanks.

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

Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!

[Duncan Coutts]

On Thu, 2009-10-01 at 13:00 -0400, John Van Enk wrote:
> Hi Duncan,
> 
> Yes, I forgot to leave out that I'd like to see 'size_t' mapped to
> CSize.
> 
> As a (dirty) workaround, one can use 'castPtr' as the marshaler when
> dealing with pointers to 'size_t'. I'm a little more concerned about
> FunPtr's (though 'castPtr' still makes the issue go away).
> 
> Here's my specific case dealing with function pointers:

Ohhh, if you're dealing with pointers to CSize then it's easy, c2hs
supports that directly. See the c2hs user guide section on the pointer
hook.

{# pointer *size_t as CSizePtr -> CSize #}

This tells c2hs that when it sees a *size_t type in a function argument
or result that it should be imported as Ptr CSize.

It generates a type alias and uses that when it imports functions eg:

{# pointer *size_t as CSizePtr -> CSize #}

foo :: Ptr CSize -> IO ()
foo = {# call foo as raw_foo #}

generates:

type CSizePtr = Ptr (CSize)

foo :: Ptr CSize -> IO ()
foo = raw_foo

foreign import ccall safe "foo.chs.h foo"
  raw_foo :: CSizePtr -> IO ()


Duncan

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

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Bas van Dijk]

2009/10/1 Maurí­cio CA :
> Meanwhile, I'll be uploading as soon as
> possible new versions...

Thanks Mauricio,

I've uploaded usb-0.1.0.1 that now depends on the fixed bindings-libusb-1.2.

http://hackage.haskell.org/package/usb-0.1.0.1

regards,

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

Re: [Haskell-cafe] Haskell for Physicists

[Paul Johnson]

I can't help with the title, but you might show how Haskell can help 
avoid the subtle bugs that create erroneous results.  Start with the 
dimensional library (http://hackage.haskell.org/package/dimensional).


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

[Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Maurí­cio CA]

>>> At least the following packages suffer from this problem:
>>> bindings-common bindings-libusb bindings-posix

> Most .tar files contain entries for the directories that
> precede the entries for the files. This is only by convention
> however. It looks like this tar file has an entry for
> "src/Bindings/SomeFile.hs" without any preceding entries for
> "src/AnotherFile" or for the directory itself "src/Bindings/".

Thanks for the tip. I used Mercurial archive to create those tars:

  hg archive -t tgz -p 'bindings-common-1.1' ~/bindings-common-1.1.tar.gz

I'll check if this is known in Mercurial, specially the weird
output got from 7zip. Meanwhile, I'll be uploading as soon as
possible new versions of those packages with

  runhaskell Setup.hs sdist

Best,
Maurício

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

Re: [Haskell-cafe] c2hs, size_t, and CSize -- argh!

[John Van Enk]

Hi Duncan,

Yes, I forgot to leave out that I'd like to see 'size_t' mapped to CSize.

As a (dirty) workaround, one can use 'castPtr' as the marshaler when dealing
with pointers to 'size_t'. I'm a little more concerned about FunPtr's
(though 'castPtr' still makes the issue go away).

Here's my specific case dealing with function pointers:

In 64bit world, it looks like this:
type ReadableCallback = Ptr () -> Ptr CUChar -> *Ptr CULong* -> IO CUInt
{#fun gcry_ac_io_init_readable_callback {
id `ACIO',
id `FunPtr ReadableCallback',
id `Ptr ()'
} -> `()'#}

In 32bit world, it looks like this:
type ReadableCallback = Ptr () -> Ptr CUChar -> *Ptr CUInt* -> IO CUInt
{#fun gcry_ac_io_init_readable_callback {
id `ACIO',
id `FunPtr ReadableCallback',
id `Ptr ()'
} -> `()'#}

I'd really like it if I could use 'Ptr CSize' (which corresponds to the
'size_t * ptr' in the C code).

My current workaround (which doesn't use a cast in Haskell) is to redefine
the function pointer type in a C header file to use 'unsigned long' instead
of 'size_t', but this gets cludgy in a hurry. If c2hs could translate to
CSize directly, I could pass a pointer to CSize.

Is it really such a problem to make the conversion? My assumption is that
CSize would match 'size_t' for the specific architecture.

Thanks for your comment.

/jve


On Thu, Oct 1, 2009 at 12:37 PM, Duncan Coutts  wrote:

> On Thu, 2009-10-01 at 10:20 -0400, John Van Enk wrote:
> > Hello List,
> >
> > I'm running into a problem with c2hs and how it parses the C typedef
> > 'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On
> > 64bit systems, this ends up as a CULong. This gets especially sticky
> > with function pointers.
>
> Right. Of course that's because on those different platforms size_t
> really is a typedef for unsigned int or unsigned long.
>
> > I see there is a ticket open for this:
> > http://hackage.haskell.org/trac/c2hs/ticket/20
> >
> > Has any one else run into this issue? Is there a good workaround that
> > doesn't involve writing a C function/typedef for each collision?
>
> So what you would want, presumably, is to map the "size_t" typedef to
> the Haskell type Foreign.C.Types.CSize, rather than what c2hs discovers
> as the actual raw type of "size_t". Then you're making the promise that
> unsigned long, or unsigned int really really does match
> Foreign.C.Types.CSize.
>
> Currently c2hs has no support for remapping basic types like that.
>
> As for a workaround, just use fromIntegral to convert to CSize. You know
> this is always possible because you know CSize matches CUInt or CULong
> on the appropriate platforms.
>
> $ cat foo.h
> #include 
> size_t foo(void);
>
> $ cat foo.c
> #include "foo.h"
> size_t foo(void) { return 42; }
>
> $ cat foo.chs
>
> import Foreign.C.Types
> foo :: IO CSize
> foo = fmap fromIntegral {# call foo as bar #}
>
> $ gcc -c foo.c
> $ c2hs foo.h foo.chs
> $ ghci foo.hs -fffi foo.o
> Main> foo
> 42
>
>
> Duncan
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Splitting data and function declarations over multiple files

[Job Vranish]

Opps, errors, it should be more like:

moveBall (Vector2 x y) (Ball ...) = ...
movePaddle (Vector2 x y) (Paddle ...) = ...

-- selection actions for Ball
instance Actor Ball where
  mkActor this = let
pos' = getBallPosition this
move' v = mkActor $ moveBall v this
in Actor pos' move'

-- selection actions for Paddle
instance Actor Paddle where
  mkActor this = let
pos' = getPaddlePosition this
move' v = mkActor $ movePaddle v this
in Actor pos' move'


Hmm, I bet some generics, or template haskell could clean up the extra
boilerplate associated with this technique.

- Job


On Thu, Oct 1, 2009 at 11:35 AM, Job Vranish  wrote:

> Along the projection/co-algebra lines (I actually didn't know that's what
> they were called until today :)  yay for learning new things!)
>
> How about something like this:
>
> -- Define "prototypes" for your class of actions here
> data Actor = Actor {pos::Vector2 Float, move::Vector2 Float -> Actor}
>
> -- simple class that selects your actions based on type
> class ActorClass a where
>   mkActor :: a -> Actor
>
> -- object types
> data Ball = Ball ...  -- stuff
> data Paddle = Paddle ... -- stuff
> data Wall = Wall ... -- suff
>
> -- Functions for working with objects
> getBallPosition (Ball ...) = ...
> getPaddlePosition (Paddle ...) = ...
>
> moveBall (Ball ...) = ...
> movePaddle (Ball ...) = ...
>
> -- selection actions for Ball
> instance Actor Ball where
>   mkActor this = let
> pos' = getBallPosition this
> move' v = moveBall this
> in Actor pos' move'
>
> -- selection actions for Paddle
> instance Actor Paddle where
>   mkActor this = let
> pos' = getPaddlePosition this
> move' v = movePaddle this
> in Actor pos' move'
>
>
> Base off a technique I ran across here:
> http://www.mail-archive.com/hask...@haskell.org/msg04513.html
>
> Also, a useful wikipage for doing OO things in haskell:
> http://www.haskell.org/haskellwiki/OOP_vs_type_classes
>
> - Job
>
>
> On Thu, Oct 1, 2009 at 4:45 AM, Peter Verswyvelen wrote:
>
>> I'm not sure if I understand what you mean with this co-algebraic
>> approach, but I guess you mean that functions - like move - don't work
>> directly on any datatype; you need to provide other functions that give
>> access to the data. But that's basically what type classes do no? And that's
>> also related to my earlier post of "strong duck typing" in Haskell.
>> At least also in C#, that's the way I usually write code that works on any
>> type, just make an interface or pass in a delegate.  I also know that my OO
>> background keeps pushing me in the wrong direction when it comes to Haskell
>> ;-)
>>
>> The collision handling approach is always interesting :)  In OO this is
>> usually solved using multi-methods or visitors:
>> http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
>> games of mine to handle collisions is not look at the type, but at the
>> "collision specific features" of a type (which are again functions that
>> extract information from the object), and that is most likely again the
>> co-algebraic approach?
>>
>> On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer  wrote:
>>
>>> On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen 
>>> wrote:
>>> > I guess this is related to the expression problem.
>>> > Suppose I have a datatype
>>> > data Actor = Ball ... | Paddle ... | Wall ...
>>> > and a function
>>> > move (Ball ...) =
>>> > move (Paddle ...) =
>>> > move (Wall ...) =
>>> > in Haskell one must put Actor and move into a single file.
>>> > This is rather cumbersome if you work with multiple people or want to
>>> keep
>>> > the files small and readable.
>>> > Surely it is possible to use type classes, existentials, etc to split
>>> the
>>> > data type into multiple ones, but that's already advanced stuff in a
>>> sense.
>>>
>>> You can do it without type classes and existentials.  The
>>> functionality you want is already supported by Haskell, you just have
>>> to let go of your syntactical expectations.  The trick is that you
>>> should rewrite your data type not as an algebra (a set of
>>> constructors), but as a coalgebra (a set of projections).
>>>
>>> Let's say your two open functions are:
>>>
>>> move :: Actor -> Actor
>>> isAlive :: Actor -> Bool
>>>
>>> This gives rise to the definition of an Actor type:
>>>
>>> data Actor = Actor { move :: Actor, isAlive :: Bool }
>>>
>>> And then the alternatives of your open data type are just values of type
>>> Actor:
>>>
>>> ball :: Vector -> Vector -> Actor
>>> ball pos vel = Actor {
>>>move = ball (pos + vel) vel,
>>>isAlive = True
>>>  }
>>>
>>> etc.
>>>
>>> This trick works well until you get to the encoding of functions that
>>> pattern match on multiple Actors at the same time.  As far as I can
>>> tell, that cannot be encoded in this style in any reasonable way.
>>> Such functions must be rephrased in a coalgebraic style; i.e. instead
>>> of asking about constructors, using projection functions it knows are
>>> a

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1

[Jonathan Daugherty]

# Nice.  This sure beats how I've been doing it in the past.  Out of
# curiousity, can you talk about what you're doing with it?

Yeah, I'd like to use this to write an administration tool for my
"dbmigrations" package.  I started doing it in hscurses and decided I
needed to be able to live with the code (and the process of writing
it), so now I'm off in the weeds working on a UI library. :)

On the way to work this morning I started working on a Scrollable
class to generalize the List's scrolling capabilities and support
scrolling of any widget rendered in constrained space.  We'll see how
that goes..

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

Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Alberto G. Corona]

May be because consciousness is relatively new and thus, not optimized.
Sequentiallity is somehow related with lack of information and lack or
resources. There is nothing more sequential than a Turing machine. The Von
Newman architecture is designed to make as much as possible with  a few more
resources. The older parts of the brain are fast and parallel because they
have a long history of optimizations by natural selection., The new cortex
still struggles, step by step, to deduce new information from the available
internal and external information at the pace they arrive.


2009/10/1 Tom Tobin 

On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
>  wrote:
> > It might be a better argument to say that human thinking is fundamentally
> > sequential; parallel computers have been around for a little while now...
>
> Perhaps *conscious* human thinking is sequential — yet our brains are
> massively parallel processors, and have been around for quite a long
> time.  ;-)
> ___
> 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] c2hs, size_t, and CSize -- argh!

[Duncan Coutts]

On Thu, 2009-10-01 at 10:20 -0400, John Van Enk wrote:
> Hello List,
> 
> I'm running into a problem with c2hs and how it parses the C typedef
> 'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On
> 64bit systems, this ends up as a CULong. This gets especially sticky
> with function pointers.

Right. Of course that's because on those different platforms size_t
really is a typedef for unsigned int or unsigned long.

> I see there is a ticket open for this:
> http://hackage.haskell.org/trac/c2hs/ticket/20
> 
> Has any one else run into this issue? Is there a good workaround that
> doesn't involve writing a C function/typedef for each collision?

So what you would want, presumably, is to map the "size_t" typedef to
the Haskell type Foreign.C.Types.CSize, rather than what c2hs discovers
as the actual raw type of "size_t". Then you're making the promise that
unsigned long, or unsigned int really really does match
Foreign.C.Types.CSize.

Currently c2hs has no support for remapping basic types like that.

As for a workaround, just use fromIntegral to convert to CSize. You know
this is always possible because you know CSize matches CUInt or CULong
on the appropriate platforms.

$ cat foo.h
#include 
size_t foo(void);

$ cat foo.c
#include "foo.h"
size_t foo(void) { return 42; }

$ cat foo.chs

import Foreign.C.Types
foo :: IO CSize
foo = fmap fromIntegral {# call foo as bar #}

$ gcc -c foo.c
$ c2hs foo.h foo.chs
$ ghci foo.hs -fffi foo.o
Main> foo
42


Duncan

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Andrew Coppin]

Tom Tobin wrote:

On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
 wrote:
  

It might be a better argument to say that human thinking is fundamentally
sequential; parallel computers have been around for a little while now...



Perhaps *conscious* human thinking is sequential — yet our brains are
massively parallel processors, and have been around for quite a long
time.  ;-)
  


This is very true. And it's just as well; I read somewhere that the 
maximum firing rate of a neuron gives the human brain an effective 
"clock frequency" of about 100 MHz - which isn't terribly fast. But it's 
massively parallel, as you say.


Actually, I just had a flash of inspiration: Maybe the reason 
programmers tend to think sequentially is because programmers tend to be 
*men*. Maybe the way to hardness the multicores is to get more women 
into programming? :-D


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

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Duncan Coutts]

On Thu, 2009-10-01 at 16:22 +0200, Martijn van Steenbergen wrote:
> Roel van Dijk wrote:
> > Yes, that happens. I don't now the cause but the work-around is easy.
> > Simply download the package manually from hackage, unpack and install
> > using cabal.
> > 
> > At least the following packages suffer from this problem:
> >   bindings-common
> >   bindings-libusb
> >   bindings-posix
> > 
> > Perhaps Maurí­cio can shed some light on this.
> 
> That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll 
> see if I can find if it's been reported before.

I suspect it is a bug in the tar code (a copy of which is used in
cabal-install).

Most .tar files contain entries for the directories that precede the
entries for the files. This is only by convention however. It looks like
this tar file has an entry for "src/Bindings/SomeFile.hs" without any
preceding entries for "src/AnotherFile" or for the directory itself
"src/Bindings/".

The bug is that while the tar code would create the "src/" directory for
a file entry "src/AnotherFile", it would not create the "src/" directory
for "src/Bindings/SomeFile.hs", just try to create the "src/Bindings"
directroy, which then fails since "src/" does not yet exist.

I was trying to avoid making all parent directories in a fully recursive
way. In particular I don't want it to make the target root directory if
it did not already exist. I guess it should at least make the
directories between the target root and the directory containing the
file to be unpacked.

If someone wants to make a patch for this then please do it against the
tar package code:

darcs get http://code.haskell.org/tar/

Note that tar files constructed using cabal sdist should not have this
particular problem due to the order of entries within the archive.

Duncan

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

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Henk-Jan van Tuyl]

The file bindings-common.tar.gz looks a bit odd: when I unpack it with  
7Zip, I get the path:

  
bindings-common-1.1.tar.gz\\home\mauricio\bindings-common-1.1.tar.gz\bindings-common-1.1\
(first part deleted)

Met vriendelijke groet,
Henk-Jan van Tuyl


--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--


On Thu, 01 Oct 2009 16:12:21 +0200, Roel van Dijk   
wrote:



Yes, that happens. I don't now the cause but the work-around is easy.
Simply download the package manually from hackage, unpack and install
using cabal.

At least the following packages suffer from this problem:
  bindings-common
  bindings-libusb
  bindings-posix

Perhaps Maurício can shed some light on this.

Groetjes,
Roel

On Thu, Oct 1, 2009 at 4:02 PM, Martijn van Steenbergen
 wrote:

Bas van Dijk wrote:


Comments and patches are highly welcome.


I tried to install on my Mac but bindings-common choked on:


cabal install bindings-common

Resolving dependencies...
cabal: Error: some packages failed to install:
bindings-common-1.1 failed while unpacking the package. The exception  
was:

/var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings:
createDirectory: does not exist (No such file or directory)

Not sure if this is interesting to you, Bas, but I thought I'd share.  
:-)


Groetjes,

Martijn.

___


--

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Tom Tobin]

On Thu, Oct 1, 2009 at 3:26 AM, Andrew Coppin
 wrote:
> It might be a better argument to say that human thinking is fundamentally
> sequential; parallel computers have been around for a little while now...

Perhaps *conscious* human thinking is sequential — yet our brains are
massively parallel processors, and have been around for quite a long
time.  ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Market Place for Haskell development teams?

[Curt Sampson]

On 2009-09-29 13:18 +0200 (Tue), Alberto G. Corona  wrote:

> What is the vehicle that haskell can use to enter the mainstream?.

Actually, I have one more thought on that: wait.

I'd had the impression that Haskell was becoming fairly well known (if
not yet heavily used, in comparison to languages like Java), but I just
ran across some hard evidence for this.

In the 32 languages ranked on http://www.langpop.com/ , Haskell
consistently comes down near the bottom in the various rankings of
use. (But hey, we're not so weird we're not in there!) But if you look
down near the bottom, at the chart labeled "Normalized Discussion Site
Results," you'll notice that Haskell comes out sixth. Even trying to be
more fair to the mainstream, and changing the weighting to drop Lambda
the Ultimate completely (after all, they're just a bunch of academic
wankers, right?) and bring IRC down to a contribution of 0.5 instead of
1 (apparently those academic wankers have lots of time to chat online),
Haskell still comes out tenth, with a score over a third that of the
leader, Java, and close to half that of PHP and C (2nd and 3rd place,
respectively).

We've also got at least one undeniably good, production-quality compiler
(which is more than PHP or Ruby can say), and have sold many tens of
thousands, perhaps even hundreds of thousands, of books. At this point,
I don't think many people (John A. De Goes excepted) are looking at
people writing major applications in Haskell as if they're aliens living
on another planet.

Haskell is in the mainstream already as far as being taken seriously;
most of the complaints I'm seeing seem to be grasping at the same kinds
of straws that the anti-Java guys were back in the late '90s. ("It's
hopeless if it uses garbage collection.")

We've even got our own over-hyped, under-utilized supposed benefit
("it's good for multicore").

The main whinging seems to be about libraries, of which we have "only"
1585 on hackage.

Compare with RubyForge, which has 2059 projects in "beta" or better
status, or 2961 if we include "alpha" as well. The Ruby Application
Archive has 1768 projects; I have no idea how much overlap there is, or
how many of these are real.

I think we just need to sit tight for a couple of years.

cjs
-- 
Curt Sampson   +81 90 7737 2974
   Functional programming in all senses of the word:
   http://www.starling-software.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Splitting data and function declarations over multiple files

[Job Vranish]

Along the projection/co-algebra lines (I actually didn't know that's what
they were called until today :)  yay for learning new things!)

How about something like this:

-- Define "prototypes" for your class of actions here
data Actor = Actor {pos::Vector2 Float, move::Vector2 Float -> Actor}

-- simple class that selects your actions based on type
class ActorClass a where
  mkActor :: a -> Actor

-- object types
data Ball = Ball ...  -- stuff
data Paddle = Paddle ... -- stuff
data Wall = Wall ... -- suff

-- Functions for working with objects
getBallPosition (Ball ...) = ...
getPaddlePosition (Paddle ...) = ...

moveBall (Ball ...) = ...
movePaddle (Ball ...) = ...

-- selection actions for Ball
instance Actor Ball where
  mkActor this = let
pos' = getBallPosition this
move' v = moveBall this
in Actor pos' move'

-- selection actions for Paddle
instance Actor Paddle where
  mkActor this = let
pos' = getPaddlePosition this
move' v = movePaddle this
in Actor pos' move'


Base off a technique I ran across here:
http://www.mail-archive.com/hask...@haskell.org/msg04513.html

Also, a useful wikipage for doing OO things in haskell:
http://www.haskell.org/haskellwiki/OOP_vs_type_classes

- Job


On Thu, Oct 1, 2009 at 4:45 AM, Peter Verswyvelen  wrote:

> I'm not sure if I understand what you mean with this co-algebraic approach,
> but I guess you mean that functions - like move - don't work directly on any
> datatype; you need to provide other functions that give access to the data.
> But that's basically what type classes do no? And that's also related to my
> earlier post of "strong duck typing" in Haskell.
> At least also in C#, that's the way I usually write code that works on any
> type, just make an interface or pass in a delegate.  I also know that my OO
> background keeps pushing me in the wrong direction when it comes to Haskell
> ;-)
>
> The collision handling approach is always interesting :)  In OO this is
> usually solved using multi-methods or visitors:
> http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
> games of mine to handle collisions is not look at the type, but at the
> "collision specific features" of a type (which are again functions that
> extract information from the object), and that is most likely again the
> co-algebraic approach?
>
> On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer  wrote:
>
>> On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen 
>> wrote:
>> > I guess this is related to the expression problem.
>> > Suppose I have a datatype
>> > data Actor = Ball ... | Paddle ... | Wall ...
>> > and a function
>> > move (Ball ...) =
>> > move (Paddle ...) =
>> > move (Wall ...) =
>> > in Haskell one must put Actor and move into a single file.
>> > This is rather cumbersome if you work with multiple people or want to
>> keep
>> > the files small and readable.
>> > Surely it is possible to use type classes, existentials, etc to split
>> the
>> > data type into multiple ones, but that's already advanced stuff in a
>> sense.
>>
>> You can do it without type classes and existentials.  The
>> functionality you want is already supported by Haskell, you just have
>> to let go of your syntactical expectations.  The trick is that you
>> should rewrite your data type not as an algebra (a set of
>> constructors), but as a coalgebra (a set of projections).
>>
>> Let's say your two open functions are:
>>
>> move :: Actor -> Actor
>> isAlive :: Actor -> Bool
>>
>> This gives rise to the definition of an Actor type:
>>
>> data Actor = Actor { move :: Actor, isAlive :: Bool }
>>
>> And then the alternatives of your open data type are just values of type
>> Actor:
>>
>> ball :: Vector -> Vector -> Actor
>> ball pos vel = Actor {
>>move = ball (pos + vel) vel,
>>isAlive = True
>>  }
>>
>> etc.
>>
>> This trick works well until you get to the encoding of functions that
>> pattern match on multiple Actors at the same time.  As far as I can
>> tell, that cannot be encoded in this style in any reasonable way.
>> Such functions must be rephrased in a coalgebraic style; i.e. instead
>> of asking about constructors, using projection functions it knows are
>> available.
>>
>> So for example instead of implementing "collide" by asking about
>> pairs, add functions which report a shape function and a normal, or
>> whatever your collide algorithm needs from shapes.
>>
>> You would probably end up having to do this anyway even with your
>> proposed extension, because watch:
>>
>> partial data Actor = Ball ...
>>
>> collide (Ball ...) (Ball ...) = ...
>> collide (Ball ...) x = ...
>>
>> We don't know about any other constructors, so the second line has to
>> contain a pattern-free x.  So you would have to use projection
>> functions to get any information about it, exactly as you would when
>> you're writing in the coalgebraic style.
>>
>> So, Yes!  Haskell can do that!
>>
>> Luke
>>
>
>
> ___
> Haskell-Cafe mailing lis

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1

[Magnus Therning]

On Thu, Oct 1, 2009 at 4:23 PM, Jonathan Daugherty  wrote:
>> Am I correct in saying that the collection of widgets contains a
>> single widget type so far?  ;-)
>
> Technically, four; vertical and horizontal boxes, a text string
> widget, and the List you mentioned.  It only has a few types because I
> was just releasing early.  I'm going to start using this in a project
> and add things as needed.

Nice.  This sure beats how I've been doing it in the past.  Out of
curiousity, can you talk about what you're doing with it?

>> The list widget looks useful, does it handle multi-line strings (i.e.
>> strings with a "\n")?
>
> It currently only handles single-line strings but I'd actually like to
> generalize it to take a list of Widget instances (possibly with
> restrictions).

Very nice.

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1

[Jonathan Daugherty]

> Am I correct in saying that the collection of widgets contains a
> single widget type so far?  ;-)

Technically, four; vertical and horizontal boxes, a text string
widget, and the List you mentioned.  It only has a few types because I
was just releasing early.  I'm going to start using this in a project
and add things as needed.

> The list widget looks useful, does it handle multi-line strings (i.e.
> strings with a "\n")?

It currently only handles single-line strings but I'd actually like to
generalize it to take a list of Widget instances (possibly with
restrictions).

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

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1

[Magnus Therning]

On Wed, Sep 30, 2009 at 5:35 AM, Jonathan Daugherty  wrote:
> vty-ui is:
>
> An extensible library of user interface widgets for composing and
> laying out Vty user interfaces. This library provides a collection of
> widgets and a type class for rendering widgets to Vty Images.

Am I correct in saying that the collection of widgets contains a
single widget type so far?  ;-)

What are the plans for adding widgets in the future?

The list widget looks useful, does it handle multi-line strings (i.e.
strings with a "\n")?

/M

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org  Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Alberto G. Corona]

;)
Off topic:

Maybe the entire space time,  the universe and his history, is isomorphic to
a mathematical structure.

http://space.mit.edu/home/tegmark/toe_frames.html


2009/10/1 Peter Verswyvelen 

>
>
> On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin  > wrote:
>
>> Sure. But what is a computer program? It's a *list of instructions* that
>> tells a computer *how to do something*. And yet, the Haskell definition of
>> sum looks more like a definition of what a sum is rather than an actual,
>> usable procedure for *computing* that sum. (Of course, we know that it /is/
>> in fact executable... it just doesn't look it at first sight.)
>>
>
> Is it? The list of instruction is just an abstraction layer built on top of
> purely physical process of electrons and transistors; I'm not sure how much
> imperativeness remains at this level? Not to mention the quantum mechanical
> processes that take place... And that are also just mathematical models... I
> mean, it really depends from which angle and at which detail you look at it,
> no?
>
>
> ___
> 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] river crossing puzzle

[Bas van Gijzel]

Or you could look at my blog posts describing the implementation of the
Cannibals and Missionaries variant step by step.
First a naive approach and secondly using a state monad solution.

http://adoseoflogic.blogspot.com/2009/07/cannibals-missionaries-and-state-monad.html

Cheers,

Bas

2009/9/28 pat browne 

> Hi,
> Does anyone know where there are any Haskell implementations of the the
> River Crossing  puzzle (AKA Farmer/Fox/Goose/Grain).
> There are several variations but the general ideas are explained at:
> http://en.wikipedia.org/wiki/River_crossing_puzzle
> http://en.wikipedia.org/wiki/Fox,_goose_and_bag_of_beans_puzzle
>
> I have found one at:
> http://www.shido.info/hs/haskell9.html
>
>
> Thanks,
> Pat
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] New OpenGL package: efficient way to convert datatypes?

[Jeff Heard]

Ah, but it takes care of my performance problems, so many thanks from
the lurker :-)

-- Jeff

On Wed, Sep 30, 2009 at 11:37 PM, wren ng thornton  wrote:
> wren ng thornton wrote:
>>>
>>> I guess one could make rules for that, but this tickets makes me wander
>>> if
>>> that really works:
>>> http://hackage.haskell.org/trac/ghc/ticket/1434
>>
>> The RealToFrac class solves Henning's performance complaint as well.
>
>
> Er, I misread his performance problems. The logfloat package doesn't offer
> any particular support for rounding to integral types.
>
> --
> 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] New TMR editor

[Wouter Swierstra]

Dear all,

After several years at the helm, I've decided to step down as editor  
of the Monad.Reader.


I am happy to announce that Brent Yorgey will take over my role as  
editor. I'd like to take this opportunity to thank Brent for helping  
to keep the Monad.Reader alive. I'm sure he'll do a fantastic job.


Finally, I'd like to thank all the people who have contributed to the  
Monad.Reader over the last few years – you guys have made this  
publication, and my job as an editor, so much fun.


All the best,

  Wouter

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

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Roel van Dijk]

> That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll see
> if I can find if it's been reported before.

I meant a manual unpack: tar xvf bindings-common-1.1.tar.gz

But it is indeed odd.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Martijn van Steenbergen]

Roel van Dijk wrote:

Yes, that happens. I don't now the cause but the work-around is easy.
Simply download the package manually from hackage, unpack and install
using cabal.

At least the following packages suffer from this problem:
  bindings-common
  bindings-libusb
  bindings-posix

Perhaps Maurí­cio can shed some light on this.


That's odd, even cabal unpack fails. Smells like a cabal bug. :-) I'll 
see if I can find if it's been reported before.


Martijn.

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

[Haskell-cafe] c2hs, size_t, and CSize -- argh!

[John Van Enk]

Hello List,

I'm running into a problem with c2hs and how it parses the C typedef
'size_t'. On 32bit systems, this ends up being parsed as a CUInt. On 64bit
systems, this ends up as a CULong. This gets especially sticky with function
pointers.

In order to make bindings with c2hs that work across the different word
sizes, I have to write an indirection layer in C that defines wrappers for
functions or re-defines typedef's for function pointers to include 'unsigned
long' instead of 'size_t'.

I see there is a ticket open for this:
http://hackage.haskell.org/trac/c2hs/ticket/20

Has any one else run into this issue? Is there a good workaround that
doesn't involve writing a C function/typedef for each collision?

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Peter Verswyvelen]

On Thu, Oct 1, 2009 at 9:53 AM, Andrew Coppin
wrote:

> Sure. But what is a computer program? It's a *list of instructions* that
> tells a computer *how to do something*. And yet, the Haskell definition of
> sum looks more like a definition of what a sum is rather than an actual,
> usable procedure for *computing* that sum. (Of course, we know that it /is/
> in fact executable... it just doesn't look it at first sight.)
>

Is it? The list of instruction is just an abstraction layer built on top of
purely physical process of electrons and transistors; I'm not sure how much
imperativeness remains at this level? Not to mention the quantum mechanical
processes that take place... And that are also just mathematical models... I
mean, it really depends from which angle and at which detail you look at it,
no?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Roel van Dijk]

Yes, that happens. I don't now the cause but the work-around is easy.
Simply download the package manually from hackage, unpack and install
using cabal.

At least the following packages suffer from this problem:
  bindings-common
  bindings-libusb
  bindings-posix

Perhaps Maurí­cio can shed some light on this.

Groetjes,
Roel

On Thu, Oct 1, 2009 at 4:02 PM, Martijn van Steenbergen
 wrote:
> Bas van Dijk wrote:
>>
>> Comments and patches are highly welcome.
>
> I tried to install on my Mac but bindings-common choked on:
>
>> cabal install bindings-common
> Resolving dependencies...
> cabal: Error: some packages failed to install:
> bindings-common-1.1 failed while unpacking the package. The exception was:
> /var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings:
> createDirectory: does not exist (No such file or directory)
>
> Not sure if this is interesting to you, Bas, but I thought I'd share. :-)
>
> Groetjes,
>
> Martijn.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] ANNOUNCE: usb-0.1

[Martijn van Steenbergen]

Bas van Dijk wrote:

Comments and patches are highly welcome.


I tried to install on my Mac but bindings-common choked on:

> cabal install bindings-common
Resolving dependencies...
cabal: Error: some packages failed to install:
bindings-common-1.1 failed while unpacking the package. The exception was:
/var/folders/mR/mRFqQvztFo0URT0d6GN9wE+++TI/-Tmp-/bindings-common-1.174967/bindings-common-1.1/src/Bindings:
createDirectory: does not exist (No such file or directory)

Not sure if this is interesting to you, Bas, but I thought I'd share. :-)

Groetjes,

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

[Haskell-cafe] ANNOUNCE: usb-0.1

[Bas van Dijk]

Hello,

I would like to announce the release of usb-0.1, a Haskell library for
communicating with USB devices from userspace.

usb is implemented as a high-level wrapper around Maurício C. Antunes'
bindings-libusb which is a binding to the C library: libusb-1.* (
http://libusb.org ).

All functionality from libusb is provided except for asynchronous IO.
I'm still thinking about if and how I should add that.

As usual, install usb using cabal:

> cabal install usb

Or download and install it manually from hackage:

http://hackage.haskell.org/package/usb-0.1

Or get the development source using darcs:

darcs get http://code.haskell.org/~basvandijk/code/usb

Comments and patches are highly welcome.

Note that this is the first release, so expect API changes in the future.

Note that my brother uploaded 'usb-id-database' to hackage. A small
library for associating usb identifiers like vendor, product, class,
subclass or prototcol identifiers with their respective names and vice
versa:

http://hackage.haskell.org/package/usb-id-database

This can be helpful when trying to find the right device to operate.

In a short while, the package 'ls-usb' will be released. This is a
simple program for showing all the usb devices currently attached to
your system. It's a nice demonstration on how to use the library.

regards,

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

Re: [Haskell-cafe] Exceptions during exception unwinding

[Brian Bloniarz]

Sorry for the garbled post, this should hopefully be plain text:

> On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote:
>> I.e. why does an exception raised during exception handling get
>> propagated past the exception that triggered the handler?
>
> Because it's the obvious and sensible thing to do and it what every
> other mainstream language with exceptions does. The behaviour you want,
> to automatically discard any exceptions raised in the handler and to
> always re-raise the original exception can be implemented using the
> current semantics, but the reverse is not true.

Good to know ... C++ (the mainstream language I'm most familiar
with) treats throwing from a destructor during unwinding as a fatal
error.

I was suggesting having bracket ignore exceptions from closeSomeHandle
when doAction threw, not that it'd ignore any exceptions from
closeSomeHandle.
 
It's only the case where bracket has 2 exceptions to choose from that's
ambiguous, and I'm saying that there's a fair amount of code
out there that'd prefer to see the first one. Your point about ^C gets us
into an even grayer area -- maybe code would prefer to propagate whichever
of the 2 exceptions is asynchronous, or define a criterion to choose which
exception is more serious, who knows.
 
All these behaviors are easy to implement using the building blocks that
Control.Exception exports right now, you're right. So I'm free to build
my own bracket variants with different behavior and that's what I'll do.
I was just wondering if the default behavior that bracket/onException
provide (which are themselves built from catch/block/unblock) is the one
that most people want.
 
Thanks,
-Brian

  
_
Microsoft brings you a new way to search the web.  Try  Bing™ now
http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try 
bing_1x1___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Exceptions during exception unwinding

[Brian Bloniarz]

 <1254389201.7656.3.ca...@localhost>
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> On Thu=2C 2009-10-01 at 03:29 +=2C Brian Bloniarz wrote:
>> I.e. why does an exception raised during exception handling get
>> propagated past the exception that triggered the handler?
>
> Because it's the obvious and sensible thing to do and it what every
> other mainstream language with exceptions does.

Good to know ... C++ (the mainstream language I'm most familiar
with) treats throwing from a destructor during unwinding as a fatal
error.

>>> bracket openSomeHandle closeSomeHandle doAction
> Then catch and ignore the exception from closeSomeHandle (though not all
> exceptions or you'd block ^C etc). That said=2C how will you know that
> closeSomeHandle ever works if you always ignore any exceptions it
> raises?

I was suggesting having bracket ignore exceptions from closeSomeHandle
when doAction threw=2C not that it'd ignore any exceptions from
closeSomeHandle.

It's only the case where bracket has 2 exceptions to choose from that's
ambiguous=2C and I'm saying that there's a fair amount of code
out there that'd prefer to see the first one. Your point about ^C gets us i=
nto
an even grayer area -- maybe code would prefer to propagate whichever of
the 2 exceptions is asynchronous=2C or define a criterion to choose which
exception is more serious=2C who knows.

All these behaviors are easy to implement using the building blocks that
Control.Exception exports right now=2C you're right. So I'm free to build
my own bracket variants with different behavior and that's what I'll do.
I was just wondering if the default behavior that bracket/onException
provide (which are themselves built from catch/block/unblock) is the one
that most people want.

Thanks=2C
-Brian
  =0A=
_=0A=
Microsoft brings you a new way to search the web.  Try  Bing=99 now=0A=
http://www.bing.com?form=3DMFEHPG&publ=3DWLHMTAG&crea=3DTEXT_MFEHPG_Core_ta=
gline_try bing_1x1=
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fwd: Uniplate + strict fields = fail. Why?

[Max Bolingbroke]

2009/10/1 Dmitry Astapov :
> Hi,
>
> I've been playing with generics in general (pardon the pun) and Uniplate in
> particular, and found out that strict data fields somehow derail Uniplate.

I think this is related to Neil's bug report about Ratio:
http://hackage.haskell.org/trac/ghc/ticket/2782

The issue is that the Data instance for your types is stricter than he
is expecting. I don't know enough about Uniplate to work out why he
can't tunnel the undefined's he's trying to send through Data by
hiding then within a box.

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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Alberto G. Corona]

2009/10/1 Curt Sampson 

> On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote:
>
> > Sure. But what is a computer program? It's a *list of instructions* that
> > tells a computer *how to do something*.
>
> Some are. Some aren't, as proven by the Haskell definition of sum, which
> is certainly a "program."
>
> I like to think of a program as a specification. A list of instructions
> can certainly qualify, but so can other things, depending on what's
> interpreting and executing that specification.
>
>


Lets say that how to do a sum is pure abstract knowledge,  and this
translates nicely to a declarative haskell sentence.

But to perform a sum of two concrete numbers is procedural, because either
the program or the compiler or yourself have to extract from the available
knowledge a  sequence of steps in order to obtain a new knowledge, that is ,
the  result.

In imperative languages the sequentiation  is more explicit. in functional
languages this is more implicit, because the compiler+ runtime do the
sequentiation.

In fact, a C compiler also perform an automatic sequentiation for this
simple operation and generates a sequence of assembler code for either a sum
or any mathematical expression, but the haskell compiler is way more
powerful for extracting sequences of steps from declarative statements.
moreover, haskell promote a declarative style because laziness avoid to
express abstract knowledge as sequences. Referential transparency avoid also
dependencies of expressions from other expressions, and thus avoids
artificial sequencing.

however every time the program has to interact with the external world, even
for printing the result,, sequencing is necessary. That´s why  the compilers
and interpreters exist!!!.

If the program has to interact many times with the external world in a given
sequence, the compiler can not guess such sequence if you don't write it
explicitly.

The perfect declarative  haskell program has no main, no IO monad and no
executable.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Any generic serializer to String? was: Any working example of using genericserialize?

[José Pedro Magalhães]

Hi Dimitry,

On Thu, Oct 1, 2009 at 05:23, Dimitry Golubovsky wrote:

> OK, I got it to work with gread/gshow.
>
> However I have noticed this:
>
> *Main> (gread $ gshow $ FuncExpr 0 [] (EmptyStmt 0)) :: [(Expression
> Int, String)]
> [(FuncExpr 0 [] (EmptyStmt 0),"")]
>
> vs.
>
> *Main> (gread $ gshow $ FuncExpr () [] (EmptyStmt ())) :: [(Expression
> (), String)]
> []
>
> Or even narrower:
>
> *Main> (gread $ gshow 1)::[(Int, String)]
> [(1,"")]
>
> vs.
>
> *Main> (gread $ gshow ())::[((), String)]
> []
>
> that is, the unit type does not work well with gread/gshow, likely
> because inner parentheses are not parsed as a constructor.
>
> *Main> gshow ()
> "(())"
>
> Is this a known bug?
>

I don't think this was noticed before. I wrote it down on the SYB tracker
[1]. It should be fixed for the next release.


Thanks,
Pedro

[1] http://code.google.com/p/scrapyourboilerplate/issues/detail?id=9


>
> Thanks.
>
> On Wed, Sep 30, 2009 at 10:19 AM, Dimitry Golubovsky
>  wrote:
> > Bulat,
> >
> > OK, gread/gshow seem to be like the basis primitives. If they work
> > properly, then it is what is needed.
> >
> > Thanks.
> >
> > On 9/30/09, Bulat Ziganshin  wrote:
> >> Hello Max,
> >>
> >> Wednesday, September 30, 2009, 5:53:37 PM, you wrote:
> >>
> >> afaik, SYB just provides gshow/gread functions what serialize any Data
> >> instance to String
>
> --
> Dimitry Golubovsky
>
> Anywhere on the Web
> ___
> 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] ANNOUNCE: SourceGraph 0.5.1.0

[Ivan Lazar Miljenovic]

This is an updated version of my graph-theoretic static analysis tool
for Haskell, SourceGraph.  This version is available from
http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on
the Hackage page!).

This version provides the ability to pass in a single Haskell source
file rather than a Cabal file for analysis purposes.  Note that the
Cabal version is still preferred as it is better able to determine
the project name and which modules are exported: when using a single
source file, that file is presumed to be the only exported module and
its module name is used as the overall project name.  This feature was
requested by Curt Sampson.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Curt Sampson]

On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote:

> Sure. But what is a computer program? It's a *list of instructions* that  
> tells a computer *how to do something*.

Some are. Some aren't, as proven by the Haskell definition of sum, which
is certainly a "program."

I like to think of a program as a specification. A list of instructions
can certainly qualify, but so can other things, depending on what's
interpreting and executing that specification.

On 2009-10-01 08:59 +0100 (Thu), Andrew Coppin wrote:

> Although, to all the people who ask "why is Ruby so popular?", I might  
> suggest "because it's easy to learn"...

Actually, Ruby isn't terribly easy to learn. If you have previous
experience in another imperative or OO language, you'll pick up the
parts of Ruby that are similar to that fairly quickly, but you're not
really learning anything so much as just doing a simple translation of a
few concepts you already know. You're still going to run into problems
with a number of standard Ruby constructions, probably not be writing
clean or idiomatic code, and you'll be a long way from writing DSLs. In
particular, you're likely to be writing highly repetitive code which
could easily be refactored into something much smaller and nicer. (I'm
constantly seeing people who have programmed in Ruby for years come up
with six- to ten-line chunks of code that are could be replaced with a
single line if they, e.g., only know that there was such as thing as a
"modulo" function.)

>From reading a lot of the code out there (particularly disasters such
as Rails), I suspect a lot of Ruby programmers don't get much past
this level.

cjs
-- 
Curt Sampson   +81 90 7737 2974
   Functional programming in all senses of the word:
   http://www.starling-software.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.

[david48]

On Tue, Sep 29, 2009 at 9:36 PM, Andrew Coppin
 wrote:
> Similarly, Parsec has some lovely external documentation (unfortunately as a 
> single giant HTML page), but the Haddock stuff is bare.

The last version (3.x) improves things.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Journals on Haskell and FP?

[Eugene Kirpichov]

Hi.

I was going to add a reference to the recently born Russian journal
"Practice of functional programming" (http://fprog.ru/ ; had its 1st
issue in July and 2nd was Sep.28) to haskellwiki into a section
devoted specifically to journals, but it turned out there is no such
section and, consequently, no information on journals: just books,
tutorials and research papers. I think this is very valuable
information and it's a shame that it's not listed on haskellwiki.

So, I added such a subsection to
http://haskell.org/haskellwiki/Books_and_tutorials#Journals and added
a reference to Monad.Reader (the only other openly available journal
on FP that I am aware of) , and I encourage the community to mention
some more journals there.

I also encourage the Russian readers who have not yet seen the
aforementioned journal to give it a look :)

-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Exceptions during exception unwinding

[Duncan Coutts]

On Thu, 2009-10-01 at 03:29 +, Brian Bloniarz wrote: 
> I had a question about onException & friends: what's the rationale
> for having:
> (error "foo") `onException` (error "bar")
> 
> give bar and not foo?

> I.e. why does an exception raised during exception handling get
> propagated past the exception that triggered the handler?

Because it's the obvious and sensible thing to do and it what every
other mainstream language with exceptions does. The behaviour you want,
to automatically discard any exceptions raised in the handler and to
always re-raise the original exception can be implemented using the
current semantics, but the reverse is not true.

> Most examples I can think for exception unwinding code would prefer the
> original exception be propagated

Then do not rethrow a different exception.

> This same argument applies to bracket, bracket_, bracketOnError & finally;
> even the common:
> > bracket openSomeHandle closeSomeHandle doAction
> If some error arises during doAction, there's a chance closeSomeHandle might 
> fail
> (even a good chance, given that exception unwinding paths are usually poorly
> tested), and probably doAction has more accurate information about what went
> wrong than closeSomeHandle.

Then catch and ignore the exception from closeSomeHandle (though not all
exceptions or you'd block ^C etc). That said, how will you know that
closeSomeHandle ever works if you always ignore any exceptions it
raises?

For example in the case of your database transaction, having the
transaction fail and roll back is something your application may be set
up to handle. But transation failing during the rollback may be much
more catastrophic and may want to be treated differently. If it fails in
the rollback it might be leaking resources and at the very least you may
want to log it differently from just a transaction that was successfully
rolled back.

> This is just a thought; I hadn't seen this discussed somewhere. I know for
> example that Java has the same approach as the current Control.Exception, so
> there must be good arguments for that too. One that I can think of: using
> onException to rethrow an exception as a different type, though that's what
> mapException is for, correct?

mapException is for the case of exceptions raised by pure code.

As you say, being able to rethrow a different kind of exception, or
simply handle the exception there and then are useful.

I think using onException is the best one for your use case. If you
really really want to ignore an exception raised by rollback then you
have the tools available to do so. As I mentioned earlier do not just
catch and discard all exceptions, see:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#4

Duncan

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

Re: [Haskell-cafe] Exceptions during exception unwinding

[Lyndon Maydwell]

Exception handling code should generally be assumed to work, so if
something goes wrong there you would normally like to know about it.
Also, there is nothing preventing you from wrapping the rescue code in
further exception handling, however, if the initial error were raised
upon encountering a second error, you would not be able to choose to
handle the second error.

This is how I see it anyway.

On Thu, Oct 1, 2009 at 11:29 AM, Brian Bloniarz  wrote:
>
> I had a question about onException & friends: what's the rationale
> for having:
> (error "foo") `onException` (error "bar")
>
> give bar and not foo? I.e. why does an exception raised during
> exception handling get propagated past the exception that triggered
> the handler?
>
> Most examples I can think for exception unwinding code would prefer the
> original exception be propagated -- for example, HDBC has a function which
> rolls back a DB transaction on exception; it implements it like so:
>> withTransaction conn func =
>>   do r <- onException (func conn) doRollback
>>  commit conn
>>  return r
>>   where doRollback =
>> -- Discard any exception from (rollback conn) so original
>> -- exception can be re-raised
>> Control.Exception.catch (rollback conn) doRollbackHandler
>> doRollbackHandler :: SomeException -> IO ()
>> doRollbackHandler _ = return ()
> IMHO, it'd be easier to just write:
>> withTransaction conn func =
>>   do r <- onException (func conn) (rollback conn)
>>  commit conn
>>  return r
>
> This same argument applies to bracket, bracket_, bracketOnError & finally;
> even the common:
>> bracket openSomeHandle closeSomeHandle doAction
> If some error arises during doAction, there's a chance closeSomeHandle might 
> fail
> (even a good chance, given that exception unwinding paths are usually poorly
> tested), and probably doAction has more accurate information about what went
> wrong than closeSomeHandle.
>
> This is just a thought; I hadn't seen this discussed somewhere. I know for
> example that Java has the same approach as the current Control.Exception, so
> there must be good arguments for that too. One that I can think of: using
> onException to rethrow an exception as a different type, though that's what
> mapException is for, correct?
>
> Thanks,
> -Brian
> _
> Microsoft brings you a new way to search the web.  Try  Bing™ now
> http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try
>  bing_1x1___
> 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] Splitting data and function declarations over multiple files

[Peter Verswyvelen]

I'm not sure if I understand what you mean with this co-algebraic approach,
but I guess you mean that functions - like move - don't work directly on any
datatype; you need to provide other functions that give access to the data.
But that's basically what type classes do no? And that's also related to my
earlier post of "strong duck typing" in Haskell.
At least also in C#, that's the way I usually write code that works on any
type, just make an interface or pass in a delegate.  I also know that my OO
background keeps pushing me in the wrong direction when it comes to Haskell
;-)

The collision handling approach is always interesting :)  In OO this is
usually solved using multi-methods or visitors:
http://en.wikipedia.org/wiki/Multiple_dispatch. What I usually did in old
games of mine to handle collisions is not look at the type, but at the
"collision specific features" of a type (which are again functions that
extract information from the object), and that is most likely again the
co-algebraic approach?

On Wed, Sep 30, 2009 at 9:15 PM, Luke Palmer  wrote:

> On Wed, Sep 30, 2009 at 9:54 AM, Peter Verswyvelen 
> wrote:
> > I guess this is related to the expression problem.
> > Suppose I have a datatype
> > data Actor = Ball ... | Paddle ... | Wall ...
> > and a function
> > move (Ball ...) =
> > move (Paddle ...) =
> > move (Wall ...) =
> > in Haskell one must put Actor and move into a single file.
> > This is rather cumbersome if you work with multiple people or want to
> keep
> > the files small and readable.
> > Surely it is possible to use type classes, existentials, etc to split the
> > data type into multiple ones, but that's already advanced stuff in a
> sense.
>
> You can do it without type classes and existentials.  The
> functionality you want is already supported by Haskell, you just have
> to let go of your syntactical expectations.  The trick is that you
> should rewrite your data type not as an algebra (a set of
> constructors), but as a coalgebra (a set of projections).
>
> Let's say your two open functions are:
>
> move :: Actor -> Actor
> isAlive :: Actor -> Bool
>
> This gives rise to the definition of an Actor type:
>
> data Actor = Actor { move :: Actor, isAlive :: Bool }
>
> And then the alternatives of your open data type are just values of type
> Actor:
>
> ball :: Vector -> Vector -> Actor
> ball pos vel = Actor {
>move = ball (pos + vel) vel,
>isAlive = True
>  }
>
> etc.
>
> This trick works well until you get to the encoding of functions that
> pattern match on multiple Actors at the same time.  As far as I can
> tell, that cannot be encoded in this style in any reasonable way.
> Such functions must be rephrased in a coalgebraic style; i.e. instead
> of asking about constructors, using projection functions it knows are
> available.
>
> So for example instead of implementing "collide" by asking about
> pairs, add functions which report a shape function and a normal, or
> whatever your collide algorithm needs from shapes.
>
> You would probably end up having to do this anyway even with your
> proposed extension, because watch:
>
> partial data Actor = Ball ...
>
> collide (Ball ...) (Ball ...) = ...
> collide (Ball ...) x = ...
>
> We don't know about any other constructors, so the second line has to
> contain a pattern-free x.  So you would have to use projection
> functions to get any information about it, exactly as you would when
> you're writing in the coalgebraic style.
>
> So, Yes!  Haskell can do that!
>
> Luke
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Eugene Kirpichov]

2009/10/1 Andrew Coppin :
> Eugene Kirpichov wrote:
>>
>> 2009/10/1 Andrew Coppin :
>>
>>>
>>> Sure. But what is a computer program? It's a *list of instructions* that
>>> tells a computer *how to do something*. And yet, the Haskell definition
>>> of
>>> sum looks more like a definition of what a sum is rather than an actual,
>>> usable procedure for *computing* that sum. (Of course, we know that it
>>> /is/
>>> in fact executable... it just doesn't look it at first sight.)
>>>
>>
>> Well, we are not writing computer programs directly, even in C, that's
>> what compilers are for.
>> That's why I find arguments about the sequential essence of computer
>> programs to be weak.
>>
>
> It might be a better argument to say that human thinking is fundamentally
> sequential; parallel computers have been around for a little while now...
>

I don't buy this argument, either; human thinking is far too broad a
concept to say that it is simply "sequential". If it were sequential,
it could barely express non-sequential concepts, and natural languages
would have rather few of them, which we all know is false.

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



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Andrew Coppin]

Eugene Kirpichov wrote:

2009/10/1 Andrew Coppin :
  

Sure. But what is a computer program? It's a *list of instructions* that
tells a computer *how to do something*. And yet, the Haskell definition of
sum looks more like a definition of what a sum is rather than an actual,
usable procedure for *computing* that sum. (Of course, we know that it /is/
in fact executable... it just doesn't look it at first sight.)



Well, we are not writing computer programs directly, even in C, that's
what compilers are for.
That's why I find arguments about the sequential essence of computer
programs to be weak.
  


It might be a better argument to say that human thinking is 
fundamentally sequential; parallel computers have been around for a 
little while now...


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

[Haskell-cafe] Re: Splitting data and function declarations over multiple files

[Heinrich Apfelmus]

Peter Verswyvelen wrote:
> I guess this is related to the expression problem.
> Suppose I have a datatype
> 
> *data Actor = Ball ... | Paddle ... | Wall ...*
> 
> and a function
> 
> *move (Ball ...) = *
> *move (Paddle ...) = *
> *move (Wall ...) = *
> 
> in Haskell one must put *Actor* and *move* into a single file.

Just a nitpick: you don't have to put  Actor  and  move  into the same
module.

module A where
data Actor = Ball | Paddle | Wall

module B where
import A (Actor)

move Ball   = ...
move Paddle = ...
move Wall   = ...

But that's probably not what you meant.


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] error on "--++ bla bla bla"

[Ketil Malde]

Hong Yang  writes:

> But in my program, I did not define "--++".

And that's what the error tells you, no?

Defining operators (or not) doesn't change the syntax.  Since the lexeme
--++ is syntactially a valid operator, it will be parsed as such,
regardless of whether it is defined or not.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Eugene Kirpichov]

2009/10/1 Andrew Coppin :
> John Dorsey wrote:
>>>
>>> Well, try this: Go ask a random person how you add up a list of numbers.
>>>  Most of them will say something about adding the first two together,
>>>  adding the third to that total, and so forth. In other words, the step  by
>>> step instructions.
>>>
>>
>> You word the (hypothetical) question with a bias toward imperative
>> thinking.  You're asking "How do you do this action?"
>>
>> Why isn't the question "What is the sum of a list of numbers?", which is
>> biased toward the declarative?
>>
>
> Sure. But what is a computer program? It's a *list of instructions* that
> tells a computer *how to do something*. And yet, the Haskell definition of
> sum looks more like a definition of what a sum is rather than an actual,
> usable procedure for *computing* that sum. (Of course, we know that it /is/
> in fact executable... it just doesn't look it at first sight.)

Well, we are not writing computer programs directly, even in C, that's
what compilers are for.
That's why I find arguments about the sequential essence of computer
programs to be weak.

>
> Whatever; I'm leaning more and more towards the concept that FP is only hard
> for people who already learned some other way...
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Andrew Coppin]

Ketil Malde wrote:

Although the question of how we "naturally" think often comes up, I'm
not sure it's a very important one.  In my experience, the natural
thing for humans appear rather to be the absence of thinking, and
instead slouching in front of the TV eating unhealthy food.

After all, we give people who program computers several years of
education to learn about unnatural things like counters and temporary
variables, or recursion and folds.  The question shouldn't be what comes
more natural for average Joe, but rather what skills can we teach a
reasonably bright student in three to five years that will make her the
most effective programmer.
  


I'll go along with that.

Although, to all the people who ask "why is Ruby so popular?", I might 
suggest "because it's easy to learn"...


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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Andrew Coppin]

John Dorsey wrote:
Well, try this: Go ask a random person how you add up a list of numbers.  
Most of them will say something about adding the first two together,  
adding the third to that total, and so forth. In other words, the step  
by step instructions.



You word the (hypothetical) question with a bias toward imperative
thinking.  You're asking "How do you do this action?"

Why isn't the question "What is the sum of a list of numbers?", which is
biased toward the declarative?
  


Sure. But what is a computer program? It's a *list of instructions* that 
tells a computer *how to do something*. And yet, the Haskell definition 
of sum looks more like a definition of what a sum is rather than an 
actual, usable procedure for *computing* that sum. (Of course, we know 
that it /is/ in fact executable... it just doesn't look it at first sight.)


Whatever; I'm leaning more and more towards the concept that FP is only 
hard for people who already learned some other way...


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

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Ketil Malde]

Andrew Coppin  writes:

> Peter Verswyvelen wrote:

>> I really doubt people tend to think in either way. It's not even
>> sure our thinking can be modeled with computing no?

> Well, try this: Go ask a random person how you add up a list of
> numbers.

Although the question of how we "naturally" think often comes up, I'm
not sure it's a very important one.  In my experience, the natural
thing for humans appear rather to be the absence of thinking, and
instead slouching in front of the TV eating unhealthy food.

After all, we give people who program computers several years of
education to learn about unnatural things like counters and temporary
variables, or recursion and folds.  The question shouldn't be what comes
more natural for average Joe, but rather what skills can we teach a
reasonably bright student in three to five years that will make her the
most effective programmer.

(That's what the question should be, of course what the question really
*is* is what curriculum can we present that looks entertaining,
fashionable, and trivial enough that enough high-school kids will apply
for the department not to be starved of funds... )

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.

[Ketil Malde]

namekuseijin  writes:

> Point is:  >>= . $ : ! `` and meaningful whitespace are all nice
> shortcuts, but also hairy confusing...

As somebody pointed out, these are rather idiomatic, and only confusing
to beginners.  (I'm not sure what you refer to with whitespace, some
think layout makes code difficult to write, but I don't think it hurts
legibility?  If you refer to extension that makes 'x?y' and 'x ? y' mean
different things, then I agree: that way lies madness.)

I agree it's usually better to use real names, but one problem with many
operators (and Haskell functions in general) is their extreme
generality.  For instance, the >>= cominator is usually pronounced
'bind'.  Does this really help?

 exp1 >>= exp2
 vs  exp1 `bind` exp2
or even  bind exp1 exp2

In some cases where names are used, it just increases confusion,
e.g. the Monoid function 'mappend' is nice for concatenating two lists,
but a rather odd name for mulitplying two integers.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe