Re: [Haskell-cafe] Re: Haskell tutorial for pseudo users?

[Jonathan Cast]

On Fri, 2009-02-06 at 08:30 +0100, Achim Schneider wrote:
> Jonathan Cast  wrote:
> > On Mon, 2009-02-02 at 20:55 +, Andrew Coppin wrote:
> > > Deniz Dogan wrote:
> > > > Learn You a Haskell for Great Good (http://learnyouahaskell.com/)
> > > 
> > > Mmm, interesting.
> > > 
> > > Does anybody else think it would be neat if GHCi really did
> > > colourise your input like that?
> > 
> > Bleah.  More terminal hacking to break and/or slow Emacs to a crawl?
> > No thanks.
> > 
> A while ago, I'd say that emacs looks like a decent operating system,
> sadly lacking a decent editor.

I always wonder how many people who say that have actually *tried*
Emacs' editor.

> Now it seems that it's even lacking a
> decent terminal.

Actually, I think the issue is just that Emacs' ANSI color parsing code
is effectively O(n^2); when I really, really need colored output I run
the command in a separate window (with B&W output) and switch major
modes.

Emacs' terminal is also lacking all the modern conveniences, like
addressable cursors and builtin line-editing designed for 1970s printing
terminals and practically no searching capabilities.  Alternatively, you
could say it's incompatible with modern Unix's biggest mistakes and
worst legacy issues.

> I'm really not sure what to make of all that: Would
> you recommend using it?

Of course.  It sucks the least of any solution I've tried.  Barely.

> Eternal flamewars cast aside, what about integrating such a thing into
> yi? Yi has the advantage of working for both masochists _and_ efficient
> typists.

Yi has a terminal?  Maybe I should try it again.

jcc


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

[Haskell-cafe] Re: Haskell tutorial for pseudo users?

[Achim Schneider]

Jonathan Cast  wrote:

> On Mon, 2009-02-02 at 20:55 +, Andrew Coppin wrote:
> > Deniz Dogan wrote:
> > > Learn You a Haskell for Great Good (http://learnyouahaskell.com/)
> > 
> > Mmm, interesting.
> > 
> > Does anybody else think it would be neat if GHCi really did
> > colourise your input like that?
> 
> Bleah.  More terminal hacking to break and/or slow Emacs to a crawl?
> No thanks.
> 
A while ago, I'd say that emacs looks like a decent operating system,
sadly lacking a decent editor. Now it seems that it's even lacking a
decent terminal. I'm really not sure what to make of all that: Would
you recommend using it?

Eternal flamewars cast aside, what about integrating such a thing into
yi? Yi has the advantage of working for both masochists _and_ efficient
typists.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] Re: Just how unsafe is unsafe

[Achim Schneider]

Peter Verswyvelen  wrote:

> I do have asked myself the question whether a "really random
> generating" function could be regarded as "pure" somehow (actually
> would a true random function still be a mathematical function?)
>
Wasn't there some agreement some time ago on this list that the
universe itself is pure and computers are just simulating impurity by
being, essentially, state monads on steroids?

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe

[Thomas Davie]

On 5 Feb 2009, at 22:11, Andrew Wagner wrote:

So we all know the age-old rule of thumb, that unsafeXXX is simply  
evil and anybody that uses it should be shot (except when it's ok).


I understand that unsafeXXX allows impurity, which defiles our  
ability to reason logically about haskell programs like we would  
like to. My question is, to what extent is this true?


Suppose we had a module, UnsafeRandoms, which had a function that  
would allow you to generate a different random number every time you  
call it. The semantics are relatively well-defined, impurity is  
safely sectioned off in its own impure module, which is clearly  
labeled as such. How much damage does this do?


The problem here is composability – you have no idea how far your non  
referentially transparent code has spread, because you can compose  
functions together willy nilly, meaning your random numbers can get  
pushed through all sorts of things, and cause odd behaviors (e.g. if a  
constant happens to get evaluated twice rather than once, and return  
different values each time).


Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe  
modules a useful idiom that we can use for other things as well?


Well not useful modules, but useful types instead.  The point of IO  
for example is to deliberately construct an environment in which you  
can't get one of your unsafe values out into the referentially  
transparent world – the IO type denotes the line on which one side  
contains unsafe values, and the other side does not.


There are however some instances where unsafe functions *are* safe,  
Conal's unamb function for example, always returns the same value (as  
long as its precondition is met), even though it contains IO based  
code to race the values.


There are also some instances where unsafe functions are safe purely  
through force of will.  For example:


type ResourcePath = FilePath

loadImageResource :: ResourcePath -> Image
loadImageResource = unsafePerformIO . loadImage =<< readFile

This is safe iff you treat the resource as a part of your program,  
just like your program's code, if it changes, the world falls down,  
but as long as it's still there and still the same, you're entirely  
safe.


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

Re: [Haskell-cafe] morphisms in IO

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 10:32 PM, Dan Weston  wrote:
> I truly have no idea what you are saying (and probably not even what I am
> saying), but I suspect:
>
> a) You are calling IO the target category of applying the functor IO [taking
> a to IO a and (a->b) to (IO a -> IO b)] to Hask.
>
> b) This category is hardly bereft, nor discrete. Its morphisms are IO a ->
> IO b.

Well, that's a function in Haskell, yes; but does it represent a
morphism /in/ the category?  It looks more like a Functor morphism to
me.
>
> c) What you are calling a "bereft" category is an empty category. Without
> (identity) morphisms, there can be no objects. There is only one such

Right, I meant other than Id morphisms.  I guess "discrete" is the correct term.

> category (the empty category), so naturally any two such are isomorphic (for
> what it's worth, which I suspect is not much).

Thanks,

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

Re: [Haskell-cafe] morphisms in IO

[Miguel Mitrofanov]

On 6 Feb 2009, at 05:52, Gregg Reynolds wrote:


I'm working on a radically different way of looking at IO.  Before I
post it and make a fool of myself, I'd appreciate a reality check on
the following points:

a)  Can IO be thought of as a category?  I think the answer is yes.


What couldn't? Everything could be thought of as category, linear  
space, graph or matroid - you'll need some intellectual efforts for  
that, but it certainly could be done.



b)  If it is a category, what are its morphisms?  I think the answer
is: it has no morphisms.


Oops. Than it's empty. In a category, every object has at least an  
identity morphism.



c)  All categories with no morphisms ("bereft categories"?) are
isomorphic (to each other).  I think yes.


Yes, all empty categories are isomorphic.

No, categories with identity morphisms only are not isomorphic in  
general.


Yes, all categories with no morphisms except identities are equivalent.

No, such categories are not very useful and there is no need to apply  
categorical language to them - thinking in terms of set (class) of  
objects would be easier.

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

Re: [Haskell-cafe] Automation and COM

[Michael Snoyman]

On Wed, Feb 4, 2009 at 3:55 AM, Günther Schmidt  wrote:

> Hi,
>
> has anyone yet been using Sigbjorns COM package?
>
> Sigbjorn hasn't had the time yet to gather some docs on how to use it, so I
> wonder if someone else could post some examples on how to use it. I'm asking
> because I need to do some COM stuff with excel, which I know how to do in
> another language, but can't seem to get it even started with haskell.
>
> Any help appreciated.
>

I just used the package for a project at work. Unfortunately, due to the
nature of the project I can't post the code here. I'll try to work up a
contrived example to demonstrate how to use it a bit, but e-mail me if you
have any direct questions. I won't claim to be an expert, but I was able to
pass some SAFEARRAYs to methods and such.

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

Re: [Haskell-cafe] Happstack 0.1 Released!

[Michael Snoyman]

On Thu, Feb 5, 2009 at 4:58 PM, Don Stewart  wrote:

>
> A comparative analysis of the 10+ Haskell web frameworks would be
> awesome.
>
> happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia,
> kibro, ella, what was that one launched yesterday? *ah, yesod...
>

Wow, that's a lot more frameworks than I realized...

Anyway, I'm the guy who just started that new one, yesod. I don't think it's
a good thing that there are so many of these unfinished web frameworks out
there, and starting more is probably not that helpful. I did so because, as
far as I can tell, none of the other frameworks out there are even remotely
interested in the same goals as me.

Happs(tack) seems to have thrown all convention about web frameworks out the
window, which is fine, but not exactly usable in many conventional
scenarios. Wash, fastcgi, and kibro all seem very low-level to me. Wash and
fastcgi seem to correlate pretty well to ASP and FCGI.pm to me, which
frankly don't provide much more than basic help in creating web sites.

Turbinado seems to be the closest to what I would imagine as a mainstream
framework. However, it is ignoring some features currently that I consider
vital (correct me if I'm wrong):

* Can run on a shared host. This means something like FastCGI, not its own
server.
* It's not aiming for any high-level Javascript/AJAX integration. I frankly
think the generating plain HTML on the backend style is a little outdated at
this point, and think we need to start exploring more advanced web
development techniques.

That said, if there's an existing web framework that has any interest in
those two goals, I'd be happy to contribute to that instead of fracturing
the community any more. It would be great if we could get some serious
support behind a single framework. Obviously, I have more opinions than the
two I just listed (I previously linked to a 14-point blog entry on the
subject), but the others I would be willing to forego to achieve unity.

Anyway, that's my plea. Sorry if it hijacked this thread too much.

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

Re: [Haskell-cafe] morphisms in IO

[Dan Weston]

I truly have no idea what you are saying (and probably not even what I 
am saying), but I suspect:


a) You are calling IO the target category of applying the functor IO 
[taking a to IO a and (a->b) to (IO a -> IO b)] to Hask.


b) This category is hardly bereft, nor discrete. Its morphisms are IO a 
-> IO b. Maybe you are thinking that it becomes an empty category after 
some fixed point process where you strip off the IO with repeated joins 
(or runIOs)? Remember there can be arbitrarily many nestings of IO, so 
that main :: IO (IO (IO Int)) is (a program that when run returns)^3 an 
Int. This is a stream with no finite least fixed point.


c) What you are calling a "bereft" category is an empty category. 
Without (identity) morphisms, there can be no objects. There is only one 
such category (the empty category), so naturally any two such are 
isomorphic (for what it's worth, which I suspect is not much).


Dan

Gregg Reynolds wrote:

I'm working on a radically different way of looking at IO.  Before I
post it and make a fool of myself, I'd appreciate a reality check on
the following points:

a)  Can IO be thought of as a category?  I think the answer is yes.

b)  If it is a category, what are its morphisms?  I think the answer
is: it has no morphisms.  The morphisms available are natural
transformations or functors, and thus not /in/ the category.
Alternatively: we have no means of directly naming its values, so the
only way we can operate on its values is to use morphisms from the
outside (operating on construction expressions qua morphisms.)

c)  All categories with no morphisms ("bereft categories"?) are
isomorphic (to each other).  I think yes.

Thanks,

gregg
___
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: evaluation semantics of bind

[wren ng thornton]

Gregg Reynolds wrote:

On Thu, Feb 5, 2009 at 7:19 PM, wren ng thornton  wrote:

Gregg Reynolds wrote:



as the formal semantics of the language are concerned, there's no
essential difference between  "getChar >>= \x -> getChar" and " Foo 3

= \x -> Foo 7 " for some data constructor Foo.  I should think the

latter would be optimized; if so, why not the former?  The presence of
some hidden (from me, anyway) semantics is inescapable.

There's no reason to assume the latter would be "optimized" either.
Consider:

   > data NotIO a = NotIO String a
   >
   > instance Monad NotIO where
   > return x  = NotIO "" x
   > (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x)
   >
   > notGetChar = NotIO "foo" 'a'

Let's consider your example:

   notGetChar >>= \x -> notGetChar
 ==
   (NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a')
 ==
   (\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a')
 ==
   (\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a')
 ==
   NotIO ("foo"++"foo") 'a'



You've defined >>= in such a way that it carries additional semantic
weight.  My example doesn't do that.


Yes, is does. Every bind operator does so (trivially for the Identity 
monad). What else would bind be "augmented" with if it's "augmented 
application"? Augmentation means to add structure. Bind does not "apply 
f to x", x is a monadic value which carries additional structure. What 
bind does is map f over x's structure and then calls join to collapse 
the monadic layers from the result.




If it doesn't then it amounts to ordinary
function application, which can be optimized out.  That's the point of
my example: data constructors don't munge their arguments, and getChar
is essentially a data constructor.


Data constructors in general are not monads.

To the extent that your Foo example is well typed it is isomorphic to 
the Identity monad. In which case your Foo x >>= f is exactly return x 
>>= f which the monad laws require to equal f x. Just because the 
Identity monad is trivial does not mean that bind is trivial. That's 
like saying that addition must do nothing because of it's behavior on 0.




> NotIO has a Chars for "side effects". IO is a perfectly fine mathematical
> object, the only difference is that it is appending sequences of an abstract

Gotcha!  "appending sequences" is not something mathematical values
are inclined to do.  They neither spin nor toil, let alone append.


Balderdash.



The dominant idiom - "IO values are actions" just doesn't work if you
want formal semantics, no matter how useful it may be pedagogically.


IO values are absolutely not actions, that's the whole point. Actions, 
such as they exist at all, are merely a domain over which we've 
constructed a monoid. The semantics from this are minimal, but if you'd 
like to define the domain more precisely there are many people who would 
be grateful for your contribution to research on effect systems and the 
ontology of computational effects on reality.




> The only way we can optimize away one of the calls to notGetChar (or any
> other monadic function) is if we can guarantee that no other computation
> will use either the monoidal values or the "contained" values associated
> with it. IO is defined with a bind operator that's strict in the monoidal
> value, which means we can never remove things (unless, perhaps, we can

Ok; but where does it say that in the language definition?  I
understand how it all works, but that comes from the many informal
narrative expositions; my point is that if you tried to write a formal
semantics for Haskell, a la ML, you couldn't do it without coming up
with a different story for IO.


It says that in the function definitions for bind and return on the IO 
type. In GHC the IO type is defined such that it's a specialized version 
of the State monad where RealWorld is the type of the state it carries. 
You can look in the source code that defines IO if you care. Other 
compilers may choose a different implementation for IO which has the 
same observational behavior in which case their "story" will be 
different. IO is an abstract type which is defined only by its 
observational behavior. One aspect of this behavior is that it is a 
monad and is not the Identity monad. Everything else follows.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] morphisms in IO

[Gregg Reynolds]

I'm working on a radically different way of looking at IO.  Before I
post it and make a fool of myself, I'd appreciate a reality check on
the following points:

a)  Can IO be thought of as a category?  I think the answer is yes.

b)  If it is a category, what are its morphisms?  I think the answer
is: it has no morphisms.  The morphisms available are natural
transformations or functors, and thus not /in/ the category.
Alternatively: we have no means of directly naming its values, so the
only way we can operate on its values is to use morphisms from the
outside (operating on construction expressions qua morphisms.)

c)  All categories with no morphisms ("bereft categories"?) are
isomorphic (to each other).  I think yes.

Thanks,

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 7:19 PM, wren ng thornton  wrote:
> Gregg Reynolds wrote:

>> as the formal semantics of the language are concerned, there's no
>> essential difference between  "getChar >>= \x -> getChar" and " Foo 3

 = \x -> Foo 7 " for some data constructor Foo.  I should think the
>>
>> latter would be optimized; if so, why not the former?  The presence of
>> some hidden (from me, anyway) semantics is inescapable.
>
> There's no reason to assume the latter would be "optimized" either.
> Consider:
>
>> data NotIO a = NotIO String a
>>
>> instance Monad NotIO where
>> return x  = NotIO "" x
>> (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x)
>>
>> notGetChar = NotIO "foo" 'a'
>
> Let's consider your example:
>
>notGetChar >>= \x -> notGetChar
>  ==
>(NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a')
>  ==
>(\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a')
>  ==
>(\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a')
>  ==
>NotIO ("foo"++"foo") 'a'
>

You've defined >>= in such a way that it carries additional semantic
weight.  My example doesn't do that.  Bind can be thought of as an
"augmented application" operator: x >>= f applies f to x, but it may
fiddle with x first.  If it doesn't then it amounts to ordinary
function application, which can be optimized out.  That's the point of
my example: data constructors don't munge their arguments, and getChar
is essentially a data constructor.

> NotIO has a Chars for "side effects". IO is a perfectly fine mathematical
> object, the only difference is that it is appending sequences of an abstract

Gotcha!  "appending sequences" is not something mathematical values
are inclined to do.  They neither spin nor toil, let alone append.
The dominant idiom - "IO values are actions" just doesn't work if you
want formal semantics, no matter how useful it may be pedagogically.
>
> The only way we can optimize away one of the calls to notGetChar (or any
> other monadic function) is if we can guarantee that no other computation
> will use either the monoidal values or the "contained" values associated
> with it. IO is defined with a bind operator that's strict in the monoidal
> value, which means we can never remove things (unless, perhaps, we can

Ok; but where does it say that in the language definition?  I
understand how it all works, but that comes from the many informal
narrative expositions; my point is that if you tried to write a formal
semantics for Haskell, a la ML, you couldn't do it without coming up
with a different story for IO.

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

Re: [Haskell-cafe] Happstack 0.1 Released!

[Creighton Hogg]

On Thu, Feb 5, 2009 at 6:58 PM, Don Stewart  wrote:
> andrewcoppin:
>> Jochem Berndsen wrote:
>>> The HAppS project has been abandoned, see
>>> http://groups.google.com/group/HAppS/msg/d128331e213c1031 .
>>>
>>> The Happstack project is intended to continue development. For more
>>> details, see http://happstack.com/faq.html .
>>>
>>>
>> So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does
>> anybody know how all these relate to each other? Where their strengths
>> and weaknesses lie?
>>
>> It's nice to have choice, but without knowing what you're choosing
>> between, it's hard to use it well.
>>
>
> A comparative analysis of the 10+ Haskell web frameworks would be
> awesome.
>
> happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia,
> kibro, ella, what was that one launched yesterday? *ah, yesod...

That's a lot of frameworks to try & compare and I don't think any one
person would have the time to do more than a couple, but perhaps we
could all agree on some kind of non-trivial, but still simple,
application that we could implement & deploy in the most natural way
for each framework.  It'd probably be easy to just point prospective
framework users to the resulting series of blog posts elucidating the
features of each.

I'd vote for something like a trimmed down reddit clone, something
that I'd expect everyone could do whether they deploy it via Apache or
something that's part of the framework such as happstack-server.

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

Re: [Haskell-cafe] Switching from Mercurial to Darcs

[wren ng thornton]

Roman Cheplyaka wrote:

* Peter Verswyvelen  [2009-02-05 16:35:34+0100]

On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde  wrote:


Peter Verswyvelen  writes:


1) hg st

 darcs cha -s


That seems to list all changes in the history.

hg st lists local changes only. Can be done using darcs?


darcs whatsnew -s


Or `darcs w -s` if you're really adverse to spelling things out ;)

The changes command gives the whole history (to varying depth, 
verbosity,...), whereas the whatsnew command gives what things have been 
altered but not recorded yet. The -s flag to whatsnew says to give a 
summary (names of files and count of lines changed). If you leave -s 
off, then you'll get textual diffs of same.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Bind as a sequencing operator

[mail]

Jake McArthur  writes:
> | Just because the compiler is allowed (and even encouraged) to change the
> | sequence where that won't change the results, considering this a
> | sequence is still valid and meaningful.
>
> It can be helpful sometimes, but I don't think it should be the standard
> way to think of bind. There are too many cases when it makes little
> sense as a sequencing operator.
>

Fair enough, thanks for your thoughts!

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

Re: [Haskell-cafe] Purely funcional LU decomposition

[wren ng thornton]

Rafael Gustavo da Cunha Pereira Pinto wrote:

What I miss most is a data structure with O(1) (amortized) direct access.


Finger trees get close, O(log(min(i,n-i))):


http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html

(And Theta(1) amortized for all dequeue operations to boot.)



One of the changes I thought today was to remove the ++ operator and create
a list of lists that I would concat in the last call.


Don't do it manually, let an abstract type do the optimization for you. 
This idea[1] is often known as "difference lists", which the estimable 
Don Stewart has already packaged up for us:


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

:)

[1] Actually, not quite that idea. The idea instead is to represent a 
list as a function [a]->[a] and then compose these functions (rather 
than concatenating the strings). At the very end once you're done, pass 
in [] and get back the whole list in O(n) time, rather than the O(n^2) 
that commonly arises from using (++).


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: evaluation semantics of bind

[ChrisK]

Jonathan Cast wrote:

On Fri, 2009-02-06 at 00:51 +0100, Peter Verswyvelen wrote:

On Thu, Feb 5, 2009 at 8:20 PM, ChrisK 
wrote:
Since this is strict there is no laziness and the code must
evaluate the input and output "State RealWorld" to ensure they
are not bottom or error.



Interesting. I also thought it was the passing of the RealWorld that
caused the sequencing, I never realized that the strictness played an
important role here. 



So what would happen if it would be lazy instead of strict? What kind
of craziness would occur?


The order of side effects would be demand-driven, rather than
order-of-statement driven.  So if I said:

[snip]

Essentially, the program would act as if every statement was wrapped up
in an unsafeInterleaveIO.

jcc


I do not think so.  Consider 
http://darcs.haskell.org/packages/base/GHC/IOBase.lhs to see unsafeInterleaveIO:



unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m)
unsafeDupableInterleaveIO (IO m)
  = IO ( \ s -> let
   r = case m s of (# _, res #) -> res
in
(# s, r #))


And Control.Monad.State.Lazy which is the non-strict State monad:


newtype State s a = State { runState :: s -> (a, s) }



instance Monad (State s) where
return a = State $ \s -> (a, s)
m >>= k  = State $ \s -> let
(a, s') = runState m s
in runState (k a) s'


And you can see that the data dependence is broken in unsafeInterleaveIO by _, 
and not broken in State.Lazy.  But neither s nor s' are not forced to WHNF.


What you can do State.Lazy is put an bottom into the state.  Or you can put an 
unevaluated thunk into the state, and if it gets replaced later then you never 
paid to evaluate it.


But the sequencing is retained.  One could make an unsafeInterleaveIO for state:


interleaveState :: State s a -> State s a
interleaveState (State m) = State ( \ s -> let (a,_) = runState m s
   in (a,s) )


Now the dependency chain is broken in the above, due to the _ being ignored.

Cheers,
  Chris

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[wren ng thornton]

Gregg Reynolds wrote:

Right, but that's only because the compiler either somehow knows about
side effects or there is some other mechanism - e.g. an implicit World
token that gets passed around - that prevents optiimization.  As far
as the formal semantics of the language are concerned, there's no
essential difference between  "getChar >>= \x -> getChar" and " Foo 3

= \x -> Foo 7 " for some data constructor Foo.  I should think the

latter would be optimized; if so, why not the former?  The presence of
some hidden (from me, anyway) semantics is inescapable.


There's no reason to assume the latter would be "optimized" either. 
Consider:


> data NotIO a = NotIO String a
>
> instance Monad NotIO where
> return x  = NotIO "" x
> (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x)
>
> notGetChar = NotIO "foo" 'a'

Let's consider your example:

notGetChar >>= \x -> notGetChar
  ==
(NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a')
  ==
(\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a')
  ==
(\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a')
  ==
NotIO ("foo"++"foo") 'a'

It's clear to see that this result is not equal to notGetChar. And the 
compiler needn't know anything special about NotIO to realize that. 
There's nothing special about IO. The only difference between NotIO and 
IO is that NotIO has a Chars for "side effects". IO is a perfectly fine 
mathematical object, the only difference is that it is appending 
sequences of an abstract type that we mere mortals like to think of as 
"actions" or "side effects" or "a program". The mathematics neither 
knows nor cares about any of that rubbish.


The only relevant thing[1] is that this abstract type ---whatever it is, 
however it's implemented--- forms a monoid. The return function 
associates the identity of the monoid with some value (which is also 
irrelevant as far as the monad is concerned), and the bind operation 
uses the associative operation of the monoid to combine them. The latter 
is more obvious when it's phrased in terms of join :: Monad m => m(m a) 
-> m a, and the monad law: join . join == join . fmap join


It so happens that a sequence of anything is the "free" monoid. 
Appending sequences of characters is no different than appending 
sequences of actions or program instructions. For lists or sets as 
monads, the monoid is a path through a decision tree aka a sequence of 
choices. These "choices" aren't stored in bits anywhere, just like IO's 
RealWorld[2], but people don't seem to get as flustered trying to figure 
out what exactly a "choice" is and what a "choice" means as a 
mathematical object. The point is, it doesn't matter. The choice, the 
side effect, the character, these are all just arbitrary sets of things. 
We can construct a free monoid over any set, and the monoid neither 
knows nor cares anything about the "values" in that set.


The only way we can optimize away one of the calls to notGetChar (or any 
other monadic function) is if we can guarantee that no other computation 
will use either the monoidal values or the "contained" values associated 
with it. IO is defined with a bind operator that's strict in the 
monoidal value, which means we can never remove things (unless, perhaps, 
we can demonstrate that they only append the identity of the monoid, in 
which case evaluating the function has no side effects--- by 
definition). There's nothing particularly intriguing about a strict bind 
operator, State has one as do other monads. And there's nothing 
particularly intriguing about "stateful" monads either, there is the 
Lazy State monad too (and the ACIO monad is something like a lazy IO).



[1] Okay, not the *only* relevant thing :)

[2] This is just like the binary search algorithm. Effectively there's a 
tree that spans the set we're searching, and each iteration of search is 
walking down one ply of that tree. Only for binary search we usually 
don't bother constructing that tree, the tree is realized in the 
recursion pattern of the algorithm. Or dually, binary tree 
datastructures are a reification of the algorithm. You get this same 
duality with, frex, lazy lists vs for-loops. There's nothing special 
about being stored in bits vs being stored in invariants or actions.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell tutorial for pseudo users?

[Jonathan Cast]

On Mon, 2009-02-02 at 20:55 +, Andrew Coppin wrote:
> Deniz Dogan wrote:
> > Learn You a Haskell for Great Good (http://learnyouahaskell.com/)
> 
> Mmm, interesting.
> 
> Does anybody else think it would be neat if GHCi really did colourise 
> your input like that?

Bleah.  More terminal hacking to break and/or slow Emacs to a crawl?  No
thanks.

jcc


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

Re: [Haskell-cafe] Happstack 0.1 Released!

[Don Stewart]

andrewcoppin:
> Jochem Berndsen wrote:
>> The HAppS project has been abandoned, see
>> http://groups.google.com/group/HAppS/msg/d128331e213c1031 .
>>
>> The Happstack project is intended to continue development. For more
>> details, see http://happstack.com/faq.html .
>>
>>   
> So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does  
> anybody know how all these relate to each other? Where their strengths  
> and weaknesses lie?
>
> It's nice to have choice, but without knowing what you're choosing  
> between, it's hard to use it well.
>

A comparative analysis of the 10+ Haskell web frameworks would be
awesome.

happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia,
kibro, ella, what was that one launched yesterday? *ah, yesod...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell tutorial for pseudo users?

[Don Stewart]

andrewcoppin:
> Deniz Dogan wrote:
>> Learn You a Haskell for Great Good (http://learnyouahaskell.com/)
>
> Mmm, interesting.
>
> Does anybody else think it would be neat if GHCi really did colourise  
> your input like that? (Or at least display the prompt in a different  
> colour to user input and program output?)

I wrote about this a while ago,

http://haskell.org/haskellwiki/GHCi_in_colour

Needs integration with ghc-api, and we're done.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Happstack 0.1 Released!

[Andrew Coppin]

Jochem Berndsen wrote:

The HAppS project has been abandoned, see
http://groups.google.com/group/HAppS/msg/d128331e213c1031 .

The Happstack project is intended to continue development. For more
details, see http://happstack.com/faq.html .

  
So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does 
anybody know how all these relate to each other? Where their strengths 
and weaknesses lie?


It's nice to have choice, but without knowing what you're choosing 
between, it's hard to use it well.



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

[Haskell-cafe] (Off-topic) CUDA

[Andrew Coppin]

And so, inspired by the marketing litrature, I just spent £££ on a very 
expensive new GPU that supports CUDA. The only problem is... I can't 
seem to get any software to use it.


Does anybody know how to make this stuff actually work?

(Also... Haskell on the GPU. It's been talked about for years, but will 
it ever actually happen?)


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

Re: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

[Andrew Coppin]

Don Stewart wrote:

The platform is a set of blessed libraries and tools. The distros will
still need to package that.

To do that for Windows, we're still going to need a windows packaging
team, along side Debian, Arch, Gentoo, Mac etc.
  


Right, so, let me make sure I understand this...

1. We sit down and pick a set of libraries that cover a useful range of 
subject areas, that are mature and stable, and that work well with each 
other. This is the "Haskell Platform".


2. For each OS, a team decides how best to deploy this set of libraries 
on that specific OS.


Is that the plan?

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

Re: [Haskell-cafe] Haskell tutorial for pseudo users?

[Andrew Coppin]

Deniz Dogan wrote:

Learn You a Haskell for Great Good (http://learnyouahaskell.com/)


Mmm, interesting.

Does anybody else think it would be neat if GHCi really did colourise 
your input like that? (Or at least display the prompt in a different 
colour to user input and program output?)


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

Re: [Haskell-cafe] Re: Haddock

[Max Rabkin]

On Thu, Feb 5, 2009 at 4:25 PM, David Waern  wrote:
> As for running arbitrary commands, I think we are opening up to a lot
> of unfamiliar syntax. I'd like to hear what everyone thinks about
> that.

I personally find it useful to have Haddock comments readable in the source.

And aren't there security issues, too? So we'd have to have an option
to disable them, which would have to be on by default, and basically
they would be disabled by everybody but the writers of the comments
themselves.

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

[Haskell-cafe] Haddock Markup

[David Waern]

I got the subject line wrong, so I'm reposting this:


Hi everyone,

I received this question from Lennart Augustsson (via Simon M) and
thought I'd send out an inquiry to the Haskell community in general
(Lennart, I hope you don't mind):

Lennart writes:
> We have some local patches for haddock that extends the <>
> syntax so you can put TeX formulae in the documentation.
> It looks like, <>, but I'd like to extend it so
> you can process the string with any command.
>
> Are you interested in folding this into the main branch?

So the question is about extending the Haddock markup language.

When modifying the language we should think about the tension between
familiarity, presentation features (pictures, math, whatever) and
visual portability across different mediums (HTML, ghci, IDE tooltips,
etc). And here I should say that Haddock already supports pictures
using the << url >> syntax.

IMHO, adding <> for TeX math is fine, because:

 - math in documentation is often useful
 - if you're going to write math, you need a format, even when the
medium is plain text as in ghci.
 - TeX formulae seem to be relatively widely used and understood.

As for running arbitrary commands, I think we are opening up to a lot
of unfamiliar syntax. I'd like to hear what everyone thinks about
that.

There was also a thread about Haddock markup on haskell-cafe@ about a
year ago, which originated with the interesting idea of using Markdown
(or a Pandoc-extended version of it) instead of the current language:

 http://www.mail-archive.com/haskell-cafe@haskell.org/msg38054.html

I think the original idea there is pretty nice, but let's first focus
on the current markup language in order to answer Lennart's question.
That thread contains some useful opinions on this matter, also.

So, any comments? :)

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

[Haskell-cafe] Re: Monad explanation

[ChrisK]

All Haskell programs start as 



main :: IO ()



though... so they all get evaluated in the context of another IO ()
don't they?



True for most cases now, but historically false.  Haskell existed and people 
wrote programs for years before the Monad class and IO were created.  A 
Haskell98 program can be taken to have a "main :: IO ()", but that is not essential.


Which is the point jcc made:



Well...  Haskell compilers and runhaskell-style interpreters (not
regular Hugs/ghci!) take the value of Main.main as `the program'.  But
that feels (to me --- I could be wrong) like an aspect of a particular
hosted environment.  REPLs can handle programs that aren't wrapped up in
IO at all; and there's no reason why IO has to be the type of
IO-performning-things in REPLs, either.  You could just as well write a
REPL that took, say, tangible values [http://haskell.org/haskellwiki/TV]
as input instead, and displayed them.  So it's more a matter of Haskell
implementations can be given an IO value to run than that combining IO
values together somehow runs them.

jcc


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

[Haskell-cafe] Re: Haddock

[David Waern]

Hi everyone,

I received this question from Lennart Augustsson (via Simon M) and
thought I'd send out an inquiry to the Haskell community in general
(Lennart, I hope you don't mind):

Lennart writes:
> We have some local patches for haddock that extends the <>
> syntax so you can put TeX formulae in the documentation.
> It looks like, <>, but I'd like to extend it so
> you can process the string with any command.
>
> Are you interested in folding this into the main branch?

So the question is about extending the Haddock markup language.

When modifying the language we should think about the tension between
familiarity, presentation features (pictures, math, whatever) and
visual portability across different mediums (HTML, ghci, IDE tooltips,
etc). And here I should say that Haddock already supports pictures
using the << url >> syntax.

IMHO, adding <> for TeX math is fine, because:

  - math in documentation is often useful
  - if you're going to write math, you need a format, even when the
medium is plain text as in ghci.
  - TeX formulae seem to be relatively widely used and understood.

As for running arbitrary commands, I think we are opening up to a lot
of unfamiliar syntax. I'd like to hear what everyone thinks about
that.

There was also a thread about Haddock markup on haskell-cafe@ about a
year ago, which originated with the interesting idea of using Markdown
(or a Pandoc-extended version of it) instead of the current language:

  http://www.mail-archive.com/haskell-cafe@haskell.org/msg38054.html

I think the original idea there is pretty nice, but let's first focus
on the current markup language in order to answer Lennart's question.
That thread contains some useful opinions on this matter, also.

So, any comments? :)

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Jonathan Cast]

On Fri, 2009-02-06 at 00:51 +0100, Peter Verswyvelen wrote:
> On Thu, Feb 5, 2009 at 8:20 PM, ChrisK 
> wrote:
> Since this is strict there is no laziness and the code must
> evaluate the input and output "State RealWorld" to ensure they
> are not bottom or error.

> Interesting. I also thought it was the passing of the RealWorld that
> caused the sequencing, I never realized that the strictness played an
> important role here. 

> So what would happen if it would be lazy instead of strict? What kind
> of craziness would occur?

The order of side effects would be demand-driven, rather than
order-of-statement driven.  So if I said:

  do
 x <- getChar
 y <- getChar
 z <- getChar

then in the sequel, the first character I evaluated would be the first
character read.  Of course, Haskell's order of evaluation is undefined,
so whether the string read from STDIN was

   [x, y, z]
or [y, x, z]
or [z, x, y]

or some other permutation would be undefined.  And, of course, if I
never evaluated y at all, y would never be read --- there would be only
two characters of input.

Essentially, the program would act as if every statement was wrapped up
in an unsafeInterleaveIO.

jcc


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

Re: [Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 15:52 -0800, David Leimbach wrote:
> 
> 
> On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast
>  wrote:
> 
> On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote:
> >
> >
> > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast
> >  wrote:
> >
> > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach
> wrote:
> > >
> > >
> > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
> > >  wrote:
> > > I think the point of the
> Monad is
> > that it
> > > works as a container of
> stuff, that
> > still
> > > allows mathematically pure
> things to
> > happen,
> > > while possibly having some
> opaque
> > "other
> > > stuff" going on.
> >
> > >  This at least sounds, very wrong, even if
> it's not.
> > Monads
> > > are not impure. IO is, but it's only _one_
> instance
> > of Monad.
> > > All others, as far as I know, are pure.
> It's just
> > that the
> > > bind operation allows you to hide the
> stuff you
> > don't want to
> > > have to worry about, that should happen
> every time
> > you compose
> > > two monadic actions.
> 
> > > Well all I can tell you is that I can have (IO
> Int) in a
> > function as a
> > > return, and the function is not idempotent in
> terms of the
> > "stuff"
> > > inside IO being the same.
> >
> >
> > Sure it's the same.
> >
> > >  cmp /bin/cat /bin/cat
> > > cp /bin/cat ~
> > > cmp /bin/cat ~/cat
> > >
> >
> > Pretty much the same, anyway.
> 
> 
> > So if IO represents a program that when executed interacts
> with the
> > world's state, is it safe to say that when I return (State
> Int Int),
> > that I'm returning a "State program"?
> 
> 
> I won't object to it.  Othe people might, though.
> 
> > That'd make sense as it really does look like we force the
> State to be
> > evaluated with runState, evalState or execState.
> 
> > The only difference with IO then is that to get IO programs
> to run,
> > you have to do it inside another IO program.
> 
> 
> Meh.  Combining IO sub-programs into larger programs doesn't
> really `get
> them to run'.  Better to say that an IO value is meaningful
> only to the
> computer, and not mathematically (denotationally) useful.
> 
> All Haskell programs start as 

> main :: IO ()

> though... so they all get evaluated in the context of another IO ()
> don't they?

Well...  Haskell compilers and runhaskell-style interpreters (not
regular Hugs/ghci!) take the value of Main.main as `the program'.  But
that feels (to me --- I could be wrong) like an aspect of a particular
hosted environment.  REPLs can handle programs that aren't wrapped up in
IO at all; and there's no reason why IO has to be the type of
IO-performning-things in REPLs, either.  You could just as well write a
REPL that took, say, tangible values [http://haskell.org/haskellwiki/TV]
as input instead, and displayed them.  So it's more a matter of Haskell
implementations can be given an IO value to run than that combining IO
values together somehow runs them.

jcc


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

Re: [Haskell-cafe] Monad explanation

[David Leimbach]

On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast wrote:

> On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote:
> >
> >
> > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast
> >  wrote:
> >
> > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote:
> > >
> > >
> > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
> > >  wrote:
> > > I think the point of the Monad is
> > that it
> > > works as a container of stuff, that
> > still
> > > allows mathematically pure things to
> > happen,
> > > while possibly having some opaque
> > "other
> > > stuff" going on.
> >
> > >  This at least sounds, very wrong, even if it's not.
> > Monads
> > > are not impure. IO is, but it's only _one_ instance
> > of Monad.
> > > All others, as far as I know, are pure. It's just
> > that the
> > > bind operation allows you to hide the stuff you
> > don't want to
> > > have to worry about, that should happen every time
> > you compose
> > > two monadic actions.
>
> > > Well all I can tell you is that I can have (IO Int) in a
> > function as a
> > > return, and the function is not idempotent in terms of the
> > "stuff"
> > > inside IO being the same.
> >
> >
> > Sure it's the same.
> >
> > >  cmp /bin/cat /bin/cat
> > > cp /bin/cat ~
> > > cmp /bin/cat ~/cat
> > >
> >
> > Pretty much the same, anyway.
>
> > So if IO represents a program that when executed interacts with the
> > world's state, is it safe to say that when I return (State Int Int),
> > that I'm returning a "State program"?
>
> I won't object to it.  Othe people might, though.
>
> > That'd make sense as it really does look like we force the State to be
> > evaluated with runState, evalState or execState.
>
> > The only difference with IO then is that to get IO programs to run,
> > you have to do it inside another IO program.
>
> Meh.  Combining IO sub-programs into larger programs doesn't really `get
> them to run'.  Better to say that an IO value is meaningful only to the
> computer, and not mathematically (denotationally) useful.
>
> jcc
>

All Haskell programs start as

main :: IO ()

though... so they all get evaluated in the context of another IO () don't
they?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Peter Verswyvelen]

On Thu, Feb 5, 2009 at 8:20 PM, ChrisK wrote:

> Since this is strict there is no laziness and the code must evaluate the
> input and output "State RealWorld" to ensure they are not bottom or error.
>

Interesting. I also thought it was the passing of the RealWorld that caused
the sequencing, I never realized that the strictness played an important
role here.

So what would happen if it would be lazy instead of strict? What kind of
craziness would occur?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Signatures in defining functions

[Peter Verswyvelen]

Maybe you mean that

f :: Int -> Int -> Int

does not say much about what the function does since the Int arguments have
no "name" in Haskell?

E.g. the following might "mean" more, but is not valid Haskell:

f :: numerator:Int -> denominator:Int -> quotient:Int

In Haskell you regularly see documentation that says: "the 4th argument of
dpSwitch is ..., the 7th argument of dpSwitch is ..."

That's okay, since it trains you at counting :-) Of course, I'm being
sarcastic.

But most of the time, this is not an issue, since functions usually only
have a few arguments, or have argument types that tell more.

2009/2/5 TKM 

>  Hello,
>
> I'm kind of new with Haskell and I would like to know about the following:
>
> [some function]:: Int -> Int -> Int
>
> Now is my question, how should I interpret "Int -> Int -> Int"? Meaning
> what does "Int -> Int -> Int" mean?
>
> Thank you for answering my question.
>
> Kind Regards, JTKM
>
> ___
> 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] Signatures in defining functions

[Miguel Mitrofanov]

It means Int -> (Int -> Int). -> is right associative.

On 6 Feb 2009, at 01:28, TKM wrote:


Hello,

I'm kind of new with Haskell and I would like to know about the  
following:


[some function]:: Int -> Int -> Int

Now is my question, how should I interpret "Int -> Int -> Int"?  
Meaning what does "Int -> Int -> Int" mean?


Thank you for answering my question.

Kind Regards, JTKM
___
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: evaluation semantics of bind

[Lennart Augustsson]

Perhaps you meant the type correct expression
  return 7 >>= \ x -> return 42
which the compiler will probably optimize to return 42, because by
seeing the definition of return the compiler can see that it has no
effects in the monad.  This expression is very different from
  getChar >>= \ x -> return 42
Assuming getChar is some kind of primitive operation, the compiler
does not know that it has no effects, so it has to remain.

There's nothing special about IO in this respect.  If IO is
implemented as a state monad the compiler can just unfold the
definitions of return and >>= and do its usual job.  Some
subexpressions (like return 7) do not touch the RealWord state and can
be optimized away, some operations (like getChar) take and return a
RealWorld, so they cannot be removed.

  -- Lennart

On Thu, Feb 5, 2009 at 8:55 PM, Gregg Reynolds  wrote:
> On Thu, Feb 5, 2009 at 11:22 AM, Gleb Alexeyev  wrote:
>> Gregg Reynolds wrote:
>>
>>> Are you saying that using equations to add a level of indirection
>>> prevents optimization?  I still don't see it - discarding x doesn't
>>> change the semantics, so a good compiler /should/ do this.  How is
>>> this different from optimizing out application of a constant function?
>>>
>>
>> Perhaps my example doesn't work, so I'll try another example.
>> As you know, (>>=) is just an (overloaded) higher-order function.
>> Let's consider another higher-order function, map. The expression
>>> map (\x -> 42) [1..3]
>> evaluates to [42, 42, 42].
>> As you can see, the function (\x -> 42) passed to map ignores its first
>> argument. Would you expect the compiler to discard the call to map?
>
> No, but I might expect it to discard the function application and just
> replace each element of the list with 42.  Which it may do at compile
> time.  Plus, it will only be evaluated once, no matter how many times
> the expression occurs, since lazy evaluation memoizes results.
>>
>> Can you see the analogy? The shapes of the two expressions, map (\x -> 42)
>> [1..3] and (>>=) getChar (\x -> getChar) are similar.
>>
>> (>>=) is a combinator just like map, you cannot optimize it away in general.
>
> Ok, I see what you're getting at, but I have to think about it some more.
>
> Here's a restatement that might make my puzzlement more clear.  Suppose we 
> have
>
>   f = \x -> 42
>
> Then I would expect the compiler to replace each expression of the
> form f x with 42, for all x.
>
> Now suppose we write  7 >>= \x -> 42.  It seems to me that a compiler
> could examine that expression, conclude that it is constant, and
> replace it with the expression 42.  So far as I know, there's nothing
> in the semantics of Haskell to forbid this, so why not do it?  There
> are no side effects, and an optimizer can always substitute equals for
> equals, no?  (Let's disregard the fact that such optimizations may be
> hard or expensive.)
>
> This is different from map, because unlike map it doesn't need to
> perform a computation (i.e. execute the function) to arrive at the
> final value; it only has to analyze the function (which is computation
> but not computation of the function itself.)
>
> Now getChar is a value of type IO Char, by definition.  That means
> mathematical value - "an action that does some IO" won't cut it in a
> formal semantics, since there is no way to express "does some IO"
> formally.  Values is values; they don't "do" anything.  So we should
> be able to replace 7 and 42 above by getChar, and do the same
> optimization.
>
> Do you see why this is problematic for me?  In any case, you're
> responses (and the others) have been quite useful and have helped me
> work through some problems with a rather radical idea I have to
> address this that I hope to write up this weekend.
>
> Thanks,
>
> gregg
> ___
> 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] Signatures in defining functions

[Martijn van Steenbergen]

Hi JTKM,

TKM wrote:
Now is my question, how should I interpret "Int -> Int -> Int"? Meaning 
what does "Int -> Int -> Int" mean?


There are many good tutorials and books online. Here's a link that 
directly answers your question:


http://book.realworldhaskell.org/read/types-and-functions.html#id581829

Section "The type of a function of more than one argument"

Hope this helps,

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

Re: [Haskell-cafe] Just how unsafe is unsafe

[Peter Verswyvelen]

Well, one could say that a truly random number function takes as input time
and some constant unique identifier (serial number) of the TRND device and
gives you the random value measured at that time by this device. Of course
this would mean the random value is not really random, since "the potential
creator of the universe" would have known the value already, but to all
humble beings living in the bubble, it would be Truly Random :)
Then the question is, is time a function? If so, is it discrete?

Okay, this is not Haskell anymore, this would become philosophy, and since a
good and smart friend of mine told me that nobody really knows what time is,
this is off topic. Sorry!  :)

On Thu, Feb 5, 2009 at 11:31 PM, Jake McArthur  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Peter Verswyvelen wrote:
> | I do have asked myself the question whether a "really random generating"
> | function could be regarded as "pure" somehow (actually would a true
> | random function still be a mathematical function?)
> |
> | E.g. the function would return a true (not pseudo) random number,
> | practically unpredictable (e.g. hardware assisted, using some physical
> | phenomenon, e.g. using atmospheric noise or something). So you surely
> | won't get referential transparency but since the function is really
> | random, this would be correct behavior?
>
> An informal definition of a function might be something like a black box
> that takes and input and produces an output, and for each possible
> input, the output must be the same. Taking this to be a function, there
> is really no such thing as a random function, and if there was, it
> wouldn't even need to be a function. (What would the input to it be?)
>
> If you wanted to mathematically represent a random number, it would, in
> most cases I can think of, best be represented as a free variable. In a
> program, such a free variable could be filled in by the runtime.
> Conveniently, (and by no coincidence) this is something the IO monad can
> provide for us! :)
>
> | Of course you could just put this random generator in the IO monad, but
> | certain algorithms- like Monte Carlo - intuitively don't seem to operate
> | in a IO monad to me.
>
> Why not?
>
> A Random monad might be more appropriate in this case anyway. Such a
> monad is a State monad that hold a random seed. Every time a random
> number is needed, the seed is passed to a deterministic psuedo-random
> number generator, and a new seed is put as the next state.
>
> If a truly random number is ever needed, either IO or unsafeInterleaveIO
> will be needed. The use of unsafeInterleaveIO would be a (rightly)
> controversial choice though.
>
> - - Jake
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmLaK4ACgkQye5hVyvIUKk88QCfRksu7z80QmzgjUvmiyrzDDjl
> QnsAn1R5DHz2tJpWP3yb0+U+loyBdyCX
> =RIX9
> -END PGP SIGNATURE-
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote:
> 
> 
> On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast
>  wrote:
> 
> On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote:
> >
> >
> > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
> >  wrote:
> > I think the point of the Monad is
> that it
> > works as a container of stuff, that
> still
> > allows mathematically pure things to
> happen,
> > while possibly having some opaque
> "other
> > stuff" going on.
> 
> >  This at least sounds, very wrong, even if it's not.
> Monads
> > are not impure. IO is, but it's only _one_ instance
> of Monad.
> > All others, as far as I know, are pure. It's just
> that the
> > bind operation allows you to hide the stuff you
> don't want to
> > have to worry about, that should happen every time
> you compose
> > two monadic actions.

> > Well all I can tell you is that I can have (IO Int) in a
> function as a
> > return, and the function is not idempotent in terms of the
> "stuff"
> > inside IO being the same.
> 
> 
> Sure it's the same.
> 
> >  cmp /bin/cat /bin/cat
> > cp /bin/cat ~
> > cmp /bin/cat ~/cat
> >
> 
> Pretty much the same, anyway.

> So if IO represents a program that when executed interacts with the
> world's state, is it safe to say that when I return (State Int Int),
> that I'm returning a "State program"?

I won't object to it.  Othe people might, though.

> That'd make sense as it really does look like we force the State to be
> evaluated with runState, evalState or execState.

> The only difference with IO then is that to get IO programs to run,
> you have to do it inside another IO program.

Meh.  Combining IO sub-programs into larger programs doesn't really `get
them to run'.  Better to say that an IO value is meaningful only to the
computer, and not mathematically (denotationally) useful.

jcc



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

[Haskell-cafe] Error in building profiling

[Marco Túlio Gontijo e Silva]

Hello,

I'm trying to package ghc-paths for debian, and I got to this:

$ ./setup configure --enable-library-profiling --disable-library-vanilla
Configuring ghc-paths-0.1.0.5...
$ ./setup build
Preprocessing library ghc-paths-0.1.0.5...
Building ghc-paths-0.1.0.5...
/usr/bin/ar: creating dist/build/libHSghc-paths-0.1.0.5_p.a
/usr/bin/ld: dist/build/GHC/Paths.o: No such file: No such file or
directory

I thought this could be a problem with this package, but I've tried with
mtl, and I got the same result:

/usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file
or directory

I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1.

Greetings.

-- 
marcot
http://marcot.iaaeee.org/


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

Re: [Haskell-cafe] Just how unsafe is unsafe

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Verswyvelen wrote:
| I do have asked myself the question whether a "really random generating"
| function could be regarded as "pure" somehow (actually would a true
| random function still be a mathematical function?)
|
| E.g. the function would return a true (not pseudo) random number,
| practically unpredictable (e.g. hardware assisted, using some physical
| phenomenon, e.g. using atmospheric noise or something). So you surely
| won't get referential transparency but since the function is really
| random, this would be correct behavior?

An informal definition of a function might be something like a black box
that takes and input and produces an output, and for each possible
input, the output must be the same. Taking this to be a function, there
is really no such thing as a random function, and if there was, it
wouldn't even need to be a function. (What would the input to it be?)

If you wanted to mathematically represent a random number, it would, in
most cases I can think of, best be represented as a free variable. In a
program, such a free variable could be filled in by the runtime.
Conveniently, (and by no coincidence) this is something the IO monad can
provide for us! :)

| Of course you could just put this random generator in the IO monad, but
| certain algorithms- like Monte Carlo - intuitively don't seem to operate
| in a IO monad to me.

Why not?

A Random monad might be more appropriate in this case anyway. Such a
monad is a State monad that hold a random seed. Every time a random
number is needed, the seed is passed to a deterministic psuedo-random
number generator, and a new seed is put as the next state.

If a truly random number is ever needed, either IO or unsafeInterleaveIO
will be needed. The use of unsafeInterleaveIO would be a (rightly)
controversial choice though.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLaK4ACgkQye5hVyvIUKk88QCfRksu7z80QmzgjUvmiyrzDDjl
QnsAn1R5DHz2tJpWP3yb0+U+loyBdyCX
=RIX9
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Signatures in defining functions

[TKM]

Hello,

I'm kind of new with Haskell and I would like to know about the following:

[some function]:: Int -> Int -> Int

Now is my question, how should I interpret "Int -> Int -> Int"? Meaning what 
does "Int -> Int -> Int" mean?

Thank you for answering my question.

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

Re: [Haskell-cafe] Switching from Mercurial to Darcs

[Henning Thielemann]

Peter Verswyvelen schrieb:

> 3) hg addrem
> this adds new files and removes deleted files from local repos.
> forgetting to add files is a common problem, and is really tricky since
> no record is made of these files, so if after a couple of versions if a
> developer finds out a file was missing, the history is useless since you
> can't reconstruct the old content of that local file anymore, and often
> it's impossible to give the local file to the other developers since it
> might be changed. I actually would like to have an option that
> automatically adds/deletes files on each commit, as it is easier to
> delete a file after it is checked in, than it is to reconstruct an old
> version from a local file you forgot to add.

I'm also not glad with darcs behaviour about non-added files. You can try

darcs whatsnew --look-for-adds

David Roundy's philosophy is that you must add a test compilation with
'darcs setprefs' anyway and this one reveals forgotten files.

> 4) hg commit -m "message"
> this commits my changes locally. I always do this before pulling since
> then I'm sure my changes are saved in the case a merge goes wrong.

In old darcs its precisely the other way round. Since it is so slow on
merging ready patches, you better merge uncrecorded changes.


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

Re: [Haskell-cafe] Just how unsafe is unsafe

[Max Rabkin]

2009/2/5 Peter Verswyvelen :
> Of course you could just put this random generator in the IO monad, but
> certain algorithms- like Monte Carlo - intuitively don't seem to operate in
> a IO monad to me.

For PRNGs, only State is needed, not IO.

But you might find the `randoms' function useful: it returns in
infinite list of pseudo-random values.

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

Re: [Haskell-cafe] Just how unsafe is unsafe

[Peter Verswyvelen]

I do have asked myself the question whether a "really random generating"
function could be regarded as "pure" somehow (actually would a true random
function still be a mathematical function?)
E.g. the function would return a true (not pseudo) random number,
practically unpredictable (e.g. hardware assisted, using some physical
phenomenon, e.g. using atmospheric noise or something). So you surely won't
get referential transparency but since the function is really random, this
would be correct behavior?

Of course you could just put this random generator in the IO monad, but
certain algorithms- like Monte Carlo - intuitively don't seem to operate in
a IO monad to me.

Okay, just some thoughts from someone who knows absolutely nothing about
category theory or advanced computer science, so don't shoot me ;-)

On Thu, Feb 5, 2009 at 10:36 PM, Jake McArthur  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Wagner wrote:
> | I understand that unsafeXXX allows impurity, which defiles our ability
> | to reason logically about haskell programs like we would like to. My
> | question is, to what extent is this true?
>
> My opinion is that unsafeXXX is acceptable only when its use is
> preserved behind an abstraction that is referentially transparent and
> type safe. Others may be able to help refine this statement.
>
> | Suppose we had a module, UnsafeRandoms, which had a function that would
> | allow you to generate a different random number every time you call it.
> | The semantics are relatively well-defined, impurity is safely sectioned
> | off in its own impure module, which is clearly labeled as such. How much
> | damage does this do?
>
> This does not preserve referential transparency, so by my criteria above
> this is an unacceptable use of an unsafe function. One reason it's a bad
> idea is that it removes determinism, which may be very important for
> testability.
>
> - - Jake
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmLW/MACgkQye5hVyvIUKniOACfQGPLiY65+eiMfsv7BlbYLI++
> Bd0An1N5wp6TDkJzhmdw831/Gj45Bv9S
> =TnQg
> -END PGP SIGNATURE-
>
> ___
> 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] about integer and float operations

[Henning Thielemann]

Yitzchak Gale schrieb:
> Manlio Perillo wrote:
>> However there is still a *big* problem: it is inefficient.
>>
>> Here is a Python version of the Chudnovsky algorithm [1] for computing Pi:
>> http://paste.pocoo.org/show/102800/
>> On my system it takes 10 seconds.
>> Here is an Haskell version:
>> http://paste.pocoo.org/show/102801/
>> On my system it takes 30 seconds.
> 
> Ah, OK. Thanks. Now we have a well-defined problem. :)

You would not need to handle huge interim results, if you compute the
factorials incrementally. E.g. (n+1)!^3 = n!^3 * (n+1)^3 etc. 'scanl' is
your friend. This should also be faster.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Just how unsafe is unsafe

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Wagner wrote:
| I understand that unsafeXXX allows impurity, which defiles our ability
| to reason logically about haskell programs like we would like to. My
| question is, to what extent is this true?

My opinion is that unsafeXXX is acceptable only when its use is
preserved behind an abstraction that is referentially transparent and
type safe. Others may be able to help refine this statement.

| Suppose we had a module, UnsafeRandoms, which had a function that would
| allow you to generate a different random number every time you call it.
| The semantics are relatively well-defined, impurity is safely sectioned
| off in its own impure module, which is clearly labeled as such. How much
| damage does this do?

This does not preserve referential transparency, so by my criteria above
this is an unacceptable use of an unsafe function. One reason it's a bad
idea is that it removes determinism, which may be very important for
testability.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLW/MACgkQye5hVyvIUKniOACfQGPLiY65+eiMfsv7BlbYLI++
Bd0An1N5wp6TDkJzhmdw831/Gj45Bv9S
=TnQg
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Just how unsafe is unsafe

[Jonathan Cast]

On Thu, 2009-02-05 at 16:11 -0500, Andrew Wagner wrote:
> So we all know the age-old rule of thumb, that unsafeXXX is simply
> evil and anybody that uses it should be shot (except when it's ok). 

> I understand that unsafeXXX allows impurity, which defiles our ability
> to reason logically about haskell programs like we would like to.

Not just that!  Parametric polymorphism is unsound in combination with
mutable values; but unsafePerformIO turns on exactly that combination.

unsafeCoerce :: alpha -> beta
unsafeCoerce x = unsafePerformIO $ do
  let r = unsafePerformIO $ newIORef undefined
  r `writeIORef` x
  readIORef r

> My question is, to what extent is this true? 

unsafePerformIO is a true function --- in the absence of any fancy
compiler trickery --- on a small subset of its domain.  Outside of that
subset, I would regard use of unsafePerformIO simply as a bug ---
violation of an unchecked precondition.  Period.

> Suppose we had a module, UnsafeRandoms, which had a function that
> would allow you to generate a different random number every time you
> call it.

unsafePerformIO does not allow you to guarantee this!  If I defined

  myRandomNumber = unsafePerformIO $ randomNumber

then the compiler is permitted to call randomNumber (at most) *once*,
and use that number throughout the program.

> The semantics are relatively well-defined,

Leaving aside the issue above, I would think complete randomness was
nearly the worst possible case, semantically.  (The *worst* worst
possible case would be non-statistical non-determinism --- which is what
you actually get here).

> impurity is safely sectioned off in its own impure module, which is
> clearly labeled as such. How much damage does this do?

Well, it forces me to chase your libraries import lists to decide
whether I want to trust your code, for one thing.  Haskell is all about
making it easier to audit code, not harder.

> Can we push the lines elsewhere?

I'd rather not.

> Is sectioning unsafeXXX into Unsafe modules a useful idiom that we can
> use for other things as well?

I'd rather not write other unsafe functions at all.  Sectioning off
things that need to be unsafe into pure solutions --- like, say, monads
--- is a much better idea.  (Go read the global variables thread from
last year).

jcc


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

[Haskell-cafe] Re: OpenAL

[Paul Langevin]

>Does the example code at
>http://articles.bluishcoder.co.nz/Haskell/OpenAL work for anyone? 

sorry for the delay, Brian :

I can hear the two sounds one after the other (I wish I knew how to hear them 
at the same time).
However, I've got a strange error message from ALSA :
"
alsa_blitbuffer: Could not write audio data to sound device: File descriptor in 
bad state
mixer: pcm.c:2644: snd_pcm_areas_copy: Assertion 'dst_areas' failed.
"

(mixer is the name of the executable (because I thought...))

OpenAL version : 1.3
ALC version : 1.0
AL version : 1.1
Ghc version : 6.6
_
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  
Téléchargez-le maintenant ! 
http://www.windowslive.fr/messenger/1.asp___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Just how unsafe is unsafe

[Andrew Wagner]

So we all know the age-old rule of thumb, that unsafeXXX is simply evil and
anybody that uses it should be shot (except when it's ok).
I understand that unsafeXXX allows impurity, which defiles our ability to
reason logically about haskell programs like we would like to. My question
is, to what extent is this true?

Suppose we had a module, UnsafeRandoms, which had a function that would
allow you to generate a different random number every time you call it. The
semantics are relatively well-defined, impurity is safely sectioned off in
its own impure module, which is clearly labeled as such. How much damage
does this do?

Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe modules
a useful idiom that we can use for other things as well?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[David Leimbach]

On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast wrote:

> On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote:
> >
> >
> > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
> >  wrote:
> > I think the point of the Monad is that it
> > works as a container of stuff, that still
> > allows mathematically pure things to happen,
> > while possibly having some opaque "other
> > stuff" going on.
>
> >  This at least sounds, very wrong, even if it's not. Monads
> > are not impure. IO is, but it's only _one_ instance of Monad.
> > All others, as far as I know, are pure. It's just that the
> > bind operation allows you to hide the stuff you don't want to
> > have to worry about, that should happen every time you compose
> > two monadic actions.
>
>
> > Well all I can tell you is that I can have (IO Int) in a function as a
> > return, and the function is not idempotent in terms of the "stuff"
> > inside IO being the same.
>
> Sure it's the same.
>
> >  cmp /bin/cat /bin/cat
> > cp /bin/cat ~
> > cmp /bin/cat ~/cat
> >
>
> Pretty much the same, anyway.
>
> jcc
>
>
So if IO represents a program that when executed interacts with the world's
state, is it safe to say that when I return (State Int Int), that I'm
returning a "State program"?  That'd make sense as it really does look like
we force the State to be evaluated with runState, evalState or execState.

The only difference with IO then is that to get IO programs to run, you have
to do it inside another IO program.

I hope I'm not making this worse! :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Bind as a sequencing operator

[Andrew Wagner]

bind is no more a sequencing operator than function composition is. Just as
the order in which you pass two functions (ignoring the type issue for the
moment) matters, the order in which you pass things to bind matters. The
sense in which the order _doesn't_ matter is that of the order in which what
you pass gets evaluated.

On Thu, Feb 5, 2009 at 3:32 PM, Jake McArthur  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> m...@justinbogner.com wrote:
> | Jake McArthur  writes:
> |> The problem with your description is that you said "and then." The
> |> result will be generated lazily. There is no sequencing here. Consider:
> |>
> |> ~do x <- [0..]
> |> ~   y <- [0..9]
> |> ~   return (x, y)
> |>
> |> Which list is generated first?
> |>
> |
> | This is an implementation detail, since y has no dependency on x the
> | compiler's free to reorder instructions, as it would be an imperative
> | language. Semantically this means do x and then y
>
> That the order does not matter is definitely not an implementation
> detail. Order not mattering is exactly what declarative programming is
> about. The semantics of the above expression are the same as this:
>
> ~(<$> [0..9]) . (,) =<< [0..]
>
> There is no "do X and then do Y," only "this is what I want."
> Declarative semantics. As I said, just because do notation makes it look
> imperative doesn't mean it actually is.
>
> | Just because the compiler is allowed (and even encouraged) to change the
> | sequence where that won't change the results, considering this a
> | sequence is still valid and meaningful.
>
> It can be helpful sometimes, but I don't think it should be the standard
> way to think of bind. There are too many cases when it makes little
> sense as a sequencing operator.
>
> - - Jake
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmLTPEACgkQye5hVyvIUKkoCACgz/IYvxa6PoEvuqgxljGAwZ8+
> TXQAn30MyLDwhLyZV3+dRuJvttx93ZNh
> =P9em
> -END PGP SIGNATURE-
> ___
> 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: Bind as a sequencing operator

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

m...@justinbogner.com wrote:
| Jake McArthur  writes:
|> The problem with your description is that you said "and then." The
|> result will be generated lazily. There is no sequencing here. Consider:
|>
|> ~do x <- [0..]
|> ~   y <- [0..9]
|> ~   return (x, y)
|>
|> Which list is generated first?
|>
|
| This is an implementation detail, since y has no dependency on x the
| compiler's free to reorder instructions, as it would be an imperative
| language. Semantically this means do x and then y

That the order does not matter is definitely not an implementation
detail. Order not mattering is exactly what declarative programming is
about. The semantics of the above expression are the same as this:

~(<$> [0..9]) . (,) =<< [0..]

There is no "do X and then do Y," only "this is what I want."
Declarative semantics. As I said, just because do notation makes it look
imperative doesn't mean it actually is.

| Just because the compiler is allowed (and even encouraged) to change the
| sequence where that won't change the results, considering this a
| sequence is still valid and meaningful.

It can be helpful sometimes, but I don't think it should be the standard
way to think of bind. There are too many cases when it makes little
sense as a sequencing operator.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLTPEACgkQye5hVyvIUKkoCACgz/IYvxa6PoEvuqgxljGAwZ8+
TXQAn30MyLDwhLyZV3+dRuJvttx93ZNh
=P9em
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote:
> 
> 
> On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
>  wrote:
> I think the point of the Monad is that it
> works as a container of stuff, that still
> allows mathematically pure things to happen,
> while possibly having some opaque "other
> stuff" going on.

>  This at least sounds, very wrong, even if it's not. Monads
> are not impure. IO is, but it's only _one_ instance of Monad.
> All others, as far as I know, are pure. It's just that the
> bind operation allows you to hide the stuff you don't want to
> have to worry about, that should happen every time you compose
> two monadic actions.


> Well all I can tell you is that I can have (IO Int) in a function as a
> return, and the function is not idempotent in terms of the "stuff"
> inside IO being the same.

Sure it's the same.

>  cmp /bin/cat /bin/cat
> cp /bin/cat ~
> cmp /bin/cat ~/cat
>

Pretty much the same, anyway.

jcc


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

Re: [Haskell-cafe] Monad explanation

[David Leimbach]

On Thu, Feb 5, 2009 at 12:25 PM, Andrew Wagner wrote:

> On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach  wrote:
>
>>
>> Well all I can tell you is that I can have (IO Int) in a function as a
>> return, and the function is not idempotent in terms of the "stuff" inside IO
>> being the same.
>>
>> Sounds impure to me.
>>
>
> Right, thus IO is impure. but as long as the function that returns the IO
> Int returns the same IO Int every time you provide the same input, it's
> pure.
>

Ah yes I see your point... that's true absolutely.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Andrew Wagner]

On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach  wrote:

>
> Well all I can tell you is that I can have (IO Int) in a function as a
> return, and the function is not idempotent in terms of the "stuff" inside IO
> being the same.
>
> Sounds impure to me.
>

Right, thus IO is impure. but as long as the function that returns the IO
Int returns the same IO Int every time you provide the same input, it's
pure.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[Tim Newsham]

You are absolutely right.  The statement
 "The values of the IO monad are programs that do IO. "
is somewhat nonsensical. Values don't do anything, they just are.
But values of the IO monad *describe* how to do IO; they can be seen
as a recipe for doing IO.
A recipe doesn't cook a dish, but when the recipe is executed by a
cook they creates a dish.
An IO values doesn't do IO, but when it is executed by the runtime
system IO happens.


Just as a recipe describes how to cook something, a program describes
how to accomplish something.  The program doesnt "do" anything
until it is executed.  However, we often use the word "do" to
describe what a program will do when executed (even though
its really the cpu that is actually "doing").


This is one way of interpreting what the IO type means.
(Another one is to say that Haskell is just an imperative programming
language, but any imperative actions show up in the type.)


I don't see the difference between these two interpretations.
Wether the program is made up of instructions for a cpu or for
an interpreter seems irrelevant.


 -- Lennart


Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad explanation

[David Leimbach]

On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner wrote:

> I think the point of the Monad is that it works as a container of stuff,
>>> that still allows mathematically pure things to happen, while possibly
>>> having some opaque "other stuff" going on.
>>>
>>
>  This at least sounds, very wrong, even if it's not. Monads are not impure.
> IO is, but it's only _one_ instance of Monad. All others, as far as I know,
> are pure. It's just that the bind operation allows you to hide the stuff you
> don't want to have to worry about, that should happen every time you compose
> two monadic actions.
>


Well all I can tell you is that I can have (IO Int) in a function as a
return, and the function is not idempotent in terms of the "stuff" inside IO
being the same.

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

Re: [Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 20:46 +0100, Lennart Augustsson wrote:
> You are absolutely right.  The statement
>   "The values of the IO monad are programs that do IO. "
> is somewhat nonsensical. Values don't do anything, they just are.

Technically, programs don't do anything either.  I think of values of
type IO a as being --- conceptually --- arbitrary sequences of machine
code instructions.  Just like a sequence of machine code instructions
can be stored away in /bin/cat, and not do anything, an IO value needn't
do anything, either.  Until it's stored in memory and the instruction
pointer set to its first instruction.  At which point, if you want to
get really picky, it's still the CPU doing things.  Which it is told to
do by its fixed microcode.  Which tells it to look at your program to
see what to do.  Which = looking at the `value' of your IO-typed
expression to see what to do.

jcc


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

[Haskell-cafe] Success (was: cURL under Windows again)

[Iliya Kuznetsov]

The problem has solved. Solution, given by http://awson.livejournal.com/,
is:
1. Copy libcurl-4.dll to libcurl.dll beause of namescheme
2. Before building haskell curl-1.3.4 _under windows_ you have to change

#define CURL_EXTERN __declspec(dllimport)
to
#define CURL_EXTERN.

After that, curl-7.19.3 and curl-1.3.4 work fine.
-- Forwarded message --
From: Iliya Kuznetsov 
Date: 2009/2/2
Subject: cURL under Windows again
To: haskell-cafe@haskell.org


Hello cafe-subscribers,

I saw some issues about installing haskell bindings for cURL under Windows,
and now I'm trapped too.
So, here is actions' log for everything (very detail; you can PgDn to the
end with questions):

1. Windows Vista without UAC
2. ghc-6.10.1-i386-windows.exe is installed to C:\Program Files\Haskell
"C:\Program Files\Haskell\package.conf" wasn't touched after
installation (Cabal nor manually)
3. MinGW-5.1.4 installed to C:\temp\MinGW
4. MSys-1.0 installed to C:\temp\msys\1.0\
5. curl-7.19.3.tar.bz2 had taken from
http://curl.haxx.se/download/curl-7.19.3.tar.bz2
6. Under msys, curl-7.19.3.tar.bz2 is untared into
/home/Kuznetsov/curl-7.19.3
7. cURL is made as:
  cd curl-7.19.3
$  ./configure
configure: Configured to build curl/libcurl:
...
  curl version:7.19.3
  Host setup:  i686-pc-mingw32
  Install prefix:  /usr/local
  Compiler:gcc
  SSL support: no  (--with-ssl / --with-gnutls)
  SSH support: no  (--with-libssh2)
  zlib support:no  (--with-zlib)
  krb4 support:no  (--with-krb4*)
  GSSAPI support:  no  (--with-gssapi)
  SPNEGO support:  no  (--with-spnego)
  c-ares support:  no  (--enable-ares)
  ipv6 support:no  (--enable-ipv6)
  IDN support: no  (--with-libidn)
  Build libcurl:   Shared=yes, Static=yes
  Built-in manual: no  (--enable-manual)
  Verbose errors:  enabled (--disable-verbose)
  SSPI support:no  (--enable-sspi)
  ca cert bundle:  no
  ca cert path:no
  LDAP support:enabled (winldap)
  LDAPS support:   no  (--enable-ldaps)

$  make
...
make[2]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src'
make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src'
make[1]: Entering directory `/home/Kuznetsov/curl-7.19.3'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3'

$  make install
...
libtool: install: /bin/install -c .libs/libcurl.dll.a
/usr/local/lib/libcurl.dll.a
libtool: install: base_file=`basename libcurl.la`
libtool: install:  dlpath=`/bin/sh 2>&1 -c '. .libs/'libcurl.la'i; echo
libcurl-4.dll'`
libtool: install:  dldir=/usr/local/lib/`dirname ../bin/libcurl-4.dll`
libtool: install:  test -d /usr/local/lib/../bin || mkdir -p
/usr/local/lib/../bin
libtool: install:  /bin/install -c .libs/libcurl-4.dll
/usr/local/lib/../bin/libcurl-4.dll
libtool: install:  chmod a+x /usr/local/lib/../bin/libcurl-4.dll
libtool: install:  if test -n '' && test -n 'strip --strip-unneeded'; then
eval 'strip --strip-unneeded /usr/local/lib/../bin/libcurl-4.dll' || exit 0;
fi
libtool: install: /bin/install -c .libs/libcurl.lai /usr/local/lib/
libcurl.la
libtool: install: /bin/install -c .libs/libcurl.a /usr/local/lib/libcurl.a
libtool: install: chmod 644 /usr/local/lib/libcurl.a
libtool: install: ranlib /usr/local/lib/libcurl.a
--
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `PATH' environment variable
 during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
 during linking
   - use the `-LLIBDIR' linker flag
...
 /bin/install -c -m 644 'curl.h' '/usr/local/include/curl/curl.h'
 /bin/install -c -m 644 'curlver.h' '/usr/local/include/curl/curlver.h'
 /bin/install -c -m 644 'easy.h' '/usr/local/include/curl/easy.h'
 /bin/install -c -m 644 'mprintf.h' '/usr/local/include/curl/mprintf.h'
 /bin/install -c -m 644 'stdcheaders.h'
'/usr/local/include/curl/stdcheaders.h'
 /bin/install -c -m 644 'types.h' '/usr/local/include/curl/types.h'
 /bin/install -c -m 644 'multi.h' '/usr/local/include/curl/multi.h'
 /bin/install -c -m 644 'typecheck-gcc.h'
'/usr/local/include/curl/typecheck-gcc.h'
 /bin/install -c -m 644 'curlbuild.h' '/usr/local/include/curl/curlbuild.h'
 /bin/install -c -m 644 'curlrules.h' '/usr/local/include/curl/curlrules.h'
...

8. $ which curl && curl
/usr/local/bin/curl
curl: try 'curl --help' for more information

I have following files in C:\temp\msys\1.0\local\bin\  (/usr/local/bin in
Unix-scheme):

02.02.2009  15:10 4 029 curl-config
02.02.2009  15:1098 591 curl.exe
02.02.2009  15:09   262 934 libcurl-4.dll

In /usr/local/include/curl ten includes:
02.02.2009  15:10

Re: [Haskell-cafe] Monad explanation

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 1:46 PM, Lennart Augustsson
 wrote:
> You are absolutely right.  The statement
>  "The values of the IO monad are programs that do IO. "
> is somewhat nonsensical. Values don't do anything, they just are.

Whew!  So I'm not crazy.  I was starting to wonder.

> But values of the IO monad *describe* how to do IO; they can be seen
> as a recipe for doing IO.
> A recipe doesn't cook a dish, but when the recipe is executed by a
> cook they creates a dish.
> An IO values doesn't do IO, but when it is executed by the runtime
> system IO happens.
>
> This is one way of interpreting what the IO type means.
> (Another one is to say that Haskell is just an imperative programming
> language, but any imperative actions show up in the type.)
>

Thanks very much to you and everybody who contributed on the thread.
It's amazing how much one can learn on this list.

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

[Haskell-cafe] Re: Bind as a sequencing operator

[mail]

Jake McArthur  writes:
> The problem with your description is that you said "and then." The
> result will be generated lazily. There is no sequencing here. Consider:
>
> ~do x <- [0..]
> ~   y <- [0..9]
> ~   return (x, y)
>
> Which list is generated first?
>

This is an implementation detail, since y has no dependency on x the
compiler's free to reorder instructions, as it would be an imperative
language. Semantically this means do x and then y, since if y is changed
to depend on x, this is still valid, but if x is changed to depend on y,
this sequence is not valid.

Just because the compiler is allowed (and even encouraged) to change the
sequence where that won't change the results, considering this a
sequence is still valid and meaningful.

> | As for Reader, I don't know enough about it to say anything.
>
> Reader provides an immutable value that can be retrieved at any point in
> the monad. There are no monadic side effects, so it doesn't really mean
> much to say that anything happens in any particular order.
>

It still needs to be retrieved (logically, not necessarily temporally)
before it's used, doesn't it?

> - Jake

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 11:22 AM, Gleb Alexeyev  wrote:
> Gregg Reynolds wrote:
>
>> Are you saying that using equations to add a level of indirection
>> prevents optimization?  I still don't see it - discarding x doesn't
>> change the semantics, so a good compiler /should/ do this.  How is
>> this different from optimizing out application of a constant function?
>>
>
> Perhaps my example doesn't work, so I'll try another example.
> As you know, (>>=) is just an (overloaded) higher-order function.
> Let's consider another higher-order function, map. The expression
>> map (\x -> 42) [1..3]
> evaluates to [42, 42, 42].
> As you can see, the function (\x -> 42) passed to map ignores its first
> argument. Would you expect the compiler to discard the call to map?

No, but I might expect it to discard the function application and just
replace each element of the list with 42.  Which it may do at compile
time.  Plus, it will only be evaluated once, no matter how many times
the expression occurs, since lazy evaluation memoizes results.
>
> Can you see the analogy? The shapes of the two expressions, map (\x -> 42)
> [1..3] and (>>=) getChar (\x -> getChar) are similar.
>
> (>>=) is a combinator just like map, you cannot optimize it away in general.

Ok, I see what you're getting at, but I have to think about it some more.

Here's a restatement that might make my puzzlement more clear.  Suppose we have

   f = \x -> 42

Then I would expect the compiler to replace each expression of the
form f x with 42, for all x.

Now suppose we write  7 >>= \x -> 42.  It seems to me that a compiler
could examine that expression, conclude that it is constant, and
replace it with the expression 42.  So far as I know, there's nothing
in the semantics of Haskell to forbid this, so why not do it?  There
are no side effects, and an optimizer can always substitute equals for
equals, no?  (Let's disregard the fact that such optimizations may be
hard or expensive.)

This is different from map, because unlike map it doesn't need to
perform a computation (i.e. execute the function) to arrive at the
final value; it only has to analyze the function (which is computation
but not computation of the function itself.)

Now getChar is a value of type IO Char, by definition.  That means
mathematical value - "an action that does some IO" won't cut it in a
formal semantics, since there is no way to express "does some IO"
formally.  Values is values; they don't "do" anything.  So we should
be able to replace 7 and 42 above by getChar, and do the same
optimization.

Do you see why this is problematic for me?  In any case, you're
responses (and the others) have been quite useful and have helped me
work through some problems with a rather radical idea I have to
address this that I hope to write up this weekend.

Thanks,

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

Re: [Haskell-cafe] Monad explanation

[Lennart Augustsson]

You are absolutely right.  The statement
  "The values of the IO monad are programs that do IO. "
is somewhat nonsensical. Values don't do anything, they just are.
But values of the IO monad *describe* how to do IO; they can be seen
as a recipe for doing IO.
A recipe doesn't cook a dish, but when the recipe is executed by a
cook they creates a dish.
An IO values doesn't do IO, but when it is executed by the runtime
system IO happens.

This is one way of interpreting what the IO type means.
(Another one is to say that Haskell is just an imperative programming
language, but any imperative actions show up in the type.)

  -- Lennart

2009/2/4 Gregg Reynolds :
> On Wed, Feb 4, 2009 at 11:41 AM, Tim Newsham  wrote:
>>
>> I put up a small Monad explanation (I wouldn't quite call it
>> a tutorial):
>>  http://www.thenewsh.com/~newsham/haskell/monad.html
>
> "The values of the IO monad are programs that do IO. "
>
> That's a fairly common representation, seems to work for lots of people, but
> it caused me no end of trouble.  Values are mathematical objects; how, I
> asked myself, can they possibly /be/ programs that do IO (or actions, or
> computations, or )?  It doesn't make sense, says I, so I
> must be misunderstanding something about "values"; better spend hours and
> hours researching and trying to figure this out.  But it turns out the
> answer is simple: they can't.  They're not actions, or IO procedures, or
> anything else other than plain old mathematical values, no different than
> '2' or Int -> Char.  They happen to correspond in some way to the external
> physical behavior of the program, but that correspondence is an
> implementation detail beyond the scope of the formal (mathematical)
> semantics of the language.  You don't even need monads for this part; they
> only enter the picture in order to provide ordered evaluation.  In fact
> there really aren't any "monadic values", since a monad is pure morphism;
> the values at issue are "functoric values" if anything.  It's (the
> implementation of) getChar the does the IO, not IO Char.
>
> So you could say that the monad itself is a purely mathematical structure
> that has the felicitous if accidental side effect of imposing temporal
> sequence on the physical interpretation (events) associated with  the
> program.
>
> -g
>
>
> ___
> 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] Monad explanation

[Miguel Mitrofanov]

Ahem... WHAT??? IO monad is impure??? What do you mean?

On 5 Feb 2009, at 22:25, Andrew Wagner wrote:

I think the point of the Monad is that it works as a container of  
stuff, that still allows mathematically pure things to happen, while  
possibly having some opaque "other stuff" going on.


 This at least sounds, very wrong, even if it's not. Monads are not  
impure. IO is, but it's only _one_ instance of Monad. All others, as  
far as I know, are pure. It's just that the bind operation allows  
you to hide the stuff you don't want to have to worry about, that  
should happen every time you compose two monadic actions.

___
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: evaluation semantics of bind

[Miguel Mitrofanov]

Let's put it this way: suppose you have two data types, say, Int and  
String; a value s of type String and a function


f :: String -> (Int -> String) -> String

This could be anything - may be, a function which looks for the first  
character '#' in it's first argument and replaces it with the second  
argument applied to the position where it's found; so


f "abc#" (\n -> replicate n 'q') = "abcqqq"

It could be anything else, of course.

Now, would you expect an optimizer to transform

f s (\x -> s)

to s? I don't think so. f s (\x -> s) and s are clearly distinct and  
there is no reason to transform one to the other.


Now, let's change notation a bit. First of all, let's denote our  
string s by getChar. Well, it's our string and we can name it with  
what name we want - especially if we forget for a moment that getChar  
is already defined. So, for a moment we assume that getChar is defined  
like this:


getChar = "abc#"

Therefore,

f getChar (\x -> getChar)

is NOT equivalent to getChar. Right?

Let's change notation even more. Let's denote our function by (>>=):

(>>=) getChar (\x -> getChar)is NOT equal togetChar

By Haskell rules we can use >>= as infix operator:

getChar >>= (\x -> getChar)is NOT equal togetChar

Now, in your example, instead of Int and String we have Char and IO  
Char. Does that matter? In all the above we didn't use the fact that  
our types are Int and String; the very same applies to Char and (IO  
Char) as well.


On 5 Feb 2009, at 19:18, Gregg Reynolds wrote:

On Thu, Feb 5, 2009 at 9:53 AM, Gleb Alexeyev  
 wrote:

Let's imagine that IO datatype is defined thus:

>{-# LANGUAGE GADTs #-}
>{-# LANGUAGE NoImplicitPrelude #-}

>import Prelude(Monad, Char)
>data IO a where
>GetChar :: IO Char
>Bind :: IO a -> (a -> IO b) -> IO b

>getChar = GetChar
>(>>=) = Bind

It is perfectly possible to construct IO actions as values of this  
data type and execute them by some function evalIO :: IO ->  
Prelude.IO with the obvious definition. Now the question arises: do  
you think

getChar >>= \x -> getChar would be optimized to getChar by compiler?

I must be misunderstanding something.  I don't know if it would be  
optimized out, but I see no reason why it couldn't be.  There's no  
data dependency, right?


-g
___
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] Monad explanation

[Andrew Wagner]

>
> I think the point of the Monad is that it works as a container of stuff,
>> that still allows mathematically pure things to happen, while possibly
>> having some opaque "other stuff" going on.
>>
>
 This at least sounds, very wrong, even if it's not. Monads are not impure.
IO is, but it's only _one_ instance of Monad. All others, as far as I know,
are pure. It's just that the bind operation allows you to hide the stuff you
don't want to have to worry about, that should happen every time you compose
two monadic actions.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

m...@justinbogner.com wrote:
|   [1..2] >>= return . (^2)
|
| This says "generate the list [1..2] and then use it to generate a list
| of squares". It's more than just application, it's a description of a
| sequence of actions. The whole point of list comprehensions (which is
| the only reason to have a list monad, as far as I know) is to think
| of it this way rather than as an application of concatMap.

The problem with your description is that you said "and then." The
result will be generated lazily. There is no sequencing here. Consider:

~do x <- [0..]
~   y <- [0..9]
~   return (x, y)

Which list is generated first?

| As for Reader, I don't know enough about it to say anything.

Reader provides an immutable value that can be retrieved at any point in
the monad. There are no monadic side effects, so it doesn't really mean
much to say that anything happens in any particular order.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLPEoACgkQye5hVyvIUKlaJACePGL6FdevDAmREsl/H9u7jjxS
bKsAoMzEkpw6XjOVg4xql8d4NN47lg8d
=jNtS
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: evaluation semantics of bind

[ChrisK]

Gregg Reynolds wrote:

getChar >>= \x -> getChar

An optimizer can see that the result of the first getChar is discarded


True, so 'x' is not used, and it can be garbage collected, and may not even be 
created.


But that data dependency is simple not the data dependency that make IO 
sequential.  Here is code from IOBase.lhs for GHC:



newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))


The # are unboxed types and thus strict, but here we can erase them for clarity:

newtype IO a = IO (State RealWorld -> (State RealWorld, a))

getChar is of type IO Char so that is constructor IO applied to a function from 
the "State RealWorld" to a strict pair of "State RealWorld" and Char.


Since this is strict there is no laziness and the code must evaluate the input 
and output "State RealWorld" to ensure they are not bottom or error.


Here is the rest of the plumbing in GHC:


unIO :: IO a -> (State# RealWorld -> (# State# RealWorld, a #))
unIO (IO a) = a

instance  Functor IO where
   fmap f x = x >>= (return . f)

instance  Monad IO  where
{-# INLINE return #-}
{-# INLINE (>>)   #-}
{-# INLINE (>>=)  #-}
m >> k  =  m >>= \ _ -> k
return x= returnIO x

m >>= k = bindIO m k
fail s  = failIO s

failIO :: String -> IO a
failIO s = ioError (userError s)

liftIO :: IO a -> State# RealWorld -> STret RealWorld a
liftIO (IO m) = \s -> case m s of (# s', r #) -> STret s' r

bindIO :: IO a -> (a -> IO b) -> IO b
bindIO (IO m) k = IO ( \ s ->
  case m s of 
(# new_s, a #) -> unIO (k a) new_s

  )

thenIO :: IO a -> IO b -> IO b
thenIO (IO m) k = IO ( \ s ->
  case m s of 
(# new_s, _ #) -> unIO k new_s

  )

returnIO :: a -> IO a
returnIO x = IO (\ s -> (# s, x #))


The "bind" operation's case statement forces the unboxed "new_s :: State# 
RealWorld" to be strictly evaluated, and this depends on the input strict "s :: 
State# RealWorld".  This data dependency of new_s on s is what forces IO 
statements to evaluate sequentially.


Cheers,
   Chris

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

Re: [Haskell-cafe] Monad explanation

[David Leimbach]

2009/2/5 Gregg Reynolds 

> On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe  wrote:
>
>>
>> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote:
>>
>>> That's a fairly common representation, seems to work for lots of people,
>>> but it caused me no end of trouble.  Values are mathematical objects; how, I
>>> asked myself, can they possibly /be/ programs that do IO (or actions, or
>>> computations, or )?  It doesn't make sense, says I,
>>>
>>
>> without reference to the rest of your message, of course values can /be/
>> programs.
>
>
> Not "programs", but "programs that do IO".  The point of the idiom is that
> there's an external side effect involved.  What sticks in my craw is that "a
> mathematical value with a non-mathematical side effect" is, well,
> non-mathematical and possibly nonsensical.  I know it works for some (most?)
> people, but for me it lacks Geometry and Theology.
>
> -g
>
>
I think the point of the Monad is that it works as a container of stuff,
that still allows mathematically pure things to happen, while possibly
having some opaque "other stuff" going on.  If you have a monadic add
operation, and a Monad of some kind that "Contains an Integer", you can call
the Monadic add operation on a pair of those monads, and some of the other
monadic gluey-stuff that happens in between can combine the "other stuff" in
specific ways, depending on how the Monad is defined.  If it's  the identity
monad, it might not be that interesting, but if it's a writer monad, it
might log things that are going on.  m 1 + m 2 = m3, but what happened
inside the "m" is entirely up to how that "m" is defined.

Does that make it a little easier to understand?  IO could have happened in
the "m", but there's still a pure peace sometimes :-)  (there's nothing
stopping you reading an integer from the keyboard and returning it to
totally break down that analogy I suppose).

At least this is how I like to think of Monads.  If you want more guarantees
about operations, keep them pure, and then you only have to really
scrutinize the monad-using bits to see where your program can get screwy.

I realize that might not make the mathematician in you feel tons better, but
*shrug*.

Dave


>
> ___
> 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] Bind as a sequencing operator (Was: evaluation semantics of bind)

[Jonathan Cast]

On Thu, 2009-02-05 at 11:47 -0700, m...@justinbogner.com wrote:
> Jake McArthur  writes:
> > m...@justinbogner.com wrote:
> > | Oops, sent this off list the first time, here it is again.
> > |
> > | Jake McArthur  writes:
> > |> m...@justinbogner.com wrote:
> > |> | Bind is a sequencing operator rather than an application operator.
> > |>
> > |> In my opinion, this is a common misconception. I think that bind would
> > |> be nicer if its arguments were reversed.
> > |
> > | If this is a misconception, why does thinking of it this way work so
> > | well? This idea is reinforced by the do notation syntactic sugar: bind
> > | can be represented by going into imperative land and "do"ing one thing
> > | before another.
> >
> > An imperative-looking notation does not make something imperative.
> >
> > Thinking of bind as sequencing really *doesn't* work very well. What
> > does bind have to do with sequencing at all in the list monad, for
> > example? What about the reader monad?
> >
> > - Jake
> 
> What doesn't bind have to do with sequencing in the list monad?
> Consider:
> 
>   [1..2] >>= return . (^2)
> 
> This says "generate the list [1..2] and then use it to generate a list
> of squares". It's more than just application, it's a description of a
> sequence of actions.

But not a temporal sequence.

(>>=) in IO is about temporal sequencing (modulo unsafeInterleaveIO,
forkIO, etc.)

> The whole point of list comprehensions (which is
> the only reason to have a list monad, as far as I know)

Huh?  I thought

newtype Parser s alpha = Parser {
  unParser :: StateT s [] alpha
  } deriving (Functor, Applicative, Alternative, Monad, MonadPlus)

was an entirely sufficient reason to have a list monad.

jcc


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

[Haskell-cafe] Re: Fastest regex package?

[ChrisK]

Eugene Kirpichov wrote:

All in all, my question remains: what is the fastest way to do this
kind of parsing on a lazy bytestring?



Your example regular expression works the same in both Posix and Perl-ish 
semantics.   Do you know the difference?  Posix libraries look for the longest 
match of all possible matches.  Perl-ish is left-bias and looks at the left 
branch first and only looks at the right branch when the left fails and it has 
to backtrack.


So the "++" operator is a hack to try and control the backtracking of Perl 
regular expressions.  Such a things has no meaning in Posix where the 
implementation details are totally different.


You might try this variant of the example pattern:
 /foo.xml.*fooid=([0-9]+)[^0-9].*barid=([0-9]+)

The [^0-9] can be used when you know that there is at least one junk character 
before the barid, which I suspect will always occur in a URL.


I expect regex-posix to be slower than regex-pcre. I have not used the new 
pcre-light.  I wrote regex-tdfa — it is pure haskell and not a C library 
wrapper.  There are patterns where regex-pcre will backtrack and take 
exponentially more time than regex-tdfa's automaton (which is not yet ideal and 
may get faster).


So what is the lazy bytestring with its multiple buffers doing for you when 
using PCRE, PCRE-light, or regex-posix? Absolutely nothing.  To run against 
these C libraries the target text is converted to a single buffer, i.e. a 
CStringLen in Haskell.  Thus it is morally converted into a strict bytestring. 
This may involve copying the logfile into a NEW strict bytestring EVERY TIME you 
run a match.  Please Please Please convert to a strict bytestring and then run 
regex-pcre or pcre-light (or any of the others).


regex-tdfa does not convert it into a strict bytestring, but is otherwise much 
slower than pcre for your simple pattern.


As for regex-pcre's interfaceyou should use the API in regex-base to get a 
pure interface.   The RegexLike functions are the pure interface for this, and 
the RegexContext class offers a slew of instances with useful variants.  But if 
you have been getting to the "low level IO API" in regex-pcre then you probably 
do not need or want the RegexContext transformations.


And BoyerMoore (which I think I helped optimize): this may be faster because it 
does not copy your whole Lazy bytestring into a Strict ByteString for each 
search.  But you may wish to test it with a Strict ByteString as input anyway.


--
Chris

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

Re: [Haskell-cafe] Re: build problems on Hackage

[Wolfgang Jeltsch]

Am Donnerstag, 5. Februar 2009 16:16 schrieb Ross Paterson:
> On Thu, Feb 05, 2009 at 03:03:35PM +0100, Wolfgang Jeltsch wrote:
> > Anyway, can something be done so that not all packages depending
> > (directly or indirectly) on type-level are without documentation? For
> > example, type-level could be installed on the Hackage server without
> > documentation instead of not being installed at all.
>
> OK, I've done that.  parameterized-data-0.1.3 now fails for other reasons,
> but the earlier ones are OK.

Thank you very much.

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

[Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)

[mail]

Jake McArthur  writes:
> m...@justinbogner.com wrote:
> | Oops, sent this off list the first time, here it is again.
> |
> | Jake McArthur  writes:
> |> m...@justinbogner.com wrote:
> |> | Bind is a sequencing operator rather than an application operator.
> |>
> |> In my opinion, this is a common misconception. I think that bind would
> |> be nicer if its arguments were reversed.
> |
> | If this is a misconception, why does thinking of it this way work so
> | well? This idea is reinforced by the do notation syntactic sugar: bind
> | can be represented by going into imperative land and "do"ing one thing
> | before another.
>
> An imperative-looking notation does not make something imperative.
>
> Thinking of bind as sequencing really *doesn't* work very well. What
> does bind have to do with sequencing at all in the list monad, for
> example? What about the reader monad?
>
> - Jake

What doesn't bind have to do with sequencing in the list monad?
Consider:

  [1..2] >>= return . (^2)

This says "generate the list [1..2] and then use it to generate a list
of squares". It's more than just application, it's a description of a
sequence of actions. The whole point of list comprehensions (which is
the only reason to have a list monad, as far as I know) is to think
of it this way rather than as an application of concatMap.

As for Reader, I don't know enough about it to say anything.

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

[Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)

[mail]

Jake McArthur  writes:
> m...@justinbogner.com wrote:
> | Oops, sent this off list the first time, here it is again.
> |
> | Jake McArthur  writes:
> |> m...@justinbogner.com wrote:
> |> | Bind is a sequencing operator rather than an application operator.
> |>
> |> In my opinion, this is a common misconception. I think that bind would
> |> be nicer if its arguments were reversed.
> |
> | If this is a misconception, why does thinking of it this way work so
> | well? This idea is reinforced by the do notation syntactic sugar: bind
> | can be represented by going into imperative land and "do"ing one thing
> | before another.
>
> An imperative-looking notation does not make something imperative.
>
> Thinking of bind as sequencing really *doesn't* work very well. What
> does bind have to do with sequencing at all in the list monad, for
> example? What about the reader monad?
>
> - Jake

What doesn't bind have to do with sequencing in the list monad?
Consider:

  [1..2] >>= 

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

[Haskell-cafe] Re: evaluation semantics of bind

[Achim Schneider]

Gregg Reynolds  wrote:

> getChar >>= \x -> getChar
> 
> An optimizer can see that the result of the first getChar is discarded
>
It isn't discarded. The first getChar results in a value of type IO
Char, always and ever. Whether or not the Char inside the IO Char gets
evaluated or not is another question... >>= could not care less about
what you do to the values that are _inside_ the monad. 

If you look at the type
(>>=) :: (Monad m) => m a -> (a -> m b) -> m b
, you will find it hard to do much of significance to "a" and/or "b"[1]

Whether or not a monad behaves strictly or lazyily wrt. to "m" depends
on the definition of the functions that come with it: IO happens to be
strict, [] to be lazy. This is nothing that messes with semantics,
though, it celebrates them.


[1] Well, you can pass them to id, seq or par, and replace them with
undefined...

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

[Haskell-cafe] RE: Define variable types

[Tsunkiet Man]

Hello,

thank you guys for your responds. I got it working now =).

Thanks a lot!

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

m...@justinbogner.com wrote:
| Oops, sent this off list the first time, here it is again.
|
| Jake McArthur  writes:
|> m...@justinbogner.com wrote:
|> | Bind is a sequencing operator rather than an application operator.
|>
|> In my opinion, this is a common misconception. I think that bind would
|> be nicer if its arguments were reversed.
|
| If this is a misconception, why does thinking of it this way work so
| well? This idea is reinforced by the do notation syntactic sugar: bind
| can be represented by going into imperative land and "do"ing one thing
| before another.

An imperative-looking notation does not make something imperative.

Thinking of bind as sequencing really *doesn't* work very well. What
does bind have to do with sequencing at all in the list monad, for
example? What about the reader monad?

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLJYQACgkQye5hVyvIUKlGmACeJTP/Oj7F0tuoN+CdrzJeZ/fU
AXgAn3Z5E1X1GDs96BgmHeqqEVVh0FSW
=Zt4V
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gleb Alexeyev wrote:
| Perhaps my example doesn't work, so I'll try another example.
| As you know, (>>=) is just an (overloaded) higher-order function.
| Let's consider another higher-order function, map. The expression
|  > map (\x -> 42) [1..3]
| evaluates to [42, 42, 42].
| As you can see, the function (\x -> 42) passed to map ignores its first
| argument. Would you expect the compiler to discard the call to map?

In fact, this can even be rewritten with bind:

~[1..3] >>= \x -> return 42

So if you wouldn't expect the map to be discarded, certainly the bind
should not be either.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLJQgACgkQye5hVyvIUKlUNQCgp6T0BCs00rYS3ygprs5rs3VM
mrgAoMo1AgLTTeosXV8dQa+1BljcpfQy
=o3iZ
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Jeremy Shaw]

At Thu, 5 Feb 2009 11:06:22 -0600,
Gregg Reynolds wrote:

> Are you saying that using equations to add a level of indirection
> prevents optimization?  I still don't see it - discarding x doesn't
> change the semantics, so a good compiler /should/ do this.  How is
> this different from optimizing out application of a constant function?

Let rewrite this:

  'getChar >>= \x -> getChar'

in a slightly different looking form, where bind = (>>=) so that we have:


 bind getChar (\x -> getChar)

If I understand your argument, you think that the compiler should be
able to look at that expression, and instead of calling 'bind' with
the two arguments 'getChar' and '(\x -> getChar)' it should just
optimize it to 'getChar'?

By comparision, consider this function:

 op :: Maybe a -> (a -> Maybe b) -> Maybe b
 op x f = Nothing


I believe that by your argument we should be able to rewrite this:

   (Just "foo") `op` \x -> (Just "bar")

as:

   (Just "bar")

because the 'x' is ignored? But, 'op' *always* returns Nothing, and
clearly Nothing /= (Just "bar")?

Maybe I misunderstanding what you mean when you say that 'discarding
x does not change the semantics'.

Thanks!
- jeremy








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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 11:12 AM, Andrew Wagner  wrote:
>
>
>> Are you saying that using equations to add a level of indirection
>> prevents optimization?  I still don't see it - discarding x doesn't
>> change the semantics, so a good compiler /should/ do this.  How is
>> this different from optimizing out application of a constant function?
>
> No, no compiler should change "getChar >>= \x -> getChar" to just getChar,
> because it's just wrong. The first will try to read in two values of type
> Char, the second will only try to read one. Side effects aren't THAT hated!

Right, but that's only because the compiler either somehow knows about
side effects or there is some other mechanism - e.g. an implicit World
token that gets passed around - that prevents optiimization.  As far
as the formal semantics of the language are concerned, there's no
essential difference between  "getChar >>= \x -> getChar" and " Foo 3
>>= \x -> Foo 7 " for some data constructor Foo.  I should think the
latter would be optimized; if so, why not the former?  The presence of
some hidden (from me, anyway) semantics is inescapable.

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

[Haskell-cafe] Re: evaluation semantics of bind

[Gleb Alexeyev]

Gregg Reynolds wrote:


Are you saying that using equations to add a level of indirection
prevents optimization?  I still don't see it - discarding x doesn't
change the semantics, so a good compiler /should/ do this.  How is
this different from optimizing out application of a constant function?



Perhaps my example doesn't work, so I'll try another example.
As you know, (>>=) is just an (overloaded) higher-order function.
Let's consider another higher-order function, map. The expression
> map (\x -> 42) [1..3]
evaluates to [42, 42, 42].
As you can see, the function (\x -> 42) passed to map ignores its first 
argument. Would you expect the compiler to discard the call to map?


Can you see the analogy? The shapes of the two expressions, map (\x -> 
42) [1..3] and (>>=) getChar (\x -> getChar) are similar.


(>>=) is a combinator just like map, you cannot optimize it away in general.

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Andrew Wagner]

Are you saying that using equations to add a level of indirection
> prevents optimization?  I still don't see it - discarding x doesn't
> change the semantics, so a good compiler /should/ do this.  How is
> this different from optimizing out application of a constant function?
>

No, no compiler should change "getChar >>= \x -> getChar" to just getChar,
because it's just wrong. The first will try to read in two values of type
Char, the second will only try to read one. Side effects aren't THAT hated!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 10:49 AM, Gleb Alexeyev  wrote:
> Gregg Reynolds wrote:
>  > I must be misunderstanding something.  I don't know if it would be
>>
>> optimized out, but I see no reason why it couldn't be.  There's no data
>> dependency, right?
>
> Of course there is data dependency. In my example, where IO is defined as a
> (generalized) algebraic datatype, the value of getChar is GetChar.
> The value of 'getChar >>= \x -> getChar' is 'Bind GetChar (\x -> GetChar'.
> 'x' is not used anywhere, but this doesn't change the fact that these are
> totally different values, no sane compiler would prove them equal.

Are you saying that using equations to add a level of indirection
prevents optimization?  I still don't see it - discarding x doesn't
change the semantics, so a good compiler /should/ do this.  How is
this different from optimizing out application of a constant function?

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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[mail]

Oops, sent this off list the first time, here it is again.

Jake McArthur  writes:
> m...@justinbogner.com wrote:
> | Bind is a sequencing operator rather than an application operator.
>
> In my opinion, this is a common misconception. I think that bind would
> be nicer if its arguments were reversed.

If this is a misconception, why does thinking of it this way work so
well? This idea is reinforced by the do notation syntactic sugar: bind
can be represented by going into imperative land and "do"ing one thing
before another.

The fact that `x' may not actually have to happen before `f' is merely
the typical sort of optimization we do in compilers for imperative
languages: instructions that do not modify non-local state can be
re-ordered, but IO cannot because it jumps elsewhere, no?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: evaluation semantics of bind

[Gleb Alexeyev]

Gregg Reynolds wrote:
 > I must be misunderstanding something.  I don't know if it would be
optimized out, but I see no reason why it couldn't be.  There's no data 
dependency, right?


Of course there is data dependency. In my example, where IO is defined 
as a (generalized) algebraic datatype, the value of getChar is GetChar.
The value of 'getChar >>= \x -> getChar' is 'Bind GetChar (\x -> 
GetChar'. 'x' is not used anywhere, but this doesn't change the fact 
that these are totally different values, no sane compiler would prove 
them equal.


For some monads, the evaluation of 'a >>= \x -> b' yields b, but it's 
not true in general.


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

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

m...@justinbogner.com wrote:
| Bind is a sequencing operator rather than an application operator.

In my opinion, this is a common misconception. I think that bind would
be nicer if its arguments were reversed.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLF0oACgkQye5hVyvIUKnTeACfW3Kvlz2PLTQ6RzPGdF+aDRPa
IKoAn2X7STrrKDUO3s9yUP5weTHcaG3Z
=bBXE
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 10:26 AM,   wrote:
>
> x >>= f does not mean "apply f to x", it means "do x, and then do f with
> the result of x". Bind is a sequencing operator rather than an
> application operator.

Sequencing is a side effect of data dependency.  What I should have
said is x >>= f means "evaluate x and f (in any order), /then/ apply f
to x".  In a non-IO monad, x can be discarded if f does not depend on
it.

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

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 10:00 AM, Lennart Augustsson
 wrote:
>
> There's nothing magic about IO when it comes to monad semantics.
> If you take ghc's implementation of IO, it's a state monad.

Doesn't that mean the semantics are defined by the implementation?  My
problem is that I'm not seeing how correct eval sequencing can be
forced unless a magic token is passed around, which means that /some/
such hidden semantics must be part of the formal semantics of IO.  In
other words, it's not enough for it to be a monad, since >>= by itself
cannot guarantee data dependency.  If it doesn't pass around the World
token, we don't get sequencing.

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

[Haskell-cafe] Re: evaluation semantics of bind

[mail]

Gregg Reynolds  writes:
> I think I've just about got monads figured out, but there's one detail that
> still escapes me.  As I understand it, a monad is a kind of programming trick
> the uses data dependency to force evaluation order.  x >>= f means apply f to
> x; since the value of f x depends on the value of x, the evaluator must
> evaluate x before f x. However, consider:
>
> getChar >>= \x -> getChar
>

x >>= f does not mean "apply f to x", it means "do x, and then do f with
the result of x". Bind is a sequencing operator rather than an
application operator.

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

Re: [Haskell-cafe] evaluation semantics of bind

[Jeremy Shaw]

Hello,

The type IO (in many Haskell implemenations) is essentially:

> type IO a  =  RealWorld -> (a, RealWorld)

And >> would be implemented like:

> (>>) :: IO a -> IO b -> IO b
> action1 >>= action2 = \world0 ->
>   let (a, world1) = action1 world0
>   (b, world2) = action2 world1
>   in (b, world2)

So, even though action2 does not depend on the 'a' value returned by
action1, it does depend on the world value. Hence, the compiler will
not optimize away the call to action1, because then it would not have
a 'world1' value to pass to action2.

It is the passing around of these 'world*' values that causes the IO
operations to happen in the right order.

Of course, this only works if the programmer is careful to ensure that
each world variable is used exactly once, and that no functions are
accidently skipped, etc. For example, lets say that (>>) was
accidently defined like:

> (>>) :: IO a -> IO b -> IO b
> action1 >>= action2 = \world0 ->
>   let (a, world1) = action1 world0
>   (b, world2) = action2 world0 -- oops, should be world1
>   in (b, world2)

now action1 would not be run. Since it is so easy to accidently screw
up the passing around of world variables, we don't do it 'by hand'. We
get it right once in the Monad instance, and then we don't have to
worry about it anymore.

- jeremy



At Thu, 5 Feb 2009 09:20:06 -0600,
Gregg Reynolds wrote:
> 
> [1  ]
> [1.1  ]
> I think I've just about got monads figured out, but there's one detail that
> still escapes me.  As I understand it, a monad is a kind of programming
> trick the uses data dependency to force evaluation order.  x >>= f means
> apply f to x; since the value of f x depends on the value of x, the
> evaluator must evaluate x before f x. However, consider:
> 
> getChar >>= \x -> getChar
> 
> An optimizer can see that the result of the first getChar is discarded and
> replace the entire expression with one getChar without changing the formal
> semantics.  But that would change the behavior, so to get the desired
> behavior, there must be some principle that prevents this from happening,
> ensuring that x >>= f always evaluates f x.
> 
> I can see that the monad laws ensure this But I haven't found anything that
> states this.  Am I missing something?
> 
> Thanks,
> 
> gregg
> [1.2  ]
> 
> [2  ]
> ___
> 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: evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 9:53 AM, Gleb Alexeyev wrote:

> Let's imagine that IO datatype is defined thus:
>
> >{-# LANGUAGE GADTs #-}
> >{-# LANGUAGE NoImplicitPrelude #-}
>
> >import Prelude(Monad, Char)
> >data IO a where
> >GetChar :: IO Char
> >Bind :: IO a -> (a -> IO b) -> IO b
>
> >getChar = GetChar
> >(>>=) = Bind
>
> It is perfectly possible to construct IO actions as values of this data
> type and execute them by some function evalIO :: IO -> Prelude.IO with the
> obvious definition. Now the question arises: do you think
> getChar >>= \x -> getChar would be optimized to getChar by compiler?
>

I must be misunderstanding something.  I don't know if it would be optimized
out, but I see no reason why it couldn't be.  There's no data dependency,
right?

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

Re: [Haskell-cafe] Monad explanation

[Gregg Reynolds]

On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe  wrote:

>
> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote:
>
>> That's a fairly common representation, seems to work for lots of people,
>> but it caused me no end of trouble.  Values are mathematical objects; how, I
>> asked myself, can they possibly /be/ programs that do IO (or actions, or
>> computations, or )?  It doesn't make sense, says I,
>>
>
> without reference to the rest of your message, of course values can /be/
> programs.


Not "programs", but "programs that do IO".  The point of the idiom is that
there's an external side effect involved.  What sticks in my craw is that "a
mathematical value with a non-mathematical side effect" is, well,
non-mathematical and possibly nonsensical.  I know it works for some (most?)
people, but for me it lacks Geometry and Theology.

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

Re: [Haskell-cafe] evaluation semantics of bind

[Jake McArthur]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Gregg Reynolds wrote:
| As I understand it, a monad is a kind of programming trick the uses
data dependency to force evaluation order.

Actually, a monad does nothing more than supply some combinators. These
combinators (and some trivial laws) are all you really need to know to
understand monads. Specific monads are really just a case-by-case issue.

Using some function names that are not used in the standard Haskell
libraries, here are the important functions you have access to when you
have a monad, all of which return monadic values:

~point ::   a -> f a
~map   ::   (a ->   b) -> f a -> f b
~apply :: f (a ->   b) -> f a -> f b
~bind  ::   (a -> f b) -> f a -> f b

I aligned the type signatures the way I did so you could see their
similarities and differences more easily.

point is the same as the return and pure functions. It lifts a pure value.

map is the same as the (<$>), fmap, liftA, and liftM functions. It
applies a pure function to a lifted value.

apply is the same as the (<*>) and ap functions. It applies a lifted
function to a lifted value.

The type signature for bind is reversed from that of (>>=). It's the
same as (=<<). I think it is more clear and better parallels the other
functions I've already shown. It applies a "lifting" function to a
lifted value.

| since the value of f x depends on the value of x, the evaluator must
evaluate x before f x

This is actually not true. Remember, Haskell is a lazy language. x need
not be evaluated before applying f to it.

| However, consider:
|
| getChar >>= \x -> getChar
|
| An optimizer can see that the result of the first getChar is discarded
and replace the entire expression with one getChar without changing the
formal semantics.

Consider how this expression would actually look in a Haskell program:

~main :: IO ()
~main = getChar >>= \x -> getChar

Remember, a type coincides with a value. That is, the entire main
function is a _value_ of type IO (). The value, as it so happens, is an
imperative program which the Haskell runtime performs. That is, the
reduction semantics of IO expressions _produce_, rather than perform,
actions. The actions are only performed by the runtime. Every monad has
a "run" function. The IO monad's run function is the Haskell runtime.

If you think of the IO monad as some sort of Writer monad, it is easy to
see that Haskell's reduction semantics actually guarantee correct order
of operations, and a semantics-preserving optimizer will not change it.

In GHC, the IO monad is actually more like a State monad (over
RealWorld). It is also easy to see that this preserves correct ordering
of side-effects as well. I just wanted to present a different point of view.

- - Jake
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLDpMACgkQye5hVyvIUKnUpwCfdAycTBv29wVt+J5VHZbNEQ3H
80kAnj7u7HS+5S1qxgzB90I7v+ftuazo
=poXT
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Lennart Augustsson]

There's nothing magic about IO when it comes to monad semantics.
If you take ghc's implementation of IO, it's a state monad.
The new state generated by x is passed to f, so there's no way to skip x.
(Well, if the compiler can show that the state is not used anywhere
then it can start removing things, but in that case there really is no
change in semantics.)

  -- Lennart

2009/2/5 Gregg Reynolds :
> On Thu, Feb 5, 2009 at 9:27 AM, Bulat Ziganshin 
> wrote:
>>
>> Hello Gregg,
>>
>> Thursday, February 5, 2009, 6:20:06 PM, you wrote:
>>
>> > An optimizer can see that the result of the first getChar is
>> > discarded and replace the entire expression with one getChar without
>> > changing the formal semantics.
>>
>> this is prohibited by using pseudo-value of type RealWorld which is
>> passed through entire action stream. actually, order of execution is
>> controlled by dependencies on this values
>>
>> http://haskell.org/haskellwiki/IO_inside
>>
> Thanks.  I actually read that a few weeks ago and forgot all about it.  So
> the gist is that type IO has special magic semantics.  Formal, but hidden.
> Which means monad semantics are built in to the language, at least for that
> type.  The Haskell Report doesn't seem to say anything about this, which
> seems odd.
>
> But then for non-IO monads, the optimization would be allowed, no?  Of
> course; only the IO monad has external world behavior.
>
> Thanks,
>
> gregg
>
> ___
> 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: Fastest regex package?

[Eugene Kirpichov]

I was wrong about BoyerMoore: it works about 2x faster than PCRE for
this example, so seems like it does the trick (although I suspect that
one could do even faster, so the question remains).

2009/2/5 Eugene Kirpichov :
> Hello.
>
> What is the fastest regex package of the multitude of packages present
> on Hackage (namely, PCRE, PCRE-light, DFA, TDFA and many more)?
>
> My benchmark (parsing a huge logfile with a regex like "GET
> /foo.xml.*fooid=([0-9]++).*barid=([0-9]++)") shows that plain PCRE is
> the fastest one (I tried PCRE, PCRE-light and TDFA; DFA can't do
> capturing groups at all, TDFA was abysmally slow (about 20x slower
> than PCRE), and it doesn't support ++), but maybe have I missed any
> blazing-fast package?
>
> Even PCRE seems somewhat too slow to me - matching this regex eats 50%
> of the program time; considering that the only things it does is
> ungzipping the log and searching for the regex, this seems like far
> too much, the regex is not that complex to my mind. I tried to replace
> this regex by Data.ByteString.Search.KnuthMorrisPratt and BoyerMoore
> from stringsearch, but they work even twice slower.
>
> I also noticed that PCRE does about 2x fewer allocations than
> PCRE-Light, but is not much faster.
> However, PCRE, strangely, has a non-pure interface, I had to use it
> with unsafePerformIO.
>
> It's a pity I can't put these findings on haskellwiki to
> http://www.haskell.org/haskellwiki/Regular_expressions since I don't
> have an account and new accounts can't be created right now. Could
> anyone put them there?
>
> All in all, my question remains: what is the fastest way to do this
> kind of parsing on a lazy bytestring?
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: evaluation semantics of bind

[Gleb Alexeyev]

Gregg Reynolds wrote:

 However, consider:

getChar >>= \x -> getChar

An optimizer can see that the result of the first getChar is discarded 
and replace the entire expression with one getChar without changing the 
formal semantics.


Let's imagine that IO datatype is defined thus:

>{-# LANGUAGE GADTs #-}
>{-# LANGUAGE NoImplicitPrelude #-}

>import Prelude(Monad, Char)
>data IO a where
>GetChar :: IO Char
>Bind :: IO a -> (a -> IO b) -> IO b

>getChar = GetChar
>(>>=) = Bind

It is perfectly possible to construct IO actions as values of this data 
type and execute them by some function evalIO :: IO -> Prelude.IO with 
the obvious definition. Now the question arises: do you think

getChar >>= \x -> getChar would be optimized to getChar by compiler?
If no, why would GHC want to do this optimization for standard IO?




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

Re: [Haskell-cafe] Switching from Mercurial to Darcs

[Roman Cheplyaka]

* Peter Verswyvelen  [2009-02-05 16:35:34+0100]
> On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde  wrote:
> 
> > Peter Verswyvelen  writes:
> >
> > > 1) hg st
> >
> >  darcs cha -s
> 
> 
> That seems to list all changes in the history.
> 
> hg st lists local changes only. Can be done using darcs?

darcs whatsnew -s


-- 
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] evaluation semantics of bind

[Gregg Reynolds]

On Thu, Feb 5, 2009 at 9:27 AM, Bulat Ziganshin
wrote:

> Hello Gregg,
>
> Thursday, February 5, 2009, 6:20:06 PM, you wrote:
>
> > An optimizer can see that the result of the first getChar is
> > discarded and replace the entire expression with one getChar without
> > changing the formal semantics.
>
> this is prohibited by using pseudo-value of type RealWorld which is
> passed through entire action stream. actually, order of execution is
> controlled by dependencies on this values
>
> http://haskell.org/haskellwiki/IO_inside
>
> Thanks.  I actually read that a few weeks ago and forgot all about it.  So
the gist is that type IO has special magic semantics.  Formal, but hidden.
Which means monad semantics are built in to the language, at least for that
type.  The Haskell Report doesn't seem to say anything about this, which
seems odd.

But then for non-IO monads, the optimization would be allowed, no?  Of
course; only the IO monad has external world behavior.

Thanks,

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

Re: [Haskell-cafe] Re: Purely funcional LU decomposition

[Rafael Gustavo da Cunha Pereira Pinto]

On Wed, Feb 4, 2009 at 05:15, Neal Alexander  wrote:

> Array is no good man! Quad Tree matrices perform much nicer from what I've
> seen.
>
> I wrote some matrix stuff based on D. Stott Parker's "Randomized Gaussian
> elimination" papers 
> (http://www.cs.ucla.edu/~stott/ge/).
> He presents some recursive block based methods of solving without pivoting.
>
> I want to upload the full library to Hackage, but it'd be nice to have some
> people look through it before - mainly because i never took linear algebra
> heh. QuickCheck seems to be holding things together though.
>
>

I read some of those papers and, yes, it is impressive. OTOH, I really need
pivoting (some ill-conditioned matrices are expected), which they all claim
to be hard to implement using quadtrees and I'm afraid that using RBTs might
introduce other sources of error.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe