reading in ghci-6-4-branch
Who knows, please, how to work with the program of main = interact (\ s - shows (read s :: Bool) \n) in the interpreter ghci ? This is on ghc-cvs-6-4-branch-June-15-2005 under Debian Linux, i386-uknown. When compiled, it works:ghc --make ReadBug ./a.out True press Enter press Control-d True And it does not work under ghci: -- ghci ReadBug.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Compiling Main ( ReadBug.hs, interpreted ) Ok, modules loaded: Main. (0.08 secs, 3210432 bytes) *Main main True ^D*** Exception: Prelude.read: no parse *Main Is this a GHC bug? Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: reading in ghci-6-4-branch
On Wed, 2005-06-22 at 11:04 +0400, Serge D. Mechveliani wrote: Who knows, please, how to work with the program of main = interact (\ s - shows (read s :: Bool) \n) Is this a GHC bug? Regards, Hi Serge, Generally speaking differences that you see between the interactive behaviour of ghci and ghc are due to buffering. By default ghci uses no buffering on stdin and ghc uses line buffering. To get what you want, use hSetBuffering stdin LineBuffering Cheers, Bernie. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Bignums in Haskell
There's nothing inherently imperative about bignums. The current algorithms may have an imperative flavour, but that may be partly because that's what suits the implementation language. If the algorithms are divide-and-conquer, perhaps a tree representation would work very nicely. And even in the imperative case there is no reason in principle why a runST-encapsulated imperative algorithm should be slower than C --- although at the moment GHC does not do a consistently good job of compiling imperative code. So I rather agree with John: implementing bignums in Haskell, and trying to make an efficient implementation based on the state of the art on the numerical side (as opposed to just writing the first code that comes into your head), would be an interesting project for someone to try. It might also expose useful optimisations that are missing in GHC or jhc. It's essential to optimise the 'small bignum' case. In practice, most bignums easily fit in 32 bits. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Marco Morazan | Sent: 22 June 2005 00:39 | To: [EMAIL PROTECTED] | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Bignums in Haskell | | This is a rather interesting question. Most efficient | implementations use array-based representations for bignums that are | mutable. The use of mutable arrays appears to be justified, because of | divide-and-conquer multiplication and division algorithms (e.g. | Karatsuba) that perform these operations in place. The problem, | however, is not this straighforward. Array-based implementations | require copying bigits into the array. A list-based implementation | simply points to the rest of the bignum avoiding any copying. | | If bignums are immutable structures (as in a true functional data | structure), then we should not be surprised if list-based | representations are as good or better than array-based | implementations. In this case, arrays are forced to copy bigits to new | memory locations while lists can continue to point to pieces of a | bignum. To avoid excessive memory allocation for pure bignums | real-time garbage collection on bignum operations can be used. | | It is certainly a rich and interesting line of research. It also | appears to me that having native support for bignums is desirable. It | would certainly make using bignum libraries seamless. | | Best wishes, | | Marco | | On 6/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: | John Meacham writes: | | I wonder if it would be feasable to implement arbitrary precision | integers in pure haskell. unboxed values would probably want to be used | in some places for speed and it would be very motivating to improve | ghc's optimizer. There should be no reason manually unboxed haskell code | should compile slower than C. | | Of course, bignums (integers) can be quite nicely implemented in Haskell, | this is btw. a known student exercise. The implementation is nice, elegant, | etc., but the efficiency... This is not only having unboxed chunks, but | also the global policy of memory allocation. Putting number chunks in lazy | lists involves a substantial overhead. I am not sure how slow it will be, | since our pedagogic games didn't care at all, but we can try to benchmark | it one day... | | | Jerzy Karczmarczuk | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bignum libraries
People, When intending to write a library for large numbers, it worths to keep in mind the following. 1. Efficient multiplication, division and gcd methods may occur rather involved mathematically. 2. It is natural for `arithmetics' to include factorization. Suppose, GHC would like to include such ... 3. It is natural to extend further the library to algebraic numbers. (2) and (3) are definitely very involved mathematically. (2) and (3) are supported by existing libraries (by Lenstra or other experts), -- as I recall, written in C, -- with various wise methods for (1),(2),(3), so that efficient arithmetics for integers is extended to algebraic numbers. (I never looked into all this, only have seen the announcements). Regards, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
comparing 5.02.3 and 6-4-branch
I have installed ghc-5.02.3 and ghc-cvs-6-4-branch-June-15 on the same Linux machine, ported DoCon to 6-4-branch, and compared DoCon-2.06 - ghc-5.02.3 to DoCon-2.09 - ghc-cvs-6-4-branch-June-15 on computer algebra (the CA algorithms are the same). 1. They work correct. 2. The performance and memory eagerness difference is within about 5 %. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bignum libraries
Serge D. Mechveliani wrote: 3. It is natural to extend further the library to algebraic numbers. Bignum arithmetics and algebraic numbers are worlds apart. Sergey - as always - is ambitious to perfection. That's good, but let people do the basics first... Jerzy Karczmarczuk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] A MonadPlusT with fair operations and pruning
G'day all.
Quoting [EMAIL PROTECTED]:
: Since Andrew Bromage wished for that interesting monad, perhaps he has
: in mind a good example of its use. We are particularly interested in a
: short example illustrating soft-cut (and, perhaps, `once').
No obvious small examples of soft cut spring to mind. (If Fergus is
listening, he might have a few suggestions...)
In Prolog parlance, there are three types of cut operation:
- A red cut is anything which prunes away solutions. Red cuts are
usually considered bad style because they have no logical
interpretation.
- A green cut is any cut which does not prune solutions, but which
may prune different proofs of the same solution.
- A blue cut prunes neither solutions, nor proofs. It's basically
an efficiency hack, where the programmer inserts a cut to tell the
Prolog implementation that some piece of code is deterministic when
the implementation can't infer that.
Green and blue cuts are sometimes collectively called grue cuts.
The most obvious use for once (which I may accidentally call commit)
is for blue cuts. This is not so useful in Haskell, but you never know.
The second most obvious use is for those times when some goal isn't
technically deterministic, but you never actually look at the output.
Mercury automatically inserts these commit operations if it can tell that
the output of some goal is never consulted.
One situation where you might use this is in negation-as-failure:
gnot :: (Logic m) = m a - m ()
gnot m = ifte (once m) (const gfail) (gsuccess ())
The point of the once is that when the then branch fails, the system
won't backtrack into m. There's no point, since it's always going to fail.
Another example of pruning is any situation where you are doing some kind
of search which would normally be intractable, but you have a heuristic.
If the heuristic is safe (that is, if whenever it can be applied,
applying it results in no solutions being lost), then the cut is green.
Otherwise it's red. (But that's sometimes okay; if it's an NP-hard
problem, for example, you just make do with the approximation provided
by the heuristic.)
With soft cuts, you can express it like this:
optimise curState
| isGoalState curState
= gsuccess success
| otherwise
= ifte
(tryHeuristic curState)
(\h - do-- then case
s - nextStateWithHeuristic h curState
optimise s)
(do -- else case
s - nextState curState
optimise s)
The soft cut guarantees that you commit to the heuristic if it applies.
As an example, here's a simple (though not THAT short) tic-tac-toe game.
The solution is highly artificial, since the next move computation is
effectively deterministic. A better example might be solving Sudoku
problems, but that's harder to set up than tic-tac-toe.
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
The -fallow-undecidable-instances will be explained in a moment.
module Main where
import Control.Monad
import Control.Monad.Trans
import LogicT
import SFKT
import Data.List
OK, now the monad that most of the computation will be done in...
class (Monad m, MonadIO (t m), LogicT t, MonadPlus (t m)) = MyMonT t m
instance (Monad m, MonadIO (t m), LogicT t, MonadPlus (t m)) = MyMonT t m
This is the reason for -fallow-undecidable-instances. To make the types
not so unwieldy, we would ideally like typeclass synonyms, but Haskell
doesn't support them. So this will have to do.
data Value = B | X | O deriving (Show, Eq, Ord)
type Player = Value
We're going to overload the Value type with two meanings: It can either
mean a value on the tic-tac-toe board, or it can refer to a player (either
X or O).
Code to switch players:
otherPlayer :: Player - Player
otherPlayer X = O
otherPlayer O = X
Code to handle the board:
data Board
= Board Value Value Value Value Value Value Value Value Value
deriving (Show, Eq, Ord)
blankBoard :: Board
blankBoard = Board B B B B B B B B B
-- Return true if the board is a win for player p.
win :: Value - Board - Bool
win p (Board a b c d e f g h i)
= (a == b b == c a == p)
|| (d == e e == f d == p)
|| (g == h h == i g == p)
|| (a == d d == g a == p)
|| (b == e e == h b == p)
|| (c == f f == i c == p)
|| (a == e e == i a == p)
|| (c == e e == g c == p)
draw :: Board - Bool
draw (Board a b c d e f g h i)
= not (any (==B) [a,b,c,d,e,f,g,h,i])
We also need to encode the desirability of a board state. We do this
with an enum type such that more desirable states come first in Ord.
data State = Win | Draw | Lose deriving (Show, Eq, Ord)
otherState :: State - State
otherState Win = Lose
otherState Lose = Win
otherState Draw = Draw
A move is
Re: [Haskell] Haskell version of Crystal Space 3D?
Benjamin L. Russell: Does anybody know any Haskell tool(s) corresponding to Crystal Space 3D ( see http://www.crystalspace3d.org/tikiwiki/tiki-view_articles.php )? The simplest solution would probably be to write a Haskell binding to the Crystal Space 3D library. However, as Crystal Space 3D is huge, that's a significant effort. This would be much like the existing binding to OpenGL http://haskell.org/HOpenGL/ only that Crystal Space 3D provides higher-level functionality. Manuel PS: See http://www.haskell.org/tmrwiki/Bzlib2Binding to get an idea what is involved in producing library bindings. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell version of Crystal Space 3D?
On 6/21/05, Benjamin L. Russell [EMAIL PROTECTED] wrote: Does anybody know any Haskell tool(s) corresponding to Crystal Space 3D ( see http://www.crystalspace3d.org/tikiwiki/tiki-view_articles.php )? To quote from About Crystal Space ( see http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=About+Crystal+Space ), Crystal Space is a free (LGPL) and portable 3D Game Development Kit written in C++. It supports: true six degrees of freedom, colored lighting, lightmapped and stencil based lighting, shader support (CG, vertex programs, fragment programs, ...), mipmapping, portals, mirrors, alpha transparency, reflective surfaces, 3D sprites (frame based or with skeletal animation using cal3d animation library), procedural textures, particle systems, halos, volumetric fog, scripting (using Python, Perl, Java, or potentially other languages), 16-bit and 32-bit display support, OpenGL, and software renderer, font support (also with freetype), hierarchical transformations, physics plugin based on ODE, ... See the extensive list of features for more details. The reason that I ask is that I would like to learn how to write my own version of PlaneShift (a 3D fantasy MMORPG written using Crystal Space 3D) with Haskell, instead of C++, if possible. However, I haven't been able to find any Haskell tools or libraries specific enough for this kind of project. I haven't looked at Crystal Space in a while, but does it have some sort of scripting interface? So you write a C++ class which implements a ton of game-related functions that the game engine then calls to set up the game etc., and in those member functions you can call Haskell functions (via FFI). I'll look into this more this coming fall, if it's possible, I will write a Haskell scripting interface to Crystal Space then (I'm taking a course which involves writing plugins to CS). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell version of Crystal Space 3D?
Two questions: 1) Would a Haskell counterpart to Crystal Space 3D, if implemented, potentially be fast enough to run a project similar to the 3D real-time Crystal Space 3D-based MMORPG PlaneShift ( see http://www.planeshift.it/main_01.html ) on Mac OS X 10.2.8 Jaguar or above? 2) For a hobbyist programmer with a computer science algorithms background including some coursework in lambda-calculus, with some programming background in Scheme and C, and with some knowledge of Java, for the purpose of writing a project similar to PlaneShift, which of the following options would more likely be easier to accomplish? Option A) Use the existing Java scripting support already available in Crystal Space 3D, and deal with debugging potentially larger programs in Java. Option B) Write a Haskell binding for the existing Crystal Space 3D libraries, and then deal with debugging potentially smaller programs in Haskell. I have written some programs in Scheme, C, and Java, but have only audited some lectures, written a few programs, and studied a few chapters on Haskell so far. As it turns out, there is a pretty large conceptual gap between the design of most object oriented libraries and idiomatic Haskell. This makes writing useful bindings in Haskell for such libraries a tricky business. If you want it to be easy, I'd say stick with an OO language that will more closely match the design (caveat: I am not familiar with the design of CS, but I assume it is OO because its written in C++). If you want to learn more about Haskell, then the ease question takes a back seat. To be honest, I don't think there is any easy way to tackle a project of this size -- the planeshift people et al have been working on this for a long time. As to performance, I suspect it would be OK, if you were sufficiently good with a profiler. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell version of Crystal Space 3D?
--- Sebastian Sylvan [EMAIL PROTECTED] wrote: I haven't looked at Crystal Space in a while, but does it have some sort of scripting interface? According to About Crystal Space ( see http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=About+Crystal+Space ), Crystal Space 3D reportedly supports ... scripting (using Python, Perl, Java, and potentially other languages)..., so it probably does. [comments deleted] I'll look into this more this coming fall, if it's possible, I will write a Haskell scripting interface to Crystal Space then (I'm taking a course which involves writing plugins to CS). That would be wonderful. Please keep me posted if you do write it. (Since my mail filter automatically sorts anything sent to or cc'd to haskell@haskell.org to my Haskell Mailing List folder, please be sure to send me a separate e-mail message from the one to this mailing list then if possible.) Many thanks, Benjamin L. Russell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell version of Crystal Space 3D?
--- robert dockins [EMAIL PROTECTED] wrote: As it turns out, there is a pretty large conceptual gap between the design of most object oriented libraries and idiomatic Haskell. This makes writing useful bindings in Haskell for such libraries a tricky business. If you want it to be easy, I'd say stick with an OO language that will more closely match the design (caveat: I am not familiar with the design of CS, but I assume it is OO because its written in C++). If you want to learn more about Haskell, then the ease question takes a back seat. Thank you; that's what I was suspecting. In that case, I'll see if I can use the existing Java scripting support for the Crystal Space 3D libraries. [comments deleted] As to performance, I suspect it would be OK, if you were sufficiently good with a profiler. Thank you; in that case, I should probably learn Haskell for my next project. Alternatively, if Sebastian Sylvan (or anybody else) completes the Haskell scripting support for Crystal Space 3D before I start actually using it, then maybe I'll learn Haskell much sooner. If only there were Haskell scripting support for Crystal Space 3D, Haskell would probably be the better choice overall to write the majority of the project. Many thanks, Benjamin L. Russell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell version of Crystal Space 3D?
On 6/22/05, Benjamin L. Russell [EMAIL PROTECTED] wrote: Two questions: 1) Would a Haskell counterpart to Crystal Space 3D, if implemented, potentially be fast enough to run a project similar to the 3D real-time Crystal Space 3D-based MMORPG PlaneShift ( see http://www.planeshift.it/main_01.html ) on Mac OS X 10.2.8 Jaguar or above? Most likely yes. For several reasons. First of all the bulk of the hard work is still being done in C and C++. Crystal Space is in C++ so all the engine stuff is still done there and the drivers are probably written in C (perhaps with some asm) and a pretty large amount of time is spent there. Second, unless you're doing some _really_ significant processing (stencil shadows, which invovles lots of geomtry processessing, see Doom3 which is pretty CPU-bound) on the CPU side you're going to be GPU bound for pretty much any game. Basically, no matter what you do (within reason) on the CPU is going to make much of a difference compared to, say, optimizing the number of draw calls you send to the driver. I see no problem writing 3D games in Haskell speed-wise. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Dynamic binding
Hi All, In Simon Thompson's The Craft of Functional Programming Second Edition, page 226, it is mentioned that Laufer (1996) describes a Haskell extension to allow dynamic binding. I was wondering if this has been implemented as an extension in any of the haskell compilers, or variants? I am a c++ programmer by trade, only dabbling in Haskell when I was at university, so it seems a disadvantage to me to not have dynamic binding in Haskell 98. What would be the normal way for a Haskell programmer to handle the typical shape example in beginner OO tutorials? Andrew Ward. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Dynamic binding
Pal-Kristian Engstad wrote:
On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
What would be the normal way for a Haskell programmer to handle the
typical shape example in beginner OO tutorials?
By not doing OO. You have to ask yourself, what is the purpose and/or benefit
of using OO? In C++, OO is _useful_ because you restrict the problems of
mutable data (by enclosing it in C++ classes).
ML type languages have other methods of doing things, and guess what, OO is
not that needed for these languages. Sum-types, pattern-matching and data
constructors make half of the need for OO go away. Higher order functions and
make it even less needed. For the rest, there's always work-arounds.
PKE.
To handle the problem of drawing all shapes, in c++, I would have a list
of shape pointers:
struct shape{ virtual void draw(...);};
struct circle : public shape {...};
struct square : public shape {...};
std::listshape * shapes;
for(std::listshape *::iterator it = shapes.begin();it !=
shapes.end();++it)
{ (*it)-draw(...); }
This general pattern of dynamic binding I use over and over again. Could
you give me some example code of this type of thing handled in Haskell's
way? Assuming that the number of classes deriving from shape might get
quite large.
Andrew Ward.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Dynamic binding
At the risk of being excluded from this list
(because of an unmoral number of plugs about OOHaskell),
here we go: http://homepages.cwi.nl/~ralf/OOHaskell/
You might start with the appendices of the paper and also read Section 2
which finally implements the Shapes example with ease. The C++ encoding
is a bit verbose in so far that C++ doesn't quite have type inference,
Haskell does and so OOHaskell does too :-)
Apologies,
Ralf
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Andrew Ward
Sent: Wednesday, June 22, 2005 6:38 PM
To: Pal-Kristian Engstad
Cc: haskell@haskell.org
Subject: Re: [Haskell] Dynamic binding
Pal-Kristian Engstad wrote:
On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
What would be the normal way for a Haskell programmer to handle the
typical shape example in beginner OO tutorials?
By not doing OO. You have to ask yourself, what is the purpose and/or
benefit
of using OO? In C++, OO is _useful_ because you restrict the problems
of
mutable data (by enclosing it in C++ classes).
ML type languages have other methods of doing things, and guess what,
OO
is
not that needed for these languages. Sum-types, pattern-matching and
data
constructors make half of the need for OO go away. Higher order
functions
and
make it even less needed. For the rest, there's always work-arounds.
PKE.
To handle the problem of drawing all shapes, in c++, I would have a
list
of shape pointers:
struct shape{ virtual void draw(...);};
struct circle : public shape {...};
struct square : public shape {...};
std::listshape * shapes;
for(std::listshape *::iterator it = shapes.begin();it !=
shapes.end();++it)
{ (*it)-draw(...); }
This general pattern of dynamic binding I use over and over again.
Could
you give me some example code of this type of thing handled in
Haskell's
way? Assuming that the number of classes deriving from shape might get
quite large.
Andrew Ward.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Compiling ghc with openal
Hi, I am configuring ghc from source(no Ports(since that is broken for this purpose too)) on freebsd 5.4: CPPFLAGS=-I/usr/X11R6/include/ -I/usr/local/include/ -L/usr/local/lib/./configure I had issues with opengl, which were resolved by adding the first dir to CPPFLAGS, but it seems impossible to get ghc to recongize OpenAL, while I have it in /usr/local/lib libogg.a libogg.so libopenal.a libopenal.so.0liborbit-c-backend.a libogg.la libogg.so.5 libopenal.so libopenal.so.0.0.8 In /usr/local/include/AL, I have al.halc.h alctypes.h alext.h alexttypes.haltypes.h alut.h aluttypes.h I get this: checking for library containing alGenSources... no configure: WARNING: no OpenAL library found, so this package will not be built So, basically the question is: how do I tell ghc to find OpenAL? Regards, Ron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Noob error: Type b - c b Does not match IO a
--text follows this line-- I'm trying to learn Haskell from YAHT. My attempt at a solution of Exercise 3.10 is failing with a Type does not match error. The exercise is to write a function that will read numbers (one per line) from the command line, until the number 0 is entered. At this point the program is supposed to print out the sum of the numbers, their product, and for each number, the factorial. The interaction should resemble this: Give me a number (or 0 to stop): 5 Give me a number (or 0 to stop): 8 Give me a number (or 0 to stop): 2 Give me a number (or 0 to stop): 0 The sum is 15 The product is 80 5 factorial is 120 8 factorial is 40320 2 factorial is 2 The code I have for this is given next (the line that fails is indicated by a comment): module Main where import IO main = do hSetBuffering stdin LineBuffering numberList - getList let s = sumList numberList let p = prodList numberList putStrLn (The sum is ++ s) putStrLn (The product is ++ p) printFact numberList fact 0 = 1 fact 1 = 1 fact x = x * fact x - 1 sumList [] = 0 sumList (x:xs) = x + sumList xs prodList [] = 1 prodList (0:xs) = 0 prodList (x:xs) = x * prodList xs printFact [] = return printFact (x:xs) = do -- triggers error message putStrLn (x ++ factorial is ++ fact x) printFact xs return getList = do putStrLn Give me a number (or 0 to stop): numString - getLine let num = read numString if num == 0 then return [] else return (num:getList) Here's the full error I get (from HUGS): IO :l Ex3_10 ERROR ./Ex3_10.hs:28 - Type error in generator *** Term : printFact xs *** Type : b - c b *** Does not match : IO a If anyone can explain to me how to fix this error I'd appreciate it. Also, what is the difference between - and let? Lastly, any comments on any other detail of the code, particularly coding, style are most welcome. Thanks! kj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Noob error: Type b - c b Does not match IO a
On Thu, 2005-06-23 at 00:17 -0400, [EMAIL PROTECTED] wrote: printFact [] = return printFact (x:xs) = do -- triggers error message putStrLn (x ++ factorial is ++ fact x) printFact xs return If anyone can explain to me how to fix this error I'd appreciate it. You forgot to return a value. Typically when you have a function which performs IO, but you don't want to return anything special as its result you return the unit value, written as: (). printFact [] = return () printFact (x:xs) = do -- triggers error message putStrLn (x ++ factorial is ++ fact x) printFact xs return () Another problem with this code is that you are trying to append numbers with strings: x ++ factorial is ++ fact x You will need to convert the numbers to strings explicitly with show: show x ++ factorial is ++ show (fact x) Also, what is the difference between - and let? The key difference is that, in the do notation, - is used exclusively with monads, whereas, let can be used with arbitrary types. The left argument to - is some kind of pattern (most often just a single variable), and the right argument is a monadic expression. Eg: x - getLine means roughly: _run_ getLine, which returns an (IO String) type, and bind the actual String to x, whatever the String happens to be in this instance. Note carefully, that getLine has type (IO String) but x has type String. The let keyword is just an ordinary polymorphic binding, eg let x = 5 + y says x is equal to the expression 5 + y from now on, until the end of the do block, or another binding of x is introduced. Note carefully that if (5 + y) has type Int (for argument's sake), then x also has type Int. Note that for let, unlike -, the right argument is an arbitrary expression, it does not have to be a monadic one. What might be confusing is that you can write: let z = getLine which is not the same as: z - getLine The former just makes z equal to getLine, the latter _runs_ getLine, unpacks the IO result, and binds it to z. You might benefit from looking at how do notation is desugared into ordinary expressions, this might help demystify some of it. Take a look at the Haskell Report: http://www.haskell.org/onlinereport/exps.html#sect3.14 Lastly, any comments on any other detail of the code, particularly coding, style are most welcome. Once you become familiar with Haskell you will learn that some patterns are idiomatic and can be simplified with the use of library functions. For instance, many operations over lists can be achieved with a map, or a fold. Also there are some useful versions of these for monads, such as mapM and foldM. Reading other people's code sometimes helps. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Noob error: Type b - c b Does not match IO a
From: Bernard Pope [EMAIL PROTECTED] Cc: haskell-cafe@haskell.org On Thu, 2005-06-23 at 00:17 -0400, [EMAIL PROTECTED] wrote: You forgot to return a value. ... Much appreciated! kj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
