Re: [Haskell-cafe] Can't install Haskell Platform (Ubuntu 9.02)

[Gregory Propf]

Yes that worked.

--- On Wed, 9/16/09, Paulo Tanimoto  wrote:

From: Paulo Tanimoto 
Subject: Re: [Haskell-cafe] Can't install Haskell Platform (Ubuntu 9.02)
To: "Gregory Propf" 
Cc: "Haskell-Cafe" 
Date: Wednesday, September 16, 2009, 7:24 PM

Hi Gregory,

On Wed, Sep 16, 2009 at 6:51 PM, Gregory Propf  wrote:
>
> I'm trying to install the Haskell Platform.  I'm using Ubuntu 9.02 and GHC 
> 6.10.4 on a 64 bit AMD and keep getting this crap when I do 'make install'.  
> The stuff builds OK and the script in question does indeed exist.  Anybody 
> know what this is.  I've looked online and none of the other people with this 
> issue seem to know the fix.
>
> Error:
> The mtl-1.1.0.2/Setup script does not exist or cannot be run
>
>

Can you try this:

http://trac.haskell.org/haskell-platform/ticket/84

Let us know if you need help applying the patch.

Paulo



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

Re: [Haskell-cafe] How to understand the 'forall' ?

[Ryan Ingram]

On Wed, Sep 16, 2009 at 11:58 AM, Cristiano Paris wrote:

> On Wed, Sep 16, 2009 at 7:12 PM, Ryan Ingram  wrote:
> > Here's the difference between these two types:
> >
> > test1 :: forall a. a -> Int
> > -- The caller of test1 determines the type for test1
> > test2 :: (forall a. a) -> Int
> > -- The internals of test2 determines what type, or types, to instantiate
> the
> > argument at
>
> I can easily understand your explanation for test2: the type var a is
> closed under existential (?) quantification. I can't do the same for
> test1, even if it seems that a is closed under universal (?)
> quantification as well.
>

Both are universally quantified, but at a different level.  To look at it in
System F-land, you have two levels of types that can get passed in lambdas.
Explicitly:

Haskell:
> test1 :: forall a. a -> Int
> test1 _ = 1
> test2 :: (forall a. a) -> Int
> test2 x = x

explicitly in System F:

test1 = /\a \(x :: a). 1
test2 = \(x :: forall a. a). x @Int

/\ is type-level lambda, and @ is type-level application.

In test1, the caller specifies "a" and then passes in an object of that
type.
In test2, the caller must pass in an object which is of all types, and test2
asks for that object to be instantiated at the type "Int"

> Or, to put it another way, since there are no non-bottom objects of type
> > (forall a. a):
>
> Why?
>

Informally, because you can't create something that can be any type.  For
example, what could the result of

test3 :: (forall a. a) -> Int
test3 x = length (x `asTypeOf` [()])

be?  How could you call it?

> test1 converts *anything* to an Int.
>
> Is the only possible implementation of test1 the one ignoring its
> argument (apart from bottom of course)?
>

There's one way that doesn't entirely ignore its argument.

test4 x = seq x 1

But I don't like to talk about that one :)

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

Re: [Haskell-cafe] Can't install Haskell Platform (Ubuntu 9.02)

[Paulo Tanimoto]

Hi Gregory,

On Wed, Sep 16, 2009 at 6:51 PM, Gregory Propf  wrote:
>
> I'm trying to install the Haskell Platform.  I'm using Ubuntu 9.02 and GHC 
> 6.10.4 on a 64 bit AMD and keep getting this crap when I do 'make install'.  
> The stuff builds OK and the script in question does indeed exist.  Anybody 
> know what this is.  I've looked online and none of the other people with this 
> issue seem to know the fix.
>
> Error:
> The mtl-1.1.0.2/Setup script does not exist or cannot be run
>
>

Can you try this:

http://trac.haskell.org/haskell-platform/ticket/84

Let us know if you need help applying the patch.

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

Re: [Haskell-cafe] Re: A thought about liberating Haskell's syntax

[Gregory Propf]

I just rejoined the list and am a bit new to things here anyway but this sounds 
a lot Lisp's old macro system a little. I'm guessing you're not proposing 
runtime execution of runtime generated code though.  I don't know much about 
Lisp internals but I suspect Lisp runtimes are quite different from any in 
Haskell.  Which leads to my real question - is there any talk of runtime 
compilation and execution capability in any of the extension proposals?  Or 
would that crap all over Haskell's reputation for reliable execution?

--- On Wed, 9/16/09, George Pollard  wrote:

From: George Pollard 
Subject: [Haskell-cafe] Re: A thought about liberating Haskell's syntax
To: "Haskell Café" 
Date: Wednesday, September 16, 2009, 5:44 AM

Also (sorry for the triple-post!) I noticed that in the TH
documentation, it says:

    Type splices are not implemented, and neither are pattern splices

This means, while we could write a preprocessor that would give us, e.g.:

    x :: Set Int
    x = {1,2,3,4}

We cannot splice in the right places to allow:

    x :: {Int}
    x = {1,2,3,4}

    isSetEmpty :: {a} → Bool
    isSetEmpty {} = True
    isSetEmpty _ = False
___
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] Can't install Haskell Platform (Ubuntu 9.02)

[Gregory Propf]

I'm trying to install the Haskell Platform.  I'm using Ubuntu 9.02 and GHC 
6.10.4 on a 64 bit AMD and keep getting this crap when I do 'make install'.  
The stuff builds OK and the script in question does indeed exist.  Anybody know 
what this is.  I've looked online and none of the other people with this issue 
seem to know the fix.

Error:
The mtl-1.1.0.2/Setup script does not exist or cannot be run




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

Re: [Haskell-cafe] How to understand the 'forall' ?

[Dan Weston]

There is no magic here. This is merely explicit type specialization from 
the most general inferred type to something more specific. The 
denotational semantics of a function whose type is specialized does not 
change for those values belonging to the more specialized type.


f :: forall a. (Num a) => a -> a -> a
f x y = x + y

g :: Int -> Int -> Int
g x y = x + y

f and g denote (extensionally) the identical function, differing only in 
their type. g is a specialization of f. It is possible that 
(operationally) f could be slower if the compiler is not clever enough 
to avoid passing a type witness dictionary.


h :: forall b. b -> Char
h = const 'a'

k :: () -> Char
k = const 'a'

data Void
m :: Void -> Char
m = const 'a'

n :: (forall a. a) -> Char
n = const 'a'

h, k, m, and n yield *identical* values for any input compatible with 
the type of any two of the functions.


In constrast, whether a function is strict or non-strict is *not* a 
function of type specialization. Strictness is not reflected in the type 
system. Compare:


u x y = y `seq` const x y
v x y = const x y

Both have type forall a b. a -> b -> a but are denotationally different 
functions:


u 2 undefined = undefined
v 2 undefined = 2

Cristiano Paris wrote:

On Wed, Sep 16, 2009 at 7:12 PM, Ryan Ingram  wrote:

Here's the difference between these two types:

test1 :: forall a. a -> Int
-- The caller of test1 determines the type for test1
test2 :: (forall a. a) -> Int
-- The internals of test2 determines what type, or types, to instantiate the
argument at


I can easily understand your explanation for test2: the type var a is
closed under existential (?) quantification. I can't do the same for
test1, even if it seems that a is closed under universal (?)
quantification as well.


Or, to put it another way, since there are no non-bottom objects of type
(forall a. a):


Why?


test1 converts *anything* to an Int.


Is the only possible implementation of test1 the one ignoring its
argument (apart from bottom of course)?


test2 converts *nothing* to an Int

-- type-correct implementation
-- instantiates the (forall a. a) argument at Int
test2 x = x



-- type error, the caller chose "a" and it is not necessarily Int
-- test1 x = x

-- type-correct implementation: ignore the argument
test1 _ = 1


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] weak pointers and memoization (was Re: memoization)

[Rodney Price]

How does garbage collection work in an example like the one below?  You
memoize a function with some sort of lookup table, which stores function
arguments as keys and function results as values.  As long as the
function remains in scope, the keys in the lookup table remain in
memory, which means that the keys themselves always remain reachable
and they cannot be garbage collected.  Right?

So what do you do in the case where you know that, after some period of
time, some entries in the lookup table will never be accessed?  That is,
there are no references to the keys for some entries remaining, except
for the references in the lookup table itself.  You'd like to allow the
memory occupied by the keys to be garbage collected.  Otherwise, if the
function stays around for a long time, the size of the lookup table
always grows.  How do you avoid the space leak?

I notice that there is a function in Data.IORef,

mkWeakIORef :: IORef a -> IO () -> IO (Weak (IORef a))

which looks promising.  In the code below, however, there's only one
IORef, so either the entire table gets garbage collected or none of it
does.

I've been reading the paper "Stretching the storage manager: weak
pointers and stable names in Haskell," which seems to answer my
question.  When I attempt to run the memoization code in the paper on
the simple fib example, I find that -- apparently due to lazy
evaluation -- no new entries are entered into the lookup table, and
therefore no lookups are ever successful!

So apparently there is some interaction between lazy evaluation and
garbage collection that I don't understand.  My head hurts.  Is it
necessary to make the table lookup operation strict?  Or is it
something entirely different that I am missing?

-Rod


On Thu, 10 Sep 2009 18:33:47 -0700
Ryan Ingram  wrote:

> 
> memoIO :: Ord a => (a -> b) -> IO (a -> IO b)
> memoIO f = do
>cache <- newIORef M.empty
>return $ \x -> do
>m <- readIORef cache
>case M.lookup x m of
>Just y -> return y
>Nothing -> do let res = f x
>  writeIORef cache $ M.insert x res m
>  return res
> 
> memo :: Ord a => (a -> b) -> (a -> b)
> memo f = unsafePerformIO $ do
> fmemo <- memoIO f
> return (unsafePerformIO . fmemo)
> 
> I don't think there is any valid transformation that breaks this,
> since the compiler can't lift anything through unsafePerformIO.  Am I
> mistaken?
> 
>   -- ryan

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

Re[2]: [Haskell-cafe] GHC threaded runtimes and pure functions

[Bulat Ziganshin]

Hello Andrew,

Wednesday, September 16, 2009, 11:31:22 PM, you wrote:

>> That makes sense.  So maybe I should split my mapping into two
>> parallel ones or however many CPUs there are using par.
>>

> If you're going to use par, it doesn't really matter how many sparks you
> create. You just need to avoid creating millions of really tiny sparks.
> You could create, say, eight and let GHC figure out the rest itself...

since these are green threads, 1 millisecond sparks should be
acceptable and may be even 1 microsecod too. afair, overhead expenses
was significantly reduced in ghc 6.12, soon to be released


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] GHC threaded runtimes and pure functions

[Andrew Coppin]

Gregory Propf wrote:
That makes sense.  So maybe I should split my mapping into two 
parallel ones or however many CPUs there are using par.




If you're going to use par, it doesn't really matter how many sparks you 
create. You just need to avoid creating millions of really tiny sparks. 
You could create, say, eight and let GHC figure out the rest itself...


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

Re: [Haskell-cafe] How to understand the 'forall' ?

[Cristiano Paris]

On Wed, Sep 16, 2009 at 7:12 PM, Ryan Ingram  wrote:
> Here's the difference between these two types:
>
> test1 :: forall a. a -> Int
> -- The caller of test1 determines the type for test1
> test2 :: (forall a. a) -> Int
> -- The internals of test2 determines what type, or types, to instantiate the
> argument at

I can easily understand your explanation for test2: the type var a is
closed under existential (?) quantification. I can't do the same for
test1, even if it seems that a is closed under universal (?)
quantification as well.

> Or, to put it another way, since there are no non-bottom objects of type
> (forall a. a):

Why?

> test1 converts *anything* to an Int.

Is the only possible implementation of test1 the one ignoring its
argument (apart from bottom of course)?

> test2 converts *nothing* to an Int
>
> -- type-correct implementation
> -- instantiates the (forall a. a) argument at Int
> test2 x = x

> -- type error, the caller chose "a" and it is not necessarily Int
> -- test1 x = x
>
> -- type-correct implementation: ignore the argument
> test1 _ = 1

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

Re: [Haskell-cafe] Parallel lazy zip

[Daniel Peebles]

Would using

zipWith (\x y -> x `par` y `pseq` x + y) (expensiveList 1) (expensiveList 2)

do it? it seems to help a bit on my machine, but doesn't give me twice
the performance

On Wed, Sep 16, 2009 at 10:59 AM, Henning Thielemann
 wrote:
>
> When reading
>  http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html
>  I got the impression, that when I want to compute in parallel I have to
> suppress laziness at all costs, otherwise only a neglible portion of the
> code is run in parallel. How can I parallelize the computation of two lazily
> generated lists, where the list generation is expensive, but the combination
> of the lists is cheap?
>
> For example:
>
>
> module Main where
>
> expensiveList :: Int -> [Int]
> expensiveList n =
>   map (\m -> sum [n..m]) [1000..]
>
> sequentialZip :: [Int]
> sequentialZip =
>   zipWith (+)
>      (expensiveList 1)
>      (expensiveList 2)
>
> main :: IO ()
> main =
>   mapM_ print $ take 10 sequentialZip
>
>
> It seems to me that this program must run almost twice as fast when using
> two cores, because the expensive lists can be computed perfectly in
> parallel. It requires however, that the zipWith can fetch data lazily across
> threads. However applying a Parallel strategy to the expensive list, will
> certainly try to evaluate it completely.
> ___
> 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] How to understand the 'forall' ?

[Ryan Ingram]

Here's the difference between these two types:

test1 :: forall a. a -> Int
-- The caller of test1 determines the type for test1
test2 :: (forall a. a) -> Int
-- The internals of test2 determines what type, or types, to instantiate the
argument at

Or, to put it another way, since there are no non-bottom objects of type
(forall a. a):
test1 converts *anything* to an Int.
test2 converts *nothing* to an Int

-- type-correct implementation
-- instantiates the (forall a. a) argument at Int
test2 x = x

-- type error, the caller chose "a" and it is not necessarily Int
-- test1 x = x

-- type-correct implementation: ignore the argument
test1 _ = 1

  -- ryan

On Wed, Sep 16, 2009 at 1:04 AM, Cristiano Paris  wrote:

> On Tue, Sep 15, 2009 at 11:38 PM, Daniel Fischer
>  wrote:
> > ...
> >> foo :: forall a. a -> a
> >
> > This is exactly the same type as
> >
> > foo :: a -> a
> >
> > (unless you're using ScopedTypeVariables and there's a type variable a in
> scope), since
> > type signatures are implicitly forall'd.
>
> Yep, perhaps I used the wrong example. What about foo: (forall a. a) ->
> Int?
>
> 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

Re: [Haskell-cafe] Re: Using tiny (atomic) mutables between multiple threads

[Bulat Ziganshin]

Hello Simon,

Wednesday, September 16, 2009, 7:05:04 PM, you wrote:
>> 1. Might readMVar really be computationally expensive under heavy load,
>> (with all it's wonderful blocking features)? How much (approximately) more
>> expensive, comparing to a assembler's "mov"?

> Probably 10-100 times more expensive than a mov, depending on the cache
> state.

many years ago, with ghc 6.6 and duron-1000, i had million or two of
withMVar per second. anyway, this sort of things is easier to test
herself


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Haskell -> .NET

[Paulo Tanimoto]

Hello!

On Wed, Sep 16, 2009 at 8:54 AM, Peter Verswyvelen  wrote:
> I heard that compiling Haskell to Java is not obvious since tail calls
> are not supported.
>
> .NET's intermediate language (IL) does support tail calls, however it
> is currently slower than regular calls, and is not always supported by
> all JITs.
>
> But given that F# will soon be officially released, I hope that
> eventually tail calls will work as expected, and fast
>
> See e.g. 
> http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx
>
> So, might it be worth considering a .NET backend for a Haskell compiler?
>
> Peter Verswyvelen
>

I remember reading this a while ago -- I think SPJ wrote it.  It may
be relevant for this discussion.

http://www.haskell.org/haskellwiki/GHC:FAQ#.NET.2FJVM_Availability

Take care,

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

[Haskell-cafe] Some question about c2hs.

[Andy Stewart]

Hi all, 

I try to binding Haskell to VTE library.
Below are Vte.chs file i wrote.



Vte.chs
Description: Binary data


I use c2hs with below command

LANG=C c2hs -d trace -l $(pkg-config --cflags vte | sed 's/-I/-C-I/g') 
vte/vte.h Vte.chs

generate Vte.hs file.

When i compile Vte.hs file, i got below error: 

Vte.chs:67:89:
Couldn't match expected type `Widget' against inferred type `()'
  Expected type: IO (Ptr Widget)
  Inferred type: IO (Ptr ())
In the second argument of `($)', namely `vte_terminal_new'
In the second argument of `($)', namely
`liftM (castPtr :: Ptr Widget -> Ptr Terminal) $ vte_terminal_new'

for binding code:

terminalNew :: IO Terminal
terminalNew = 
makeNewObject mkTerminal $ liftM (castPtr :: Ptr Widget -> Ptr 
Terminal) $ {#call unsafe
terminal_new#}

In C code, fucntion `GtkWidget *vte_terminal_new(void);' return `IO (Ptr
Widget), then i use castPtr transform (Ptr Widget) to (Ptr Terminal),
right?

Why GHC report function `vte_terminal_new` return `IO (Ptr ())', I do
something wrong?

Any help?

Thanks!

  -- Andy


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

[Haskell-cafe] Re: Using tiny (atomic) mutables between multiple threads

[Simon Marlow]

On 13/09/2009 07:45, Belka wrote:


Hello, Haskell Cafe!

I used an MVar to signalize to many threads, when it's time to finish their
business (I called it a LoopBreaker). Recently I realized, that it might be
too expensive (to use MVar) for cases when threads are many and all of them
read my LoopBreaker intensively. This assumption appeared in a case, where I
widely (in many threads) used my stopableThreadDelay, which checks
LoopBreaker every d = 100 milliseconds.

So I decided that I don't really need all the great features, that MVar
provides, and that a simpler memory usage concept might be applied here. In
a most (machinely) reduced view, all I need is a mutable byte. It would be
thread safe, since reading and writing are atomic operations. I then wrote a
simple experimental module (my first experience with Ptr in Haskell):
-
import Control.Monad
import Foreign.Marshal.Utils
import Foreign.Ptr
import Foreign.Storable

newtype MyVar a = MyVar { mvPtr :: Ptr a }

newMyVar :: Storable a =>  a ->  IO (MyVar a)
newMyVar val = MyVar `liftM` new val

readMyVar :: Storable a =>  (MyVar a) ->  IO a
readMyVar val = peek $ mvPtr val

writeMyVar :: Storable a =>  (MyVar a) ->  a ->  IO ()
writeMyVar var val = poke (mvPtr var) val
-

Now, please, help me to answer few questions about all it:
1. Might readMVar really be computationally expensive under heavy load,
(with all it's wonderful blocking features)? How much (approximately) more
expensive, comparing to a assembler's "mov"?


Probably 10-100 times more expensive than a mov, depending on the cache 
state.



2. Are the above readMyVar and writeMyVar really atomic? Or are they atomic
only if I apply them to  type?


It depends what you mean by atomic.  If you mean is readMyVar atomic 
with respect to writeMyVar, then it depends on which type you're 
instantiating MyVar with, and what machine you're running on.  e.g. a 
MyVar Word32 will probably be atomic, but MyVar Word64 might only be 
atomic on a 64-bit platform.  You'd also have to check your machine's 
architecture manuals to be sure.  MyVar Word8 is atomic on some 
platforms but not others.


The upshot is that it's not a good idea to rely on atomicity here.

I'd recommend using IORef and atomicModifyIORef when you need atomicity.


3. Are the above readMyVar and writeMyVar safe against asynchronous
exceptions? Or again, only if I use  type?


It depends what you mean by "safe", but probably you're worried about 
atomicity again.


It's pretty unusual to want just a mutable variable for communication 
between threads, normally you need *some* kind of synchronisation. 
What's your application?


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

[Haskell-cafe] Parallel lazy zip

[Henning Thielemann]

When reading
  http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html
 I got the impression, that when I want to compute in parallel I have to 
suppress laziness at all costs, otherwise only a neglible portion of the 
code is run in parallel. How can I parallelize the computation of two 
lazily generated lists, where the list generation is expensive, but the 
combination of the lists is cheap?


For example:


module Main where

expensiveList :: Int -> [Int]
expensiveList n =
   map (\m -> sum [n..m]) [1000..]

sequentialZip :: [Int]
sequentialZip =
   zipWith (+)
  (expensiveList 1)
  (expensiveList 2)

main :: IO ()
main =
   mapM_ print $ take 10 sequentialZip


It seems to me that this program must run almost twice as fast when using 
two cores, because the expensive lists can be computed perfectly in 
parallel. It requires however, that the zipWith can fetch data lazily 
across threads. However applying a Parallel strategy to the expensive 
list, will certainly try to evaluate it completely.

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

Re: [Haskell-cafe] GHC threaded runtimes and pure functions

[Gregory Propf]

That makes sense.  So maybe I should split my mapping into two parallel ones or 
however many CPUs there are using par.

--- On Wed, 9/16/09, Bulat Ziganshin  wrote:

From: Bulat Ziganshin 
Subject: Re: [Haskell-cafe] GHC threaded runtimes and pure functions
To: "Gregory Propf" 
Cc: "Haskell-Cafe" 
Date: Wednesday, September 16, 2009, 6:29 AM

Hello Gregory,

Wednesday, September 16, 2009, 5:17:01 PM, you wrote:

no. additional threads are launched for i/o system and, as you
requested by -N2 for haskell workload. but ghc don't auto-parallelize
your code. it's a bit too hard, since making too much threads (e.g.
one for every addition) will make bookkeeping too heavy and it's
impossible to automatically deduce how much operations each
computation will require. instead, you are provided with 'par'
primitive to show compiler explicitly what parts to run in parallel

> One of the things I liked about Haskell was the notion of pure
> functions and the fact that they can be, in theory, automatically
> parallelized on multicore hardware. I think this will become a huge
> deal in a few years as cores multiply.  My question is simply this:
> under GHC is this what really happens with, say a mapping over a
> pure function.  Yes, I compiled with --threaded and am using the
> +RTS -N2 options on my dual core machine.  Here's the code I wrote
> as a speed test.  It just doesn't seem any faster with -N2.  Using
> the ps command I found that multiple threads are indeed launched
> (this is Linux) but all but one show as being in a state of waiting
> for some event to finish (the ps output flags them all 'Sl'.




> main = do rg <- getStdGen
>   let rs = take  1000 $ randomRs (1::Int,10::Int) rg
>   rs'= map (\n -> n*n) rs
>   print rs'

>   


-- 
Best regards,
 Bulat                            mailto:bulat.zigans...@gmail.com




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

RE: [Haskell-cafe] Haskell -> .NET

[Sittampalam, Ganesh]

I think Sigbjorn's binding (http://haskell.forkio.com/dotnet/
  as linked below) is the most
complete and likely to work, but it's still just a binding not a
compiler backend.



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Matthew
Podwysocki
Sent: 16 September 2009 15:25
To: Peter Verswyvelen
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Haskell -> .NET


There was in fact another attempt as well, Salsa:
http://haskell.org/haskellwiki/Salsa

This showed quite a bit of promise but unfortunately was not more than
just an experiment.

Matt


On Wed, Sep 16, 2009 at 10:21 AM, Peter Verswyvelen 
wrote:


Yes, but interop only touches the surface of what is possible.

When a Haskell compiler could create IL code, it would be
possible to
use the generated code inside a sandbox, e.g. to be used on the
web as
loadable Silverlight code.

Of course the same could be said about other virtual machines,
such as
Flash or Java, but I don't know about the tail call issue here.

I guess for now F# would be the best option, but it would be
awesome
if Haskell compilers could have more backends.

I realize this is a very big undertaking, and has been mentioned
before, but it doesn't hurt to refresh the cache lines once in a
while, so maybe some bright student picks this up and hacks
together
something cool during the summer :)


On Wed, Sep 16, 2009 at 4:03 PM, Paul Sujkov 
wrote:
> Hi Peter,
>
> it seems that this question has been already raised before:
>
>
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html
>
> and there are some .Net interop implementations on the net (it
is a question
> how mature they are, however):
>
> http://php.cin.ufpe.br/~haskell/haskelldotnet/
 
> http://haskell.forkio.com/dotnet/
>
> 2009/9/16 Peter Verswyvelen 
>>
>> I heard that compiling Haskell to Java is not obvious since
tail calls
>> are not supported.
>>
>> .NET's intermediate language (IL) does support tail calls,
however it
>> is currently slower than regular calls, and is not always
supported by
>> all JITs.
>>
>> But given that F# will soon be officially released, I hope
that
>> eventually tail calls will work as expected, and fast
>>
>> See e.g.
>>
http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-imp
rovements-in-net-framework-4.aspx
>>
>> So, might it be worth considering a .NET backend for a
Haskell compiler?
>>
>> Peter Verswyvelen
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Regards, Paul Sujkov
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC threaded runtimes and pure functions

[Don Stewart]

gregorypropf:
> One of the things I liked about Haskell was the notion of pure functions and
> the fact that they can be, in theory, automatically parallelized on multicore
> hardware. I think this will become a huge deal in a few years as cores
> multiply.  My question is simply this: under GHC is this what really happens
> with, say a mapping over a pure function.  Yes, I compiled with --threaded and
> am using the +RTS -N2 options on my dual core machine.  Here's the code I 
> wrote
> as a speed test.  It just doesn't seem any faster with -N2.  Using the ps
> command I found that multiple threads are indeed launched (this is Linux) but
> all but one show as being in a state of waiting for some event to finish (the
> ps output flags them all 'Sl'.
> 
> 
> 
> 
> main = do rg <- getStdGen
>   let rs = take 1000 $ randomRs (1::Int,10::Int) rg
>   rs'= map (\n -> n*n) rs
>   print rs'


GHC doesn't auto-parallelize.

You would have to use one of the several fine parallelism constructrs to
achieve a speedup.

Here's a recent tutorial,


http://donsbot.wordpress.com/2009/09/05/defun-2009-multicore-programming-in-haskell-now/

and some background reading,


http://donsbot.wordpress.com/2009/09/03/parallel-programming-in-haskell-a-reading-list/

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

Re: [Haskell-cafe] Haskell -> .NET

[Matthew Podwysocki]

There was in fact another attempt as well, Salsa:
http://haskell.org/haskellwiki/Salsa

This showed quite a bit of promise but unfortunately was not more than just
an experiment.

Matt

On Wed, Sep 16, 2009 at 10:21 AM, Peter Verswyvelen wrote:

> Yes, but interop only touches the surface of what is possible.
>
> When a Haskell compiler could create IL code, it would be possible to
> use the generated code inside a sandbox, e.g. to be used on the web as
> loadable Silverlight code.
>
> Of course the same could be said about other virtual machines, such as
> Flash or Java, but I don't know about the tail call issue here.
>
> I guess for now F# would be the best option, but it would be awesome
> if Haskell compilers could have more backends.
>
> I realize this is a very big undertaking, and has been mentioned
> before, but it doesn't hurt to refresh the cache lines once in a
> while, so maybe some bright student picks this up and hacks together
> something cool during the summer :)
>
> On Wed, Sep 16, 2009 at 4:03 PM, Paul Sujkov  wrote:
> > Hi Peter,
> >
> > it seems that this question has been already raised before:
> >
> > http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html
> >
> > and there are some .Net interop implementations on the net (it is a
> question
> > how mature they are, however):
> >
> > http://php.cin.ufpe.br/~haskell/haskelldotnet/
> > http://haskell.forkio.com/dotnet/
> >
> > 2009/9/16 Peter Verswyvelen 
> >>
> >> I heard that compiling Haskell to Java is not obvious since tail calls
> >> are not supported.
> >>
> >> .NET's intermediate language (IL) does support tail calls, however it
> >> is currently slower than regular calls, and is not always supported by
> >> all JITs.
> >>
> >> But given that F# will soon be officially released, I hope that
> >> eventually tail calls will work as expected, and fast
> >>
> >> See e.g.
> >>
> http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx
> >>
> >> So, might it be worth considering a .NET backend for a Haskell compiler?
> >>
> >> Peter Verswyvelen
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> >
> > --
> > Regards, Paul Sujkov
> >
> ___
> 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] Haskell -> .NET

[Peter Verswyvelen]

Yes, but interop only touches the surface of what is possible.

When a Haskell compiler could create IL code, it would be possible to
use the generated code inside a sandbox, e.g. to be used on the web as
loadable Silverlight code.

Of course the same could be said about other virtual machines, such as
Flash or Java, but I don't know about the tail call issue here.

I guess for now F# would be the best option, but it would be awesome
if Haskell compilers could have more backends.

I realize this is a very big undertaking, and has been mentioned
before, but it doesn't hurt to refresh the cache lines once in a
while, so maybe some bright student picks this up and hacks together
something cool during the summer :)

On Wed, Sep 16, 2009 at 4:03 PM, Paul Sujkov  wrote:
> Hi Peter,
>
> it seems that this question has been already raised before:
>
> http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html
>
> and there are some .Net interop implementations on the net (it is a question
> how mature they are, however):
>
> http://php.cin.ufpe.br/~haskell/haskelldotnet/
> http://haskell.forkio.com/dotnet/
>
> 2009/9/16 Peter Verswyvelen 
>>
>> I heard that compiling Haskell to Java is not obvious since tail calls
>> are not supported.
>>
>> .NET's intermediate language (IL) does support tail calls, however it
>> is currently slower than regular calls, and is not always supported by
>> all JITs.
>>
>> But given that F# will soon be officially released, I hope that
>> eventually tail calls will work as expected, and fast
>>
>> See e.g.
>> http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx
>>
>> So, might it be worth considering a .NET backend for a Haskell compiler?
>>
>> Peter Verswyvelen
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Regards, Paul Sujkov
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell -> .NET

[Paul Sujkov]

Hi Peter,

it seems that this question has been already raised before:

http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html

and there are some .Net interop implementations on the net (it is a question
how mature they are, however):

http://php.cin.ufpe.br/~haskell/haskelldotnet/
http://haskell.forkio.com/dotnet/

2009/9/16 Peter Verswyvelen 

> I heard that compiling Haskell to Java is not obvious since tail calls
> are not supported.
>
> .NET's intermediate language (IL) does support tail calls, however it
> is currently slower than regular calls, and is not always supported by
> all JITs.
>
> But given that F# will soon be officially released, I hope that
> eventually tail calls will work as expected, and fast
>
> See e.g.
> http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx
>
> So, might it be worth considering a .NET backend for a Haskell compiler?
>
> Peter Verswyvelen
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

[Haskell-cafe] Haskell -> .NET

[Peter Verswyvelen]

I heard that compiling Haskell to Java is not obvious since tail calls
are not supported.

.NET's intermediate language (IL) does support tail calls, however it
is currently slower than regular calls, and is not always supported by
all JITs.

But given that F# will soon be officially released, I hope that
eventually tail calls will work as expected, and fast

See e.g. 
http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx

So, might it be worth considering a .NET backend for a Haskell compiler?

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

Re: [Haskell-cafe] Building a monoid, continuation-passing style

[Edward Kmett]

For reference Oleg's indexed continuation monad is packaged on hackage in
category-extras as:

http://hackage.haskell.org/packages/archive/category-extras/latest/doc/html/Control-Monad-Indexed-Cont.html
-Edward Kmett
On Wed, Sep 16, 2009 at 7:07 AM, Martijn van Steenbergen <
mart...@van.steenbergen.nl> wrote:

> David Menendez wrote:
>
>> I'm reminded of the parameterized monad of continuations that Oleg
>> mentioned a few years back.
>>
>> 
>>
>
> This is all very interesting, thank you both for the pointers!
>
> I was trying to get rid of the newtypes but couldn't think of how to do
> that. I can't believe the solution now is as simple as (m -> r) -> a.
> There's hardly any code left, now.
>
> The fact that it all exists already is nice on the one hand and sad on the
> other. :-)
>
> I will have to look into parametrized monads and parametrized applicatives.
>
> Thanks again,
>
> Martijn.
>
> ___
> 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] GHC threaded runtimes and pure functions

[Bulat Ziganshin]

Hello Gregory,

Wednesday, September 16, 2009, 5:17:01 PM, you wrote:

no. additional threads are launched for i/o system and, as you
requested by -N2 for haskell workload. but ghc don't auto-parallelize
your code. it's a bit too hard, since making too much threads (e.g.
one for every addition) will make bookkeeping too heavy and it's
impossible to automatically deduce how much operations each
computation will require. instead, you are provided with 'par'
primitive to show compiler explicitly what parts to run in parallel

> One of the things I liked about Haskell was the notion of pure
> functions and the fact that they can be, in theory, automatically
> parallelized on multicore hardware. I think this will become a huge
> deal in a few years as cores multiply.  My question is simply this:
> under GHC is this what really happens with, say a mapping over a
> pure function.  Yes, I compiled with --threaded and am using the
> +RTS -N2 options on my dual core machine.  Here's the code I wrote
> as a speed test.  It just doesn't seem any faster with -N2.  Using
> the ps command I found that multiple threads are indeed launched
> (this is Linux) but all but one show as being in a state of waiting
> for some event to finish (the ps output flags them all 'Sl'.




> main = do rg <- getStdGen
>   let rs = take  1000 $ randomRs (1::Int,10::Int) rg
>   rs'= map (\n -> n*n) rs
>   print rs'

>   


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

[Haskell-cafe] GHC threaded runtimes and pure functions

[Gregory Propf]

One of the things I liked about Haskell was the notion of pure functions and 
the fact that they can be, in theory, automatically parallelized on multicore 
hardware. I think this will become a huge deal in a few years as cores 
multiply.  My question is simply this: under GHC is this what really happens 
with, say a mapping over a pure function.  Yes, I compiled with --threaded and 
am using the +RTS -N2 options on my dual core machine.  Here's the code I wrote 
as a speed test.  It just doesn't seem any faster with -N2.  Using the ps 
command I found that multiple threads are indeed launched (this is Linux) but 
all but one show as being in a state of waiting for some event to finish (the 
ps output flags them all 'Sl'.




main = do rg <- getStdGen
  let rs = take 1000 $ randomRs (1::Int,10::Int) rg
  rs'= map (\n -> n*n) rs
  print rs'



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

[Haskell-cafe] Re: A thought about liberating Haskell's syntax

[George Pollard]

Also (sorry for the triple-post!) I noticed that in the TH
documentation, it says:

Type splices are not implemented, and neither are pattern splices

This means, while we could write a preprocessor that would give us, e.g.:

x :: Set Int
x = {1,2,3,4}

We cannot splice in the right places to allow:

x :: {Int}
x = {1,2,3,4}

isSetEmpty :: {a} → Bool
isSetEmpty {} = True
isSetEmpty _ = False
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A thought about liberating Haskell's syntax

[George Pollard]

Oh, and output is as expected:

> ./test
(1,2,3)
1
(1,(2,3))
((1,2),3)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A thought about liberating Haskell's syntax

[George Pollard]

Just occurred to me that you can actually do this with a preprocessor.
If we extract the "template" declarations to a separate module, then
it can happen something like this (I have corrected some errors in the
above code):

 main.hs 

import Language.Haskell.TH
import QList
import Control.Monad

{-

pretend we had this:

main = do
print (1,2,3)
print (1)
print (1,(2,3))
print ((1,2),3)

- "template_outfix_lparen_rparen_expression" matches normal parens in
the expression context
- we also have a template operator for commas

The rules for the preprocessor are: inputs to the templates are always
wrapped in [| |].
The templates are wrapped in $().

This explains some of the extraneous nesting below (trying to pretend
I'm a machine!)

-}

main = do
print $(
 template_outfix_lparen_rparen_expression `fmap` [|
  $( comma `fmap` [| 1 |] `ap` (comma `fmap` [| 2 |] `ap` [| 3 |]) )
 |])
print $(
 template_outfix_lparen_rparen_expression `fmap` [|
  $( [| 1 |] )
 |])
print $(
 template_outfix_lparen_rparen_expression `fmap` [|
  $( comma `fmap` [| 1 |] `ap` [|
$(template_outfix_lparen_rparen_expression `fmap` [| $( comma
`fmap` [| 2 |] `ap` [| 3 |]) |] ) |] )
 |])
print $(
 template_outfix_lparen_rparen_expression `fmap` [|
  $( comma `fmap` [| $( template_outfix_lparen_rparen_expression
`fmap` [| $(comma `fmap` [| 1 |] `ap` [| 2 |]) |] ) |]
`ap` [| 3 |]  )
 |])

-- QList.hs ---
{-
contains the templates and QList.
(the module created by preprocessor would usually only include
templates, with QList being a helper module)
-}

module QList
where
import Debug.Trace
import Language.Haskell.TH

data QList a = QCons a (QList a) | QNil

comma :: Exp → Exp → Exp
a `comma` b@(AppE (AppE (ConE x) _) _)
| x == qconsName = a `qcons` b
| otherwise  = a `qcons` (b `qcons` qnil)
a `comma` b = a `qcons` (b `qcons` qnil)

qnil :: Exp
qnil = ConE (mkName "QNil")

qcons :: Exp → Exp → Exp
a `qcons` b = (ConE (mkName "QCons")) `AppE` a `AppE` b

template_outfix_lparen_rparen_expression :: Exp → Exp
template_outfix_lparen_rparen_expression x = case x of
(AppE (AppE (ConE y) _) _) → if y == qconsName
then TupE $ fromQList x
else x
_ → x

fromQList :: Exp → [Exp]
fromQList (AppE (AppE (ConE c) h) t)
| c == qconsName = h:fromQList t
| otherwise  = error "malformed qlist (head)"
fromQList (ConE n)
| n == mkName "QNil" = []
| otherwise = error "malformed qlist (tail)"

qconsName = mkName "QCons"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Building a monoid, continuation-passing style

[Martijn van Steenbergen]

David Menendez wrote:

I'm reminded of the parameterized monad of continuations that Oleg
mentioned a few years back.




This is all very interesting, thank you both for the pointers!

I was trying to get rid of the newtypes but couldn't think of how to do 
that. I can't believe the solution now is as simple as (m -> r) -> a. 
There's hardly any code left, now.


The fact that it all exists already is nice on the one hand and sad on 
the other. :-)


I will have to look into parametrized monads and parametrized applicatives.

Thanks again,

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

Re: [Haskell-cafe] Hopefully simple monad question

[Miguel Mitrofanov]

O, great. I didn't know you can write it this way.

Tom Nielsen wrote:

newtype VMT m a =
  VMT {runVMT :: StateT VMState m a}
deriving (Monad, MonadIO, MonadTrans, TransM, MonadState VMState)

works  here (ghc-6.10.3)

On Wed, Sep 16, 2009 at 11:42 AM, Miguel Mitrofanov
 wrote:


newtype VMT m a =
 VMT {runVMT :: StateT VMState m a}
   deriving (Monad, MonadIO, MonadTrans, TransM)

Unfortunately, you can't automatically derive MonadState, since it's a
multi-paremeter type class. You'll have to write down the derivation
yourself.

___
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] Hopefully simple monad question

[Tom Nielsen]

newtype VMT m a =
  VMT {runVMT :: StateT VMState m a}
    deriving (Monad, MonadIO, MonadTrans, TransM, MonadState VMState)

works  here (ghc-6.10.3)

On Wed, Sep 16, 2009 at 11:42 AM, Miguel Mitrofanov
 wrote:

> newtype VMT m a =
>  VMT {runVMT :: StateT VMState m a}
>    deriving (Monad, MonadIO, MonadTrans, TransM)
>
> Unfortunately, you can't automatically derive MonadState, since it's a
> multi-paremeter type class. You'll have to write down the derivation
> yourself.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hopefully simple monad question

[Miguel Mitrofanov]

Well, it's almost always better to reuse as much code as possible. But I 
don't think "type" is an answer here. I recommend using a "newtype", 
enabling "GeneralizedNewtypeDeriving" and deriving as much as possible:


{-# LANGUAGE GeneralizedNewtypeDeriving #-}
...
newtype VM a =
  VM {runVM :: State VMState a} deriving Monad

or

newtype VMT m a =
  VMT {runVMT :: StateT VMState m a}
deriving (Monad, MonadIO, MonadTrans, TransM)

Unfortunately, you can't automatically derive MonadState, since it's a 
multi-paremeter type class. You'll have to write down the derivation 
yourself.


Gregory Propf wrote:
I'm playing around with a little program that implements a simple 
virtual machine.  I want to use a monad to represent machine state.  I 
created a data type for the machine (VM) and a monadic type for the 
monadic computations using it.  I declared this an instance of 
MonadState and Monad and created the usual operators.  That stuff 
works.  My issue is that I want to run some functions in the machine 
monad, call it VMS - "virtual machine w/state" and then pull the 
underlying VM data structure out and print it.


I've read about monad transformers, lift, liftM, liftIO and all these 
instances in the libraries like MonadIO and am rather confused.  The 
most sensible conclusion I can reach is that I probably need to create 
my own Transformer monad and define liftIO.  Is this where I need to 
go?  Also, my VMS monad doesn't really do anything different from the 
State monad except explicitly specify that state is a VM and not a 
generic type.  Am I doing too much work creating my own instances here?  
Would a simple "type" statement work?






___
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] Hopefully simple monad question

[Holger Siegel]

Am Mittwoch, den 16.09.2009, 03:23 -0700 schrieb Gregory Propf:
> I'm playing around with a little program that implements a simple
> virtual machine.  I want to use a monad to represent machine state.  I
> created a data type for the machine (VM) and a monadic type for the
> monadic computations using it.  I declared this an instance of
> MonadState and Monad and created the usual operators.  That stuff
> works.  My issue is that I want to run some functions in the machine
> monad, call it VMS - "virtual machine w/state" and then pull the
> underlying VM data structure out and print it.
> 
> I've read about monad transformers, lift, liftM, liftIO and all these
> instances in the libraries like MonadIO and am rather confused.  The
> most sensible conclusion I can reach is that I probably need to create
> my own Transformer monad and define liftIO.  Is this where I need to
> go?  Also, my VMS monad doesn't really do anything different from the
> State monad except explicitly specify that state is a VM and not a
> generic type.  Am I doing too much work creating my own instances
> here?  Would a simple "type" statement work?

Yes. You can use the existing implementation of state monads:

  import Control.Monad.State

and define a data type for the machine state

  data MS = VM { pc :: Int, heap :: MyHeap }

and then you can define your monad via

  type MSM = State MS

or, if you want your virtual machine to do some IO,

  type MSM = StateT IO MS

Now functions that operate on the virtual machine state might have the
following types:

isInStopState   :: MSM Bool
doOneStep   :: MSM ()
runUntilStopState   :: MSM ()
doSomeSteps :: Int -> MSM Int


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

[Haskell-cafe] Hopefully simple monad question

[Gregory Propf]

I'm playing around with a little program that implements a simple virtual 
machine.  I want to use a monad to represent machine state.  I created a data 
type for the machine (VM) and a monadic type for the monadic computations using 
it.  I declared this an instance of MonadState and Monad and created the usual 
operators.  That stuff works.  My issue is that I want to run some functions in 
the machine monad, call it VMS - "virtual machine w/state" and then pull the 
underlying VM data structure out and print it.

I've read about monad transformers, lift, liftM, liftIO and all these instances 
in the libraries like MonadIO and am rather confused.  The most sensible 
conclusion I can reach is that I probably need to create my own Transformer 
monad and define liftIO.  Is this where I need to go?  Also, my VMS monad 
doesn't really do anything different from the State monad except explicitly 
specify that state is a VM and not a generic type.  Am I doing too much work 
creating my own instances here?  Would a simple "type" statement work?



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

[Haskell-cafe] ANNOUNCE: levmar-0.2

[Bas van Dijk]

Hello,

We like to announce a new release of the high-level
Levenberg-Marquardt library levmar:

http://hackage.haskell.org/package/levmar-0.2

Changes:

* There's one new major feature: automatic calculation of the Jacobian
using automatic differentiation with Conal Elliott's vector-space
library.

(Conal: would you like to take a quick look at the implementation and
see if I'm using vector-space the way it supposed to be used, thanks)

* Furthermore we made the type Model from LevMar more type-safe by replacing:

type Model m r = NFunction m r [r]

with:

type Model m n r = NFunction m r (SizedList n r)

* Finally we did lot's of internal refactorings and updated the documentation.

regards,

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

[Haskell-cafe] ANNOUNCE: bindings-levmar-0.1.1

[Roel van Dijk]

I am pleased to announce the release of bindings-levmar-0.1.1:

http://hackage.haskell.org/package/bindings-levmar

The most important change compared to the previous version is a
custom configure script (copied from hmatrix) that detects which
libraries are needed. The cabal file also has some flags which
allow you to choose for instance intel's mkl library instead of
the normal lapack (also copied from hmatrix).

Happy hacking,
Roel and Bas van Dijk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] How to understand the 'forall' ?

[David Menendez]

On Wed, Sep 16, 2009 at 4:18 AM, Bulat Ziganshin
 wrote:
> Hello Cristiano,
>
> Wednesday, September 16, 2009, 12:04:48 PM, you wrote:
>
>> Yep, perhaps I used the wrong example. What about foo: (forall a. a) -> Int?
>
> it's a function that convert anything to integer.

That would be forall a. a -> Int.

The only value of type (forall a. a) is _|_.

-- 
Dave Menendez 

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

Re[2]: [Haskell-cafe] How to understand the 'forall' ?

[Bulat Ziganshin]

Hello Cristiano,

Wednesday, September 16, 2009, 12:04:48 PM, you wrote:

> Yep, perhaps I used the wrong example. What about foo: (forall a. a) -> Int?

it's a function that convert anything to integer. for example:

foo _ = 1

it's hard to find better examples, since haskell has very few
functions with fully polymorphic arguments


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] How to understand the 'forall' ?

[Cristiano Paris]

On Tue, Sep 15, 2009 at 11:38 PM, Daniel Fischer
 wrote:
> ...
>> foo :: forall a. a -> a
>
> This is exactly the same type as
>
> foo :: a -> a
>
> (unless you're using ScopedTypeVariables and there's a type variable a in 
> scope), since
> type signatures are implicitly forall'd.

Yep, perhaps I used the wrong example. What about foo: (forall a. a) -> Int?

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

[Haskell-cafe] Re: retrieving arguments for functions from a heterogenous list

[oleg]

Andrew U. Frank wrote:
> I have a number of functions which have some arguments and produce a single
> result. all the arguments are in a heterogenous list and the results should
> update the list. 

If I understand the problem correctly, you have a typed-indexed collection
TIP and you would like to apply a transformation function to it,
whose argument types and the result type are in the TIP. The function
should locate its arguments based on their types, and update the TIP
with the result. The function may have any number of arguments,
including zero; the order of arguments should not matter.

Then the following code seems to solve the problem. It starts with the
examples.


{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables, UndecidableInstances #-}

-- Transforming a TIP: applying to a TIP a (polyvariadic) function
-- that takes arguments from a TIP and updates the TIP with the result

module TIPTransform where

import Data.HList
import Data.HList.TIP

import Data.HList.TypeEqGeneric1
import Data.HList.TypeCastGeneric1
import Data.HList.Label5


newtype MyVal = MyVal Int deriving Show

-- A sample TIP
tip1 = MyVal 20 .*. (1::Int) .*. True .*. emptyTIP
-- TIP (HCons (MyVal 20) (HCons 1 (HCons True HNil)))

-- Update the Int component of tip1 to 2. The Int component must
-- exist. Otherwise, it is a type error
tip2 = ttip (2::Int) tip1
-- TIP (HCons (MyVal 20) (HCons 2 (HCons True HNil)))

-- Negate the boolean component of tip1
tip3 = ttip not tip1
-- TIP (HCons (MyVal 20) (HCons 1 (HCons False HNil)))

-- Update the Int component from the values of two other components
tip4 = ttip (\(MyVal x) y -> x+y) tip1
-- TIP (HCons (MyVal 20) (HCons 21 (HCons True HNil)))

-- Update the MyVal component from the values of three other components
tip5 = ttip (\b (MyVal x) y -> MyVal $ if b then x+y else 0) tip1
-- TIP (HCons (MyVal 21) (HCons 1 (HCons True HNil)))

-- The same but with the permuted argument order.
-- The order of arguments is immaterial: the values will be looked up using
-- their types
tip5' = ttip (\b y (MyVal x)-> MyVal $ if b then x+y else 0) tip1
-- TIP (HCons (MyVal 21) (HCons 1 (HCons True HNil)))


-- The implementation

class TransTIP op db where
ttip :: op -> db -> db

instance (HMember op db b, TransTIP' b op (TIP db)) 
=> TransTIP op (TIP db) where
ttip = ttip' (undefined::b)

class TransTIP' b op db where
ttip' :: b -> op -> db -> db

-- If op is found in a TIP, update the TIP with op
instance (HTypeIndexed db, HUpdateAtHNat n op db db, HType2HNat op db n)
=> TransTIP' HTrue op (TIP db) where
ttip' _ = tipyUpdate

-- If op is not found in a TIP, it must be a function. Look up
-- its argument in a TIP and recur.
instance (HOccurs arg db, TransTIP op db) 
=> TransTIP' HFalse (arg -> op) db where
ttip' _ f db = ttip (f (hOccurs db)) db

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