Re: [Haskell-cafe] What is the role of $!?

[David Fox]

Argh, that last sentence should read "the file is left alone"..

On Dec 9, 2007 10:15 PM, David Fox <[EMAIL PROTECTED]> wrote:

> Here is a practical example I ran into a few days ago.  With this
> expression:
>
>writeFile path (compute text)
>
> the file at path would be overwritten with an empty file if an error
> occurs while evaluating (compute text).  With this one:
>
>   writeFile path $! (compute text)
>
> the file alone when an error occurs.
>
>
> On Nov 17, 2007 8:04 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
>
> > Hi
> > okay, so $! is a bit like $ i.e. the equivalent of putting
> > parentheses around the righthand expression. I'm still not sure of
> > the difference between $ and $!. Maybe it's because I don't
> > understand the meaning of "strict application". While we're on the
> > subject, what's meant by Haskell being a non-strict language?
> > Cheers
> > Paul
> > At 01:50 15/11/2007, you wrote:
> > >On 14 Nov 2007, at 4:32 PM, Shachaf Ben-Kiki wrote:
> > >
> > >>On Nov 14, 2007 4:27 PM, Justin Bailey < [EMAIL PROTECTED]> wrote:
> > >>>It's:
> > >>>
> > >>>   f $! x = x `seq` f x
> > >>>
> > >>>That is, the argument to the right of $! is forced to evaluate, and
> > >>>then that value is passed to the function on the left. The function
> > >>>itself is not strictly evaluated (i.e., f x) I don't believe.
> > >>
> > >>Unless you mean f -- which I still don't think would do much -- it
> > >>wouldn't make sense to evaluate (f x) strictly.
> > >
> > >Right.  (f x) evaluates f and then applies it to x.  (f $! x)
> > >evaluates x, evaluates f, and then applies f to x.
> > >
> > >jcc
> > >
> > >___
> > >Haskell-Cafe mailing list
> > >Haskell-Cafe@haskell.org
> > >http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What is the role of $!?

[David Fox]

Here is a practical example I ran into a few days ago.  With this
expression:

   writeFile path (compute text)

the file at path would be overwritten with an empty file if an error occurs
while evaluating (compute text).  With this one:

  writeFile path $! (compute text)

the file alone when an error occurs.

On Nov 17, 2007 8:04 PM, PR Stanley <[EMAIL PROTECTED]> wrote:

> Hi
> okay, so $! is a bit like $ i.e. the equivalent of putting
> parentheses around the righthand expression. I'm still not sure of
> the difference between $ and $!. Maybe it's because I don't
> understand the meaning of "strict application". While we're on the
> subject, what's meant by Haskell being a non-strict language?
> Cheers
> Paul
> At 01:50 15/11/2007, you wrote:
> >On 14 Nov 2007, at 4:32 PM, Shachaf Ben-Kiki wrote:
> >
> >>On Nov 14, 2007 4:27 PM, Justin Bailey <[EMAIL PROTECTED]> wrote:
> >>>It's:
> >>>
> >>>   f $! x = x `seq` f x
> >>>
> >>>That is, the argument to the right of $! is forced to evaluate, and
> >>>then that value is passed to the function on the left. The function
> >>>itself is not strictly evaluated (i.e., f x) I don't believe.
> >>
> >>Unless you mean f -- which I still don't think would do much -- it
> >>wouldn't make sense to evaluate (f x) strictly.
> >
> >Right.  (f x) evaluates f and then applies it to x.  (f $! x)
> >evaluates x, evaluates f, and then applies f to x.
> >
> >jcc
> >
> >___
> >Haskell-Cafe mailing list
> >Haskell-Cafe@haskell.org
> >http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Do real programs need IO? (was IO is a bad example for Monads)

[Maurí­cio]

>  >(...)
>  > Would you deny that any useful programme has to do at least some of
> the following:
>  > -accept programme arguments at invocation
>  > -get input, be it from a keyboard, mouse, reading files, pipes...
>  > -output a result or state info, to the monitor, a file, a pipe...
>===
>

As long as we use current interfaces, no one
would deny it. But after reading some stuff
about Epigram language, I wonder if those
ideas could not be used to write a better
interface to computers. Then, all those tasks
would be handled by your interface plug-ins,
not by programs.

Really, we need to do all of that today. But
I believe reading from keyboard, files
etc. should not be part of programs we write
daily, just a task for a basic interface to
which our programs should be linked.

Best,
Maurício

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

[Haskell-cafe] Need help please.

[Ryan Bloor]

hi I am writing a basic Parser from scratch. So far I have functions;# 
removeSpaces# match - which checks if a string is a substring of another# 
orParser which combines two parser's abilities# Basic pasrers like... parseInt, 
parseTrue, parseFalse, parseBoolusing the orParser on True and False.What I 
want to do now is have a parseBinaryOp that recognises:parseBinaryOp "+" "(5 + 
2) if"  >>>gives>> [(EInt 5, EInt 2, "if")]So I 
think that I have to split the initial string into four parts."+" becomes op'(' 
becomes tokenF')' becomes tokenB"5" becomes e1"2" becomes e2parseBinaryOp :: 
String -> String -> [(Expr, Expr, String)]parseBinaryOp op str = let 
(tokenF,e1,op,e2,tokenB) =I am not sure how to go about separating the string 
for how I need itusing my other functiuons. Ryan
_
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] IVars

[Conal Elliott]

Thanks.  I don't know for what uses of IVars the difference in
expressiveness is helpful, but now I get that the difference is there.
Cheers,  - Conal

On Dec 9, 2007 2:08 PM, Benja Fallenstein <[EMAIL PROTECTED]>
wrote:

> Hi Conal,
>
> On Dec 9, 2007 6:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> > > readIVar' :: IVar a -> a
> > > readIVar' = unsafePerformIO . readIVar
> >
> > > so, we do not need readIVar'. it could be a nice addition to the
> > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> >
> > The same argument applies any to pure function, doesn't it?  For
> instance, a
> > non-IO version of succ is unnecessary.  My question is why make readIVar
> a
> > blocking IO action rather than a blocking pure value, considering that
> it
> > always returns the same value?
>
> From the rest of Marc's post, I understood the point to be that
> readIVar lets you do something that readIVar' does not let you do:
> block until the IVar is written, then continue *without* first
> evaluating the thunk in the IVar to WHNF. I haven't used IVars myself,
> so this isn't informed by hands-on experience, but it does sound
> sensible to me that "block until the IVar has been written" and
> "evaluate the thunk to WHNF" should be separable.
>
> All the best,
> - Benja
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] IVars

[Conal Elliott]

Makes sense to me.  Giving a formal semantics to the IO version of readIVar
most likely is simpler (taking IO and concurrent IO as given) than the
non-IO version.  I didn't understand that before.  Thanks for helping me get
it.  - Conal

On Dec 9, 2007 12:09 PM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:

> I would claim that it's fine to use the type
>   readIVar :: IVar a -> a
> if you're willing to give the "right" semantics to
>   newIVar :: IO (IVar a)
> The semantics is that sometimes when you create an IVar you'll get one
> that always returns _|_ when read, sometimes you'll get a proper one.  Now
> if you happen to read an IVar and it deadlocks your program, well, sorry,
> you were unlucky and got a bad IVar that time.
>
> So it's possible to explain away the deadlock as something
> non-deterministic in the IO monad.  Doing so comes at a terrible price
> though, because you can no longer reason about your program.
>
>   -- Lennart
>
>
> On Dec 9, 2007 7:48 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
>
> > Thanks, Luke.  I'd been unconsciously assuming that the IVar would get
> > written to (if ever) by a thread other than the one doing the reading.
> > (Even then, there could be a deadlock.)
> >
> >   - Conal
> >
> >
> > On Dec 9, 2007 9:37 AM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 9, 2007 5:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> > > > (moving to haskell-cafe)
> > > >
> > > > > readIVar' :: IVar a -> a
> > > > > readIVar' = unsafePerformIO . readIVar
> > > >
> > > > > so, we do not need readIVar'. it could be a nice addition to the
> > > > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > > >
> > > > The same argument applies any to pure function, doesn't it?  For
> > > instance, a
> > > > non-IO version of succ is unnecessary.  My question is why make
> > > readIVar a
> > > > blocking IO action rather than a blocking pure value, considering
> > > that it
> > > > always returns the same value?
> > >
> > > But I don't think it does.  If we're single-threaded, before we
> > > writeIVar on it,
> > > it "returns" bottom, but afterward it returns whatever what was
> > > written.  It's
> > > a little fuzzy, but that doesn't seem referentially transparent.
> > >
> > > Luke
> > >
> > > >   - Conal
> > > >
> > > > On Dec 8, 2007 11:12 AM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote:
> > > > > many many answers, many guesses...
> > > > > let's compare these semantics:
> > > > >
> > > > >
> > > > > readIVar :: IVar a -> IO a
> > > > > readIVar' :: IVar a -> a
> > > > > readIVar' = unsafePerformIO . readIVar
> > > > >
> > > > > so, we do not need readIVar'. it could be a nice addition to the
> > > > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > > > > but the other way:
> > > > >
> > > > > readIVar v = return $ readIVar' v
> > > > >
> > > > > does not work. with this definition, readIVar itself does not
> > > block
> > > > anymore. it's like hGetContents.
> > > > > and...
> > > > >
> > > > > readIVar v = return $! readIVar' v
> > > > >
> > > > > evaluates too much:
> > > > >  it wont work if the stored value evaluates to 1) undefined or 2)
> > > _|_.
> > > > >  it may even cause a 3) deadlock:
> > > > >
> > > > > do
> > > > >  writeIVar v (readIVar' w)
> > > > >  x<-readIVar v
> > > > >  writeIVar w "cat"
> > > > >  return x :: IO String
> > > > >
> > > > > readIVar should only return the 'reference'(internal pointer) to
> > > the read
> > > > object without evaluating it. in other words:
> > > > > readIVar should wait to receive but not look into the received
> > > "box"; it
> > > > may contain a nasty undead werecat of some type. (Schrödinger's
> > > Law.)
> > > > >
> > > > > - marc
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> > > > >
> > > > >
> > > > >
> > > > > > Conal Elliott wrote:
> > > > > > > Oh.  Simple enough.  Thanks.
> > > > > > >
> > > > > > > Another question:  why the IO in readIVar :: IVar a -> IO a,
> > > instead
> > > > > > > of just readIVar :: IVar a -> a?  After all, won't readIVar iv
> > > yield
> > > > > > > the same result (eventually) every time it's called?
> > > > > > Because it won't necessarily yield the same result the next time
> > > you run
> > > > > > it.  This is the same reason the stuff in System.Environmentreturns
> > > > > > values in IO.
> > > > > >
> > > > > > Paul.
> > > > >
> > > > >
> > > > >
> > > > > > ___
> > > > > > Haskell mailing list
> > > > > > [EMAIL PROTECTED]
> > > > >
> > > > > > http://www.haskell.org/mailman/listinfo/haskell
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > ___
> > > > Haskell-Cafe mailing list
> > > > Haskell-Cafe@haskell.org
> > > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > > >
> > > >
> > >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-C

Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe

[Vimal]

> And looks like this post has gone on a tangent :D
>
> Vimal
>

And looks like this _thread_ has gone on a tangent :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe

[Vimal]

Hi,

Yes, I looked into it as per the Mailman documentation.
I was wondering if there was a module already that could do it, to
avoid some work :)

What is the difference between In-Reply-To and References?

And the list of posts was just the beginning. Each post would have
sufficient information to reconstruct the tree...

And looks like this post has gone on a tangent :D

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

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Conal Elliott]

It so happens that Haskell currently insists on main :: IO ().  That's
simple to fix, however, and with great pay-off.  Suppose instead main :: TV
a (where I'm omitting the other TV type args for simplicity.)  Then a
program could not only be run, but also composed with other programs.  They
could even be composed by the end-user *while running*, as in Eros.

Similarly, ghci implicitly inserts "print" when given a non-IO type.  We
could make that mechanism a little more general, and allow implicit
insertions of other kinds of renderers, for purely functional images, music,
2D & 3D geometry & animation, interactive GUIs, etc.

  - Conal

On Dec 9, 2007 4:38 PM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:

> I doubt all imperative programming will be banished from Haskell anytime
> soon.  I really, really wish we had all the nice abstractions in place
> already, but we just don't.
>
> You can't write any program in Haskell without using IO, because the type
> of main involves IO.
> And currently I believe that almost any real program will have to involve
> IO.
> (BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell
> because I insisted on it.)
> It's just from my experience.  No matter how pure your program is, here
> and there it will be interacting with the rest of the world.
>
>   -- Lennart
>
>
> On Dec 9, 2007 10:16 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
>
> > Thanks.  If I'm tracking, your real point is that imperative programming
> > in Haskell is still useful enough to keep around.  I agree.
> >
> > I'm still puzzled.  Did you understand something I said, or maybe
> > someone else said, as suggesting that imperative programming be removed from
> > Haskell any time soon?
> >
> > > It's also important to teach people to stay away from IO whenever
> > possible, but it's simply not always possible.
> >
> > How can we possibly teach them to stay away from IO where possible if
> > we're also telling them that they can't write *any* real program without
> > using IO?
> >
> > Cheers, - Conal
> >
> >
> > On Dec 9, 2007 12:02 PM, Lennart Augustsson <[EMAIL PROTECTED] >
> > wrote:
> >
> > > Conal,
> > >
> > > It's true that you can avoid using IO (except for a wrapper) for
> > > certain kinds of programs.
> > > For instance, if all you want is a String->String function, or some
> > > GUI program (you forgot to mention fudgets, which was the first wrapper of
> > > this kind) then you can ignore IO and just use a nice wrapper.
> > >
> > > But if someone asks me how to traverse a directory tree, invoking the
> > > 'file' program for each ',o' file and then renaming it if it's a text 
> > > file,
> > > then what should I answer?  "Sorry, you can't do that in Haskell."  or 
> > > "You
> > > need to use the IO monad."?
> > > I prefer the latter answer, and I think people who learn Haskell need
> > > to learn something about how you do some of the things that are easy in
> > > other languages.
> > >
> > > It's also important to teach people to stay away from IO whenever
> > > possible, but it's simply not always possible.
> > >
> > >   -- Lennart
> > >
> > >
> > > On Dec 9, 2007 5:31 PM, Conal Elliott <[EMAIL PROTECTED] > wrote:
> > >
> > > > > IO is important because you can't write any real program without
> > > > using it.
> > > >
> > > > Ouch!  I get awfully discouraged when I read statements like this
> > > > one.  The more people who believe it, the more true it becomes.  If you 
> > > > want
> > > > to do functional programming, instead of imperative programming in a
> > > > functional language, you can.  For instance, write real, interactive
> > > > programs in FRP, phooey, or TV.  And if you do, you'll get semantic
> > > > simplicity, powerful & simpler reasoning, safety and composability.
> > > >
> > > >   - Conal
> > > >
> > > > On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED] >
> > > > wrote:
> > > >
> > > > > I agree with Dan here.
> > > > >
> > > > > IO is important because you can't write any real program without
> > > > > using it.
> > > > > So why not teach enough of it to get people off the ground
> > > > > straight away?
> > > > >
> > > > > People who hang around long enough to do some more Haskell
> > > > > programming
> > > > > will run into the other monads sooner or later.  But IO is an
> > > > > unavoidable step to
> > > > > writing Haskell programs.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Dec 4, 2007 5:11 AM, Dan Piponi < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > On Dec 3, 2007 6:36 PM, Ben Franksen < [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > then the special features of IO
> > > > > > > will remain associated with monads in general, leading to a
> > > > > > whole jumble of
> > > > > > > completely wrong ideas about them.
> > > > > >
> > > > > > As I only learnt about monads a couple of years ago, the process
> > > > > > is
> > > > > > still fresh in my mind. I wasted quite a bit of time labouring
> > > > > > under
> > > > >

[Haskell-cafe] ANNOUNCE: xmonad 0.5: a tiling window manager

[Don Stewart]

The xmonad dev team is pleased to announce the 0.5 release of xmonad! 

   http://xmonad.org

xmonad is a tiling window manager for X. Windows are arranged
automatically to tile the screen without gaps or overlap, maximising
screen use. Window manager features are accessible from the keyboard: a
mouse is optional. xmonad is extensible in Haskell, allowing for
powerful customisation. Custom layout algorithms, key bindings and other
extensions may be written by the user in config files. Layouts are
applied dynamically, and different layouts may be used on each
workspace. Xinerama is fully supported, allowing windows to be tiled on
several physical screens.

Features:

* Very stable, fast, small and simple.
* Automatic window tiling and management
* First class keyboard support: a mouse is unnecessary
* Full support for tiling windows on multi-head displays
* Full support for floating windows
* XRandR support to rotate, add or remove monitors
* Per-workspace layout algorithms
* Per-screens custom status bars
* Easy, powerful customisation and reconfiguration in Haskell
* Large extension library
* Extensive documentation and support for hacking

Get it!

More information, screenshots, documentation, tutorials and community
resources are available from the xmonad home page:

http://xmonad.org

The 0.5 release, and its dependencies, are available from
hackage.haskell.org, here:

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

**The headlines**

xmonad 0.5 is a major new release of xmonad, allowing, for the first
time, dynamic extension in Haskell without requiring recompilation.

Extension and configuration of xmonad is now faster, simpler, and more
flexible.

All configuration is done via the ~/.xmonad/xmonad.hs file.
Example config files and screenshots are available on the wiki:

http://haskell.org/haskellwiki/Xmonad/Config_archive

This marks the final break from its dwm origins. As a result, xmonad is
now also much easier to package, distribute and extend, as recompilation
of xmonad is not required to extend it.


New features:

* xmonad is now a library, as is the collection of xmonad extensions
* xmonad is configured by editing ~/.xmonad/xmonad.hs
* simpler layout hooks type and interface
* small EDSL for writing window management rules
* support for ghc 6.8.x
* xmonad now requires Cabal 1.2 or newer
* small bug fixes


Extensions:

xmonad comes with a huge library of extensions (now more than 5
times the size of xmonad), contributed by viewers like you.

Extensions enable pretty much arbitrary window manager behaviour to
be implemented by users, in Haskell, in the config files. Examples
include:

* ion-like window tabs
* status bar support
* X property and hints support
* altnerative layout algorithms

For more information on using and writing extensions see the webpage.
The library of extensions is available from hackage:


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

Brought to you by the xmonad team:

Spencer Janssen
Don Stewart
Jason Creighton
Andrea Rossato
David Roundy
Brent Yorgey

with code contributions from:

Brandon AllberyChris Mears
Shachaf Ben-Kiki   Eric Mertens
Alec Berryman  Neil Mitchell
Gwern Branwen  Devin Mullins
Joachim Breitner   Daniel Neri
Alexandre Buisse   Stefan O'Rear
Nick Burlett   Simon Peyton Jones
Peter De Wachter   Hans Philipp Annen
Aaron Denney   Karsten Schoelzel
Nelson Elhage  Michael Sloan
Shae Erisson   Ivan Tarasov
Joachim FastingAlex Tarkovsky
Michael Fellinger  Christian Thiemann
David Glasser  Joe Thornber
Kai GrossjohannMatsuyama Tomohiro
Dave Harrison  Daniel Wagner
Juraj Hercek   Ferenc Wagner
Sam Hughes Jamie Webb
Miikka KoskinenKlaus Weidner
David Lazarnornagon
Lucas Mai  timthelion
Robert Marlow  Valery V. Vorotyntsev 
Dougal Stanton Joel Suovaniemi
Mats Jansborg  Dmitry Kurochkin
Clemens Fruhwirth

As well as the support of many others on the #xmonad and #haskell IRC
channels, and the wider Haskell and window manager communities.

Thanks to everyone for their support!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problem with Gtk2hs

[Duncan Coutts]

On Sat, 2007-12-08 at 13:08 -0800, Stefan O'Rear wrote: 
> On Sat, Dec 08, 2007 at 08:33:36PM +, Andrew Coppin wrote:
> > I just spent the evening writing a library that's a thin layer over Gtk2hs. 
> > It took an age to get it to compile, but eventually it worked. Yay!
> >
> > When I ran it, I got this:
> >
> > Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor 
> > default method for class operation Data.Array.Base.getNumElements
> >
> > Er... wow.
> >
> > OK, at this point, I am completely stumped. Any hints?
> 
> That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't
> fully implement the (M)Array class.

The MArray class changed in ghc-6.8 and we didn't notice until the
gtk2hs release was already out.

So there are a couple workarounds, either grab the darcs version of the
0.9.12 branch which contains the fix:
http://darcs.haskell.org/gtk2hs-branches/gtk2hs-0.9.12/

Or use the released version with ghc-6.6.x rather than 6.8.x, since 6.6
has the previous different MArray interface.

Or use the unsafe indexing operators which bypass the bounds check which
calls getNumElements.


Duncan

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

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Daniel Fischer]

Just darcs got TV and read the sources.
Awesome stuff!

But what do I find in Interface.TV.IO ?

-- | 'Input' version of 'getContents'
contentsIn :: Input IO String
contentsIn = iPrim getContents

-- | 'Input' version of 'readFile'
fileIn :: FilePath -> Input IO String
fileIn name = iPrim (readFile name)

-- | 'Output' version of 'writeFile'
fileOut :: FilePath -> Output IO OI String
fileOut name = oPrim (Flip (writeFile name))

> If by "programme", you mean the code I write, then I'm happy to deny that
> my programme has to do these things.  

If you're saying you have a great library which takes care of IO chores, among 
other things, enforces (or at least strongly supports) separation of 
algorithm and IO, so that basically you have written the IO-part of your 
programmes once and for all, I won't deny that.
If you're saying your programmes don't use the IO monad to interface with the 
external world, I disagree.
If you consider your library to be part of the stateful RTS, I conclude that 
we have different ideas about the meaning of RTS.

Anyway, thanks for acquainting me with TV, it is a really cool library.

Cheers,
Daniel

Am Sonntag, 9. Dezember 2007 20:26 schrieb Conal Elliott:
> On Dec 9, 2007 10:07 AM, Daniel Fischer <[EMAIL PROTECTED]> wrote:
> > Interactive programmes without using IO? Cool :)
>
> And how!
>
> > I think you misunderstood Lennart.
>
> Thanks for checking.  In this case, I think I understood Lennart fine and
> that he was saying what you're saying.
>
> > Would you deny that any useful programme has to do at least some of the
>
> following:
> > -accept programme arguments at invocation
> > -get input, be it from a keyboard, mouse, reading files, pipes...
> > -output a result or state info, to the monitor, a file, a pipe...
>
>===
>
> If by "programme", you mean the code I write, then I'm happy to deny that
> my programme has to do these things.  Examples below.  If you include a
> stateful RTS, then no I don't deny it.
>

> Explicit imperative programming is just one way to deal with input &
> output, not the only way.  As proof, see FRP, Pan, or TV programs, which
> contain uses of none of these functions.  (Nor could they, as these
> libraries are functional, having IO-free types and semantics.)  Moreover,
> use of imperative programming sacrifices some of the semantic simplicity &
> composability that makes FP so appealing.  That's why I'd like to see this
> belief in its necessity dispelled.
>
> That said, I don't think the existing functional (non-IO) approaches to
> interaction are quite there yet with the flexibility of imperative
> programming.  It will take more work to get them there, and that work is
> mostly likely to be pursued by people who doubt the necessity of IO for
> writing "real programs".  In that sense, Lennart's and your statements are
> self-fulfilling prophechies, as are mine.
>
> BTW, if you haven't seen it already, please check out
> http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
> includes a simple algebra of interfaces (input/output) and keeps separable
> from the core computation.  The separability allows the interface parts to
> be composed in parallel with the core part.  For instance, when two
> function-valued TVs are composed, the interfaces are peeled off, so that
> the core functions can be composed directly.  The output half of one
> interface and the matching input half of the other are discarded.  The
> remaining input and output halves are recombined into a new interface,
> which is used as the interface of the composed TV.  The core interface
> algebra can be used for text stream i/o, GUIs, and many other possible
> styles of information passing.
>
> I mention TV, because it's an example of combining the purity &
> composability I love about FP with the usability a "real" app.  For more
> about this combination, please see my Google tech talk "Tangible Functional
> Programming: a modern marriage of usability and composability" (
> http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-m
>odern.html). That talk focus on end-user composability, but the essential
> points apply as well to explicit programming.  As I mentioned before, TV
> (a) is currently less flexible than imperative/IO programming, and (b) has
> the composability, guaranteed safety, and amenability to reasoning of pure
> functional programming.
>
>
> Cheers,  - Conal
>
> Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > > > IO is important because you can't write any real program without
> > > > using it.
> > >
> > > Ouch!  I get awfully discouraged when I read statements like this one.
> >
> >  The
> >
> > > more people who believe it, the more true it becomes.  If you want to
> > > do functional programming, instead of imperative programming in a
> >
> > functional
> >
> > > language, you can.  For instance, write real, interactive programs in
> >
> > FRP,
> >
> > > phooey, or TV.  And if you do, you'll get sema

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Lennart Augustsson]

Maybe I'm exaggerating, but it's true for 96% of all programs.  (96% is with
a :-))
I did not express anything that was meant to be a perpetual truth, only best
practice at the moment.

For a living I write programs that are almost without interaction with the
outside world. Still, I need a to spend 1% of the code doing IO related
stuff and it's very important that I can do it.  The other 99% are just pure
computations.
But that I think that validates rather than invalidates my point.

  -- Lennart

On Dec 9, 2007 8:29 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

> I think your real point is that some things we still haven't figured out
> how to express functionally.  Right?  I would certainly agree with that
> part.  Perhaps you exaggerating when you wrote "IO is important because you
> can't write any real program without using it."
>
> Cheers, - Conal
>
>
> On Dec 9, 2007 12:14 PM, Lennart Augustsson <[EMAIL PROTECTED]>
> wrote:
>
> > Conal,
> >
> > I think TV etc. is fantastic stuff, but that mean that we cannot, say,
> > invoke an external program in Haskell until someone has figured out a
> > composable library for this?
> > I sincerely hope someone will, but the only way we have right now is the
> > ugly IO monad.
> >
> >   -- Lennart
> >
> > On Dec 9, 2007 7:26 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 9, 2007 10:07 AM, Daniel Fischer <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Interactive programmes without using IO? Cool :)
> > >
> > > And how!
> > >
> > > > I think you misunderstood Lennart.
> > >
> > > Thanks for checking.  In this case, I think I understood Lennart fine
> > > and that he was saying what you're saying.
> > >
> > > > Would you deny that any useful programme has to do at least some of
> > > the following:
> > > > -accept programme arguments at invocation
> > > > -get input, be it from a keyboard, mouse, reading files, pipes...
> > > > -output a result or state info, to the monitor, a file, a pipe...
> > >===
> > >
> > > If by "programme", you mean the code I write, then I'm happy to deny
> > > that my programme has to do these things.  Examples below.  If you 
> > > include a
> > > stateful RTS, then no I don't deny it.
> > >
> > > > I think Lennart was referring to that, you HAVE to know a little IO
> > > to write
> > > > programmes, at least getArgs, getLine, putStr(Ln), readFile,
> > > writeFile,
> > > > appendFile. And therefore some use of the IO monad has to be taught
> > > > relatively early.
> > >
> > > Explicit imperative programming is just one way to deal with input &
> > > output, not the only way.  As proof, see FRP, Pan, or TV programs, which
> > > contain uses of none of these functions.  (Nor could they, as these
> > > libraries are functional, having IO-free types and semantics.)  Moreover,
> > > use of imperative programming sacrifices some of the semantic simplicity &
> > > composability that makes FP so appealing.  That's why I'd like to see this
> > > belief in its necessity dispelled.
> > >
> > > That said, I don't think the existing functional (non-IO) approaches
> > > to interaction are quite there yet with the flexibility of imperative
> > > programming.  It will take more work to get them there, and that work is
> > > mostly likely to be pursued by people who doubt the necessity of IO for
> > > writing "real programs".  In that sense, Lennart's and your statements are
> > > self-fulfilling prophechies, as are mine.
> > >
> > > BTW, if you haven't seen it already, please check out
> > > http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
> > > includes a simple algebra of interfaces (input/output) and keeps separable
> > > from the core computation.  The separability allows the interface parts to
> > > be composed in parallel with the core part.  For instance, when two
> > > function-valued TVs are composed, the interfaces are peeled off, so that 
> > > the
> > > core functions can be composed directly.  The output half of one interface
> > > and the matching input half of the other are discarded.  The remaining 
> > > input
> > > and output halves are recombined into a new interface, which is used as 
> > > the
> > > interface of the composed TV.  The core interface algebra can be used for
> > > text stream i/o, GUIs, and many other possible styles of information
> > > passing.
> > >
> > > I mention TV, because it's an example of combining the purity &
> > > composability I love about FP with the usability a "real" app.  For more
> > > about this combination, please see my Google tech talk "Tangible 
> > > Functional
> > > Programming: a modern marriage of usability and composability" (
> > > http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html).
> > > That talk focus on end-user composability, but the essential points apply 
> > > as
> > > well to explicit programming.  As I mentioned before, TV (a) is currently
> > > less flexible than imperative/IO programming, and (b) has

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Lennart Augustsson]

I doubt all imperative programming will be banished from Haskell anytime
soon.  I really, really wish we had all the nice abstractions in place
already, but we just don't.

You can't write any program in Haskell without using IO, because the type of
main involves IO.
And currently I believe that almost any real program will have to involve
IO.
(BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell
because I insisted on it.)
It's just from my experience.  No matter how pure your program is, here and
there it will be interacting with the rest of the world.

  -- Lennart

On Dec 9, 2007 10:16 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

> Thanks.  If I'm tracking, your real point is that imperative programming
> in Haskell is still useful enough to keep around.  I agree.
>
> I'm still puzzled.  Did you understand something I said, or maybe someone
> else said, as suggesting that imperative programming be removed from Haskell
> any time soon?
>
> > It's also important to teach people to stay away from IO whenever
> possible, but it's simply not always possible.
>
> How can we possibly teach them to stay away from IO where possible if
> we're also telling them that they can't write *any* real program without
> using IO?
>
> Cheers, - Conal
>
>
> On Dec 9, 2007 12:02 PM, Lennart Augustsson <[EMAIL PROTECTED] >
> wrote:
>
> > Conal,
> >
> > It's true that you can avoid using IO (except for a wrapper) for certain
> > kinds of programs.
> > For instance, if all you want is a String->String function, or some GUI
> > program (you forgot to mention fudgets, which was the first wrapper of this
> > kind) then you can ignore IO and just use a nice wrapper.
> >
> > But if someone asks me how to traverse a directory tree, invoking the
> > 'file' program for each ',o' file and then renaming it if it's a text file,
> > then what should I answer?  "Sorry, you can't do that in Haskell."  or "You
> > need to use the IO monad."?
> > I prefer the latter answer, and I think people who learn Haskell need to
> > learn something about how you do some of the things that are easy in other
> > languages.
> >
> > It's also important to teach people to stay away from IO whenever
> > possible, but it's simply not always possible.
> >
> >   -- Lennart
> >
> >
> > On Dec 9, 2007 5:31 PM, Conal Elliott <[EMAIL PROTECTED] > wrote:
> >
> > > > IO is important because you can't write any real program without
> > > using it.
> > >
> > > Ouch!  I get awfully discouraged when I read statements like this
> > > one.  The more people who believe it, the more true it becomes.  If you 
> > > want
> > > to do functional programming, instead of imperative programming in a
> > > functional language, you can.  For instance, write real, interactive
> > > programs in FRP, phooey, or TV.  And if you do, you'll get semantic
> > > simplicity, powerful & simpler reasoning, safety and composability.
> > >
> > >   - Conal
> > >
> > > On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED] >
> > > wrote:
> > >
> > > > I agree with Dan here.
> > > >
> > > > IO is important because you can't write any real program without
> > > > using it.
> > > > So why not teach enough of it to get people off the ground straight
> > > > away?
> > > >
> > > > People who hang around long enough to do some more Haskell
> > > > programming
> > > > will run into the other monads sooner or later.  But IO is an
> > > > unavoidable step to
> > > > writing Haskell programs.
> > > >
> > > >
> > > >
> > > >
> > > > On Dec 4, 2007 5:11 AM, Dan Piponi < [EMAIL PROTECTED]> wrote:
> > > >
> > > > > On Dec 3, 2007 6:36 PM, Ben Franksen < [EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > then the special features of IO
> > > > > > will remain associated with monads in general, leading to a
> > > > > whole jumble of
> > > > > > completely wrong ideas about them.
> > > > >
> > > > > As I only learnt about monads a couple of years ago, the process
> > > > > is
> > > > > still fresh in my mind. I wasted quite a bit of time labouring
> > > > > under
> > > > > the impression that monads were primarily about sequencing. But
> > > > > that
> > > > > wasn't because I incorrectly generalised from IO. It was because
> > > > > countless people out there explicitly said they were about
> > > > > sequencing.
> > > > > I suspect that if courses started with the List monad there'd be
> > > > > countless blogs telling people that monads are a way to eliminate
> > > > > loops from your code like the way list comprehensions are used in
> > > > > Python.
> > > > >
> > > > > > This is yet another problem with IO as the standard example for
> > > > > monads: its
> > > > > > effect base is huge and poorly structured.
> > > > >
> > > > > You don't teach *all* of IO to students in one go!
> > > > >
> > > > > > This again makes it difficult to
> > > > > > see exactly which intuitions about IO can be generalized to
> > > > > arbitrary
> > > > > > monads and which not.
> > > > >
> > > > > That's true of

[Haskell-cafe] hi

[Ryan Bloor]

hi
 
I am writing a basic Parser from scratch. So far I have functions;# 
removeSpaces# match - which checks if a string is a substring of another# 
orParser which combines two parser's abilities# Basic pasrers like... parseInt, 
parseTrue, parseFalse, parseBoolusing the orParser on True and False.What I 
want to do now is have a parseBinaryOp that recognises:parseBinaryOp "+" "(5 + 
2) if"  >>>gives>> [(EInt 5, EInt 2, "if")]So I 
think that I have to split the initial string into four parts."+" becomes op'(' 
becomes tokenF')' becomes tokenB"5" becomes e1"2" becomes e2parseBinaryOp :: 
String -> String -> [(Expr, Expr, String)]parseBinaryOp op str = let 
(tokenF,e1,op,e2,tokenB) =I am not sure how to go about separating the string 
for how I need itusing my other functiuons. Ryan
_
Get free emoticon packs and customisation from Windows Live. 
http://www.pimpmylive.co.uk___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Point and link

[Tim Docker]

Andrew Coppin wrote:
>
> Such a GUI would be cool for a number of projects. It still needs to
exist first. ;-)
>

I don't think anyone has mentioned this:

http://haskell.org/Blobs

which I haven't used, though the screenshots look good.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] parsebinaryoperations

[Philip Weaver]

Maybe you should look into Parsec, a Haskell library for writing parsers.
Google should find what you need.

- Phil

On Dec 9, 2007 1:58 AM, Ryan Bloor <[EMAIL PROTECTED]> wrote:

> hi
>
> I have a function parseInt... which needs an error guard for when the
> input is not an Int.
>
> parseInt :: Parser
> parseInt [] = []
> parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)
> in [(EInt (read digits), removeSpace rest)]
>
> Also... I have a function that does this... parseBinaryOp "+" "(5 + 2)
> if"  gives...[(Int 5, Int 2, "if")]
> so, op is '+' or "&&". I am unsure of how to begin...
>
> parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
> parseBinaryOp op str
>
> Thankyou
>
> Ryan
>
> --
> Get closer to the jungle… I'm a Celebrity Get Me Out Of 
> Here!
>
> ___
> 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] IO is a bad example for Monads

[Daniel Fischer]

Am Sonntag, 9. Dezember 2007 23:35 schrieb Ketil Malde:
> Daniel Fischer <[EMAIL PROTECTED]> writes:
> >>> IO is important because you can't write any real program without using
> >>> it.
> >>
> >> Ouch!  I get awfully discouraged when I read statements like this
> >> one.
> >
> > I think Lennart was referring to that, you HAVE to know a little IO to
> > write programmes, at least getArgs, getLine, putStr(Ln), readFile,
> > writeFile, appendFile. And therefore some use of the IO monad has to be
> > taught relatively early.

Emphasis on *use*, introduce the concept of monads not before lists, Maybe and 
Either.
>
> Well, I guess you could get pretty far using 'interact' - far enough
> in an educational setting to do lists and Maybe, and then monads,
> before introducing monadic IO.
>
> -k

Pretty far, yes, and in an educational setting, at a university, it is quite 
common, I believe, to use an interpreter for a while, not producing 
executables (that's how I met Haskell, write pure functions and type 
expressions at the Hugs prompt). But what about a tutorial for programmers?
How would you do

main = do
putStrLn "Please enter your name."
name <- getLine
putStrLn $ "Hello " ++ name ++ ", nice to meet you."

in that setting?
I doubt you could keep many interested without telling them how to create 
standalone programmes, including reading input from stdin and printing output 
to stdout.

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

Re: [Haskell-cafe] IO is a bad example for Monads

[Ketil Malde]

Daniel Fischer <[EMAIL PROTECTED]> writes:

>>> IO is important because you can't write any real program without using
>>> it.

>> Ouch!  I get awfully discouraged when I read statements like this
>> one.

> I think Lennart was referring to that, you HAVE to know a little IO to write 
> programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, 
> appendFile. And therefore some use of the IO monad has to be taught 
> relatively early.

Well, I guess you could get pretty far using 'interact' - far enough
in an educational setting to do lists and Maybe, and then monads,
before introducing monadic IO.

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

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Conal Elliott]

Thanks.  If I'm tracking, your real point is that imperative programming in
Haskell is still useful enough to keep around.  I agree.

I'm still puzzled.  Did you understand something I said, or maybe someone
else said, as suggesting that imperative programming be removed from Haskell
any time soon?

> It's also important to teach people to stay away from IO whenever
possible, but it's simply not always possible.

How can we possibly teach them to stay away from IO where possible if we're
also telling them that they can't write *any* real program without using IO?

Cheers, - Conal

On Dec 9, 2007 12:02 PM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:

> Conal,
>
> It's true that you can avoid using IO (except for a wrapper) for certain
> kinds of programs.
> For instance, if all you want is a String->String function, or some GUI
> program (you forgot to mention fudgets, which was the first wrapper of this
> kind) then you can ignore IO and just use a nice wrapper.
>
> But if someone asks me how to traverse a directory tree, invoking the
> 'file' program for each ',o' file and then renaming it if it's a text file,
> then what should I answer?  "Sorry, you can't do that in Haskell."  or "You
> need to use the IO monad."?
> I prefer the latter answer, and I think people who learn Haskell need to
> learn something about how you do some of the things that are easy in other
> languages.
>
> It's also important to teach people to stay away from IO whenever
> possible, but it's simply not always possible.
>
>   -- Lennart
>
>
> On Dec 9, 2007 5:31 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
>
> > > IO is important because you can't write any real program without using
> > it.
> >
> > Ouch!  I get awfully discouraged when I read statements like this one.
> > The more people who believe it, the more true it becomes.  If you want to do
> > functional programming, instead of imperative programming in a functional
> > language, you can.  For instance, write real, interactive programs in FRP,
> > phooey, or TV.  And if you do, you'll get semantic simplicity, powerful &
> > simpler reasoning, safety and composability.
> >
> >   - Conal
> >
> > On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED] >
> > wrote:
> >
> > > I agree with Dan here.
> > >
> > > IO is important because you can't write any real program without using
> > > it.
> > > So why not teach enough of it to get people off the ground straight
> > > away?
> > >
> > > People who hang around long enough to do some more Haskell programming
> > >
> > > will run into the other monads sooner or later.  But IO is an
> > > unavoidable step to
> > > writing Haskell programs.
> > >
> > >
> > >
> > >
> > > On Dec 4, 2007 5:11 AM, Dan Piponi < [EMAIL PROTECTED]> wrote:
> > >
> > > > On Dec 3, 2007 6:36 PM, Ben Franksen < [EMAIL PROTECTED]>
> > > > wrote:
> > > > > then the special features of IO
> > > > > will remain associated with monads in general, leading to a whole
> > > > jumble of
> > > > > completely wrong ideas about them.
> > > >
> > > > As I only learnt about monads a couple of years ago, the process is
> > > > still fresh in my mind. I wasted quite a bit of time labouring under
> > > > the impression that monads were primarily about sequencing. But that
> > > >
> > > > wasn't because I incorrectly generalised from IO. It was because
> > > > countless people out there explicitly said they were about
> > > > sequencing.
> > > > I suspect that if courses started with the List monad there'd be
> > > > countless blogs telling people that monads are a way to eliminate
> > > > loops from your code like the way list comprehensions are used in
> > > > Python.
> > > >
> > > > > This is yet another problem with IO as the standard example for
> > > > monads: its
> > > > > effect base is huge and poorly structured.
> > > >
> > > > You don't teach *all* of IO to students in one go!
> > > >
> > > > > This again makes it difficult to
> > > > > see exactly which intuitions about IO can be generalized to
> > > > arbitrary
> > > > > monads and which not.
> > > >
> > > > That's true of any monad. IO is unique. [] is unique. Cont is
> > > > unique.
> > > > All of them can lead you down the garden path. You need to see
> > > > multiple monads, and it helps if you can sneak an example under a
> > > > student's nose so they can already reason about monads before they
> > > > even know what a monad is.
> > > >
> > > > > What is pointless about failure and how to handle it?
> > > >
> > > > It's pointless when you're still trying to make your first tweaks to
> > > >
> > > > "Hello, World!" work.
> > > > --
> > > > Dan
> > > > ___
> > > > 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/listinf

Re: [Haskell-cafe] Re: [Haskell] IVars

[Benja Fallenstein]

Hi Conal,

On Dec 9, 2007 6:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> > readIVar' :: IVar a -> a
> > readIVar' = unsafePerformIO . readIVar
>
> > so, we do not need readIVar'. it could be a nice addition to the
> libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
>
> The same argument applies any to pure function, doesn't it?  For instance, a
> non-IO version of succ is unnecessary.  My question is why make readIVar a
> blocking IO action rather than a blocking pure value, considering that it
> always returns the same value?

>From the rest of Marc's post, I understood the point to be that
readIVar lets you do something that readIVar' does not let you do:
block until the IVar is written, then continue *without* first
evaluating the thunk in the IVar to WHNF. I haven't used IVars myself,
so this isn't informed by hands-on experience, but it does sound
sensible to me that "block until the IVar has been written" and
"evaluate the thunk to WHNF" should be separable.

All the best,
- Benja
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] binaryop

[Ryan Bloor]

hi  sorry for vagueness.  I am writing a basic Parser from scratch. So far I 
have functions;  # removeSpaces # match - which checks if a string is a 
substring of another # orParser which combines two parser's abilities # Basic 
pasrers like... parseInt, parseTrue, parseFalse, parseBoolusing the orParser on 
True and False.  What I want to do now is have a parseBinaryOp that recognises: 
parseBinaryOp "+" "(5 + 2) if"  >>>gives>> 
[(EInt 5, EInt 2, "if")]  So I think that I have to split the initial string 
into four parts.  "+" becomes op '(' becomes tokenF ')' becomes tokenB "5" 
becomes e1 "2" becomes e2  parseBinaryOp :: String -> String -> [(Expr, Expr, 
String)]parseBinaryOp op str = let (tokenF,e1,op,e2,tokenB) =  I am not sure 
how to go about separating the string for how I need itusing my other 
functiuons. Ryan
_
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Conal Elliott]

Thanks for the clarification.

>AFAIK, the only way to get input and produce output is via the IO monad

Now you know something different, don't you?  FRP, Pan, TV.  Also
Grapefruit, functional forms, and others I'm not thinking of or don't know
about.

As for your example, mixing the IO with the functional, as you have
interferes with composing the result.  I can think of two alternatives.  One
is to move reading & printing from the definition to the uses, as with Unix
stream filters.  Still convenient, and much more flexible.  Of course, Unix
programs were written in C and so use explicit I/O instead of lazy
functional streams.  (Though Doug McIlroy, who invented Unix pipes, knew
that pipes were equivalent to coroutines and to lazy evaluation.  See my
"modern marriage" talk (the video I mentioned) for more about Unix and TV.)

A second alternative is to use TV to explicitly capture the interface (I/O),
which could look like this:

coolTV :: TV (String -> String)
coolTV = tv (olambda (fileIn "Data.txt") defaultOut)
performAwfullyCoolFunctionalStuff

where

tv :: Output src snk a -> a -> TV src snk a

The type parameters src & snk are for various interface styles.  Then coolTV
can then be used on *either* side of a TV-style pipe, resulting in the
removal of the reading or writing half.

And yes, there are *some* uses of IO for which I'd be hard pressed at this
point to offer you an alternative.  Which is a far cry from IO being
necessary for all "real" programs, even today.

Given this state of affairs, I'd prefer the Haskell community to point
newbies away from IO and toward purely functional programming for things
like UIs and graphics and help them change their way of thinking.  Let's
also admit that we haven't yet figured out how to apply our functional
paradigm as flexibly or broadly as we'd like, and so meanwhile we have thi
monadic IO trick that let's them write nicely factored imperative code that
can call into the functional pieces.

Regards,  - Conal

On Dec 9, 2007 12:54 PM, Daniel Fischer <[EMAIL PROTECTED]> wrote:

> Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott:
> > I think your real point is that some things we still haven't figured out
> > how to express functionally.  Right?
>
> That's my point, at least. Currently, AFAIK, the only way to get input and
> produce output is via the IO monad, so it is de facto necessary for all
> 'real' programmes, it need not remain so (though I cannot imagine how to
> functionally express
> 'readFile "Data.txt" >>= print . performAwfullyCoolFunctionalStuff' -
> surprise
> me :).
> Read "IO is important" as a description of current affairs, not as a claim
> of
> the inherent grandeur of it.
>
> Cheers,
> Daniel
>
> >  I would certainly agree with that
> > part. Perhaps you exaggerating when you wrote "IO is important because
> you
> > can't write any real program without using it."
> >
> > Cheers, - Conal
> >
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Fwd: Parsing integers [was: Re: [Haskell-cafe] help]

[Tim Chevalier]

[reply forwarded to list]

-- Forwarded message --
From: Ryan Bloor <[EMAIL PROTECTED]>

hi

 sorry for vagueness.


I am writing a basic Parser from scratch. So far I have functions;

 # removeSpaces
 # match - which checks if a string is a substring of another
 # orParser which combines two parser's abilities
 # Basic pasrers like... parseInt, parseTrue, parseFalse, parseBool
using the orParser on True and False.

 What I want to do now is have a parseBinaryOp that recognises:
 parseBinaryOp "+" "(5 + 2) if"  >>>gives>>
 [(EInt 5, EInt 2, "if")]

 So I think that I have to split the initial string into four parts.

 "+" becomes op
 '(' becomes tokenF
 ')' becomes tokenB
 "5" becomes e1
 "2" becomes e2

 parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
parseBinaryOp op str = let (tokenF,e1,op,e2,tokenB) =

 I am not sure how to go about separating the string for how I need it
using my other functiuons.

 Ryan





 

 > Date: Sun, 9 Dec 2007 13:07:23 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Parsing integers [was: Re: [Haskell-cafe] help]
> CC: haskell-cafe@haskell.org

>
> On 12/9/07, Ryan Bloor <[EMAIL PROTECTED]> wrote:
> >
> > hi
> >
> > I have a function parseInt... which needs an error guard for when the input
> > is not an Int.
> >
> > parseInt :: Parser
> > parseInt [] = []
> > parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)
> > in [(EInt (read digits), removeSpace rest)]
> >
> > Also... I have a function that does this... parseBinaryOp "+" "(5 + 2) if"
> > gives...[(Int 5, Int 2, "if")]
> > so, op is '+' or "&&". I am unsure of how to begin...
> >
> > parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
> > parseBinaryOp op str
> >
>
> Check out:
> http://www.haskell.org/haskellwiki/Homework_help
>
> If this isn't homework, try posting again and phrasing your question
> in the form of a question; saying "I am unsure of how to begin"
> doesn't help us help you think about the problem.
>
> Cheers,
> Tim
>
> --
> Tim Chevalier * catamorphism.org * Often in error, never in doubt
> "[Teaching children to read] will make America what we want it to be,
> a literate country and a hopefuller country." -- George W. Bush



Are you the Quizmaster? Play BrainBattle with a friend now!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Parsing integers [was: Re: [Haskell-cafe] help]

[Tim Chevalier]

On 12/9/07, Ryan Bloor <[EMAIL PROTECTED]> wrote:
>
> hi
>
> I have a function parseInt... which needs an error guard for when the input
> is not an Int.
>
> parseInt :: Parser
> parseInt [] = []
> parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)
> in [(EInt (read digits), removeSpace rest)]
>
> Also... I have a function that does this... parseBinaryOp "+" "(5 + 2) if"
>gives...[(Int 5, Int 2, "if")]
> so, op is '+' or "&&". I am unsure of how to begin...
>
> parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
> parseBinaryOp op str
>

Check out:
http://www.haskell.org/haskellwiki/Homework_help

If this isn't homework, try posting again and phrasing your question
in the form of a question; saying "I am unsure of how to begin"
doesn't help us help you think about the problem.

Cheers,
Tim

-- 
Tim Chevalier * catamorphism.org * Often in error, never in doubt
"[Teaching children to read] will make America what we want it to be,
a literate country and a hopefuller country." -- George W. Bush
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] help

[Ryan Bloor]

hi I have a function parseInt... which needs an error guard for when the input 
is not an Int. parseInt :: ParserparseInt [] = []parseInt xs = let (digits, 
rest) = span isDigit (removeSpace xs)in [(EInt (read digits), 
removeSpace rest)] Also... I have a function that does this... parseBinaryOp 
"+" "(5 + 2) if"  gives...[(Int 5, Int 2, "if")]so, op is '+' or "&&". I am 
unsure of how to begin...  parseBinaryOp :: String -> String -> [(Expr, Expr, 
String)]parseBinaryOp op str Thankyou Ryan
_
Get free emoticon packs and customisation from Windows Live. 
http://www.pimpmylive.co.uk___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Daniel Fischer]

Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott:
> I think your real point is that some things we still haven't figured out
> how to express functionally.  Right?

That's my point, at least. Currently, AFAIK, the only way to get input and 
produce output is via the IO monad, so it is de facto necessary for all 
'real' programmes, it need not remain so (though I cannot imagine how to 
functionally express 
'readFile "Data.txt" >>= print . performAwfullyCoolFunctionalStuff' - surprise 
me :).
Read "IO is important" as a description of current affairs, not as a claim of 
the inherent grandeur of it.

Cheers,
Daniel

>  I would certainly agree with that
> part. Perhaps you exaggerating when you wrote "IO is important because you
> can't write any real program without using it."
>
> Cheers, - Conal
>

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

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Conal Elliott]

I think your real point is that some things we still haven't figured out how
to express functionally.  Right?  I would certainly agree with that part.
Perhaps you exaggerating when you wrote "IO is important because you can't
write any real program without using it."

Cheers, - Conal

On Dec 9, 2007 12:14 PM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:

> Conal,
>
> I think TV etc. is fantastic stuff, but that mean that we cannot, say,
> invoke an external program in Haskell until someone has figured out a
> composable library for this?
> I sincerely hope someone will, but the only way we have right now is the
> ugly IO monad.
>
>   -- Lennart
>
> On Dec 9, 2007 7:26 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
>
> > On Dec 9, 2007 10:07 AM, Daniel Fischer <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Interactive programmes without using IO? Cool :)
> >
> > And how!
> >
> > > I think you misunderstood Lennart.
> >
> > Thanks for checking.  In this case, I think I understood Lennart fine
> > and that he was saying what you're saying.
> >
> > > Would you deny that any useful programme has to do at least some of
> > the following:
> > > -accept programme arguments at invocation
> > > -get input, be it from a keyboard, mouse, reading files, pipes...
> > > -output a result or state info, to the monitor, a file, a pipe...
> >===
> >
> > If by "programme", you mean the code I write, then I'm happy to deny
> > that my programme has to do these things.  Examples below.  If you include a
> > stateful RTS, then no I don't deny it.
> >
> > > I think Lennart was referring to that, you HAVE to know a little IO to
> > write
> > > programmes, at least getArgs, getLine, putStr(Ln), readFile,
> > writeFile,
> > > appendFile. And therefore some use of the IO monad has to be taught
> > > relatively early.
> >
> > Explicit imperative programming is just one way to deal with input &
> > output, not the only way.  As proof, see FRP, Pan, or TV programs, which
> > contain uses of none of these functions.  (Nor could they, as these
> > libraries are functional, having IO-free types and semantics.)  Moreover,
> > use of imperative programming sacrifices some of the semantic simplicity &
> > composability that makes FP so appealing.  That's why I'd like to see this
> > belief in its necessity dispelled.
> >
> > That said, I don't think the existing functional (non-IO) approaches to
> > interaction are quite there yet with the flexibility of imperative
> > programming.  It will take more work to get them there, and that work is
> > mostly likely to be pursued by people who doubt the necessity of IO for
> > writing "real programs".  In that sense, Lennart's and your statements are
> > self-fulfilling prophechies, as are mine.
> >
> > BTW, if you haven't seen it already, please check out
> > http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
> > includes a simple algebra of interfaces (input/output) and keeps separable
> > from the core computation.  The separability allows the interface parts to
> > be composed in parallel with the core part.  For instance, when two
> > function-valued TVs are composed, the interfaces are peeled off, so that the
> > core functions can be composed directly.  The output half of one interface
> > and the matching input half of the other are discarded.  The remaining input
> > and output halves are recombined into a new interface, which is used as the
> > interface of the composed TV.  The core interface algebra can be used for
> > text stream i/o, GUIs, and many other possible styles of information
> > passing.
> >
> > I mention TV, because it's an example of combining the purity &
> > composability I love about FP with the usability a "real" app.  For more
> > about this combination, please see my Google tech talk "Tangible Functional
> > Programming: a modern marriage of usability and composability" (
> > http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html).
> > That talk focus on end-user composability, but the essential points apply as
> > well to explicit programming.  As I mentioned before, TV (a) is currently
> > less flexible than imperative/IO programming, and (b) has the composability,
> > guaranteed safety, and amenability to reasoning of pure functional
> > programming.
> >
> >
> > Cheers,  - Conal
> >
> >
> >
> > Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > > > > IO is important because you can't write any real program without
> > > using
> > > > > it.
> > > >
> > > > Ouch!  I get awfully discouraged when I read statements like this
> > > one.  The
> > > > more people who believe it, the more true it becomes.  If you want
> > > to do
> > > > functional programming, instead of imperative programming in a
> > > functional
> > > > language, you can.  For instance, write real, interactive programs
> > > in FRP,
> > > > phooey, or TV.  And if you do, you'll get semantic simplicity,
> > > powerful &
> > > > simpler reasoning, 

Re: [Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Lennart Augustsson]

Conal,

I think TV etc. is fantastic stuff, but that mean that we cannot, say,
invoke an external program in Haskell until someone has figured out a
composable library for this?
I sincerely hope someone will, but the only way we have right now is the
ugly IO monad.

  -- Lennart

On Dec 9, 2007 7:26 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

> On Dec 9, 2007 10:07 AM, Daniel Fischer <[EMAIL PROTECTED]> wrote:
>
> > Interactive programmes without using IO? Cool :)
>
> And how!
>
> > I think you misunderstood Lennart.
>
> Thanks for checking.  In this case, I think I understood Lennart fine and
> that he was saying what you're saying.
>
> > Would you deny that any useful programme has to do at least some of the
> following:
> > -accept programme arguments at invocation
> > -get input, be it from a keyboard, mouse, reading files, pipes...
> > -output a result or state info, to the monitor, a file, a pipe...
>===
>
> If by "programme", you mean the code I write, then I'm happy to deny that
> my programme has to do these things.  Examples below.  If you include a
> stateful RTS, then no I don't deny it.
>
> > I think Lennart was referring to that, you HAVE to know a little IO to
> write
> > programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile,
> > appendFile. And therefore some use of the IO monad has to be taught
> > relatively early.
>
> Explicit imperative programming is just one way to deal with input &
> output, not the only way.  As proof, see FRP, Pan, or TV programs, which
> contain uses of none of these functions.  (Nor could they, as these
> libraries are functional, having IO-free types and semantics.)  Moreover,
> use of imperative programming sacrifices some of the semantic simplicity &
> composability that makes FP so appealing.  That's why I'd like to see this
> belief in its necessity dispelled.
>
> That said, I don't think the existing functional (non-IO) approaches to
> interaction are quite there yet with the flexibility of imperative
> programming.  It will take more work to get them there, and that work is
> mostly likely to be pursued by people who doubt the necessity of IO for
> writing "real programs".  In that sense, Lennart's and your statements are
> self-fulfilling prophechies, as are mine.
>
> BTW, if you haven't seen it already, please check out
> http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
> includes a simple algebra of interfaces (input/output) and keeps separable
> from the core computation.  The separability allows the interface parts to
> be composed in parallel with the core part.  For instance, when two
> function-valued TVs are composed, the interfaces are peeled off, so that the
> core functions can be composed directly.  The output half of one interface
> and the matching input half of the other are discarded.  The remaining input
> and output halves are recombined into a new interface, which is used as the
> interface of the composed TV.  The core interface algebra can be used for
> text stream i/o, GUIs, and many other possible styles of information
> passing.
>
> I mention TV, because it's an example of combining the purity &
> composability I love about FP with the usability a "real" app.  For more
> about this combination, please see my Google tech talk "Tangible Functional
> Programming: a modern marriage of usability and composability" (
> http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html).
> That talk focus on end-user composability, but the essential points apply as
> well to explicit programming.  As I mentioned before, TV (a) is currently
> less flexible than imperative/IO programming, and (b) has the composability,
> guaranteed safety, and amenability to reasoning of pure functional
> programming.
>
>
> Cheers,  - Conal
>
>
>
> Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > > > IO is important because you can't write any real program without
> > using
> > > > it.
> > >
> > > Ouch!  I get awfully discouraged when I read statements like this one.
> >  The
> > > more people who believe it, the more true it becomes.  If you want to
> > do
> > > functional programming, instead of imperative programming in a
> > functional
> > > language, you can.  For instance, write real, interactive programs in
> > FRP,
> > > phooey, or TV.  And if you do, you'll get semantic simplicity,
> > powerful &
> > > simpler reasoning, safety and composability.
> > >
> > >   - Conal
> >
>  > > On Dec 8, 2007 1:26 AM, Lennart Augustsson < [EMAIL PROTECTED]>
> wrote:
>
> > > [...]
>
> > > IO is important because you can't write any real program without using
> it.
> > > So why not teach enough of it to get people off the ground straight
> away?
>
> > > People who hang around long enough to do some more Haskell programming
> > > will run into the other monads sooner or later.  But IO is an
> unavoidable step to
> > > writing Haskell programs.
>
>
>
>
> __

Re: [Haskell-cafe] Re: [Haskell] IVars

[Lennart Augustsson]

I would claim that it's fine to use the type
  readIVar :: IVar a -> a
if you're willing to give the "right" semantics to
  newIVar :: IO (IVar a)
The semantics is that sometimes when you create an IVar you'll get one that
always returns _|_ when read, sometimes you'll get a proper one.  Now if you
happen to read an IVar and it deadlocks your program, well, sorry, you were
unlucky and got a bad IVar that time.

So it's possible to explain away the deadlock as something non-deterministic
in the IO monad.  Doing so comes at a terrible price though, because you can
no longer reason about your program.

  -- Lennart

On Dec 9, 2007 7:48 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

> Thanks, Luke.  I'd been unconsciously assuming that the IVar would get
> written to (if ever) by a thread other than the one doing the reading.
> (Even then, there could be a deadlock.)
>
>   - Conal
>
>
> On Dec 9, 2007 9:37 AM, Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > On Dec 9, 2007 5:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> > > (moving to haskell-cafe)
> > >
> > > > readIVar' :: IVar a -> a
> > > > readIVar' = unsafePerformIO . readIVar
> > >
> > > > so, we do not need readIVar'. it could be a nice addition to the
> > > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > >
> > > The same argument applies any to pure function, doesn't it?  For
> > instance, a
> > > non-IO version of succ is unnecessary.  My question is why make
> > readIVar a
> > > blocking IO action rather than a blocking pure value, considering that
> > it
> > > always returns the same value?
> >
> > But I don't think it does.  If we're single-threaded, before we
> > writeIVar on it,
> > it "returns" bottom, but afterward it returns whatever what was written.
> >  It's
> > a little fuzzy, but that doesn't seem referentially transparent.
> >
> > Luke
> >
> > >   - Conal
> > >
> > > On Dec 8, 2007 11:12 AM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote:
> > > > many many answers, many guesses...
> > > > let's compare these semantics:
> > > >
> > > >
> > > > readIVar :: IVar a -> IO a
> > > > readIVar' :: IVar a -> a
> > > > readIVar' = unsafePerformIO . readIVar
> > > >
> > > > so, we do not need readIVar'. it could be a nice addition to the
> > > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > > > but the other way:
> > > >
> > > > readIVar v = return $ readIVar' v
> > > >
> > > > does not work. with this definition, readIVar itself does not block
> > > anymore. it's like hGetContents.
> > > > and...
> > > >
> > > > readIVar v = return $! readIVar' v
> > > >
> > > > evaluates too much:
> > > >  it wont work if the stored value evaluates to 1) undefined or 2)
> > _|_.
> > > >  it may even cause a 3) deadlock:
> > > >
> > > > do
> > > >  writeIVar v (readIVar' w)
> > > >  x<-readIVar v
> > > >  writeIVar w "cat"
> > > >  return x :: IO String
> > > >
> > > > readIVar should only return the 'reference'(internal pointer) to the
> > read
> > > object without evaluating it. in other words:
> > > > readIVar should wait to receive but not look into the received
> > "box"; it
> > > may contain a nasty undead werecat of some type. (Schrödinger's Law.)
> > > >
> > > > - marc
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> > > >
> > > >
> > > >
> > > > > Conal Elliott wrote:
> > > > > > Oh.  Simple enough.  Thanks.
> > > > > >
> > > > > > Another question:  why the IO in readIVar :: IVar a -> IO a,
> > instead
> > > > > > of just readIVar :: IVar a -> a?  After all, won't readIVar iv
> > yield
> > > > > > the same result (eventually) every time it's called?
> > > > > Because it won't necessarily yield the same result the next time
> > you run
> > > > > it.  This is the same reason the stuff in System.Environmentreturns
> > > > > values in IO.
> > > > >
> > > > > Paul.
> > > >
> > > >
> > > >
> > > > > ___
> > > > > Haskell mailing list
> > > > > [EMAIL PROTECTED]
> > > >
> > > > > http://www.haskell.org/mailman/listinfo/haskell
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > ___
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> > >
> >
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Lennart Augustsson]

Conal,

It's true that you can avoid using IO (except for a wrapper) for certain
kinds of programs.
For instance, if all you want is a String->String function, or some GUI
program (you forgot to mention fudgets, which was the first wrapper of this
kind) then you can ignore IO and just use a nice wrapper.

But if someone asks me how to traverse a directory tree, invoking the 'file'
program for each ',o' file and then renaming it if it's a text file, then
what should I answer?  "Sorry, you can't do that in Haskell."  or "You need
to use the IO monad."?
I prefer the latter answer, and I think people who learn Haskell need to
learn something about how you do some of the things that are easy in other
languages.

It's also important to teach people to stay away from IO whenever possible,
but it's simply not always possible.

  -- Lennart

On Dec 9, 2007 5:31 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

> > IO is important because you can't write any real program without using
> it.
>
> Ouch!  I get awfully discouraged when I read statements like this one.
> The more people who believe it, the more true it becomes.  If you want to do
> functional programming, instead of imperative programming in a functional
> language, you can.  For instance, write real, interactive programs in FRP,
> phooey, or TV.  And if you do, you'll get semantic simplicity, powerful &
> simpler reasoning, safety and composability.
>
>   - Conal
>
> On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
>
> > I agree with Dan here.
> >
> > IO is important because you can't write any real program without using
> > it.
> > So why not teach enough of it to get people off the ground straight
> > away?
> >
> > People who hang around long enough to do some more Haskell programming
> > will run into the other monads sooner or later.  But IO is an
> > unavoidable step to
> > writing Haskell programs.
> >
> >
> >
> >
> > On Dec 4, 2007 5:11 AM, Dan Piponi < [EMAIL PROTECTED]> wrote:
> >
> > > On Dec 3, 2007 6:36 PM, Ben Franksen < [EMAIL PROTECTED]> wrote:
> > > > then the special features of IO
> > > > will remain associated with monads in general, leading to a whole
> > > jumble of
> > > > completely wrong ideas about them.
> > >
> > > As I only learnt about monads a couple of years ago, the process is
> > > still fresh in my mind. I wasted quite a bit of time labouring under
> > > the impression that monads were primarily about sequencing. But that
> > > wasn't because I incorrectly generalised from IO. It was because
> > > countless people out there explicitly said they were about sequencing.
> > > I suspect that if courses started with the List monad there'd be
> > > countless blogs telling people that monads are a way to eliminate
> > > loops from your code like the way list comprehensions are used in
> > > Python.
> > >
> > > > This is yet another problem with IO as the standard example for
> > > monads: its
> > > > effect base is huge and poorly structured.
> > >
> > > You don't teach *all* of IO to students in one go!
> > >
> > > > This again makes it difficult to
> > > > see exactly which intuitions about IO can be generalized to
> > > arbitrary
> > > > monads and which not.
> > >
> > > That's true of any monad. IO is unique. [] is unique. Cont is unique.
> > > All of them can lead you down the garden path. You need to see
> > > multiple monads, and it helps if you can sneak an example under a
> > > student's nose so they can already reason about monads before they
> > > even know what a monad is.
> > >
> > > > What is pointless about failure and how to handle it?
> > >
> > > It's pointless when you're still trying to make your first tweaks to
> > > "Hello, World!" work.
> > > --
> > > Dan
> > > ___
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] IVars

[Conal Elliott]

Thanks, Luke.  I'd been unconsciously assuming that the IVar would get
written to (if ever) by a thread other than the one doing the reading.
(Even then, there could be a deadlock.)

  - Conal

On Dec 9, 2007 9:37 AM, Luke Palmer <[EMAIL PROTECTED]> wrote:

> On Dec 9, 2007 5:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> > (moving to haskell-cafe)
> >
> > > readIVar' :: IVar a -> a
> > > readIVar' = unsafePerformIO . readIVar
> >
> > > so, we do not need readIVar'. it could be a nice addition to the
> > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> >
> > The same argument applies any to pure function, doesn't it?  For
> instance, a
> > non-IO version of succ is unnecessary.  My question is why make readIVar
> a
> > blocking IO action rather than a blocking pure value, considering that
> it
> > always returns the same value?
>
> But I don't think it does.  If we're single-threaded, before we writeIVar
> on it,
> it "returns" bottom, but afterward it returns whatever what was written.
>  It's
> a little fuzzy, but that doesn't seem referentially transparent.
>
> Luke
>
> >   - Conal
> >
> > On Dec 8, 2007 11:12 AM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote:
> > > many many answers, many guesses...
> > > let's compare these semantics:
> > >
> > >
> > > readIVar :: IVar a -> IO a
> > > readIVar' :: IVar a -> a
> > > readIVar' = unsafePerformIO . readIVar
> > >
> > > so, we do not need readIVar'. it could be a nice addition to the
> > libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > > but the other way:
> > >
> > > readIVar v = return $ readIVar' v
> > >
> > > does not work. with this definition, readIVar itself does not block
> > anymore. it's like hGetContents.
> > > and...
> > >
> > > readIVar v = return $! readIVar' v
> > >
> > > evaluates too much:
> > >  it wont work if the stored value evaluates to 1) undefined or 2) _|_.
>
> > >  it may even cause a 3) deadlock:
> > >
> > > do
> > >  writeIVar v (readIVar' w)
> > >  x<-readIVar v
> > >  writeIVar w "cat"
> > >  return x :: IO String
> > >
> > > readIVar should only return the 'reference'(internal pointer) to the
> read
> > object without evaluating it. in other words:
> > > readIVar should wait to receive but not look into the received "box";
> it
> > may contain a nasty undead werecat of some type. (Schrödinger's Law.)
> > >
> > > - marc
> > >
> > >
> > >
> > >
> > >
> > > Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> > >
> > >
> > >
> > > > Conal Elliott wrote:
> > > > > Oh.  Simple enough.  Thanks.
> > > > >
> > > > > Another question:  why the IO in readIVar :: IVar a -> IO a,
> instead
> > > > > of just readIVar :: IVar a -> a?  After all, won't readIVar iv
> yield
> > > > > the same result (eventually) every time it's called?
> > > > Because it won't necessarily yield the same result the next time you
> run
> > > > it.  This is the same reason the stuff in System.Environment returns
> > > > values in IO.
> > > >
> > > > Paul.
> > >
> > >
> > >
> > > > ___
> > > > Haskell mailing list
> > > > [EMAIL PROTECTED]
> > >
> > > > http://www.haskell.org/mailman/listinfo/haskell
> > > >
> > >
> > >
> > >
> >
> >
> > ___
> > 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] Problem with Gtk2hs

[Felipe Lessa]

On Dec 8, 2007 6:33 PM, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> (Also, the documentation for Graphics.UI.Gtk.Misc.DrawingArea suggests
> that you may want to draw a Pixbuf using the pixbufRenderToDrawable
> function - but GHC complains that this function doesn't exist. I had to
> use drawPixbuf instead. Wow that has a lot of parameters... In
> particular, the final two don't seem to be documented. Interesting.
> They're both 0 in the "fastdraw" demo.)

Just for the record:
http://library.gnome.org/devel/gdk/unstable/gdk-Drawing-Primitives.html#gdk-draw-pixbuf

I have found that it's eventually useful to try to look at Gtk+
"official C" documentation when coding with a binding (not only with
Gtk2Hs, but also Gtk#, PyGtk, etc).

(Also, it seem the second argument should be "Maybe GC" as the C
documentation says it could be a NULL value.)

HTH,

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

[Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Conal Elliott]

On Dec 9, 2007 10:07 AM, Daniel Fischer <[EMAIL PROTECTED]> wrote:

> Interactive programmes without using IO? Cool :)

And how!

> I think you misunderstood Lennart.

Thanks for checking.  In this case, I think I understood Lennart fine and
that he was saying what you're saying.

> Would you deny that any useful programme has to do at least some of the
following:
> -accept programme arguments at invocation
> -get input, be it from a keyboard, mouse, reading files, pipes...
> -output a result or state info, to the monitor, a file, a pipe...
   ===

If by "programme", you mean the code I write, then I'm happy to deny that my
programme has to do these things.  Examples below.  If you include a
stateful RTS, then no I don't deny it.

> I think Lennart was referring to that, you HAVE to know a little IO to
write
> programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile,
> appendFile. And therefore some use of the IO monad has to be taught
> relatively early.

Explicit imperative programming is just one way to deal with input & output,
not the only way.  As proof, see FRP, Pan, or TV programs, which contain
uses of none of these functions.  (Nor could they, as these libraries are
functional, having IO-free types and semantics.)  Moreover, use of
imperative programming sacrifices some of the semantic simplicity &
composability that makes FP so appealing.  That's why I'd like to see this
belief in its necessity dispelled.

That said, I don't think the existing functional (non-IO) approaches to
interaction are quite there yet with the flexibility of imperative
programming.  It will take more work to get them there, and that work is
mostly likely to be pursued by people who doubt the necessity of IO for
writing "real programs".  In that sense, Lennart's and your statements are
self-fulfilling prophechies, as are mine.

BTW, if you haven't seen it already, please check out
http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
includes a simple algebra of interfaces (input/output) and keeps separable
from the core computation.  The separability allows the interface parts to
be composed in parallel with the core part.  For instance, when two
function-valued TVs are composed, the interfaces are peeled off, so that the
core functions can be composed directly.  The output half of one interface
and the matching input half of the other are discarded.  The remaining input
and output halves are recombined into a new interface, which is used as the
interface of the composed TV.  The core interface algebra can be used for
text stream i/o, GUIs, and many other possible styles of information
passing.

I mention TV, because it's an example of combining the purity &
composability I love about FP with the usability a "real" app.  For more
about this combination, please see my Google tech talk "Tangible Functional
Programming: a modern marriage of usability and composability" (
http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-modern.html).
That talk focus on end-user composability, but the essential points apply as
well to explicit programming.  As I mentioned before, TV (a) is currently
less flexible than imperative/IO programming, and (b) has the composability,
guaranteed safety, and amenability to reasoning of pure functional
programming.


Cheers,  - Conal



Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > > IO is important because you can't write any real program without using
> > > it.
> >
> > Ouch!  I get awfully discouraged when I read statements like this one.
>  The
> > more people who believe it, the more true it becomes.  If you want to do
> > functional programming, instead of imperative programming in a
> functional
> > language, you can.  For instance, write real, interactive programs in
> FRP,
> > phooey, or TV.  And if you do, you'll get semantic simplicity, powerful
> &
> > simpler reasoning, safety and composability.
> >
> >   - Conal
>
 > > On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED]>
wrote:

> > [...]

> > IO is important because you can't write any real program without using
it.
> > So why not teach enough of it to get people off the ground straight
away?

> > People who hang around long enough to do some more Haskell programming
> > will run into the other monads sooner or later.  But IO is an
unavoidable step to
> > writing Haskell programs.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ARM back end?

[Lennart Augustsson]

There's an ARM backend in hbc.

On Nov 2, 2007 8:30 PM, Greg Fitzgerald <[EMAIL PROTECTED]> wrote:

> Anybody know of an ARM back end for any of the Haskell compilers?
>
> Thanks,
> Greg
>
> ___
> 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] [OT] A nice organized collection of threads in Haskell-Cafe

[Albert Y. C. Lai]

Bryan O'Sullivan wrote:

Albert Y. C. Lai wrote:


I can't blame you for being not observant. Afterall, this is precisely
what I'm alluding to with "everyone can haz PC" [...]


Please don't flame people on the list.


I'm flaming an idea, not people on the list.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Daniel Fischer]

Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > IO is important because you can't write any real program without using
> > it.
>
> Ouch!  I get awfully discouraged when I read statements like this one.  The
> more people who believe it, the more true it becomes.  If you want to do
> functional programming, instead of imperative programming in a functional
> language, you can.  For instance, write real, interactive programs in FRP,
> phooey, or TV.  And if you do, you'll get semantic simplicity, powerful &
> simpler reasoning, safety and composability.
>
>   - Conal
>

Interactive programmes without using IO? Cool :)

I think you misunderstood Lennart. 
Would you deny that any useful programme has to do at least some of the 
following:
-accept programme arguments at invocation
-get input, be it from a keyboard, mouse, reading files, pipes...
-output a result or state info, to the monitor, a file, a pipe...

I think Lennart was referring to that, you HAVE to know a little IO to write 
programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, 
appendFile. And therefore some use of the IO monad has to be taught 
relatively early.

Another thing is that you should use IO only where it's necessary, which is 
admittedly rare.

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

Re: [Haskell-cafe] Re: [Haskell] IVars

[Luke Palmer]

On Dec 9, 2007 5:09 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
> (moving to haskell-cafe)
>
> > readIVar' :: IVar a -> a
> > readIVar' = unsafePerformIO . readIVar
>
> > so, we do not need readIVar'. it could be a nice addition to the
> libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
>
> The same argument applies any to pure function, doesn't it?  For instance, a
> non-IO version of succ is unnecessary.  My question is why make readIVar a
> blocking IO action rather than a blocking pure value, considering that it
> always returns the same value?

But I don't think it does.  If we're single-threaded, before we writeIVar on it,
it "returns" bottom, but afterward it returns whatever what was written.  It's
a little fuzzy, but that doesn't seem referentially transparent.

Luke

>   - Conal
>
> On Dec 8, 2007 11:12 AM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote:
> > many many answers, many guesses...
> > let's compare these semantics:
> >
> >
> > readIVar :: IVar a -> IO a
> > readIVar' :: IVar a -> a
> > readIVar' = unsafePerformIO . readIVar
> >
> > so, we do not need readIVar'. it could be a nice addition to the
> libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> > but the other way:
> >
> > readIVar v = return $ readIVar' v
> >
> > does not work. with this definition, readIVar itself does not block
> anymore. it's like hGetContents.
> > and...
> >
> > readIVar v = return $! readIVar' v
> >
> > evaluates too much:
> >  it wont work if the stored value evaluates to 1) undefined or 2) _|_.
> >  it may even cause a 3) deadlock:
> >
> > do
> >  writeIVar v (readIVar' w)
> >  x<-readIVar v
> >  writeIVar w "cat"
> >  return x :: IO String
> >
> > readIVar should only return the 'reference'(internal pointer) to the read
> object without evaluating it. in other words:
> > readIVar should wait to receive but not look into the received "box"; it
> may contain a nasty undead werecat of some type. (Schrödinger's Law.)
> >
> > - marc
> >
> >
> >
> >
> >
> > Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> >
> >
> >
> > > Conal Elliott wrote:
> > > > Oh.  Simple enough.  Thanks.
> > > >
> > > > Another question:  why the IO in readIVar :: IVar a -> IO a, instead
> > > > of just readIVar :: IVar a -> a?  After all, won't readIVar iv yield
> > > > the same result (eventually) every time it's called?
> > > Because it won't necessarily yield the same result the next time you run
> > > it.  This is the same reason the stuff in System.Environment returns
> > > values in IO.
> > >
> > > Paul.
> >
> >
> >
> > > ___
> > > Haskell mailing list
> > > [EMAIL PROTECTED]
> >
> > > http://www.haskell.org/mailman/listinfo/haskell
> > >
> >
> >
> >
>
>
> ___
> 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] ST Monad - what's wrong?

[Stefan O'Rear]

On Sun, Dec 09, 2007 at 12:11:42PM +0100, Nicu Ionita wrote:
> Hi,
> 
> I'm trying to use the ST monad in order to turn an almost pure function into
> a pure one: reading a precalculated list of primes into a prime set. But the
> following code brings an error:
> 
> > primes :: Set Integer
> > primes = runST $ getPrimes "primes10h7.txt"
> 
> > getPrimes :: String -> (forall s. ST s (Set Integer))
> > getPrimes file =
> > do cont <- unsafeIOToST (readFile file)
> >let set = fromList $ map read $ lines cont
> >return set
> 
> And here is the error:
> 
> Couldn't match expected type `forall s. ST s a'
> against inferred type `ST s (Set Integer)'
> In the second argument of `($)', namely
> `getPrimes "primes10h7.txt"'
> In the expression: runST $ (getPrimes "primes10h7.txt")
> In the definition of `primes':
> primes = runST $ (getPrimes "primes10h7.txt")

ST is far too big a hammer to use here.  It gives you safety you're not
using, at the cost of much more complicated typechecking.  I'd just use
unsafePerformIO.

Stefan


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

Re: [Haskell-cafe] IO is a bad example for Monads [was: do]

[Conal Elliott]

> IO is important because you can't write any real program without using it.

Ouch!  I get awfully discouraged when I read statements like this one.  The
more people who believe it, the more true it becomes.  If you want to do
functional programming, instead of imperative programming in a functional
language, you can.  For instance, write real, interactive programs in FRP,
phooey, or TV.  And if you do, you'll get semantic simplicity, powerful &
simpler reasoning, safety and composability.

  - Conal

On Dec 8, 2007 1:26 AM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:

> I agree with Dan here.
>
> IO is important because you can't write any real program without using it.
> So why not teach enough of it to get people off the ground straight away?
>
> People who hang around long enough to do some more Haskell programming
> will run into the other monads sooner or later.  But IO is an unavoidable
> step to
> writing Haskell programs.
>
>
>
>
> On Dec 4, 2007 5:11 AM, Dan Piponi < [EMAIL PROTECTED]> wrote:
>
> > On Dec 3, 2007 6:36 PM, Ben Franksen < [EMAIL PROTECTED]> wrote:
> > > then the special features of IO
> > > will remain associated with monads in general, leading to a whole
> > jumble of
> > > completely wrong ideas about them.
> >
> > As I only learnt about monads a couple of years ago, the process is
> > still fresh in my mind. I wasted quite a bit of time labouring under
> > the impression that monads were primarily about sequencing. But that
> > wasn't because I incorrectly generalised from IO. It was because
> > countless people out there explicitly said they were about sequencing.
> > I suspect that if courses started with the List monad there'd be
> > countless blogs telling people that monads are a way to eliminate
> > loops from your code like the way list comprehensions are used in
> > Python.
> >
> > > This is yet another problem with IO as the standard example for
> > monads: its
> > > effect base is huge and poorly structured.
> >
> > You don't teach *all* of IO to students in one go!
> >
> > > This again makes it difficult to
> > > see exactly which intuitions about IO can be generalized to arbitrary
> > > monads and which not.
> >
> > That's true of any monad. IO is unique. [] is unique. Cont is unique.
> > All of them can lead you down the garden path. You need to see
> > multiple monads, and it helps if you can sneak an example under a
> > student's nose so they can already reason about monads before they
> > even know what a monad is.
> >
> > > What is pointless about failure and how to handle it?
> >
> > It's pointless when you're still trying to make your first tweaks to
> > "Hello, World!" work.
> > --
> > Dan
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] IVars

[Conal Elliott]

(moving to haskell-cafe)

> readIVar' :: IVar a -> a
> readIVar' = unsafePerformIO . readIVar

> so, we do not need readIVar'. it could be a nice addition to the
libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".

The same argument applies any to pure function, doesn't it?  For instance, a
non-IO version of succ is unnecessary.  My question is why make readIVar a
blocking IO action rather than a blocking pure value, considering that it
always returns the same value?

  - Conal

On Dec 8, 2007 11:12 AM, Marc A. Ziegert <[EMAIL PROTECTED]> wrote:

> many many answers, many guesses...
> let's compare these semantics:
>
> readIVar :: IVar a -> IO a
> readIVar' :: IVar a -> a
> readIVar' = unsafePerformIO . readIVar
>
> so, we do not need readIVar'. it could be a nice addition to the
> libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
> but the other way:
>
> readIVar v = return $ readIVar' v
>
> does not work. with this definition, readIVar itself does not block
> anymore. it's like hGetContents.
> and...
>
> readIVar v = return $! readIVar' v
>
> evaluates too much:
>  it wont work if the stored value evaluates to 1) undefined or 2) _|_.
>  it may even cause a 3) deadlock:
>
> do
>  writeIVar v (readIVar' w)
>  x<-readIVar v
>  writeIVar w "cat"
>  return x :: IO String
>
> readIVar should only return the 'reference'(internal pointer) to the read
> object without evaluating it. in other words:
> readIVar should wait to receive but not look into the received "box"; it
> may contain a nasty undead werecat of some type. (Schrödinger's Law.)
>
> - marc
>
>
>
>
>
> Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> > Conal Elliott wrote:
> > > Oh.  Simple enough.  Thanks.
> > >
> > > Another question:  why the IO in readIVar :: IVar a -> IO a, instead
> > > of just readIVar :: IVar a -> a?  After all, won't readIVar iv yield
> > > the same result (eventually) every time it's called?
> > Because it won't necessarily yield the same result the next time you run
> > it.  This is the same reason the stuff in System.Environment returns
> > values in IO.
> >
> > Paul.
> > ___
> > Haskell mailing list
> > [EMAIL PROTECTED]
> > http://www.haskell.org/mailman/listinfo/haskell
> >
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: distinguish functions from non-functions in a class/instances

[Jonathan Cast]

On 7 Dec 2007, at 12:39 PM, Dan Weston wrote:


Luke Palmer wrote:

On Dec 7, 2007 7:57 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:

On Dec 7, 2007 7:41 PM, Dan Weston <[EMAIL PROTECTED]> wrote:

Luke Palmer wrote:

You can project the compile time numbers into runtime ones:
Yes, that works well if I know a priori what the arity of the  
function
is. But I want to be able to have the compiler deduce the arity  
of the
function (e.g. by applying undefined until it is no longer a  
function),

precisely so I don't have to supply it myself.

Function arity is (I think) something already known to GHC, so I  
don't

know why we can't get at it too.

No, it is not.  Consider:

compose f g x = f (g x)

What is the arity of f?

Oh, you're saying at run-time, given an object.


No, at compile time. Type is static.


What about a type that contains lexical type variables?

For that matter, what about a type that ends in a type variable, e.g.

head :: [a] -> a

Is the arity of

head (x:xn) = x

Different from that of

head' :: [a -> b] -> a -> b
head' (x:xn) = x

?

jcc

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

Re: [Haskell-cafe] ARM back end?

[Andreas Farre]

On Mon, 03 Dec 2007 18:24:10 +0100, Mathieu Boespflug <[EMAIL PROTECTED]>  
wrote:



On Nov 2, 2007 10:19 PM, nornagon <[EMAIL PROTECTED]> wrote:

On 03/11/2007, Greg Fitzgerald <[EMAIL PROTECTED]> wrote:
> Anybody know of an ARM back end for any of the Haskell compilers?
>

If there's an arm-eabi port somewhere, I might be able to get Haskell
code running on the Nintendo DS...


https://garage.maemo.org/projects/hugs/

Runs on my Nokia N800 which is arm-eabi based.

Mathieu


The DS is a bit peckish, but I did get hugs to run on it with devkitPro. I  
wrote about my experiences at my blog: www.closuretohome.com.


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

Re: [Haskell-cafe] ST Monad - what's wrong?

[Alfonso Acosta]

> True. However, note that the release notes of 6.8.1 encourage not to
> rely in this "new feature" because it can change in the feature.
>

I obviously meant in the future, sorry.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ST Monad - what's wrong?

[Alfonso Acosta]

On Dec 9, 2007 2:39 PM, pepe <[EMAIL PROTECTED]> wrote:
> The typechecker in 6.6.1 gets confused by the ($) and loses track of
> the 'freeness' of s (the thread variable) . The same code should work
> fine in 6.8.1, or alternatively in 6.6.1 without the ($).

True. However, note that the release notes of 6.8.1 encourage not to
rely in this "new feature" because it can change in the feature.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ST Monad - what's wrong?

[pepe]

The typechecker in 6.6.1 gets confused by the ($) and loses track of  
the 'freeness' of s (the thread variable) . The same code should work  
fine in 6.8.1, or alternatively in 6.6.1 without the ($).


Cheers
pepe


On 09/12/2007, at 12:11, Nicu Ionita wrote:


Hi,

I'm trying to use the ST monad in order to turn an almost pure  
function into
a pure one: reading a precalculated list of primes into a prime set.  
But the

following code brings an error:


primes :: Set Integer
primes = runST $ getPrimes "primes10h7.txt"



getPrimes :: String -> (forall s. ST s (Set Integer))
getPrimes file =
   do cont <- unsafeIOToST (readFile file)
  let set = fromList $ map read $ lines cont
  return set


And here is the error:

Couldn't match expected type `forall s. ST s a'
against inferred type `ST s (Set Integer)'
In the second argument of `($)', namely
`getPrimes "primes10h7.txt"'
In the expression: runST $ (getPrimes "primes10h7.txt")
In the definition of `primes':
primes = runST $ (getPrimes "primes10h7.txt")

Compiled with GHC 6.6.1 with extensions activated.

Nicu

___
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] Problem with Gtk2hs

[Andrew Coppin]

Stefan O'Rear wrote:

On Sat, Dec 08, 2007 at 08:33:36PM +, Andrew Coppin wrote:
  
I just spent the evening writing a library that's a thin layer over Gtk2hs. 
It took an age to get it to compile, but eventually it worked. Yay!


When I ran it, I got this:

Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor 
default method for class operation Data.Array.Base.getNumElements


Er... wow.

OK, at this point, I am completely stumped. Any hints?



That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't
fully implement the (M)Array class.
  


Well OK, but... how come nobody else has tripped over this before?

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

[Haskell-cafe] AW: ST Monad - what's wrong?

[Nicu Ionita]

Ok, solved, the use of ($) was the problem.

I changed it

> primes :: Set Integer
> primes = runST (getPrimes "primes10h7.txt")

and it compiles (and works too).

Nicu


> -Ursprüngliche Nachricht-
> Von: Nicu Ionita [mailto:[EMAIL PROTECTED] 
> Gesendet: Sonntag, 9. Dezember 2007 12:12
> An: 'haskell-cafe@haskell.org'
> Betreff: ST Monad - what's wrong?
> 
> 
> Hi,
> 
> I'm trying to use the ST monad in order to turn an almost 
> pure function into a pure one: reading a precalculated list 
> of primes into a prime set. But the following code brings an error:
> 
> > primes :: Set Integer
> > primes = runST $ getPrimes "primes10h7.txt"
> 
> > getPrimes :: String -> (forall s. ST s (Set Integer)) 
> getPrimes file =
> > do cont <- unsafeIOToST (readFile file)
> >let set = fromList $ map read $ lines cont
> >return set
> 
> And here is the error:
> 
> Couldn't match expected type `forall s. ST s a'
> against inferred type `ST s (Set Integer)'
> In the second argument of `($)', namely
> `getPrimes "primes10h7.txt"'
> In the expression: runST $ (getPrimes "primes10h7.txt")
> In the definition of `primes':
> primes = runST $ (getPrimes "primes10h7.txt")
> 
> Compiled with GHC 6.6.1 with extensions activated.
> 
> Nicu
> 

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

[Haskell-cafe] ST Monad - what's wrong?

[Nicu Ionita]

Hi,

I'm trying to use the ST monad in order to turn an almost pure function into
a pure one: reading a precalculated list of primes into a prime set. But the
following code brings an error:

> primes :: Set Integer
> primes = runST $ getPrimes "primes10h7.txt"

> getPrimes :: String -> (forall s. ST s (Set Integer))
> getPrimes file =
> do cont <- unsafeIOToST (readFile file)
>let set = fromList $ map read $ lines cont
>return set

And here is the error:

Couldn't match expected type `forall s. ST s a'
against inferred type `ST s (Set Integer)'
In the second argument of `($)', namely
`getPrimes "primes10h7.txt"'
In the expression: runST $ (getPrimes "primes10h7.txt")
In the definition of `primes':
primes = runST $ (getPrimes "primes10h7.txt")

Compiled with GHC 6.6.1 with extensions activated.

Nicu

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

[Haskell-cafe] parsebinaryoperations

[Ryan Bloor]

hi
 
I have a function parseInt... which needs an error guard for when the input is 
not an Int.
 
parseInt :: ParserparseInt [] = []parseInt xs = let (digits, rest) = span 
isDigit (removeSpace xs)in [(EInt (read digits), removeSpace 
rest)]
 
Also... I have a function that does this... parseBinaryOp "+" "(5 + 2) if"  
gives...[(Int 5, Int 2, "if")]
so, op is '+' or "&&". I am unsure of how to begin... 
 
parseBinaryOp :: String -> String -> [(Expr, Expr, String)]parseBinaryOp op str
 
Thankyou
 
Ryan
_
Celeb spotting – Play CelebMashup and win cool prizes
https://www.celebmashup.com___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe