Re: [Haskell-cafe] What are side effects in Haskell?
On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott co...@conal.net wrote: Everything in Haskell is a function [...] Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a-b for some types a b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Updating doubly linked lists
S. Günther wrote: Whether circular or not, sharing values by using a back pointer is problematic for any update. Why not use a zipper instead? I looked into zippers before and the problem I had was that they never really matched the structure which I needed and which led me to think about this whole knot tying thing again. What kind of structure do you need exactly? The things I read about them always assumed either a list like (i.e. linear) or a tree like (i.e. existence of a root) structure on the type to be plugged into the zipper. Viewing the zipper as the derivative of a data type opens up more possibilities. That being said, every algebraic data types has a tree-like structure. The extra invariants like left . right = right . left that the programmer imposes are what make them different from trees. So I just have to decide whether to use IORefs/Vars (clunky) or to implement zippers for the structure I need (probably too hard for me). It's not too hard for you. You've got a whole haskell-cafe and #haskell at your fingertips, after all. ;) Regards, H. Apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC-ODBC - MS-Access backend problems with inserts
Hi,
I'm using HDBC extensively in my app and it works very well. Most of the
time my app uses an Sqlite database with HDBC and no problems there.
The only problem I have is when I use it against an Access database
backend in which I want to do inserts.
Creating a connection works fine, also running queries. It only budges
when I want to do inserts.
*RedcomBatch.Export handleSqlError $ run dbc insert into mytable
values (?) [toSql dummytext]
*** Exception: user error (SQL error: SqlError {seState = [\HY104\],
seNativ
eError = -1, seErrorMsg = bindparameter 1: [\98: [Microsoft][ODBC
Microsoft Ac
cess Driver]Ung\\252ltiger Genauigkeitswert. \]})
*RedcomBatch.Export
Any ideas why?
Günther
The German part of the error message reads invalid precision value
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Use of abbreviations in Haskell
Hi all,
There is currently a discussion on reddit/programming about Haskell.
One complaint is that Haskell functions often use abbreviated names. I
tend to agree with that. In my personal experience it generally takes
more time to learn a third party Haskell library than libraries
written in other languages. I am not sure why but it could be because
of function names. It seems to me that Haskell's current record syntax
enhances this. Take for example the new xml library,
data Element = Element {
elName :: QName
elAttribs :: [Attr]
elContent :: [Content]
elLine :: Maybe Line
}
data Attr = Attr {
attrKey :: QName
attrVal :: String
}
data QName = QName {
qName :: String
qURI :: Maybe String
qPrefix :: Maybe String
}
Personally i would prefer it to be something like
data Element = Element {
name :: QualifiedName
attributes :: [Attribute]
content :: [Content]
line :: Maybe Line
}
data Attribute = Attribute {
key :: QualifiedName
value :: String
}
data QualifiedName = QualifiedName {
name :: String
uri :: Maybe String
prefix :: Maybe String
}
but the global scope of the record field names doesn't allow that and
therefore all kinds of abbreviations are inserted in front of the
record field names which are hard to remember. So a better record
syntax would be welcome. Perhaps the constructor could be used to
limit the scope of the record field name e.g. QualifiedName.prefix?
Regards,
Felix
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris fr...@theshire.org wrote: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott co...@conal.net wrote: Everything in Haskell is a function [...] Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a-b for some types a b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano I think most of the introductory material I've seen that made me go aha now I get it say pure functional programming is about values, and transformations of those values, and that functions are also values. Then they usually go into admitting that that's only really good for heating up the CPU and that I/O and side-effects have to be made possible, but they're not willing to give up what they won for us by having everything be a value... then monads enter the discussion or actions, and then monads get introduced later. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite grid
Henning Thielemann wrote: A dungeon game? :-) Yes. :-) Thank you all for your answers! I especially like David's no-intermediate-structure solution because it allows for defining the area in terms of neighbours instead of needing an index on the rooms. Now that I have core functionality in my game I want to try and build some interesting areas, such as infinite ones: a infinite grid, or an N-dimensional Hilbert curve. Because rooms are mutable, I am building them inside a state monad and use ids: mkRoom :: M RoomId addExit :: RoomId - Exit - M () type Exit = (String, RoomId) I thought my original question would give me some ideas on how to construct infinite areas, but this monadic interface complicates things somewhat. If I create all rooms at once, runState never returns, so I will have to create them lazily, perhaps by changing: type Exit = M (String, RoomId) But I think in addition to that I will also needs refs, so that the monadic computation can check using a ref whether it's created its target room before. I will have to experiment and think on this some more. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Beginner question
Supposing I have the following code: module Main(main) where main = putStr (show []) I will get these errors from GHC and Hugs respectively: Main.hs:2:16: Ambiguous type variable `a' in the constraint: `Show a' arising from a use of `show' at Main.hs:2:16-22 Probable fix: add a type signature that fixes these type variable(s) ERROR src/Main.hs:2 - Unresolved top-level overloading *** Binding : main *** Outstanding context : Show b But if I change my code to the following, it will compile. module Main(main) where main = putStr (show [1]) I have no problems typing in putStr (show []) in Hugs... runs fine. So what's wrong? I've really tried hard to think of an explanation, but with no luck.. Thanks, Benjamin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Beginner question
Benjamin == Benjamin Bach benjaom...@gmail.com writes: Benjamin Supposing I have the following code: module Main(main) where main = putStr (show []) Benjamin I will get these errors from GHC and Hugs respectively: Main.hs:2:16: Ambiguous type variable `a' in the constraint: `Show a' arising from a use of `show' at Main.hs:2:16-22 Probable fix: add a type signature that fixes these type variable(s) ERROR src/Main.hs:2 - Unresolved top-level overloading *** Binding : main *** Outstanding context : Show b Benjamin But if I change my code to the following, it will Benjamin compile. module Main(main) where main = putStr (show [1]) Benjamin I have no problems typing in putStr (show []) in Benjamin Hugs... runs fine. So what's wrong? I've really tried Benjamin hard to think of an explanation, but with no luck.. I would say that it is complaining that it doesn't know what type of empty list you want it to show. of course, they will all display the same at run time, but it's compile time that is the problem. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Beginner question
On 2 Jan 2009, at 19:57, Benjamin Bach wrote: Supposing I have the following code: module Main(main) where main = putStr (show []) What type is your [] here? main :: IO () putStr :: String - IO () show [] :: String show :: Show a = a - String Now, how is Hugs or GHCi supposed to know the type of []? The only information it has is that it's type belongs to the class Show. You may think it's irrelevant, since empty lists are showed the same; but they are not: for example, ([] :: [Char]) would be shown as '' (empty string). I will get these errors from GHC and Hugs respectively: Main.hs:2:16: Ambiguous type variable `a' in the constraint: `Show a' arising from a use of `show' at Main.hs:2:16-22 Probable fix: add a type signature that fixes these type variable(s) ERROR src/Main.hs:2 - Unresolved top-level overloading *** Binding : main *** Outstanding context : Show b But if I change my code to the following, it will compile. module Main(main) where main = putStr (show [1]) I have no problems typing in putStr (show []) in Hugs... runs fine. So what's wrong? I've really tried hard to think of an explanation, but with no luck.. Thanks, Benjamin ___ 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] Beginner question
module Main(main) where main = putStr (show []) What type is your [] here? (...) You may think it's irrelevant, since empty lists are showed the same; but they are not: for example, ([] :: [Char]) would be shown as '' (empty string). Of course you're right. Didn't know how to type an empty list. main = putStr (show ([] :: [Char])) seems so obvious now. Thanks, Benjamin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What are side effects in Haskell?
David Leimbach leim...@gmail.com wrote: I think most of the introductory material I've seen that made me go aha now I get it say pure functional programming is about values, I dare to claim that functional programming is all about lambdas and reduction, and that functions and values are just two names for the same thing... in the same way that there are words for square and cube, but only one word to sum up all (n-dimensional) hypercubes. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
Felix Martini fmart...@gmail.com wrote:
[..]
data QualifiedName = QualifiedName {
name :: String
uri :: Maybe String
prefix :: Maybe String
}
but the global scope of the record field names doesn't allow that and
therefore all kinds of abbreviations are inserted in front of the
record field names which are hard to remember. So a better record
syntax would be welcome. Perhaps the constructor could be used to
limit the scope of the record field name e.g. QualifiedName.prefix?
/me votes for introducing
data Attribute = Attribute {
Attribute.key :: QualifiedName
Attribute.value :: String
}
It's surely gonna be used, and iff it becomes exceedingly wide-spread,
it can be made default (in 10 years or so).
OTOH, I don't like the idea of having to write Attribute all the
time, and neither want to write pages of
attrKey = Attribute.key
for 1000-element records (or TH to tackle standard language problems,
for that matter), so there has to be some way for library users to
shorten code without being masochistic, somewhat like this:
A = Attribute
, that is, allow definition of data constructors in usual declarations,
up to some limits.
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Use of abbreviations in Haskell
Achim == Achim Schneider bars...@web.de writes: Achim OTOH, I don't like the idea of having to write Attribute Achim all the time, and neither want to write pages of Achim attrKey = Attribute.key Achim for 1000-element records (or TH to tackle standard language Achim problems, for that matter), so there has to be some way for Achim library users to shorten code without being masochistic, Achim somewhat like this: Achim A = Attribute Nay, there's no tax on keystrokes. Code is far more often read than written. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
Hi Cristiano, Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative). And yet I've heard everything is a function on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations: * In pure OO programming, everything is an object, so in pure functional programming, one might assume everything is a function. I find the term value-oriented programming a more accurate label than functional programming. * C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as functions, whether they're of function type or not.) Are there other thoughts insights about the source of the idea that everything is a function? Thanks, - Conal On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris fr...@theshire.org wrote: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott co...@conal.net wrote: Everything in Haskell is a function [...] Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a-b for some types a b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
Colin Paul Adams co...@colina.demon.co.uk wrote: Achim == Achim Schneider bars...@web.de writes: Achim OTOH, I don't like the idea of having to write Attribute Achim all the time, and neither want to write pages of Achim attrKey = Attribute.key Achim for 1000-element records (or TH to tackle standard language Achim problems, for that matter), so there has to be some way for Achim library users to shorten code without being masochistic, Achim somewhat like this: Achim A = Attribute Nay, there's no tax on keystrokes. Code is far more often read than written. Say, did you ever read Java and wondered why you have to continuously scroll to the right albeit using a 500-column terminal? Exceedingly long names are fine to organise a large library, but becomes burdensome when code only uses a subset of it... which is usually the case. _both_ in reading and writing. The longer identifiers are, the shorter information distance between two related ones tends to be, as in generateMapThatTakesAFooAndReturnsABarBydoingBaz vs. generateMapThatTakesAFuAndReturnsABarBydoingBaz compare this with locally-defined aliases mapOfFoo and mapOfFu Short notation isn't the problem, missing explanation of it is.[1] Currently, you can observe stuff like data Abst -- raction = Foo | Bar in my code. I don't mind making that a language feature for increased profit. Anyway, my code tends to get refactored more than being read or written. I want to finish typing _before_ the next idea kicks in. [1] This, as a side note, also tends to make me hate academics. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
On Fri, Jan 2, 2009 at 8:53 PM, Conal Elliott co...@conal.net wrote: I have some speculations: * In pure OO programming, everything is an object, so in pure functional programming, one might assume everything is a function. I find the term value-oriented programming a more accurate label than functional programming. First, I've to say that I'm not a language theorist in any way. That said, I think yours is indeed a good point, yet programs in Haskell are *strictly* expressed in terms of function applications, in contrast to other languages where programs are made up *mostly* of function invocations and other effectful statements, like assignments and IO. The fact that functions are values like any others is, at the same time, the beauty and the power of the functional paradigm. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
module Element where
import QName
import ...
data Element = Element {name :: QName, attribs :: [Attr], content ::
[Content], line :: Maybe Line}
module Attr where
import QName
import ...
data Attr = Attr {key :: QName, val :: String}
module QName where
import ...
data QName = QName {name :: String, uri :: Maybe String, prefix ::
Maybe String}
module Main where
import qualified QName as Q
import qualified Element as E
... Q.name ... E.name ...
On 2 Jan 2009, at 17:20, Felix Martini wrote:
Hi all,
There is currently a discussion on reddit/programming about Haskell.
One complaint is that Haskell functions often use abbreviated names. I
tend to agree with that. In my personal experience it generally takes
more time to learn a third party Haskell library than libraries
written in other languages. I am not sure why but it could be because
of function names. It seems to me that Haskell's current record syntax
enhances this. Take for example the new xml library,
data Element = Element {
elName :: QName
elAttribs :: [Attr]
elContent :: [Content]
elLine :: Maybe Line
}
data Attr = Attr {
attrKey :: QName
attrVal :: String
}
data QName = QName {
qName :: String
qURI :: Maybe String
qPrefix :: Maybe String
}
Personally i would prefer it to be something like
data Element = Element {
name :: QualifiedName
attributes :: [Attribute]
content :: [Content]
line :: Maybe Line
}
data Attribute = Attribute {
key :: QualifiedName
value :: String
}
data QualifiedName = QualifiedName {
name :: String
uri :: Maybe String
prefix :: Maybe String
}
but the global scope of the record field names doesn't allow that and
therefore all kinds of abbreviations are inserted in front of the
record field names which are hard to remember. So a better record
syntax would be welcome. Perhaps the constructor could be used to
limit the scope of the record field name e.g. QualifiedName.prefix?
Regards,
Felix
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] #haskell IRC channel reaches 600 users
A small announcement :) 7 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the #haskell IRC channel[1] on freenode has reached 600 concurrent users! It's now in the top 3 language channels by size. To chart the growth, we can note that the channel was founded in late 2001, and had slow growth till 2006, reaching 200 users in January of that year. Since then growth in the user base has been far more rapid, reaching 300 users in Dec 2006, 400 users in August 2007, 500 users by July 2008, and 600 on January 2, 2009. This puts the channel at the 7th largest community of the 7000 freenode channels, and in the top 3 language communities. For comparision, a sample of the state of the other language communities, with comments comapred to their status a year ago: #php 612 #python 604 #haskell 602 -- up 4 ##c++558 ##c 506 -- down 1 #perl502 -- down 3 #ruby-lang 288 -- down #lisp264 ##javascript 241 #erlang 146 -- unchanged #perl6 129 -- unchanged #scheme 123 -- down #lua 102 -- unchanged #clojure 78 #ocaml70 -- unchanged You can see the growth of the channel over here: http://haskell.org/haskellwiki/IRC_channel If you've not dropped by the channel yet, feel free to come and chat, and toss around some lambdas! :) Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
On Fri, Jan 2, 2009 at 9:21 PM, Miguel Mitrofanov miguelim...@yandex.ru wrote:
module Element where
import QName
import ...
data Element = Element {name :: QName, attribs :: [Attr], content ::
[Content], line :: Maybe Line}
module Attr where
import QName
import ...
data Attr = Attr {key :: QName, val :: String}
module QName where
import ...
data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe
String}
module Main where
import qualified QName as Q
import qualified Element as E
... Q.name ... E.name ...
I'm using this pattern of writing code and, so far, I find it very
convenient. Yet, the code is likely to be spread across lots of files,
which is not always a Good Thing.
Cristiano
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
On Fri, 2009-01-02 at 15:20 +0100, Felix Martini wrote:
Hi all,
There is currently a discussion on reddit/programming about Haskell.
One complaint is that Haskell functions often use abbreviated names. I
tend to agree with that. In my personal experience it generally takes
more time to learn a third party Haskell library than libraries
written in other languages. I am not sure why but it could be because
of function names. It seems to me that Haskell's current record syntax
enhances this. Take for example the new xml library,
data Element = Element {
elName :: QName
elAttribs :: [Attr]
elContent :: [Content]
elLine :: Maybe Line
}
data Attr = Attr {
attrKey :: QName
attrVal :: String
}
data QName = QName {
qName :: String
qURI :: Maybe String
qPrefix :: Maybe String
}
Personally i would prefer it to be something like
data Element = Element {
name :: QualifiedName
attributes :: [Attribute]
content :: [Content]
line :: Maybe Line
}
data Attribute = Attribute {
key :: QualifiedName
value :: String
}
data QualifiedName = QualifiedName {
name :: String
uri :: Maybe String
prefix :: Maybe String
}
but the global scope of the record field names doesn't allow that
They are not global. They are scoped to the module just like any other
function definition. So if you were to put each record in it's own
module you can have Attribute.key today. No one does this though
because that's rather heavy-weight.
I've suggested in #haskell a few times an orthogonal language feature
that will resolve this as well as providing other nice things and, being
orthogonal, it keeps namespacing to namespacing mechanisms (namely
modules.) The feature is simply local modules.
You'd get what you want by simply writing,
module Attribute where
data Attribute = Attribute {
key :: QualifiedName,
value :: String
}
I haven't been able to find any semantic difficulties with this
addition. There are some choices, namely what to import and export by
default and some scoping issues. My choices would be to import
everything in scope at the module declaration, the containing module
tacitly imports everything the contained module exports, the same
notation Module.name is used so a local module would shadow a top-level
(hierarchical) module of the same name (though I don't expect that to be
a common case.) With these conventions there would often be nominal
mutual recursion between local modules at the same level. The
implementation could either check to see if there is any actual mutual
recursion and give an error, or, much more preferably, simply allow
mutually recursive local modules as this should be much easier to handle
than mutually recursive top-level modules.
Some other benefits of this would be a nice way to make abstract data
types, which are also underused due to the heaviness of the module
system. You could write, for example,
module Stack (Stack, empty, push, pop, isEmpty) where
newtype Stack a = Stack [a]
empty = Stack []
push x (Stack xs) = Stack (x:xs)
pop (Stack (x:xs)) = Just (x, Stack xs)
pop (Stack []) = Nothing
isEmpty (Stack xs) = null xs
It should be straightforward to implement this today as a pre-processor
at the cost of not allowing local modules with the same qualified name
as a top-level module and losing some encapsulation. The pre-processor
would simply need to extract all the local module declarations and make
the appropriate hierarchical modules and add the appropriate import
statements. The easiest and most restrictive way to deal with mutual
recursion in this case is simply have a local module only import it's
ancestor modules and any modules explicitly imported. The benefit of
this approach is that it doesn't require any kind of analysis, it could
be done on an almost purely textual basis.
and
therefore all kinds of abbreviations are inserted in front of the
record field names which are hard to remember. So a better record
syntax would be welcome. Perhaps the constructor could be used to
limit the scope of the record field name e.g. QualifiedName.prefix?
Regards,
Felix
___
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] Use of abbreviations in Haskell
module Main where import qualified QName as Q import qualified Element as E ... Q.name ... E.name ... I'm using this pattern of writing code and, so far, I find it very convenient. Yet, the code is likely to be spread across lots of files, which is not always a Good Thing. That's a completely different matter. Personally, I think that holding each module in a separate file is not a great idea. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
On Fri, 2009-01-02 at 23:48 +0300, Miguel Mitrofanov wrote: module Main where import qualified QName as Q import qualified Element as E ... Q.name ... E.name ... I'm using this pattern of writing code and, so far, I find it very convenient. Yet, the code is likely to be spread across lots of files, which is not always a Good Thing. That's a completely different matter. Personally, I think that holding each module in a separate file is not a great idea. +1 jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
Derek Elkins wrote: I haven't been able to find any semantic difficulties with this addition. I like it too... what I run into is that there's an implicit assumption that module of name Foo.Bar.Baz *must* be found in a file Foo/Bar/Baz.[l]hs . module Main seems to be the only one exempted from it. GHC uses this all the time when going looking for a module's source code. (it does help make sure that for any module name in a package, there's only one version of the source-code for that module...) So I think we need to accomplish working out the kinks we may get in trying to break this assumption. -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
Granting the everything is a function idea the best intent, maybe what it's trying to express is the related but different notion that everything *can be* a function -- i.e. that any value can be replaced by a function which yields a value of the appropriate type. Alternately, it could be a confusion between the untyped lambda calculus, in which everything really is a function, and the typed lambda calculus, in which things are more complicated? --S. On Jan 2, 2009, at 2:53 PM, Conal Elliott wrote: Hi Cristiano, Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative). And yet I've heard everything is a function on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations: * In pure OO programming, everything is an object, so in pure functional programming, one might assume everything is a function. I find the term value-oriented programming a more accurate label than functional programming. * C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as functions, whether they're of function type or not.) Are there other thoughts insights about the source of the idea that everything is a function? Thanks, - Conal On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris fr...@theshire.org wrote: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott co...@conal.net wrote: Everything in Haskell is a function [...] Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a-b for some types a b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Minor quibble
Do CORE pragmas inhibit optimizations going between the code inside and outside of the pragma? This seems the case with certain code of mine, but it's not even alluded to in the GHC documentation. ;_; Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gitit - Encoding
Not positive this is relevant, but have you seen http://happstutorial.com/tutorial/foreignchars ? This was my writeup on the problems (and workarounds) I had when working with utf-8 and happs. Overall, it wasn't too bad, but there were some gotchas. Thomas. 2008/12/30 Arnaud Bailly abai...@oqube.com: Hello, I have started using Gitit and I am very happy with it and eager to start hacking. I am running into a practical problem: characters encoding. When I edit pages using accented characters (I am french), the accents get mangled when the page come back from server. The raw files are incorrectly encoded. Where Shall I look for fixing this issue ? Thanks ps: the wiki is live at http://www.notre-ecole.org -- Arnaud Bailly, PhD OQube - Software Engineering web http://www.oqube.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
[Haskell-cafe] How do we decide on the new logo?
Now that the new year is upon us, I suppose we must decide how to decide* on the new logo for the Haskell site. I'm not sure what the protocol and procedure for voting and tallying should be, but see below for a suggestion. (* a higher-order decision, very appropriate) If you haven't seen the page on the Wiki with proposed new logos, be sure to go there and take a look (but recall that submissions are now closed): http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas I want to thank Don for proposing the contest and everyone who contributed logo designs or modifications. As the designer of the last official logo, I think this new crop is terrific, with many suggestions that are more professional-looking and sleeker than the old one: I will have a hard time deciding which one to vote for. Without starting a war on the theory of voting systems, perhaps we should use a system which allows for a certain amount of secondary (etc.) preference to be expressed? (Uh-oh, here come Control.Monad.Voting.HareSTV and Control.Monad.Voting.BordaCount and a hundred other variations, complete with back-tracking and trampolined continuations and ... .) Once we have a winning design, we could perhaps award the designer(s) with a T-shirt or some similar item. We have a small amount of CafeBucks (or whatever) accrued in the CafePress account, despite all efforts to avoid profit (rather like avoiding success at all costs). In the past, these funds have been used to purchase courtesy shirts for a few Haskell luminaries, at the discretion of the store proprietor. (Currently I think there are about $60 available.) -- Fritz (Ruehr) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How do we decide on the new logo?
Fritz Ruehr fru...@willamette.edu wrote: Now that the new year is upon us, I suppose we must decide how to decide* on the new logo for the Haskell site. I'm not sure what the protocol and procedure for voting and tallying should be, but see below for a suggestion. (* a higher-order decision, very appropriate) If you haven't seen the page on the Wiki with proposed new logos, be sure to go there and take a look (but recall that submissions are now closed): http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas I want to thank Don for proposing the contest and everyone who contributed logo designs or modifications. As the designer of the last official logo, I think this new crop is terrific, with many suggestions that are more professional-looking and sleeker than the old one: I will have a hard time deciding which one to vote for. Without starting a war on the theory of voting systems, perhaps we should use a system which allows for a certain amount of secondary (etc.) preference to be expressed? Step 1: Crunch down the size of proposals by factoring out common themes (eg. all the \= logos count as one) Step 2: Determine the winner by polling preferences, same-level preference (ambivalence) allowed (eg. place 1 for logos C and D, place 2 for A and place 3 for B) Step 3: Re-open contest, accepting submissions _using_ the winning logo, in the categories a) colour schemes[1] b), official shapes[2] c), font[3] to go to b), d) layouts of b) + c) Step 4: Repeat step 2 for every category of step 3 Step 5: Announce the new buzzword-compliant branding and hand over a t-shirt to the one who wrote code to apply colour schemes to logos for displaying step 3. Obviously, we need to know the winner of step 2 to completely define step 3. Did I miss anything? [1] coloured, monochrome and b/w [2] shape details[4] vs. (coloured and monochrome vs. b/w) [3] not forgetting its licence [4] like whether or not to completely connect that and \ to a lambda -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
2009/1/3 Conal Elliott co...@conal.net: Are there other thoughts insights about the source of the idea that everything is a function? Lazy evaluation can make values seem like functions, given that laziness can be modeled in a strict imperative language by 0-argument functions. Also, in an uncurried language, decreasing the number of arguments to a function, still keeps it a function, eg foo(int a, int b); // 2 arguments foo(int a); // 1 argument foo(); // 0 arguments, but still a function In a strict language, there is a distinction between 0-argument functions and values; there isn't in Haskell, but it is still nice to maintain the idea of 0-argument functions in Haskell -- which are just values. Cheers, Reiner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell IRC channel reaches 600 users
The haskell community has a well deserved reputation for being one of the friendliest online communities. Perhaps this would be a good point to figure out what we're doing right? I'm convinced that part of it is that offtopic conversation is encouraged through on haskell-cafe, planet haskell and irc. It makes people seem more human and hence harder to flame. Jamie On Fri, Jan 2, 2009 at 8:27 PM, Don Stewart d...@galois.com wrote: A small announcement :) 7 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the #haskell IRC channel[1] on freenode has reached 600 concurrent users! It's now in the top 3 language channels by size. To chart the growth, we can note that the channel was founded in late 2001, and had slow growth till 2006, reaching 200 users in January of that year. Since then growth in the user base has been far more rapid, reaching 300 users in Dec 2006, 400 users in August 2007, 500 users by July 2008, and 600 on January 2, 2009. This puts the channel at the 7th largest community of the 7000 freenode channels, and in the top 3 language communities. For comparision, a sample of the state of the other language communities, with comments comapred to their status a year ago: #php 612 #python 604 #haskell 602 -- up 4 ##c++558 ##c 506 -- down 1 #perl502 -- down 3 #ruby-lang 288 -- down #lisp264 ##javascript 241 #erlang 146 -- unchanged #perl6 129 -- unchanged #scheme 123 -- down #lua 102 -- unchanged #clojure 78 #ocaml70 -- unchanged You can see the growth of the channel over here: http://haskell.org/haskellwiki/IRC_channel If you've not dropped by the channel yet, feel free to come and chat, and toss around some lambdas! :) Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Updating doubly linked lists
There goes my promise like a new years resolution... ;) What kind of structure do you need exactly? What I really need is a structure which represents a two dimensional grid, i.e. it consists of nodes having a value and a list of neighbours attached to it. Point is that if node 1 has node 2 as a neighbour then node 2 has to have node 1 as a neighbour and each node has the same number of neighbours (currently 4, but may vary). So it really is just an undirected planar graph with some restrictions. And it isn't even circular because nodes may have Leaves as neighbours signalling that they are boundary nodes. And since the algorithm I would like to implement is specified in a purely imperative way I need to be able to update the values stored at the nodes and insert new nodes at where there a Leaves. So I figured since the structure isn't even circular I could do it the inefficient way and just use a generalization of the update function for doubly linked lists I came up with before and thus always rebuild the whole structure. That's why I said that thinking about the circular case was just a divergence that rally got me wondering/interested which is why I posted the question in it's short form at the beginning. Anyways, back to the structure I need. One additional thing which will happen during the algorithm is that there will be updates to a certain local neighbourhood of a node. Now I understand, that that might very well be possible with zippers. Instead of lists of neighbouring nodes I might as well save the paths through the graphs separately from the nodes although I only have a very vague intuition about how that would look like. And instead of calculating a lists of nodes to update, I could calculate a path visting the nodes and update them (again beeing unable to escape from the prison of an imperative mindset) traversing the path. The things I read about them always assumed either a list like (i.e. linear) or a tree like (i.e. existence of a root) structure on the type to be plugged into the zipper. Viewing the zipper as the derivative of a data type opens up more possibilities. That being said, every algebraic data types has a tree-like structure. The extra invariants like left . right = right . left that the programmer imposes are what make them different from trees. That's right. After I wrote I that I realized that the distinction I made was a little bit of nonsense since a linear structure is a degenerated case of a tree like structure. But the point was that I just had a hard time generalizing what I read about zippers to structures where you can have embedded cycles, e.g. up . left . down . right = id. So I just have to decide whether to use IORefs/Vars (clunky) or to implement zippers for the structure I need (probably too hard for me). It's not too hard for you. You've got a whole haskell-cafe and #haskell at your fingertips, after all. ;) Righty right, but there's still the possibility that given all the time in the world and the clearest explanations I'm just to dense to get a hold of it. That said I hope that's note the case but I might still be better off timewise to just go with MVars and a straightforward way first and then doing the reading and maybe refactoring to a different approach. cheers Stephan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Use of abbreviations in Haskell
Miguel Mitrofanov schrieb:
module Element where
import QName
import ...
data Element = Element {name :: QName, attribs :: [Attr], content ::
[Content], line :: Maybe Line}
module Attr where
import QName
import ...
data Attr = Attr {key :: QName, val :: String}
module QName where
import ...
data QName = QName {name :: String, uri :: Maybe String, prefix :: Maybe
String}
module Main where
import qualified QName as Q
import qualified Element as E
... Q.name ... E.name ...
+1 for this style
http://www.haskell.org/haskellwiki/Qualified_names
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How do we decide on the new logo?
Fritz Ruehr schrieb: Without starting a war on the theory of voting systems, perhaps we should use a system which allows for a certain amount of secondary (etc.) preference to be expressed? Give everyone 10 points and let every voter assign these points to his favorite logos, where it is possible to give more than one of his points to the same logo. (Or give every user one point and let him choose how to divide this into fractions which can be assigned to logos. Or give every voter any number of points he want and scale them to 1 afterwards.) Another question is how to handle logos with variations. I think all logos of one idea should be grouped and considered one object and the favorite variant can be voted on later. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Parsec : Problems with operator precedence (solution)
Erik de Castro Lopo schrieb:
Erik de Castro Lopo wrote:
binaryOp :: String - (SourcePos - a - a - a) - E.Assoc - E.Operator
Char st a
binaryOp name con assoc =
E.Infix (reservedOp name
getPosition =
return . con) assoc
Replacing reservedOp above with:
reservedOpNf :: String - CharParser st ()
reservedOpNf name = try (reservedOp name notFollowedBy (oneOf |=))
fixed the problem.
Hi Erik,
There is an easy, better solution, modifying the lexer:
lexer = makeTokenParser $ emptyDef
{ L.reservedOpNames = words || | ^ }
reservedOp = P.reservedOp lexer
identifier = P.identifier lexer
...
I'd try to avoid 'try', if possible.
benedikt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How do we decide on the new logo?
Achim Schneider schrieb: Step 2: Determine the winner by polling preferences, same-level preference (ambivalence) allowed (eg. place 1 for logos C and D, place 2 for A and place 3 for B) We recently had to vote for the new design of our university's website. This was done by asking every voter for an order of preference, with no equal preferences allowed. However, when the maintainer of the voting system was asked, how these answers are processed, he didn't know an answer. I think he finally converted positions to scores and added them. However, I suspect in chosing the scores for each position, he had an essential influence of the outcome of the election. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell IRC channel reaches 600 users
On Sat, Jan 03, 2009 at 12:01:06AM +, Jamie Brandon wrote: The haskell community has a well deserved reputation for being one of the friendliest online communities. Perhaps this would be a good point to figure out what we're doing right? I'm convinced that part of it is that offtopic conversation is encouraged through on haskell-cafe, planet haskell and irc. It makes people seem more human and hence harder to flame. Jamie I have no hard data to back this up, but I suspect that another large part of the answer is simply the fact that culture tends to be self-reinforcing. So, as I understand it, we mostly have Shae to thank for very intentionally creating a friendly culture in the first place. Many online communities simply arise without anyone giving much thought to the sort of culture they want to create; empirically, emergent online culture is not so friendly. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parsec : Problems with operator precedence (solution)
Benedikt Huber wrote:
There is an easy, better solution, modifying the lexer:
lexer = makeTokenParser $ emptyDef
{ L.reservedOpNames = words || | ^ }
reservedOp = P.reservedOp lexer
identifier = P.identifier lexer
...
I'd try to avoid 'try', if possible.
Hi Benedikt,
I did try that (reservedOpNames as a list of operators as strings)
but that interferred rather badly with another part of the parser
which handles raw inline XML like this (yes, utterly horrid):
var xdata = xmlsucks/xml ;
Because I had the XML parsing working when I hit the operator precedence
problem I worked towards a solution that didn't break the XML rather
than do the right thing to fix the operator precedence and then have to
fix the XML part.
Erik
--
-
Erik de Castro Lopo
-
how am I expected to quit smoking if I have to deal with NT
every day -- Ben Raia
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Don't make 'show*' functions
Henning Thielemann wrote: I think, that a user who uses GHCi becomes a developer. For me a user is someone who calls compiled Haskell programs. GHCi makes for a great calculator. I agree that, to a first approximation, users call compiled binaries and developers use GHCi. But there's a big gap between those two which is not devoid of life. I think there are many more people who use GHCi as an interactive shell session than most folks give credit for. More particularly, I posit that the prevalence of these people is part of what muddies the questions of who the audience of Show should be. Even if we chose to lump them in with developers there's still the very real problem of resolution. Many people develop by bricolage, which means that over time they transition from being interactive users or casual developers or scripters into being 'real' developers. Just as often 'real' developers transition into interaction when they want to do active debugging. We should be able to visualize data differently at each of these different stages, but it is just as important ---if not moreso--- to be able to transition between different resolutions easily. So far, the Show class is very much a one-size-fits-all solution which doesn't fit anyone very well. IMO, trying to refine or redefine the intended semantics of Show is wrongheaded, because the space between users and developers is far closer to being continuous than discrete. A single type-class that looks like Show cannot possibly resolve this mismatch, no matter what the intended semantics are. The continuous space between users and developers requires some solution which takes the variability of audiences/resolutions into consideration. Trying to shove everyone into the same bucket has been not working for some time already. We should acknowledge the real problem behind that. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What are side effects in Haskell?
Reiner Pope reiner.p...@gmail.com wrote: 2009/1/3 Conal Elliott co...@conal.net: Are there other thoughts insights about the source of the idea that everything is a function? Lazy evaluation can make values seem like functions, given that laziness can be modeled in a strict imperative language by 0-argument functions. Also, in an uncurried language, decreasing the number of arguments to a function, still keeps it a function, eg foo(int a, int b); // 2 arguments foo(int a); // 1 argument foo(); // 0 arguments, but still a function In a strict language, there is a distinction between 0-argument functions and values; there isn't in Haskell, but it is still nice to maintain the idea of 0-argument functions in Haskell -- which are just values. You can factor a cool intuitive understanding about IO actions not being the action itself, but just tokens that represent an action, out of this, by adding just one sentence. I guess the proper way to offset functions and values depends on what you want to explain, and multiple views on the same thing can't hurt. Conal, you aren't interrogating the list to figure out how to write a Haskell version of the wizard book, are you? We'd have to stop the pizza deliveries if you stop working on reactive... ;) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Use of abbreviations in Haskell
Derek Elkins derek.a.elk...@gmail.com wrote:
module Attribute where
data Attribute = Attribute {
key :: QualifiedName,
value :: String
}
+1
Assuming that the above definition is inside a file called Foo/Bar.hs
and, syntactically, inside a module Foo where, I think a sane way to
search for the module Foo.Bar.Attribute is
a) Foo.Bar.Attribute.hs
b) Foo/Bar.Attribute.hs
c) Foo/Bar/Attribute.hs
d) Foo.Bar.hs:Attribute
e) Foo/Bar.hs:Attribute
...I guess you see a pattern emerging. It's not entirely unlike public
inner java classes[1]
The reason that the Main module is an exception to the naming/placement
rules is that it's _always_ the root of the search tree, which is only
confusing if you insist on being confused by it[2].
Furthermore, if you
import Foo.Bar
, you get Attribute.(..) imported by default, _except_ if you also do
import [qualified] Foo.Bar.Attribute [as A]
This fixes both the insanity of having thousands of three-line modules
in thousands of files (which noone wants to manage) and source
directories consisting of more directories than files.
[1]uhmm... can inner classes be public? I think I never tried...
[2]like javac chooses to be.
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How do we decide on the new logo?
Henning Thielemann schlepp...@henning-thielemann.de wrote: Achim Schneider schrieb: Step 2: Determine the winner by polling preferences, same-level preference (ambivalence) allowed (eg. place 1 for logos C and D, place 2 for A and place 3 for B) We recently had to vote for the new design of our university's website. This was done by asking every voter for an order of preference, with no equal preferences allowed. However, when the maintainer of the voting system was asked, how these answers are processed, he didn't know an answer. I think he finally converted positions to scores and added them. However, I suspect in chosing the scores for each position, he had an essential influence of the outcome of the election. I intended to sum up all scaled preferences for every logo, and take the smallest one as the winner. Scaled meaning that every voter, in the end, had the same total points to distribute... like in your system. I like mine because it shifts the calculation burden from the voter to the program doing the processing. A vote of all 10's would be equivalent to a vote of all ones, and a vote of just one one would be equivalent to a vote of one one and the rest two's. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What are side effects in Haskell?
Adrian Neumann aneum...@inf.fu-berlin.de wrote: Am 23.12.2008 um 15:16 schrieb Hans van Thiel: I just saw somewhere that one of the purposes of monads is to capture side effects. I understand what a side effect is in C, for example. Say you want to switch the contents of two variables. Then you need a third temporary variable to store an intermediate result. If this is global, then it will be changed by the operation. [...] However when you *do* want state you can simulate it with a monad. The IO Monad is a special case here, since its actions don't change your program, they change the world the program is running in (writing files etc.). getLine etc are functions when you think of them as taking a hidden parameter, the state of the world. So getChar would become getChar :: World - (Char,World) but the world stays hidden inside the IO Monad. Yes, I like this view, but you shouldn't say that the world is hidden inside the IO monad, because you can easily use part of that state in computations. In my view, the IO monad is some notion of this: type IO = State World The main difference between this and the real IO is that there is no value for the (entire) world's state you could refer to, which eliminates the need for 'get', 'put', and by introducing a 'main' computation, also 'runState' becomes unnecessary. In fact, this makes the whole 'World' type unnecessary. So IO is really just a theoretical construct to make input/output consistent with referential transparency. This is a very short version of what I have written in section 7 [1] of my monads tutorial. [1] http://ertes.de/articles/monads.html#section-7 Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife = sex) http://blog.ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
