date:20111230


On 12/29/2011 07:07 PM, Steve Horne wrote:

On 29/12/2011 10:05, Jerzy Karczmarczuk wrote:

Sorry, a long and pseudo-philosophical treatise. Trash it before reading.

Heinrich Apfelmus:

You could say that side effects have been moved from functions to
some other type (namely IO) in Haskell.

I have no reason to be categorical, but I believe that calling the
interaction of a Haskell programme with the World - a side effect is
sinful, and it is a source of semantical trouble.

People do it, SPJ (cited by S. Horne) did it as well, and this is too
bad.
People, when you eat a sandwich: are you doing side effects?? If you
break a tooth on it, this IS a side effect, but neither the eating nor
digesting it, seems to be one.


By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but nonetheless the jargon meaning is correct within
programming and has been for decades. It's not going to go away.



This doesn't sound right to me. To me, a side effect is something 
which happens as a (intended or unintended) consequence of something 
else. An effect which you want to happen (e.g. by calling a procedure, 
or letting the GHC runtime interpreting an IO Int) is just an effect.



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

Re: [Haskell-cafe] On the purity of Haskell


On 12/29/2011 11:06 PM, Steve Horne wrote:

On 29/12/2011 21:01, Chris Smith wrote:

On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote:

By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but nonetheless the jargon meaning is correct within
programming and has been for decades. It's not going to go away.

Basically, the jargon definition was coined by one of the pioneers of
function programming - he recognised a problem and needed a simple way
to describe it, but in some ways the choice of word is unfortunate.

I don't believe this is true. Side effect refers to having a FUNCTION
-- that is, a map from input values to output values -- such that when
it is evaluated there is some effect in addition to computing the
resulting value from that map. The phrase side effect refers to a
very specific confusion: namely, conflating the performing of effects
with computing the values of functions.

Yes - again, by definition that is true. But that definition is not the
everyday definition of side-effect.


 Repeating and explaining one

definition doesn't make the other go away.



That's what you seem to be doing a lot in this thread. It's very hard to 
glean what *exactly* you're trying to argue since you seem to be all 
over the place.


(I hope this isn't taken as an insult, it certainly isn't meant as one.)

Maybe a summary of your argument + counter-arguments (as you understand 
them) on a wiki would be helpful? Mail threads with 40+ posts aren't 
really useful for hashing out this kind of thing.




1. To say that the C printf function has the side-effect of printing to
the screen - that's true.


No, it has the effect of printing to the screen. When you call 
printf() you *intend* for it to print something.



2. To say that the C printf function has no side-effects because it
works correctly - the only effects are intentional - that's also true.



I realize this is nitpicking, but all of its effects may not be 
intentional. For example, given certain terminal settings it may also 
flush the buffer if you have a newline in the argument string. That's a 
side effect (may be desirable/undesirable).


[--snip--]

Using similar mixed definitions to conclude that every C program is full
of bugs (basically equating intentional effects with side-effects, then
equating side-effects with unintentional bugs) is a fairly common thing
in my experience, but it's a logical fallacy. If you aren't aware of the
two definitions of side-effect, it's hard to get deal with that.

Some people don't want anyone to figure out the fallacy - they like
having this convenient way to attack C, irrespective of whether it's
valid or not. Rare I think - mostly it's more confusion and memetics.
But still, I'm convinced there's some sophistry in this. And I'm not the
only person to think so, and to have reacted against that in the past.

Extra sad - you don't need that fallacy to attack C. It's redundant. C
is quite happy to demonstrate its many failings.


That's the flimsiest straw man I've ever seen.


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

Re: [Haskell-cafe] On the purity of Haskell /Random generators


On 12/29/2011 09:39 PM, Jerzy Karczmarczuk wrote:


Truly random numbers are very rarely used, forget about them.


Well, obviously, but why should we forget about them? The usual 
approach(*) is to gather entropy from a truly(**) random source

and use that to seed (and perhaps periodically re-seed) a PRNG.

(*) At least as far as I understand it.
(**) At least one believed to be truly random.

My point was simply to make clear the distinction between RNG vs. PRNG.


Standard r. generators (pseudo-random) in Haskell are monadic, because
the relevant algorithms are stateful.
Congruential, Fibonacci, Mersenne Twister, whatever, is a function, more
or less:
(newValue,newSeed) = rgen seed

The monadic approach serves mainly to hide the seed.
Some people prefer to use random streams, no monads, so the question of
Steve Horne is not universal.


Random streams are not referentially transparent, though, AFAICT...?

Either way this thread has gone on long enough, let's not prolong it 
needlessly with this side discussion.



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

Re: [Haskell-cafe] Overloaded Quotes for Template Haskell

2011-12-30 Thread James Cook

One possible option would be to make a library that has all the combinators 
lifted to your more general type and use lift or runQ or something similar 
for any quotes that need lifting, along with operations from monad-control or 
monad-peel to lift quotes that also need access to the StateT layer in the 
splice.  It's a bit messier and those libraries are brain-bending at first 
(although definitely worth learning about), but it would allow you to code in 
the style you're talking about with a relatively small amount of extra 
syntactic clutter.

-- James

On Dec 29, 2011, at 9:51 PM, Michael D. Adams wrote:

 What would it take to get an -XOverloadedQuotes flag of the same
 sort as the -XOverloadedStrings flag?  I.e. [| ... |] would have
 type Quasi m = m Exp instead of Q Exp and any splices in that
 quotation expect the contents of that splice to have type m Exp.
 (Obviously, top level splices would still have type Q Exp otherwise
 the compiler wouldn't know how to evaluate the monad.)
 
 I ran into this problem when writing a Template Haskell program in
 which part of it operates in a StateT S Q a monad instead of the
 usual Q a monad.  (The S type stores the state of a memoization
 table of code fragments already generated.  Without it, the code would
 loop infinitely when processing certain recursive structures.)
 
 It is fairly easy to declare an instance of Quasi for StateT S Q,
 so in order to keep the code clean, I'd like to use quotations with
 splices in them (i.e. [| ... $( ... ) ... |] ) for expressing the
 generated code.  However, quotations and splices are tied to the Q
 monad which means that as it is now I have to manually write LamE ...
 VarP ... VarE ... etc. instead of using the much nicer quotation
 syntax.
 
 Michael D. Adams
 mdmko...@gmail.com
 
 ___
 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] On the purity of Haskell


On Dec 29, 2011, at 2:16 PM, Steve Horne wrote:
 
 Of course you can extract values out of IO actions to work with them - the 
 bind operator does this for you nicely, providing the value as an argument to 
 the function you pass to the right-hand argument of the bind. But that 
 function returns another IO action anyway - although you've extracted a value 
 out and the value affects a computation, all you can do with it in the long 
 run is return another IO action.
 
 Even so, that value can only be extracted out at run-time, after the action 
 is executed.
 
 So, consider the following...
 
 getAnIntFromTheUser :: IO Int
 
 From a pure functional point of view, that should return the same action 
 every time. Well, the partially evaluated getAnIntFromTheUser has the same 
 structure each time - but the actual Int packaged inside the action isn't 
 decided until runtime, when the action is executed. At compile-time, that 
 action can only be partially evaluated - the final value OF THE ACTION 
 depends on what Int the user chooses to give because that Int is a part of 
 the action value.

Howdy Steve,

You are correct that Haskell is not, strictly speaking pure - no language 
that does anything useful (e.g. IO) can possibly be purely functional.  But 
there seems to be a certain amount of language policing in the Haskell 
community - pure means what we mean when we use it to describe Haskell, and 
don't you dare use it otherwise.  Ok, but that just leads to riddles like when 
is a pure language impure?  A: when it isn't pure.

Several posts to this thread have insisted that IO values are really values 
like any other values, can be reasoned about, etc. and that the process 
yielding the value (including possible side-effects) is therefore irrelevant or 
secondary or etc..  Well, you can reason about them indirectly, by virtue of 
their types, but you can't reason about the values themselves, because they are 
non-deterministic and undecidable.  And the process clearly is relevant, since 
it motivates the use of the value in the first place.  Not much point in a pure 
IO value that does not cause IO, and if the side effects were truly irrelevant 
to the use of such values then we would not need monads to order their 
evaluation.  So the argument that all of Haskell is immaculately, purely 
functional is pure hooey, for me at least.  I completely understand what people 
mean when they talk like this; I just think it's a misuse of English.

Now one way of understanding all this is to say that it implicates the 
static/dynamic (compile-time/run-time) distinction: you don't know what e.g. IO 
values are until runtime, so this distinction is critical to distinguishing 
between pure and impure.  I gather this is your view.

I think that is reasonable, but with the caveat that it must be at the right 
level of abstraction.  I don't think ASTs etc. enter into it - those are 
implementation techniques, and the only generalization we can apply to 
compilers is that they do implement the language definition, not how they do it 
(not all C compilers use ASTs).  The right level of abstraction (IMHO) is the 
distinction between atemporality and temporality.  The functional stuff is 
atemporal, which means among other things that evaluation is unordered 
(evaluation being a temporal process).  Adding IO etc. capabilities to the 
purely functional fragment of a language infects it with temporality.  But we 
can model temporality using order, so we can dispense with the notion of 
run-time and say that IO etc. stuff adds an ordered fragment to the unordered 
fragment.  One goal of the language is then to enforce a strict correspondence 
between the order of events outside the program (e.g. keystrokes) and events 
inside the program (getchar).

The beauty of the monad solution is not that it magically transforms 
non-functional stuff like IO into functional stuff, but that it exploits type 
discipline to make such operations *mimic* purely functional stuff in a sense - 
but only at the level of typing.  Impure operations then have purely functional 
type discipline while remaining essentially non-functional.  So I think of 
Haskell as a quasi-pure or hybrid language.  C on the other hand is totally 
impure (except for predefined constants like '1').  For totally pure languages 
you have to look elsewhere, e.g. logics - there are no pure programming 
languages.

It's fairly easy to grasp the point by going back to Turing's original insight. 
 The cornerstone of his ideas was not the machine but the human calculator 
working with pencil and paper, finite memory, etc.  So to see the diff all you 
have to do is think about what a human does with a problem (program) written on 
paper.  Give the human calculator a computable task - add 2+2 - and you can be 
confident you will receive a definite answer in a finite amount of time.  Lard 
this with a non-computable step - add 2 + 2 + getInt - and all bets are off.  
In this case,

Re: [Haskell-cafe] On the purity of Haskell

Gregg Reynolds d...@mobileink.com писал(а) в своём письме Fri, 30 Dec  
2011 17:23:20 +0200:


Regarding side-effects, they can be (informally) defined pretty simply:   
any non-computational effect caused by a computation is a side-effect.


I wonder: can writing to memory be called a “computational effect”? If  
yes, then every computation is impure. If no, then what’s the difference  
between memory and hard drive?


By the way, the Data.HashTable is in IO monad. Is it impure? Would it be  
pure if designers had chosen to use ST instead?


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

Re: [Haskell-cafe] (...) Random generators

2011-12-30 Thread Jerzy Karczmarczuk


Bardur Arantsson:

Random streams are not referentially transparent, though, AFAICT...?

Either way this thread has gone on long enough, let's not prolong it 
needlessly with this side discussion. 


Sure.
But the discussion on randomness is /per se/ interesting, especially in 
a functional setting.


Anyway, nobody can convince Steve Horne. Perhaps as an unintentional  
side-effect...


But random streams, or rather pseudo-random streals (infinite lazy 
lists, as the example I gave, the `iterate` of `next`) are as 
referentially transparent as any Haskell data. Really.


What I find really amazing, since I converted my soul from physics to 
computer since (many, many years ago...) is that most comments about 
random number generators come from people who don't need them, don't use 
them, and usually don't care about them...
I taught random numbers, and I did some Monte-Carlo calculation in High 
Energy Physics, when many people here were not born. I *NEVER* used 
true random numbers, even to initialize a generator, since in the 
simulation business it is essential that you can repeat the sequence on 
some other platform, with some other parameters, etc.


Of course, they are useful (don't need to convince an ancien 
physicist... And I lied. I used them, e.g. when I programmed some games 
for my children.) --


but why should we forget about them? The usual approach(*) is to 
gather entropy from a truly(**) random source

and use that to seed (and perhaps periodically re-seed) a PRNG.
So, sorry, I didn't mean really forget, only to change the subject 
which was irrelevant for the purity (but somehow has shown once more 
that Steve Horne had strange ideas about random generators).


The generator of L'Ecuyer, or Mersenne Twister, or anything, don't care 
about the entropy. For a typical user, the only interesting thing is 
that the random streams pass the usual statistical tests : moments, 
correlation, spectrum... Otherwise it is as deterministic as 1 2 3 4. 
(For a typical user from my mafia. The mafia of cryptographists has 
different criteria ; from time to time we shoot ourselves in the 
coffee-machine corner of our dept.)


Thank you for the discussion. You are right, I brake.

Jerzy


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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 10:34 AM, Artyom Kazak wrote:

 Gregg Reynolds d...@mobileink.com писал(а) в своём письме Fri, 30 Dec 2011 
 17:23:20 +0200:
 
 Regarding side-effects, they can be (informally) defined pretty simply:  any 
 non-computational effect caused by a computation is a side-effect.
 
 I wonder: can writing to memory be called a “computational effect”? If yes, 
 then every computation is impure. If no, then what’s the difference between 
 memory and hard drive?
 

Great question!  It suggests that the line between computation and its side 
effects is not as clear-cut as we (well, I) thought.

If computations are Platonistic, mathematico-logical things, then is actual 
computation a side-effect of the Platonic Idea?  Heh heh.

 By the way, the Data.HashTable is in IO monad. Is it impure? Would it be pure 
 if designers had chosen to use ST instead?

Dunno, somebody else will have to answer that one.

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, 2011-12-30 at 18:34 +0200, Artyom Kazak wrote:
 I wonder: can writing to memory be called a “computational effect”? If  
 yes, then every computation is impure. If no, then what’s the difference  
 between memory and hard drive?

The difference is that our operating systems draw an abstraction
boundary such that memory is private to a single program, while the hard
drive is shared between independent entities.  It's not the physical
distinction (which has long been blurred by virtual memory and caches
anyway), but the fact that they are on different sides of that
abstraction boundary.

-- 
Chris Smith



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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:

Conal Elliott wrote:

I wrote that post to point out the fuzziness that fuels many
discussion threads like this one. See also http://conal.net/blog/posts/**
notions-of-purity-in-haskell/http://conal.net/blog/posts/notions-of-purity-in-haskell/and
the
comments.

I almost never find value in discussion about whether language X is
functional, pure, or even referentially transparent, mainly
because those terms are used so imprecisely. In the notions-of-purity
post, I suggest another framing, as whether or not a language and/or
collection of data types is/are denotative, to use Peter Landin's
recommended replacement for functional, declarative, etc. I
included some quotes and a link in that post. so people can track
down what denotative means. In my understanding, Haskell-with-IO is
not denotative, simply because we do not have a
(precise/mathematical) model for IO. And this lack is by design, as
explained in the toxic avenger remarks in a comment on that post.

I often hear explanations of what IO means (world-passing etc), but I
don't hear any consistent with Haskell's actual IO, which includes
nondeterministic concurrency. Perhaps the difficulties could be
addressed, but I doubt it, and I haven't seen claims pursued far
enough to find out.

Personally, the operational semantics given in SPJ's Tackling the Awkward
Squad always struck me as an accurate model of how GHC performs IO.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

It might be accurate, but it's not denotational. - Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 8:12 AM, Conal Elliott co...@conal.net wrote:

On Fri, Dec 30, 2011 at 12:52 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:

Conal Elliott wrote:

I wrote that post to point out the fuzziness that fuels many
discussion threads like this one. See also http://conal.net/blog/posts/*
*notions-of-purity-in-haskell/http://conal.net/blog/posts/notions-of-purity-in-haskell/and
the
comments.

Personally, the operational semantics given in SPJ's Tackling the
Awkward Squad always struck me as an accurate model of how GHC performs IO.

It might be accurate, but it's not denotational. - Conal

Moreover, afaict, the Awkward Squad operational semantics tackles only a
tiny fraction of the IO type.

One of the strengths of Haskell IO is that it can be extended easily via
the FFI. And I guess that strength is also a theoretical weakness in the
sense that only a tiny fraction of the IO interface has even an operational
semantics.

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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 10:19 AM, Conal Elliott wrote:

 
 
 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:
 
 The function
 
  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)
 
 is pure according to the common definition of pure in the context of purely 
 functional programming. That's because
 
  f 42 = f (43-1) = etc.
 
 Put differently, the function always returns the same IO action, i.e. the 
 same value (of type  IO Int) when given the same parameter.
 
 Two questions trouble me:
 
 How can we know whether this claim is true or not?


time t:  f 42   (computational process implementing func application begins…)
t+1:   keystroke = 1
t+2:  43   (… and ends)

time t+3:  f 42
t+4:  keystroke = 2
t+5:  44

Conclusion:  f 42 != f 42

(This seems so extraordinarily obvious that maybe Heinrich has something else 
in mind.)

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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Colin Adams

On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:


 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:


 The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

 Put differently, the function always returns the same IO action, i.e. the
 same value (of type  IO Int) when given the same parameter.




 time t:  f 42   (computational process implementing func application
 begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)

 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44

 Conclusion:  f 42 != f 42

 (This seems so extraordinarily obvious that maybe Heinrich has something
 else in mind.)

 This seems such an obviously incorrect conclusion.

f42 is a funtion for returning a program for returning an int, not a
function for returning an int.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell


 time t:  f 42   (computational process implementing func application
 begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)
 
 
 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44
 
 
 Conclusion:  f 42 != f 42

That conclusion would only follow if the same IO action always produced
the same result when performed twice in a row.  That's obviously untrue,
so the conclusion doesn't follow.  What you've done is entirely
consistent with the fact that f 42 = f 42... it just demonstrates that
whatever f 42 is, it doesn't always produce the same result when you o
it twice.

What Conal is getting at is that we don't have a formal model of what an
IO action means.  Nevertheless, we know because f is a function, that
when it is applied twice to the same argument, the values we get back
(which are IO actions, NOT integers) are the same.

-- 
Chris Smith




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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:

 
 
 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
 
 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:
 
 The function
 
  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)
 
 is pure according to the common definition of pure in the context of 
 purely functional programming. That's because
 
  f 42 = f (43-1) = etc.
 
 Put differently, the function always returns the same IO action, i.e. the 
 same value (of type  IO Int) when given the same parameter.
 
 
 
 
 time t:  f 42   (computational process implementing func application begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)
 
 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44
 
 Conclusion:  f 42 != f 42
 
 (This seems so extraordinarily obvious that maybe Heinrich has something else 
 in mind.)
 
 This seems such an obviously incorrect conclusion.
 
 f42 is a funtion for returning a program for returning an int, not a function 
 for returning an int.


My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you with an 
explanation. ;)

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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Heinrich Apfelmus


Conal Elliott wrote:

Heinrich Apfelmus wrote:


The function

 f :: Int - IO Int
 f x = getAnIntFromTheUser = \i - return (i+x)

is pure according to the common definition of pure in the context of
purely functional programming. That's because

 f 42 = f (43-1) = etc.

Put differently, the function always returns the same IO action, i.e. the
same value (of type  IO Int) when given the same parameter.



Two questions trouble me:

How can we know whether this claim is true or not?

What does the claim even mean, i.e., what does the same IO action mean,
considering that we lack a denotational model of IO?


I think you can put at least these troubles to rest by noting that  f 42 
 and  f (43-1)  are intentionally equal, even though you're not 
confident on their extensional meaning.


The idea is to represent IO as an abstract data type

type IO' a = Program IOInstr a

data Program instr a where
Return :: a - Program instr a
Then   :: instr a - (a - Program instr b) - Program instr b

instance Monad (Program instr) where
return = Return
(Return a)   = g = g a
(i `Then` f) = g = i `Then` (\x - f x = g)

date IOInstr a where
PutChar :: Char - IOInstr ()
GetChar :: IOInstr Char
etc...

So, two values of type  IO' a  are equal iff their program codes are 
equal (= intensional equality), and this is indeed the case for  f 42 
and  f (43-1) . Therefore, the (extensional) interpretations of these 
values by GHC  are equal, too, even though you don't think we know what 
these interpretations are.


(Of course, programs with different source code may be extensionally 
equal, i.e. have the same effects. That's something we would need a 
semantics of IO for.)



Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Colin Adams

On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:


 On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:



 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:


 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:


 The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

 Put differently, the function always returns the same IO action, i.e.
 the same value (of type  IO Int) when given the same parameter.




 time t:  f 42   (computational process implementing func application
 begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)

 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44

 Conclusion:  f 42 != f 42

 (This seems so extraordinarily obvious that maybe Heinrich has something
 else in mind.)

 This seems such an obviously incorrect conclusion.

 f42 is a funtion for returning a program for returning an int, not a
 function for returning an int.


 My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you with
 an explanation. ;)

 -Gregg

Your conclusion is clearly erroneous.

proof: f is a function, and it is taking the same argument each time.
Therefore the result is the same each time.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:11 AM, Chris Smith cdsm...@gmail.com wrote:


  time t:  f 42   (computational process implementing func application
  begins…)
  t+1:   keystroke = 1
  t+2:  43   (… and ends)
 
 
  time t+3:  f 42
  t+4:  keystroke = 2
  t+5:  44
 
 
  Conclusion:  f 42 != f 42

 That conclusion would only follow if the same IO action always produced
 the same result when performed twice in a row.  That's obviously untrue,
 so the conclusion doesn't follow.  What you've done is entirely
 consistent with the fact that f 42 = f 42... it just demonstrates that
 whatever f 42 is, it doesn't always produce the same result when you o
 it twice.


Exactly. Gregg threw in two different executions, which of course can
produce two different values, whether or not the IOs are equal.


 What Conal is getting at is that we don't have a formal model of what an
 IO action means.  Nevertheless, we know because f is a function, that
 when it is applied twice to the same argument, the values we get back
 (which are IO actions, NOT integers) are the same.


And I also raised a more fundamental question than whether this claim of
sameness is true, namely what is equality on IO? Without a precise 
consistent definition of equality, the claims like f 42 == f (43 - 1) are
even defined, let alone true. And since the conversation is about Haskell
IO, I'm looking for a definition that applies to all of IO, not just some
relatively well-behaved subset like putchar/getchar+IORefs+threads.

  - Conal

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote:



 On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:


 On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:



 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:


 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:


 The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

 Put differently, the function always returns the same IO action, i.e.
 the same value (of type  IO Int) when given the same parameter.




 time t:  f 42   (computational process implementing func application
 begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)

 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44

 Conclusion:  f 42 != f 42

 (This seems so extraordinarily obvious that maybe Heinrich has something
 else in mind.)

 This seems such an obviously incorrect conclusion.

 f42 is a funtion for returning a program for returning an int, not a
 function for returning an int.


 My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you
 with an explanation. ;)

 -Gregg

 Your conclusion is clearly erroneous.

 proof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


Careful of circular reasoning here. Is f actually a function in the
mathematical sense? It's that math sense that you need to reach your
conclusion.

BTW, the more I hear words like clearly and obvious, the more I suspect
that fuzziness is being swept under the carpet.

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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Colin Adams

On 30 December 2011 17:27, Conal Elliott co...@conal.net wrote:

 On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams colinpaulad...@gmail.comwrote:


 proof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


 Careful of circular reasoning here. Is f actually a function in the
 mathematical sense? It's that math sense that you need to reach your
 conclusion.

 Yes. Because Haskell is a functional programming language.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:19 AM, Heinrich Apfelmus 
apfel...@quantentunnel.de wrote:

 Conal Elliott wrote:

  Heinrich Apfelmus wrote:

  The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

 Put differently, the function always returns the same IO action, i.e. the
 same value (of type  IO Int) when given the same parameter.


 Two questions trouble me:

 How can we know whether this claim is true or not?

 What does the claim even mean, i.e., what does the same IO action mean,
 considering that we lack a denotational model of IO?


 I think you can put at least these troubles to rest by noting that  f 42
  and  f (43-1)  are intentionally equal, even though you're not confident
 on their extensional meaning.

 The idea is to represent IO as an abstract data type

type IO' a = Program IOInstr a

data Program instr a where
Return :: a - Program instr a
Then   :: instr a - (a - Program instr b) - Program instr b

instance Monad (Program instr) where
return = Return
(Return a)   = g = g a
(i `Then` f) = g = i `Then` (\x - f x = g)

date IOInstr a where
PutChar :: Char - IOInstr ()
GetChar :: IOInstr Char
etc...

 So, two values of type  IO' a  are equal iff their program codes are
 equal (= intensional equality), and this is indeed the case for  f 42 and
  f (43-1) . Therefore, the (extensional) interpretations of these values by
 GHC  are equal, too, even though you don't think we know what these
 interpretations are.

 (Of course, programs with different source code may be extensionally
 equal, i.e. have the same effects. That's something we would need a
 semantics of IO for.)


How do you know that GHC's (or YHC's, etc) interpretation of IO is a
composition of this program code interpretation with some other (more
extensional) interpretation? In particular, how do you know that no IO
primitive can ever distinguish between 42 and 43-1.

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:30 AM, Colin Adams colinpaulad...@gmail.comwrote:



 On 30 December 2011 17:27, Conal Elliott co...@conal.net wrote:

  On Fri, Dec 30, 2011 at 9:20 AM, Colin Adams 
 colinpaulad...@gmail.comwrote:


 proof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


 Careful of circular reasoning here. Is f actually a function in the
 mathematical sense? It's that math sense that you need to reach your
 conclusion.

 Yes. Because Haskell is a functional programming language.


And how do you know that claim to be true?

And do you mean a *purely* functional language? Otherwise f might be in the
impure part. If you do mean *purely* functional, aren't you arguing for
purity by assuming purity?

Moreover, do you have a precise definition for functional? I've witnessed
a lot of these arguments and have seen a diversity of interpretations.
Which is why I recommend shifting away from such fuzzy terms and following
Peter Landin's recommended more precise  substantive replacement, namely
denotative. (See
http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882for
a quote and reference.)

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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:

 
 On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:
 
 On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
 
 
 
 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:
 
 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:
 
 The function
 
  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)
 
 is pure according to the common definition of pure in the context of 
 purely functional programming. That's because
 
  f 42 = f (43-1) = etc.
 
 Conclusion:  f 42 != f 42
 
 (This seems so extraordinarily obvious that maybe Heinrich has something 
 else in mind.)
 
 This seems such an obviously incorrect conclusion.
 
 f42 is a funtion for returning a program for returning an int, not a 
 function for returning an int.
 
 
 My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you with an 
 explanation. ;)
 
 -Gregg
 Your conclusion is clearly erroneous.
 
 proof: f is a function, and it is taking the same argument each time. 
 Therefore the result is the same each time.

That's called begging the question.  f is not a function, so I guess your proof 
is flawed.

It seems pretty clear that we're working with different ideas of what 
constitutes a function.  When I use the term, I intend what I take to be the 
standard notion of a function in computation: not just a unique mapping from 
one input to one output, but one where the output is computable from the input. 
 Any function that depends on a non-computable component is by that 
definition not a true function.  For clarity let's call such critters  
quasi-functions, so we can retain the notion of application.  Equality cannot 
be defined for quasi-functions, for obvious reasons.

f is a quasi-function because it depends on getAnIntFromUser, which is not 
definable and is obviously not a function.  When applied to an argument like 
42, it yields another quasi-function, and therefore f 42 = f 42 is false, or 
at least unknown, and the same goes for f 42 != f 42 I suppose.  

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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:11 AM, Chris Smith wrote:

 
 time t:  f 42   (computational process implementing func application
 begins…)
 t+1:   keystroke = 1
 t+2:  43   (… and ends)
 
 
 time t+3:  f 42
 t+4:  keystroke = 2
 t+5:  44
 
 
 Conclusion:  f 42 != f 42
 
 That conclusion would only follow if the same IO action always produced
 the same result when performed twice in a row.  That's obviously untrue,
 so the conclusion doesn't follow.  What you've done is entirely
 consistent with the fact that f 42 = f 42... it just demonstrates that
 whatever f 42 is, it doesn't always produce the same result when you o
 it twice.
 
 What Conal is getting at is that we don't have a formal model of what an
 IO action means.

Right, and my little counter-example is intended to support that.

  Nevertheless, we know because f is a function

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote:

 On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:
 On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:

 On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:

 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:

 The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

  Conclusion:  f 42 != f 42

 (This seems so extraordinarily obvious that maybe Heinrich has something
 else in mind.)

 This seems such an obviously incorrect conclusion.

 f42 is a funtion for returning a program for returning an int, not a
 function for returning an int.


 My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you
 with an explanation. ;)

 -Gregg

 Your conclusion is clearly erroneous.

 proof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


 That's called begging the question.  f is not a function, so I guess your
 proof is flawed.

 It seems pretty clear that we're working with different ideas of what
 constitutes a function.  When I use the term, I intend what I take to be
 the standard notion of a function in computation: not just a unique mapping
 from one input to one output, but one where the output is computable from
 the input.  Any function that depends on a non-computable component is by
 that definition not a true function.  For clarity let's call such critters
  quasi-functions, so we can retain the notion of application.  Equality
 cannot be defined for quasi-functions, for obvious reasons.

 f is a quasi-function because it depends on getAnIntFromUser, which is not
 definable and is obviously not a function.  When applied to an argument
 like 42, it yields another quasi-function, and therefore f 42 = f 42 is
 false, or at least unknown, and the same goes for f 42 != f 42 I suppose.

 -Gregg


Please don't redefine function to mean computable function. Besides
distancing yourself from math, I don't think doing so really helps your
case.

And on what do you base your claim that getAnIntFromUser is not definable?
Or that applying it (what?) to 42 gives a quasi-function?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 9:43 AM, Conal Elliott co...@conal.net wrote:

 On Fri, Dec 30, 2011 at 9:43 AM, Gregg Reynolds d...@mobileink.com wrote:

 On Dec 30, 2011, at 11:20 AM, Colin Adams wrote:
 On 30 December 2011 17:17, Gregg Reynolds d...@mobileink.com wrote:

 On Dec 30, 2011, at 11:04 AM, Colin Adams wrote:
 On 30 December 2011 16:59, Gregg Reynolds d...@mobileink.com wrote:

 On Fri, Dec 30, 2011 at 12:49 AM, Heinrich Apfelmus 
 apfel...@quantentunnel.de wrote:

 The function

  f :: Int - IO Int
  f x = getAnIntFromTheUser = \i - return (i+x)

 is pure according to the common definition of pure in the context of
 purely functional programming. That's because

  f 42 = f (43-1) = etc.

  Conclusion:  f 42 != f 42

 (This seems so extraordinarily obvious that maybe Heinrich has
 something else in mind.)

 This seems such an obviously incorrect conclusion.

 f42 is a funtion for returning a program for returning an int, not a
 function for returning an int.


 My conclusion holds:  f 42 != f 42.  Obviously, so I won't burden you
 with an explanation. ;)

 -Gregg

 Your conclusion is clearly erroneous.

 proof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


 That's called begging the question.  f is not a function, so I guess your
 proof is flawed.

 It seems pretty clear that we're working with different ideas of what
 constitutes a function.  When I use the term, I intend what I take to be
 the standard notion of a function in computation: not just a unique mapping
 from one input to one output, but one where the output is computable from
 the input.  Any function that depends on a non-computable component is by
 that definition not a true function.  For clarity let's call such critters
  quasi-functions, so we can retain the notion of application.  Equality
 cannot be defined for quasi-functions, for obvious reasons.

 f is a quasi-function because it depends on getAnIntFromUser, which is
 not definable and is obviously not a function.  When applied to an argument
 like 42, it yields another quasi-function, and therefore f 42 = f 42 is
 false, or at least unknown, and the same goes for f 42 != f 42 I suppose.

 -Gregg


 Please don't redefine function to mean computable function. Besides
 distancing yourself from math, I don't think doing so really helps your
 case.

 And on what do you base your claim that getAnIntFromUser is not definable?
 Or that applying it (what?) to 42 gives a quasi-function?


Also:

f is not a function, so I guess your proof is flawed.


Can you support the claim that f is not a function?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:19 AM, Heinrich Apfelmus wrote:

 Conal Elliott wrote:
 Heinrich Apfelmus wrote:
 The function
 
 f :: Int - IO Int
 f x = getAnIntFromTheUser = \i - return (i+x)
 
 is pure according to the common definition of pure in the context of
 purely functional programming. That's because
 
 f 42 = f (43-1) = etc.
 
 Put differently, the function always returns the same IO action, i.e. the
 same value (of type  IO Int) when given the same parameter.
 
 Two questions trouble me:
 How can we know whether this claim is true or not?
 What does the claim even mean, i.e., what does the same IO action mean,
 considering that we lack a denotational model of IO?
 
 I think you can put at least these troubles to rest by noting that  f 42  and 
  f (43-1)  are intentionally equal, even though you're not confident on their 
 extensional meaning.

(I think you meant intensionally).  Ok, I think I can go with that, something 
like f 42 means the sum of 42 and the user input.  And I suppose one could 
argue that the extension of f is well-defined as the set of integer pairs.  But 
that does not make f a (computable) function, because the mapping from domain 
to co-domain remains undefined, dependent as it is on IO.

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

Re: [Haskell-cafe] On the purity of Haskell


On 30/12/2011 10:41, Bardur Arantsson wrote:


This doesn't sound right to me. To me, a side effect is something 
which happens as a (intended or unintended) consequence of something 
else. An effect which you want to happen (e.g. by calling a procedure, 
or letting the GHC runtime interpreting an IO Int) is just an effect.


Trouble is, whether it sounds right doesn't really matter - that's just 
an artifact of the meaning you're most familiar with. Any specialist 
field has it's own jargon, including old words given new 
related-but-different meanings.



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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:43 AM, Conal Elliott wrote:
 roof: f is a function, and it is taking the same argument each time. 
 Therefore the result is the same each time.
 
 That's called begging the question.  f is not a function, so I guess your 
 proof is flawed.
 
 It seems pretty clear that we're working with different ideas of what 
 constitutes a function.  When I use the term, I intend what I take to be the 
 standard notion of a function in computation: not just a unique mapping from 
 one input to one output, but one where the output is computable from the 
 input.  Any function that depends on a non-computable component is by that 
 definition not a true function.  For clarity let's call such critters  
 quasi-functions, so we can retain the notion of application.  Equality cannot 
 be defined for quasi-functions, for obvious reasons.
 
 f is a quasi-function because it depends on getAnIntFromUser, which is not 
 definable and is obviously not a function.  When applied to an argument like 
 42, it yields another quasi-function, and therefore f 42 = f 42 is false, 
 or at least unknown, and the same goes for f 42 != f 42 I suppose.  
 
 -Gregg
 
 Please don't redefine function to mean computable function. Besides 
 distancing yourself from math, I don't think doing so really helps your case.

No redefinition involved, just a narrowing of scope.  I assume that, since we 
are talking about computation, it is reasonable to limit  the discussion to the 
class of computable functions - which, by the way, are about as deeply embedded 
in orthodox mathematics as you can get, by way of recursion theory.  What would 
be the point of talking about non-computable functions for the semantics of a 
programming language?

 And on what do you base your claim that getAnIntFromUser is not definable?

Sorry, not definable might a little strong.  Not definable in the way we can 
define computable functions work better?  In any case I think you probably see 
what I'm getting at.

 Or that applying it (what?) to 42 gives a quasi-function?

I can't think of a way to improve on what I've already written at the moment - 
it too would depend on IO - so if my meaning is not clear, so be it.

Wait, here's another way of looking at it.  Think of IO actions as random 
variables.  So instead of getAnIntFromUser, use X as an integer random variable 
yielding something like:

 f :: Int - IO Int
 f x = X = \i - return (i+x)

I would not call this f a function because I don't think it answers to the 
commonly accepted definition of a function.  Ditto for the result of applying 
it to 42.  Others obviously might consider it a function.  De gustibus non set 
disputandem.

-Gregg

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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Donn Cave

Quoth Steve Horne sh006d3...@blueyonder.co.uk,
 On 30/12/2011 10:41, Bardur Arantsson wrote:

 This doesn't sound right to me. To me, a side effect is something 
 which happens as a (intended or unintended) consequence of something 
 else. An effect which you want to happen (e.g. by calling a procedure, 
 or letting the GHC runtime interpreting an IO Int) is just an effect.

 Trouble is, whether it sounds right doesn't really matter - that's just 
 an artifact of the meaning you're most familiar with. Any specialist 
 field has it's own jargon, including old words given new 
 related-but-different meanings.

It may help to recall that the point of Haskell is to write computer
programs, and by extension the point of discussing its properties
and semantics.  Mostly we intend to refine our understanding of those
properties and semantics;  sometimes we may hope to actually improve
them by questioning things that haven't been, but perhaps could be,
rigorously defined. (That's how I read some of Conal Elliott's recent
posts, for example - but of course, it's still a legitimate question:
does it matter, if we only want to write programs?)

That's why we use terms in a sense that apply meaningfully to computer
programming languages in general and Haskell in particular.  To do
otherwise - for example to insist on a definition of pure that could
not even in principle apply to any useful programming language, or a
definition of side effect that would have to apply every time a
program does anything - seems to me like an inane waste of time, to
put it mildly.

Donn

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

Re: [Haskell-cafe] On the purity of Haskell


On Dec 30, 2011, at 11:21 AM, Conal Elliott wrote:

 
 And I also raised a more fundamental question than whether this claim of 
 sameness is true, namely what is equality on IO? Without a precise  
 consistent definition of equality, the claims like f 42 == f (43 - 1) are 
 even defined, let alone true. And since the conversation is about Haskell IO, 
 I'm looking for a definition that applies to all of IO, not just some 
 relatively well-behaved subset like putchar/getchar+IORefs+threads.

Well, you'll no doubt be glad to know I think I've said about all I need to say 
on this topic, but I'll add one more thing.  Threads like this I often find 
useful even when I disagree vehemently with various parties.  In this case an 
old idea I'd forgotten about was suddenly dislodged by the discussion.  A few 
years ago - the last time I got involved in a discussion on Haskell semantics - 
I spent some time sketching out ideas for using random variables to provide 
definitions (or at least notation) for stuff like IO.  I'm not sure I could 
even find the notes now, but my recollection is that it seemed like a promising 
approach.  One advantage is that this eliminates the kind of informal language 
(like user input) that seems unavoidable in talking about IO.  Instead of 
defining e.g. readChar or the like as an action that does something and 
returns an char (or however standard Haskell idiom puts it), you can just say 
that readChar is a random char variable and be done with it.  The notion of 
doing an action goes away.  The side-effect of actually reading the input or 
the like can be defined generically by saying that evaluating a random variable 
always has some side-effect; what specifically the side effect is does not 
matter.  I mention this as a possible approach for anybody looking for a better 
way of accounting for IO in Haskell.

Cheers,

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

Re: [Haskell-cafe] (...) Random generators


On 12/30/2011 04:38 PM, Jerzy Karczmarczuk wrote:
 Bardur Arantsson:
 Random streams are not referentially transparent, though, AFAICT...?

 Either way this thread has gone on long enough, let's not prolong it
 needlessly with this side discussion.

 Sure.
 But the discussion on randomness is /per se/ interesting, especially in
 a functional setting.

 Anyway, nobody can convince Steve Horne. Perhaps as an unintentional
 side-effect...

 But random streams, or rather pseudo-random streals (infinite lazy
 lists, as the example I gave, the `iterate` of `next`) are as
 referentially transparent as any Haskell data. Really.


Of course -- if you just have a starting seed and the rest of the 
sequence is known from there. I was thinking of e.g. those periodic 
re-initialization ways of doing RNG.


 I *NEVER* used
 true random numbers, even to initialize a generator, since in the
 simulation business it is essential that you can repeat the sequence on
 some other platform, with some other parameters, etc.


I've heard this a lot from physicists -- of course if you run a 
simulation reproducibility can be extremely important (e.g. for 
double-checking computations across different machines). However, if 
you're doing crypto it may not be so desirable :).


Anyway, I'm out of this thread too :).

Cheers,


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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 10:24 AM, Gregg Reynolds d...@mobileink.com wrote:


 On Dec 30, 2011, at 11:43 AM, Conal Elliott wrote:

 roof: f is a function, and it is taking the same argument each time.
 Therefore the result is the same each time.


 That's called begging the question.  f is not a function, so I guess your
 proof is flawed.

 It seems pretty clear that we're working with different ideas of what
 constitutes a function.  When I use the term, I intend what I take to be
 the standard notion of a function in computation: not just a unique mapping
 from one input to one output, but one where the output is computable from
 the input.  Any function that depends on a non-computable component is by
 that definition not a true function.  For clarity let's call such critters
  quasi-functions, so we can retain the notion of application.  Equality
 cannot be defined for quasi-functions, for obvious reasons.

 f is a quasi-function because it depends on getAnIntFromUser, which is
 not definable and is obviously not a function.  When applied to an argument
 like 42, it yields another quasi-function, and therefore f 42 = f 42 is
 false, or at least unknown, and the same goes for f 42 != f 42 I suppose.

 -Gregg


 Please don't redefine function to mean computable function. Besides
 distancing yourself from math, I don't think doing so really helps your
 case.


 No redefinition involved, just a narrowing of scope.  I assume that, since
 we are talking about computation, it is reasonable to limit  the discussion
 to the class of computable functions - which, by the way, are about as
 deeply embedded in orthodox mathematics as you can get, by way of recursion
 theory.  What would be the point of talking about non-computable functions
 for the semantics of a programming language?

 And on what do you base your claim that getAnIntFromUser is not definable?


 Sorry, not definable might a little strong.  Not definable in the way we
 can define computable functions work better?  In any case I think you
 probably see what I'm getting at.

 Or that applying it (what?) to 42 gives a quasi-function?


 I can't think of a way to improve on what I've already written at the
 moment - it too would depend on IO - so if my meaning is not clear, so be
 it.

 Wait, here's another way of looking at it.  Think of IO actions as random
 variables.  So instead of getAnIntFromUser, use X as an integer random
 variable yielding something like:

  f :: Int - IO Int
  f x = X = \i - return (i+x)

 I would not call this f a function because I don't think it answers to the
 commonly accepted definition of a function.  Ditto for the result of
 applying it to 42.  Others obviously might consider it a function.  De
 gustibus non set disputandem.

 -Gregg


I'm recommending a shift to more well-defined terms in hopes to move this
discussion away from tastes  opinions and from what's obvious (even if
untrue or ill-defined).

If you look at the signature of 'f', you can see that it's declared to be a
function (and a computable one at that). To demonstrate that it's not
actually a function, I'd expect you to show that it's one-to-many, which
then raises the question of equality, as needed to distinguish one from
many.

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

Re: [Haskell-cafe] On the purity of Haskell


On 30/12/2011 15:23, Gregg Reynolds wrote:

Now one way of understanding all this is to say that it implicates the 
static/dynamic (compile-time/run-time) distinction: you don't know what e.g. IO 
values are until runtime, so this distinction is critical to distinguishing 
between pure and impure.  I gather this is your view.

Yes.

I think that is reasonable, but with the caveat that it must be at the right 
level of abstraction.  I don't think ASTs etc. enter into it - those are 
implementation techniques, and the only generalization we can apply to 
compilers is that they do implement the language definition, not how they do it 
(not all C compilers use ASTs).
I would argue that AST is more an analogy than an implementation - I 
don't really care if a person dry-runs the code by reading and rewriting 
fragments of the source code in notepad - there is still something that 
represents an unevaluated function but which is itself being treated as 
a value - the fallback result in this model.


A possible way to implement a Haskell program would be...

1. Apply rewrite rules to evaluate everything possible without
   executing primitive IO actions.
2. Wait until you need to run the program.
3. Continue applying rewrite rules to evaluate everything possible, but
   this time executing primitive IO actions (and substituting run-time
   inputs into the model) as and when necessary so that the rewriting
   can eliminate them.

The model correctly describes how the program should behave. It requires 
no metaphors, only a very careful person to do the re-writing and 
(unavoidably) to execute the primitive IO actions.

   The right level of abstraction (IMHO) is the distinction between atemporality and 
temporality.  The functional stuff is atemporal, which means among other things that 
evaluation is unordered (evaluation being a temporal process).  Adding IO etc. 
capabilities to the purely functional fragment of a language infects it with temporality. 
 But we can model temporality using order, so we can dispense with the notion of run-time 
and say that IO etc. stuff adds an ordered fragment to the unordered fragment.  One goal 
of the language is then to enforce a strict correspondence between the order of events 
outside the program (e.g. keystrokes) and events inside the program (getchar).

Nice way to put it.

The beauty of the monad solution is not that it magically transforms 
non-functional stuff like IO into functional stuff, but that it exploits type 
discipline to make such operations *mimic* purely functional stuff in a sense - 
but only at the level of typing.  Impure operations then have purely functional 
type discipline while remaining essentially non-functional.  So I think of 
Haskell as a quasi-pure or hybrid language.  C on the other hand is totally 
impure (except for predefined constants like '1').  For totally pure languages 
you have to look elsewhere, e.g. logics - there are no pure programming 
languages.
Well - on C is impure, it depends how you look at that. If it's valid to 
say that your home-grown while loop is a function that accepts two 
actions as parameters, well, C has an equivalent function built into the 
compiler. Again you can separate the pure from the impure, and the 
impurity is only realized when the program is executed. The 
correspondence between orderings arises in different ways, but even C 
only demands that results are as if the standards-defined evaluation 
order were followed - partial-evaluation and other optimisations during 
compilation are done in whatever order the C compiler finds convenient, 
exploiting associativity and commutativity where those are guaranteed etc.


It doesn't make Haskell and C the same thing, of course.

It's fairly easy to grasp the point by going back to Turing's original insight. 
 The cornerstone of his ideas was not the machine but the human calculator 
working with pencil and paper, finite memory, etc.  So to see the diff all you 
have to do is think about what a human does with a problem (program) written on 
paper.  Give the human calculator a computable task - add 2+2 - and you can be 
confident you will receive a definite answer in a finite amount of time.  Lard 
this with a non-computable step - add 2 + 2 + getInt - and all bets are off.
Precisely my point with my bind example - in the expression 
getAnIntFromTheUser = \i - return (i+1) you cannot know the value 
of i at compile-time, or within the realm of the atemporal. But even if 
at one level you consider that expression still to be evaluated within 
the atemporal realm, it is still evaluated also (in 
translated/rewritten/whatever form) in the temporal realm - at run-time. 
If the user happens to enter the value 1, at some point, the expression 
i+1 is conceptually rewritten to 1+1 and then to 2.


Arguably everything that can be evaluated at compile-time - everything 
in the atemporal realm - is just optimisation. That's a narrow view, and 
not one that I (now)

Re: [Haskell-cafe] On the purity of Haskell

On Fri, Dec 30, 2011 at 10:45 AM, Gregg Reynolds d...@mobileink.com wrote:


 On Dec 30, 2011, at 11:21 AM, Conal Elliott wrote:

 
  And I also raised a more fundamental question than whether this claim of
 sameness is true, namely what is equality on IO? Without a precise 
 consistent definition of equality, the claims like f 42 == f (43 - 1) are
 even defined, let alone true. And since the conversation is about Haskell
 IO, I'm looking for a definition that applies to all of IO, not just some
 relatively well-behaved subset like putchar/getchar+IORefs+threads.

 Well, you'll no doubt be glad to know I think I've said about all I need
 to say on this topic, [...]


Honestly, I'm not trying to get you to speak less, but rather to share your
perspective more clearly. I've have more than my fill of circular arguments
and ill-defined claims.

I'm reminded of a quote from David R. MacIver in “A problem of
languagehttp://www.drmaciver.com/2009/05/a-problem-of-language/,


Of course, once you start defining the term people will start arguing about
 the definitions. This is pretty tedious, I know. But as tedious as arguing
 about definitions is, it can’t hold a candle to arguing without definitions.

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

Re: [Haskell-cafe] Overloaded Quotes for Template Haskell

2011-12-30 Thread Michael D. Adams

I'm not very familiar with monad-control, but it looks like the
equivalent of liftWith from monad-control would be a function that has
type StateT S Q a - Q (S - (a, S)).  IIUC, you are suggesting that
the code would look something like restoreT [| ... $( liftWith ( ...
) ) ... |].

Unfortunately, I don't think that would work because GHC requires that
the contents of $( ... ) have exactly the type Q Exp (or Q Type,
etc.).  Using liftWith in that way makes the contents of $( ... )
have type Q (S - (a, S)).

On Fri, Dec 30, 2011 at 5:55 AM, James Cook mo...@deepbondi.net wrote:
 One possible option would be to make a library that has all the combinators 
 lifted to your more general type and use lift or runQ or something 
 similar for any quotes that need lifting, along with operations from 
 monad-control or monad-peel to lift quotes that also need access to the 
 StateT layer in the splice.  It's a bit messier and those libraries are 
 brain-bending at first (although definitely worth learning about), but it 
 would allow you to code in the style you're talking about with a relatively 
 small amount of extra syntactic clutter.

 -- James

 On Dec 29, 2011, at 9:51 PM, Michael D. Adams wrote:

 What would it take to get an -XOverloadedQuotes flag of the same
 sort as the -XOverloadedStrings flag?  I.e. [| ... |] would have
 type Quasi m = m Exp instead of Q Exp and any splices in that
 quotation expect the contents of that splice to have type m Exp.
 (Obviously, top level splices would still have type Q Exp otherwise
 the compiler wouldn't know how to evaluate the monad.)

 I ran into this problem when writing a Template Haskell program in
 which part of it operates in a StateT S Q a monad instead of the
 usual Q a monad.  (The S type stores the state of a memoization
 table of code fragments already generated.  Without it, the code would
 loop infinitely when processing certain recursive structures.)

 It is fairly easy to declare an instance of Quasi for StateT S Q,
 so in order to keep the code clean, I'd like to use quotations with
 splices in them (i.e. [| ... $( ... ) ... |] ) for expressing the
 generated code.  However, quotations and splices are tied to the Q
 monad which means that as it is now I have to manually write LamE ...
 VarP ... VarE ... etc. instead of using the much nicer quotation
 syntax.

 Michael D. Adams
 mdmko...@gmail.com

 ___
 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] On the purity of Haskell

On 30/12/2011 15:50, Gregg Reynolds wrote:

On Dec 30, 2011, at 10:34 AM, Artyom Kazak wrote:

Gregg Reynoldsd...@mobileink.com писал(а) в своём письме Fri, 30 Dec 2011
17:23:20 +0200:

Regarding side-effects, they can be (informally) defined pretty simply: any
non-computational effect caused by a computation is a side-effect.

I wonder: can writing to memory be called a “computational effect”? If yes,
then every computation is impure. If no, then what’s the difference between
memory and hard drive?

Great question! It suggests that the line between computation and its side
effects is not as clear-cut as we (well, I) thought.
It relates to that while loop thing in my last reply to you, I think -
the computational effect dressed up as non-computational.

We can do some work in Haskell using a temporary file on disk as a
pragmatic solution to a space issue. We can feed that composed IO action
to unsafePerformIO without breaking referential transparency, at least
if we choose to ignore issues like running out of disk space (we ignore
similar memory issues all the time).

And really, it's just explicit virtual memory - it's implicitly
happening in the background anyway.

Or - it's layers of abstraction. The implementation of a function that
uses explicit virtual memory is impure, but the abstraction it provides
is pure. At least in principle (hand-waving away possible disk errors
etc), the abstraction doesn't leak impurity.

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, 2011-12-30 at 12:45 -0600, Gregg Reynolds wrote:
 I spent some time sketching out ideas for using random variables to provide
 definitions (or at least notation) for stuff like IO.  I'm not sure I could
 even find the notes now, but my recollection is that it seemed like a
 promising approach.  One advantage is that this eliminates the kind of 
 informal
 language (like user input) that seems unavoidable in talking about IO.
 Instead of defining e.g. readChar or the like as an action that does
 something and returns an char (or however standard Haskell idiom puts it),
 you can just say that readChar is a random char variable and be done with
 it.  The notion of doing an action goes away.  The side-effect of actually
 reading the input or the like can be defined generically by saying that
 evaluating a random variable always has some side-effect; what specifically
 the side effect is does not matter.

Isn't this just another way of saying the same thing that's been said
already?  It's just that you're saying random variable instead of I/O
action.  But you don't really mean random variable, because there's all
this stuff about side effects thrown in which certainly isn't part of
any idea of random variables that anyone else uses.  What you really
mean is, apparently, I/O action, and you're still left with all the
actual issues that have been discussed here, such as when two I/O
actions (aka random variables) are the same.

There is one difference, and it's that you're still using the term
evaluation to mean performing an action.  That's still a mistake.
Evaluation is an idea from operational semantics, and it has nothing to
do with performing effects.  The tying of effects to evaluation is
precisely why it's so hard to reason about programs in, say, C
denotationally, because once there is no such thing as an evaluation
process, modeling the meaning of terms becomes much more complex and
amounts to reinventing operational semantics in denotational clothing)\.

I'd submit that it is NOT an advantage to any approach that the notion
of doing an action goes away.  That notion is *precisely* what programs
are trying to accomplish, and obscuring it inside functions and
evaluation rather than having a way to talk about it is handicapping
yourself from a denotational perspective.  Rather, what would be an
advantage (but also rather hopeless) would be to define the notion of
doing an action more precisely.

-- 
Chris Smith


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

Re: [Haskell-cafe] On the purity of Haskell

Donn Cave d...@avvanta.com писал(а) в своём письме Fri, 30 Dec 2011  
20:36:46 +0200:



That's why we use terms in a sense that apply meaningfully to computer
programming languages in general and Haskell in particular.  To do
otherwise - for example to insist on a definition of pure that could
not even in principle apply to any useful programming language, or a
definition of side effect that would have to apply every time a
program does anything - seems to me like an inane waste of time, to
put it mildly.


When one questions accepted definitions or beliefs, it is the sign of
their vagueness. To be honest, the definitions of “side effect” and
“purity” are vague indeed. I hope that eventually (probably in this
very discussion) they will be refined.

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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, 2011-12-30 at 12:24 -0600, Gregg Reynolds wrote:
 No redefinition involved, just a narrowing of scope.  I assume that,
 since we are talking about computation, it is reasonable to limit  the
 discussion to the class of computable functions - which, by the way,
 are about as deeply embedded in orthodox mathematics as you can get,
 by way of recursion theory.  What would be the point of talking about
 non-computable functions for the semantics of a programming language?

Computability is just a distraction here.  The problem isn't whether
getAnIntFromUser is computable... it is whether it's a function at
all!  Even uncomputable functions are first and foremost functions, and
not being computable is just a property that they have.  Clearly this is
not a function at all.  It doesn't even have the general form of a
function: it has no input, so clearly it can't map each input value to a
specific output value.  Now, since it's not a function, it makes little
sense to even try to talk about whether it is computable or not (unless
you first define a notion of computability for something other than
functions).

If you want to talk about things that read values from the keyboard or
such, calling them uncomputable is confusing, since the issue isn't
really computability at all, but rather needing information from a
constantly changing external environment.  I suspect that at least some
people talking about functions are using the word to mean a
computational procedure, the sort of thing meant by the C programming
language by that word.  Uncomputable is a very poor word for that idea.


-- 
Chris Smith


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

Re: [Haskell-cafe] On the purity of Haskell

Chris Smith cdsm...@gmail.com писал(а) в своём письме Fri, 30 Dec 2011  
22:04:21 +0200:



Computability is just a distraction here.  The problem isn't whether
getAnIntFromUser is computable... it is whether it's a function at
all!  Even uncomputable functions are first and foremost functions, and
not being computable is just a property that they have.  Clearly this is
not a function at all.  It doesn't even have the general form of a
function: it has no input, so clearly it can't map each input value to a
specific output value.  Now, since it's not a function, it makes little
sense to even try to talk about whether it is computable or not (unless
you first define a notion of computability for something other than
functions).


Of course getAnIntFromUser is not a function. It is an instruction to  
computer.


Think of IO as a form of writing instructions to some worker (essentially,  
the kernel, which in its turn uses processor's io ports). You are asking  
this “worker” to change some global state.


Thus, your function “f” is a function indeed, which generates a list of  
instructions to kernel, according to given number.


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

Re: [Haskell-cafe] On the purity of Haskell

On Fri, 2011-12-30 at 23:16 +0200, Artyom Kazak wrote:
 Thus, your function “f” is a function indeed, which generates a list of  
 instructions to kernel, according to given number.

Not my function, but yes, f certainly appears to be a function.

Conal's concern is that if there is no possible denotational meaning for
values of IO types, then f can't be said to be a function, since its
results are not well-defined, as values.

This is a valid concern... assigning a meaning to values of IO types
necessarily involves some very unsatisfying hand-waving about
indeterminacy, since for example IO actions can distinguish between
bottoms that are considered equivalent in the denotational semantics of
pure values (you can catch a use of 'error', but you can't catch
non-termination).  Nevertheless, I'm satisfied that to the extent that
any such meaning can be assigned, f will be a valid function on
non-bottom values.  Not perfect, but close.

-- 
Chris Smith


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

Re: [Haskell-cafe] On the purity of Haskell

2011-12-30 Thread Scott Turner

On 2011-12-30 14:32, Steve Horne wrote:
 A possible way to implement a Haskell program would be...
 
  1. Apply rewrite rules to evaluate everything possible without
 executing primitive IO actions.
  2. Wait until you need to run the program.
  3. Continue applying rewrite rules to evaluate everything possible, but
 this time executing primitive IO actions (and substituting run-time
 inputs into the model) as and when necessary so that the rewriting
 can eliminate them.

This is inadequate, because it is does not specify when the program's
various IO actions are executed, or even which of them are executed. Try
print first `seq` print second
or
let x = print x in print value
Also, evaluate everything possible is strangely hard to match up with
the concepts involved in Haskell's non-strict evaluation.

An accurate description of how an IO expression is executed would be:

Evaluate the expression. There are three possible results.
1. If it is a 'return' operation, the result is the operand.
2. If it is a bind (=) operation,
   a. Execute the left operand, obtaining a result expression.
   b. The right operand is a function. Apply it to the returned
  expression, obtaining an IO expression.
   c. Execute the IO expression.
3. If it is a primitive, execute it, obtaining an expression.

A Haskell program is an IO expression, and is executed as above. Notice
that when a program is executed, its IO actions are not performed as a
result of being evaluated. Rather, they are evaluated (down to values)
in order to be performed. Every evaluation in the above procedure is
pure, with no IO effects.

The concept of AST is no more helpful in explaining IO than it is in
explaining
foldr (*) 1 [1..5]
IMO it's no help at all.

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

Re: [Haskell-cafe] On the purity of Haskell

Chris Smith cdsm...@gmail.com писал(а) в своём письме Fri, 30 Dec 2011  
22:28:36 +0200:


I really think that the notion of “purity” appeared to convince C  
programmers. It would be silly to try to explain that “Int - IO Int”  
isn't really a function from Int to Int, monads, blah blah blah. So, we're  
saying: “here is a function which accepts Int and (sic!) returns Int, but  
it can also do IO, which is kinda unsafe. So we are marking it with ‘IO’  
letters, see? This means that this function is ‘impure’. And to prevent  
mixing pure things with impure things, compiler demands you to mark with  
IO every “function” which ‘uses’ IO”.


Functions don't use IO. Funtions return IO something. And functions  
returning IO are impure. That's all.



This is a valid concern... assigning a meaning to values of IO types
necessarily involves some very unsatisfying hand-waving about
indeterminacy, since for example IO actions can distinguish between
bottoms that are considered equivalent in the denotational semantics of
pure values (you can catch a use of 'error', but you can't catch
non-termination).  Nevertheless, I'm satisfied that to the extent that
any such meaning can be assigned, f will be a valid function on
non-bottom values.  Not perfect, but close.


Agree. The fact that IO actions can distinguish between bottoms,  
self-modify code, terminate non-terminable computations by rebooting the  
system, send killbots to the programmer's house and so on are extremely  
unsatisfying. That's IO for you.


The dirty impure bottom comparison which uses IO, though, is available  
only to already impure functions.


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

Re: [Haskell-cafe] On the purity of Haskell


On 30/12/2011 10:47, Bardur Arantsson wrote:

On 12/29/2011 11:06 PM, Steve Horne wrote:

Using similar mixed definitions to conclude that every C program is full
of bugs (basically equating intentional effects with side-effects, then
equating side-effects with unintentional bugs) is a fairly common thing
in my experience, but it's a logical fallacy. If you aren't aware of the
two definitions of side-effect, it's hard to get deal with that.

Some people don't want anyone to figure out the fallacy - they like
having this convenient way to attack C, irrespective of whether it's
valid or not. Rare I think - mostly it's more confusion and memetics.
But still, I'm convinced there's some sophistry in this. And I'm not the
only person to think so, and to have reacted against that in the past.

Extra sad - you don't need that fallacy to attack C. It's redundant. C
is quite happy to demonstrate its many failings.


That's the flimsiest straw man I've ever seen.

Calling it a straw man won't convince anyone who has the scars from 
being attacked by those straw men.


I've been in those arguments, being told that C has side-effects 
therefore all C programs are full of bugs, whereas Haskell can't have 
similar bugs because it doesn't have side-effects.


I'm really not interested in whose-side-are-you-on arguments. Trying to 
keep the two definitions separate is relevant, and that was my 
motivation for saying this - it's a fact that if you mix your 
definitions up enough you can prove anything.


I like C++. I recognise the flaws in C++, as every everyday-user of the 
language must. Pretending they don't exist doesn't solve the issues - 
it's for OTT advocates, not developers. I don't insist that every 
virtuous-sounding term must apply to C++. I don't pretend every C++ 
advocate is an angel.


I like Haskell. I can't claim to be an everyday user, but I'm learning 
more and using it more all the time. I'm still uncertain whether some 
flaws I see are real - some that I used to see weren't - but I'll 
address that over time by thinking and debating. I won't pretend every 
Haskell advocate is an angel.


I've already confessed to being in the anti-Haskell role in arguments 
where the points I, ahem, emphatically made were (I now recognise) 
fallacious. So I won't even pretend I'm an angel.


If someone who was on the other side in one of my rants makes this same 
keep-your-definitions-straight point while acting as a C advocate, is 
that also a straw-man?



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

Re: [Haskell-cafe] On the purity of Haskell


On 30/12/2011 20:38, Scott Turner wrote:

On 2011-12-30 14:32, Steve Horne wrote:

A possible way to implement a Haskell program would be...

  1. Apply rewrite rules to evaluate everything possible without
 executing primitive IO actions.
  2. Wait until you need to run the program.
  3. Continue applying rewrite rules to evaluate everything possible, but
 this time executing primitive IO actions (and substituting run-time
 inputs into the model) as and when necessary so that the rewriting
 can eliminate them.

This is inadequate, because it is does not specify when the program's
various IO actions are executed, or even which of them are executed.
Yes it does. Specifying when all the various IO actions are executed 
relative to each other is what the IO *monad* is for.


IIRC, there is a little hand-waving that SPJ confesses to about that - 
basically that each term will only be reduced once.

  Try
 print first `seq` print second
or
 let x = print x in print value
Also, evaluate everything possible is strangely hard to match up with
the concepts involved in Haskell's non-strict evaluation.
I didn't say what order to evaluate it in. For example, in this 
expression...


  let a = (2*2) in (a+a)

One valid next evaluation (rewriting) set would give...

  (2*2)+(2*2)

Another would give...

  let a = 4 in (a+a)

I don't care which you choose. I don't demand that only concrete 
arithmetic steps count. I don't demand that evaluation must be bottom-up 
or top-down or left-to-right. Only that as many evaluation steps as 
possible are applied.


The hand-waving there - the infinity issue. For a lazy list, we need a 
very careful definition of possible. That's one reason why even lazy 
evaluation implies at least a particular preferred evaluation order - 
just not the same order as for strict evaluation.


Anyway, you cannot use rewriting to extract a result out of a primitive 
IO action without executing the IO action. Even if every IO action was 
of type IO () this still applies by the rules of the Haskell language - 
you cannot extract that () out of a (putStrLn Hello) until you execute 
that action.



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

[Haskell-cafe] purity and the season of good will

2011-12-30 Thread Chris Dornan

(Whether readers would consider the post [or indeed this post] an act of
trollery was mooted and mentioned several times in the original post - my
thoughts at the end. I am writing this because I would have expected
somebody to have said this by now. If it has been said then my sincere
apologies. Meta issues, flames, etc., to me and not the list of course.)
 
 
Pure versus Impure
 
I suspect introducing C into this discussion may not help clarify the
fundamental issue.
 
As anyone with experience of programming in Haskell appreciates, there is a
big difference between (e.g.) these two functions for taking the sum of two
integers:
 
plus   :: Int - Int - Int
 
plusIO :: Int - Int - IO Int
 
The choice is a profound one and will affect their construction as well as
the contexts they can be used and so forth. 
 
Haskell supports both styles of programming and allows them to be safely and
freely intermixed with the type system guaranteeing to keep them properly
separated.
 
The type system and static semantics are critical to the Haskell approach to
IO and 'purity'.  I can't see how it can be meaningfully pushed into the
background in any discussion or comparative discussion of these issues. 
 
 
In Short
 
If the programming context in question doesn't provide any equivalent formal
separation in its type system of plus-like functions and plusIO-like
computations, that programmers use in practice to guide the construction of
their programs, then how can the said programming context be considered
equivalent to Haskell's treatment of pure functions and effects-generating
computations.
 
You just need to consider your own Haskell programming activity and how the
type system keeps calculations and I/O actions separate to see this point. I
doubt if any extra theory (or theology!) will add much insight.
 
 
That T word Again (or not)
 
Let's keep this forward-looking. With the email piling in as I write this,
please consider whether this continuation of this discussion is likely to be
helpful to the general readers of this list or whether it will confuse or
discourage them, before adding to it.
 
 
A Happy New Year to you,
 
 
Chris
 
 
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Steve Horne
Sent: 28 December 2011 17:40
To: Haskell Cafe Mailing List
Subject: [Haskell-cafe] On the purity of Haskell
 
This is just my view on whether Haskell is pure, being offered up for
criticism. I haven't seen this view explicitly articulated anywhere before,
but it does seem to be implicit in a lot of explanations - in particular the
description of Monads in SBCs Tackling the Awkward Squad. I'm entirely
focused on the IO monad here, but aware that it's just one concrete case of
an abstraction.

Warning - it may look like trolling at various points. Please keep going to
the end before making a judgement.

To make the context explicit, there are two apparently conflicting
viewpoints on Haskell...
1.  The whole point of the IO monad is to support programming with
side-effecting actions - ie impurity.
2.  The IO monad is just a monad - a generic type (IO actions), a couple
of operators (primarily return and bind) and some rules - within a pure
functional language. You can't create impurity by taking a subset of a pure
language.
My view is that both of these are correct, each from a particular point of
view. Furthermore, by essentially the same arguments, C is also both an
impure language and a pure one.

See what I mean about the trolling thing? I'm actually quite serious about
this, though - and by the end I think Haskell advocates will generally
approve.

First assertion... Haskell is a pure functional language, but only from the
compile-time point of view. The compiler manipulates and composes IO actions
(among other things). The final resulting IO actions are finally swallowed
by unsafePerformIO or returned from main. However, Haskell is an impure
side-effecting language from the run-time point of view - when the composed
actions are executed. Impurity doesn't magically spring from the ether - it
results from the translation by the compiler of IO actions to executable
code and the execution of that code.

In this sense, IO actions are directly equivalent to the AST nodes in a C
compiler. A C compiler can be written in a purely functional way - in
principle it's just a pure function that accepts a string (source code) and
returns another string (executable code). I'm fudging issues like separate
compilation and #include, but all of these can be resolved in principle in a
pure functional way. Everything a C compiler does at compile time is
therefore, in principle, purely functional.

In fact, in the implementation of Haskell compilers, IO actions almost
certainly *are* ASTs. Obviously there's some interesting aspects to that
such as all the partially evaluated and unevaluated functions. But even a
partially evaluated function has a representation within a compiler that can
be

[Haskell-cafe] Plugins on ghc 7.2: GHC does not export defaultCallbacks

2011-12-30 Thread Brian Victor


Hi all,

As a getting-my-feet-wet project I was starting to look into using 
plugins-auto with the yesod devel server, but I was quickly stymied 
because the plugins package isn't building on GHC 7.2. The error I get 
locally is the same as the one reported by hackage[1]. In short, 
defaultCallbacks seems to be gone from 7.2.


It doesn't look like that function has simply been moved. So can someone 
give me an idea about how to proceed?


Thanks!

[1] 
http://hackage.haskell.org/packages/archive/plugins/1.5.1.4/logs/failure/ghc-7.2


--
Brian


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

Re: [Haskell-cafe] Level of Win32 GUI support in the Haskell platform

2011-12-30 Thread Ivan Perez

I'm using Gtk2hs in windows (and linux) with no big problems. Cairo also works.
Glade does not allow me to use accents in the user interfaces on windows, but
otherwise works ok.

I haven't tried wx on windows. It works on linux and it provides a
more natural interface
(gtk will look like gtk also in windows). I found wx a bit limited (I
couldn't dock my app into
the traybar), but it was enough to write a sudoku UI.

I'm releasing apps using gtk2hs on windows and my clients haven't complained so
far. You'll need to strip your apps if you are planning to distribute
them, otherwise you'll
carry more than 15MB with every executable.

Cheers,
Ivan.

On 30 December 2011 05:49, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
 Hi,

 Steve Horne sh006d3592 at blueyonder.co.uk writes:


 I've been for functions like GetMessage, TranslateMessage and
 DispatchMessage in the Haskell Platform Win32 library - the usual
 message loop stuff - and not finding them. Hoogle says no results found.

 Haskell Platform includes the Win32 package which provides access to these
 functions. Hoogle doesn't index Windows-only packages, unfortunately.


 ___
 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] On the purity of Haskell