Re: [Haskell-cafe] Function application like a Unix pipe

[Cale Gibbard]

On 24/11/05, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Cale Gibbard:
>
> > x f does perhaps make more sense, especially with the current
> > categorical view of functions, but there would have to be a really
> > hugely good reason to change notation, as almost all current work puts
> > things the other way around.
>
> "Almost all"?
> Well, excluding the Smalltalkers, people using Forth, PostScript, etc.
>
Perhaps I should have qualified that: I meant in pure mathematics.
 - Cale
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function application like a Unix pipe

[jerzy . karczmarczuk]

Cale Gibbard: 


x f does perhaps make more sense, especially with the current
categorical view of functions, but there would have to be a really
hugely good reason to change notation, as almost all current work puts
things the other way around.


"Almost all"?
Well, excluding the Smalltalkers, people using Forth, PostScript, etc. 



Jerzy Karczmarczuk 



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

Re: [Haskell-cafe] Function application like a Unix pipe

[Bill Wood]

On Wed, 2005-11-23 at 21:21 -0500, Cale Gibbard wrote:
   . . .
> Hmm, which edition? My copy (5th ed.) uses the ordinary notation: f(x).
> 
> x f does perhaps make more sense, especially with the current
> categorical view of functions, but there would have to be a really
> hugely good reason to change notation, as almost all current work puts
> things the other way around.

My copy reads
   First published 1997 by
   Prentice Hall Europe
   (Address lines)
   Copyright Prentice Hall Europe 1997
   ...
   ISBN 0-13-507245-X

It's hardcover, white cover with red around the spine (standard for this
series edited by C.A.R. Hoare), black banner with "100th title" in red.
The lack of any edition information leads me to surmise it's a first
edition.

Do you (or anyone) know if the "diagrammatic notation" has any currency
among algebraists?

 -- Bill Wood


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

Re: [Haskell-cafe] Function application like a Unix pipe

[Cale Gibbard]

On 23/11/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote:
> Bill Wood <[EMAIL PROTECTED]> writes:
>
> > Interesting note: in Richard Bird and Oege de Moor, _Algebra
> > of Programming_, pp. 2-3, the authors write
> >
> >As a departure from tradition, we write "f : A <- B" rather than
> >"f : B -> A" to indicate the source and target types associated
> >with a function "f". ... The reason for this choice has to do with
> >functional composition, whose definition now takes the smooth
> >form: if f : A <- B and g : B <- C, then f . g : A <- C is defined
> >by (f . g) x = f(g x).
> >
> > Further along the same paragraph they write:
> >
> >In the alternative, so-called diagrammatic forms, one writes
> >"x f" for application and "f ; g" for composition, where
> >x (f ; g) = (x f) g.
> >
> > I know I've read about the latter notation as one used by
> > some algebraists, but I can't put my hands on a source right now.
> >
> > I guess it's not even entirely clear what constitutes
> > "mathematical notation". :-)
> >
> >  -- Bill Wood
>
> Good point. One of my undergrad algebra books ("Contemporary Abstract
> Algebra", by Gallian) actually used notation like this. Function
> application was written (x f). Some people even write the function as an
> exponential. But (f x) is still far more common.

Hmm, which edition? My copy (5th ed.) uses the ordinary notation: f(x).

x f does perhaps make more sense, especially with the current
categorical view of functions, but there would have to be a really
hugely good reason to change notation, as almost all current work puts
things the other way around.

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

[Haskell-cafe] Re: Records vs HList

[David Menendez]

Keean Schupke writes:

> HList can do O(log n) by the way, if the labels have order, you can
> implement a binary search tree of labels (Of course all the accessor
> functions would need to be rewritten).

The idea of writing a type-level balanced binary search tree fills me
with an uncertain mixture of excitement and dread. Particularly if you
want to be able to compare records for equality.
-- 
David Menendez <[EMAIL PROTECTED]> | "In this house, we obey the laws
  |of thermodynamics!"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Re[2]: Uses forkOS all CPUS on-board?

[Shae Matijs Erisson]

Bulat Ziganshin <[EMAIL PROTECTED]> writes:

> >> They work, even in a context switching regime, but I can't
> >> exploit all the CPU's on my computer. Always is "active"
> >> just one thread
> this will not help. multi-processing support will be added in GHC 6.6,
> which must roll out due 6 months, as HCAR says

In the meantime, you can try it yourself by grabbing ghc 6.5 from cvs and
reading http://www.haskell.org/~simonmar/papers/multiproc.pdf
-- 
Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said:
You could switch out the unicycles for badgers, and the game would be the same.

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

Re[2]: [Haskell-cafe] Uses forkOS all CPUS on-board?

[Bulat Ziganshin]

Hello Sebastian,

Wednesday, November 23, 2005, 6:46:54 PM, you wrote:

>> They work, even in a context switching regime, but I can't
>> exploit all the CPU's on my computer. Always is "active"
>> just one thread

SS> Did you compile it with "-threaded"?

this will not help. multi-processing support will be added in GHC 6.6,
which must roll out due 6 months, as HCAR says

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]



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

[Haskell-cafe] Problem over Context Free Grammar Transitive Closure Algorithm

[Victor Silva]

Folks this is a parser for Context Free Grammars, for some reason when
I go simplify the grammar trying to remove productions that substitute
variables like in the case:
S -> A, A -> B, B -> a, it works perfectly and returns S ->
a, the problem is when the root symbol is on the listthat must be
replaced as in:
S -> aXa | bXb , X -> a | b | S | £(empty)
instead of returning
S -> aXa | bXb, X -> a | b | £ | aXa | bXb

it ruturns X as
X -> a | b | £ | S <- this S is wrong! it should return X -> a
| b | £ | aXa | bXb! Im not sure about where is the mistake. If you can
give me hints it would be grat. I will be checking the mail and also
hanging over #haskell at freenode ifyou want to contact me directly.
Thanks in advance for the help!

Victor
module CFG where
 
import Text.ParserCombinators.Parsec
{--import Data.Map--}
import Control.Monad (liftM)
import Data.Map (Map)
import qualified Data.Map as Map

data CFG t nt = CFG {terminals:: [Symb t nt],
 nonterminals :: [Symb t nt],
 root ::  Symb t nt ,
{-productions :: Map (Symb t nt) [(ProdName,[Symb t nt])]-}
 productions :: Map (Symb t nt) [[Symb t nt]]}
deriving (Eq,Ord,Show)

type Prod t nt = (ProdName,[Symb t nt])
 
type ProdName = String
 
data Symb t nt = Root
   | T t
   | NT nt
   | Empty
   deriving (Eq,Ord,Show)


{-Checks if the non-terminals are oki, the restriction that each NT must consist of a single symbol is already checked by the mapping structure here the only check needed id that the terminals and nonterminals sets are disjunct-}
nonterminal :: [Char] -> CharParser st (Symb Char Char)
nonterminal termchars = liftM NT (noneOf (" |\n"++termchars))

{-Now I try to check if a given symbol is a terminal-}
terminal :: [Char] -> CharParser st (Symb Char Char)
terminal termchars = liftM T (oneOf termchars)

{-Checks if it is a $ production, Ive used $ for empty prodution because GHC doesnt supports unicode YET :-) -}
empty :: CharParser st (Symb Char Char)
empty = do {char '$'; return Empty}


{-rhs termchars = production termchars `sepBy` string " | "-}
{- parseTest (rhs "sz") "sN | z" -}
{- rhs stands for right-hand-side -}
production termchars = (do empty; return [])
   <|> many (terminal termchars <|> nonterminal termchars)

rhs termchars = production termchars `sepBy` string " | "

rule termchars = do x <- nonterminal termchars
string " -> "
ys <- rhs termchars
return (x, ys)


{-parseTest grammar (unlines ["termchars sz","start N","N -> sN | z"])-}
grammar = do string "termchars "; termchars <- many (noneOf " |\n"); newline
 string "start "; root <- nonterminal termchars; newline
 productionsList <- rule termchars `sepEndBy` newline
 return (CFG { terminals = map T termchars,
   nonterminals = map fst productionsList,
   root = root,
   productions = Map.fromList productionsList
})

{-let cfg = run grammar "" (unlines ["termchars sz","start N","N -> sN | z"])-}
{-*CFG> let cfg = run grammar "" (unlines ["termchars sz","start N","N -> sN | z"])
Loading package parsec-1.0 ... linking ... done.
*CFG> cfg
CFG {terminals = [T 's',T 'z'], nonterminals = [NT 'N'], root = NT 'N', productions = {NT 'N':=[[T 's',NT 'N'],[T 'z']]}}
*CFG> start

:1:0: Not in scope: `start'
*CFG> cfg
CFG {terminals = [T 's',T 'z'], nonterminals = [NT 'N'], root = NT 'N', productions = {NT 'N':=[[T 's',NT 'N'],[T 'z']]}}
*CFG> root cfg
NT 'N'
-}
run p name xs = case parse p name xs of
   	 Left  err -> error (show err)
   		 Right res -> res


{-Finds empty productions-}
{- *CFG> let cfg = run grammar "" (unlines ["termchars ab","start S","S -> aXa | bXb | $","X -> a | b | Y","Y -> $"])
*CFG> empties cfg
 [NT 'S',NT 'Y'] -}
empties cfg = Map.keys (Map.filter (any (==[])) (productions cfg))

{-cleanset cfg = Map.map ((filter (/=[Empty])) (productions cfg))-}
removeEmpties1 cfg = cfg { productions = prods'' }
where
prods= productions cfg
{-prods'   = Map.map (filter (/=[])) prods-}
prods'   = Map.mapWithKey (\k -> if k == root cfg 
	then id 
	else filter (/=[])) 
prods

prods''  = Map.map (concatMap f) prods'
f [] = [[]] 
f (x:xs) | x `elem` empties cfg = map (x:) (f xs) ++ f xs
	 | otherwise= map (x:) (f xs)

removeEmpties :: (Ord t, Ord nt) => CFG t nt -> CFG t nt
removeEmpties = doToDeath removeEmpties1

doToDeath f x = findFixedPoint (iterate f x)
where
findFixedPoint (x:y:z)
| x == y= x
| otherwise = findFixedPoint (y:z)


--remove useless
{-removeUseless (removeEmpties cfg)-}
useless cfg = Map.keys (Map.delete (root cfg)
 (Map.filter null (productions cfg)))

removeUseless cfg

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[David Menendez]

Wolfgang Jeltsch writes:

> If we use an implementation of State *without lazy patterns*, it
> becomes something like this:
> 
>   \s -> case next s of
>   (x,s') -> case everyting s' of
>   (xs,s'') -> ((x : xs),s'')
> 
> Note that I used case expressions to realize strict patterns because
> pattern binding in let expressions is implicitely lazy.
> 
> Now lets apply the function denoted by the last code fragment to some
> initial state and try to extract just the first element of the
> output.  In order to do so we have to take the result of the function
> and match it against ((x : _),_).  Especially, we have to reduce the
> pair, i.e., we have to make sure that it's really an application of
> (,) and not _|_.

Would the lazy pattern match be equivalent to using fst and snd?

\s -> case next s of
  p1 -> case everything (snd p1) of
   p2 -> (fst p1 : fst p2, snd p2)
-- 
David Menendez <[EMAIL PROTECTED]> | "In this house, we obey the laws
  |of thermodynamics!"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[Fan Wu]

Hi Wolfgang,

Thanks for your response and examples! It helps a lot.

>From your example I can see "Lazy patterns are useful in contexts
where infinite data structures are being defined recursively" (quote
section 4.4 of Gentle Introduction to Haskell). But does it apply to
the mplus case? I mean the mplus in (mplus m1 m2) and the mplus in
(mplus m1' m2') are different due to the difference of Monads (one is
StateT s m, the other is just m). If I change the mplus inside lift to
something else like:

  mplus m1 m2   = do s <- peek
 let m1' = runState s m1
 m2' = runState s m2
 ~(a,s') <- lift (other_func m1' m2')
 poke s'
 return a


Is it still required that (a,s') be lazy?

I just want to see how things works in an less obvious example like this one.

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

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[Andrew Pimlott]

On Wed, Nov 23, 2005 at 02:03:22AM -0700, Fan Wu wrote:
> instance MonadPlus m => MonadPlus (StateT s m) where
>   mzero = lift mzero
>   mplus m1 m2   = do s <- peek
>  let m1' = runState s m1
>  m2' = runState s m2
>   ???>   ~(a,s') <- lift (mplus m1' m2')
>  poke s'
>  return a

Perhaps you were wondering, as I did when I read this, how

~(a,s') <- lift (mplus m1' m2')
poke s'
return a

differs from

lift (mplus m1' m2')

It helped me to rewrite mplus:

mplus m1 m2 = S (\s ->  let m1' = runState s m1
m2' = runState s m2
in  ~(a, s') <- mplus m1' m2'
return (a, s'))

(If you reduce the first definition to this, you can verify that the
lazy pattern matches in the two correspond.)  So my question boils down
to, can you ever distinguish

S (\s -> m >>= ~(a, s') -> return (a, s'))

from

S (\s -> m)

using only exported operators?  I don't think so, because a subsequent
bind will do the lazy pattern match itself.  Did I miss something, or is
this use of ~ (and the subsequent poke, return) superfluous?

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

RE: [Haskell-cafe] Function application like a Unix pipe

[Scherrer, Chad]

Bill Wood <[EMAIL PROTECTED]> writes:

> Interesting note: in Richard Bird and Oege de Moor, _Algebra 
> of Programming_, pp. 2-3, the authors write
> 
>As a departure from tradition, we write "f : A <- B" rather than
>"f : B -> A" to indicate the source and target types associated
>with a function "f". ... The reason for this choice has to do with
>functional composition, whose definition now takes the smooth
>form: if f : A <- B and g : B <- C, then f . g : A <- C is defined
>by (f . g) x = f(g x).
> 
> Further along the same paragraph they write:
> 
>In the alternative, so-called diagrammatic forms, one writes
>"x f" for application and "f ; g" for composition, where
>x (f ; g) = (x f) g.
> 
> I know I've read about the latter notation as one used by 
> some algebraists, but I can't put my hands on a source right now.
> 
> I guess it's not even entirely clear what constitutes 
> "mathematical notation". :-)
> 
>  -- Bill Wood

Good point. One of my undergrad algebra books ("Contemporary Abstract
Algebra", by Gallian) actually used notation like this. Function
application was written (x f). Some people even write the function as an
exponential. But (f x) is still far more common.

Chad Scherrer
Computational Mathematics Group
Pacific Northwest National Laboratory

"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Function application like a Unix pipe

[Bill Wood]

On Wed, 2005-11-23 at 17:47 +0100, Henning Thielemann wrote:
   . . .
>   Why is there no (<<) and why is (=<<) not the default? The order of 'do 
> {a;b;c}' is compatible with that of (>>). So we have the fundamental 
> conflict, that usually function application is from right to left, but 
> interpreting imperative statements is from left to right.
>   I think that's a similar conflict like that of little endian and big 
> endian.

There may be something to your functional/imperative conflict.

I had occasion to develop a computational model of a theoretical
state-transition machine that the inventors wanted to be able to
program.  My model used the standard trick of construing a parameterized
operation as a function f : Arg1 -> ... -> Argn -> State -> State.  By
writing the (ML) code for the instructions in the curried form and using
a reversed composition operator, I was able to provide a programmatic
interface which could be laid out one instruction per line with the
composition operators way off to the right in the comment column, just
like assembler code!  The inventors thought this was just wonderful
(there's no accounting for taste, I guess :-).

 -- Bill Wood


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

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[Wolfgang Jeltsch]

Am Mittwoch, 23. November 2005 19:02 schrieb Fan Wu:
> HI Wolfgang,
>
> The code is from GHC source
> ghc-6.4.1/libraries/monads/Monad/StateT.hs, am I looking at the wrong
> place?
>
> I found the thread discussing "Monad strictness", where is your StateT
> defined?

Hello Fan,

the GHC source is just where I looked, except that my GHC version is 6.2.2.  
Obviously they corrected the implementation of (>>=) for StateT to use a lazy 
pattern between 6.2.2 and 6.4.1.

> But it is still not clear to me why lazy pattern is used here. Any ideas?

Let's discuss this for State instead of StateT because this makes the 
discussion easier.

A state transformer should ideally be implemented as a kind of function which 
gets one argument (the initial state) and returns *two* results (the output 
and the final state).  Of course, a real function cannot return two results, 
so the obvious solution is to use a function which returns a pair, consisting 
of the output and the final state.  If we would do so, it would work.

But Haskell's pairs are not real pairs but lifted pairs.  There are pairs like 
(x,y) which are an application of the data constructor (,) to x and y, and 
there is the special pair _|_ which denotes undefinedness.  Note that _|_ is 
not the same as (_|_,_|_).  Pattern matching of _|_ against the pattern (_,_) 
will not be successful while matching (_|_,_|_) against the same pattern 
will.

The problem now is that when using Haskell pairs for implementing state 
transformers, it might not immediately be clear for a given state transformer 
if it returns an application of (,) (i.e., a "true pair") or if it returns
_|_.  Pattern matching of a state transformer's result against a pattern of 
the form (x,y) may therefore result in unnecessary evaluation of certain 
expressions.

Let's look at an example.  We have two types S and T as well as some state 
transformer next :: State S T.  Now we want to construct a state transformer 
which calls next infinitely many times and returns the outputs of the next 
invocations as an infinite list.  We would write:

everything :: State S [T]
everything
= do
x <- next
xs <- everything
return (x : xs)

The do expression can be rewritten as:

next >>= (\x -> everything >>= \xs -> return (x : xs))

If we use an implementation of State *without lazy patterns*, it becomes 
something like this:

\s -> case next s of
(x,s') -> case everyting s' of
(xs,s'') -> ((x : xs),s'')

Note that I used case expressions to realize strict patterns because pattern 
binding in let expressions is implicitely lazy.

Now lets apply the function denoted by the last code fragment to some initial 
state and try to extract just the first element of the output.  In order to 
do so we have to take the result of the function and match it against
((x : _),_).  Especially, we have to reduce the pair, i.e., we have to make 
sure that it's really an application of (,) and not _|_.

In order to do so we have to first reduce next s.  After this, s' has to be 
taken and the result of everything s' has to be reduced.  We cannot tell that 
the result of the whole function is really a (,) application until we have 
reduced everything s' and made sure that its result is not bottom.  The 
problem is that for reducing everything s', we have to start the whole 
procedure again.  So we end up in an infinite recursion and never get any 
result.

However, if we use lazy patterns, we don't have to reduce next s at first.  We 
also don't have to reduce everything s'.  No matter whether these two 
expressions are _|_ or not, we know that the whole function always has a 
result of the form ((x : xs),s'').  The first component of the pair can be 
immediately extracted from the pair and so can the first element of the list.  
Only if we start to evaluate this first element, next s has to be reduced.  
But only next s!

I hope, this did clarify this problem a bit.  If you still have questions, 
feel free to ask.

> Thanks,
> Fan

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

RE: [Haskell-cafe] Function application like a Unix pipe

[Bill Wood]

On Wed, 2005-11-23 at 08:55 -0800, Scherrer, Chad wrote:
   . . .
> I see. I like the argument order also, since it so nicely reflects
> mathematical notation. But I do think there's a place for (flip ($)) and
> (flip (.)). The problem is that the assignment of fixities is much more
> subtle and requires a consideration of what should be considered "proper
> style".

Interesting note: in Richard Bird and Oege de Moor, _Algebra of
Programming_, pp. 2-3, the authors write

   As a departure from tradition, we write "f : A <- B" rather than
   "f : B -> A" to indicate the source and target types associated
   with a function "f". ... The reason for this choice has to do with
   functional composition, whose definition now takes the smooth
   form: if f : A <- B and g : B <- C, then f . g : A <- C is defined
   by (f . g) x = f(g x).

Further along the same paragraph they write:

   In the alternative, so-called diagrammatic forms, one writes
   "x f" for application and "f ; g" for composition, where
   x (f ; g) = (x f) g.

I know I've read about the latter notation as one used by some
algebraists, but I can't put my hands on a source right now.

I guess it's not even entirely clear what constitutes "mathematical
notation". :-)

 -- Bill Wood


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

Re: [Haskell-cafe] GHCi always optimizes?

[Tomasz Zielonka]

On Wed, Nov 23, 2005 at 08:48:04AM -, Simon Peyton-Jones wrote:
> | Anyway, it's strange that you are experiencing crashes.  IIRC, there
> | were problems if you mixed modules compiled with different levels of
> | optimisation in the same program, but I am not sure it still happens.
> 
> If you can make a reproducible crash, please tar it up and send it to
> us.  It shouldn't happen. Ever.

I am not sure who you are replying to - me or Dusan. If you can't
remember such a problem, then it is only my memory playing tricks ;-)

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

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[Fan Wu]

HI Wolfgang,

The code is from GHC source
ghc-6.4.1/libraries/monads/Monad/StateT.hs, am I looking at the wrong
place?

I found the thread discussing "Monad strictness", where is your StateT defined?

But it is still not clear to me why lazy pattern is used here. Any ideas?

Thanks,
Fan

On 11/23/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 23. November 2005 10:03 schrieb Fan Wu:
> > [...]
>
> > I'm puzzled over this line:
> >
> > ~(a,s') <- lift (mplus m1' m2')
>
> Why is this line in Monad.State.StateT?  Recently, we discussed that StateT
> does *not* use a lazy pattern here but that it should be changed to using
> one.  So where did you see this lazy pattern?
>
> > [...]
>
> Best wishes,
> Wolfgang
> ___
> 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] Function application like a Unix pipe

[Tomasz Zielonka]

On Wed, Nov 23, 2005 at 09:01:07AM -0800, Scherrer, Chad wrote:
> So I think of the types as being 
> grep "." *.hs :: String
> wc :: String -> Int  -- ok, not really, but it shows the point better.

Every unix program has a standard input, even if it doesn't use it, so
I would rather give this type to grep "." *.hs:

grep "." *.hs :: a -> String

You can run something like this

p | echo bla | grep "." *.hs | wc

even if it seems non-sensical.

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

RE: [Haskell-cafe] Function application like a Unix pipe

[Scherrer, Chad]

Udo Stenzel <[EMAIL PROTECTED]> writes:

> The unix pipe is actually function composition.  Its argument 
> (standard
> input) isn't explicitly mentioned

Then it seems Unix must overload the "|" operator. I typically use it to
do things like
grep "." *.hs | wc

So I think of the types as being 
grep "." *.hs :: String
wc :: String -> Int  -- ok, not really, but it shows the point better.

So we'd have to have 
(|) :: a -> (a -> b) -> b

And (flip ($)) is the only thing that makes sense. Is it the case that a
Unix pipe is analagous to (flip ($)) or (flip (.)) depending on the
context?

Chad Scherrer
Computational Mathematics Group
Pacific Northwest National Laboratory

"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Function application like a Unix pipe

[Scherrer, Chad]

Henning Thielemann <[EMAIL PROTECTED]> writes:

>   I want to say, that the order of symbols for ($), (.) and 
> function application is consistent. This is a fine thing. I 
> think that shall not be distroyed by giving ($) and (.) 
> reversed argument order.

I see. I like the argument order also, since it so nicely reflects
mathematical notation. But I do think there's a place for (flip ($)) and
(flip (.)). The problem is that the assignment of fixities is much more
subtle and requires a consideration of what should be considered "proper
style".

Chad Scherrer
Computational Mathematics Group
Pacific Northwest National Laboratory

"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx 

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

RE: [Haskell-cafe] Function application like a Unix pipe

[Henning Thielemann]

On Wed, 23 Nov 2005, Scherrer, Chad wrote:


Henning Thielemann <[EMAIL PROTECTED]> writes:


Since
  (a . b) x
  a $ b x
  a (b x)

are equivalent, do you also want to reverse function and
argument in order to match argument order of . and $ ?

That is
  x (b . a)
  x b $ a
  (x b) a
?


I'm sorry, I'm not sure I understand your question. Are you asking
whether one should be allowed to write x f instead of f x? I don't think
anyone is advocating this, but is can be convenient to have an infix
operator for this purpose.


 I want to say, that the order of symbols for ($), (.) and function 
application is consistent. This is a fine thing. I think that shall not be 
distroyed by giving ($) and (.) reversed argument order.


 It's of course a good question, why (>>) and (>>=) have the opposite 
order of (.). Compare function application

 a b
  where a is applied to b with the monadic case
 b >>= a
  where a is applied to the result of b. This makes changing a non-monadic 
expression to a similar monadic expression more difficult.
 Why is there no (<<) and why is (=<<) not the default? The order of 'do 
{a;b;c}' is compatible with that of (>>). So we have the fundamental 
conflict, that usually function application is from right to left, but 
interpreting imperative statements is from left to right.
 I think that's a similar conflict like that of little endian and big 
endian.

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

RE: [Haskell-cafe] Function application like a Unix pipe

[Scherrer, Chad]

Henning Thielemann <[EMAIL PROTECTED]> writes:

> Since
>   (a . b) x
>   a $ b x
>   a (b x)
> 
> are equivalent, do you also want to reverse function and 
> argument in order to match argument order of . and $ ?
> 
> That is
>   x (b . a)
>   x b $ a
>   (x b) a
> ?

I'm sorry, I'm not sure I understand your question. Are you asking
whether one should be allowed to write x f instead of f x? I don't think
anyone is advocating this, but is can be convenient to have an infix
operator for this purpose.

Chad Scherrer
Computational Mathematics Group
Pacific Northwest National Laboratory

"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx 

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

Re: [Haskell-cafe] Uses forkOS all CPUS on-board?

[Sebastian Sylvan]

On 11/23/05, Dusan Kolar <[EMAIL PROTECTED]> wrote:
> Hello haskellers,
>
>   in past few days, a lot of stuff on concurrency went through
> the conference. I'm trying to use posted things and my own.
> They work, even in a context switching regime, but I can't
> exploit all the CPU's on my computer. Always is "active"
> just one thread and, thus, the computation is even slower
> than having a sequential version. Below, you can find
> my code - it computes nothing useful, it's been simplified
> to test parallelism, nothing else. Where's my error?
>

Did you compile it with "-threaded"?

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

[Haskell-cafe] Uses forkOS all CPUS on-board?

[Dusan Kolar]

Hello haskellers,

 in past few days, a lot of stuff on concurrency went through
the conference. I'm trying to use posted things and my own.
They work, even in a context switching regime, but I can't
exploit all the CPU's on my computer. Always is "active"
just one thread and, thus, the computation is even slower
than having a sequential version. Below, you can find
my code - it computes nothing useful, it's been simplified
to test parallelism, nothing else. Where's my error?

 Regards

   Dusan


import Control.Concurrent

-- computes nothing too much useful, but takes a long time ;-)
sumAllSums [] = 0
sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs
   where sumlist res [] = res
 sumlist sr  (v:vs) = sumlist (sr+v) vs


main = do
 putStrLn "Starting..."
 mv1 <- newEmptyMVar
 mv2 <- newEmptyMVar
 t1 <- forkOS $ mkSum1 mv1
 t2 <- forkOS $ mkSum2 mv2
 tt mv1 mv2
 forkOS $ do killThread t1
 killThread t2
 putStrLn "Done!"
 where
   mkSum1 mv = do
 let res = sumAllSums [1..1]
 let ms1 = "Sum1: " ++ show res
 seq (length ms1) (putMVar mv ms1)
   mkSum2 mv = do
 let res = sumAllSums [1..10001]
 let ms2 = "Sum2: " ++ show res
 seq (length ms2) (putMVar mv ms2)
   tt mv1 mv2 = do
 yield
 mr1 <- tryTakeMVar mv1
 case mr1 of
   Just r1 -> do
 yield
 putStrLn r1
 yield
 r2 <- takeMVar mv2
 putStrLn r2
   Nothing -> do
 mr2 <- tryTakeMVar mv2
 case mr2 of
   Just r2 -> do
 yield
 putStrLn r2
 yield
 r1 <- takeMVar mv1
 putStrLn r1
   Nothing -> tt mv1 mv2
 


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

RE: [Haskell-cafe] Spurious program crashes

[Simon Marlow]

On 23 November 2005 13:29, Joel Reymont wrote:

> On Nov 23, 2005, at 1:18 PM, Simon Marlow wrote:
> 
>> After subsequent dicsussion, do you still think something strange was
>> going on here?
> 
> Yes, but in a different thread. The "Postmortem" one.
> 
>> so this basically loops until there are no messages in the channel,
>> and then exits.  Is that what you wanted, or did you want it to keep
>> reading from the channel until told to die?
> 
> I probably made a mistake someplace as I wanted to read until told to
> die but ONLY if the channel was empty. I replaced that code with
> Tomasz's elegant solution so now I read until Nothing is read from
> the channel.
> 
> logger :: Handle -> IO ()
> logger h =
>  do ss <- getChanContents parent
> logger' ss
> where logger' [] = return ()
>   logger' (Nothing:_) = return ()
>   logger' ((Just x):xs) =
>   do putStrLn x
>  hPutStrLn h x
>  logger' xs
>  yield

The yield is unnecessary.  Also, getChanContents is considered by some
(me included) to be poor style, because it relies on lazy I/O.  This
should work just as well:

  logger h = do
 m <- readChan parent
 case m of
   Nothing -> return ()
   Just x  -> do hPutStrLn h x; logger h

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

Re: [Haskell-cafe] Spurious program crashes

[Joel Reymont]

On Nov 23, 2005, at 1:18 PM, Simon Marlow wrote:


After subsequent dicsussion, do you still think something strange was
going on here?


Yes, but in a different thread. The "Postmortem" one.

so this basically loops until there are no messages in the channel,  
and
then exits.  Is that what you wanted, or did you want it to keep  
reading

from the channel until told to die?


I probably made a mistake someplace as I wanted to read until told to  
die but ONLY if the channel was empty. I replaced that code with  
Tomasz's elegant solution so now I read until Nothing is read from  
the channel.


logger :: Handle -> IO ()
logger h =
do ss <- getChanContents parent
   logger' ss
   where logger' [] = return ()
 logger' (Nothing:_) = return ()
 logger' ((Just x):xs) =
 do putStrLn x
hPutStrLn h x
logger' xs
yield

For whatever reason this generates empty lines with some sort of an  
unprintable character at the beginning. It prints these to the screen  
but not to the file. Of course it also prints what it's supposed to  
but the garbage shows both on Windows and the Mac.



STM is a better solution, as already suggested.  Without STM, the best
way to do this is to multiplex everything into a single channel (i.e.
send the die message down the channel).


Right.

Thanks, Joel

--
http://wagerlabs.com/





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

RE: [Haskell-cafe] Spurious program crashes

[Simon Marlow]

On 21 November 2005 16:43, Joel Reymont wrote:

> I'm being quite careful with resources these days. The outstanding
> issues are
> 
> 1) Crashes on Mac OSX that are not reproduced on Linux, Windows, etc.
> 
> 2) Some kind of a problem with Chan. getChanContents retrieves things
> smoothly, readChan only does it for the first few lines. Simon?
> Anyone? 

After subsequent dicsussion, do you still think something strange was
going on here?  The code does look strange:

logger :: MVar () -> IO ()
logger die =
do empty <- isEmptyChan parent
   unless empty $ do x <- readChan parent
 putStrLn x
   alive <- isEmptyMVar die
   when (alive || not empty) $ logger die

so this basically loops until there are no messages in the channel, and
then exits.  Is that what you wanted, or did you want it to keep reading
from the channel until told to die?

STM is a better solution, as already suggested.  Without STM, the best
way to do this is to multiplex everything into a single channel (i.e.
send the die message down the channel).

> 3) Different performance of the logger thread on Mac OSX and Windows.
> 
> I'm having thousands of threads write their trace messages to a Chan.
> The logger On Windows I only see the first few lines of output when
> using isEmptyChan/readChan to retrieve values in a loop. On Mac OSX I
> do see smooth output.

Context switch behaviour might be different between MacOS X and Windows.
With the above code, it might be that the logger thread found an empty
channel at sp,e point and exited.  Does that make sense?

> On Windows I run out of memory because all the output sent to the
> chan builds up and is never processed. I can process it by replacing
> isEmptyChan/readChan with getChanContents but then my logger thread
> hangs forever (right semantics) and hangs everything else that waits
> for the logger thread to check an MVar and exit.

yes, because the logger thread has exited.

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

Re: [Haskell-cafe] questions on lazy pattern, StateT monad

[Wolfgang Jeltsch]

Am Mittwoch, 23. November 2005 10:03 schrieb Fan Wu:
> [...]

> I'm puzzled over this line:
>
> ~(a,s') <- lift (mplus m1' m2')

Why is this line in Monad.State.StateT?  Recently, we discussed that StateT 
does *not* use a lazy pattern here but that it should be changed to using 
one.  So where did you see this lazy pattern?

> [...]

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

Re: [Haskell-cafe] Function application like a Unix pipe

[Henning Thielemann]

On Wed, 23 Nov 2005, Udo Stenzel wrote:


Scherrer, Chad wrote:

Maybe my point wasn't clear. Of course this idea of comparing lazy
evaluation to Unix pipes is very old (long before July 2004, I'm sure).
The point I'm making is that there is an old idea that may be underused.


It is, and only because (.) is defined all wrong!


Since
 (a . b) x
 a $ b x
 a (b x)

are equivalent, do you also want to reverse function and argument in order 
to match argument order of . and $ ?


That is
 x (b . a)
 x b $ a
 (x b) a
?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Function application like a Unix pipe

[Tomasz Zielonka]

On Wed, Nov 23, 2005 at 11:17:25AM +0100, Udo Stenzel wrote:
> infixl 2 \|
> (\|)  = flip (.) -- though I'm using (&)
> 
> The unix pipe becomes (filter ("foo" `isPrefixOf`) \| sort \| nub) or
> something, which is rather neat, and (#) is used to call "member
> functions", as in

Why not use Control.Arrow.>>> ?
The instance for (->) is exactly what you want, and the syntax is quite
nice:

(filter ("foo" `isPrefixOf`) >>> sort >>> nub)

BTW, using sort before nub is a bit pointless. In fact, using nub for
longer lists is a bad idea.

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

Re: [Haskell-cafe] Records

[Arjen van Weelden]

Ketil Malde wrote:

Cale Gibbard <[EMAIL PROTECTED]> writes:



This really isn't so bad in practice though. I've certainly never been
confused by it. 



Well, what can I say?  Good for you?



You'd have to go out of your way to construct a
situation in which it's potentially confusing



No.



There are much more important issues to deal with than this, really.



Like inventing as many new and wonderful symbolic operators as
possible!  Hey, why not allow quoted function names?  So that I can
defined a function "f " different from "f  "?  Or differentiate
(+4) from completely different  (+ 4), ( +4) and ( + 4) which
*obviously* are entirely differen things?



might be relevant in the IOHCC, but not in ordinary programming.



So why not go for the Obfuscated Language Design Contest instead?



In a sane language, small amounts of whitespace sensitivity are going
to be around no matter what you do.



And if you already are using whitespace to separate words, surely the
logical (not to mention aesthetical) way forward would be to introduce
evene more whitespace sensitivity - here is the Holy Grail
  http://compsoc.dur.ac.uk/whitespace/index.php 


I don't understand why this isn't obvious to people who generally
appear fairly bright, but: introducing extension that turns working
programs into non-working ones is generally a bad idea.  Having it be
due to spacing habits around symbolic operators is worse.  That
spacing changes suddenly starts bringing very complex language
extensions into the picture, with an associated heap of
incomprehensible error messages is *not* a nice thing for anybody -
except, perhaps, the two academics who wrote the paper, and the three
academics who read it.





Okay, I'm being unfair here.  Haskell is an academic language, its
primary purpose is to produce papers, not software.  And as a mere
programmer, I'm in a minority.  I think Haskell is really cool, but I
don't really belong here, and I realize of course that my voice isn't
going to carry a lot of weight.

But IF there is a desire for Haskell to be used for Real Work, I think
there should be a certain degree of stability.  Taking the function
composition operator and turning it into record selection -- depending
on spacing, of course -- is, IMO, madness.

But good luck on those papers, and see you later, probably on the
Clean mailing lists. 


-k


Speaking about Clean...

Clean uses record.field for record selections and it combines record 
syntax (using field names) with array syntax (using indices) in a nice 
way IMHO.


Function composition is defined as: (o) f g = \x -> f (g x)
Using the lower case letter o as an approximation to the mathematical 
symbol. (Actually, it is a macro, but that is a totally different thread.)


http://www.cs.ru.nl/~clean/CleanExtra/report20/chapter5/s52.html may 
give some inspiration for new record syntax (and maybe array syntax).


I'm sorry for promoting Clean on a Haskell list, but both languages are 
very similar yet they have a very different approach to records, so it 
might be interesting to compare them.


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

Re: [Haskell-cafe] Function application like a Unix pipe

[Udo Stenzel]

Scherrer, Chad wrote:
> Maybe my point wasn't clear. Of course this idea of comparing lazy
> evaluation to Unix pipes is very old (long before July 2004, I'm sure).
> The point I'm making is that there is an old idea that may be underused.

It is, and only because (.) is defined all wrong!

The unix pipe is actually function composition.  Its argument (standard
input) isn't explicitly mentioned, so the analogous Haskell code should
do the same.  However, function composition reads backwards, which makes
code quite unreadable, especially when (.), (>>=) and `liftM` (which
also has an all wrong fixity) are mixed.

Im summary, I'd define

infixl 0 #
infixl 1 >>#
infixl 2 \|
(#)   = flip ($)
(>>#) = flip liftM
(\|)  = flip (.) -- though I'm using (&)

The unix pipe becomes (filter ("foo" `isPrefixOf`) \| sort \| nub) or
something, which is rather neat, and (#) is used to call "member
functions", as in

some_map # add key value
 # add something or_other
 # delete old_trash

which actually gives the result one expects when reading it top to bottom.
In summary, (.) is tremendously useful, but it would be even better if
it had the correct argument order.  Unfortunately, this cannot be
corrected any more.


Udo.
-- 
"God is real, unless declared as an Integer." - Unknown Source


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

[Haskell-cafe] Re: Records vs HList

[Keean Schupke]

David Menendez wrote:


Keean Schupke writes:

 


David Menendez wrote:

   


Chris Kuklewicz writes:

 


Would the record system describe at
http://lambda-the-ultimate.org/node/view/1119
also be convertable "into System Fw, GHC's existing, strongly-typeed
intermediate language." ?
   


Probably. Daan's current implementation uses MLF, which I believe is
system F implemented for ML.

(We're talking about the system in Daan Leijen's paper, "Extensible
Records With Scoped Labels". Good stuff.)
 


You can change the project and update operators in the HList library
to behave in exactly this way. At the moment they are constrained to
not allow multiple identical labels in records. If this kind of
access is considered useful, I can add it to the HList distribution.
   



This is true. I've implemented a small subset of HList that's able to
emulate Daan's three record operators using only fundeps and undecidable
instances.

   *Main> let r = foo .=. "Bar" .*. emptyRecord
   *Main> r
   Record{foo="Bar"}
   *Main> let r2 = foo .=. () .*. r  
   *Main> r2

   Record{foo=(),foo="Bar"}
   *Main> r2 .!. foo
   ()
   *Main> (r2 .-. foo) .!. foo
   "Bar"

(This is actually *more* powerful than the system described in Daan's
paper, because labels are first class.)

While this is a testament to the power of Haskell's extended type-class
system, I'm not sure that it can replace a dedicated record system. In
his paper, Daan describes how to implement the records such that field
lookups take O(log n) or even O(1) time. HList can't do better than
O(n).

Of course, in the absence of a powerful record system, HList is the way
to go. Rather than decide on a new record system sight unseen, let's
implement them using HList and see how they feel.E
 

Exactly! I like the idea of being able to construct and modify the 
semantics of a record system
(and with the stuff in the OOHaskell paper you can play with Object 
systems in the same way).


The important point with HLists is not that record syntax should not be 
added to Haskell, but
that we can translate it to the existing type system with no conflicts. 
(ie the type system does not
need to be extended there just needs to be some syntax, with an 
optimised implementation)


HList can do O(log n) by the way, if the labels have order, you can 
implement a binary search
tree of labels (Of course all the accessor functions would need to be 
rewritten).


I wonder if some syntactic support for label creation would make things 
nicer.


Actually one really useful change I would like would be to define type 
class functions over all tuples,
that way you could write O(1) accessor functions on tuples using peano 
number indexes.


class TupleIdx u i t | u i -> t where
   idx :: u -> i -> t
instance (a,b) HNil a where
   (a,_) _ = a
instance (a,b) (HSucc HNil) b where
   (_,b) _ = b
instance (a,b,c) HNil a where
   (a,_,_) = a
instance (a,b,c) (HSucc HNil) b where
   (_,b,_) = b
instance (a,b,c) (HSucc (HSucc HNil)) c where
   (_,_,c) = c

etc...

However I haven't thought very hard about how to represent the complete 
(infinite) set
of instances, but using this you can write products of tuples, and 
create records with O(1)

access times from a pair of tuples.

   Keean

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

[Haskell-cafe] Re: Frag: a First Person Shooting game

[Mun Hon Cheong]

Did you encounter any difficulties in your
development because of Haskell?

Well, Haskell is different compared with other languages
like C. I thought collision detection would be easier
if i could use some local or global variables, but i
managed to get around it.



Was lazy evaluation ever a problem?

I found some space leaks in the game, so i had to profile and
enforce strictness in some areas.



Why did you choose Yampa to program the game
entities? Did this give you a particular advantage?

Me and Sean Seefried thought it that would be interesting
to use FRP in the game. I thought the design of
the Space Invaders game in the paper "The Yampa Arcade"
would work for this game and it did.

We could use Yampa's parallel switchers to simulate game
entities simultaneously without much trouble. I felt
that Yampa offered good encapsulation. State information
could be kept inside the signal function used to define the game entity
and they were updated within that function.  So with a
well designed interface we could add game entities without major
changes to the rest of the program.



Isn't your frame rate a bit low?

Yeah, it does run slower than Quake 3 which would run on
my Pentium II 350 and voodoo3 , currently  i doubt my game could do
the same.

I'm sure there are optimisations that could be used to improve
the games performance.

On my machine with an Athlon 1900+ and a Geforce 4mx the game
runs at 60fps in "leveleg". If you find that the framerate
doesn't go above 60fps, its because its capped at 60.



HopenGL



I didn't find any missing features.

Perhaps a listing of functions that have changed significantly
from the original API could be made? ( I've forgotten which functions
that I had trouble looking for though, but it wasn't because their
gl prefixes were removed)


regards,
Mun


On Tue, 22 Nov 2005, Joel Reymont wrote:


Mun,

I hope this ushers the era of Haskell games! I, for one, was certainly 
looking for something like this.


Did you encounter any difficulties in your development because of Haskell?

Was lazy evaluation ever a problem?

Why did you choose Yampa to program the game entities? Did this give you a 
particular advantage?


Isn't your frame rate a bit low?

Thanks, Joel

On Nov 22, 2005, at 6:05 AM, Mun Hon Cheong wrote:


Frag is a 3D First Person Shooting game.

Features:

*Yampa, a domain-specific embedded language
 for the programming of hybrid systems that
 using the concepts of Functional Reactive
 Programming (FRP) was used to program the
 game entities.


--
http://wagerlabs.com/






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

[Haskell-cafe] questions on lazy pattern, StateT monad

[Fan Wu]

Hi Haskell gurus,

I'm very puzzled on some code I saw in GHC Monad.StateT (which is
about state monad transformers) source and hope you can kindly give me
some insight into this.

newtype StateT s m a  = S (s -> m (a,s))

instance MonadPlus m => MonadPlus (StateT s m) where
  mzero = lift mzero
  mplus m1 m2   = do s <- peek
 let m1' = runState s m1
 m2' = runState s m2
  ???>   ~(a,s') <- lift (mplus m1' m2')
 poke s'
 return a


To illustrate my puzzle, say m is of List type and

   runState s m1 = m1' = [(a1, s1)]
   runState s m2 = m2' = [(a2, s2)]

With the definition of lift (also in the StateT.hs file) as

   instance Trans (StateT s) where
  lift m= S (\s -> do x <- m
  return (x,s))

I got

   lift (mplus m1' m2') = lift ([(a1,s1), (a2,s2)])
=  S (\s -> [ ((a1,s1),s), ((a2,s2),s)])

I'm puzzled over this line:

~(a,s') <- lift (mplus m1' m2')

I think ~(a,s') shall be the value of the (StateT s m a) which is
generated by "lift (mplus m1' m2')". My questions are

- why use lazy pattern?

- how is ~(a,s') extracted from (StateT s m a)? This looks like magic
to me. In the example I have (a1,s1) and (a2,s2) in the lifted monad,
but it seems (a,s') only represents one at a time. It looks like how
data is pulled out of a List monad.

Your help is highly appreciated.

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

RE: Re[2]: [Haskell-cafe] using of data types as kinds

[Simon Peyton-Jones]

Sorry should be fixed now (or shortly when the mirror does its stuff)

Simon

| -Original Message-
| From: Bulat Ziganshin [mailto:[EMAIL PROTECTED]
| Sent: 22 November 2005 19:28
| To: Simon Peyton-Jones
| Cc: haskell-cafe@haskell.org
| Subject: Re[2]: [Haskell-cafe] using of data types as kinds
| 
| Hello Simon,
| 
| Tuesday, November 22, 2005, 8:17:38 PM, you wrote:
| 
| SPJ> I have not written anything about what I plan to do in GHC, but
| SPJ> basically it amounts to allowing you to use a data type as a
| SPJ> kind.  Busy doing GADTs and impredicativity at the moment though
| 
| Simon, i can't download file
| 
| http://research.microsoft.com/~simonpj/papers/boxy/boxy-pldi.ps.gz
| 
| reffered at http://research.microsoft.com/~simonpj/papers/boxy/
| 
| 
| --
| Best regards,
|  Bulatmailto:[EMAIL PROTECTED]
| 
| 

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

RE: [Haskell-cafe] GHCi always optimizes?

[Simon Peyton-Jones]

| Anyway, it's strange that you are experiencing crashes.  IIRC, there
| were problems if you mixed modules compiled with different levels of
| optimisation in the same program, but I am not sure it still happens.

If you can make a reproducible crash, please tar it up and send it to
us.  It shouldn't happen. Ever.

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