[Haskell-cafe] Re: Monad explanation

2009-02-09 Thread Emilio Jesús Gallego Arias
Gregg Reynolds d...@mobileink.com writes:

 But it can't be a function, since it is non-deterministic.  

IMHO, if you assume IO a = World - (World, a), then getChar is indeed a
function and deterministic. It is, there are not w :: World such that
getChar w != getChar.

The fact that World is too big to be represented in Haskell and we use
IO to simulate it is a different matter.

With regard to your original question, I like to keep in mind that
arrow composition in the Kleisli category (= in Haskell) is defined in
terms of the monad's join :: m (m a) - m a.

Then, the question is, how many ways can you map an IO (IO a) to an IO
a? 

You will find that you cannot ignore the inner (first) IO in order to
obey monad laws.

Regards,

Emilio


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


[Haskell-cafe] Re: Monad explanation

2009-02-09 Thread Emilio Jesús Gallego Arias
egall...@babel.ls.fi.upm.es (Emilio Jesús Gallego Arias) writes:

 IMHO, if you assume IO a = World - (World, a), then getChar is indeed a
 function and deterministic. It is, there are not w :: World such that
 getChar w != getChar.

Sorry I meant:

There is not w :: World such that getChar w != getChar w.


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


[Haskell-cafe] Re: Monad explanation

2009-02-05 Thread Benjamin L . Russell
On Wed, 4 Feb 2009 21:43:04 -0800, Max Rabkin max.rab...@gmail.com
wrote:

On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell
dekudekup...@yahoo.com wrote:
 Is it possible to write a self-referential function in Haskell that
 modifies itself?

Is it possible to write *any* kind of function in Haskell that
modifies *anything*?

While trying to research this issue, I came across a relevant archived
thread in Haskell-Cafe, entitled [Haskell-cafe] haskell and
reflection, started by Greg Meredith, dated Tue, 11 Sep 2007
07:09:22 -0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg29882.html),
which at first had me worried.  Specifically, Greg wrote as follows:

Am i wrong in my assessment that the vast majority of reflective machinery
is missing from Haskell? Specifically,

   - there is no runtime representation of type available for
   programmatic representation
   - there is no runtime representation of the type-inferencing or
   checking machinery
   - there is no runtime representation of the evaluation machinery
   - there is no runtime representation of the lexical or parsing
   machinery

However, I was somewhat relieved to find that Haskell apparently does
support, in at least one GHC extension to Haskell, a limited form of
reflection.  In the same thread, Reinier Lamers, in his response,
dated Tue, 11 Sep 2007 13:08:38 -0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg29898.html),
wrote as follows:

Op 11-sep-2007, om 18:43 heeft Greg Meredith het volgende geschreven:

[...]

Template Haskell [1] is a system that lets you write programs that get 
executed at *compile time*, and that produce parts of the Haskell program 
to be compiled by manipulating a representation of the program as structured 
data. It's a form of reflection restricted to compile time, if you'd ask me.

[...]

[1] http://www.haskell.org/haskellwiki/Template_Haskell

According to the site referenced by the above-mentioned link,

Template Haskell is an extension to Haskell 98 that allows you to do type-safe 
compile-time meta-programming, with Haskell both as the manipulating language 
and the language being manipulated.

This site is even referenced on the site for The Meta-Programming
Project (see
http://www.infosun.fim.uni-passau.de/cl/metaprog/index.php3), as
follows:

Languages which we are using for meta-programming

* Template Haskell, permits analysis of object programs

Additionally, Don Stewart, in an earlier post in the same thread,
dated Thu, 13 Sep 2007 11:36:11 -0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg30009.html),
wrote as follows:

lgreg.meredith:
Haskellians,
 
Am i wrong in my assessment that the vast majority of reflective machinery
is missing from Haskell? Specifically,
 
  * there is no runtime representation of type available for programmatic
representation

  * there is no runtime representation of the type-inferencing or checking
machinery

  * there is no runtime representation of the evaluation machinery

  * there is no runtime representation of the lexical or parsing machinery

So there is library support for all of this, in various forms:

* lexer, parser, type checker, evaluator:
ghc-api
hs-plugins

* lexer, parser, pretty printer
many parser libs (Language.Haskell, Template Haskell)

* runtime type representation
Data.Typeable

* reflecting code to data:
Data.Generics

As a sidenote, I discovered an interesting post and associated paper
by Lauri Alanko, who in a post in the same thread, dated Tue, 11 Sep
2007 10:12:09 -0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg29895.html),
responded that while both structural and procedural reflection are
possible in Haskell, because of static typing, type safety is
nevertheless an issue:

On Tue, Sep 11, 2007 at 07:33:54AM -0700, Greg Meredith wrote:
 Our analysis suggested the following breakdown
 
- Structural reflection -- all data used in the evaluation of programs
has a programmatic representation
- Procedural reflection -- all execution machinery used in the
evaluation of programs has a programmatic representation

[...]

As for Haskell, there are various tools for both (at least
Data.Typeable and hs-plugins), but neither are truly type-safe: it is
possible to write code that uses these libraries and type-checks, yet
crashes. Static typing makes reflection very difficult to support
safely.

You might be interested in my MS thesis, where I explored these issues
in some more length: 
http://www.cs.helsinki.fi/u/lealanko/alanko04types.pdf

This thesis is entitled Types and Reflection (see the
above-mentioned URL), and summarizes the problem as follows (see p.
1):

This thesis is about reflection in typed programming languages. The central 
idea of this work, the thesis proper, can be summarized in three points:
. Typed reflection is a good thing.

Re: [Haskell-cafe] Re: Monad explanation

2009-02-05 Thread Daryoush Mehrtash
Can someone compare/contrast functions and computation?

thanks

daryoush

On Thu, Feb 5, 2009 at 1:38 AM, Benjamin L. Russell
dekudekup...@yahoo.comwrote:

 On Wed, 4 Feb 2009 21:43:04 -0800, Max Rabkin max.rab...@gmail.com
 wrote:

 On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell
 dekudekup...@yahoo.com wrote:
  Is it possible to write a self-referential function in Haskell that
  modifies itself?
 
 Is it possible to write *any* kind of function in Haskell that
 modifies *anything*?

 While trying to research this issue, I came across a relevant archived
 thread in Haskell-Cafe, entitled [Haskell-cafe] haskell and
 reflection, started by Greg Meredith, dated Tue, 11 Sep 2007
 07:09:22 -0700 (see
 http://www.mail-archive.com/haskell-cafe@haskell.org/msg29882.html),
 which at first had me worried.  Specifically, Greg wrote as follows:

 Am i wrong in my assessment that the vast majority of reflective machinery
 is missing from Haskell? Specifically,
 
- there is no runtime representation of type available for
programmatic representation
- there is no runtime representation of the type-inferencing or
checking machinery
- there is no runtime representation of the evaluation machinery
- there is no runtime representation of the lexical or parsing
machinery

 However, I was somewhat relieved to find that Haskell apparently does
 support, in at least one GHC extension to Haskell, a limited form of
 reflection.  In the same thread, Reinier Lamers, in his response,
 dated Tue, 11 Sep 2007 13:08:38 -0700 (see
 http://www.mail-archive.com/haskell-cafe@haskell.org/msg29898.html),
 wrote as follows:

 Op 11-sep-2007, om 18:43 heeft Greg Meredith het volgende geschreven:
 
 [...]
 
 Template Haskell [1] is a system that lets you write programs that get
 executed at *compile time*, and that produce parts of the Haskell program
 to be compiled by manipulating a representation of the program as
 structured
 data. It's a form of reflection restricted to compile time, if you'd ask
 me.
 
 [...]
 
 [1] http://www.haskell.org/haskellwiki/Template_Haskell

 According to the site referenced by the above-mentioned link,

 Template Haskell is an extension to Haskell 98 that allows you to do
 type-safe
 compile-time meta-programming, with Haskell both as the manipulating
 language
 and the language being manipulated.

 This site is even referenced on the site for The Meta-Programming
 Project (see
 http://www.infosun.fim.uni-passau.de/cl/metaprog/index.php3), as
 follows:

 Languages which we are using for meta-programming
 
 * Template Haskell, permits analysis of object programs

 Additionally, Don Stewart, in an earlier post in the same thread,
 dated Thu, 13 Sep 2007 11:36:11 -0700 (see
 http://www.mail-archive.com/haskell-cafe@haskell.org/msg30009.html),
 wrote as follows:

 lgreg.meredith:
 Haskellians,
 
 Am i wrong in my assessment that the vast majority of reflective
 machinery
 is missing from Haskell? Specifically,
 
   * there is no runtime representation of type available for
 programmatic
 representation
 
   * there is no runtime representation of the type-inferencing or
 checking
 machinery
 
   * there is no runtime representation of the evaluation machinery
 
   * there is no runtime representation of the lexical or parsing
 machinery
 
 So there is library support for all of this, in various forms:
 
 * lexer, parser, type checker, evaluator:
 ghc-api
 hs-plugins
 
 * lexer, parser, pretty printer
 many parser libs (Language.Haskell, Template Haskell)
 
 * runtime type representation
 Data.Typeable
 
 * reflecting code to data:
 Data.Generics

 As a sidenote, I discovered an interesting post and associated paper
 by Lauri Alanko, who in a post in the same thread, dated Tue, 11 Sep
 2007 10:12:09 -0700 (see
 http://www.mail-archive.com/haskell-cafe@haskell.org/msg29895.html),
 responded that while both structural and procedural reflection are
 possible in Haskell, because of static typing, type safety is
 nevertheless an issue:

 On Tue, Sep 11, 2007 at 07:33:54AM -0700, Greg Meredith wrote:
  Our analysis suggested the following breakdown
 
 - Structural reflection -- all data used in the evaluation of
 programs
 has a programmatic representation
 - Procedural reflection -- all execution machinery used in the
 evaluation of programs has a programmatic representation
 
 [...]
 
 As for Haskell, there are various tools for both (at least
 Data.Typeable and hs-plugins), but neither are truly type-safe: it is
 possible to write code that uses these libraries and type-checks, yet
 crashes. Static typing makes reflection very difficult to support
 safely.

 You might be interested in my MS thesis, where I explored these issues
 in some more length:
 http://www.cs.helsinki.fi/u/lealanko/alanko04types.pdf

 This thesis is entitled Types and 

[Haskell-cafe] Re: Monad explanation

2009-02-05 Thread ChrisK
All Haskell programs start as 



main :: IO ()



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



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


Which is the point jcc made:



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

jcc


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


[Haskell-cafe] Re: Monad explanation

2009-02-04 Thread Benjamin L . Russell
On Thu, 5 Feb 2009 15:18:09 +1300, Richard O'Keefe
o...@cs.otago.ac.nz wrote:


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

without reference to the rest of your message, of course values can /be/
programs.  One of the fundamental insights in programming is that
(all) programs are values, which, in combination with the observation
that some programs exist, means that some values are programs.
Indeed, in the pure lambda calculus, _everything_ is a function (=
program).

Indeed.  Perhaps at least part of this confusion is caused by a
difference in style of thinking between the functional and imperative
programming paradigms; in functional programming, functions are
first-class values, so they are treated just like any other values.
Therefore, functional programs are values.

This style of thinking contrasts with that of imperative programming,
where programs are typically considered to be composed of statements
which change global state when executed (see Functional programming -
HaskellWiki: 1 What is functional programming? at
http://www.haskell.org/haskellwiki/Functional_programming#What_is_functional_programming.3F
.


If you don't like it put that way, say that values can be _names for_
programs, or that values can _be treated as_ programs by interpreters.
I'd rather not get too far into White Knight territory, though.

Actually, I have a question myself on this issue.  I had intended to
give an example of a self-referential program that modifies itself to
illustrate programs as first-class values, but then I just discovered
that it seems that Haskell doesn't support reflection (see
http://en.wikipedia.org/wiki/Reflection_(computer_science)).

In particular, I just came across the following archived post in
Haskell-Cafe, Re: [Haskell-cafe] To yi or not to yi, is this really
the question? A plea for a cooperative, ubiquitous, distributed
integrated development system., dated Mon, 18 Jun 2007 14:05:53
-0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg25257.html),
in which Pasqualino 'Titto' Assini wrote as follows:

Most languages, even Java, have a reflection capability to dynamically inspect 
an object. It is surprising that Haskell doesn't offer it.

In the same thread, Claus Reinke, in his response, dated Mon, 18 Jun
2007 15:45:50 -0700 (see
http://www.mail-archive.com/haskell-cafe@haskell.org/msg25270.html),
wrote as follows:

Most languages, even Java, have a reflection capability to dynamically 
inspect 
an object. It is surprising that Haskell doesn't offer it.

it has to be done with care, or it will invalidate *all* your nice reasoning
about haskell programs. random example

reify (f . g) == [| f . g |] =/= [| \x- f (g x) |] == reify (\x- f (g x)) 

I tried looking up self-reference on HaskellWiki, but my search did
not result in any hits.

Is it possible to write a self-referential function in Haskell that
modifies itself?  My intuition is that this would violate referential
transparency, so it is probably not possible, but as long as the
program is only allowed to reference itself without actually modifying
itself, then there should be a way.

Alternatively, it should be possible for a Haskell program to create a
copy of itself, and then to modify that copy, as long as referential
transparency is not violated.

To what extent are self-reference and reflection supported n Haskell?

-- Benjamin L. Russell
-- 
Benjamin L. Russell  /   DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile:  +011 81 80-3603-6725
Furuike ya, kawazu tobikomu mizu no oto. 
-- Matsuo Basho^ 

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


Re: [Haskell-cafe] Re: Monad explanation

2009-02-04 Thread Max Rabkin
On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell
dekudekup...@yahoo.com wrote:
 Is it possible to write a self-referential function in Haskell that
 modifies itself?

Is it possible to write *any* kind of function in Haskell that
modifies *anything*?

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