Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Stuart Cook]

On Thu, Aug 20, 2009 at 4:28 PM, Colin Paul
Adams wrote:
> But how do you get Latin-1 bytes from a Unicode string? This would
> need a transcoding process.

The first 256 code-points of Unicode coincide with Latin-1. Therefore,
if you truncate Unicode characters down to 8 bits you'll effectively
end up with Latin-1 text (except that any code points above U+00FF
will give strange results).

If your terminal then interprets these bytes as UTF-8 (or anything
else, really), the result will be gibberish or worse.


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

[Haskell-cafe] Right way to implement setPixel function

[CK Kashyap]

Hi,
I had posted a note on line drawing algo with Haskell some time back. Now, I am 
trying to write a PNM image.

import qualified Data.ByteString as B

width = 256
height = 256
bytesInImage = width * height * 3
blankImage =  B.pack $ take bytesInImage (repeat 0)

type Color = (Int,Int,Int)
setPixel :: B.ByteString -> Int -> Int -> Color -> B.ByteString
setPixel image x y (r,g,b) = B.concat [beforePixel, pixel, afterPixel]
where
beforePixel = B.take before image
afterPixel = B.drop (before+3) image
pixel=B.pack [(fromIntegral r),(fromIntegral g),(fromIntegral 
b)]
-- number of bytes before the 3 bytes of
-- the pixel at x y
before = (y * width * 3) + (x * 3) - 3

main = do
putStrLn "P6"
putStrLn ( (show width) ++ " " ++ (show height) )
putStrLn "255"
-- Set a red pixel at 100 100
B.putStr (setPixel blankImage 100 100 (255,0,0)) 


Can I please have some review comments on the code above? Would recreating the 
entire ByteString for each setPixel be an overhead?
Also, I am barely beginning to grasp the Monad conceptI was wondering if 
there could be a monadic style of implementation of this - that could 
potentially have a series of setPixels inside a do block?

Regards,
Kashyap



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

Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Colin Paul Adams]

> "Bulat" == Bulat Ziganshin  writes:

Bulat> Hello Colin,
Bulat> Thursday, August 20, 2009, 10:13:28 AM, you wrote:

> I don't understand where latin-1 comes into this. String is supposed
>> to be a list of Unicode characters.

Bulat> but ghc 6.10 i/o used String as list of bytes

But how do you get Latin-1 bytes from a Unicode string? This would
need a transcoding process.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Bulat Ziganshin]

Hello Colin,

Thursday, August 20, 2009, 10:13:28 AM, you wrote:

> I don't understand where latin-1 comes into this. String is supposed
> to be a list of Unicode characters.

but ghc 6.10 i/o used String as list of bytes


-- 
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] gbp sign showing as unknown character by GHC

[Colin Paul Adams]

> "Judah" == Judah Jacobson  writes:

Judah> On Wed, Aug 19, 2009 at 10:31 AM, Iain Barnett 
wrote:
>> Quick question: I've tested this in a couple of different
>> terminals (roxterm and xterm), so I'm fairly sure it's GHC
>> that's the problem. Have I missed a setting?  GHCi, version
>> 6.10.4
Prelude> putStrLn "£"
>> � Hugs98 200609-3
Hugs> putStrLn "£"
>> £
>> 

ghc-6.10.4 and earlier don't automatically encode/decode Unicode
Judah> characters.  So on terminals which don't use the latin-1
Judah> encoding, you need to do the conversion explicitly with a
Judah> separate package such as utf8-string, iconv or text-icu.

I don't understand where latin-1 comes into this. String is supposed
to be a list of Unicode characters.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Planning for a website

[Gour]

> "Colin" == Colin Paul Adams  writes:
Colin> I'd much rather be using happstack's macid stuff, especially as I
Colin> will have only very low usage, so i shouldn't have any
Colin> scalability problems.  

Well, I do not have enough money to pay for Happs resources...

Right, Turbinado is not perfect - lack of docs is one area and it is not
clear if it's still developed. Otoh, although I'll use Haskell for my
desktop app, atm, I'm learning Django to do the job...


Sincerely,
Gour

-- 

Gour | Hlapičina, Croatia  | GPG key: F96FF5F6 
---


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

[Haskell-cafe] Re: Unifcation and matching in Abelian groups

[Chung-chieh Shan]

John D. Ramsdell  wrote in article 
<7687290b0908190243y70541426x3d485267c4a94...@mail.gmail.com> in 
gmane.comp.lang.haskell.cafe:
> I've been studying equational unification.  I decided to test my
> understanding of it by implementing unification and matching in
> Abelian groups.  I am quite surprised by how little code it takes.
> Let me share it with you.

Thanks!  Another small change that might shorten the code is to use
Data.Map for linear combinations:

type Lin = Data.Map.Map String Int

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Shaik Riaz

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

Re: [Haskell-cafe] Control.Parallel on 6.10.4 - Mac OS X version

[Kevin Smith]

I ran the simple parallel "hello world" on my system.  the output of the
programs with N1 and N2 is shown below. I'm not sure how to interpret this -
it looks like I am getting a little speedup on the "real time". I'm running
the 6.10.4 install package for Mac OS X on a intel core 2 mac book.
Here is output of ghc --info:

Macintosh-4:~ kevinsmith$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("Project version","6.10.4")
 ,("Booter version","6.10.3.20090628")
 ,("Stage","2")
 ,("Interface file version","6")
 ,("Have interpreter","YES")
 ,("Object splitting","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Unregisterised","NO")
 ,("Tables next to code","YES")
 ,("Win32 DLLs","")
 ,("RTS ways"," debug  thr thr_p thr_debug")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ]


Here is output from program:

$ time ./paratest +RTS -N1 -s
./paratest +RTS -N1 -s
1405006117752879898543142606244511569936384005711076
 758,080,164 bytes allocated in the heap
  61,076 bytes copied during GC
   3,044 bytes maximum residency (1 sample(s))
  16,204 bytes maximum slop
   1 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  1445 collections, 0 parallel,  0.08s,  0.08s elapsed
  Generation 1: 1 collections, 0 parallel,  0.00s,  0.00s elapsed

  Task  0 (worker) :  MUT time:   0.00s  (  0.00s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  1 (worker) :  MUT time:   1.91s  (  1.86s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   1.83s  (  1.86s elapsed)
  GC  time:   0.08s  (  0.08s elapsed)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time1.83s  (  1.86s elapsed)
  GCtime0.08s  (  0.08s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time1.91s  (  1.94s elapsed)

  %GC time   4.1%  (4.3% elapsed)

  Alloc rate413,412,206 bytes per MUT second

  Productivity  95.9% of total user, 94.4% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0

real 0m1.946s
user 0m1.912s
sys 0m0.025s
Macintosh-4:~ kevinsmith$ time ./paratest +RTS -N2 -s
./paratest +RTS -N2 -s
1405006117752879898543142606244511569936384005711076
 758,092,440 bytes allocated in the heap
  79,084 bytes copied during GC
   3,076 bytes maximum residency (1 sample(s))
  14,724 bytes maximum slop
   2 MB total memory in use (0 MB lost due to fragmentation)

  Generation 0:  1024 collections, 0 parallel,  0.08s,  0.08s elapsed
  Generation 1: 1 collections, 0 parallel,  0.00s,  0.00s elapsed

  Parallel GC work balance: nan (0 / 0, ideal 2)

  Task  0 (worker) :  MUT time:   1.84s  (  1.18s elapsed)
  GC  time:   0.08s  (  0.08s elapsed)

  Task  1 (worker) :  MUT time:   1.92s  (  1.18s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   1.92s  (  1.18s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  3 (worker) :  MUT time:   1.92s  (  1.18s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time1.84s  (  1.18s elapsed)
  GCtime0.08s  (  0.08s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time1.92s  (  1.27s elapsed)

  %GC time   4.0%  (6.5% elapsed)

  Alloc rate411,138,454 bytes per MUT second

  Productivity  95.9% of total user, 145.6% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0

real 0m1.269s
user 0m1.922s
sys 0m0.042s


On Tue, Aug 18, 2009 at 8:17 PM, Don Stewart  wrote:

> k2msmith:
> > I'm using the Control.Parallel package on ghc version 6.10.4 and I don't
> seem
> > to be getting any parallel threads or sparks created at all with the
> > "-threaded" compilation option using runtime flags "+RTS -N2".  I'm using
> > simple examples from the paper "A Tutorial on Parallel and Concurrent
> > Programming in Haskell" by Jones and Singh.
> >
> > I'm running on an Intel Mac core 2 duo.  Does anyone know how I can check
> if
> > the parallel functionality in ghc is working on my 6.10.4 ghc package
> installed
> > on this platform ? I installed it from the "supported" runtime pkg for OS
> X
> > from the ghc website.
> >
>
> A simple parallel 'hello world'
>
>
> http://haskell.org/haskellwiki/Haskell_in_5_steps#Write_your_first_parallel_Haskell_program
>
__

Re: [Haskell-cafe] Keeping an indexed collection of values?

[Bernie Pope]

2009/8/19 Job Vranish :

>
> My first hacked up attempt is as follows:
>
> data IndexedCollection a = IndexedCollection {
>     nextKey        :: Int,
>     availableKeys :: [Int],
>     items                :: (IntMap Int a)
> } deriving (Show)
>
> emptyIndexedCollection :: IndexedCollection a
> emptyIndexedCollection = IndexedCollection 0 [] empty
>
> addItem :: a -> IndexedCollection a -> (Int, IndexedCollection a)
> addItem a (IndexedCollection nextKey' [] t) = (nextKey',
> IndexedCollection (nextKey' + 1) [] (insert nextKey' a t))
> addItem a (IndexedCollection nextKey' (k:ks) t) = (k, IndexedCollection
> nextKey' ks (insert k a t))
>
> removeItem :: Int -> IndexedCollection a -> IndexedCollection a
> removeItem k (IndexedCollection nextKey' ks t) = IndexedCollection nextKey'
> (k:ks) (delete k t)
>
> lookupItem :: Int -> IndexedCollection a -> Maybe a
> lookupItem k (IndexedCollection _ _ t) = lookup k t

It might be the case for IntMap (I haven't checked) that it is better
to do a modify operation than to do a deletion followed by an
insertion on the same key.

One possible improvement is to delay deletions by putting them in a
pending queue. A pending deletion followed by an addItem could be
coalesced into a modify operation on the key to be deleted.

You could even push lookupItems through pending deletions, assuming
that they aren't on the same key (if they are on the same key then the
lookup would fail).

One question is how big should the pending deletion queue be allowed
to become? A long queue might not be a good idea. One problem with
delaying deletions is that it could introduce a space leak (same as
unintended lazy evaluation). Maybe a queue of max length one is
sufficient?

I'm not sure it is worth the trouble, but it might be fun to try.

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

Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Judah Jacobson]

On Wed, Aug 19, 2009 at 10:31 AM, Iain Barnett wrote:
> Quick question: I've tested this in a couple of different terminals (roxterm
> and xterm), so I'm fairly sure it's GHC that's the problem. Have I missed a
> setting?
> GHCi, version 6.10.4
> Prelude> putStrLn "£"
> �
> Hugs98 200609-3
> Hugs> putStrLn "£"
> £
>

ghc-6.10.4 and earlier don't automatically encode/decode Unicode
characters.  So on terminals which don't use the latin-1 encoding, you
need to do the conversion explicitly with a separate package such as
utf8-string, iconv or text-icu.  For example, on OS X:

$ echo $LANG
en_US.UTF-8
$ ghci
Prelude> putStrLn "£"
?
Prelude> System.IO.UTF8.putStrLn "£"
£

The conversion is done automatically by hugs, which is why the outputs
differ.  This feature will also be supported in ghc-6.12.

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

Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Sebastian Sylvan]

Both of these happen on Windows 7 64-bit for me too.

On Wed, Aug 19, 2009 at 7:08 PM, Iain Barnett  wrote:

>
>
> 2009/8/19 David Leimbach 
>
>> Interesting... GHCI bug?  Didn't the readline dependency go away not too
>> long ago?  Could it be related?
>>
>
> I just tried this
>
> Prelude> putStrLn "\£"
> ghc: panic! (the 'impossible' happened)
>   (GHC version 6.10.4 for i386-unknown-linux):
> charType: '\163'
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
>
> So perhaps I should put in a bug report, as that shouldn't happen (it
> doesn't with some other characters I tried), unless anyone has a different
> idea? I'm running Arch Linux with xmonad and using roxterm, so perhaps it's
> something to do with my setup?
>
> Iain
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


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

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Well I really wrote this code as an exercise, and it was a good one. Now I
(or someone) needs to explain why it works.
But is this monad really useful? I mean it would be straightforward to write
this using the ST monad I guess?

Anyway, the reason why I want this pure code is that even with a console
based game, I don't want IO in it, since recording the input and replaying
it is vital to reproduce the actions the user did, and if things go wrong
(they always do), the log of all input can be used to restore the exact game
play. Of course you can do the same using imperative techniques and IO
redirection (which I did for my old games), but with this pure code you
don't have to worry about other places where IO could be used.

On Wed, Aug 19, 2009 at 10:06 PM, David Leimbach  wrote:

> Hmmm very interesting thinking on this.  Perhaps ByteStrings would be a
> good way to go for efficiency of composition.
> I'd love to see some profiling of all of this as part of the lesson at some
> point.  (Perhaps with vacuum visualization?)
>
> This thread has tackled 3 major tricky issue areas with Haskell so far:
>
> 1. Lazy IO and seq
> 2. Roll-your-own-Monad
> 3. Data growth profiling.
>
> It's been a good read anyway, and fun to play with the code.
>
> Dave
>
> On Wed, Aug 19, 2009 at 1:00 PM, Peter Verswyvelen wrote:
>
>> Wow, very nice cleanup! That's really a good way for me to learn, thanks.
>> Well, my intuition told me that strings and ++ wouldn't work, since what
>> we want is an infinite list of output strings, and using ++ would result in
>> (((s1++s2)++s3)++s4)++s5... which is highly inefficient and I think it would
>> keep the complete output text in memory. Using difference lists results in
>> right associative concatenation of s1++(s2++(s3++(s4++... which is efficient
>> and can be garbage collected nicely. At least that's what I guess. I really
>> would like to get a deeper understanding of all this but that will take lots
>> of time and study, but if I'm lucky I still have 20 to 40 years to go, so I
>> won't be bored :-)
>>
>>
>>
>>
>> On Wed, Aug 19, 2009 at 9:46 PM, David Leimbach wrote:
>>
>>> Very cool!
>>> I am still wondering what the significance of the DList is with this
>>> though, or why it was needed to begin with.
>>>
>>> Dave
>>>
>>>
>>> On Wed, Aug 19, 2009 at 12:28 PM, Ryan Ingram wrote:
>>>
 Added a new version (tested, works with infinite loops, no early output,
 etc.)

 http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343

 I'll put up a short write-up after lunch.

  -- ryan

 On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelen
 wrote:
 > The cleaned up code didn't seem to work for me, it printed everything
 before
 > asking input again.
 > But I added a patch that looks like it supports looping, but I don't
 > understand exactly what is going on :-)
 > I added the "delay" function which makes appending to the output less
 > strict.
 > Note that in this version I add a delay to each right argument of >>=,
 but
 > one could also do it manually
 > On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach 
 wrote:
 >>
 >> I've corrected it.  It still doesn't suffer looping.  :-)
 >>
 >> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach 
 >> wrote:
 >>>
 >>> Doesn't seem to compile.
 >>> I nearly never use case statements in my code, so I'm not really
 sure
 >>> what's going on.
 >>> neat2.hs:14:39: parse error on input `='
 >>> Dave
 >>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram >>> >
 >>> wrote:
 
  I posted a reply to your paste with a stricter version of S and
 some
  cleanup.
 
  Untested, though I believe it should work without "seq".
 
  "case" provides all the strictness you need, I think!
 
   -- ryan
 
  On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen<
 bugf...@gmail.com>
  wrote:
  > Expect more bugs with this though :-) Just found out that looping
 does
  > not
  > work, it hangs, e.g.
  >
  > test = do
  >   out "Enter your first name:"
  >   fstName <- inp
  >   out "Enter your second name:"
  >   sndName <- inp
  >   out ("Welcome "++fstName++" "++sndName)
  >   out "Goodbye!"
  >   test
  >
  > Doesn't seem to work :-) Back to the drawing board.
  >
  > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen <
 bugf...@gmail.com>
  > wrote:
  >>
  >> Not at all, use it for whatever you want to :-)
  >> I'm writing this code because I'm preparing to write a bunch of
  >> tutorials
  >> on FRP, and I first wanted to start with simple console based
 FRP,
  >> e.g.
  >> making a little text adventure game, where the input/choices of

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Hmmm very interesting thinking on this.  Perhaps ByteStrings would be a good
way to go for efficiency of composition.
I'd love to see some profiling of all of this as part of the lesson at some
point.  (Perhaps with vacuum visualization?)

This thread has tackled 3 major tricky issue areas with Haskell so far:

1. Lazy IO and seq
2. Roll-your-own-Monad
3. Data growth profiling.

It's been a good read anyway, and fun to play with the code.

Dave

On Wed, Aug 19, 2009 at 1:00 PM, Peter Verswyvelen wrote:

> Wow, very nice cleanup! That's really a good way for me to learn, thanks.
> Well, my intuition told me that strings and ++ wouldn't work, since what we
> want is an infinite list of output strings, and using ++ would result in
> (((s1++s2)++s3)++s4)++s5... which is highly inefficient and I think it would
> keep the complete output text in memory. Using difference lists results in
> right associative concatenation of s1++(s2++(s3++(s4++... which is efficient
> and can be garbage collected nicely. At least that's what I guess. I really
> would like to get a deeper understanding of all this but that will take lots
> of time and study, but if I'm lucky I still have 20 to 40 years to go, so I
> won't be bored :-)
>
>
>
>
> On Wed, Aug 19, 2009 at 9:46 PM, David Leimbach  wrote:
>
>> Very cool!
>> I am still wondering what the significance of the DList is with this
>> though, or why it was needed to begin with.
>>
>> Dave
>>
>>
>> On Wed, Aug 19, 2009 at 12:28 PM, Ryan Ingram wrote:
>>
>>> Added a new version (tested, works with infinite loops, no early output,
>>> etc.)
>>>
>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343
>>>
>>> I'll put up a short write-up after lunch.
>>>
>>>  -- ryan
>>>
>>> On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelen
>>> wrote:
>>> > The cleaned up code didn't seem to work for me, it printed everything
>>> before
>>> > asking input again.
>>> > But I added a patch that looks like it supports looping, but I don't
>>> > understand exactly what is going on :-)
>>> > I added the "delay" function which makes appending to the output less
>>> > strict.
>>> > Note that in this version I add a delay to each right argument of >>=,
>>> but
>>> > one could also do it manually
>>> > On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach 
>>> wrote:
>>> >>
>>> >> I've corrected it.  It still doesn't suffer looping.  :-)
>>> >>
>>> >> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach 
>>> >> wrote:
>>> >>>
>>> >>> Doesn't seem to compile.
>>> >>> I nearly never use case statements in my code, so I'm not really sure
>>> >>> what's going on.
>>> >>> neat2.hs:14:39: parse error on input `='
>>> >>> Dave
>>> >>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram 
>>> >>> wrote:
>>> 
>>>  I posted a reply to your paste with a stricter version of S and some
>>>  cleanup.
>>> 
>>>  Untested, though I believe it should work without "seq".
>>> 
>>>  "case" provides all the strictness you need, I think!
>>> 
>>>   -- ryan
>>> 
>>>  On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen<
>>> bugf...@gmail.com>
>>>  wrote:
>>>  > Expect more bugs with this though :-) Just found out that looping
>>> does
>>>  > not
>>>  > work, it hangs, e.g.
>>>  >
>>>  > test = do
>>>  >   out "Enter your first name:"
>>>  >   fstName <- inp
>>>  >   out "Enter your second name:"
>>>  >   sndName <- inp
>>>  >   out ("Welcome "++fstName++" "++sndName)
>>>  >   out "Goodbye!"
>>>  >   test
>>>  >
>>>  > Doesn't seem to work :-) Back to the drawing board.
>>>  >
>>>  > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen <
>>> bugf...@gmail.com>
>>>  > wrote:
>>>  >>
>>>  >> Not at all, use it for whatever you want to :-)
>>>  >> I'm writing this code because I'm preparing to write a bunch of
>>>  >> tutorials
>>>  >> on FRP, and I first wanted to start with simple console based
>>> FRP,
>>>  >> e.g.
>>>  >> making a little text adventure game, where the input/choices of
>>> the
>>>  >> user
>>>  >> might be parsed ala parsec, using monadic style, applicative
>>> style,
>>>  >> and
>>>  >> arrows, and then doing the same with FRP frameworks like Yampa,
>>>  >> Elera,
>>>  >> Reactive, etc...
>>>  >> After that I would start writing tutorials that use OpenGL,
>>> making
>>>  >> some
>>>  >> very simple games, again with the above approaches, and ending
>>> with a
>>>  >> conversion of a very old game of mine (Zarathrusta written in
>>>  >> assembler from
>>>  >> 1991, which was based on Thrust from 1986, converted by myself in
>>> C++
>>>  >> to
>>>  >> PocketPC as G-Pod, and so I would like to make a version in
>>> Haskell
>>>  >> that
>>>  >> runs on the iPhone :-)
>>>  >> This of course is a lot of work, and I would like to put this on
>>> the
>>>  >> Haskell wiki or a blog or something, so others can contribute and
>

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Wow, very nice cleanup! That's really a good way for me to learn, thanks.
Well, my intuition told me that strings and ++ wouldn't work, since what we
want is an infinite list of output strings, and using ++ would result in
(((s1++s2)++s3)++s4)++s5... which is highly inefficient and I think it would
keep the complete output text in memory. Using difference lists results in
right associative concatenation of s1++(s2++(s3++(s4++... which is efficient
and can be garbage collected nicely. At least that's what I guess. I really
would like to get a deeper understanding of all this but that will take lots
of time and study, but if I'm lucky I still have 20 to 40 years to go, so I
won't be bored :-)




On Wed, Aug 19, 2009 at 9:46 PM, David Leimbach  wrote:

> Very cool!
> I am still wondering what the significance of the DList is with this
> though, or why it was needed to begin with.
>
> Dave
>
>
> On Wed, Aug 19, 2009 at 12:28 PM, Ryan Ingram wrote:
>
>> Added a new version (tested, works with infinite loops, no early output,
>> etc.)
>>
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343
>>
>> I'll put up a short write-up after lunch.
>>
>>  -- ryan
>>
>> On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelen
>> wrote:
>> > The cleaned up code didn't seem to work for me, it printed everything
>> before
>> > asking input again.
>> > But I added a patch that looks like it supports looping, but I don't
>> > understand exactly what is going on :-)
>> > I added the "delay" function which makes appending to the output less
>> > strict.
>> > Note that in this version I add a delay to each right argument of >>=,
>> but
>> > one could also do it manually
>> > On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach 
>> wrote:
>> >>
>> >> I've corrected it.  It still doesn't suffer looping.  :-)
>> >>
>> >> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach 
>> >> wrote:
>> >>>
>> >>> Doesn't seem to compile.
>> >>> I nearly never use case statements in my code, so I'm not really sure
>> >>> what's going on.
>> >>> neat2.hs:14:39: parse error on input `='
>> >>> Dave
>> >>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram 
>> >>> wrote:
>> 
>>  I posted a reply to your paste with a stricter version of S and some
>>  cleanup.
>> 
>>  Untested, though I believe it should work without "seq".
>> 
>>  "case" provides all the strictness you need, I think!
>> 
>>   -- ryan
>> 
>>  On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen> >
>>  wrote:
>>  > Expect more bugs with this though :-) Just found out that looping
>> does
>>  > not
>>  > work, it hangs, e.g.
>>  >
>>  > test = do
>>  >   out "Enter your first name:"
>>  >   fstName <- inp
>>  >   out "Enter your second name:"
>>  >   sndName <- inp
>>  >   out ("Welcome "++fstName++" "++sndName)
>>  >   out "Goodbye!"
>>  >   test
>>  >
>>  > Doesn't seem to work :-) Back to the drawing board.
>>  >
>>  > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen <
>> bugf...@gmail.com>
>>  > wrote:
>>  >>
>>  >> Not at all, use it for whatever you want to :-)
>>  >> I'm writing this code because I'm preparing to write a bunch of
>>  >> tutorials
>>  >> on FRP, and I first wanted to start with simple console based FRP,
>>  >> e.g.
>>  >> making a little text adventure game, where the input/choices of
>> the
>>  >> user
>>  >> might be parsed ala parsec, using monadic style, applicative
>> style,
>>  >> and
>>  >> arrows, and then doing the same with FRP frameworks like Yampa,
>>  >> Elera,
>>  >> Reactive, etc...
>>  >> After that I would start writing tutorials that use OpenGL, making
>>  >> some
>>  >> very simple games, again with the above approaches, and ending
>> with a
>>  >> conversion of a very old game of mine (Zarathrusta written in
>>  >> assembler from
>>  >> 1991, which was based on Thrust from 1986, converted by myself in
>> C++
>>  >> to
>>  >> PocketPC as G-Pod, and so I would like to make a version in
>> Haskell
>>  >> that
>>  >> runs on the iPhone :-)
>>  >> This of course is a lot of work, and I would like to put this on
>> the
>>  >> Haskell wiki or a blog or something, so others can contribute and
>>  >> comment. I
>>  >> would like to show real examples that explain the shortcomings of
>> the
>>  >> FRP
>>  >> approaches, because now this is still a bit blurry to me.
>>  >>
>>  >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach <
>> leim...@gmail.com>
>>  >> wrote:
>>  >>>
>>  >>> This Monad you've created is quite excellent.  I was trying to do
>>  >>> something like this about a year ago, to make the input and
>> output
>>  >>> handling
>>  >>> of an interactive bowling score card work nicely.  I kept running
>>  >>> into
>>  >>> issues, and did not believe that seq was going to do the trick.
>> 

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Very cool!
I am still wondering what the significance of the DList is with this though,
or why it was needed to begin with.

Dave

On Wed, Aug 19, 2009 at 12:28 PM, Ryan Ingram  wrote:

> Added a new version (tested, works with infinite loops, no early output,
> etc.)
>
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343
>
> I'll put up a short write-up after lunch.
>
>  -- ryan
>
> On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelen
> wrote:
> > The cleaned up code didn't seem to work for me, it printed everything
> before
> > asking input again.
> > But I added a patch that looks like it supports looping, but I don't
> > understand exactly what is going on :-)
> > I added the "delay" function which makes appending to the output less
> > strict.
> > Note that in this version I add a delay to each right argument of >>=,
> but
> > one could also do it manually
> > On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach 
> wrote:
> >>
> >> I've corrected it.  It still doesn't suffer looping.  :-)
> >>
> >> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach 
> >> wrote:
> >>>
> >>> Doesn't seem to compile.
> >>> I nearly never use case statements in my code, so I'm not really sure
> >>> what's going on.
> >>> neat2.hs:14:39: parse error on input `='
> >>> Dave
> >>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram 
> >>> wrote:
> 
>  I posted a reply to your paste with a stricter version of S and some
>  cleanup.
> 
>  Untested, though I believe it should work without "seq".
> 
>  "case" provides all the strictness you need, I think!
> 
>   -- ryan
> 
>  On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen
>  wrote:
>  > Expect more bugs with this though :-) Just found out that looping
> does
>  > not
>  > work, it hangs, e.g.
>  >
>  > test = do
>  >   out "Enter your first name:"
>  >   fstName <- inp
>  >   out "Enter your second name:"
>  >   sndName <- inp
>  >   out ("Welcome "++fstName++" "++sndName)
>  >   out "Goodbye!"
>  >   test
>  >
>  > Doesn't seem to work :-) Back to the drawing board.
>  >
>  > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen <
> bugf...@gmail.com>
>  > wrote:
>  >>
>  >> Not at all, use it for whatever you want to :-)
>  >> I'm writing this code because I'm preparing to write a bunch of
>  >> tutorials
>  >> on FRP, and I first wanted to start with simple console based FRP,
>  >> e.g.
>  >> making a little text adventure game, where the input/choices of the
>  >> user
>  >> might be parsed ala parsec, using monadic style, applicative style,
>  >> and
>  >> arrows, and then doing the same with FRP frameworks like Yampa,
>  >> Elera,
>  >> Reactive, etc...
>  >> After that I would start writing tutorials that use OpenGL, making
>  >> some
>  >> very simple games, again with the above approaches, and ending with
> a
>  >> conversion of a very old game of mine (Zarathrusta written in
>  >> assembler from
>  >> 1991, which was based on Thrust from 1986, converted by myself in
> C++
>  >> to
>  >> PocketPC as G-Pod, and so I would like to make a version in Haskell
>  >> that
>  >> runs on the iPhone :-)
>  >> This of course is a lot of work, and I would like to put this on
> the
>  >> Haskell wiki or a blog or something, so others can contribute and
>  >> comment. I
>  >> would like to show real examples that explain the shortcomings of
> the
>  >> FRP
>  >> approaches, because now this is still a bit blurry to me.
>  >>
>  >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach  >
>  >> wrote:
>  >>>
>  >>> This Monad you've created is quite excellent.  I was trying to do
>  >>> something like this about a year ago, to make the input and output
>  >>> handling
>  >>> of an interactive bowling score card work nicely.  I kept running
>  >>> into
>  >>> issues, and did not believe that seq was going to do the trick.
>  >>>  Nice work!
>  >>> This is a very useful monad I think, it could be called "Prompter"
>  >>> or
>  >>> something to that effect.
>  >>> Do you mind if I use it in some of my code?
>  >>> Dave
>  >>>
>  >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen
>  >>> 
>  >>> wrote:
>  
>   LOL. Maybe we should have that coffee together ;-) at least
>   virtually!
>   On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach <
> leim...@gmail.com>
>   wrote:
>  >
>  > Argh... I too have been up too late :-).  I edited THE WRONG
> FILE!
>  >  No
>  > wonder your change didn't take effect!  :-/
>  > Time for coffee I suppose.
>  >
>  > On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach
>  > 
>  > wrote:
>  >>
>  >> This doesn't seem to be working for me interacti

Re: Re[2]: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Iain Barnett]

2009/8/19 Bulat Ziganshin 

>
> probably, terminals reports some unusual symbols. but any panic should
> be reported to GHC Trac - anyway
>
>
I've added a new ticket here, in case you feel you want to add to it (or not
:)
http://hackage.haskell.org/trac/ghc/ticket/3443


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

Re: [Haskell-cafe] Re: Where do I put the seq?

[Ryan Ingram]

Added a new version (tested, works with infinite loops, no early output, etc.)

http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8343

I'll put up a short write-up after lunch.

  -- ryan

On Wed, Aug 19, 2009 at 11:28 AM, Peter Verswyvelen wrote:
> The cleaned up code didn't seem to work for me, it printed everything before
> asking input again.
> But I added a patch that looks like it supports looping, but I don't
> understand exactly what is going on :-)
> I added the "delay" function which makes appending to the output less
> strict.
> Note that in this version I add a delay to each right argument of >>=, but
> one could also do it manually
> On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach  wrote:
>>
>> I've corrected it.  It still doesn't suffer looping.  :-)
>>
>> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach 
>> wrote:
>>>
>>> Doesn't seem to compile.
>>> I nearly never use case statements in my code, so I'm not really sure
>>> what's going on.
>>> neat2.hs:14:39: parse error on input `='
>>> Dave
>>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram 
>>> wrote:

 I posted a reply to your paste with a stricter version of S and some
 cleanup.

 Untested, though I believe it should work without "seq".

 "case" provides all the strictness you need, I think!

  -- ryan

 On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen
 wrote:
 > Expect more bugs with this though :-) Just found out that looping does
 > not
 > work, it hangs, e.g.
 >
 > test = do
 >   out "Enter your first name:"
 >   fstName <- inp
 >   out "Enter your second name:"
 >   sndName <- inp
 >   out ("Welcome "++fstName++" "++sndName)
 >   out "Goodbye!"
 >   test
 >
 > Doesn't seem to work :-) Back to the drawing board.
 >
 > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen 
 > wrote:
 >>
 >> Not at all, use it for whatever you want to :-)
 >> I'm writing this code because I'm preparing to write a bunch of
 >> tutorials
 >> on FRP, and I first wanted to start with simple console based FRP,
 >> e.g.
 >> making a little text adventure game, where the input/choices of the
 >> user
 >> might be parsed ala parsec, using monadic style, applicative style,
 >> and
 >> arrows, and then doing the same with FRP frameworks like Yampa,
 >> Elera,
 >> Reactive, etc...
 >> After that I would start writing tutorials that use OpenGL, making
 >> some
 >> very simple games, again with the above approaches, and ending with a
 >> conversion of a very old game of mine (Zarathrusta written in
 >> assembler from
 >> 1991, which was based on Thrust from 1986, converted by myself in C++
 >> to
 >> PocketPC as G-Pod, and so I would like to make a version in Haskell
 >> that
 >> runs on the iPhone :-)
 >> This of course is a lot of work, and I would like to put this on the
 >> Haskell wiki or a blog or something, so others can contribute and
 >> comment. I
 >> would like to show real examples that explain the shortcomings of the
 >> FRP
 >> approaches, because now this is still a bit blurry to me.
 >>
 >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach 
 >> wrote:
 >>>
 >>> This Monad you've created is quite excellent.  I was trying to do
 >>> something like this about a year ago, to make the input and output
 >>> handling
 >>> of an interactive bowling score card work nicely.  I kept running
 >>> into
 >>> issues, and did not believe that seq was going to do the trick.
 >>>  Nice work!
 >>> This is a very useful monad I think, it could be called "Prompter"
 >>> or
 >>> something to that effect.
 >>> Do you mind if I use it in some of my code?
 >>> Dave
 >>>
 >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen
 >>> 
 >>> wrote:
 
  LOL. Maybe we should have that coffee together ;-) at least
  virtually!
  On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach 
  wrote:
 >
 > Argh... I too have been up too late :-).  I edited THE WRONG FILE!
 >  No
 > wonder your change didn't take effect!  :-/
 > Time for coffee I suppose.
 >
 > On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach
 > 
 > wrote:
 >>
 >> This doesn't seem to be working for me interactively though on a
 >> Mac.
 >>  I still get "Welcome" before I've entered text.
 >>
 >> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen
 >> 
 >> wrote:
 >>>
 >>> I fixed it myself but it's really tricky :-)
 >>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
 >>> The idea is, that when the input is requested, the output that
 >>> is
 >>> then generated must be in sync with the input.

Re[2]: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Bulat Ziganshin]

Hello Alexander,

Wednesday, August 19, 2009, 10:16:26 PM, you wrote:

> Could it be a terminfo problem of some sort? It seems suspicious that
> there is a difference between terminals.

probably, terminals reports some unusual symbols. but any panic should
be reported to GHC Trac - anyway


-- 
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] Re: Where do I put the seq?

[Peter Verswyvelen]

The cleaned up code didn't seem to work for me, it printed everything before
asking input again.

But I added a patch that looks like it supports looping, but I don't
understand exactly what is going on :-)
I added the "delay" function which makes appending to the output less
strict.

Note that in this version I add a delay to each right argument of >>=, but
one could also do it manually

On Wed, Aug 19, 2009 at 7:37 PM, David Leimbach  wrote:

> I've corrected it.  It still doesn't suffer looping.  :-)
>
>
> On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach wrote:
>
>> Doesn't seem to compile.
>> I nearly never use case statements in my code, so I'm not really sure
>> what's going on.
>>
>> neat2.hs:14:39: parse error on input `='
>>
>> Dave
>>
>> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram wrote:
>>
>>> I posted a reply to your paste with a stricter version of S and some
>>> cleanup.
>>>
>>> Untested, though I believe it should work without "seq".
>>>
>>> "case" provides all the strictness you need, I think!
>>>
>>>  -- ryan
>>>
>>> On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen
>>> wrote:
>>> > Expect more bugs with this though :-) Just found out that looping does
>>> not
>>> > work, it hangs, e.g.
>>> >
>>> > test = do
>>> >   out "Enter your first name:"
>>> >   fstName <- inp
>>> >   out "Enter your second name:"
>>> >   sndName <- inp
>>> >   out ("Welcome "++fstName++" "++sndName)
>>> >   out "Goodbye!"
>>> >   test
>>> >
>>> > Doesn't seem to work :-) Back to the drawing board.
>>> >
>>> > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen 
>>> > wrote:
>>> >>
>>> >> Not at all, use it for whatever you want to :-)
>>> >> I'm writing this code because I'm preparing to write a bunch of
>>> tutorials
>>> >> on FRP, and I first wanted to start with simple console based FRP,
>>> e.g.
>>> >> making a little text adventure game, where the input/choices of the
>>> user
>>> >> might be parsed ala parsec, using monadic style, applicative style,
>>> and
>>> >> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
>>> >> Reactive, etc...
>>> >> After that I would start writing tutorials that use OpenGL, making
>>> some
>>> >> very simple games, again with the above approaches, and ending with a
>>> >> conversion of a very old game of mine (Zarathrusta written in
>>> assembler from
>>> >> 1991, which was based on Thrust from 1986, converted by myself in C++
>>> to
>>> >> PocketPC as G-Pod, and so I would like to make a version in Haskell
>>> that
>>> >> runs on the iPhone :-)
>>> >> This of course is a lot of work, and I would like to put this on the
>>> >> Haskell wiki or a blog or something, so others can contribute and
>>> comment. I
>>> >> would like to show real examples that explain the shortcomings of the
>>> FRP
>>> >> approaches, because now this is still a bit blurry to me.
>>> >>
>>> >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach 
>>> wrote:
>>> >>>
>>> >>> This Monad you've created is quite excellent.  I was trying to do
>>> >>> something like this about a year ago, to make the input and output
>>> handling
>>> >>> of an interactive bowling score card work nicely.  I kept running
>>> into
>>> >>> issues, and did not believe that seq was going to do the trick.  Nice
>>> work!
>>> >>> This is a very useful monad I think, it could be called "Prompter" or
>>> >>> something to that effect.
>>> >>> Do you mind if I use it in some of my code?
>>> >>> Dave
>>> >>>
>>> >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen <
>>> bugf...@gmail.com>
>>> >>> wrote:
>>> 
>>>  LOL. Maybe we should have that coffee together ;-) at least
>>> virtually!
>>>  On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach 
>>>  wrote:
>>> >
>>> > Argh... I too have been up too late :-).  I edited THE WRONG FILE!
>>>  No
>>> > wonder your change didn't take effect!  :-/
>>> > Time for coffee I suppose.
>>> >
>>> > On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach >> >
>>> > wrote:
>>> >>
>>> >> This doesn't seem to be working for me interactively though on a
>>> Mac.
>>> >>  I still get "Welcome" before I've entered text.
>>> >>
>>> >> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen <
>>> bugf...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> I fixed it myself but it's really tricky :-)
>>> >>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>> >>> The idea is, that when the input is requested, the output that is
>>> >>> then generated must be in sync with the input.
>>> >>>
>>> >>> inp = S $ \s i -> let r = (s `D.append` (i `seq` D.empty), head
>>> i) in
>>> >>> (tail i, r)
>>> >>>
>>> >>>
>>> >>> I first had
>>> >>>
>>> >>> inp = S $ \s i -> let r = (i `seq` s, head i) in (tail i, r)
>>> >>>
>>> >>> But that was too eager, since i syncs the input not with the
>>> output,
>>> >>> but with the function that will generate the output.
>>> >>>
>>> >>>
>>> >>>
>>> 

Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Alexander Dunlap]

On Wed, Aug 19, 2009 at 11:08 AM, Iain Barnett wrote:
>
>
> 2009/8/19 David Leimbach 
>>
>> Interesting... GHCI bug?  Didn't the readline dependency go away not too
>> long ago?  Could it be related?
>
> I just tried this
> Prelude> putStrLn "\£"
> ghc: panic! (the 'impossible' happened)
>   (GHC version 6.10.4 for i386-unknown-linux):
> charType: '\163'
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> So perhaps I should put in a bug report, as that shouldn't happen (it
> doesn't with some other characters I tried), unless anyone has a different
> idea? I'm running Arch Linux with xmonad and using roxterm, so perhaps it's
> something to do with my setup?
> Iain
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

I can reproduce the panic on both urxvt and uxterm.

On urxvt, GHCi works correctly with putStrLn "£". On uxterm, it just
prints a blank space.

I can type the GBP sign into both terminals.

Could it be a terminfo problem of some sort? It seems suspicious that
there is a difference between terminals.

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

Re: [Haskell-cafe] gbp sign showing as unknown character by GHC

[Iain Barnett]

2009/8/19 David Leimbach 

> Interesting... GHCI bug?  Didn't the readline dependency go away not too
> long ago?  Could it be related?
>

I just tried this

Prelude> putStrLn "\£"
ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.4 for i386-unknown-linux):
charType: '\163'

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


So perhaps I should put in a bug report, as that shouldn't happen (it
doesn't with some other characters I tried), unless anyone has a different
idea? I'm running Arch Linux with xmonad and using roxterm, so perhaps it's
something to do with my setup?

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

Re: [Haskell-cafe] Observations about foldM

[Eugene Kirpichov]

You're right. My bad, indeed.

2009/8/19 Daniel Fischer :
> Am Mittwoch 19 August 2009 16:32:57 schrieb Eugene Kirpichov:
>> 2009/8/19 Dan Doel :
>> > On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:
>> >> Interestingly, foldM can also be written as a left fold. To see this,
>> >> note that it is a theorem that foldr f z xs = foldl f z xs as long as f
>> >> is associative and z is a unit for f.
>>
>> This is not true: f has to be commutative, not associative.
>>
>> Consider matrix multiplication.
>>
>
> It is true:
> foldr: A1*(A2*(... *AN*E))
> foldl: (...((E*A1)*A2)*...*AN)
>
> Commutativity doesn't help, consider
>
> data Foo = Z | A | B
>
> (~) :: Foo -> Foo -> Foo
> Z ~ x = x
> x ~ Z = x
> B ~ B = A
> _ ~ _ = B
>
> (~) is commutative, but not associative, Z is a unit for (~).
>
> foldr (~) Z [A,A,B] = B
> foldl (~) Z [A,A,B] = A
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

I've corrected it.  It still doesn't suffer looping.  :-)

On Wed, Aug 19, 2009 at 10:31 AM, David Leimbach  wrote:

> Doesn't seem to compile.
> I nearly never use case statements in my code, so I'm not really sure
> what's going on.
>
> neat2.hs:14:39: parse error on input `='
>
> Dave
>
> On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram wrote:
>
>> I posted a reply to your paste with a stricter version of S and some
>> cleanup.
>>
>> Untested, though I believe it should work without "seq".
>>
>> "case" provides all the strictness you need, I think!
>>
>>  -- ryan
>>
>> On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen
>> wrote:
>> > Expect more bugs with this though :-) Just found out that looping does
>> not
>> > work, it hangs, e.g.
>> >
>> > test = do
>> >   out "Enter your first name:"
>> >   fstName <- inp
>> >   out "Enter your second name:"
>> >   sndName <- inp
>> >   out ("Welcome "++fstName++" "++sndName)
>> >   out "Goodbye!"
>> >   test
>> >
>> > Doesn't seem to work :-) Back to the drawing board.
>> >
>> > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen 
>> > wrote:
>> >>
>> >> Not at all, use it for whatever you want to :-)
>> >> I'm writing this code because I'm preparing to write a bunch of
>> tutorials
>> >> on FRP, and I first wanted to start with simple console based FRP, e.g.
>> >> making a little text adventure game, where the input/choices of the
>> user
>> >> might be parsed ala parsec, using monadic style, applicative style, and
>> >> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
>> >> Reactive, etc...
>> >> After that I would start writing tutorials that use OpenGL, making some
>> >> very simple games, again with the above approaches, and ending with a
>> >> conversion of a very old game of mine (Zarathrusta written in assembler
>> from
>> >> 1991, which was based on Thrust from 1986, converted by myself in C++
>> to
>> >> PocketPC as G-Pod, and so I would like to make a version in Haskell
>> that
>> >> runs on the iPhone :-)
>> >> This of course is a lot of work, and I would like to put this on the
>> >> Haskell wiki or a blog or something, so others can contribute and
>> comment. I
>> >> would like to show real examples that explain the shortcomings of the
>> FRP
>> >> approaches, because now this is still a bit blurry to me.
>> >>
>> >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach 
>> wrote:
>> >>>
>> >>> This Monad you've created is quite excellent.  I was trying to do
>> >>> something like this about a year ago, to make the input and output
>> handling
>> >>> of an interactive bowling score card work nicely.  I kept running into
>> >>> issues, and did not believe that seq was going to do the trick.  Nice
>> work!
>> >>> This is a very useful monad I think, it could be called "Prompter" or
>> >>> something to that effect.
>> >>> Do you mind if I use it in some of my code?
>> >>> Dave
>> >>>
>> >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen > >
>> >>> wrote:
>> 
>>  LOL. Maybe we should have that coffee together ;-) at least
>> virtually!
>>  On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach 
>>  wrote:
>> >
>> > Argh... I too have been up too late :-).  I edited THE WRONG FILE!
>>  No
>> > wonder your change didn't take effect!  :-/
>> > Time for coffee I suppose.
>> >
>> > On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach 
>> > wrote:
>> >>
>> >> This doesn't seem to be working for me interactively though on a
>> Mac.
>> >>  I still get "Welcome" before I've entered text.
>> >>
>> >> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen <
>> bugf...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I fixed it myself but it's really tricky :-)
>> >>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>> >>> The idea is, that when the input is requested, the output that is
>> >>> then generated must be in sync with the input.
>> >>>
>> >>> inp = S $ \s i -> let r = (s `D.append` (i `seq` D.empty), head i)
>> in
>> >>> (tail i, r)
>> >>>
>> >>>
>> >>> I first had
>> >>>
>> >>> inp = S $ \s i -> let r = (i `seq` s, head i) in (tail i, r)
>> >>>
>> >>> But that was too eager, since i syncs the input not with the
>> output,
>> >>> but with the function that will generate the output.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Okay, now I can sleep again :-)
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen
>> >>>  wrote:
>> 
>>  Thanks, but that doesn't really matter in my example, my code is
>>  just buggy, and I'm not sure why. For example if I change my test
>> function
>>  so that it outputs lines only, then it still prints Welcome first
>> before
>>  asking for input.
>>  See e.g.
>> http://hpaste.org/fastcg

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Doesn't seem to compile.
I nearly never use case statements in my code, so I'm not really sure what's
going on.

neat2.hs:14:39: parse error on input `='

Dave

On Wed, Aug 19, 2009 at 10:23 AM, Ryan Ingram  wrote:

> I posted a reply to your paste with a stricter version of S and some
> cleanup.
>
> Untested, though I believe it should work without "seq".
>
> "case" provides all the strictness you need, I think!
>
>  -- ryan
>
> On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen
> wrote:
> > Expect more bugs with this though :-) Just found out that looping does
> not
> > work, it hangs, e.g.
> >
> > test = do
> >   out "Enter your first name:"
> >   fstName <- inp
> >   out "Enter your second name:"
> >   sndName <- inp
> >   out ("Welcome "++fstName++" "++sndName)
> >   out "Goodbye!"
> >   test
> >
> > Doesn't seem to work :-) Back to the drawing board.
> >
> > On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen 
> > wrote:
> >>
> >> Not at all, use it for whatever you want to :-)
> >> I'm writing this code because I'm preparing to write a bunch of
> tutorials
> >> on FRP, and I first wanted to start with simple console based FRP, e.g.
> >> making a little text adventure game, where the input/choices of the user
> >> might be parsed ala parsec, using monadic style, applicative style, and
> >> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
> >> Reactive, etc...
> >> After that I would start writing tutorials that use OpenGL, making some
> >> very simple games, again with the above approaches, and ending with a
> >> conversion of a very old game of mine (Zarathrusta written in assembler
> from
> >> 1991, which was based on Thrust from 1986, converted by myself in C++ to
> >> PocketPC as G-Pod, and so I would like to make a version in Haskell that
> >> runs on the iPhone :-)
> >> This of course is a lot of work, and I would like to put this on the
> >> Haskell wiki or a blog or something, so others can contribute and
> comment. I
> >> would like to show real examples that explain the shortcomings of the
> FRP
> >> approaches, because now this is still a bit blurry to me.
> >>
> >> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach 
> wrote:
> >>>
> >>> This Monad you've created is quite excellent.  I was trying to do
> >>> something like this about a year ago, to make the input and output
> handling
> >>> of an interactive bowling score card work nicely.  I kept running into
> >>> issues, and did not believe that seq was going to do the trick.  Nice
> work!
> >>> This is a very useful monad I think, it could be called "Prompter" or
> >>> something to that effect.
> >>> Do you mind if I use it in some of my code?
> >>> Dave
> >>>
> >>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen 
> >>> wrote:
> 
>  LOL. Maybe we should have that coffee together ;-) at least virtually!
>  On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach 
>  wrote:
> >
> > Argh... I too have been up too late :-).  I edited THE WRONG FILE!
>  No
> > wonder your change didn't take effect!  :-/
> > Time for coffee I suppose.
> >
> > On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach 
> > wrote:
> >>
> >> This doesn't seem to be working for me interactively though on a
> Mac.
> >>  I still get "Welcome" before I've entered text.
> >>
> >> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen <
> bugf...@gmail.com>
> >> wrote:
> >>>
> >>> I fixed it myself but it's really tricky :-)
> >>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
> >>> The idea is, that when the input is requested, the output that is
> >>> then generated must be in sync with the input.
> >>>
> >>> inp = S $ \s i -> let r = (s `D.append` (i `seq` D.empty), head i)
> in
> >>> (tail i, r)
> >>>
> >>>
> >>> I first had
> >>>
> >>> inp = S $ \s i -> let r = (i `seq` s, head i) in (tail i, r)
> >>>
> >>> But that was too eager, since i syncs the input not with the
> output,
> >>> but with the function that will generate the output.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Okay, now I can sleep again :-)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen
> >>>  wrote:
> 
>  Thanks, but that doesn't really matter in my example, my code is
>  just buggy, and I'm not sure why. For example if I change my test
> function
>  so that it outputs lines only, then it still prints Welcome first
> before
>  asking for input.
>  See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>  On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach <
> leim...@gmail.com>
>  wrote:
> >
> > Try LineBuffering.
> > I do linewise stuff with interact a lot.  You'll find stuff like
> > unlines . lines
> 

[Haskell-cafe] gbp sign showing as unknown character by GHC

[Iain Barnett]

Quick question: I've tested this in a couple of different terminals (roxterm
and xterm), so I'm fairly sure it's GHC that's the problem. Have I missed a
setting?
GHCi, version 6.10.4
Prelude> putStrLn "£"
�

Hugs98 200609-3
Hugs> putStrLn "£"
£


I get the same character output from a password generator I've writtern,
after compilation with GHC

[iainb]$ ./makepass2 50 2 >> testfile.txt
[iainb]$ cat testfile.txt
H(xW!:maNyxZ;h,IW=Uu4G$ztc>k...@q[g6?y:�TbG&5Nd")+"5+


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

Re: [Haskell-cafe] Re: Where do I put the seq?

[Ryan Ingram]

I posted a reply to your paste with a stricter version of S and some cleanup.

Untested, though I believe it should work without "seq".

"case" provides all the strictness you need, I think!

  -- ryan

On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen wrote:
> Expect more bugs with this though :-) Just found out that looping does not
> work, it hangs, e.g.
>
> test = do
>   out "Enter your first name:"
>   fstName <- inp
>   out "Enter your second name:"
>   sndName <- inp
>   out ("Welcome "++fstName++" "++sndName)
>   out "Goodbye!"
>   test
>
> Doesn't seem to work :-) Back to the drawing board.
>
> On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen 
> wrote:
>>
>> Not at all, use it for whatever you want to :-)
>> I'm writing this code because I'm preparing to write a bunch of tutorials
>> on FRP, and I first wanted to start with simple console based FRP, e.g.
>> making a little text adventure game, where the input/choices of the user
>> might be parsed ala parsec, using monadic style, applicative style, and
>> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
>> Reactive, etc...
>> After that I would start writing tutorials that use OpenGL, making some
>> very simple games, again with the above approaches, and ending with a
>> conversion of a very old game of mine (Zarathrusta written in assembler from
>> 1991, which was based on Thrust from 1986, converted by myself in C++ to
>> PocketPC as G-Pod, and so I would like to make a version in Haskell that
>> runs on the iPhone :-)
>> This of course is a lot of work, and I would like to put this on the
>> Haskell wiki or a blog or something, so others can contribute and comment. I
>> would like to show real examples that explain the shortcomings of the FRP
>> approaches, because now this is still a bit blurry to me.
>>
>> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach  wrote:
>>>
>>> This Monad you've created is quite excellent.  I was trying to do
>>> something like this about a year ago, to make the input and output handling
>>> of an interactive bowling score card work nicely.  I kept running into
>>> issues, and did not believe that seq was going to do the trick.  Nice work!
>>> This is a very useful monad I think, it could be called "Prompter" or
>>> something to that effect.
>>> Do you mind if I use it in some of my code?
>>> Dave
>>>
>>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen 
>>> wrote:

 LOL. Maybe we should have that coffee together ;-) at least virtually!
 On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach 
 wrote:
>
> Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
> wonder your change didn't take effect!  :-/
> Time for coffee I suppose.
>
> On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach 
> wrote:
>>
>> This doesn't seem to be working for me interactively though on a Mac.
>>  I still get "Welcome" before I've entered text.
>>
>> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen 
>> wrote:
>>>
>>> I fixed it myself but it's really tricky :-)
>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>> The idea is, that when the input is requested, the output that is
>>> then generated must be in sync with the input.
>>>
>>> inp = S $ \s i -> let r = (s `D.append` (i `seq` D.empty), head i) in
>>> (tail i, r)
>>>
>>>
>>> I first had
>>>
>>> inp = S $ \s i -> let r = (i `seq` s, head i) in (tail i, r)
>>>
>>> But that was too eager, since i syncs the input not with the output,
>>> but with the function that will generate the output.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Okay, now I can sleep again :-)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen
>>>  wrote:

 Thanks, but that doesn't really matter in my example, my code is
 just buggy, and I'm not sure why. For example if I change my test 
 function
 so that it outputs lines only, then it still prints Welcome first 
 before
 asking for input.
 See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
 On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach 
 wrote:
>
> Try LineBuffering.
> I do linewise stuff with interact a lot.  You'll find stuff like
> unlines . lines
> may help too.  In fact I just wrote a blog post about this.
> http://leimy9.blogspot.com
> I'm trying to write some interactive code to automate working with
> serial console controlled power strips, so I need to either use Expect
> (yuck) or do my own thing.
> Dave
>
> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen
>  wrote:
>>
>> Apparently this particular example happens to work on Mac and
>> Linux becaus

Re: [Haskell-cafe] Observations about foldM

[Edward Kmett]

It is associativity that is required, not commutativity (in addition to the
fact that the list is finite).

This is why Data.Foldable provides operations for monoids over containers.
Monoids just provide you with associativity and a unit, which lets you
reparenthesize the fold however you want.

See the monoids library or my slides from hac-phi for lots of (ab)uses of a
monoid's associativity.

http://comonad.com/reader/2009/hac-phi-slides/

-Edward Kmett

On Wed, Aug 19, 2009 at 10:32 AM, Eugene Kirpichov wrote:

> 2009/8/19 Dan Doel :
> > On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:
> >> Interestingly, foldM can also be written as a left fold. To see this,
> note
> >> that it is a theorem that foldr f z xs = foldl f z xs as long as f is
> >> associative and z is a unit for f.
> >
>
> This is not true: f has to be commutative, not associative.
>
> Consider matrix multiplication.
>
> > It must also be the case that xs is finite in length, because if it is
> > infinite, then 'foldl f z xs' is bottom, while 'foldr f z xs' needn't be.
> This
> > difference holds over into foldM implemented with each, where you can
> write
> > something like:
> >
> >  foldM (\f e -> if even e then Left (show e) else Right f) "no evens"
> [1..]
> >
> > and get an answer of 'Left "2"' with a foldr implementation, but bottom
> with a
> > foldl implementation.
> >
> > This potentially translates into its own performance concerns, because in
> such
> > monads, the computation can short-circuit upon finding a 'throw' when
> using
> > the foldr implementation, but with the foldl implementation, you have to
> do at
> > least a little shuffling of thunks for the entire list.
> >
> > -- Dan
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Eugene Kirpichov
> Web IR developer, market.yandex.ru
>  ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haddock: Failed to create dependency graph (when adding sections with * or a module heading)

[Jared Updike]

I compiled and installed haddock-2.4.2 from the tarball source.

Adding a few simple comments to the code here:

  https://dl.getdropbox.com/u/143480/doc/DualMap.hs

and running haddock

$ haddock -h -o doc Data/DualMap.hs
Warning: Data.DualMap: could not find link destinations for:
Data.Typeable.Typeable2 GHC.Base.Eq GHC.Show.Show GHC.Base.Ord
GHC.Base.Bool Data.Set.Set

yields:

  https://dl.getdropbox.com/u/143480/doc/Data-DualMap.html

Things look good. (Note that this module only depends on libs that ship with
GHC and no other source modules.)

However, when I try to add sections (a la
http://www.haskell.org/haddock/doc/html/ch03s04.html#id289234 ) in the
comments with "-- * test" I get:

$ haddock -h -o doc Data/DualMap.hs
Data/DualMap.hs:20:0: parse error on input `-- * test'
haddock: Failed to create dependency graph

I have no idea where to begin getting this to work since this error message
only tells me that Haddock.Interface.depanal returned Nothing (according to
a grep of the haddock sources) but not how to stop the dependency analysis
from failing. Perhaps I need some more command line arguments or references
to missing link destinations in GHC/base/containers documentation or some
haddock config file?

Searching Google yielded plenty of cabal build errors of the same ilk for
packages on hackage but nothing about how to fix them.

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

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Yet this does work
interact $ run test9

test9 = replicateM 9 test

Will run test 9 times.  I suppose if one constructed an infinite list you
could loop as you wanted to.

Yet, that might not be what you want.

Dave

On Wed, Aug 19, 2009 at 9:28 AM, Peter Verswyvelen wrote:

> Expect more bugs with this though :-) Just found out that looping does not
> work, it hangs, e.g.
>
> test = do  out "Enter your first name:"  fstName <- inp  out "Enter your 
> second name:"  sndName <- inp  out ("Welcome "++fstName++" "++sndName)  out 
> "Goodbye!"*  **test*
>
> Doesn't seem to work :-) Back to the drawing board.
>
>
> On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen wrote:
>
>> Not at all, use it for whatever you want to :-)
>> I'm writing this code because I'm preparing to write a bunch of tutorials
>> on FRP, and I first wanted to start with simple console based FRP, e.g.
>> making a little text adventure game, where the input/choices of the user
>> might be parsed ala parsec, using monadic style, applicative style, and
>> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
>> Reactive, etc...
>>
>> After that I would start writing tutorials that use OpenGL, making some
>> very simple games, again with the above approaches, and ending with a
>> conversion of a very old game of mine (Zarathrusta written in assembler from
>> 1991, which was based on 
>> Thrustfrom 1986, converted by 
>> myself in C++ to PocketPC as
>> G-Pod,
>> and so I would like to make a version in Haskell that runs on the iPhone :-)
>>
>> This of course is a lot of work, and I would like to put this on the
>> Haskell wiki or a blog or something, so others can contribute and comment. I
>> would like to show real examples that explain the shortcomings of the FRP
>> approaches, because now this is still a bit blurry to me.
>>
>>
>>
>> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach wrote:
>>
>>> This Monad you've created is quite excellent.  I was trying to do
>>> something like this about a year ago, to make the input and output handling
>>> of an interactive bowling score card work nicely.  I kept running into
>>> issues, and did not believe that seq was going to do the trick.  Nice work!
>>> This is a very useful monad I think, it could be called "Prompter" or
>>> something to that effect.
>>>
>>> Do you mind if I use it in some of my code?
>>>
>>> Dave
>>>
>>>
>>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen wrote:
>>>
 LOL. Maybe we should have that coffee together ;-) at least virtually!

 On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach wrote:

> Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
> wonder your change didn't take effect!  :-/
> Time for coffee I suppose.
>
>
> On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach wrote:
>
>> This doesn't seem to be working for me interactively though on a Mac.
>>  I still get "Welcome" before I've entered text.
>>
>>
>> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen > > wrote:
>>
>>> I fixed it myself but it's really tricky :-)
>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>>
>>> The idea
>>> is, that when the input is requested, the output that is then generated 
>>> must
>>> be in sync with the input.
>>>
>>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** 
>>> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r)
>>>
>>>
>>>
>>> I first had
>>>
>>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>>>
>>>
>>> But that was too eager, since i syncs the input not with the output,
>>> but with the function that will generate the output.
>>>
>>> Okay, now I can sleep again :-)
>>>
>>>
>>>
>>>
>>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen <
>>> bugf...@gmail.com> wrote:
>>>
 Thanks, but that doesn't really matter in my example, my code is
 just buggy, and I'm not sure why. For example if I change my test 
 function
 so that it outputs lines only, then it still prints Welcome first 
 before
 asking for input.
 See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328

 On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach 
 wrote:

> Try LineBuffering.
> I do linewise stuff with interact a lot.  You'll find stuff like
>
> unlines . lines
>
> may help too.  In fact I just wrote a blog post about this.
>
> http://leimy9.blogspot.com
>
> I'm trying to write some interactive code to automate working with
> serial console controlled power strips, so I need to

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Have you spoken to Conal Elliott about this stuff?  He might be interested.
 He was looking for doing this sort of thing on iPhones for a bit.
Also, I was wondering if you thought this Monad might be useful as a way to
automate tasks in an Expect like fashion.  I've been struggling with a good
way to do this stuff in Haskell for a while.

One challenge is that input is not always line oriented, for example the
"Password: " token that we get when we use ssh interactively.  My first
thought was to try to avoid seq, and use "words" and "unwords".

However, I'm thinking now that I'm going to need new Monad Operations like
inp, but for different token sizes and possibly different matches of
characters.

Dave

On Wed, Aug 19, 2009 at 8:55 AM, Peter Verswyvelen wrote:

> Not at all, use it for whatever you want to :-)
> I'm writing this code because I'm preparing to write a bunch of tutorials
> on FRP, and I first wanted to start with simple console based FRP, e.g.
> making a little text adventure game, where the input/choices of the user
> might be parsed ala parsec, using monadic style, applicative style, and
> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
> Reactive, etc...
>
> After that I would start writing tutorials that use OpenGL, making some
> very simple games, again with the above approaches, and ending with a
> conversion of a very old game of mine (Zarathrusta written in assembler from
> 1991, which was based on 
> Thrustfrom 1986, converted by 
> myself in C++ to PocketPC as
> G-Pod,
> and so I would like to make a version in Haskell that runs on the iPhone :-)
>
> This of course is a lot of work, and I would like to put this on the
> Haskell wiki or a blog or something, so others can contribute and comment. I
> would like to show real examples that explain the shortcomings of the FRP
> approaches, because now this is still a bit blurry to me.
>
>
>
> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach  wrote:
>
>> This Monad you've created is quite excellent.  I was trying to do
>> something like this about a year ago, to make the input and output handling
>> of an interactive bowling score card work nicely.  I kept running into
>> issues, and did not believe that seq was going to do the trick.  Nice work!
>> This is a very useful monad I think, it could be called "Prompter" or
>> something to that effect.
>>
>> Do you mind if I use it in some of my code?
>>
>> Dave
>>
>>
>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen wrote:
>>
>>> LOL. Maybe we should have that coffee together ;-) at least virtually!
>>>
>>> On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach wrote:
>>>
 Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
 wonder your change didn't take effect!  :-/
 Time for coffee I suppose.


 On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach wrote:

> This doesn't seem to be working for me interactively though on a Mac.
>  I still get "Welcome" before I've entered text.
>
>
> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen 
> wrote:
>
>> I fixed it myself but it's really tricky :-)
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>
>> The idea
>> is, that when the input is requested, the output that is then generated 
>> must
>> be in sync with the input.
>>
>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** 
>> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r)
>>
>>
>>
>> I first had
>>
>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>>
>>
>> But that was too eager, since i syncs the input not with the output,
>> but with the function that will generate the output.
>>
>> Okay, now I can sleep again :-)
>>
>>
>>
>>
>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen > > wrote:
>>
>>> Thanks, but that doesn't really matter in my example, my code is just
>>> buggy, and I'm not sure why. For example if I change my test function so
>>> that it outputs lines only, then it still prints Welcome first before 
>>> asking
>>> for input.
>>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>>>
>>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach 
>>> wrote:
>>>
 Try LineBuffering.
 I do linewise stuff with interact a lot.  You'll find stuff like

 unlines . lines

 may help too.  In fact I just wrote a blog post about this.

 http://leimy9.blogspot.com

 I'm trying to write some interactive code to automate working with
 serial console controlled power strips, so I need to either use Expect
 (yuck) or do m

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Expect more bugs with this though :-) Just found out that looping does not
work, it hangs, e.g.

test = do  out "Enter your first name:"  fstName <- inp  out "Enter
your second name:"  sndName <- inp  out ("Welcome "++fstName++"
"++sndName)  out "Goodbye!"*  **test*

Doesn't seem to work :-) Back to the drawing board.


On Wed, Aug 19, 2009 at 5:55 PM, Peter Verswyvelen wrote:

> Not at all, use it for whatever you want to :-)
> I'm writing this code because I'm preparing to write a bunch of tutorials
> on FRP, and I first wanted to start with simple console based FRP, e.g.
> making a little text adventure game, where the input/choices of the user
> might be parsed ala parsec, using monadic style, applicative style, and
> arrows, and then doing the same with FRP frameworks like Yampa, Elera,
> Reactive, etc...
>
> After that I would start writing tutorials that use OpenGL, making some
> very simple games, again with the above approaches, and ending with a
> conversion of a very old game of mine (Zarathrusta written in assembler from
> 1991, which was based on 
> Thrustfrom 1986, converted by 
> myself in C++ to PocketPC as
> G-Pod,
> and so I would like to make a version in Haskell that runs on the iPhone :-)
>
> This of course is a lot of work, and I would like to put this on the
> Haskell wiki or a blog or something, so others can contribute and comment. I
> would like to show real examples that explain the shortcomings of the FRP
> approaches, because now this is still a bit blurry to me.
>
>
>
> On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach  wrote:
>
>> This Monad you've created is quite excellent.  I was trying to do
>> something like this about a year ago, to make the input and output handling
>> of an interactive bowling score card work nicely.  I kept running into
>> issues, and did not believe that seq was going to do the trick.  Nice work!
>> This is a very useful monad I think, it could be called "Prompter" or
>> something to that effect.
>>
>> Do you mind if I use it in some of my code?
>>
>> Dave
>>
>>
>> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen wrote:
>>
>>> LOL. Maybe we should have that coffee together ;-) at least virtually!
>>>
>>> On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach wrote:
>>>
 Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
 wonder your change didn't take effect!  :-/
 Time for coffee I suppose.


 On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach wrote:

> This doesn't seem to be working for me interactively though on a Mac.
>  I still get "Welcome" before I've entered text.
>
>
> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen 
> wrote:
>
>> I fixed it myself but it's really tricky :-)
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>
>> The idea
>> is, that when the input is requested, the output that is then generated 
>> must
>> be in sync with the input.
>>
>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** 
>> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r)
>>
>>
>>
>> I first had
>>
>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>>
>>
>> But that was too eager, since i syncs the input not with the output,
>> but with the function that will generate the output.
>>
>> Okay, now I can sleep again :-)
>>
>>
>>
>>
>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen > > wrote:
>>
>>> Thanks, but that doesn't really matter in my example, my code is just
>>> buggy, and I'm not sure why. For example if I change my test function so
>>> that it outputs lines only, then it still prints Welcome first before 
>>> asking
>>> for input.
>>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>>>
>>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach 
>>> wrote:
>>>
 Try LineBuffering.
 I do linewise stuff with interact a lot.  You'll find stuff like

 unlines . lines

 may help too.  In fact I just wrote a blog post about this.

 http://leimy9.blogspot.com

 I'm trying to write some interactive code to automate working with
 serial console controlled power strips, so I need to either use Expect
 (yuck) or do my own thing.

 Dave

 On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen <
 bugf...@gmail.com> wrote:

> Apparently this particular example happens to work on Mac and Linux
> because of different buffering (thanks Martijn for the help!)
> To make sure we have no buffering at all, the main function should
> be:

Re: [Haskell-cafe] Re: ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Colin Paul Adams]

> "Jon" == Jon Fairbairn  writes:

>> Will it be cabal-ized soon?

Jon> That depends on whether anyone wants it done sufficiently
Jon> strongly to do it.

Then I guess I will - some time in October.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Not at all, use it for whatever you want to :-)
I'm writing this code because I'm preparing to write a bunch of tutorials on
FRP, and I first wanted to start with simple console based FRP, e.g. making
a little text adventure game, where the input/choices of the user might be
parsed ala parsec, using monadic style, applicative style, and arrows, and
then doing the same with FRP frameworks like Yampa, Elera, Reactive, etc...

After that I would start writing tutorials that use OpenGL, making some very
simple games, again with the above approaches, and ending with a conversion
of a very old game of mine (Zarathrusta written in assembler from 1991,
which was based on Thrust
from 1986, converted by
myself in C++ to PocketPC as
G-Pod,
and so I would like to make a version in Haskell that runs on the iPhone :-)

This of course is a lot of work, and I would like to put this on the Haskell
wiki or a blog or something, so others can contribute and comment. I would
like to show real examples that explain the shortcomings of the FRP
approaches, because now this is still a bit blurry to me.



On Wed, Aug 19, 2009 at 5:43 PM, David Leimbach  wrote:

> This Monad you've created is quite excellent.  I was trying to do something
> like this about a year ago, to make the input and output handling of an
> interactive bowling score card work nicely.  I kept running into issues, and
> did not believe that seq was going to do the trick.  Nice work!
> This is a very useful monad I think, it could be called "Prompter" or
> something to that effect.
>
> Do you mind if I use it in some of my code?
>
> Dave
>
>
> On Wed, Aug 19, 2009 at 8:42 AM, Peter Verswyvelen wrote:
>
>> LOL. Maybe we should have that coffee together ;-) at least virtually!
>>
>> On Wed, Aug 19, 2009 at 5:39 PM, David Leimbach wrote:
>>
>>> Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
>>> wonder your change didn't take effect!  :-/
>>> Time for coffee I suppose.
>>>
>>>
>>> On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach wrote:
>>>
 This doesn't seem to be working for me interactively though on a Mac.  I
 still get "Welcome" before I've entered text.


 On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen 
 wrote:

> I fixed it myself but it's really tricky :-)
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>
> The idea is,
> that when the input is requested, the output that is then generated must 
> be
> in sync with the input.
>
> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** 
> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r)
>
>
>
> I first had
>
> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>
>
> But that was too eager, since i syncs the input not with the output,
> but with the function that will generate the output.
>
> Okay, now I can sleep again :-)
>
>
>
>
> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen 
> wrote:
>
>> Thanks, but that doesn't really matter in my example, my code is just
>> buggy, and I'm not sure why. For example if I change my test function so
>> that it outputs lines only, then it still prints Welcome first before 
>> asking
>> for input.
>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>>
>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach wrote:
>>
>>> Try LineBuffering.
>>> I do linewise stuff with interact a lot.  You'll find stuff like
>>>
>>> unlines . lines
>>>
>>> may help too.  In fact I just wrote a blog post about this.
>>>
>>> http://leimy9.blogspot.com
>>>
>>> I'm trying to write some interactive code to automate working with
>>> serial console controlled power strips, so I need to either use Expect
>>> (yuck) or do my own thing.
>>>
>>> Dave
>>>
>>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen <
>>> bugf...@gmail.com> wrote:
>>>
 Apparently this particular example happens to work on Mac and Linux
 because of different buffering (thanks Martijn for the help!)
 To make sure we have no buffering at all, the main function should
 be:

 main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin 
 NoBuffering  test

 Now I think it should also be *incorrect* on Unix systems.

 I guess the way I'm concatenating the strings is not correct, not
 sure.

 I would like to use a graphical tool to show the graph reduction
 step by step, to get a better understanding of the laziness & 
 strictness.
 Does such a tool exist? I know people often say this is n

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

Argh... I too have been up too late :-).  I edited THE WRONG FILE!  No
wonder your change didn't take effect!  :-/
Time for coffee I suppose.

On Wed, Aug 19, 2009 at 8:38 AM, David Leimbach  wrote:

> This doesn't seem to be working for me interactively though on a Mac.  I
> still get "Welcome" before I've entered text.
>
>
> On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen wrote:
>
>> I fixed it myself but it's really tricky :-)
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>>
>> The idea is,
>> that when the input is requested, the output that is then generated must be
>> in sync with the input.
>>
>> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** 
>> **`**seq**`** **D**.**empty**)*, head i) in (tail i, r)
>>
>>
>>
>> I first had
>>
>> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>>
>>
>> But that was too eager, since i syncs the input not with the output, but
>> with the function that will generate the output.
>>
>> Okay, now I can sleep again :-)
>>
>>
>>
>>
>> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen wrote:
>>
>>> Thanks, but that doesn't really matter in my example, my code is just
>>> buggy, and I'm not sure why. For example if I change my test function so
>>> that it outputs lines only, then it still prints Welcome first before asking
>>> for input.
>>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>>>
>>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach wrote:
>>>
 Try LineBuffering.
 I do linewise stuff with interact a lot.  You'll find stuff like

 unlines . lines

 may help too.  In fact I just wrote a blog post about this.

 http://leimy9.blogspot.com

 I'm trying to write some interactive code to automate working with
 serial console controlled power strips, so I need to either use Expect
 (yuck) or do my own thing.

 Dave

 On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen 
 wrote:

> Apparently this particular example happens to work on Mac and Linux
> because of different buffering (thanks Martijn for the help!)
> To make sure we have no buffering at all, the main function should be:
>
> main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin 
> NoBuffering  test
>
> Now I think it should also be *incorrect* on Unix systems.
>
> I guess the way I'm concatenating the strings is not correct, not sure.
>
> I would like to use a graphical tool to show the graph reduction step
> by step, to get a better understanding of the laziness & strictness. Does
> such a tool exist? I know people often say this is not usable because the
> amount of information is too much, but I used to be an assembly language
> programmer so I still would like to give it a try :-)
>
>
>
> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen 
> wrote:
>
>> In an attempt to get a deeper understanding of several monads (State,
>> ST, IO, ...) I skimmed over some of the research papers (but didn't
>> understand all of it, I lack the required education) and decided to 
>> write a
>> little program myself without using any prefab monad instances that 
>> should
>> mimic the following:
>> main = do
>>   putStrLn "Enter your name:"
>>   x <- getLine
>>   putStr "Welcome "
>>   putStrLn x
>>   putStrLn "Goodbye!"
>>
>> But instead of using IO, I wanted to make my own pure monad that gets
>> evaluated with interact, and does the same.
>>
>> However, I get the following output:
>>
>> Enter your name:
>> Welcome ..
>>
>> So the Welcome is printed too soon.
>>
>> This is obvious since my monad is lazy, so I tried to put a seq at
>> some strategic places to get the same behavior as IO. But I completely
>> failed doing so, either the program doesn't print anything and asks input
>> first, or it still prints too much output.
>>
>> Of course I could just use ST, State, transformers, etc, but this is
>> purely an exercise I'm doing.
>>
>> So, I could re-read all papers and look in detail at all the code, but
>> maybe someone could help me out where to put the seq or what to do :-)
>>
>> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316
>>
>> Oh btw, the usage of DList here might not be needed; intuitively it
>> felt like the correct thing to do, but when it comes to Haskell, my
>> intuition is usually wrong ;-)
>>
>> Thanks a lot,
>> Peter Verswyvelen
>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

>>>
>>
>
___
Haskell-Cafe mailing list
Haskell

Re: [Haskell-cafe] Re: Where do I put the seq?

[David Leimbach]

This doesn't seem to be working for me interactively though on a Mac.  I
still get "Welcome" before I've entered text.

On Wed, Aug 19, 2009 at 8:25 AM, Peter Verswyvelen wrote:

> I fixed it myself but it's really tricky :-)
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330
>
> The idea is,
> that when the input is requested, the output that is then generated must be
> in sync with the input.
>
> inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i** **`**seq**`** 
> **D**.**empty**)*, head i) in (tail i, r)
>
>
>
> I first had
>
> inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)
>
>
> But that was too eager, since i syncs the input not with the output, but
> with the function that will generate the output.
>
> Okay, now I can sleep again :-)
>
>
>
>
> On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen wrote:
>
>> Thanks, but that doesn't really matter in my example, my code is just
>> buggy, and I'm not sure why. For example if I change my test function so
>> that it outputs lines only, then it still prints Welcome first before asking
>> for input.
>> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>>
>> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach wrote:
>>
>>> Try LineBuffering.
>>> I do linewise stuff with interact a lot.  You'll find stuff like
>>>
>>> unlines . lines
>>>
>>> may help too.  In fact I just wrote a blog post about this.
>>>
>>> http://leimy9.blogspot.com
>>>
>>> I'm trying to write some interactive code to automate working with serial
>>> console controlled power strips, so I need to either use Expect (yuck) or do
>>> my own thing.
>>>
>>> Dave
>>>
>>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen wrote:
>>>
 Apparently this particular example happens to work on Mac and Linux
 because of different buffering (thanks Martijn for the help!)
 To make sure we have no buffering at all, the main function should be:

 main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin 
 NoBuffering  test

 Now I think it should also be *incorrect* on Unix systems.

 I guess the way I'm concatenating the strings is not correct, not sure.

 I would like to use a graphical tool to show the graph reduction step by
 step, to get a better understanding of the laziness & strictness. Does such
 a tool exist? I know people often say this is not usable because the amount
 of information is too much, but I used to be an assembly language 
 programmer
 so I still would like to give it a try :-)



 On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen 
 wrote:

> In an attempt to get a deeper understanding of several monads (State,
> ST, IO, ...) I skimmed over some of the research papers (but didn't
> understand all of it, I lack the required education) and decided to write 
> a
> little program myself without using any prefab monad instances that should
> mimic the following:
> main = do
>   putStrLn "Enter your name:"
>   x <- getLine
>   putStr "Welcome "
>   putStrLn x
>   putStrLn "Goodbye!"
>
> But instead of using IO, I wanted to make my own pure monad that gets
> evaluated with interact, and does the same.
>
> However, I get the following output:
>
> Enter your name:
> Welcome ..
>
> So the Welcome is printed too soon.
>
> This is obvious since my monad is lazy, so I tried to put a seq at some
> strategic places to get the same behavior as IO. But I completely failed
> doing so, either the program doesn't print anything and asks input first, 
> or
> it still prints too much output.
>
> Of course I could just use ST, State, transformers, etc, but this is
> purely an exercise I'm doing.
>
> So, I could re-read all papers and look in detail at all the code, but
> maybe someone could help me out where to put the seq or what to do :-)
>
> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316
>
> Oh btw, the usage of DList here might not be needed; intuitively it
> felt like the correct thing to do, but when it comes to Haskell, my
> intuition is usually wrong ;-)
>
> Thanks a lot,
> Peter Verswyvelen
>
>

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


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

[Haskell-cafe] Re: ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Jon Fairbairn]

Colin Paul Adams  writes:

>> "Jon" == Jon Fairbairn  writes:
> Jon> darcs get --partial
> Jon> http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs
>
> Did you make any progress on this at Anglo-Haskell?

Not really, owing to Microsoft site security ;-) [not that they were
being unreasonable, just that it cut me off rather abruptly]. I've
started some notes connected with this at

(which as implied is not quite finished), though they are not especially
interesting to anyone who simply wants to use the library.

> Will it be cabal-ized soon?

That depends on whether anyone wants it done sufficiently strongly to do
it... at the moment I'm not motivated to learning how to do it (if I get
past all the non-programming stuff on my life to-do list, there are
several things on the project's TODO list that come before "Caballise").
After all, if I'm the only person using the library, there's no reason
to caballise... granted, that smacks of a self fulfilling prophecy, but
I'm led to believe that if someone already knows cabal, it would be the
work of moments to do the job, whereas learning it would take
significant effort¹

The license would need attention too... in the absence of convincing
arguments to the contrary, I would favour GPL myself.


[1] And by the time I next wanted to do it, the chances are it would
have changed so much (or I would have forgotten it anyway) that I'd have
to learn it again.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk


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

Re: [Haskell-cafe] Re: Planning for a website

[Marc Weber]

Excerpts from Colin Paul Adams's message of Wed Aug 19 17:13:14 +0200 2009:
> I'd much rather be using happstack's macid stuff, especially as I will
> have only very low usage, so i shouldn't have any scalability problems.
See also this current thread: 
http://groups.google.com/group/happs/browse_thread/thread/961ab7cc28f1f91f

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

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

I fixed it myself but it's really tricky :-)
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8330

The idea is, that
when the input is requested, the output that is then generated must be in
sync with the input.

inp = S $ \s i -> let r = (*s** **`**D**.**append**`** **(**i**
**`**seq**`** **D**.**empty**)*, head i) in (tail i, r)


I first had

inp = S $ \s i -> let r = (i `seq` *s*, head i) in (tail i, r)


But that was too eager, since i syncs the input not with the output, but
with the function that will generate the output.

Okay, now I can sleep again :-)




On Wed, Aug 19, 2009 at 5:12 PM, Peter Verswyvelen wrote:

> Thanks, but that doesn't really matter in my example, my code is just
> buggy, and I'm not sure why. For example if I change my test function so
> that it outputs lines only, then it still prints Welcome first before asking
> for input.
> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>
> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach  wrote:
>
>> Try LineBuffering.
>> I do linewise stuff with interact a lot.  You'll find stuff like
>>
>> unlines . lines
>>
>> may help too.  In fact I just wrote a blog post about this.
>>
>> http://leimy9.blogspot.com
>>
>> I'm trying to write some interactive code to automate working with serial
>> console controlled power strips, so I need to either use Expect (yuck) or do
>> my own thing.
>>
>> Dave
>>
>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen wrote:
>>
>>> Apparently this particular example happens to work on Mac and Linux
>>> because of different buffering (thanks Martijn for the help!)
>>> To make sure we have no buffering at all, the main function should be:
>>>
>>> main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin 
>>> NoBuffering  test
>>>
>>> Now I think it should also be *incorrect* on Unix systems.
>>>
>>> I guess the way I'm concatenating the strings is not correct, not sure.
>>>
>>> I would like to use a graphical tool to show the graph reduction step by
>>> step, to get a better understanding of the laziness & strictness. Does such
>>> a tool exist? I know people often say this is not usable because the amount
>>> of information is too much, but I used to be an assembly language programmer
>>> so I still would like to give it a try :-)
>>>
>>>
>>>
>>> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen wrote:
>>>
 In an attempt to get a deeper understanding of several monads (State,
 ST, IO, ...) I skimmed over some of the research papers (but didn't
 understand all of it, I lack the required education) and decided to write a
 little program myself without using any prefab monad instances that should
 mimic the following:
 main = do
   putStrLn "Enter your name:"
   x <- getLine
   putStr "Welcome "
   putStrLn x
   putStrLn "Goodbye!"

 But instead of using IO, I wanted to make my own pure monad that gets
 evaluated with interact, and does the same.

 However, I get the following output:

 Enter your name:
 Welcome ..

 So the Welcome is printed too soon.

 This is obvious since my monad is lazy, so I tried to put a seq at some
 strategic places to get the same behavior as IO. But I completely failed
 doing so, either the program doesn't print anything and asks input first, 
 or
 it still prints too much output.

 Of course I could just use ST, State, transformers, etc, but this is
 purely an exercise I'm doing.

 So, I could re-read all papers and look in detail at all the code, but
 maybe someone could help me out where to put the seq or what to do :-)

 The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316

 Oh btw, the usage of DList here might not be needed; intuitively it felt
 like the correct thing to do, but when it comes to Haskell, my intuition is
 usually wrong ;-)

 Thanks a lot,
 Peter Verswyvelen


>>>
>>> ___
>>> 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: Where do I put the seq?

[David Leimbach]

On Wed, Aug 19, 2009 at 8:12 AM, Peter Verswyvelen wrote:

> Thanks, but that doesn't really matter in my example, my code is just
> buggy, and I'm not sure why. For example if I change my test function so
> that it outputs lines only, then it still prints Welcome first before asking
> for input.
>


Ah I see, I misunderstood. Sorry for the noise!  ;-)  I thought perhaps
you'd hit something I ran into last night.


Dave

>
> See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328
>
> On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach  wrote:
>
>> Try LineBuffering.
>> I do linewise stuff with interact a lot.  You'll find stuff like
>>
>> unlines . lines
>>
>> may help too.  In fact I just wrote a blog post about this.
>>
>> http://leimy9.blogspot.com
>>
>> I'm trying to write some interactive code to automate working with serial
>> console controlled power strips, so I need to either use Expect (yuck) or do
>> my own thing.
>>
>> Dave
>>
>> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen wrote:
>>
>>> Apparently this particular example happens to work on Mac and Linux
>>> because of different buffering (thanks Martijn for the help!)
>>> To make sure we have no buffering at all, the main function should be:
>>>
>>> main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin 
>>> NoBuffering  test
>>>
>>> Now I think it should also be *incorrect* on Unix systems.
>>>
>>> I guess the way I'm concatenating the strings is not correct, not sure.
>>>
>>> I would like to use a graphical tool to show the graph reduction step by
>>> step, to get a better understanding of the laziness & strictness. Does such
>>> a tool exist? I know people often say this is not usable because the amount
>>> of information is too much, but I used to be an assembly language programmer
>>> so I still would like to give it a try :-)
>>>
>>>
>>>
>>> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen wrote:
>>>
 In an attempt to get a deeper understanding of several monads (State,
 ST, IO, ...) I skimmed over some of the research papers (but didn't
 understand all of it, I lack the required education) and decided to write a
 little program myself without using any prefab monad instances that should
 mimic the following:
 main = do
   putStrLn "Enter your name:"
   x <- getLine
   putStr "Welcome "
   putStrLn x
   putStrLn "Goodbye!"

 But instead of using IO, I wanted to make my own pure monad that gets
 evaluated with interact, and does the same.

 However, I get the following output:

 Enter your name:
 Welcome ..

 So the Welcome is printed too soon.

 This is obvious since my monad is lazy, so I tried to put a seq at some
 strategic places to get the same behavior as IO. But I completely failed
 doing so, either the program doesn't print anything and asks input first, 
 or
 it still prints too much output.

 Of course I could just use ST, State, transformers, etc, but this is
 purely an exercise I'm doing.

 So, I could re-read all papers and look in detail at all the code, but
 maybe someone could help me out where to put the seq or what to do :-)

 The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316

 Oh btw, the usage of DList here might not be needed; intuitively it felt
 like the correct thing to do, but when it comes to Haskell, my intuition is
 usually wrong ;-)

 Thanks a lot,
 Peter Verswyvelen


>>>
>>> ___
>>> 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: ANN: Typeful/Text/HTMLs (for AngloHaskell/for scrap?)

[Colin Paul Adams]

> "Jon" == Jon Fairbairn  writes:

Jon> I wrote:
>> You can get the whole thing with
>> 
>> darcs get --partial
>> http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/nHTMLs

Jon> but that was a temporary url that I copied and pasted. The
Jon> correct one:

Jon> darcs get --partial
Jon> http://homepage.ntlworld.com/jon.fairbairn/Typeful/Text/HTMLs

Did you make any progress on this at Anglo-Haskell? Will it be
cabal-ized soon?
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Planning for a website

[Colin Paul Adams]

> "Gour" == Gour   writes:

> "Colin" == Colin Paul Adams  writes:
Colin> So my major decision is what framework and html-generating
Colin> libraries to use. There is such a wide choice on the
Colin> Haskell Wiki. But I guess some are more maintained than
Colin> others. For instance, WASH attracts me, with it's guarantee
Colin> of valid generated pages, but it isn't clear to me that
Colin> it's actively maintained (last date I can see on the web
Colin> pages is 2006).

Gour> Have you thought about Turbinado (http://turbinado.org) ?


I didn't like it when I clicked on the link that says:

Learn about Turbinado here

and got a this page doesn't exist response.

Then I looked at the archticeture link, and didn't like the idea of
having to generate Haskell data types from relational tables (if i
understood it right).

I'd much rather be using happstack's macid stuff, especially as I will
have only very low usage, so i shouldn't have any scalability problems.
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Thanks, but that doesn't really matter in my example, my code is just buggy,
and I'm not sure why. For example if I change my test function so that it
outputs lines only, then it still prints Welcome first before asking for
input.
See e.g. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8328

On Wed, Aug 19, 2009 at 5:00 PM, David Leimbach  wrote:

> Try LineBuffering.
> I do linewise stuff with interact a lot.  You'll find stuff like
>
> unlines . lines
>
> may help too.  In fact I just wrote a blog post about this.
>
> http://leimy9.blogspot.com
>
> I'm trying to write some interactive code to automate working with serial
> console controlled power strips, so I need to either use Expect (yuck) or do
> my own thing.
>
> Dave
>
> On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen wrote:
>
>> Apparently this particular example happens to work on Mac and Linux
>> because of different buffering (thanks Martijn for the help!)
>> To make sure we have no buffering at all, the main function should be:
>>
>> main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin NoBuffering 
>>  test
>>
>> Now I think it should also be *incorrect* on Unix systems.
>>
>> I guess the way I'm concatenating the strings is not correct, not sure.
>>
>> I would like to use a graphical tool to show the graph reduction step by
>> step, to get a better understanding of the laziness & strictness. Does such
>> a tool exist? I know people often say this is not usable because the amount
>> of information is too much, but I used to be an assembly language programmer
>> so I still would like to give it a try :-)
>>
>>
>>
>> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen wrote:
>>
>>> In an attempt to get a deeper understanding of several monads (State, ST,
>>> IO, ...) I skimmed over some of the research papers (but didn't understand
>>> all of it, I lack the required education) and decided to write a little
>>> program myself without using any prefab monad instances that should mimic
>>> the following:
>>> main = do
>>>   putStrLn "Enter your name:"
>>>   x <- getLine
>>>   putStr "Welcome "
>>>   putStrLn x
>>>   putStrLn "Goodbye!"
>>>
>>> But instead of using IO, I wanted to make my own pure monad that gets
>>> evaluated with interact, and does the same.
>>>
>>> However, I get the following output:
>>>
>>> Enter your name:
>>> Welcome ..
>>>
>>> So the Welcome is printed too soon.
>>>
>>> This is obvious since my monad is lazy, so I tried to put a seq at some
>>> strategic places to get the same behavior as IO. But I completely failed
>>> doing so, either the program doesn't print anything and asks input first, or
>>> it still prints too much output.
>>>
>>> Of course I could just use ST, State, transformers, etc, but this is
>>> purely an exercise I'm doing.
>>>
>>> So, I could re-read all papers and look in detail at all the code, but
>>> maybe someone could help me out where to put the seq or what to do :-)
>>>
>>> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316
>>>
>>> Oh btw, the usage of DList here might not be needed; intuitively it felt
>>> like the correct thing to do, but when it comes to Haskell, my intuition is
>>> usually wrong ;-)
>>>
>>> Thanks a lot,
>>> Peter Verswyvelen
>>>
>>>
>>
>> ___
>> 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: Where do I put the seq?

[David Leimbach]

Try LineBuffering.
I do linewise stuff with interact a lot.  You'll find stuff like

unlines . lines

may help too.  In fact I just wrote a blog post about this.

http://leimy9.blogspot.com

I'm trying to write some interactive code to automate working with serial
console controlled power strips, so I need to either use Expect (yuck) or do
my own thing.

Dave

On Wed, Aug 19, 2009 at 7:35 AM, Peter Verswyvelen wrote:

> Apparently this particular example happens to work on Mac and Linux because
> of different buffering (thanks Martijn for the help!)
> To make sure we have no buffering at all, the main function should be:
>
> main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin NoBuffering  
> test
>
> Now I think it should also be *incorrect* on Unix systems.
>
> I guess the way I'm concatenating the strings is not correct, not sure.
>
> I would like to use a graphical tool to show the graph reduction step by
> step, to get a better understanding of the laziness & strictness. Does such
> a tool exist? I know people often say this is not usable because the amount
> of information is too much, but I used to be an assembly language programmer
> so I still would like to give it a try :-)
>
>
>
> On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen wrote:
>
>> In an attempt to get a deeper understanding of several monads (State, ST,
>> IO, ...) I skimmed over some of the research papers (but didn't understand
>> all of it, I lack the required education) and decided to write a little
>> program myself without using any prefab monad instances that should mimic
>> the following:
>> main = do
>>   putStrLn "Enter your name:"
>>   x <- getLine
>>   putStr "Welcome "
>>   putStrLn x
>>   putStrLn "Goodbye!"
>>
>> But instead of using IO, I wanted to make my own pure monad that gets
>> evaluated with interact, and does the same.
>>
>> However, I get the following output:
>>
>> Enter your name:
>> Welcome ..
>>
>> So the Welcome is printed too soon.
>>
>> This is obvious since my monad is lazy, so I tried to put a seq at some
>> strategic places to get the same behavior as IO. But I completely failed
>> doing so, either the program doesn't print anything and asks input first, or
>> it still prints too much output.
>>
>> Of course I could just use ST, State, transformers, etc, but this is
>> purely an exercise I'm doing.
>>
>> So, I could re-read all papers and look in detail at all the code, but
>> maybe someone could help me out where to put the seq or what to do :-)
>>
>> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316
>>
>> Oh btw, the usage of DList here might not be needed; intuitively it felt
>> like the correct thing to do, but when it comes to Haskell, my intuition is
>> usually wrong ;-)
>>
>> Thanks a lot,
>> Peter Verswyvelen
>>
>>
>
> ___
> 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] Observations about foldM

[Daniel Fischer]

Am Mittwoch 19 August 2009 16:32:57 schrieb Eugene Kirpichov:
> 2009/8/19 Dan Doel :
> > On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:
> >> Interestingly, foldM can also be written as a left fold. To see this,
> >> note that it is a theorem that foldr f z xs = foldl f z xs as long as f
> >> is associative and z is a unit for f.
>
> This is not true: f has to be commutative, not associative.
>
> Consider matrix multiplication.
>

It is true:
foldr: A1*(A2*(... *AN*E))
foldl: (...((E*A1)*A2)*...*AN)

Commutativity doesn't help, consider

data Foo = Z | A | B

(~) :: Foo -> Foo -> Foo
Z ~ x = x
x ~ Z = x
B ~ B = A
_ ~ _ = B

(~) is commutative, but not associative, Z is a unit for (~).

foldr (~) Z [A,A,B] = B
foldl (~) Z [A,A,B] = A

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

Re: [Haskell-cafe] Hugs used in circuit simulations code

[Fernan Bolando]

On Wed, Jul 29, 2009 at 10:54 AM, Daniel
Fischer wrote:
> Am Mittwoch 29 Juli 2009 03:32:20 schrieb Fernan Bolando:
>> What is everybodies expereience in speed difference between C and
>> interpreted haskell?
>
> That depends on what you do, unsurprisingly. But usually it's huge. A factor 
> of several
> hundred is not uncommon, but 10-100 is the normal range (in my limited 
> experience, I
> almost always compile).
>

Hi Daniel and other

thanks for the feedback the old simulation that took 13mins now only
takes 2mins. I included a bunch of tweaking options. Someone needs to
have a considerable knowledge in the circuit they are simulating and
circuit simulator to be able tweak these. I am not that guy though all
the tweak strategy are based on a bunch of papers I have been reading
lately and blindly implements them.

thanks again for the feedback. The new code is still not very haskelly
but its a lot more useful now.
http://plan9.bell-labs.com/sources/contrib/fernan/escomma/


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

[Haskell-cafe] Re: Where do I put the seq?

[Peter Verswyvelen]

Apparently this particular example happens to work on Mac and Linux because
of different buffering (thanks Martijn for the help!)
To make sure we have no buffering at all, the main function should be:

main = do  hSetBuffering stdout NoBuffering  hSetBuffering stdin
NoBuffering  test

Now I think it should also be *incorrect* on Unix systems.

I guess the way I'm concatenating the strings is not correct, not sure.

I would like to use a graphical tool to show the graph reduction step by
step, to get a better understanding of the laziness & strictness. Does such
a tool exist? I know people often say this is not usable because the amount
of information is too much, but I used to be an assembly language programmer
so I still would like to give it a try :-)



On Wed, Aug 19, 2009 at 1:07 PM, Peter Verswyvelen wrote:

> In an attempt to get a deeper understanding of several monads (State, ST,
> IO, ...) I skimmed over some of the research papers (but didn't understand
> all of it, I lack the required education) and decided to write a little
> program myself without using any prefab monad instances that should mimic
> the following:
> main = do
>   putStrLn "Enter your name:"
>   x <- getLine
>   putStr "Welcome "
>   putStrLn x
>   putStrLn "Goodbye!"
>
> But instead of using IO, I wanted to make my own pure monad that gets
> evaluated with interact, and does the same.
>
> However, I get the following output:
>
> Enter your name:
> Welcome ..
>
> So the Welcome is printed too soon.
>
> This is obvious since my monad is lazy, so I tried to put a seq at some
> strategic places to get the same behavior as IO. But I completely failed
> doing so, either the program doesn't print anything and asks input first, or
> it still prints too much output.
>
> Of course I could just use ST, State, transformers, etc, but this is purely
> an exercise I'm doing.
>
> So, I could re-read all papers and look in detail at all the code, but
> maybe someone could help me out where to put the seq or what to do :-)
>
> The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316
>
> Oh btw, the usage of DList here might not be needed; intuitively it felt
> like the correct thing to do, but when it comes to Haskell, my intuition is
> usually wrong ;-)
>
> Thanks a lot,
> Peter Verswyvelen
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Observations about foldM

[Eugene Kirpichov]

2009/8/19 Dan Doel :
> On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:
>> Interestingly, foldM can also be written as a left fold. To see this, note
>> that it is a theorem that foldr f z xs = foldl f z xs as long as f is
>> associative and z is a unit for f.
>

This is not true: f has to be commutative, not associative.

Consider matrix multiplication.

> It must also be the case that xs is finite in length, because if it is
> infinite, then 'foldl f z xs' is bottom, while 'foldr f z xs' needn't be. This
> difference holds over into foldM implemented with each, where you can write
> something like:
>
>  foldM (\f e -> if even e then Left (show e) else Right f) "no evens" [1..]
>
> and get an answer of 'Left "2"' with a foldr implementation, but bottom with a
> foldl implementation.
>
> This potentially translates into its own performance concerns, because in such
> monads, the computation can short-circuit upon finding a 'throw' when using
> the foldr implementation, but with the foldl implementation, you have to do at
> least a little shuffling of thunks for the entire list.
>
> -- Dan
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] Observations about foldM

[Dan Doel]

On Wednesday 19 August 2009 12:14:24 am Jason McCarty wrote:
> Interestingly, foldM can also be written as a left fold. To see this, note
> that it is a theorem that foldr f z xs = foldl f z xs as long as f is
> associative and z is a unit for f.

It must also be the case that xs is finite in length, because if it is 
infinite, then 'foldl f z xs' is bottom, while 'foldr f z xs' needn't be. This 
difference holds over into foldM implemented with each, where you can write 
something like:

  foldM (\f e -> if even e then Left (show e) else Right f) "no evens" [1..]

and get an answer of 'Left "2"' with a foldr implementation, but bottom with a 
foldl implementation.

This potentially translates into its own performance concerns, because in such 
monads, the computation can short-circuit upon finding a 'throw' when using 
the foldr implementation, but with the foldl implementation, you have to do at 
least a little shuffling of thunks for the entire list.

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

Re: [Haskell-cafe] Unifcation and matching in Abelian groups

[Jules Bean]

John D. Ramsdell wrote:

On Wed, Aug 19, 2009 at 6:16 AM, Neil Mitchell wrote:


Why not:
 if done then return () else
   do prob <- getLine
  test prob
  main


I've given up on using if-then-else in do expressions.  They confuse
emacs.  There is a proposal for Haskell' to fix the problem, but until
then, I will not use them in do expressions.


Do not blame haskell, blame emacs, if emacs is so stupid.

Fortunately there is a better emacs mode which understands layout and if:

http://kuribas.hcoop.net/haskell-indentation.el


I'm so glad new languages do not use the offset rule.  I get tired
typing tab in emacs, especially since for most other languages, emacs
does so well at picking a good indent.  Requiring coders to spend so
much time choosing indents reminds me of the days when I wrote C code
with vi.  I've been there, done that, and moved on to emacs.


Do not blame haskell, blame emacs. The layout rule is simple to 
understand and I think it makes attractive code. It's not haskell's 
fault that the emacs mode chooses a bad indent so often.


There is a better emacs mode which gets the indentation right more 
often, I find ;)


http://kuribas.hcoop.net/haskell-indentation.el

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

[Haskell-cafe] Re: Planning for a website

[Gour]

> "Colin" == Colin Paul Adams  writes:

Colin> So my major decision is what framework and html-generating
Colin> libraries to use. There is such a wide choice on the Haskell
Colin> Wiki. But I guess some are more maintained than others. For
Colin> instance, WASH attracts me, with it's guarantee of valid
Colin> generated pages, but it isn't clear to me that it's actively
Colin> maintained (last date I can see on the web pages is 2006).

Have you thought about Turbinado (http://turbinado.org) ?


Sincerely,
Gour

-- 

Gour | Hlapičina, Croatia  | GPG key: F96FF5F6 
---


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

[Haskell-cafe] Where do I put the seq?

[Peter Verswyvelen]

In an attempt to get a deeper understanding of several monads (State, ST,
IO, ...) I skimmed over some of the research papers (but didn't understand
all of it, I lack the required education) and decided to write a little
program myself without using any prefab monad instances that should mimic
the following:
main = do
  putStrLn "Enter your name:"
  x <- getLine
  putStr "Welcome "
  putStrLn x
  putStrLn "Goodbye!"

But instead of using IO, I wanted to make my own pure monad that gets
evaluated with interact, and does the same.

However, I get the following output:

Enter your name:
Welcome ..

So the Welcome is printed too soon.

This is obvious since my monad is lazy, so I tried to put a seq at some
strategic places to get the same behavior as IO. But I completely failed
doing so, either the program doesn't print anything and asks input first, or
it still prints too much output.

Of course I could just use ST, State, transformers, etc, but this is purely
an exercise I'm doing.

So, I could re-read all papers and look in detail at all the code, but maybe
someone could help me out where to put the seq or what to do :-)

The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316

Oh btw, the usage of DList here might not be needed; intuitively it felt
like the correct thing to do, but when it comes to Haskell, my intuition is
usually wrong ;-)

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

Re: [Haskell-cafe] Unifcation and matching in Abelian groups

[John D. Ramsdell]

On Wed, Aug 19, 2009 at 6:51 AM, Neil Mitchell wrote:

> F# is new and has the offset rule. Haskell is old and has the optional
> offset rule:

I thought F# uses OCaml syntax.  Emacs does well with OCaml syntax.

Guy Steele told this story at a conference.  As part of the Fortress
design effort, he and other at Sun visited several sites that make use
of high performance computing.  They received a variety of suggestions
on how to design a high productivity language for high performance
computing, and uniformly were asked not to give programmers a language
that uses the offset rule.

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

Re: [Haskell-cafe] Unifcation and matching in Abelian groups

[Neil Mitchell]

Hi

> I've given up on using if-then-else in do expressions.  They confuse
> emacs.  There is a proposal for Haskell' to fix the problem, but until
> then, I will not use them in do expressions.

It's a shame, there are ways of indenting them that work, but they're
not as natural. It's a wart, but it will be fixed.

> I'm so glad new languages do not use the offset rule.

F# is new and has the offset rule. Haskell is old and has the optional
offset rule:

do { prob <- getLine
 ; test prob
 ; main}

Now your indentation is your own :-)

Some people prefer this style. Simon Peyton Jones uses it in the book
beautiful code. I much prefer indentation only.

Thanks

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

Re: [Haskell-cafe] Unifcation and matching in Abelian groups

[John D. Ramsdell]

On Wed, Aug 19, 2009 at 6:16 AM, Neil Mitchell wrote:

> Why not:
>  if done then return () else
>    do prob <- getLine
>       test prob
>       main

I've given up on using if-then-else in do expressions.  They confuse
emacs.  There is a proposal for Haskell' to fix the problem, but until
then, I will not use them in do expressions.

I'm so glad new languages do not use the offset rule.  I get tired
typing tab in emacs, especially since for most other languages, emacs
does so well at picking a good indent.  Requiring coders to spend so
much time choosing indents reminds me of the days when I wrote C code
with vi.  I've been there, done that, and moved on to emacs.

>  unless done $
>    do prob <- getLine
>       test prob
>       main

I do like this suggestion.  Thanks.

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

Re[2]: [Haskell-cafe] Unifcation and matching in Abelian groups

[Bulat Ziganshin]

Hello Neil,

Wednesday, August 19, 2009, 2:16:06 PM, you wrote:

>> main =
>> do
>>   done <- isEOF
>>   unless done $ do
>>   prob <- getLine
>>   test prob
>>   main

main = untilM isEOF (getLine >>= test)


-- 
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] Unifcation and matching in Abelian groups

[Neil Mitchell]

Hi,

I ran your code thought HLint
(http://community.haskell.org/~ndm/hlint), and it suggested a couple
of things (mainly eta reduce). The most interesting suggestions are on
your main function:

> main :: IO ()
> main =
> do
>   done <- isEOF
>   case done of
> True -> return ()
> False ->
> do
>   prob <- getLine
>   test prob
>   main

It suggests:

Example.lhs:432:3: Warning: Use if
Found:
  case done of
  True -> return ()
  False -> do prob <- getLine
  test prob
  main
Why not:
  if done then return () else
do prob <- getLine
   test prob
   main

Changing that and rerunning says:

Example.lhs:432:3: Error: Use unless
Found:
  if done then return () else
do prob <- getLine
   test prob
   main
Why not:
  unless done $
do prob <- getLine
   test prob
   main

So I (or rather HLint) recommends you do:

> main :: IO ()
> main =
> do
>   done <- isEOF
>   unless done $ do
>   prob <- getLine
>   test prob
>   main

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

[Haskell-cafe] Re: Some trouble with AttoParsec.

[Jason Dusek]

2009/08/19 Jason Dusek :
>  Aha. From `Data.ByteString.Lazy` we have:
>
>    null :: ByteString -> Bool
>    null Empty = True
>    null _     = False
>
>  So either users need to norm ByteStrings before testing
>  them for emptiness or it needs to happen within the ByteString
>  code...

  Well, no, actually -- the lazy `ByteString` constructors are
  all supposed to conform to the invariant that there are no
  empty chunks. So something is funny with AttoParsec:

Prelude Data.ParserCombinators.Attoparsec.Char8
Data.ByteString.Lazy.Char8> parse (takeTill (== '"')) (pack "\"\"")
(Chunk "\"" Empty,Right (Chunk "" Empty))
it :: (ByteString, Either ParseError ByteString)

  Sorry to hash this out on the list; I'm used to think of my
  troubles with Haskell libs as misunderstandings on my part.
  I'll have to look into what AttoParsec is doing and file a bug
  report.

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

[Haskell-cafe] Unifcation and matching in Abelian groups

[John D. Ramsdell]

I've been studying equational unification.  I decided to test my
understanding of it by implementing unification and matching in
Abelian groups.  I am quite surprised by how little code it takes.
Let me share it with you.

John

Test cases:

2x+y=3z
2x=x+y
64x-41y=a

Code:

> -- Unification and matching in Abelian groups
> -- John D. Ramsdell -- August 2009
>
> module Main (main, test) where
>
> import Data.Char (isSpace, isAlpha, isAlphaNum, isDigit)
> import Data.List (sort)
> import System.IO (isEOF)
>
> -- Chapter 8, Section 5 of the Handbook of Automated Reasoning by
> -- Franz Baader and Wayne Snyder describes unification and matching in
> -- communtative/monoidal theories.  This module refines the described
> -- algorithms for the special case of Abelian groups.
>
> -- In this module, an Abelian group is a free algebra over a signature
> -- with three function symbols,
> --
> -- * the binary symbol +, the group operator,
> -- * a constant 0, the identity element, and
> -- * the unary symbol -, the inverse operator.
> --
> -- The algebra is generated by a set of variables.  Syntactically, a
> -- variable is an identifer such as x and y.
>
> -- The axioms associated with the algebra are:
> --
> -- * x + y = y + x Commutativity
> -- * (x + y) + z = x + (y + z) Associativity
> -- * x + 0 = x Group identity
> -- * x + -x = 0Cancellation
>
> -- A substitution maps variables to terms.  A substitution s is
> -- extended to a term as follows.
> --
> -- s(0) = 0
> -- s(-t) = -s(t)
> -- s(t + t') = s(t) + s(t')
>
> -- The unification problem is given the problem statement t =? t',
> -- find a substitution s such that s(t) = s(t') modulo the axioms of
> -- the algebra.  The matching problem is to find substitution s such
> -- that s(t) = t' modulo the axioms.
>
> -- A term is represented as the sum of factors, and a factor is the
> -- product of an integer coeficient and a variable or the group
> -- identity, zero.  In this representation, every coeficient is
> -- non-zero, and no variable occurs twice.
>
> -- A term can be represented by a finite map from variables to
> -- non-negative integers.  To make the code easier to understand,
> -- association lists are used instead of Data.Map.
>
> newtype Lin = Lin [(String, Int)]
>
> -- Constructors
>
> -- Identity element (zero)
> ide :: Lin
> ide = Lin []
>
> -- Factors
> var :: Int -> String -> Lin
> var 0 _ = Lin []
> var c x = Lin [(x, c)]
>
> -- Invert by negating coefficients.
> neg :: Lin -> Lin
> neg (Lin t) =
> Lin $ map (\(x, c) -> (x, negate c)) t
>
> -- Join terms ensuring that coefficients are non-zero, and no variable
> -- occurs twice.
> add :: Lin -> Lin -> Lin
> add (Lin t) (Lin t') =
> Lin $ foldr f t' t
> where
>   f (x, c) t =
>   case lookup x t of
> Just c' | c + c' == 0 -> remove x t
> | otherwise -> (x, c + c') : remove x t
> Nothing -> (x, c) : t
>
> -- Remove the first pair in an association list that matches the key.
> remove :: Eq a => a -> [(a, b)] -> [(a, b)]
> remove _ [] = []
> remove x (y@(z, _) : ys)
>| x == z = ys
>| otherwise = y : remove x ys
>
> canonicalize :: Lin -> Lin
> canonicalize (Lin t) =
> Lin (sort t)
>
> -- Convert a linearized term into an association list.
> assocs :: Lin -> [(String, Int)]
> assocs (Lin t) = t
>
> term :: [(String, Int)] -> Lin
> term assoc =
> foldr f ide assoc
> where
>   f (x, c) t = add t $ var c x
>
> -- Unification and Matching
>
> newtype Equation = Equation (Lin, Lin)
>
> newtype Maplet = Maplet (String, Lin)
>
> -- Unification is the same as matching when there are no constants
> unify :: Monad m => Equation -> m [Maplet]
> unify (Equation (t0, t1)) =
> match $ Equation (add t0 (neg t1), ide)
>
> -- Matching in Abelian groups is performed by finding integer
> -- solutions to linear equations, and then using the solutions to
> -- construct a most general unifier.
> match :: Monad m => Equation -> m [Maplet]
> match (Equation (t0, t1)) =
> case (assocs t0, assocs t1) of
>   ([], []) -> return []
>   ([], _) -> fail "no solution"
>   (t0, t1) ->
>   do
> subst <- intLinEq (map snd t0) (map snd t1)
> return $ mgu (map fst t0) (map fst t1) subst
>
> -- Construct a most general unifier from a solution to a linear
> -- equation.  The function adds the variables back into terms, and
> -- generates fresh variables as needed.
> mgu :: [String] -> [String] -> Subst -> [Maplet]
> mgu vars syms subst =
> foldr f [] (zip vars [0..])
> where
>   f (x, n) maplets =
>   case lookup n subst of
> Just (factors, consts) ->
> Maplet (x, g factors consts) : maplets
> Nothing ->
> Maplet (x, var 1 $ genSym n) : maplets
>   g factors consts =
>   term (zip genSyms factors ++ zip syms consts)
>   genSym

[Haskell-cafe] Re: Some trouble with AttoParsec.

[Jason Dusek]

  Aha. From `Data.ByteString.Lazy` we have:

null :: ByteString -> Bool
null Empty = True
null _ = False

  So either users need to norm ByteStrings before testing
  them for emptiness or it needs to happen within the ByteString
  code...

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

[Haskell-cafe] Some trouble with AttoParsec.

[Jason Dusek]

  The linked to text demoes a seemingly impossible error when
  processing a lazy byte string with AttoParsec: I check to see
  if the ByteString is null, take the last character and get an
  exception.

--
Jason Dusek


http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8309#a8309
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Type family signatures

[Simon Peyton-Jones]

David is right that the program should be rejected.  To be concrete, as he 
suggests, suppose
  type instance Fam Int = Bool
  type instance Fam Char = Bool

Now suppose that 'unwrap' did typecheck. Then we could write: 
  x :: Fam Int
  x = GADT 3 True

  y :: (Char, Bool)
  y = unwrap x

Voila!  We started with an Int (3), and managed to return it as the first 
component of a pair of type (Char,Bool).   


Ryan's explanation of the type checking process is accurate, but I agree that 
the error message is horrible.  Dimitrios and I are working on a better version 
of the type checker that will say something more helpful, like
Cannot deduce (a ~ a1) from (Fam a ~ Fam a1)
which is a lot more useful.

Nice example, thank you.

Simon

| -Original Message-
| From: haskell-cafe-boun...@haskell.org 
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Ryan Ingram
| Sent: 18 August 2009 21:56
| To: Thomas van Noort
| Cc: Haskell Cafe
| Subject: Re: [Haskell-cafe] Type family signatures
| 
| On Mon, Aug 17, 2009 at 12:12 AM, Thomas van Noort wrote:
| > Somehow I didn't receive David's mail, but his explanation makes a lot of
| > sense. I'm still wondering how this results in a type error involving rigid
| > type variables.
| 
| "rigid" type means the type has been specified by the programmer somehow.
| 
| Desugaring your code a bit, we get:
| 
| GADT :: forall a b. (b ~ Fam a) => a -> b -> GADT b
| 
| Notice that this is an existential type that partially hides "a"; all
| we know about "a" after unwrapping this type is that (Fam a ~ b).
| 
| unwrap :: forall a b. (b ~ Fam a) => GADT b -> (a,b)
| unwrap (GADT x y) = (x,y)
| 
| So, the type signature of unwrap fixes "a" and "b" to be supplied by
| the caller.  Then the pattern match on GADT needs a type variable for
| the existential, so a new "a1" is invented.  These are rigid because
| they cannot be further refined by the typechecker; the typechecker
| cannot unify them with other types, like "a1 ~ Int", or "a1 ~ a".
| 
| An example of a non-rigid variable occurs type-checking this expression:
| 
| foo x = x + (1 :: Int)
| 
| During type-checking/inference, there is a point where the type environment 
is:
| 
| (+) :: forall a. Num a => a -> a -> a
| 
| b :: *, non-rigid
| x :: b
| 
| c :: *, non-rigid
| foo :: b -> c
| 
| Then (+) gets instantiated at Int and forces "b" and "c" to be Int.
| 
| In your case, during the typechecking of unwrap, we have:
| 
| unwrap :: forall a b. (b ~ Fam a) => GADT b -> (a,b)
| a :: *, rigid
| b :: *, rigid
| (b ~ Fam a)
| 
| -- From the pattern match on GADT:
| a1 :: *, rigid
| x :: a1
| y :: b
| (b ~ Fam a1)
| 
| Now the typechecker wants to unify "a" and "a1", and it cannot,
| because they are rigid.  If one of them was still open, we could unify
| it with the other.
| 
| The type equalities give us (Fam a ~ Fam a1), but that does not give
| us (a ~ a1).  If Fam was a data type or data family, we would know it
| is injective and be able to derive (a ~ a1), but it is a type family,
| so we are stuck.
| 
|   -- ryan
| ___
| 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] Type family signatures

[Thomas van Noort]

Thank your for this elaborate explanation, you made my day!

Thomas

Ryan Ingram wrote:

On Mon, Aug 17, 2009 at 12:12 AM, Thomas van Noort wrote:

Somehow I didn't receive David's mail, but his explanation makes a lot of
sense. I'm still wondering how this results in a type error involving rigid
type variables.


"rigid" type means the type has been specified by the programmer somehow.

Desugaring your code a bit, we get:

GADT :: forall a b. (b ~ Fam a) => a -> b -> GADT b

Notice that this is an existential type that partially hides "a"; all
we know about "a" after unwrapping this type is that (Fam a ~ b).

unwrap :: forall a b. (b ~ Fam a) => GADT b -> (a,b)
unwrap (GADT x y) = (x,y)

So, the type signature of unwrap fixes "a" and "b" to be supplied by
the caller.  Then the pattern match on GADT needs a type variable for
the existential, so a new "a1" is invented.  These are rigid because
they cannot be further refined by the typechecker; the typechecker
cannot unify them with other types, like "a1 ~ Int", or "a1 ~ a".

An example of a non-rigid variable occurs type-checking this expression:

foo x = x + (1 :: Int)

During type-checking/inference, there is a point where the type environment is:

(+) :: forall a. Num a => a -> a -> a

b :: *, non-rigid
x :: b

c :: *, non-rigid
foo :: b -> c

Then (+) gets instantiated at Int and forces "b" and "c" to be Int.

In your case, during the typechecking of unwrap, we have:

unwrap :: forall a b. (b ~ Fam a) => GADT b -> (a,b)
a :: *, rigid
b :: *, rigid
(b ~ Fam a)

-- From the pattern match on GADT:
a1 :: *, rigid
x :: a1
y :: b
(b ~ Fam a1)

Now the typechecker wants to unify "a" and "a1", and it cannot,
because they are rigid.  If one of them was still open, we could unify
it with the other.

The type equalities give us (Fam a ~ Fam a1), but that does not give
us (a ~ a1).  If Fam was a data type or data family, we would know it
is injective and be able to derive (a ~ a1), but it is a type family,
so we are stuck.

  -- ryan


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

Re: [Haskell-cafe] Text.Html introduction

[Malcolm Wallace]

"Based on the original Text.Html library by Andy Gill. See
http://www.cse.ogi.edu/~andy/html/intro.htm for an introduction to
that library. "


Try the Internet Archive:

http://web.archive.org/web/*/http://www.cse.ogi.edu/~andy/html/intro.htm

Regards,
Malcolm

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

Re: [Haskell-cafe] Re: simulation in the haskell way

[Peter Verswyvelen]

I don't really agree that in Haskell when it comes to simulation a program
"just is". That is the idealized story.
At least when writing your own simulation engine, in practice you have to
deal with operational details such as future unknown values that can block
computations; to much laziness can cause hickups in the framerate since
unobserved computations build up over time (a bit like sum does) which is
why most Yampa simulations I've seen mark all the outputs deep strict (so
even the end user needs to know about the operational details); binding to
the head of signals and signal recursion causes space and time leaks, and
that's why Yampa doesn't provide first signals, which in turn gives problems
with inefficiency regarding too much redundant evaluation, etc...

*Wolfgang *Jeltsch is working on a PhD thesis for Grapefruit in which I hope
all problems with FRP will be nicely documented, since currently there
doesn't seem to be clear literature that tells the whole story with
pros/cons of each framework.

I even believe Luke Palmer abandoned Haskell for doing FRP and started
inventing his own language "Dana"; see http://lukepalmer.wordpress.com

And of course Conal Elliot's blog outlines some of the problems and beauties
of his latest FRP system (Reactive)

So it's not all sunshine and roses, but that's also what makes it
interesting :)

2009/8/19 Maurí­cio CA 

> When I was using C and Python, I used to think of most applications in an
>> simulation way.  I think it's right to say that programs are simulations.
>> But now I have to change my mind in Haskell, I have to think in a
>> data-flow
>> way, that is: data in, processing using function composition, data out.
>>
>
> You have to think there's no in and out, since there's
> no state and so no before and after. And no flow, since
> time is just an ilusion of users. In Haskell, a program
> just "is".
>
> Sorry, could not resist the Jedi talk...
>
> Hope you like the language. Best,
> Maurício
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Keeping an indexed collection of values?

[Sebastian Fischer]

On Aug 18, 2009, at 9:19 PM, Job Vranish wrote:


data IndexedCollection a = IndexedCollection {
nextKey:: Int,
availableKeys :: [Int],
items:: (IntMap Int a)
} deriving (Show)

emptyIndexedCollection :: IndexedCollection a
emptyIndexedCollection = IndexedCollection 0 [] empty
[...]
Does anyone know of a better/already existent data structure for  
handling this problem?
Or perhaps a better way of keeping a "key pool" than my  
availableKeys solution?


just a slight simplification: you could drop the nextKey field and  
initialise availableKeys with [0..] in emptyIndexCollection. The add  
function would consume the head of this list, the remove function add  
the deleted key as new head.


--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



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

Re: [Haskell-cafe] Re: Planning for a website

[Michael Snoyman]

On Tue, Aug 18, 2009 at 10:22 PM, Max Desyatov
wrote:

> Simon Michael  writes:
>
> > I can give a +1 vote for the Hack api and related libs. (Jinjing Wang
> > is a one-man army.) Below hack you'll run happstack or another
> > web-serving lib. Above hack you might run some combination of loli,
> > maid, the hack middleware modules, hsp.
> >
> > The advantage is that changing the low-level server in future is a
> > matter of changing one or two lines; and the upper-level utilities
> > seem more usable to me than current happstack's.
>
> The problem is that `hack` isn't documented at all and that prevents it
> from being in wide use.  At least, when I started my web app, I
> preferred happstack, as low-level and documented API is better than
> high-level API without a little bit of documentation, examples and
> tutorials.
>

I don't see how you can call hack a "high-level API." It's about as
low-level as it gets, kind of equivalent to the CGI protocol. I wrote up a
little blog article with a hack introduction (
http://blog.snoyman.com/2009/06/28/hack-introduction/). I would also
recommend checking out my hack-samples repo on github (
http://github.com/snoyberg/hack-samples/tree/master).

Overall, hack is still developing, so the documentation is a little lacking.
However, I at least am using it in production on a few sites (
http://eliezer.snoyman.com, http://wordify.snoyman.com).

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