From guthrie at mum.edu Sun Feb 1 03:13:02 2015 From: guthrie at mum.edu (Gregory Guthrie) Date: Sat, 31 Jan 2015 21:13:02 -0600 Subject: [Haskell-beginners] Cabal reset/restart Message-ID: <08EF9DA445C4B5439C4733E1F35705BA0492BF915163@MAIL.cs.mum.edu> I did a complete reset and restart of Haskell & Cabal, and trying to re-install my former packages on a new clean system, most went easily but there are already a number which would not install. (Deleted .ghc, .cabal, and .sandbox; reinstalled Platform). 1) "ghc-pkg check" indicates a lot of issues (although most seemed to be warnings about missing .hi or haddock html files). Many seem to be related to looking for older versions, e.g. it complains that: There are problems in package Win32-2.2.2.0: Warning: library-dirs: E:\Plang\Haskell Platform\lib\Win32-2.2.2.0 doesn't exist or isn't a directory Warning: include-dirs: E:\Plang\Haskell Platform\lib\Win32-2.2.2.0\include doesn't exist or isn't a directory import-dirs: E:\Plang\Haskell Platform\lib\Win32-2.2.2.0 doesn't exist or isn't a directory cannot find any of ["libHSWin32-2.2.2.0.a","libHSWin32-2.2.2.0.p_a","libHSWin32-2.2.2.0-ghc7.8.3.so","libHSWin32-2.2.2.0- ghc7.8.3.dylib","HSWin32-2.2.2.0-ghc7.8.3.dll"] on library path And indeed it is not there, but Win32-2.3.0.2 is present, and similarly for most all others that I see. So why are these being reported as problems, and what to do? 2) cabal install of several of my previous packages fails; is there just some intrinsic incompatibility of these packages, or some other error? An example: C:\Users\myUser\.cabal-sandbox>cabal install cgi Resolving dependencies... In order, the following would be installed: exceptions-0.6.1 (reinstall) changes: mtl-2.1.3.1 -> 2.2.1, transformers-0.3.0.0 -> 0.4.2.0 network-2.6.0.2 (new version) cgi-3001.2.2.0 (new version) cabal: The following packages are likely to be broken by the reinstalls: temporary-1.2.0.3 ghc-mod-5.2.1.2 either-4.3.3 monad-journal-0.7 Use --force-reinstalls if you want to install anyway. 3) ghc-pkg check indicates a lot of broken packages for a new installation, Although all those that I checked of these are from old versioning as above, and there really is a good and more current version installed: The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. Win32-2.2.2.0 time-1.4 template-haskell-2.7.0.0 regex-base-0.93.2 process-1.1.0.1 pretty-1.1.1.0 parsec-3.1.3 old-time-1.1.0.0 old-locale-1.0.0.4 integer-gmp-0.4.0.0 HTTP-4000.2.5 hpc-0.5.1.1 hoopl-3.8.7.3 haskell98-2.0.0.1 haskell2010-1.1.0.1 haskell-platform-2012.4.0.0 ghc-prim-0.2.0.0 ghc-7.4.2 filepath-1.3.0.0 fgl-5.4.2.4 extensible-exceptions-0.1.1.4 directory-1.1.0.2 deepseq-1.3.0.0 containers-0.4.2.1 cgi-3001.1.7.4 Cabal-1.14.0 bytestring-0.9.2.1 binary-0.5.1.0 base-4.5.1.0 array-0.4.0.0 zlib-0.5.4.0 xhtml-3000.2.1 vector-0.10.0.1 transformers-0.3.0.0 text-0.11.2.3 syb-0.3.7 stm-2.4 split-0.2.1.1 regex-posix-0.95.2 regex-posix-0.95.2 regex-compat-0.95.1 regex-compat-0.95.1 random-1.0.1.1 QuickCheck-2.5.1.1 primitive-0.5.0.1 parallel-3.2.0.3 OpenGL-2.2.3.1 network-2.3.1.0 HUnit-1.2.5.1 ------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 2 18:22:45 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 2 Feb 2015 10:22:45 -0800 Subject: [Haskell-beginners] Build woes (cabal configure can't find sandboxed deps) Message-ID: Hi list, I've got a number of modules in a project set up like this: project |-- foo |-- bar |-- baz `-- sandbox where 'foo', 'bar' and 'baz' are modules which depend on one another, and 'sandbox' is a sandbox. Before building from scratch, I do a $(cabal sandbox init --sandbox=../sandbox) in each of the module folders. If I run $(cabal install ./foo ./bar ./baz) from the projects/ directory, everything is happy. However, if I reconfigure one of the sub-modules with different flags, it fails with missing dependencies: # in foo/ $ cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. # module builds correctly $ cabal configure --enable-tests Resolving dependencies... Configuring foo-0.1... $ cabal build dist/setup/setup.hs:13:8: Could not find module ?System.FilePath.Glob? Perhaps you meant System.FilePath (from filepath-1.3.0.2) System.FilePath.Posix (from filepath-1.3.0.2) Use -v to see a list of the files searched for. Glob is installed in the sandbox. I've tried pointing to the sandbox config file manually with both $(cabal --sandbox-config-file=project/foo/cabal.sandbox.config) and $(cabal --sandbox-config-file=project/cabal.sandbox.config) with the same result. Cabal insists that Glob isn't installed until I nuke the foo/dist directory and start over. I figure there's some flag I need to pass to `cabal configure` that I'm missing, but I can't figure out what it is. Anybody have any hints? Cheers, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 2 20:40:19 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 2 Feb 2015 12:40:19 -0800 Subject: [Haskell-beginners] Build woes (cabal configure can't find sandboxed deps) In-Reply-To: References: Message-ID: Hmm, nuking ~/.cabal and ~/.ghc seems to have fixed it. Good old cabal. When in doubt, delete everything. On Mon, Feb 2, 2015 at 10:22 AM, Alex Hammel wrote: > Hi list, > > I've got a number of modules in a project set up like this: > > project > |-- foo > |-- bar > |-- baz > `-- sandbox > > where 'foo', 'bar' and 'baz' are modules which depend on one another, and > 'sandbox' is a sandbox. Before building from scratch, I do a $(cabal > sandbox init --sandbox=../sandbox) in each of the module folders. > > If I run $(cabal install ./foo ./bar ./baz) from the projects/ directory, > everything is happy. However, if I reconfigure one of the sub-modules with > different flags, it fails with missing dependencies: > > # in foo/ > $ cabal build > Package has never been configured. Configuring with default flags. If this > fails, please run configure manually. > # module builds correctly > > $ cabal configure --enable-tests > Resolving dependencies... > Configuring foo-0.1... > > $ cabal build > > dist/setup/setup.hs:13:8: > Could not find module ?System.FilePath.Glob? > Perhaps you meant > System.FilePath (from filepath-1.3.0.2) > System.FilePath.Posix (from filepath-1.3.0.2) > Use -v to see a list of the files searched for. > > Glob is installed in the sandbox. > > I've tried pointing to the sandbox config file manually with both $(cabal > --sandbox-config-file=project/foo/cabal.sandbox.config) and $(cabal > --sandbox-config-file=project/cabal.sandbox.config) with the same result. > Cabal insists that Glob isn't installed until I nuke the foo/dist directory > and start over. > > I figure there's some flag I need to pass to `cabal configure` that I'm > missing, but I can't figure out what it is. Anybody have any hints? > > Cheers, > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Feb 2 20:44:04 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 2 Feb 2015 15:44:04 -0500 Subject: [Haskell-beginners] Build woes (cabal configure can't find sandboxed deps) In-Reply-To: References: Message-ID: On Mon, Feb 2, 2015 at 3:40 PM, Alex Hammel wrote: > Hmm, nuking ~/.cabal and ~/.ghc seems to have fixed it. > Good old cabal. When in doubt, delete everything. > That says to me you didn't have the sandbox set up right. I'd have set up the sandbox and then used --add-source for foo, bar, and baz... or, sometimes, symlink the original sandbox into those dirs, but I suspect that's asking for trouble :) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 2 20:50:05 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 2 Feb 2015 12:50:05 -0800 Subject: [Haskell-beginners] Build woes (cabal configure can't find sandboxed deps) In-Reply-To: References: Message-ID: That's exactly what I did. From my setup script: cabal sandbox init --sandbox sandbox for folder in $SUBMODULES; do (cd "$folder"; cabal sandbox init --sandbox ../sandbox) cabal sandbox add-source "$folder" done $SUBMODULES contains ./foo, ./bar, and ./baz On Mon, Feb 2, 2015 at 12:44 PM, Brandon Allbery wrote: > On Mon, Feb 2, 2015 at 3:40 PM, Alex Hammel wrote: > >> Hmm, nuking ~/.cabal and ~/.ghc seems to have fixed it. >> Good old cabal. When in doubt, delete everything. >> > > That says to me you didn't have the sandbox set up right. I'd have set up > the sandbox and then used --add-source for foo, bar, and baz... or, > sometimes, symlink the original sandbox into those dirs, but I suspect > that's asking for trouble :) > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewmoppett at gmail.com Tue Feb 3 09:30:20 2015 From: matthewmoppett at gmail.com (Matthew Moppett) Date: Tue, 3 Feb 2015 16:30:20 +0700 Subject: [Haskell-beginners] Vim + Syntastic + ghc-mod: over-verbose error messages Message-ID: I'm not sure if this is the right forum to raise this issue, but: Trying out the Syntastic plugin in Vim, I've found that it displays confusingly over-verbose error messages that contain unnecessary information about the module location of identifiers -- e.g.: Config.hs|13 col 7 error| Couldn't match type `(Config.ConfigElem, GHC.Base.String)' with `[GHC.Types.Char]'Expected type: [GHC.Base.String] -> containers-0.5.0.0:Data.Map.Base.Map Config.ConfigElem GHC.Base.String Actual type: [(Config.ConfigElem, GHC.Base.String)] -> containers-0.5.0.0:Data.Map.Base.Map Config.ConfigElem GHC.Base.StringIn the expression: Data.Map.Strict.fromList :: [GHC.Base.String] -> containers-0.5.0.0:Data.Map.Base.Map Config.ConfigElem GHC.Base.StringIn an equation for `Config.foo': Config.foo = Data.Map.Strict.fromList :: [GHC.Base.String] -> containers-0.5.0.0:Data.Map.Base.Map Config.ConfigElem GHC.Base.String Syntastic uses the output from "ghc-mod check" to generate this, and in turn I think ghc-mod relies on ghc, since options can be passed to ghc from ghc-mod using the -g option flag. Does anyone know of a way to modify the behaviour of Syntastic/ghc-mod/ghc to produce output that's more readable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhub.bits at gmail.com Wed Feb 4 03:23:42 2015 From: madhub.bits at gmail.com (Madhu Babu) Date: Tue, 3 Feb 2015 22:23:42 -0500 Subject: [Haskell-beginners] ghc --make Vs runhaskell Message-ID: Hi !, I have the following program from ?Learn You a Haskell? ( http://learnyouahaskell.com/input-and-output#randomness ). When i run this using runhaskell, code works perfectly fine. However, when i compile and run the binary file, code behaves differently. Basically, in the following code, we print a line first and the read the line from stdin. This behavior works perfectly fine when using ?runhaskell guess.hs?. But when i say ?./guess?, i had to type in a number directly ( i.e. first prompt is skipped ). btw.. i am using mac yosomite command terminal. Any help greatly appreciated.. Thanks a lot in advance.. import System.Random import Control.Monad(when) main = do ranGen <- getStdGen let (rand,_) = randomR (1,10) ranGen :: (Int,StdGen) putStr "Guess a number between 1 and 10 : " numStr <- getLine when(not $ null numStr) $ do let num = read numStr if rand == num then putStrLn "Yuhaa!! you are right baby!" else putStrLn $ "Sorry dude!! it was " ++ show rand newStdGen main -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 4 03:35:59 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 3 Feb 2015 22:35:59 -0500 Subject: [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu wrote: > Basically, in the following code, we print a line first and the read the > line from stdin. This behavior works perfectly fine when using ?runhaskell > guess.hs?. But when i say ?./guess?, i had to type in a number directly ( > i.e. first prompt is skipped ). > runhaskell is presumably using unbuffered I/O for some reason, so outputting directly to the terminal. The compiled program follows standard Unix buffering conventions: line buffering on output to a terminal, so the putStr is sitting in a buffer waiting to see a newline output. C / C++ programs also do buffering, but there's a heinous hack which detects reads on stdin and flushes stdout beforehand. (Heinous because there is no guarantee that they are actually related --- but na?ve programmers invariably do not learn about line buffering and expect all output to be unbuffered(*), and C standard library programmers eventually gave up and catered to them after years of trying to get them to pay attention. I have a nasty suspicion we're going to end up with a similar horrible hack in Haskell eventually.) You can use hFlush from System.IO to flush the prompt out to the terminal, or disable output buffering with hSetBuffering in the same module. (*) At some point someone will pop up and say that on modern computers, buffering is obsolete because it's fast enough that horribly inefficient character-at-a-time I/O is good enough. Yet, I can *still* see visible hesitations when character-at-a-time I/O is used on a modern Intel core i5/i7. And your disk benchmarks will *tank* even with server-class disk subsystems. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Wed Feb 4 03:45:07 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 4 Feb 2015 10:45:07 +0700 Subject: [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: Hey Madhu, Right, this is another gotcha -- haskell has a bunch of them. As Tristan and Brandon have remarked, the runhaskell interpreter and compiled programs handle output buffering differently. Here are changes to make your game work: On Wed, Feb 4, 2015 at 10:23 AM, Madhu Babu wrote: > import System.Random > import Control.Monad(when) > import System.IO > main = do > ranGen <- getStdGen > let (rand,_) = randomR (1,10) ranGen :: (Int,StdGen) > hSetBuffering stdout NoBuffering > putStr "Guess a number between 1 and 10 : " > You might want to take a look at the "Summing Two Numbers" section here: https://www.haskell.org/onlinereport/io.html -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhub.bits at gmail.com Wed Feb 4 04:57:16 2015 From: madhub.bits at gmail.com (Madhu Babu) Date: Tue, 3 Feb 2015 23:57:16 -0500 Subject: [Haskell-beginners] [Haskell-cafe] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: Thanks a lot. .this really helps.. On Feb 3, 2015 10:35 PM, "Tristan Seligmann" wrote: > On 4 February 2015 at 05:23, Madhu Babu wrote: > > Basically, in the following code, we print a line first and the read the > > line from stdin. This behavior works perfectly fine when using > ?runhaskell > > guess.hs?. But when i say ?./guess?, i had to type in a number directly ( > > i.e. first prompt is skipped ). > > This is most likely due to stdio buffering; usually stdin/stdout are > line buffered, so data you write with putStr may not actually be > written until a newline is written. This post / thread details some > ways to handle this problem: > > https://www.haskell.org/pipermail/beginners/2010-March/003692.html > -- > mithrandi, i Ainil en-Balandor, a faer Ambar > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Feb 5 03:45:30 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 4 Feb 2015 22:45:30 -0500 Subject: [Haskell-beginners] [Haskell-cafe] ghc --make Vs runhaskell In-Reply-To: <2DB2EE12-5811-4FAC-9938-D237A23ACF7D@cs.otago.ac.nz> References: <2DB2EE12-5811-4FAC-9938-D237A23ACF7D@cs.otago.ac.nz> Message-ID: On Wed, Feb 4, 2015 at 10:10 PM, Richard A. O'Keefe wrote: > Given things like sockets, STREAMS, and ptys, I am not > sure that it is _possible_ for a Unix system to determine whether two > streams > are or are not "related" reliably. > It's not. I was not implying that it was, or that it was even a good idea to try to do so. On the other hand, flushing *every* line-buffered FILE is rather overkill but less heinous than highly dubious and untestable assumptions about relationships. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 5 11:37:12 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 12:37:12 +0100 Subject: [Haskell-beginners] =?windows-1252?q?Couldn=27t_match_expected_ty?= =?windows-1252?q?pe_=91IO_=28=29=92_with_actual_type_=5BInteger=5D?= Message-ID: <54D355E8.3010503@home.nl> An HTML attachment was scrubbed... URL: From max.voit+mlhb at with-eyes.net Thu Feb 5 12:01:50 2015 From: max.voit+mlhb at with-eyes.net (Max Voit) Date: Thu, 5 Feb 2015 13:01:50 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <54D355E8.3010503@home.nl> References: <54D355E8.3010503@home.nl> Message-ID: <20150205130150.2e6dd21c@veeloqu.lan> Hi Roelof, On Thu, 05 Feb 2015 12:37:12 +0100 Roelof Wobben wrote: > main :: IO () > main = do > ??? toDigits 123 > src/Main.hs at 14:5-14:17 > Couldn't match expected type ?IO ()? with actual type > [Integer] > ? In a stmt of a 'do' block: toDigits 123 In the expression: do > { toDigits 123 } since your do block consists only of one expression, actually your main looks like: main :: IO () main = toDigits 123 Perhaps this explains where the problem lies. Considering, however, do-notation: The last statement of a do-block needs to be an expression of the type of the do-block. Translating do-notation to bind operator sequences[1] may be helpful in understanding this. best, Max [1] http://en.wikibooks.org/wiki/Haskell/do_notation From r.wobben at home.nl Thu Feb 5 12:25:16 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 13:25:16 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <20150205130150.2e6dd21c@veeloqu.lan> References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> Message-ID: <54D3612C.5080800@home.nl> Max Voit schreef op 5-2-2015 om 13:01: > Hi Roelof, > > On Thu, 05 Feb 2015 12:37:12 +0100 > Roelof Wobben wrote: > >> main :: IO () >> main = do >> toDigits 123 >> src/Main.hs at 14:5-14:17 >> Couldn't match expected type ?IO ()? with actual type >> [Integer] >> ? In a stmt of a 'do' block: toDigits 123 In the expression: do >> { toDigits 123 } > since your do block consists only of one expression, > actually your main looks like: > > main :: IO () > main = toDigits 123 > > Perhaps this explains where the problem lies. > > Considering, however, do-notation: The last statement of a do-block > needs to be an expression of the type of the do-block. Translating > do-notation to bind operator sequences[1] may be helpful in > understanding this. > > best, > Max > > [1] http://en.wikibooks.org/wiki/Haskell/do_notation > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners Thanks, Another question : how can I display the array ? putStrln works only for strings, Roelof From nadirsampaoli at gmail.com Thu Feb 5 12:26:54 2015 From: nadirsampaoli at gmail.com (Nadir Sampaoli) Date: Thu, 5 Feb 2015 13:26:54 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <54D355E8.3010503@home.nl> References: <54D355E8.3010503@home.nl> Message-ID: "Roelof Wobben": > > I have this : > > -- | Main entry point to the application. > module Main where > > > -- | convert a number to a array in pieces where a negative number will be a empty array. > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | otherwise = n/10 : [] > > -- | The main entry point. > main :: IO () > main = do > toDigits 123 First of all, what do you expect from your program? The problem with your code is that `main` declares type `IO ()` in its signatures but its body has another type, [Integer]. What do you think is wrong with the compiler's output? -- Nadir -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.voit+mlhb at with-eyes.net Thu Feb 5 12:35:11 2015 From: max.voit+mlhb at with-eyes.net (Max Voit) Date: Thu, 5 Feb 2015 13:35:11 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <54D3612C.5080800@home.nl> References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> Message-ID: <20150205133511.5fd4b93a@veeloqu.lan> On Thu, 05 Feb 2015 13:25:16 +0100 Roelof Wobben wrote: > Another question : how can I display the array ? > > putStrln works only for strings, Yep, so you need to convert it to a string and putStrLn that. Kindly enough typing ":i []" into ghci tells you, that lists have an instance for "show". Anonther option would be to convert every single list element to a string and putStrLn that. "map" comes in handy here (or mapM_ if you directly want to use print instead of putStrLn . show). best, Max From r.wobben at home.nl Thu Feb 5 13:07:02 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 14:07:02 +0100 Subject: [Haskell-beginners] =?windows-1252?q?Couldn=27t_match_expected_ty?= =?windows-1252?q?pe_=91IO_=28=29=92_with_actual_type_=5BInteger=5D?= In-Reply-To: <20150205133511.5fd4b93a@veeloqu.lan> References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> Message-ID: <54D36AF6.50704@home.nl> Max Voit schreef op 5-2-2015 om 13:35: > On Thu, 05 Feb 2015 13:25:16 +0100 > Roelof Wobben wrote: > >> Another question : how can I display the array ? >> >> putStrln works only for strings, > Yep, so you need to convert it to a string and putStrLn that. Kindly > enough typing ":i []" into ghci tells you, that lists have an instance > for "show". > > Anonther option would be to convert every single list element to a > string and putStrLn that. "map" comes in handy here (or mapM_ if you > directly want to use print instead of putStrLn . show). > > best, > Max > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > Thanks that part worked fine. One part I cannot figure out is how to make this : -- | Main entry point to the application. module Main where -- | convert a number to a array in pieces where a negative number will be a empty array. toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | otherwise = n `mod` 10 : [] -- | The main entry point. main :: IO () main = do print $ toDigits 123 Now it showing only [1] or [23] I have to find out how I can do something like this toDigits 23 [1] But I cannot do this that way because it has to be Integer -> [Integer] Who has a tip for me ? Roelof From marcin.jan.mrotek at gmail.com Thu Feb 5 16:29:08 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 5 Feb 2015 17:29:08 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <54D36AF6.50704@home.nl> References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> <54D36AF6.50704@home.nl> Message-ID: Well, toDigits is always finishing its work after dividing the input number once, and always returns lists of at most one element. You need it to call itself recursively until it's done, and append the calculated digit to the result: toDigits :: Integer -> [Integer] toDigits n | n <= 0 = [] | otherwise = n `mod` 10 : toDigits (n `div` 10) The <= is necessary, otherwise the function would loop infinitely on 0. This version will print the digits in reverse, so you might move the code to a local function in toDigits, and make toDigit call it and then reverse the result. I'd strongly recommend reading a Haskell tutorial (for example http://learnyouahaskell.com ) to learn the basics. Kind regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From timmelzer at gmail.com Thu Feb 5 17:16:37 2015 From: timmelzer at gmail.com (Norbert Melzer) Date: Thu, 5 Feb 2015 18:16:37 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> <54D36AF6.50704@home.nl> Message-ID: Am 05.02.2015 17:29 schrieb "Marcin Mrotek" : > > Well, toDigits is always finishing its work after dividing the input number once, and always returns lists of at most one element. You need it to call itself recursively until it's done, and append the calculated digit to the result: > > toDigits :: Integer -> [Integer] > toDigits n > | n <= 0 = [] > | otherwise = n `mod` 10 : toDigits (n `div` 10) This doesn't feel right: toDigits 10 = 0 : toDigits 1 = 0 : 1 : toDigits 0 = 0 : 1 : [] = [0,1] I'd expect the result to be [1,0]... > > The <= is necessary, otherwise the function would loop infinitely on 0. This version will print the digits in reverse, so you might move the code to a local function in toDigits, and make toDigit call it and then reverse the result. > > I'd strongly recommend reading a Haskell tutorial (for example http://learnyouahaskell.com ) to learn the basics. > > Kind regards, > Marcin Mrotek > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 5 19:03:31 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 20:03:31 +0100 Subject: [Haskell-beginners] =?windows-1252?q?Couldn=27t_match_expected_ty?= =?windows-1252?q?pe_=91IO_=28=29=92_with_actual_type_=5BInteger=5D?= In-Reply-To: References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> <54D36AF6.50704@home.nl> Message-ID: <54D3BE83.7040807@home.nl> An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 5 19:51:52 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 5 Feb 2015 14:51:52 -0500 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function Message-ID: Question: As I work my way through Learn You as Haskell, I have been writing small File IO programs. Unlike the example in that book, where the author reads from one file, writes altered data to a temp file and then deletes the original file and renames the temp file, I have been trying to read from a given file, alter the data and then overwrite the same file with the new data. Is this possible? In a main do block I have tried: contents <- readFile fileName -- do stuff to contents-- writeFile fileName result After using appendFile to add items to the file, when I call the function to read and write I get this error: openFile: resource busy, (file is locked) I have also tried using the file handles like so: handle <- openFile fileName ReadWriteMode contents <- hGetContents handle -- do stuff to contents -- hPutStr handle results hClose handle I have also tried opening with one handle to read, closing it, then using another handle for writing, but the error message is that the handle to the file is closed. I am thinking that the the author of LYAH maybe has good reasons to use a temp file, or is there another way that is not too difficult to grasp?? Many thanks, Geoffrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Feb 5 20:26:39 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 5 Feb 2015 21:26:39 +0100 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: Message-ID: <20150205202639.GA6653@x60s.casa> On Thu, Feb 05, 2015 at 02:51:52PM -0500, Geoffrey Bays wrote: > As I work my way through Learn You as Haskell, I have been writing small > File IO programs. > Unlike the example in that book, where the author reads from one file, > writes altered data to a temp file and then deletes the original file and > renames the temp file, I have been trying to read from a given file, alter > the data and then overwrite the same file with the new data. Is this > possible? Try `withFile` [1], there is an example of its usage in chapter 9 of LYAH [2]. [1] https://downloads.haskell.org/~ghc/6.12.2/docs/html/libraries/base-4.2.0.1/System-IO.html#v%3AwithFile [2] http://learnyouahaskell.com/input-and-output#files-and-streams From marcin.jan.mrotek at gmail.com Thu Feb 5 20:59:13 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 5 Feb 2015 21:59:13 +0100 Subject: [Haskell-beginners] =?utf-8?q?Couldn=27t_match_expected_type_?= =?utf-8?b?4oCYSU8gKCnigJkgd2l0aCBhY3R1YWwgdHlwZSBbSW50ZWdlcl0=?= In-Reply-To: <54D3BE83.7040807@home.nl> References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> <54D36AF6.50704@home.nl> <54D3BE83.7040807@home.nl> Message-ID: @Norbert Melzer - Yeah, I just wanted to provide a solution without shuffling Roelof's code too much, so he'd recognize how is it different from his version. I did write that this is incomplete and requires the list to be reversed later. @Roelof Wobben - Maybe try a different one? There are several popular choices other than LYAH: * FP Complete Shool of Haskellhttps://www.fpcomplete.com/school * Wikibooks: http://en.wikibooks.org/wiki/Haskell * Real World Haskell: http://book.realworldhaskell.org (Warning: while I remember learning from this book some time ago and it was fine, every now and then I see people saying that it's outdated and some examples don't compile) Kind regards, Marcin Mrotek From r.wobben at home.nl Thu Feb 5 21:12:31 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 22:12:31 +0100 Subject: [Haskell-beginners] =?windows-1252?q?Couldn=27t_match_expected_ty?= =?windows-1252?q?pe_=91IO_=28=29=92_with_actual_type_=5BInteger=5D?= In-Reply-To: References: <54D355E8.3010503@home.nl> <20150205130150.2e6dd21c@veeloqu.lan> <54D3612C.5080800@home.nl> <20150205133511.5fd4b93a@veeloqu.lan> <54D36AF6.50704@home.nl> <54D3BE83.7040807@home.nl> Message-ID: <54D3DCBF.1060907@home.nl> Marcin Mrotek schreef op 5-2-2015 om 21:59: > @Norbert Melzer - Yeah, I just wanted to provide a solution without > shuffling Roelof's code too much, so he'd recognize how is it > different from his version. I did write that this is incomplete and > requires the list to be reversed later. > > @Roelof Wobben - Maybe try a different one? There are several popular > choices other than LYAH: > * FP Complete Shool of Haskellhttps://www.fpcomplete.com/school > * Wikibooks: http://en.wikibooks.org/wiki/Haskell > * Real World Haskell: http://book.realworldhaskell.org (Warning: while > I remember learning from this book some time ago and it was fine, > every now and then I see people saying that it's outdated and some > examples don't compile) > > Kind regards, > Marcin Mrotek > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > Thanks, Im followinh the CiS 194 course which can be found here : http://www.seas.upenn.edu/~cis194/spring13/index.html and not the LYAH. The last book is used on this course. Roelof From chaddai.fouche at gmail.com Thu Feb 5 21:30:27 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Thu, 5 Feb 2015 22:30:27 +0100 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: Message-ID: Hello, On Thu, Feb 5, 2015 at 8:51 PM, Geoffrey Bays wrote: > Question: > > As I work my way through Learn You as Haskell, I have been writing small > File IO programs. > Unlike the example in that book, where the author reads from one file, > writes altered data to a temp file and then deletes the original file and > renames the temp file, I have been trying to read from a given file, alter > the data and then overwrite the same file with the new data. Is this > possible? > It is certainly possible, whether it is a good idea is another thing entirely. > > In a main do block I have tried: > > contents <- readFile fileName > > -- do stuff to contents-- > > writeFile fileName result > > This generally won't work because readFile is lazy, it only deliver a promise of content without reading it immediately, to allow simple streaming. To do that it has to hold on an opened handle to fileName, it will only close it when the the EOF is reached in contents, so when contents is completely evaluated, which depending on your code will probably only happen when result is completely evaluated... Except it won't be since writeFile would be the one doing this evaluation and writeFile won't even start because it needs to open fileName in WriteMode and fileName is still open in ReadMode... > After using appendFile to add items to the file, when I call the function > to read and write I get this error: > openFile: resource busy, (file is locked) > > I have also tried using the file handles like so: > > handle <- openFile fileName ReadWriteMode > contents <- hGetContents handle > -- do stuff to contents -- > > hPutStr handle results > hClose handle > Interleaving lazy IO in the form of hGetContents and trying to write on the same handle strike me as a really bad idea... Supposing it worked, where exactly in the file did you think this would write ? ReadWriteMode is generally a very bad idea (whatever the language) except if you're manipulating a binary format with fixed length fields and, even then, it requires good discipline. > > I have also tried opening with one handle to read, closing it, then using > another handle for writing, > but the error message is that the handle to the file is closed. > That should work, provided you do it properly but you probably still used lazy IO so you're left with a promise of content but you closed the handle that was supposed to provide this content... If you were to use strict IO though that would mean you would have to get the entire content of your file in memory which depending on the size of this file may be bad or even catastrophic (hint : String is *extremely* wasteful, Text is better for text and ByteString for binary formats). > > I am thinking that the the author of LYAH maybe has good reasons to use a > temp file, or is there another way that is not too difficult to grasp?? > > Right ! Reading from a file and writing to a temp file then closing everything and renaming *is the proper way* to handle your workflow, it has only advantages : - you can stream the content of your file while modifying it, using far less memory (RAM) in exchange for an insignificant bump in disk usage, - your modification is atomic (in a proper filesystem) : if your program is interrupted for whatever reason, you're not left with a corrupted file but the intact original and an incomplete temp file you can use for diagnostic This is actually true whatever language you're using (and is the recommended way by all experts) ! But in Haskell the other way is even trickier to get right if you don't understand when you should use strict IO (tip : getContents and readFile are both lazy IO and completely inappropriate if controlling *when* the IO happens is important, like here). So given that the other way is both harder to get right and generally a bad idea anyway, I really would recommend to use the proper way. -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 5 21:30:40 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 5 Feb 2015 16:30:40 -0500 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: <20150205202639.GA6653@x60s.casa> References: <20150205202639.GA6653@x60s.casa> Message-ID: Francesco: Unfortunately, using withFile I get the same error as before with handles: hPutStr: illegal operation (handle is closed). Any other suggestions for reading and writing to the same file in the same function? Thanks On Thu, Feb 5, 2015 at 3:26 PM, Francesco Ariis wrote: > On Thu, Feb 05, 2015 at 02:51:52PM -0500, Geoffrey Bays wrote: > > As I work my way through Learn You as Haskell, I have been writing small > > File IO programs. > > Unlike the example in that book, where the author reads from one file, > > writes altered data to a temp file and then deletes the original file and > > renames the temp file, I have been trying to read from a given file, > alter > > the data and then overwrite the same file with the new data. Is this > > possible? > > Try `withFile` [1], there is an example of its usage in chapter 9 of > LYAH [2]. > > [1] > https://downloads.haskell.org/~ghc/6.12.2/docs/html/libraries/base-4.2.0.1/System-IO.html#v%3AwithFile > [2] http://learnyouahaskell.com/input-and-output#files-and-streams > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Thu Feb 5 21:33:11 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Thu, 5 Feb 2015 22:33:11 +0100 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: <20150205202639.GA6653@x60s.casa> Message-ID: On Thu, Feb 5, 2015 at 10:30 PM, Geoffrey Bays wrote: > Francesco: > > Unfortunately, using withFile I get the same error as before with handles: > hPutStr: illegal operation (handle is closed). > > This error suggests you're forgetting to reopen your file in WriteMode once withFile closed it (you *did *read the documentation of withFile ?). Trying to write on a closed handle is an exercise in futility. -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Thu Feb 5 21:42:38 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Thu, 5 Feb 2015 22:42:38 +0100 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: <20150205202639.GA6653@x60s.casa> Message-ID: If you're still wedded to your notion (I strongly urge you to use the proper way with temp file and renaming, even making it a function if you need to repeat this several times) : readModifyWrite fileName modify = do contents <- readFile fileName evaluate (length contents) -- ensure that contents is evaluated and the handle closed writeFile fileName (modify contents) This should work (but may consume a fair bit of memory, you should probably use Text or ByteString anyway and use the proper way instead). -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 5 21:43:29 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 5 Feb 2015 16:43:29 -0500 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: <20150205202639.GA6653@x60s.casa> Message-ID: Chaddai: Thanks for your excellent explanation of why using a temp file is necessary and a good thing to do. The problem also with using withFile and a lambda is that in my infinite Haskell beginnerness, I do not know how to get the contents out of the lambda for use later for the second try of withFile in WriteMode. As in LYAH 1. withFile "girlfriend.txt" ReadMode (\handle -> do 2. contents <- hGetContents handle 3. putStr contents) how to retrieve contents for later use? Scope of contents variable in inside lambda only it would appear. Can I declare an empty contents IO String before the withFile lambda somehow? Thanks On Thu, Feb 5, 2015 at 4:33 PM, Chadda? Fouch? wrote: > On Thu, Feb 5, 2015 at 10:30 PM, Geoffrey Bays > wrote: > >> Francesco: >> >> Unfortunately, using withFile I get the same error as before with >> handles: hPutStr: illegal operation (handle is closed). >> >> > This error suggests you're forgetting to reopen your file in WriteMode > once withFile closed it (you *did *read the documentation of withFile ?). > Trying to write on a closed handle is an exercise in futility. > > -- > Jeda? > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Thu Feb 5 21:55:08 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Thu, 5 Feb 2015 22:55:08 +0100 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: <20150205202639.GA6653@x60s.casa> Message-ID: On Thu, Feb 5, 2015 at 10:43 PM, Geoffrey Bays wrote: > > The problem also with using withFile and a lambda is that in my infinite > Haskell beginnerness, I do not know how to get the > contents out of the lambda for use later for the second try of withFile in > WriteMode. > > As in LYAH > > 1. withFile "girlfriend.txt" ReadMode (\handle -> do > 2. contents <- hGetContents handle > 3. putStr contents) > > how to retrieve contents for later use? Scope of contents variable in > inside lambda only it would appear. > Well withFile type is "FilePath -> Mode -> (Handle -> IO a) -> IO a", note that "IO a", this "a" is a type variable that can be any type, this means that the action you do in your lambda may return any type, and the type returned by the whole withFile action is also "a", since this can be anything, withFile can't invent it, so this must be the same thing that the action in your lambda returned. Thus you can return the content you wished for : contents <- withFile fileName ReadMode $ \h -> do contentsInside <- hGetContents handle evaluate (length contentsInside) -- still the same, you have to evaluate the whole contents now since withFile will close the handle as soon as you exit your lambda, use a strict variant of hGetContents to avoid this line return contentsInside Note this is convoluted, using a strict variant of hGetContents would allows you to just go : contents <- withFile fileName ReadMode $ \h -> hGetContents h Text for instance provide such a strict variant in Data.Text.IO (but you should then just use its strict variant of readFile which is exactly equivalent to what I just wrote). -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 5 22:03:57 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 5 Feb 2015 17:03:57 -0500 Subject: [Haskell-beginners] File I/O: reading from, writing to, same file in one function In-Reply-To: References: <20150205202639.GA6653@x60s.casa> Message-ID: Thanks, Chaddai. It seems quite obvious once you explain it. And I now know that ghci :t is my friend indeed. Geoffrey On Thu, Feb 5, 2015 at 4:55 PM, Chadda? Fouch? wrote: > On Thu, Feb 5, 2015 at 10:43 PM, Geoffrey Bays > wrote: >> >> The problem also with using withFile and a lambda is that in my infinite >> Haskell beginnerness, I do not know how to get the >> contents out of the lambda for use later for the second try of withFile >> in WriteMode. >> >> As in LYAH >> >> 1. withFile "girlfriend.txt" ReadMode (\handle -> do >> 2. contents <- hGetContents handle >> 3. putStr contents) >> >> how to retrieve contents for later use? Scope of contents variable in >> inside lambda only it would appear. >> > > Well withFile type is "FilePath -> Mode -> (Handle -> IO a) -> IO a", note > that "IO a", this "a" is a type variable that can be any type, this means > that the action you do in your lambda may return any type, and the type > returned by the whole withFile action is also "a", since this can be > anything, withFile can't invent it, so this must be the same thing that the > action in your lambda returned. Thus you can return the content you wished > for : > > contents <- withFile fileName ReadMode $ \h -> do > contentsInside <- hGetContents handle > evaluate (length contentsInside) -- still the same, you have to > evaluate the whole contents now since withFile will close the handle as > soon as you exit your lambda, use a strict variant of hGetContents to avoid > this line > return contentsInside > > Note this is convoluted, using a strict variant of hGetContents would > allows you to just go : contents <- withFile fileName ReadMode $ \h -> > hGetContents h > Text for instance provide such a strict variant in Data.Text.IO (but you > should then just use its strict variant of readFile which is exactly > equivalent to what I just wrote). > > -- > Jeda? > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Feb 5 23:14:55 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 05 Feb 2015 18:14:55 -0500 Subject: [Haskell-beginners] File I/O: reading from, writing to, Message-ID: <201502052314.t15NEtRJ031076@coolidge.cs.dartmouth.edu> same file in one function > I strongly urge you to use the proper way with temp file and renaming, even making it a function if you need to repeat this several times The "proper way" is fraught with pitfalls: potentially changes in file ownership and permissions, loss of linkage when the file is known by multiple names, and even total failure if you don't have The proper way does have one safety advantage. The original file is highly likely to survive should the writing of the new contents stop prematurely for some external reason. Doug From doug at cs.dartmouth.edu Thu Feb 5 23:28:46 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 05 Feb 2015 18:28:46 -0500 Subject: [Haskell-beginners] Subject: Re: File I/O: reading from, writing to, Message-ID: <201502052328.t15NSkBr031141@coolidge.cs.dartmouth.edu> same file in one function One more safety feature in the "proper way": in most systems it will guarantee that a concurrent reader sees a coherent file image. ------------------------------------------------------------ > I strongly urge you to use the proper way with temp file and renaming, even making it a function if you need to repeat this several times The "proper way" is fraught with pitfalls: potentially changes in file ownership and permissions, loss of linkage when the file is known by multiple names, and even total failure if you don't have write permission on the directory.^C The proper way does have one safety advantage. The original file is highly likely to survive should the writing of the new contents stop prematurely for some external reason. Doug From dontdieych at gmail.com Fri Feb 6 06:06:34 2015 From: dontdieych at gmail.com (YCH) Date: Fri, 06 Feb 2015 15:06:34 +0900 Subject: [Haskell-beginners] =?iso8859-7?q?Couldn=27t_match_expected_type_?= =?iso8859-7?q?=A1IO_=28=29=A2_with_actual_type_=5BInteger=5D?= In-Reply-To: <54D3BE83.7040807@home.nl> References: <54D3BE83.7040807@home.nl> Message-ID: <1423202794.1010.0@smtp.gmail.com> Hello, Roelof. Your function is done. But it should be named 'toDigitsReversed' or so. So if you could write another 'reverse' function then you can compose like this. toDigits = reverse . toDigitsReversed -- YCH From r.wobben at home.nl Fri Feb 6 09:25:59 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 10:25:59 +0100 Subject: [Haskell-beginners] recursion problem. Message-ID: <54D488A7.2090104@home.nl> Hello, I have figured out how I can make from 123 [1,2,3] I did it this way : -- | convert a number to a array in pieces where a negative number will be a empty array. toDigits :: Integer -> [Integer] toDigits n | n <= 0 = [] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] but now when I do toDigits 0 , I see [] as output where I was expected [0] But when I do toDigits 100 I see the right output [ 1,0,0] which surprises me because I tought that with the first 0 there will be a [] Or is the n the second time [0,0] and the thirth time [0] So it will be like this : toDigits 100 to Digits [1] ++ [ 0,0] toDigits [1] ++ [0] ++ [0] which leads to [1,0,0] Roelof From dontdieych at gmail.com Fri Feb 6 10:06:56 2015 From: dontdieych at gmail.com (YCH) Date: Fri, 06 Feb 2015 19:06:56 +0900 Subject: [Haskell-beginners] recursion problem. In-Reply-To: <54D488A7.2090104@home.nl> References: <54D488A7.2090104@home.nl> Message-ID: <1423217216.3284.0@smtp.gmail.com> On Fri, Feb 6, 2015 at 6:25 PM, Roelof Wobben wrote: > Hello, > > I have figured out how I can make from 123 [1,2,3] > > I did it this way : > > -- | convert a number to a array in pieces where a negative number > will be a empty array. > toDigits :: Integer -> [Integer] > toDigits n > | n <= 0 = [] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > > but now when I do toDigits 0 , I see [] as output where I was > expected [0] > > But when I do toDigits 100 I see the right output [ 1,0,0] which > surprises me because I tought that with the first 0 there will be a [] > > Or is the n the second time [0,0] and the thirth time [0] So it will > be like this : > > toDigits 100 > > to Digits [1] ++ [ 0,0] > toDigits [1] ++ [0] ++ [0] > > which leads to [1,0,0] toDigits 100 toDigits 10 ++ [0] toDigits 1 ++ [0] ++ [0] [1] ++ [0] ++ [0] [1,0,0] toDigits 0 [] -- because first guard clause 0 is valid input. It should be dealt different from negative number. -- YCH From marcin.jan.mrotek at gmail.com Fri Feb 6 10:27:56 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Fri, 6 Feb 2015 11:27:56 +0100 Subject: [Haskell-beginners] recursion problem. In-Reply-To: <1423217216.3284.0@smtp.gmail.com> References: <54D488A7.2090104@home.nl> <1423217216.3284.0@smtp.gmail.com> Message-ID: Ah, sorry, I didn't think of that when I responded to your other thread. You can always insert a check before recursion: toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | otherwise = (if n' > 0 then toDigits n' else []) ++ [n `mod` 10] where n' = n `div` 10 Regards, Marcin Mrotek From r.wobben at home.nl Fri Feb 6 13:44:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 14:44:19 +0100 Subject: [Haskell-beginners] recursion problem. In-Reply-To: References: <54D488A7.2090104@home.nl> <1423217216.3284.0@smtp.gmail.com> Message-ID: <54D4C533.7080102@home.nl> Marcin Mrotek schreef op 6-2-2015 om 11:27: > Ah, sorry, I didn't think of that when I responded to your other > thread. You can always insert a check before recursion: > > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | otherwise = (if n' > 0 then toDigits n' else []) ++ [n `mod` 10] > where n' = n `div` 10 > > Regards, > Marcin Mrotek > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > Hello, Can you explain to me why we need a n' and a where here. I tried the same solution here : toDigitsRev :: Integer -> [Integer] toDigitsRev n | n <= 0 = [] | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) but I could not make it work. Roelof From r.wobben at home.nl Fri Feb 6 14:05:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 15:05:11 +0100 Subject: [Haskell-beginners] recursion problem. In-Reply-To: <54D488A7.2090104@home.nl> References: <54D488A7.2090104@home.nl> Message-ID: <54D4CA17.3030408@home.nl> Roelof Wobben schreef op 6-2-2015 om 10:25: > Hello, > > I have figured out how I can make from 123 [1,2,3] > > I did it this way : > > -- | convert a number to a array in pieces where a negative number > will be a empty array. > toDigits :: Integer -> [Integer] > toDigits n > | n <= 0 = [] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > > but now when I do toDigits 0 , I see [] as output where I was expected > [0] > > But when I do toDigits 100 I see the right output [ 1,0,0] which > surprises me because I tought that with the first 0 there will be a [] > > Or is the n the second time [0,0] and the thirth time [0] So it will > be like this : > > toDigits 100 > > to Digits [1] ++ [ 0,0] > toDigits [1] ++ [0] ++ [0] > > which leads to [1,0,0] > > Roelof > Hmm, this is also not working : -- | convert a number to a array in pieces where a negative number will be a empty array. toDigits :: Integer -> [Integer] toDigits 0 = [0] toDigits n | n < 0 = [] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] -- | convert a number to a reversed array where a negative number will be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = [0] toDigitsRev n | n <= 0 = [] | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) -- | The main entry point. main :: IO () main = do print $ toDigits 100 print $ toDigitsRev 100 print $ toDigits 0 print $ toDigitsRev 0 print $ toDigits (-17) print $ toDigitsRev (-17) you get a zero too much when you use a number above 0 . From r.wobben at home.nl Fri Feb 6 16:47:24 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 17:47:24 +0100 Subject: [Haskell-beginners] length problem Message-ID: <54D4F01C.40505@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 16:55:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 17:55:55 +0100 Subject: [Haskell-beginners] length problem In-Reply-To: <20150206165048.GA13064@x60s.casa> References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> Message-ID: <54D4F21B.1050300@home.nl> Oke, I have solved it already. The problem was that I did list.length but Haskell uses length list Still too much Ruby in my system :( Roelof Francesco Ariis schreef op 6-2-2015 om 17:50: > (off-list) please consider not using html in your mails, it's quite difficult > to read them for us who plaintext-friendly client > > On Fri, Feb 06, 2015 at 05:47:24PM +0100, Roelof Wobben wrote: >> >> >> >> >> >> >> Hello,
>>
>> I have to double every second element from the right.
>>
>> So for a even length array that means : 1 , 3 , 5 and so on
>> and for a non even lenght that means the 2,4 and so on.
>>
>> So I thought I could solve that on this way :
>>
>> -- | Doubles every second number from the right.
>> doubleEveryOther :: [Integer] -> [Integer]
>> doubleEveryOther [] = []
>> doubleEveryOther (x:[]) = [x]
>> doubleEveryOther (x:(y:zs))
>> | ((x:(y:zs)).length) `mod` 2 /= 0 = [x] ++ (y * 2) : >> doubleEveryOther zs
>> | otherwise = [x *2] ++ y : doubleEveryOther zs
>>
>>
>>
>> but this does not work because I see this error message :
>>
>>
src/Main.hs at 14:8-14:16
>>
Couldn't match expected type ?Int >> -> c0? with actual type >>
[> class="cm-variable-2">Integer]
>> > class="ide-error-collapse-btn"> ? >> In the first argument of ?(.)?, namely ?(x : (y : zs))? >> In the first argument of ?mod?, namely ?((x : (y : zs)) . >> length)? >> In the first argument of ?(/=)?, namely ?((x : (y : zs)) . >> length) `mod` 2?
>>
>>
>> Can anyone give me a better way to check if I have a even or odd >> length array ?
>>
>> Roelof
>>
>>
>>
>> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners > From ahammel87 at gmail.com Fri Feb 6 19:41:48 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Fri, 6 Feb 2015 11:41:48 -0800 Subject: [Haskell-beginners] length problem In-Reply-To: <54D4F21B.1050300@home.nl> References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> Message-ID: This is mostly for my own recreation, feel free to ignore it. Your solution is fine, but it lacks modularity. What if you discover that you don't actually want to double every other number but triple it? Or if the list of numbers is suddenly a list of words and you need to capitalize every other one? You don't want to have to write a new function from scratch. Let's make a function that applies any function to every other value: everyOther :: (a -> a) -> [a] -> [a] everyOther _ [] = [] everyOther _ [x] = [x] everyOther f (x:y:xs) = x : f y : everyOther f xs doubleEveryOther :: [Int] -> [Int] doubleEveryOther = everyOther (*2) But hang on, what if the requirements change again and now we have to double every third value? Writing something like this is no fun: everyThird :: (a -> a) -> [a] -> [a] everyThird _ [] = [] everyThird _ [x] = [x] everyThird _ [x,y] = [x,y] everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs And the implementation of everyHundredAndFifth will obviously be ridiculous. Clearly what we need is an `everyNth` function which allows the programmer to specify which list elements the function is applied to. One trick is to create a list of functions and use zipWith ($). ($) is just function application; so a list with `id` at every position except the nth will work: ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] [1,3,3,5] We can use `cycle` to make an infinite list of functions and `replicate` to generate the padding of the function list: everyNth :: Int -> (a -> a) -> [a] -> [a] everyNth n f = zipWith ($) fs where fs = cycle $ replicate (n-1) id ++ [f] -- e.g. cycle [id, f] when n is 2 everyOther' :: (a -> a) -> [a] -> [a] everyOther' = everyNth 2 everyThird' :: (a -> a) -> [a] -> [a] everyThird' = everyNth 3 As for testing whether the length is odd or even: why not just reverse it, double every other number, and reverse it again? doubleEveryOther :: Num a => [a] -> [a] doubleEveryOther = reverse . everyOther (*2) . reverse Cheers, Alex On Fri, Feb 6, 2015 at 8:55 AM, Roelof Wobben wrote: > Oke, > > I have solved it already. > The problem was that I did list.length but Haskell uses length list > > Still too much Ruby in my system :( > > Roelof > > > > Francesco Ariis schreef op 6-2-2015 om 17:50: > >> (off-list) please consider not using html in your mails, it's quite >> difficult >> to read them for us who plaintext-friendly client >> >> On Fri, Feb 06, 2015 at 05:47:24PM +0100, Roelof Wobben wrote: >> >>> >>> >>> >>> >>> >>> >>> Hello,
>>>
>>> I have to double every second element from the right.
>>>
>>> So for a even length array that means : 1 , 3 , 5 and so on
>>> and for a non even lenght that means the 2,4 and so on.
>>>
>>> So I thought I could solve that on this way :
>>>
>>> -- | Doubles every second number from the right.
>>> doubleEveryOther :: [Integer] -> [Integer]
>>> doubleEveryOther [] = []
>>> doubleEveryOther (x:[]) = [x]
>>> doubleEveryOther (x:(y:zs))
>>> | ((x:(y:zs)).length) `mod` 2 /= 0 = [x] ++ (y * 2) : >>> doubleEveryOther zs
>>> | otherwise = [x *2] ++ y : doubleEveryOther zs
>>>
>>>
>>>
>>> but this does not work because I see this error message :
>>>
>>>
src/Main.hs at 14:8-14:16
>>>
Couldn't match expected type ?Int >>> -> c0? with actual type >>>
[>> class="cm-variable-2">Integer]
>>> >> class="ide-error-collapse-btn"> ? >>> In the first argument of ?(.)?, namely ?(x : (y : zs))? >>> In the first argument of ?mod?, namely ?((x : (y : zs)) . >>> length)? >>> In the first argument of ?(/=)?, namely ?((x : (y : zs)) . >>> length) `mod` 2?
>>>
>>>
>>> Can anyone give me a better way to check if I have a even or odd >>> length array ?
>>>
>>> Roelof
>>>
>>>
>>>
>>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://www.haskell.org/mailman/listinfo/beginners >>> >> >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontdieych at gmail.com Fri Feb 6 19:54:00 2015 From: dontdieych at gmail.com (YCH) Date: Sat, 7 Feb 2015 04:54:00 +0900 Subject: [Haskell-beginners] length problem In-Reply-To: References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> Message-ID: Thanks for explanation. 2015. 2. 7. ?? 4:42? "Alex Hammel" ?? ??: > This is mostly for my own recreation, feel free to ignore it. > > Your solution is fine, but it lacks modularity. What if you discover that > you don't actually want to double every other number but triple it? Or if > the list of numbers is suddenly a list of words and you need to capitalize > every other one? You don't want to have to write a new function from > scratch. Let's make a function that applies any function to every other > value: > > everyOther :: (a -> a) -> [a] -> [a] > everyOther _ [] = [] > everyOther _ [x] = [x] > everyOther f (x:y:xs) = x : f y : everyOther f xs > > doubleEveryOther :: [Int] -> [Int] > doubleEveryOther = everyOther (*2) > > But hang on, what if the requirements change again and now we have to > double every third value? Writing something like this is no fun: > > everyThird :: (a -> a) -> [a] -> [a] > everyThird _ [] = [] > everyThird _ [x] = [x] > everyThird _ [x,y] = [x,y] > everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs > > And the implementation of everyHundredAndFifth will obviously be > ridiculous. Clearly what we need is an `everyNth` function which allows the > programmer to specify which list elements the function is applied to. > > One trick is to create a list of functions and use zipWith ($). ($) is > just function application; so a list with `id` at every position except the > nth will work: > > ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] > [1,3,3,5] > > We can use `cycle` to make an infinite list of functions and `replicate` > to generate the padding of the function list: > > everyNth :: Int -> (a -> a) -> [a] -> [a] > everyNth n f = zipWith ($) fs > where > fs = cycle $ replicate (n-1) id ++ [f] -- e.g. cycle [id, f] when n > is 2 > > everyOther' :: (a -> a) -> [a] -> [a] > everyOther' = everyNth 2 > > everyThird' :: (a -> a) -> [a] -> [a] > everyThird' = everyNth 3 > > As for testing whether the length is odd or even: why not just reverse it, > double every other number, and reverse it again? > > doubleEveryOther :: Num a => [a] -> [a] > doubleEveryOther = reverse . everyOther (*2) . reverse > > Cheers, > Alex > > > On Fri, Feb 6, 2015 at 8:55 AM, Roelof Wobben wrote: > >> Oke, >> >> I have solved it already. >> The problem was that I did list.length but Haskell uses length list >> >> Still too much Ruby in my system :( >> >> Roelof >> >> >> >> Francesco Ariis schreef op 6-2-2015 om 17:50: >> >>> (off-list) please consider not using html in your mails, it's quite >>> difficult >>> to read them for us who plaintext-friendly client >>> >>> On Fri, Feb 06, 2015 at 05:47:24PM +0100, Roelof Wobben wrote: >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hello,
>>>>
>>>> I have to double every second element from the right.
>>>>
>>>> So for a even length array that means : 1 , 3 , 5 and so on
>>>> and for a non even lenght that means the 2,4 and so on.
>>>>
>>>> So I thought I could solve that on this way :
>>>>
>>>> -- | Doubles every second number from the right.
>>>> doubleEveryOther :: [Integer] -> [Integer]
>>>> doubleEveryOther [] = []
>>>> doubleEveryOther (x:[]) = [x]
>>>> doubleEveryOther (x:(y:zs))
>>>> | ((x:(y:zs)).length) `mod` 2 /= 0 = [x] ++ (y * 2) : >>>> doubleEveryOther zs
>>>> | otherwise = [x *2] ++ y : doubleEveryOther zs
>>>>
>>>>
>>>>
>>>> but this does not work because I see this error message :
>>>>
>>>>
src/Main.hs at 14:8-14:16
>>>>
Couldn't match expected type ?Int >>>> -> c0? with actual type >>>>
[>>> class="cm-variable-2">Integer]
>>>> >>> class="ide-error-collapse-btn"> ? >>>> In the first argument of ?(.)?, namely ?(x : (y : zs))? >>>> In the first argument of ?mod?, namely ?((x : (y : zs)) . >>>> length)? >>>> In the first argument of ?(/=)?, namely ?((x : (y : zs)) . >>>> length) `mod` 2?
>>>>
>>>>
>>>> Can anyone give me a better way to check if I have a even or >>>> odd >>>> length array ?
>>>>
>>>> Roelof
>>>>
>>>>
>>>>
>>>> >>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners at haskell.org >>>> http://www.haskell.org/mailman/listinfo/beginners >>>> >>> >>> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 20:24:30 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 21:24:30 +0100 Subject: [Haskell-beginners] length problem In-Reply-To: References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> Message-ID: <54D522FE.1030405@home.nl> An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Fri Feb 6 20:35:01 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Fri, 6 Feb 2015 12:35:01 -0800 Subject: [Haskell-beginners] length problem In-Reply-To: <54D522FE.1030405@home.nl> References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> <54D522FE.1030405@home.nl> Message-ID: You can think of zipWith as a function that combines the values of two lists. If you want to add the numbers in two lists you can do this: zipWith (+) [1, 2, 3] [4, 5, 6] which is the same thing as: [1+4, 2+5, 3+6] which results in [5, 7, 9] When you call zipWith ($) you're just applying the functions in one list to the values in another. E.g.: zipWith ($) [(+1), (+2), (+3)] [1, 2, 3] is the same thing as [($) (+1) 1, ($) (+2) 2, ($) (+3) 3] which is the same thing as [1+1, 2+2, 3+3] once you've rewritten it in sane syntax. So the example I gave: zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] is the same thing as [id 1, 2+1, id 3, 4+1] On Fri, Feb 6, 2015 at 12:24 PM, Roelof Wobben wrote: > YCH schreef op 6-2-2015 om 20:54: > > Thanks for explanation. > 2015. 2. 7. ?? 4:42? "Alex Hammel" ?? ??: > >> This is mostly for my own recreation, feel free to ignore it. >> >> Your solution is fine, but it lacks modularity. What if you discover that >> you don't actually want to double every other number but triple it? Or if >> the list of numbers is suddenly a list of words and you need to capitalize >> every other one? You don't want to have to write a new function from >> scratch. Let's make a function that applies any function to every other >> value: >> >> everyOther :: (a -> a) -> [a] -> [a] >> everyOther _ [] = [] >> everyOther _ [x] = [x] >> everyOther f (x:y:xs) = x : f y : everyOther f xs >> >> doubleEveryOther :: [Int] -> [Int] >> doubleEveryOther = everyOther (*2) >> >> But hang on, what if the requirements change again and now we have to >> double every third value? Writing something like this is no fun: >> >> everyThird :: (a -> a) -> [a] -> [a] >> everyThird _ [] = [] >> everyThird _ [x] = [x] >> everyThird _ [x,y] = [x,y] >> everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs >> >> And the implementation of everyHundredAndFifth will obviously be >> ridiculous. Clearly what we need is an `everyNth` function which allows the >> programmer to specify which list elements the function is applied to. >> >> One trick is to create a list of functions and use zipWith ($). ($) is >> just function application; so a list with `id` at every position except the >> nth will work: >> >> ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] >> [1,3,3,5] >> >> > Here I miss you,. I have only done the first chapter of the NIC course > and it not talked about using zipWith. > > I only learned recursion and how that worked on list. > > So can you explain how only the second item is added by 1 . > > As soon as I understand that part I will study the rest and I think I have > more questions. > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 20:41:49 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 21:41:49 +0100 Subject: [Haskell-beginners] length problem In-Reply-To: References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> <54D522FE.1030405@home.nl> Message-ID: <54D5270D.3030008@home.nl> An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Fri Feb 6 20:47:49 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Fri, 6 Feb 2015 12:47:49 -0800 Subject: [Haskell-beginners] length problem In-Reply-To: <54D5270D.3030008@home.nl> References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> <54D522FE.1030405@home.nl> <54D5270D.3030008@home.nl> Message-ID: Yep, that's correct On Fri, Feb 6, 2015 at 12:41 PM, Roelof Wobben wrote: > Alex Hammel schreef op 6-2-2015 om 21:35: > > You can think of zipWith as a function that combines the values of two > lists. If you want to add the numbers in two lists you can do this: > > zipWith (+) [1, 2, 3] [4, 5, 6] > > which is the same thing as: > > [1+4, 2+5, 3+6] > > which results in [5, 7, 9] > > When you call zipWith ($) you're just applying the functions in one list > to the values in another. E.g.: > > zipWith ($) [(+1), (+2), (+3)] [1, 2, 3] > > is the same thing as > > [($) (+1) 1, ($) (+2) 2, ($) (+3) 3] > > which is the same thing as > > [1+1, 2+2, 3+3] > > once you've rewritten it in sane syntax. > > So the example I gave: > > zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] > > is the same thing as > > [id 1, 2+1, id 3, 4+1] > > On Fri, Feb 6, 2015 at 12:24 PM, Roelof Wobben wrote: > >> YCH schreef op 6-2-2015 om 20:54: >> >> Thanks for explanation. >> 2015. 2. 7. ?? 4:42? "Alex Hammel" ?? ??: >> >>> This is mostly for my own recreation, feel free to ignore it. >>> >>> Your solution is fine, but it lacks modularity. What if you discover >>> that you don't actually want to double every other number but triple it? Or >>> if the list of numbers is suddenly a list of words and you need to >>> capitalize every other one? You don't want to have to write a new function >>> from scratch. Let's make a function that applies any function to every >>> other value: >>> >>> everyOther :: (a -> a) -> [a] -> [a] >>> everyOther _ [] = [] >>> everyOther _ [x] = [x] >>> everyOther f (x:y:xs) = x : f y : everyOther f xs >>> >>> doubleEveryOther :: [Int] -> [Int] >>> doubleEveryOther = everyOther (*2) >>> >>> But hang on, what if the requirements change again and now we have to >>> double every third value? Writing something like this is no fun: >>> >>> everyThird :: (a -> a) -> [a] -> [a] >>> everyThird _ [] = [] >>> everyThird _ [x] = [x] >>> everyThird _ [x,y] = [x,y] >>> everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs >>> >>> And the implementation of everyHundredAndFifth will obviously be >>> ridiculous. Clearly what we need is an `everyNth` function which allows the >>> programmer to specify which list elements the function is applied to. >>> >>> One trick is to create a list of functions and use zipWith ($). ($) is >>> just function application; so a list with `id` at every position except the >>> nth will work: >>> >>> ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] >>> [1,3,3,5] >>> >>> >> Here I miss you,. I have only done the first chapter of the NIC course >> and it not talked about using zipWith. >> >> I only learned recursion and how that worked on list. >> >> So can you explain how only the second item is added by 1 . >> >> As soon as I understand that part I will study the rest and I think I >> have more questions. >> >> Roelof >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://www.haskell.org/mailman/listinfo/beginners > > > Oke, I think I get it. > > So if I want to add +1 to the thirt item I can do this : ? zipWith ($) > [id, id, (+1), id] [1, 2, 3, 4] which gives [1.2.4.4] > > Am i correct ? > > Roelof > > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 20:52:21 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 21:52:21 +0100 Subject: [Haskell-beginners] length problem In-Reply-To: References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> Message-ID: <54D52985.409@home.nl> Alex Hammel schreef op 6-2-2015 om 20:41: > This is mostly for my own recreation, feel free to ignore it. > > Your solution is fine, but it lacks modularity. What if you discover > that you don't actually want to double every other number but triple > it? Or if the list of numbers is suddenly a list of words and you need > to capitalize every other one? You don't want to have to write a new > function from scratch. Let's make a function that applies any function > to every other value: > > everyOther :: (a -> a) -> [a] -> [a] > everyOther _ [] = [] > everyOther _ [x] = [x] > everyOther f (x:y:xs) = x : f y : everyOther f xs > > doubleEveryOther :: [Int] -> [Int] > doubleEveryOther = everyOther (*2) > > But hang on, what if the requirements change again and now we have to > double every third value? Writing something like this is no fun: > > everyThird :: (a -> a) -> [a] -> [a] > everyThird _ [] = [] > everyThird _ [x] = [x] > everyThird _ [x,y] = [x,y] > everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs > > And the implementation of everyHundredAndFifth will obviously be > ridiculous. Clearly what we need is an `everyNth` function which > allows the programmer to specify which list elements the function is > applied to. > > One trick is to create a list of functions and use zipWith ($). ($) is > just function application; so a list with `id` at every position > except the nth will work: > > ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] > [1,3,3,5] > > We can use `cycle` to make an infinite list of functions and > `replicate` to generate the padding of the function list: > > everyNth :: Int -> (a -> a) -> [a] -> [a] > everyNth n f = zipWith ($) fs > where > fs = cycle $ replicate (n-1) id ++ [f] -- e.g. cycle [id, f] > when n is 2 > oke, Can you also explain what this function does exactly. I see a variable n and f and I see cycle en replicate and a n-1 What is I want to multiply the second item by 2. That was the challenge I had now. Roelof From ahammel87 at gmail.com Fri Feb 6 21:07:02 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Fri, 6 Feb 2015 13:07:02 -0800 Subject: [Haskell-beginners] length problem In-Reply-To: <54D52985.409@home.nl> References: <54D4F01C.40505@home.nl> <20150206165048.GA13064@x60s.casa> <54D4F21B.1050300@home.nl> <54D52985.409@home.nl> Message-ID: `everyNth` applies a function f to every nth item in a list. If you want to double every other item in a list you can do everyNth 2 (*2) aList In order to accomplish this, it makes an infinite list of functions where every nth function is `f` (the user-supplied function) and the rest are `id`. (This function terminates when applied to finite lists becase zipWith stops when the shorter of it's arguments runs out). So: everyNth 2 (*2) [1, 2, 3, 4] is the same as zipWith ($) [id, (*2), id, (*2)] [1, 2, 3, 4] On Fri, Feb 6, 2015 at 12:52 PM, Roelof Wobben wrote: > Alex Hammel schreef op 6-2-2015 om 20:41: > >> This is mostly for my own recreation, feel free to ignore it. >> >> Your solution is fine, but it lacks modularity. What if you discover that >> you don't actually want to double every other number but triple it? Or if >> the list of numbers is suddenly a list of words and you need to capitalize >> every other one? You don't want to have to write a new function from >> scratch. Let's make a function that applies any function to every other >> value: >> >> everyOther :: (a -> a) -> [a] -> [a] >> everyOther _ [] = [] >> everyOther _ [x] = [x] >> everyOther f (x:y:xs) = x : f y : everyOther f xs >> >> doubleEveryOther :: [Int] -> [Int] >> doubleEveryOther = everyOther (*2) >> >> But hang on, what if the requirements change again and now we have to >> double every third value? Writing something like this is no fun: >> >> everyThird :: (a -> a) -> [a] -> [a] >> everyThird _ [] = [] >> everyThird _ [x] = [x] >> everyThird _ [x,y] = [x,y] >> everyThird f (x:y:z:xs) = x : y : f z : everyThird f xs >> >> And the implementation of everyHundredAndFifth will obviously be >> ridiculous. Clearly what we need is an `everyNth` function which allows the >> programmer to specify which list elements the function is applied to. >> >> One trick is to create a list of functions and use zipWith ($). ($) is >> just function application; so a list with `id` at every position except the >> nth will work: >> >> ? zipWith ($) [id, (+1), id, (+1)] [1, 2, 3, 4] >> [1,3,3,5] >> >> We can use `cycle` to make an infinite list of functions and `replicate` >> to generate the padding of the function list: >> >> everyNth :: Int -> (a -> a) -> [a] -> [a] >> everyNth n f = zipWith ($) fs >> where >> fs = cycle $ replicate (n-1) id ++ [f] -- e.g. cycle [id, f] when n >> is 2 >> >> > oke, Can you also explain what this function does exactly. > > I see a variable n and f and I see cycle en replicate and a n-1 > > What is I want to multiply the second item by 2. > That was the challenge I had now. > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at karlv.net Sat Feb 7 04:59:36 2015 From: karl at karlv.net (Karl Voelker) Date: Fri, 06 Feb 2015 20:59:36 -0800 Subject: [Haskell-beginners] recursion problem. In-Reply-To: <54D488A7.2090104@home.nl> References: <54D488A7.2090104@home.nl> Message-ID: <1423285176.1254095.224241757.68C01536@webmail.messagingengine.com> On Fri, Feb 6, 2015, at 01:25 AM, Roelof Wobben wrote: > but now when I do toDigits 0 , I see [] as output where I was expected > [0] In our written notation, "0" is a special case: it's the only integer written with a leading zero. So don't be too surprised if your code requires a special case for it. -Karl From r.wobben at home.nl Sat Feb 7 08:53:34 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 09:53:34 +0100 Subject: [Haskell-beginners] sum problem Message-ID: <54D5D28E.3090807@home.nl> Hello, The exercises of CIS 194 are really hard. Now I have to sum all the numbers in a array with a catch If a number is greater then 10 it has to be dived in single numbers. so [ 1 , 12, 3] will be [ 1, 1,2,3] and then sum up. So far I have this : -- | sum all the digits of a array sumDigits :: [Integer] -> Integer sumDigits n | n == 0 = acc | n < 10 = acc + n | otherwise = sumDigits acc + n `mod` 10 + n `rem` 10 But now I see a message that acc is not known which is not wierd. But when I do sumDigits n acc I see a message that sumDigits has only 1 parameter where I give it to, When I only had to sum up i is easy , I could use map [+] xs Anyone who can give a me tip without giving the answer otherwise I do not learn anything. Roelof From zhiwudazhanjiangshi at gmail.com Sat Feb 7 09:01:48 2015 From: zhiwudazhanjiangshi at gmail.com (yi lu) Date: Sat, 7 Feb 2015 17:01:48 +0800 Subject: [Haskell-beginners] sum problem In-Reply-To: <54D5D28E.3090807@home.nl> References: <54D5D28E.3090807@home.nl> Message-ID: Do not try to `sum` all at first. See how you can deal with one integer. On Sat, Feb 7, 2015 at 4:53 PM, Roelof Wobben wrote: > Hello, > > The exercises of CIS 194 are really hard. > > Now I have to sum all the numbers in a array with a catch > If a number is greater then 10 it has to be dived in single numbers. > > so [ 1 , 12, 3] will be [ 1, 1,2,3] and then sum up. > > So far I have this : > > -- | sum all the digits of a array > sumDigits :: [Integer] -> Integer > sumDigits n > | n == 0 = acc > | n < 10 = acc + n > | otherwise = sumDigits acc + n `mod` 10 + n `rem` 10 > > > But now I see a message that acc is not known which is not wierd. > > But when I do sumDigits n acc I see a message that sumDigits has only 1 > parameter where I give it to, > > When I only had to sum up i is easy , I could use map [+] xs > > Anyone who can give a me tip without giving the answer otherwise I do not > learn anything. > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 7 09:05:16 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 10:05:16 +0100 Subject: [Haskell-beginners] sum problem In-Reply-To: References: <54D5D28E.3090807@home.nl> Message-ID: <54D5D54C.6020005@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 7 09:37:08 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 10:37:08 +0100 Subject: [Haskell-beginners] any feedback on this solution Message-ID: <54D5DCC4.9070208@home.nl> Hello, I finally solved exercise 1 where I had to write a programm which checks if a creditcard number is valid. I solved it this way : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n < 10 = [n] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] -- | convert a number to a reversed array where a negative number will be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = [0] toDigitsRev n | n < 0 = [] | n < 10 = [n] | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) -- | Doubles every second number from the right. doubleEveryOther :: [Integer] -> [Integer] doubleEveryOther [] = [] doubleEveryOther (x:[]) = [x] doubleEveryOther (x:(y:zs)) | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther zs | otherwise = [x *2] ++ y : doubleEveryOther zs -- | sum all the digits of a array sumDigits :: [Integer] -> Integer sumDigits [] = 0 sumDigits (x:zs) | x < 10 = x + sumDigits zs | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs -- | validate a number by looking if a number can be divided by 10 validate :: Integer -> Bool validate n = sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 -- | The main entry point. main :: IO () main = do print $ validate 4012888888881881 Any remarks about this solution. I know there are higher function solutions but that part is not descrived in chapter 1 . Roelof From K.Bleijenberg at lijbrandt.nl Sat Feb 7 09:56:11 2015 From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg) Date: Sat, 7 Feb 2015 10:56:11 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <54D5DCC4.9070208@home.nl> References: <54D5DCC4.9070208@home.nl> Message-ID: <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> Roelof, Maybe it's better to reuse toDigits in sumDigits. Kees -----Oorspronkelijk bericht----- Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof Wobben Verzonden: zaterdag 7 februari 2015 10:37 Aan: The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell Onderwerp: [Haskell-beginners] any feedback on this solution Hello, I finally solved exercise 1 where I had to write a programm which checks if a creditcard number is valid. I solved it this way : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n < 10 = [n] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] -- | convert a number to a reversed array where a negative number will be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = [0] toDigitsRev n | n < 0 = [] | n < 10 = [n] | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) -- | Doubles every second number from the right. doubleEveryOther :: [Integer] -> [Integer] doubleEveryOther [] = [] doubleEveryOther (x:[]) = [x] doubleEveryOther (x:(y:zs)) | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther zs | otherwise = [x *2] ++ y : doubleEveryOther zs -- | sum all the digits of a array sumDigits :: [Integer] -> Integer sumDigits [] = 0 sumDigits (x:zs) | x < 10 = x + sumDigits zs | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs -- | validate a number by looking if a number can be divided by 10 validate :: Integer -> Bool validate n = sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 -- | The main entry point. main :: IO () main = do print $ validate 4012888888881881 Any remarks about this solution. I know there are higher function solutions but that part is not descrived in chapter 1 . Roelof _______________________________________________ Beginners mailing list Beginners at haskell.org http://www.haskell.org/mailman/listinfo/beginners ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 From r.wobben at home.nl Sat Feb 7 10:01:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 11:01:55 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> Message-ID: <54D5E293.1090508@home.nl> Why, They have opposite terms. SumDigits takes a array and has a integer as output. ToDigits takes a integer and puts out a array. Roelof Kees Bleijenberg schreef op 7-2-2015 om 10:56: > Roelof, > > Maybe it's better to reuse toDigits in sumDigits. > > Kees > > -----Oorspronkelijk bericht----- > Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof Wobben > Verzonden: zaterdag 7 februari 2015 10:37 > Aan: The Haskell-Beginners Mailing List - Discussion of primarily > beginner-level topics related to Haskell > Onderwerp: [Haskell-beginners] any feedback on this solution > > Hello, > > I finally solved exercise 1 where I had to write a programm which checks > if a creditcard number is valid. > > I solved it this way : > > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > -- | convert a number to a reversed array where a negative number will > be a empty array > toDigitsRev :: Integer -> [Integer] > toDigitsRev 0 = [0] > toDigitsRev n > | n < 0 = [] > | n < 10 = [n] > | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) > > -- | Doubles every second number from the right. > doubleEveryOther :: [Integer] -> [Integer] > doubleEveryOther [] = [] > doubleEveryOther (x:[]) = [x] > doubleEveryOther (x:(y:zs)) > | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther zs > | otherwise = [x *2] ++ y : doubleEveryOther zs > > > -- | sum all the digits of a array > sumDigits :: [Integer] -> Integer > sumDigits [] = 0 > sumDigits (x:zs) > | x < 10 = x + sumDigits zs > | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs > > > -- | validate a number by looking if a number can be divided by 10 > validate :: Integer -> Bool > validate n = sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 > > > -- | The main entry point. > main :: IO () > main = do > print $ validate 4012888888881881 > > Any remarks about this solution. > > I know there are higher function solutions but that part is not > descrived in chapter 1 . > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > From timmelzer at gmail.com Sat Feb 7 10:41:11 2015 From: timmelzer at gmail.com (Norbert Melzer) Date: Sat, 7 Feb 2015 11:41:11 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <54D5E293.1090508@home.nl> References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> Message-ID: I'm sure you don't mean array here, but a list! The difference is crucial! Am 07.02.2015 11:01 schrieb "Roelof Wobben" : > Why, > > They have opposite terms. > > SumDigits takes a array and has a integer as output. > ToDigits takes a integer and puts out a array. > > Roelof > > > Kees Bleijenberg schreef op 7-2-2015 om 10:56: > >> Roelof, >> >> Maybe it's better to reuse toDigits in sumDigits. >> >> Kees >> >> -----Oorspronkelijk bericht----- >> Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof >> Wobben >> Verzonden: zaterdag 7 februari 2015 10:37 >> Aan: The Haskell-Beginners Mailing List - Discussion of primarily >> beginner-level topics related to Haskell >> Onderwerp: [Haskell-beginners] any feedback on this solution >> >> Hello, >> >> I finally solved exercise 1 where I had to write a programm which checks >> if a creditcard number is valid. >> >> I solved it this way : >> >> toDigits :: Integer -> [Integer] >> toDigits n >> | n < 0 = [] >> | n < 10 = [n] >> | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] >> >> -- | convert a number to a reversed array where a negative number will >> be a empty array >> toDigitsRev :: Integer -> [Integer] >> toDigitsRev 0 = [0] >> toDigitsRev n >> | n < 0 = [] >> | n < 10 = [n] >> | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) >> >> -- | Doubles every second number from the right. >> doubleEveryOther :: [Integer] -> [Integer] >> doubleEveryOther [] = [] >> doubleEveryOther (x:[]) = [x] >> doubleEveryOther (x:(y:zs)) >> | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther >> zs >> | otherwise = [x *2] ++ y : doubleEveryOther zs >> >> >> -- | sum all the digits of a array >> sumDigits :: [Integer] -> Integer >> sumDigits [] = 0 >> sumDigits (x:zs) >> | x < 10 = x + sumDigits zs >> | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs >> >> >> -- | validate a number by looking if a number can be divided by 10 >> validate :: Integer -> Bool >> validate n = sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 >> >> >> -- | The main entry point. >> main :: IO () >> main = do >> print $ validate 4012888888881881 >> >> Any remarks about this solution. >> >> I know there are higher function solutions but that part is not >> descrived in chapter 1 . >> >> Roelof >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 7 10:59:36 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 11:59:36 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> Message-ID: <54D5F018.4020507@home.nl> An HTML attachment was scrubbed... URL: From timmelzer at gmail.com Sat Feb 7 11:09:25 2015 From: timmelzer at gmail.com (Norbert Melzer) Date: Sat, 7 Feb 2015 12:09:25 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <54D5F018.4020507@home.nl> References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <54D5F018.4020507@home.nl> Message-ID: Nope they don't! Lists and arrays are conceptionally very different! An array is a fixed block of memory where the single elements are lined up in order, you have constant time access here, but changing the size requires you to completely reallocate the memory and copy old content over. A list on the other hand side is dynamic sized, this is bought by a larger memory footprint per element (pointer to the next one is added) and higher time for random access. Am 07.02.2015 11:59 schrieb "Roelof Wobben" : > You are right. Im was confusing it because several languages uses these > words differencely. > > Roelof > > > > Norbert Melzer schreef op 7-2-2015 om 11:41: > > I'm sure you don't mean array here, but a list! The difference is crucial! > Am 07.02.2015 11:01 schrieb "Roelof Wobben" : > >> Why, >> >> They have opposite terms. >> >> SumDigits takes a array and has a integer as output. >> ToDigits takes a integer and puts out a array. >> >> Roelof >> >> >> Kees Bleijenberg schreef op 7-2-2015 om 10:56: >> >>> Roelof, >>> >>> Maybe it's better to reuse toDigits in sumDigits. >>> >>> Kees >>> >>> -----Oorspronkelijk bericht----- >>> Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof >>> Wobben >>> Verzonden: zaterdag 7 februari 2015 10:37 >>> Aan: The Haskell-Beginners Mailing List - Discussion of primarily >>> beginner-level topics related to Haskell >>> Onderwerp: [Haskell-beginners] any feedback on this solution >>> >>> Hello, >>> >>> I finally solved exercise 1 where I had to write a programm which checks >>> if a creditcard number is valid. >>> >>> I solved it this way : >>> >>> toDigits :: Integer -> [Integer] >>> toDigits n >>> | n < 0 = [] >>> | n < 10 = [n] >>> | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] >>> >>> -- | convert a number to a reversed array where a negative number will >>> be a empty array >>> toDigitsRev :: Integer -> [Integer] >>> toDigitsRev 0 = [0] >>> toDigitsRev n >>> | n < 0 = [] >>> | n < 10 = [n] >>> | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) >>> >>> -- | Doubles every second number from the right. >>> doubleEveryOther :: [Integer] -> [Integer] >>> doubleEveryOther [] = [] >>> doubleEveryOther (x:[]) = [x] >>> doubleEveryOther (x:(y:zs)) >>> | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : >>> doubleEveryOther zs >>> | otherwise = [x *2] ++ y : doubleEveryOther zs >>> >>> >>> -- | sum all the digits of a array >>> sumDigits :: [Integer] -> Integer >>> sumDigits [] = 0 >>> sumDigits (x:zs) >>> | x < 10 = x + sumDigits zs >>> | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs >>> >>> >>> -- | validate a number by looking if a number can be divided by 10 >>> validate :: Integer -> Bool >>> validate n = sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 >>> >>> >>> -- | The main entry point. >>> main :: IO () >>> main = do >>> print $ validate 4012888888881881 >>> >>> Any remarks about this solution. >>> >>> I know there are higher function solutions but that part is not >>> descrived in chapter 1 . >>> >>> Roelof >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://www.haskell.org/mailman/listinfo/beginners >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://www.haskell.org/mailman/listinfo/beginners >>> >>> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://www.haskell.org/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From K.Bleijenberg at lijbrandt.nl Sat Feb 7 12:48:25 2015 From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg) Date: Sat, 7 Feb 2015 13:48:25 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <54D5E293.1090508@home.nl> References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> Message-ID: <002201d042d4$5d0c1fc0$17245f40$@lijbrandt.nl> Roelof, Say, you find after a few months a bug or a better algorithm for toDigits, then you have to remember that sumDigits uses this algorithm (in a bit different form) too. In this case the functions are so small that it is not a problem. If you apply toDigits to all elements of a list of int's and you get almost the solution apply toDigits to alle elements of [4,12,3] and you get [[4],[1,2],[3]], which is a small step to [4,1,2,3] Kees -----Oorspronkelijk bericht----- Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof Wobben Verzonden: zaterdag 7 februari 2015 11:02 Aan: The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell Onderwerp: Re: [Haskell-beginners] any feedback on this solution Why, They have opposite terms. SumDigits takes a array and has a integer as output. ToDigits takes a integer and puts out a array. Roelof Kees Bleijenberg schreef op 7-2-2015 om 10:56: > Roelof, > > Maybe it's better to reuse toDigits in sumDigits. > > Kees > > -----Oorspronkelijk bericht----- > Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof > Wobben > Verzonden: zaterdag 7 februari 2015 10:37 > Aan: The Haskell-Beginners Mailing List - Discussion of primarily > beginner-level topics related to Haskell > Onderwerp: [Haskell-beginners] any feedback on this solution > > Hello, > > I finally solved exercise 1 where I had to write a programm which > checks if a creditcard number is valid. > > I solved it this way : > > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > -- | convert a number to a reversed array where a negative number will > be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = > [0] toDigitsRev n > | n < 0 = [] > | n < 10 = [n] > | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) > > -- | Doubles every second number from the right. > doubleEveryOther :: [Integer] -> [Integer] > doubleEveryOther [] = [] > doubleEveryOther (x:[]) = [x] > doubleEveryOther (x:(y:zs)) > | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther zs > | otherwise = [x *2] ++ y : doubleEveryOther zs > > > -- | sum all the digits of a array > sumDigits :: [Integer] -> Integer > sumDigits [] = 0 > sumDigits (x:zs) > | x < 10 = x + sumDigits zs > | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs > > > -- | validate a number by looking if a number can be divided by 10 > validate :: Integer -> Bool validate n = > sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 > > > -- | The main entry point. > main :: IO () > main = do > print $ validate 4012888888881881 > > Any remarks about this solution. > > I know there are higher function solutions but that part is not > descrived in chapter 1 . > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: > 02/07/15 > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > _______________________________________________ Beginners mailing list Beginners at haskell.org http://www.haskell.org/mailman/listinfo/beginners ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 From joel.neely at gmail.com Sat Feb 7 13:25:32 2015 From: joel.neely at gmail.com (Joel Neely) Date: Sat, 7 Feb 2015 07:25:32 -0600 Subject: [Haskell-beginners] recursion problem. In-Reply-To: <1423285176.1254095.224241757.68C01536@webmail.messagingengine.com> References: <54D488A7.2090104@home.nl> <1423285176.1254095.224241757.68C01536@webmail.messagingengine.com> Message-ID: Brilliantly succinct answer! And the programming task that started this thread is a nice (though microscopic) illustration of the culture shock when our tidy, jewel-like programming models come to grips with the messy, non-systematic nature of many application domains. Thanks for both. -jn- On Fri, Feb 6, 2015 at 10:59 PM, Karl Voelker wrote: > On Fri, Feb 6, 2015, at 01:25 AM, Roelof Wobben wrote: > > but now when I do toDigits 0 , I see [] as output where I was expected > > [0] > > In our written notation, "0" is a special case: it's the only integer > written with a leading zero. So don't be too surprised if your code > requires a special case for it. > > -Karl > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Sat Feb 7 13:42:21 2015 From: joel.neely at gmail.com (Joel Neely) Date: Sat, 7 Feb 2015 07:42:21 -0600 Subject: [Haskell-beginners] sum problem In-Reply-To: <54D5D28E.3090807@home.nl> References: <54D5D28E.3090807@home.nl> Message-ID: Question/hint: You refer to acc three times, all in the right-hand-side expressions. Where is acc defined? -jn- On Sat, Feb 7, 2015 at 2:53 AM, Roelof Wobben wrote: > Hello, > > The exercises of CIS 194 are really hard. > > Now I have to sum all the numbers in a array with a catch > If a number is greater then 10 it has to be dived in single numbers. > > so [ 1 , 12, 3] will be [ 1, 1,2,3] and then sum up. > > So far I have this : > > -- | sum all the digits of a array > sumDigits :: [Integer] -> Integer > sumDigits n > | n == 0 = acc > | n < 10 = acc + n > | otherwise = sumDigits acc + n `mod` 10 + n `rem` 10 > > > But now I see a message that acc is not known which is not wierd. > > But when I do sumDigits n acc I see a message that sumDigits has only 1 > parameter where I give it to, > > When I only had to sum up i is easy , I could use map [+] xs > > Anyone who can give a me tip without giving the answer otherwise I do not > learn anything. > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 7 15:52:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 16:52:55 +0100 Subject: [Haskell-beginners] sum problem In-Reply-To: References: <54D5D28E.3090807@home.nl> Message-ID: <54D634D7.80303@home.nl> An HTML attachment was scrubbed... URL: From joel.s.williamson at gmail.com Sat Feb 7 15:56:14 2015 From: joel.s.williamson at gmail.com (Joel Williamson) Date: Sat, 07 Feb 2015 15:56:14 +0000 Subject: [Haskell-beginners] any feedback on this solution References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <002201d042d4$5d0c1fc0$17245f40$@lijbrandt.nl> Message-ID: Roelof, It doesn't look like you ever call toDigitsRev. To keep the solution clearer, you should remove any unneeded definitions. Joel On Sat, 7 Feb 2015 07:50 Kees Bleijenberg wrote: > Roelof, > > Say, you find after a few months a bug or a better algorithm for toDigits, > then you have to remember that sumDigits uses this algorithm (in a bit > different form) too. In this case the functions are so small that it is not > a problem. > > If you apply toDigits to all elements of a list of int's and you get > almost > the solution > apply toDigits to alle elements of [4,12,3] and you get [[4],[1,2],[3]], > which is a small step to [4,1,2,3] > > Kees > > -----Oorspronkelijk bericht----- > Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof Wobben > Verzonden: zaterdag 7 februari 2015 11:02 > Aan: The Haskell-Beginners Mailing List - Discussion of primarily > beginner-level topics related to Haskell > Onderwerp: Re: [Haskell-beginners] any feedback on this solution > > Why, > > They have opposite terms. > > SumDigits takes a array and has a integer as output. > ToDigits takes a integer and puts out a array. > > Roelof > > > Kees Bleijenberg schreef op 7-2-2015 om 10:56: > > Roelof, > > > > Maybe it's better to reuse toDigits in sumDigits. > > > > Kees > > > > -----Oorspronkelijk bericht----- > > Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof > > Wobben > > Verzonden: zaterdag 7 februari 2015 10:37 > > Aan: The Haskell-Beginners Mailing List - Discussion of primarily > > beginner-level topics related to Haskell > > Onderwerp: [Haskell-beginners] any feedback on this solution > > > > Hello, > > > > I finally solved exercise 1 where I had to write a programm which > > checks if a creditcard number is valid. > > > > I solved it this way : > > > > toDigits :: Integer -> [Integer] > > toDigits n > > | n < 0 = [] > > | n < 10 = [n] > > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > > > -- | convert a number to a reversed array where a negative number will > > be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = > > [0] toDigitsRev n > > | n < 0 = [] > > | n < 10 = [n] > > | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) > > > > -- | Doubles every second number from the right. > > doubleEveryOther :: [Integer] -> [Integer] > > doubleEveryOther [] = [] > > doubleEveryOther (x:[]) = [x] > > doubleEveryOther (x:(y:zs)) > > | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther > zs > > | otherwise = [x *2] ++ y : doubleEveryOther zs > > > > > > -- | sum all the digits of a array > > sumDigits :: [Integer] -> Integer > > sumDigits [] = 0 > > sumDigits (x:zs) > > | x < 10 = x + sumDigits zs > > | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs > > > > > > -- | validate a number by looking if a number can be divided by 10 > > validate :: Integer -> Bool validate n = > > sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 > > > > > > -- | The main entry point. > > main :: IO () > > main = do > > print $ validate 4012888888881881 > > > > Any remarks about this solution. > > > > I know there are higher function solutions but that part is not > > descrived in chapter 1 . > > > > Roelof > > > > _______________________________________________ > > Beginners mailing list > > Beginners at haskell.org > > http://www.haskell.org/mailman/listinfo/beginners > > > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: > > 02/07/15 > > > > _______________________________________________ > > Beginners mailing list > > Beginners at haskell.org > > http://www.haskell.org/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 7 16:01:28 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 07 Feb 2015 17:01:28 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <002201d042d4$5d0c1fc0$17245f40$@lijbrandt.nl> Message-ID: <54D636D8.3040809@home.nl> An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Sat Feb 7 16:06:02 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sat, 7 Feb 2015 17:06:02 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: <54D636D8.3040809@home.nl> References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <002201d042d4$5d0c1fc0$17245f40$@lijbrandt.nl> <54D636D8.3040809@home.nl> Message-ID: You should probably not remove toDigitsRev, especially since it's normally a piece of the correct solution for sumDigits... Your current sumDigits is incorrect, try it on [100, 100]. On Sat, Feb 7, 2015 at 5:01 PM, Roelof Wobben wrote: > Oke, > > toDigitsRev was one of the steps of this exercise. but I can remove it. > > Roelof > > > Joel Williamson schreef op 7-2-2015 om 16:56: > > Roelof, > > It doesn't look like you ever call toDigitsRev. To keep the solution > clearer, you should remove any unneeded definitions. > > Joel > > -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Sat Feb 7 16:11:53 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sat, 7 Feb 2015 17:11:53 +0100 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <002201d042d4$5d0c1fc0$17245f40$@lijbrandt.nl> <54D636D8.3040809@home.nl> Message-ID: On the other hand it will work here since the source is a list of digits which have been doubled every two elements... On Sat, Feb 7, 2015 at 5:06 PM, Chadda? Fouch? wrote: > You should probably not remove toDigitsRev, especially since it's normally > a piece of the correct solution for sumDigits... Your current sumDigits is > incorrect, try it on [100, 100]. > > On Sat, Feb 7, 2015 at 5:01 PM, Roelof Wobben wrote: > >> Oke, >> >> toDigitsRev was one of the steps of this exercise. but I can remove it. >> >> Roelof >> >> >> Joel Williamson schreef op 7-2-2015 om 16:56: >> >> Roelof, >> >> It doesn't look like you ever call toDigitsRev. To keep the solution >> clearer, you should remove any unneeded definitions. >> >> Joel >> >> > -- > Jeda? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwawrzyczek at gmail.com Sun Feb 8 11:11:18 2015 From: mwawrzyczek at gmail.com (Marek Wawrzyczek) Date: Sun, 08 Feb 2015 12:11:18 +0100 Subject: [Haskell-beginners] ODP: Re: any feedback on this solution Message-ID: Wys?ane z telefonu Samsung -------- Oryginalna wiadomo?? -------- Od: Roelof Wobben Data: 07.02.2015 17:01 (GMT+01:00) Do: The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell Temat: Re: [Haskell-beginners] any feedback on this solution Oke, toDigitsRev was one of the steps of this exercise. but I can remove it. Roelof Joel Williamson schreef op 7-2-2015 om 16:56: Roelof, It doesn't look like you ever call toDigitsRev. To keep the solution clearer, you should remove any unneeded definitions. Joel On Sat, 7 Feb 2015 07:50?Kees Bleijenberg wrote: Roelof, Say, you find after a few months a bug or a better algorithm for toDigits, then you have to remember that sumDigits uses this algorithm (in a bit different form) too. In this case the functions are so small that it is not a problem. If you apply toDigits to all elements of a list of int's and you get almost the solution apply toDigits to alle elements of [4,12,3] and you get [[4],[1,2],[3]], which is a small step to [4,1,2,3] Kees -----Oorspronkelijk bericht----- Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof Wobben Verzonden: zaterdag 7 februari 2015 11:02 Aan: The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell Onderwerp: Re: [Haskell-beginners] any feedback on this solution Why, They have opposite terms. SumDigits takes a array and has a integer as output. ToDigits takes a integer and puts out a array. Roelof Kees Bleijenberg schreef op 7-2-2015 om 10:56: > Roelof, > > Maybe it's better to reuse toDigits in sumDigits. > > Kees > > -----Oorspronkelijk bericht----- > Van: Beginners [mailto:beginners-bounces at haskell.org] Namens Roelof > Wobben > Verzonden: zaterdag 7 februari 2015 10:37 > Aan: The Haskell-Beginners Mailing List - Discussion of primarily > beginner-level topics related to Haskell > Onderwerp: [Haskell-beginners] any feedback on this solution > > Hello, > > I finally solved exercise 1 where I had to write a programm which > checks if a creditcard number is valid. > > I solved it this way : > > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > -- | convert a number to a reversed array where a negative number will > be a empty array toDigitsRev :: Integer -> [Integer] toDigitsRev 0 = > [0] toDigitsRev n > | n < 0 = [] > | n < 10 = [n] > | otherwise = n `mod` 10 : toDigitsRev (n `div` 10) > > -- | Doubles every second number from the right. > doubleEveryOther :: [Integer] -> [Integer] > doubleEveryOther [] = [] > doubleEveryOther (x:[])? ? ?= [x] > doubleEveryOther (x:(y:zs)) > | length (x:(y:zs)) `mod` 2 /= 0 = [x] ++ (y * 2) : doubleEveryOther zs > | otherwise = [x *2]? ++ y : doubleEveryOther zs > > > -- | sum all the digits of a array > sumDigits :: [Integer] -> Integer > sumDigits [] = 0 > sumDigits (x:zs) > | x < 10 = x + sumDigits zs > | otherwise = x `mod` 10 + x `div` 10 + sumDigits zs > > > -- | validate a number by looking if a number can be divided by 10 > validate :: Integer -> Bool validate n = > sumDigits(doubleEveryOther(toDigits(n))) `mod` 10 == 0 > > > -- | The main entry point. > main :: IO () > main = do > print $ validate 4012888888881881 > > Any remarks about this solution. > > I know there are higher function solutions but that part is not > descrived in chapter 1 . > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: > 02/07/15 > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > _______________________________________________ Beginners mailing list Beginners at haskell.org http://www.haskell.org/mailman/listinfo/beginners ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5646 / Virus Database: 4281/9071 - Release Date: 02/07/15 _______________________________________________ Beginners mailing list Beginners at haskell.org http://www.haskell.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list Beginners at haskell.org http://www.haskell.org/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Sun Feb 8 14:47:04 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sun, 8 Feb 2015 21:47:04 +0700 Subject: [Haskell-beginners] any feedback on this solution In-Reply-To: References: <54D5DCC4.9070208@home.nl> <000001d042bc$4d8d11c0$e8a73540$@lijbrandt.nl> <54D5E293.1090508@home.nl> <54D5F018.4020507@home.nl> Message-ID: On Sat, Feb 7, 2015 at 6:09 PM, Norbert Melzer wrote: > Lists and arrays are conceptionally very different! It's fair to point out that e.g. javascript arrays are list-like, as I understand them. They afford dynamic resizing that's seamlessly part of the traditional array API. Other languages may conflate them that way too, I don't know. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglaschristman at gmail.com Tue Feb 10 00:36:29 2015 From: douglaschristman at gmail.com (Douglas Christman) Date: Mon, 9 Feb 2015 19:36:29 -0500 Subject: [Haskell-beginners] Code review request Message-ID: Hi everyone, After spending some time reading "Learn you a Haskell," I decided to try writing my first Haskell program (https://github.com/dobyrch/musicbox). It reads ASCII "sheet music" and uses the terminal bell to play the song as it displays the frequency of each note. I'm looking for any tips that would make my code look more idiomatic. Please point out any places where I could simplify the logic or use standard library functions in place of custom code. Style suggestions are also welcome--let me know if you see anything ugly that could be written in a more readable way. Thanks! Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at karlv.net Tue Feb 10 05:48:55 2015 From: karl at karlv.net (Karl Voelker) Date: Mon, 09 Feb 2015 21:48:55 -0800 Subject: [Haskell-beginners] Code review request In-Reply-To: References: Message-ID: <1423547335.2521317.225470565.7B4D2482@webmail.messagingengine.com> Doug, Here are a few thoughts: * If you had a function "playOne :: Double -> IO ()" that plays one note, then you could define "play = mapM_ playOne". * It would be nice to separate the pure logic that converts a frequency into a string from the IO code that prints the string and delays. You would probably discover this yourself if you were to write some unit tests. * It seems that you are parsing and interpreting the input in a single pass (readSheet/readColumn). This is fine on such a small-scale example, although even still I find those functions a bit hard to grok. And a simple example like this might be a great place to learn about the many ways of writing parsers that are out there. * The Ord instance for Pitch could be simplified by using the built-in Monoid instance for Ordering. I'm going to leave the details of that unspecified so you can puzzle it out. * For the rest of the code, some comments would probably help those of us who are not music theory experts to follow it better. The one thing that caught my eye was the use of type synonyms (type Octave = Int and type Line = Int). You could mix up an Octave and a Line without getting a compile-time error. If you want to read a lot of opinions on when to use type synonyms, the Caf? had a thread about that recently: https://www.haskell.org/pipermail/haskell-cafe/2015-January/117771.html. Anyway, it looks like you have learned a lot already, so good job! -Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Tue Feb 10 12:58:37 2015 From: joel.neely at gmail.com (Joel Neely) Date: Tue, 10 Feb 2015 06:58:37 -0600 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" Message-ID: I understand the meaning of the warning, but got it in a situation I didn't expect. The following source file contains the simplest case I could construct quickly to illustrate my question: Why does the first function (sumDigits) get the "non-exhaustive" warning? It contains a definition for both empty and non-empty arguments, just as the second (sumList), which does not get a warning. {-# OPTIONS_GHC -Wall #-} sumDigits :: [Integer] -> Integer sumDigits [] = 0 sumDigits (n:ns) | n < 10 = n + sumDigits ns | n >= 10 = r + sumDigits (q : ns) where (q, r) = n `quotRem` 10 sumList :: [Integer] -> Integer sumList [] = 0 sumList (n:ns) = n + sumList ns ?For completeness, here is the ghci transcript, with the location reported: Prelude> :load sumDigits.hs [1 of 1] Compiling Main ( sumDigits.hs, interpreted ) sumDigits.hs:4:1: Warning: Pattern match(es) are non-exhaustive In an equation for ?sumDigits?: Patterns not matched: _ : _ Ok, modules loaded: Main. ? ?Thanks in advance for any guidance on this. -jn-? -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Tue Feb 10 13:18:11 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 10 Feb 2015 07:18:11 -0600 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 6:58 AM, Joel Neely wrote: > {-# OPTIONS_GHC -Wall #-} > > sumDigits :: [Integer] -> Integer > sumDigits [] = 0 > sumDigits (n:ns) > | n < 10 = n + sumDigits ns > | n >= 10 = r + sumDigits (q : ns) > where (q, r) = n `quotRem` 10 > > sumList :: [Integer] -> Integer > sumList [] = 0 > sumList (n:ns) = n + sumList ns > > > ghc can't decide whether or not the tests in the guards are complete or not. If you rewrite the second condition as "otherwise", it'll recognize the catch-all and you won't get a warning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Feb 10 13:52:24 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 10 Feb 2015 08:52:24 -0500 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 8:18 AM, Mike Meyer wrote: > ghc can't decide whether or not the tests in the guards are complete or > not. Expanding on this: that < and >= cover all cases is something that is convention for Ord instances, not something absolutely guaranteed to be true. (In fact, they *don't* cover all cases for IEEE floating point math, if either value is NaN. An SQL numeric value type would also not cover all cases because of the behavior of NULL. In both those cases, *both* conditions would return False.) The fact that you specified a type for which it does happen to be true doesn't really matter, because there's no way to convey a proof to the compiler that it's true for some types but not others. (Some argue that this and some other things are signs that the Ord typeclass is poorly designed; that is a fairly complex discussion.) A compiler for something like C would assume that it covers all types (and then behave weirdly in the above mentioned cases. Somewhat infamously, there was a longstanding bug in a standard C library function (qsort()) for decades because of this); Haskell compilers are a bit more pedantic and warn you that Ord provides no proof that those two conditions cover all cases. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 10 15:52:06 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 10 Feb 2015 22:52:06 +0700 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 7:58 PM, Joel Neely wrote: > sumDigits (n:ns) > | n < 10 = n + sumDigits ns > | n >= 10 = r + sumDigits (q : ns) > where (q, r) = n `quotRem` 10 > To reiterate what Mike and Brandon just said, it's not that both the [] and (n:ns) cases have not been covered. They have. It's that the (n:ns) case hasn't been covered completely because of the guards. This will work: sumDigits (n:ns) | n < 10 = n + sumDigits ns | otherwise = r + sumDigits (q : ns) As will this: sumDigits (n:ns) | n < 10 = n + sumDigits ns | n >= 10 = r + sumDigits (q : ns) | otherwise = error "will never fire, only to suppress spurious warning" There's also -fno-warn-incomplete-patterns. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From raabe at froglogic.com Tue Feb 10 16:14:56 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Tue, 10 Feb 2015 17:14:56 +0100 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: <37249b49747434770b529fa660472563@roundcube.froglogic.com> On 2015-02-10 14:52, Brandon Allbery wrote: > On Tue, Feb 10, 2015 at 8:18 AM, Mike Meyer wrote: > >> ghc can't decide whether or not the tests in the guards are complete or >> not. > > Expanding on this: that < and >= cover all cases is something that is > convention for Ord instances, not something absolutely guaranteed to be > true. (In fact, they *don't* cover all cases for IEEE floating point math, > if either value is NaN. An SQL numeric value type would also not > cover all cases because of the behavior of NULL. In both those cases, *both* > conditions would return False.) The fact that you specified a > type for which it does happen to be true doesn't really matter, because > there's no way to convey a proof to the compiler that it's true for > some types but not others. (Some argue that this and some other things are > signs that the Ord typeclass is poorly designed; that is a fairly > complex discussion.) Interesting! This got me thinking - is this issue because the compiler doesn't (cannot?) see the implementation of e.g. (<=)? I noticed that a similiar case exists with f :: Bool -> Bool f x | x = True | not x = False ...which yields the same warning. I suppose this is because the compiler doesn't know the definition of 'not' so it doesn't understand that either of the two guards will always be True. Is there some technical reason for this - maybe it's very time consuming prove that the guards are exhaustive? -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From ky3 at atamo.com Tue Feb 10 16:46:26 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 10 Feb 2015 23:46:26 +0700 Subject: [Haskell-beginners] Fwd: GHC 7.10 Prelude: we need your opinion Message-ID: Simon PJ missed out the haskell-beginners list, but I encourage you to fill out the survey below as well. Now you may ask, "Well, I'm still learning haskell and I don't know enough." But consider that by being on this list and by haskelling whatever you may consider as utterly insignificant, you're still waaaaaaaay ahead than those who have yet to reach haskell at all. Your opinion counts. Because those _after_ you will help provide jobs by creating haskell projects, just like you. But unlike them, you get to influence the haskell of tomorrow that will be their first encounter, whether that would be a haskell that's friendlier or more @#$%^& than what it is today. The survey link is here: *http://goo.gl/forms/XP1W2JdfpX * Summaries (each quite long) are here: ? Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 ? Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List ? Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP Fwiw, I voted to delay FTP. In fact, here's what I wrote: "FTP is rushed and potentially unstable. I don't think we understand all about Traversable that we think we do, which might mean another big Prelude overhaul in the future. Actually, FTP doesn't even belong in 7.12 per se. It belongs in a new Haskell language standard and if that coincides with GHC 7.12, great. If not, it can wait for GHC 8.x and up." Because I've been keeping tabs on FTP I wrote my opinion without perusing the summaries, but on doing so later, I stumbled upon the following points that happen to reflect my exact observations, points that are relevant to learning haskell and growing the haskell community: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List - The existing corpus of books, tutorials, syllabi, and the like usually have a significant portion of the text dedicated to these very Prelude functions - and they would all need significant revision. - Teaching beginners what sequence means in its full generality is going to be a challenge. - While teaching beginners who end up on #haskell IRC might be possible, this is likely to increase the "bounce" rate, people who see Haskell, play around, and run away scared. I think Haskell probably has a higher bounce rate than most other languages, making it worse would be bad. Whether you agree or disagree with the above, now's the time to make yourself heard. The survey closes Feb 21. p.s. Needless to say, feel free to discuss FTP on this list should your opinion need a sounding board and a bit of time (not too long!) to firm up. -- Kim-Ee ---------- Forwarded message ---------- From: Simon Peyton Jones Date: Tue, Feb 10, 2015 at 10:50 PM Subject: GHC 7.10 Prelude: we need your opinion To: "haskell at haskell.org" , "Haskell Cafe ( haskell-cafe at haskell.org)" , GHC users < glasgow-haskell-users at haskell.org>, "ghc-devs at haskell.org" < ghc-devs at haskell.org> Haskell Friends *This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX . Deadline is 21 Feb.* The ?Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the *Foldable and Traversable classes* (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: ? Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. ? Invite input from the Haskell community on which of two approaches to adopt (this survey ). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. ? Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: ? Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 ? Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List ? Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP This survey invites your input on which plan we should follow. Would you please ? Read the details of the alternative plans on the three wiki pages above ? Add your response to the survey Please do read the background. Well-informed responses will help. Thank you! *DEADLINE: 21 February 2015* Simon PJ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 10 17:01:41 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 00:01:41 +0700 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: <37249b49747434770b529fa660472563@roundcube.froglogic.com> References: <37249b49747434770b529fa660472563@roundcube.froglogic.com> Message-ID: On Tue, Feb 10, 2015 at 11:14 PM, Frerich Raabe wrote: > Interesting! This got me thinking - is this issue because the compiler > doesn't (cannot?) see the implementation of e.g. (<=)? > > It "sees" the implementation of (<=) for otherwise it won't be able to generate code for it. But see below. > I noticed that a similiar case exists with > > f :: Bool -> Bool > f x | x = True > | not x = False > > ...which yields the same warning. I suppose this is because the compiler > doesn't know the definition of 'not' so it doesn't understand that either > of the two guards will always be True. Again, it has to "know" the definition of the function "not" because it has to generate code to call it. But it doesn't "know" the function from any other function, say foo. Semantically speaking, both are equally opaque. Now you could point out that "Ah, but look at the definition of not. It could inline, simplify, et voila, obtain f True = True f False = False and hence pattern-matching is complete." Therein lies the rub. All that inlining and simplification boils down to evaluating the program _in_ the compiler, so if your program diverges so would the compiler, which wouldn't be a happy thing. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 10 17:07:43 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 00:07:43 +0700 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: <37249b49747434770b529fa660472563@roundcube.froglogic.com> Message-ID: On Wed, Feb 11, 2015 at 12:01 AM, Kim-Ee Yeoh wrote: > All that inlining and simplification boils down to evaluating the program > _in_ the compiler My apologies, I meant "amounts to", not "boils down to". -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Tue Feb 10 17:11:02 2015 From: joel.neely at gmail.com (Joel Neely) Date: Tue, 10 Feb 2015 11:11:02 -0600 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: Thanks for all the good explanations! I was misdirected by the fact that the warning location was on the empty case, but based on descriptions I think I understand why now. I find it interesting that there is a bit of a conflict between "good practice" heuristics: 1. Use -Wall (to eliminate questionable code that triggers warnings), and 2. Avoid _ in patterns in favor of explicit statement of the cases. So it would appear that the advice (per Kim-Ee) to add an "otherwise" as a third guard allows me to satisfy the compiler while documenting to the human reader that the definition is really complete without it. Thanks, -jn- On Tue, Feb 10, 2015 at 9:52 AM, Kim-Ee Yeoh wrote: > > On Tue, Feb 10, 2015 at 7:58 PM, Joel Neely wrote: > >> sumDigits (n:ns) >> | n < 10 = n + sumDigits ns >> | n >= 10 = r + sumDigits (q : ns) >> where (q, r) = n `quotRem` 10 >> > > To reiterate what Mike and Brandon just said, it's not that both the [] > and (n:ns) cases have not been covered. They have. > > It's that the (n:ns) case hasn't been covered completely because of the > guards. > > This will work: > > sumDigits (n:ns) > | n < 10 = n + sumDigits ns > | otherwise = r + sumDigits (q : ns) > > As will this: > > sumDigits (n:ns) > | n < 10 = n + sumDigits ns > | n >= 10 = r + sumDigits (q : ns) > | otherwise = error "will never fire, only to suppress spurious > warning" > > There's also -fno-warn-incomplete-patterns. > > -- Kim-Ee > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 10 17:39:06 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 00:39:06 +0700 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: Message-ID: On Wed, Feb 11, 2015 at 12:11 AM, Joel Neely wrote: > So it would appear that the advice (per Kim-Ee) to add an "otherwise" as a > third guard allows me to satisfy the compiler while documenting to the > human reader that the definition is really complete without it. Thanks for the citation! But if you look at lots of haskell code, I don't think there's One Best Style on how to write haskell. E.g. I hardly ever use guards and I'm far from being alone. For the code in question I'd probably have ended up with an if expression, although I do see the structural elegance that guards bring here. Another e.g. some will argue that the "right" approach is to collapse to 2 guards with the otherwise in the 2nd one. So the reader is expected to infer in a snap that if n is not < 10 then obviously it's >= 10. A "strong opinions, weakly held" strategy might work best. Be bold, make choices, trust in the warm diversity of the haskell universe. Don Stewart has a nice list of coding styles here: http://stackoverflow.com/a/6399082 -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.birch at gmail.com Tue Feb 10 22:15:37 2015 From: julian.birch at gmail.com (Julian Birch) Date: Tue, 10 Feb 2015 22:15:37 +0000 Subject: [Haskell-beginners] Fwd: GHC 7.10 Prelude: we need your opinion In-Reply-To: References: Message-ID: Ironically, as a beginner, I supported FTP. As a beginner, I don't need to worry about legacy compatibility, but I do worry about cognitive overload. And actually, for someone coming from almost any other language, having a non-general fold is a speedbump for me. As for sequence in its full generality, I don't know if I completely grasp it, but the basic idea of swapping two typeclasses around I found the first time I hoogled for something that did exactly that. J On 10 February 2015 at 16:46, Kim-Ee Yeoh wrote: > Simon PJ missed out the haskell-beginners list, but I encourage you to > fill out the survey below as well. > > Now you may ask, "Well, I'm still learning haskell and I don't know > enough." > > But consider that by being on this list and by haskelling whatever you may > consider as utterly insignificant, you're still waaaaaaaay ahead than those > who have yet to reach haskell at all. > > Your opinion counts. > > Because those _after_ you will help provide jobs by creating haskell > projects, just like you. > > But unlike them, you get to influence the haskell of tomorrow that will be > their first encounter, whether that would be a haskell that's friendlier or > more @#$%^& than what it is today. > > The survey link is here: > *http://goo.gl/forms/XP1W2JdfpX * > > Summaries (each quite long) are here: > > ? Overall summary: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710 > > > ? Details of Plan List: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > ? Details of Plan FTP: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP > > > Fwiw, I voted to delay FTP. In fact, here's what I wrote: > > "FTP is rushed and potentially unstable. I don't think we understand all > about Traversable that we think we do, which might mean another big Prelude > overhaul in the future. > > Actually, FTP doesn't even belong in 7.12 per se. It belongs in a new > Haskell language standard and if that coincides with GHC 7.12, great. If > not, it can wait for GHC 8.x and up." > > Because I've been keeping tabs on FTP I wrote my opinion without perusing > the summaries, but on doing so later, I stumbled upon the following points > that happen to reflect my exact observations, points that are relevant to > learning haskell and growing the haskell community: > > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > > - The existing corpus of books, tutorials, syllabi, and the like > usually have a significant portion of the text dedicated to these very > Prelude functions - and they would all need significant revision. > > > - Teaching beginners what sequence means in its full generality is > going to be a challenge. > > > - While teaching beginners who end up on #haskell IRC might be > possible, this is likely to increase the "bounce" rate, people who see > Haskell, play around, and run away scared. I think Haskell probably has a > higher bounce rate than most other languages, making it worse would be bad. > > > Whether you agree or disagree with the above, now's the time to make > yourself heard. The survey closes Feb 21. > > p.s. Needless to say, feel free to discuss FTP on this list should your > opinion need a sounding board and a bit of time (not too long!) to firm up. > > -- Kim-Ee > > ---------- Forwarded message ---------- > From: Simon Peyton Jones > Date: Tue, Feb 10, 2015 at 10:50 PM > Subject: GHC 7.10 Prelude: we need your opinion > To: "haskell at haskell.org" , "Haskell Cafe ( > haskell-cafe at haskell.org)" , GHC users < > glasgow-haskell-users at haskell.org>, "ghc-devs at haskell.org" < > ghc-devs at haskell.org> > > > Haskell Friends > > *This email asks for your help in deciding how to proceed with some > Prelude changes in GHC 7.10. Please read on, but all the info is also at > the survey link, here: http://goo.gl/forms/XP1W2JdfpX > . Deadline is 21 Feb.* > > > > The ?Core Libraries Committee (CLC) is responsible for developing the core > libraries that ship with GHC. This is an important but painstaking task, > and we owe the CLC a big vote of thanks for taking it on. > > For over a year the CLC has been working on integrating the *Foldable and > Traversable classes* (shipped in base in GHC 7.8) into the core > libraries, and into the Prelude in particular. Detailed planning for GHC > 7.10 started in the autumn of 2014, and the CLC went ahead with this > integration. > > Then we had a failure of communication. As these changes affect the > Prelude, which is in scope for all users of Haskell, these changes should > be held to a higher bar than the regular libraries@ review process. > However, the Foldable/Traversable changes were not particularly well > signposted. Many people have only recently woken up to them, and some have > objected (both in principle and detail). > > This is an extremely unfortunate situation. On the one hand we are at RC2 > for GHC 7.10, so library authors have invested effort in updating their > libraries to the new Prelude. On the other, altering the Prelude is in > effect altering the language, something we take pretty seriously. We should > have had this debate back in 2014, but here we are, and it is unproductive > to argue about whose fault it is. We all share responsibility. > > We need to decide what to do now. A small group of us met by Skype and > we've decided to do this: > > ? Push back GHC 7.10's release by at least a month, to late > March. This delay also gives us breathing space to address an unrelated > show-stopping bug, Trac #9858. > > ? Invite input from the Haskell community on which of two > approaches to adopt (this survey ). The > main questions revolve around impact on the Haskell ecosystem (commercial > applications, teaching, libraries, etc etc), so we want to ask your opinion > rather than guess it. > > ? Ask Simon Marlow and Simon Peyton Jones to decide which > approach to follow for GHC 7.10. > > Wiki pages have been created summarizing these two primary alternatives, > including many more points and counter-points and technical details: > > ? Overall summary: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710 > > > ? Details of Plan List: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > > ? Details of Plan FTP: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP > > > This survey invites your input on which plan we should follow. Would you > please > > ? Read the details of the alternative plans on the three wiki > pages above > > ? Add your response to the survey > > Please do read the background. Well-informed responses will help. Thank > you! > > *DEADLINE: 21 February 2015* > > Simon PJ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Tue Feb 10 22:18:27 2015 From: tonymorris at gmail.com (Tony Morris) Date: Wed, 11 Feb 2015 08:18:27 +1000 Subject: [Haskell-beginners] Fwd: GHC 7.10 Prelude: we need your opinion In-Reply-To: References: Message-ID: <54DA83B3.9090608@gmail.com> This is not ironic. This is the experience of hundreds of beginners. I can point to them from here. FTP supports beginners and teaching. On 11/02/15 08:15, Julian Birch wrote: > Ironically, as a beginner, I supported FTP. As a beginner, I don't > need to worry about legacy compatibility, but I do worry about > cognitive overload. And actually, for someone coming from almost any > other language, having a non-general fold is a speedbump for me. > > As for sequence in its full generality, I don't know if I completely > grasp it, but the basic idea of swapping two typeclasses around I > found the first time I hoogled for something that did exactly that. > > J > > On 10 February 2015 at 16:46, Kim-Ee Yeoh > wrote: > > Simon PJ missed out the haskell-beginners list, but I encourage > you to fill out the survey below as well. > > Now you may ask, "Well, I'm still learning haskell and I don't > know enough." > > But consider that by being on this list and by haskelling whatever > you may consider as utterly insignificant, you're still waaaaaaaay > ahead than those who have yet to reach haskell at all. > > Your opinion counts. > > Because those _after_ you will help provide jobs by creating > haskell projects, just like you. > > But unlike them, you get to influence the haskell of tomorrow that > will be their first encounter, whether that would be a haskell > that's friendlier or more @#$%^& than what it is today. > > The survey link is here: *http://goo.gl/forms/XP1W2JdfpX > * > > Summaries (each quite long) are here: > > ?Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 > > > > ?Details of Plan List: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > > ?Details of Plan FTP: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP > > > Fwiw, I voted to delay FTP. In fact, here's what I wrote: > > "FTP is rushed and potentially unstable. I don't think we > understand all about Traversable that we think we do, which might > mean another big Prelude overhaul in the future. > > Actually, FTP doesn't even belong in 7.12 per se. It belongs in a > new Haskell language standard and if that coincides with GHC 7.12, > great. If not, it can wait for GHC 8.x and up." > > Because I've been keeping tabs on FTP I wrote my opinion without > perusing the summaries, but on doing so later, I stumbled upon the > following points that happen to reflect my exact observations, > points that are relevant to learning haskell and growing the > haskell community: > > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > * The existing corpus of books, tutorials, syllabi, and the like > usually have a significant portion of the text dedicated to > these very Prelude functions - and they would all need > significant revision. > > * Teaching beginners what sequence means in its full generality > is going to be a challenge. > > * While teaching beginners who end up on #haskell IRC might be > possible, this is likely to increase the "bounce" rate, people > who see Haskell, play around, and run away scared. I think > Haskell probably has a higher bounce rate than most other > languages, making it worse would be bad. > > > Whether you agree or disagree with the above, now's the time to > make yourself heard. The survey closes Feb 21. > > p.s. Needless to say, feel free to discuss FTP on this list should > your opinion need a sounding board and a bit of time (not too > long!) to firm up. > > -- Kim-Ee > > ---------- Forwarded message ---------- > From: *Simon Peyton Jones* > > Date: Tue, Feb 10, 2015 at 10:50 PM > Subject: GHC 7.10 Prelude: we need your opinion > To: "haskell at haskell.org " > >, "Haskell Cafe > (haskell-cafe at haskell.org )" > >, GHC > users >, "ghc-devs at haskell.org > " > > > > Haskell Friends > > *This email asks for your help in deciding how to proceed with > some Prelude changes in GHC 7.10. Please read on, but all the info > is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. > Deadline is 21 Feb.* > > The ?Core Libraries Committee (CLC) is responsible for developing > the core libraries that ship with GHC. This is an important but > painstaking task, and we owe the CLC a big vote of thanks for > taking it on. > > For over a year the CLC has been working on integrating the > *Foldable and Traversable classes* (shipped in base in GHC 7.8) > into the core libraries, and into the Prelude in particular. > Detailed planning for GHC 7.10 started in the autumn of 2014, and > the CLC went ahead with this integration. > > Then we had a failure of communication. As these changes affect > the Prelude, which is in scope for all users of Haskell, these > changes should be held to a higher bar than the regular libraries@ > review process. However, the Foldable/Traversable changes were > not particularly well signposted. Many people have only recently > woken up to them, and some have objected (both in principle and > detail). > > This is an extremely unfortunate situation. On the one hand we are > at RC2 for GHC 7.10, so library authors have invested effort in > updating their libraries to the new Prelude. On the other, > altering the Prelude is in effect altering the language, something > we take pretty seriously. We should have had this debate back in > 2014, but here we are, and it is unproductive to argue about whose > fault it is. We all share responsibility. > > We need to decide what to do now. A small group of us met by Skype > and we've decided to do this: > > ?Push back GHC 7.10's release by at least a month, to late March. > This delay also gives us breathing space to address an unrelated > show-stopping bug, Trac #9858. > > ?Invite input from the Haskell community on which of two > approaches to adopt (this survey > ). The main questions revolve > around impact on the Haskell ecosystem (commercial applications, > teaching, libraries, etc etc), so we want to ask your opinion > rather than guess it. > > ?Ask Simon Marlow and Simon Peyton Jones to decide which approach > to follow for GHC 7.10. > > Wiki pages have been created summarizing these two primary > alternatives, including many more points and counter-points and > technical details: > > ?Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 > > > ?Details of Plan List: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > > ?Details of Plan FTP: > https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP > > > This survey invites your input on which plan we should follow. > Would you please > > ?Read the details of the alternative plans on the three wiki pages > above > > ?Add your response to the survey > > Please do read the background. Well-informed responses will > help. Thank you! > > *DEADLINE: 21 February 2015* > > Simon PJ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhub.bits at gmail.com Wed Feb 11 03:57:53 2015 From: madhub.bits at gmail.com (madhub) Date: Tue, 10 Feb 2015 22:57:53 -0500 Subject: [Haskell-beginners] svgcairo/ghc vis cabal install error.. Message-ID: Hi !, I tried installing svgcairo ( for installing ghc vis ). I am getting following error. Could you please help me out install ghc vis. Thanks in advance Madhu ? environment details. I am on mac yosomite with gcc provided by OS X. Following is the gcc ?version 22:54:34:~$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig export LDFLAGS=-L/usr/local/lib export CFLAGS=-I/usr/local/include export LIBS=-L/usr/local/lib svgcairo error =============== Configuring svgcairo-0.13.0.1... Building svgcairo-0.13.0.1... Preprocessing library svgcairo-0.13.0.1... gtk2hsC2hs: Error in C header file. /usr/include/sys/qos.h:124: (column 34) [FATAL] >>> Syntax error! The symbol `__attribute__' does not fit here. cabal: Error: some packages failed to install: svgcairo-0.13.0.1 failed during the building phase. The exception was: ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dedgrant at gmail.com Wed Feb 11 05:25:30 2015 From: dedgrant at gmail.com (Darren Grant) Date: Tue, 10 Feb 2015 21:25:30 -0800 Subject: [Haskell-beginners] Fwd: GHC 7.10 Prelude: we need your opinion In-Reply-To: References: Message-ID: Julian, You're not alone. The lack of a general fold was a stumbling block for me as well. I'd rather not propagate the special cases any further than absolutely necessary when a solution is known. It's easier to point to outdated material and explain how the situation was improved rather than continue to propagate mistakes in literature. Cheers, Darren On Tue, Feb 10, 2015 at 2:15 PM, Julian Birch wrote: > Ironically, as a beginner, I supported FTP. As a beginner, I don't need to > worry about legacy compatibility, but I do worry about cognitive overload. > And actually, for someone coming from almost any other language, having a > non-general fold is a speedbump for me. > > As for sequence in its full generality, I don't know if I completely grasp > it, but the basic idea of swapping two typeclasses around I found the first > time I hoogled for something that did exactly that. > > J > > On 10 February 2015 at 16:46, Kim-Ee Yeoh wrote: > >> Simon PJ missed out the haskell-beginners list, but I encourage you to >> fill out the survey below as well. >> >> Now you may ask, "Well, I'm still learning haskell and I don't know >> enough." >> >> But consider that by being on this list and by haskelling whatever you >> may consider as utterly insignificant, you're still waaaaaaaay ahead than >> those who have yet to reach haskell at all. >> >> Your opinion counts. >> >> Because those _after_ you will help provide jobs by creating haskell >> projects, just like you. >> >> But unlike them, you get to influence the haskell of tomorrow that will >> be their first encounter, whether that would be a haskell that's friendlier >> or more @#$%^& than what it is today. >> >> The survey link is here: >> *http://goo.gl/forms/XP1W2JdfpX * >> >> Summaries (each quite long) are here: >> >> ? Overall summary: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710 >> >> >> ? Details of Plan List: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List >> >> ? Details of Plan FTP: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP >> >> >> Fwiw, I voted to delay FTP. In fact, here's what I wrote: >> >> "FTP is rushed and potentially unstable. I don't think we understand all >> about Traversable that we think we do, which might mean another big Prelude >> overhaul in the future. >> >> Actually, FTP doesn't even belong in 7.12 per se. It belongs in a new >> Haskell language standard and if that coincides with GHC 7.12, great. If >> not, it can wait for GHC 8.x and up." >> >> Because I've been keeping tabs on FTP I wrote my opinion without perusing >> the summaries, but on doing so later, I stumbled upon the following points >> that happen to reflect my exact observations, points that are relevant to >> learning haskell and growing the haskell community: >> >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List >> >> >> - The existing corpus of books, tutorials, syllabi, and the like >> usually have a significant portion of the text dedicated to these very >> Prelude functions - and they would all need significant revision. >> >> >> - Teaching beginners what sequence means in its full generality is >> going to be a challenge. >> >> >> - While teaching beginners who end up on #haskell IRC might be >> possible, this is likely to increase the "bounce" rate, people who see >> Haskell, play around, and run away scared. I think Haskell probably has a >> higher bounce rate than most other languages, making it worse would be bad. >> >> >> Whether you agree or disagree with the above, now's the time to make >> yourself heard. The survey closes Feb 21. >> >> p.s. Needless to say, feel free to discuss FTP on this list should your >> opinion need a sounding board and a bit of time (not too long!) to firm up. >> >> -- Kim-Ee >> >> ---------- Forwarded message ---------- >> From: Simon Peyton Jones >> Date: Tue, Feb 10, 2015 at 10:50 PM >> Subject: GHC 7.10 Prelude: we need your opinion >> To: "haskell at haskell.org" , "Haskell Cafe ( >> haskell-cafe at haskell.org)" , GHC users < >> glasgow-haskell-users at haskell.org>, "ghc-devs at haskell.org" < >> ghc-devs at haskell.org> >> >> >> Haskell Friends >> >> *This email asks for your help in deciding how to proceed with some >> Prelude changes in GHC 7.10. Please read on, but all the info is also at >> the survey link, here: http://goo.gl/forms/XP1W2JdfpX >> . Deadline is 21 Feb.* >> >> >> >> The ?Core Libraries Committee (CLC) is responsible for developing the >> core libraries that ship with GHC. This is an important but painstaking >> task, and we owe the CLC a big vote of thanks for taking it on. >> >> For over a year the CLC has been working on integrating the *Foldable >> and Traversable classes* (shipped in base in GHC 7.8) into the core >> libraries, and into the Prelude in particular. Detailed planning for GHC >> 7.10 started in the autumn of 2014, and the CLC went ahead with this >> integration. >> >> Then we had a failure of communication. As these changes affect the >> Prelude, which is in scope for all users of Haskell, these changes should >> be held to a higher bar than the regular libraries@ review process. >> However, the Foldable/Traversable changes were not particularly well >> signposted. Many people have only recently woken up to them, and some have >> objected (both in principle and detail). >> >> This is an extremely unfortunate situation. On the one hand we are at RC2 >> for GHC 7.10, so library authors have invested effort in updating their >> libraries to the new Prelude. On the other, altering the Prelude is in >> effect altering the language, something we take pretty seriously. We should >> have had this debate back in 2014, but here we are, and it is unproductive >> to argue about whose fault it is. We all share responsibility. >> >> We need to decide what to do now. A small group of us met by Skype and >> we've decided to do this: >> >> ? Push back GHC 7.10's release by at least a month, to late >> March. This delay also gives us breathing space to address an unrelated >> show-stopping bug, Trac #9858. >> >> ? Invite input from the Haskell community on which of two >> approaches to adopt (this survey ). The >> main questions revolve around impact on the Haskell ecosystem (commercial >> applications, teaching, libraries, etc etc), so we want to ask your opinion >> rather than guess it. >> >> ? Ask Simon Marlow and Simon Peyton Jones to decide which >> approach to follow for GHC 7.10. >> >> Wiki pages have been created summarizing these two primary alternatives, >> including many more points and counter-points and technical details: >> >> ? Overall summary: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710 >> >> >> ? Details of Plan List: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List >> >> >> ? Details of Plan FTP: >> https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP >> >> >> This survey invites your input on which plan we should follow. Would you >> please >> >> ? Read the details of the alternative plans on the three wiki >> pages above >> >> ? Add your response to the survey >> >> >> Please do read the background. Well-informed responses will help. Thank >> you! >> >> *DEADLINE: 21 February 2015* >> >> Simon PJ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raabe at froglogic.com Wed Feb 11 08:24:18 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Wed, 11 Feb 2015 09:24:18 +0100 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: References: <37249b49747434770b529fa660472563@roundcube.froglogic.com> Message-ID: <7ad517d245cd925b846c6ff2c4ee9098@roundcube.froglogic.com> On 2015-02-10 18:01, Kim-Ee Yeoh wrote: > On Tue, Feb 10, 2015 at 11:14 PM, Frerich Raabe wrote: >> I noticed that a similiar case exists with >> >> f :: Bool -> Bool >> f x | x = True >> | not x = False [..] > Now you could point out that "Ah, but look at the definition of not. It > could inline, simplify, et voila, obtain > > f True = True > f False = False > > and hence pattern-matching is complete." > > Therein lies the rub. All that inlining and simplification boils down to > evaluating the program _in_ the compiler, so if your program diverges > so would the compiler, which wouldn't be a happy thing. Ah, true. The compiler would need to evaluate the program, I didn't realize that. But: what do you mean by 'if your program diverges' -- diverges from what? -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From raabe at froglogic.com Wed Feb 11 08:33:07 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Wed, 11 Feb 2015 09:33:07 +0100 Subject: [Haskell-beginners] Fwd: GHC 7.10 Prelude: we need your opinion In-Reply-To: References: Message-ID: <9abac1d896aeba7d7eeec4495b41abac@roundcube.froglogic.com> On 2015-02-10 17:46, Kim-Ee Yeoh wrote: > Your opinion counts. > > Because those _after_ you will help provide jobs by creating haskell > projects, just like you. I just want to express that I'm very positively surprised about how open the evolution of the language is! The fact that everybody can participate is a very welcome change from what I'm used to (in the C++ world, the standard is mostly developed and defined in among a very small circle of people). -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From ky3 at atamo.com Wed Feb 11 08:38:33 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 15:38:33 +0700 Subject: [Haskell-beginners] Question re "Pattern match(es) are non-exhaustive" In-Reply-To: <7ad517d245cd925b846c6ff2c4ee9098@roundcube.froglogic.com> References: <37249b49747434770b529fa660472563@roundcube.froglogic.com> <7ad517d245cd925b846c6ff2c4ee9098@roundcube.froglogic.com> Message-ID: On Wed, Feb 11, 2015 at 3:24 PM, Frerich Raabe wrote: > Ah, true. The compiler would need to evaluate the program, I didn't > realize that. But: what do you mean by 'if your program diverges' -- > diverges from what? http://en.wikipedia.org/wiki/Divergence_%28computer_science%29 -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 11 16:57:13 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 11 Feb 2015 11:57:13 -0500 Subject: [Haskell-beginners] svgcairo/ghc vis cabal install error.. In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 10:57 PM, madhub wrote: > Preprocessing library svgcairo-0.13.0.1... > gtk2hsC2hs: Error in C header file. > > /usr/include/sys/qos.h:124: (column 34) [FATAL] > >>> Syntax error! > The symbol `__attribute__' does not fit here. > What version of gtk2hs-buildtools / gtk2hsc2hs? They had to be upgraded recently (past several months) to deal with changes in Apple header files related to Yosemite and to Apple's migration from gcc to clang. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nemowiki at gmail.com Thu Feb 12 08:01:18 2015 From: nemowiki at gmail.com (Federico Leva (Nemo)) Date: Thu, 12 Feb 2015 09:01:18 +0100 Subject: [Haskell-beginners] Can't connect to or contact haskell.org Message-ID: <54DC5DCE.7070301@gmail.com> Multiple bug reports inside. == 0. Original problem == Open https://www.haskell.org/cabal/users-guide/ == 1. Networking issue == The website doesn't load, I can't connect to www.haskell.org. Some other websites work, for instance --- community.haskell.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 27.645/31.075/35.602/2.886 ms You can see my IP in the headers of this email; I'm a Fastweb user in Italy and the traceroute is the following: $ traceroute haskell.org traceroute to haskell.org (23.253.242.70), 30 hops max, 60 byte packets 1 192.168.1.254 (192.168.1.254) 1.172 ms 6.645 ms 6.500 ms 2 10.57.94.195 (10.57.94.195) 9.440 ms 9.391 ms 9.371 ms 3 * * 10.251.136.89 (10.251.136.89) 16.638 ms 4 10.251.132.44 (10.251.132.44) 16.565 ms 16.550 ms 16.541 ms 5 * * * 6 10.251.137.186 (10.251.137.186) 16.661 ms 3.071 ms 11.863 ms 7 10.0.56.69 (10.0.56.69) 11.822 ms 11.857 ms 11.877 ms 8 10.0.1.94 (10.0.1.94) 17.569 ms 17.996 ms * 9 10.254.2.174 (10.254.2.174) 20.047 ms 20.015 ms 22.521 ms 10 10.254.9.210 (10.254.9.210) 22.463 ms 13.660 ms 13.531 ms 11 10.254.9.82 (10.254.9.82) 16.350 ms 16.370 ms 15.166 ms 12 10.1.128.38 (10.1.128.38) 16.620 ms 17.120 ms 17.009 ms 13 10.1.146.186 (10.1.146.186) 15.362 ms 15.352 ms 15.707 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * == 2. Contacts issue == I looked for contact information on your website (well, http://web.archive.org/web/20150102193702/https://www.haskell.org/haskellwiki/Main_Page ), but couldn't find any. http://code.haskell.org/~dons/haskell-1990-2000/msg06755.html still applies == 3. Trac registration form == http://trac.haskell.org is accessible for me, so I tried that instead. When I register, I get the following: Notice: An email has been sent to federicoleva at tiscali with a token to verify your new email address Oops? Trac detected an internal error: OperationalError: disk I/O error There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue. To that end, you could a ticket at this site. The action that triggered the error was: POST: /login == 4. Trac confirmation email == The confirmation email was never received, so I can't complete the registration the obvious "Error: Forbidden TICKET_CREATE privileges are required to perform this operation" ensues. I tried another address (this) as well, but that wasn't enough. == 5. Mailman? == So far the email interface to mailman worked, let's hope this gets through. :) If this isn't the appropriate place for the reports, please forgive my insufficient browse-by-proxy capabilities. Nemo From ky3 at atamo.com Thu Feb 12 08:55:22 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 12 Feb 2015 15:55:22 +0700 Subject: [Haskell-beginners] Can't connect to or contact haskell.org In-Reply-To: <54DC5DCE.7070301@gmail.com> References: <54DC5DCE.7070301@gmail.com> Message-ID: Hi Nemo, Thank you for taking the effort to write a useful and detailed description of what appears to be an acute problem with the haskell.org infrastructure. I feel your frustration. Expectations of Haskell can be very high. But the reality is that with the resources given to it, I'm amazed every day that this ship -- being built as it sails where none has sailed before -- even moves at all. If you look at reddit haskell you'll find a history of recent haskell.org brownouts. If you kindly repost there, you'll elevate notice and help expedite resolution. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 13 19:39:29 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 13 Feb 2015 20:39:29 +0100 Subject: [Haskell-beginners] tower of hanoi problem Message-ID: <54DE52F1.5070800@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 13 21:09:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 13 Feb 2015 22:09:19 +0100 Subject: [Haskell-beginners] tower hanoi problem Message-ID: <54DE67FF.9020909@home.nl> An HTML attachment was scrubbed... URL: From theblessedadventhope at gmail.com Fri Feb 13 21:16:24 2015 From: theblessedadventhope at gmail.com (Steven Williams) Date: Fri, 13 Feb 2015 15:16:24 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DE67FF.9020909@home.nl> References: <54DE67FF.9020909@home.nl> Message-ID: <54DE69A8.2010704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am really horrible at helping people which is why I delayed replying to this. Your email got through to the list twice, you don't need to send it again. The steps you need to take are in the homework assignment. The items 1-3 are literally the algorithm you need to use. Something to keep in mind is that the pegs can change per function call. For example initially you call it with "hanoi 2 a b c", then hanoi calls itself again with "hanoi 1 a c b" to achieve one of the steps that you need to take. Steven Williams My PGP Key: http://pgp.mit.edu/pks/lookup?op=get&search=0xCACA6C74669A54FA On 02/13/2015 03:09 PM, Roelof Wobben wrote: > Hello, > > After a short break I try to make the next assignment of the CIS > 194 course. I do self-study. > > Lets say we have 1 disk with 2 pegs then we have this : > > > type Peg = String. type Move = (Peg, Peg) Hanoi :: Integer -> Peg > -> Peg -> [Move] > > So I can do this Hanoi 2 a b > > How can I proceed further. > > I do not see how I can tell that the disk can move from a to b And > I do not see what the base case will be . I think when a is empty > and b has a value. > > Can anyone shine a light on this matter without telling me the > answer ? > > Roelof > > typ > > > > _______________________________________________ Beginners mailing > list Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU3mmnAAoJEMrKbHRmmlT6zHMP/iOKoYXJejbt7CbEGsVhCvEl HXm1qPDNY+1wRAVVVmyCPSY3xXieE8Q+yPagfS4DhzUhsJjCnXZ1ZUBvm+Bx0tww 427ofFTuMYlrQ2gFlT2feHTm2l3NfSeeOQ8KiWS1XT6/UxQddarF8GIyO2tp29b8 51NxiOLJJpfGmGK0u2i0moDqMavHLeKWERToUrfkhTHcSVzyC7Aw4zAiG2ScaRzD CrYjIRq8SLB38svs8X31jx4vGVsVvwvCnoxReNjCNfYULgOHjfXE4kRz+pb0fScc A46uIkNxZ34sQdIWbuGbVe4sGDQl+BUh0HzdRDtviMbj38attE8WAjd8r+3SRpr9 ZgFoXGbj1Z0l9Pm82auvrKRX5aP2OmVAkCCyQW/PrsqRq8Ezz+t1bC0jNlYQbQc+ tgWUoQFeejJgxvmFqp693wpFe9gkbZ7pTjKYXFtv22IHsb7vlW9+Hhe7qxsLRPF9 QuSh1mkBElnK604b79HV8HtPmRezuQtFlKgmnkoT/fcu2KaAvReIdnGkTgjbs1qW JTvTCnxI9wHGUPpBLh8F5bx79UH/rKh43rz5IQZIA/fqwS+25OkFpAbm7UhB6pOh vknsLjaH4yzTqMJT15IWF/RMXITgMengmon2hzjzySqxEeK84rO8kIrOzYMqK3dr Z6ZSaA1o8Ba00Iz6EMpS =7773 -----END PGP SIGNATURE----- From r.wobben at home.nl Fri Feb 13 21:25:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 13 Feb 2015 22:25:55 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DE69A8.2010704@gmail.com> References: <54DE67FF.9020909@home.nl> <54DE69A8.2010704@gmail.com> Message-ID: <54DE6BE3.2030209@home.nl> Thanks, Is it the second time a c b because the next step will be a disk from the a to the c disk ? Roelof Steven Williams schreef op 13-2-2015 om 22:16: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am really horrible at helping people which is why I delayed replying > to this. Your email got through to the list twice, you don't need to > send it again. > > The steps you need to take are in the homework assignment. The items > 1-3 are literally the algorithm you need to use. Something to keep in > mind is that the pegs can change per function call. For example > initially you call it with "hanoi 2 a b c", then hanoi calls itself > again with "hanoi 1 a c b" to achieve one of the steps that you need > to take. > > Steven Williams > My PGP Key: http://pgp.mit.edu/pks/lookup?op=get&search=0xCACA6C74669A54FA > > On 02/13/2015 03:09 PM, Roelof Wobben wrote: >> Hello, >> >> After a short break I try to make the next assignment of the CIS >> 194 course. I do self-study. >> >> Lets say we have 1 disk with 2 pegs then we have this : >> >> >> type Peg = String. type Move = (Peg, Peg) Hanoi :: Integer -> Peg >> -> Peg -> [Move] >> >> So I can do this Hanoi 2 a b >> >> How can I proceed further. >> >> I do not see how I can tell that the disk can move from a to b And >> I do not see what the base case will be . I think when a is empty >> and b has a value. >> >> Can anyone shine a light on this matter without telling me the >> answer ? >> >> Roelof >> >> typ >> >> >> >> _______________________________________________ Beginners mailing >> list Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJU3mmnAAoJEMrKbHRmmlT6zHMP/iOKoYXJejbt7CbEGsVhCvEl > HXm1qPDNY+1wRAVVVmyCPSY3xXieE8Q+yPagfS4DhzUhsJjCnXZ1ZUBvm+Bx0tww > 427ofFTuMYlrQ2gFlT2feHTm2l3NfSeeOQ8KiWS1XT6/UxQddarF8GIyO2tp29b8 > 51NxiOLJJpfGmGK0u2i0moDqMavHLeKWERToUrfkhTHcSVzyC7Aw4zAiG2ScaRzD > CrYjIRq8SLB38svs8X31jx4vGVsVvwvCnoxReNjCNfYULgOHjfXE4kRz+pb0fScc > A46uIkNxZ34sQdIWbuGbVe4sGDQl+BUh0HzdRDtviMbj38attE8WAjd8r+3SRpr9 > ZgFoXGbj1Z0l9Pm82auvrKRX5aP2OmVAkCCyQW/PrsqRq8Ezz+t1bC0jNlYQbQc+ > tgWUoQFeejJgxvmFqp693wpFe9gkbZ7pTjKYXFtv22IHsb7vlW9+Hhe7qxsLRPF9 > QuSh1mkBElnK604b79HV8HtPmRezuQtFlKgmnkoT/fcu2KaAvReIdnGkTgjbs1qW > JTvTCnxI9wHGUPpBLh8F5bx79UH/rKh43rz5IQZIA/fqwS+25OkFpAbm7UhB6pOh > vknsLjaH4yzTqMJT15IWF/RMXITgMengmon2hzjzySqxEeK84rO8kIrOzYMqK3dr > Z6ZSaA1o8Ba00Iz6EMpS > =7773 > -----END PGP SIGNATURE----- > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > From mwm at mired.org Fri Feb 13 21:54:07 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 13 Feb 2015 15:54:07 -0600 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: <54DE52F1.5070800@home.nl> References: <54DE52F1.5070800@home.nl> Message-ID: On Fri, Feb 13, 2015 at 1:39 PM, Roelof Wobben wrote: > Hello, > > After a short break I try to make the next assignment of the CIS 194 > course. > I do self-study. > > Lets say we have 1 disk with 2 pegs then we have this : > > > type Peg = String. > type Move = (Peg, Peg) > Hanoi :: Integer -> Peg -> Peg -> [Move] > > So I can do this Hanoi 2 a b > > How can I proceed further. > > I do not see how I can tell that the disk can move from a to b > And I do not see what the base case will be . I think when a is empty and > b has a value. > It's a recursion problem. So you tackle it like any other recursion problem: ? Divide your input into two cases: the terminal one that ends the recursion and the one you recurse on. ? Decide how to handle the terminal case. In this case, you'll return a list consisting of one move. ? Decide how to divide the non-terminal case into at least two sub-problems that are all closer to the terminal case by some measurement. ? Write the code that makes the non-terminal calls and combines their values to create your return value. In cases where your function returns a list, the combination is almost always appending one case to the other. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 12:43:18 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 13:43:18 +0100 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: References: <54DE52F1.5070800@home.nl> Message-ID: <54DF42E6.4070001@home.nl> Hello, I try to answer your questions. Maybe then it is clear where My thinking gets the wrong turn. > > ? Divide your input into two cases: the terminal one that ends the > recursion and the one you recurse on. I think the terminal one is when there is no moves anymore so when a and b are empty and c holds all the disk. > ? Decide how to handle the terminal case. In this case, you'll return > a list consisting of one move. There is a problem. I thought I must return all the moves then. > ? Decide how to divide the non-terminal case into at least two > sub-problems that are all closer to the terminal case by some measurement. two subproblems ? I can only think about one and that is looking what the next move can be. > ? Write the code that makes the non-terminal calls and combines their > values to create your return value. Oke, when I have the right answers to the former questions, I can think about how to solve this one. > > In cases where your function returns a list, the combination is almost > always appending one case to the other. I also think so , so it will be old case ++ new case because otherwise it will display in the wrong order. Roelof From dontdieych at gmail.com Sat Feb 14 13:16:52 2015 From: dontdieych at gmail.com (YCH) Date: Sat, 14 Feb 2015 22:16:52 +0900 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: <54DE52F1.5070800@home.nl> References: <54DE52F1.5070800@home.nl> Message-ID: On Sat, Feb 14, 2015 at 4:39 AM, Roelof Wobben wrote: > Hello, > > After a short break I try to make the next assignment of the CIS 194 course. > I do self-study. > > Lets say we have 1 disk with 2 pegs then we have this : > > > type Peg = String. > type Move = (Peg, Peg) > Hanoi :: Integer -> Peg -> Peg -> [Move] > > So I can do this Hanoi 2 a b Should it be, hanoi :: Integer -> Peg -> Peg -> Peg -> [Move] ? So, hanoi n a b c hanoi 2 "a" "b" "c" - You have n disks at 'a' peg in right order(bigger is on bottom). - n should be >= 2. - You have to move all disk from 'a' to 'b'. - You can use 'c' as your temporary place. I've done this as, - write 'hanoi 2 "a" "b" "c" - write 'hanoi 3 "a" "b" "c" - write 'hanoi 4 "a" "b" "c" - find some common pattern >I do not see how I can tell that the disk can move from a to b Output of hanoi is 'move plan'. It does not actually do somthing. [ ("a", "b") , ("a", "c") ] means, - move disk on top of "a" peg to "b" - move disk on top of "b" peg to "c" From mwm at mired.org Sat Feb 14 15:24:17 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 14 Feb 2015 09:24:17 -0600 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: <54DF42E6.4070001@home.nl> References: <54DE52F1.5070800@home.nl> <54DF42E6.4070001@home.nl> Message-ID: On Sat, Feb 14, 2015 at 6:43 AM, Roelof Wobben wrote: > Hello, > > I try to answer your questions. Maybe then it is clear where My thinking > gets the wrong turn. > >> >> ? Divide your input into two cases: the terminal one that ends the >> recursion and the one you recurse on. >> > > I think the terminal one is when there is no moves anymore so when a and b > are empty and c holds all the disk. > I'd say the terminal one is one move, not no moves. I even gave it away with the next comment: ? Decide how to handle the terminal case. In this case, you'll return a >> list consisting of one move. > > There is a problem. I thought I must return all the moves then. > Ah, I think we miscommunciated about what "terminal" means. I meant the case that terminates the recursion, not the problem. That result will be combined with the values returned by other calls to create the ultimate return value having all the moves. So when hanoi is called with only 1 disk to move, you just return the list consisting of that move. If it's called with more than 1 disk, you have to make multiple recursive calls with fewer disks than it was called with. I don't think you can do this without special handling for the single disk case, so you might as well make that one your terminating case. Handling the no-disk case would be part of the initial error checking. > ? Decide how to divide the non-terminal case into at least two >> sub-problems that are all closer to the terminal case by some measurement. > > two subproblems ? I can only think about one and that is looking what the > next move can be. > There's gotta be at least two subproblems, because you have to create smaller problems for the recursive calls. If you can make the problem smaller without creating two subpropblems - well, then your problem can just goes away! For hanoi, you don't need to worry about what the next move will be. Assume that you have a working hanoi routine that can handle fewer disks that you currently have. How can you use that to solve your current problem? It should be obvious that you have to move some number less than all of them to one peg, then move the rest to the other peg, and finally move the first stack you moved on top of the second stack. So you need to figure out how many to move and where to move them to so you don't make any illegal moves in the process. > ? Write the code that makes the non-terminal calls and combines their >> values to create your return value. > > Oke, when I have the right answers to the former questions, I can think > about how to solve this one. Yup. > In cases where your function returns a list, the combination is almost >> always appending one case to the other. > > I also think so , so it will be old case ++ new case because otherwise it > will display in the wrong order. > Well, the solution I outlined has more than one case to deal with, as you have to make three recursive calls. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.birch at gmail.com Sat Feb 14 15:39:36 2015 From: julian.birch at gmail.com (Julian Birch) Date: Sat, 14 Feb 2015 15:39:36 +0000 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: References: <54DE52F1.5070800@home.nl> <54DF42E6.4070001@home.nl> Message-ID: Slightly off-topic, but you may be interesting in my post about the Fox/Goose/Corn problem. http://www.colourcoding.net/blog/archive/2015/01/03/fox-goose-corn-in-haskell-for-clojure-programmers.aspx It's a full Haskell solution from beginning to end, and explains the steps as it goes along, and it's a pretty similar problem to Hanoi. J On 14 February 2015 at 15:24, Mike Meyer wrote: > On Sat, Feb 14, 2015 at 6:43 AM, Roelof Wobben wrote: > >> Hello, >> >> I try to answer your questions. Maybe then it is clear where My thinking >> gets the wrong turn. >> >>> >>> ? Divide your input into two cases: the terminal one that ends the >>> recursion and the one you recurse on. >>> >> >> I think the terminal one is when there is no moves anymore so when a and >> b are empty and c holds all the disk. >> > > I'd say the terminal one is one move, not no moves. I even gave it away > with the next comment: > > ? Decide how to handle the terminal case. In this case, you'll return a >>> list consisting of one move. >> >> There is a problem. I thought I must return all the moves then. >> > > Ah, I think we miscommunciated about what "terminal" means. I meant the > case that terminates the recursion, not the problem. That result will be > combined with the values returned by other calls to create the ultimate > return value having all the moves. > > So when hanoi is called with only 1 disk to move, you just return the list > consisting of that move. If it's called with more than 1 disk, you have to > make multiple recursive calls with fewer disks than it was called with. I > don't think you can do this without special handling for the single disk > case, so you might as well make that one your terminating case. Handling > the no-disk case would be part of the initial error checking. > > >> ? Decide how to divide the non-terminal case into at least two >>> sub-problems that are all closer to the terminal case by some measurement. >> >> two subproblems ? I can only think about one and that is looking what >> the next move can be. >> > > There's gotta be at least two subproblems, because you have to create > smaller problems for the recursive calls. If you can make the problem > smaller without creating two subpropblems - well, then your problem can > just goes away! > > For hanoi, you don't need to worry about what the next move will be. > Assume that you have a working hanoi routine that can handle fewer disks > that you currently have. How can you use that to solve your current > problem? It should be obvious that you have to move some number less than > all of them to one peg, then move the rest to the other peg, and finally > move the first stack you moved on top of the second stack. So you need to > figure out how many to move and where to move them to so you don't make any > illegal moves in the process. > > >> ? Write the code that makes the non-terminal calls and combines their >>> values to create your return value. >> >> Oke, when I have the right answers to the former questions, I can think >> about how to solve this one. > > > Yup. > > >> In cases where your function returns a list, the combination is almost >>> always appending one case to the other. >> >> I also think so , so it will be old case ++ new case because otherwise it >> will display in the wrong order. >> > > Well, the solution I outlined has more than one case to deal with, as you > have to make three recursive calls. > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 17:56:35 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 18:56:35 +0100 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: References: <54DE52F1.5070800@home.nl> <54DF42E6.4070001@home.nl> Message-ID: <54DF8C53.4030606@home.nl> An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Sat Feb 14 18:43:49 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Sat, 14 Feb 2015 10:43:49 -0800 Subject: [Haskell-beginners] tower of hanoi problem In-Reply-To: References: <54DE52F1.5070800@home.nl> <54DF42E6.4070001@home.nl> Message-ID: <54DF9765.80108@runforyourlife.org> An aside about the Towers of Hanoi which does not answer the OP's question but is interesting: A recursive solution is a great method for having a computer play the game. But human beings might want to play it also, and humans don't think recursively -- we can't keep track of the intermediate results and where we are in the process. We think iteratively. It turns out that if you actually physically play the game you will discover that there is a very simple iterative pattern to the moves. I won't tell it, so that people can have the fun of discovering it. Disclosure: I "discovered" this while teaching the game to a child friend who had no particular mathematical or computer-related inclination ... and it was actually *she* who discovered it. She couldn't articulate it in words ... but she could *do* it. Here's a "Chinese proverb" definition (or example) of recursion: A journey of 10,000 miles starts with a single step ... followed by being able to take one more step no matter how many steps you have already taken. On 2/14/15 7:24 AM, Mike Meyer wrote: > On Sat, Feb 14, 2015 at 6:43 AM, Roelof Wobben > wrote: > > Hello, > > I try to answer your questions. Maybe then it is clear where My > thinking gets the wrong turn. > > > ? Divide your input into two cases: the terminal one that ends > the recursion and the one you recurse on. > > > I think the terminal one is when there is no moves anymore so when > a and b are empty and c holds all the disk. > > I'd say the terminal one is one move, not no moves. I even gave it > away with the next comment: > > ? Decide how to handle the terminal case. In this case, you'll > return a list consisting of one move. > > There is a problem. I thought I must return all the moves then. > > > Ah, I think we miscommunciated about what "terminal" means. I meant > the case that terminates the recursion, not the problem. That result > will be combined with the values returned by other calls to create the > ultimate return value having all the moves. > > So when hanoi is called with only 1 disk to move, you just return the > list consisting of that move. If it's called with more than 1 disk, > you have to make multiple recursive calls with fewer disks than it was > called with. I don't think you can do this without special handling > for the single disk case, so you might as well make that one your > terminating case. Handling the no-disk case would be part of the > initial error checking. > > ? Decide how to divide the non-terminal case into at least two > sub-problems that are all closer to the terminal case by some > measurement. > > two subproblems ? I can only think about one and that is looking > what the next move can be. > > > There's gotta be at least two subproblems, because you have to create > smaller problems for the recursive calls. If you can make the problem > smaller without creating two subpropblems - well, then your problem > can just goes away! > > For hanoi, you don't need to worry about what the next move will be. > Assume that you have a working hanoi routine that can handle fewer > disks that you currently have. How can you use that to solve your > current problem? It should be obvious that you have to move some > number less than all of them to one peg, then move the rest to the > other peg, and finally move the first stack you moved on top of the > second stack. So you need to figure out how many to move and where to > move them to so you don't make any illegal moves in the process. > > ? Write the code that makes the non-terminal calls and > combines their values to create your return value. > > Oke, when I have the right answers to the former questions, I can > think about how to solve this one. > > > Yup. > > In cases where your function returns a list, the combination > is almost always appending one case to the other. > > I also think so , so it will be old case ++ new case because > otherwise it will display in the wrong order. > > > Well, the solution I outlined has more than one case to deal with, as > you have to make three recursive calls. > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc1956 at gmail.com Sat Feb 14 21:23:14 2015 From: kc1956 at gmail.com (KC) Date: Sat, 14 Feb 2015 13:23:14 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DE67FF.9020909@home.nl> References: <54DE67FF.9020909@home.nl> Message-ID: Hint: - think about what you need to do in each recursive step and in the base case - there is also an interesting way of viewing the problem -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Feb 13, 2015 1:09 PM, "Roelof Wobben" wrote: > Hello, > > After a short break I try to make the next assignment of the CIS 194 > course. > I do self-study. > > Lets say we have 1 disk with 2 pegs then we have this : > > > type Peg = String. > type Move = (Peg, Peg) > Hanoi :: Integer -> Peg -> Peg -> [Move] > > So I can do this Hanoi 2 a b > > How can I proceed further. > > I do not see how I can tell that the disk can move from a to b > And I do not see what the base case will be . I think when a is empty and > b has a value. > > Can anyone shine a light on this matter without telling me the answer ? > > Roelof > > typ > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 21:27:27 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 22:27:27 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> Message-ID: <54DFBDBF.4020808@home.nl> KC schreef op 14-2-2015 om 22:23: > > Hint: > > - think about what you need to do in each recursive step and in the > base case > > - there is also an interesting way of viewing the problem > > Check if I can do another step or check if the end case all disk are on the last peg. Im very curious what the interesting way is From mwm at mired.org Sat Feb 14 21:30:11 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 14 Feb 2015 15:30:11 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DFBDBF.4020808@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> Message-ID: On Sat, Feb 14, 2015 at 3:27 PM, Roelof Wobben wrote: > KC schreef op 14-2-2015 om 22:23: > >> >> Hint: >> >> - think about what you need to do in each recursive step and in the base >> case >> >> - there is also an interesting way of viewing the problem >> >> >> > Check if I can do another step or check if the end case all disk are on > the last peg. > > Im very curious what the interesting way is > I suspect it's the iterative version that was already mentioned here. You were close to discovering it when worked through the problem on paper. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 21:35:25 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 22:35:25 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> Message-ID: <54DFBF9D.30704@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Sat Feb 14 21:38:01 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 14 Feb 2015 15:38:01 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DFBF9D.30704@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: On Sat, Feb 14, 2015 at 3:35 PM, Roelof Wobben wrote: > I know. > > Eveyone says there is a pattern but I do not see it at the moment. > > Maybe I do the wrong first move with more then 2 disk. > > You can put the first disk on the second or the thirth peg. > Think about which peg you want the stack to end up on, and what your last move HAS to be based on the rules. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontdieych at gmail.com Sat Feb 14 21:40:45 2015 From: dontdieych at gmail.com (YCH) Date: Sun, 15 Feb 2015 06:40:45 +0900 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DFBF9D.30704@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: Would you mind show code for only two cases? Just think about two cases. hanoi 2 a b c hanoi 3 a b c 2015. 2. 15. ?? 6:35? "Roelof Wobben" ?? ??: > I know. > > Eveyone says there is a pattern but I do not see it at the moment. > > Maybe I do the wrong first move with more then 2 disk. > > You can put the first disk on the second or the thirth peg. > > Roelof > > > Mike Meyer schreef op 14-2-2015 om 22:30: > > > > On Sat, Feb 14, 2015 at 3:27 PM, Roelof Wobben wrote: > >> KC schreef op 14-2-2015 om 22:23: >> >>> >>> Hint: >>> >>> - think about what you need to do in each recursive step and in the base >>> case >>> >>> - there is also an interesting way of viewing the problem >>> >>> >>> >> Check if I can do another step or check if the end case all disk are on >> the last peg. >> >> Im very curious what the interesting way is >> > > I suspect it's the iterative version that was already mentioned here. > You were close to discovering it when worked through the problem on paper. > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://www.haskell.org/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 21:45:29 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 22:45:29 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: <54DFC1F9.70208@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 14 21:46:37 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 14 Feb 2015 22:46:37 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: <54DFC23D.1000704@home.nl> YCH schreef op 14-2-2015 om 22:40: > > Would you mind show code for only two cases? Just think about two cases. > > hanoi 2 a b c > hanoi 3 a b c > > I do not have a code at the moment. I try it on paper. That one I can give you for both cases. Roelof From mwm at mired.org Sat Feb 14 21:51:17 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 14 Feb 2015 15:51:17 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: Do you want to see the list for those two cases? Because in either the recursive or iterative solution, there's only two cases. The 2-disk moves are: [(a, c), (a, b), (c, b)] The 3-disk moves are: [(a, b), (a, c), (b, c), (a, b), (c, a), (c, b), (a, b)] On Sat, Feb 14, 2015 at 3:40 PM, YCH wrote: > Would you mind show code for only two cases? Just think about two cases. > > hanoi 2 a b c > hanoi 3 a b c > 2015. 2. 15. ?? 6:35? "Roelof Wobben" ?? ??: > >> I know. >> >> Eveyone says there is a pattern but I do not see it at the moment. >> >> Maybe I do the wrong first move with more then 2 disk. >> >> You can put the first disk on the second or the thirth peg. >> >> Roelof >> >> >> Mike Meyer schreef op 14-2-2015 om 22:30: >> >> >> >> On Sat, Feb 14, 2015 at 3:27 PM, Roelof Wobben wrote: >> >>> KC schreef op 14-2-2015 om 22:23: >>> >>>> >>>> Hint: >>>> >>>> - think about what you need to do in each recursive step and in the >>>> base case >>>> >>>> - there is also an interesting way of viewing the problem >>>> >>>> >>>> >>> Check if I can do another step or check if the end case all disk are on >>> the last peg. >>> >>> Im very curious what the interesting way is >>> >> >> I suspect it's the iterative version that was already mentioned here. >> You were close to discovering it when worked through the problem on paper. >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://www.haskell.org/mailman/listinfo/beginners >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://www.haskell.org/mailman/listinfo/beginners >> >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontdieych at gmail.com Sat Feb 14 21:53:11 2015 From: dontdieych at gmail.com (YCH) Date: Sun, 15 Feb 2015 06:53:11 +0900 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54DFBF9D.30704@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: > You can put the first disk on the second or the thirth peg. Think a, b, c as 'src, target, temp' So if you have only one disk on src peg, it has to go target peg. But if you have two or more discs, you cannot put first peg on target peg. hanoi 1 1 2 3 = [ (1, 2) ] hanoi 2 1 2 3 = [ ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From borgauf at gmail.com Sat Feb 14 22:30:13 2015 From: borgauf at gmail.com (Lawrence Bottorff) Date: Sat, 14 Feb 2015 17:30:13 -0500 Subject: [Haskell-beginners] Getting "Discrete Mathematics Using a Computer" code to run Message-ID: Saw this message: Error Loading Stdm.lhs in Haskell platform 2012 *Iwan Awaludin* awaludin at gmail.com *Tue Sep 4 07:08:20 CEST 2012* and that helped past that error. But now I get [1 of 1] Compiling Stdm ( .../Discrete/Stdm02142015.lhs, interpreted ) .../Discrete/Stdm02142015.lhs:1036:40-46: Not in scope: `catch' .../Discrete/Stdm02142015.lhs:1048:40-46: Not in scope: `catch' Failed, modules loaded: none. This is on ghci 7.6.3 lb -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sun Feb 15 08:23:33 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 15 Feb 2015 09:23:33 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> Message-ID: <54E05785.4000001@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sun Feb 15 08:29:45 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 15 Feb 2015 09:29:45 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E05785.4000001@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> Message-ID: <54E058F9.7010409@home.nl> An HTML attachment was scrubbed... URL: From dontdieych at gmail.com Sun Feb 15 08:45:24 2015 From: dontdieych at gmail.com (YCH) Date: Sun, 15 Feb 2015 17:45:24 +0900 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E058F9.7010409@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> Message-ID: How about if I say "Actually target was c not b and here is one more disc. I put it on a. Now you should move all to c" On Sun, Feb 15, 2015 at 5:29 PM, Roelof Wobben wrote: > Roelof Wobben schreef op 15-2-2015 om 9:23: > > YCH schreef op 14-2-2015 om 22:53: > >> You can put the first disk on the second or the thirth peg. > > Think a, b, c as 'src, target, temp' > > So if you have only one disk on src peg, it has to go target peg. But if you > have two or more discs, you cannot put first peg on target peg. > > hanoi 1 1 2 3 = [ (1, 2) ] > hanoi 2 1 2 3 = [ ? > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > > Hanoi 1 a b c - [ (a,b)] > > Hanoi 2 123 = [ ( a,b)] > = [ (a,c) ] > =[ (b,c) ] > > > solved. > > Roelof > > > > Sorry, that one is wrong. Everything is on the 3th now. > > Another attempt. > > Hanoi 2 a b c = [ (a, c)] > = [ (a, b)] > = [ (c, b) ] > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From r.wobben at home.nl Sun Feb 15 08:51:52 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 15 Feb 2015 09:51:52 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> Message-ID: <54E05E28.1020806@home.nl> YCH schreef op 15-2-2015 om 9:45: > How about if I say "Actually target was c not b and here is one more > disc. I put it on a. Now you should move all to c" > > Hanoi 1 a b c A -> C Hanoi 2 a b c A -> B A -> C B -> C Hanoi 3 a b c A -> C A -> B C -> B A -> C B -> A B -> C A -> C Roelof From hjgtuyl at chello.nl Sun Feb 15 10:06:08 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 15 Feb 2015 11:06:08 +0100 Subject: [Haskell-beginners] Getting "Discrete Mathematics Using a Computer" code to run In-Reply-To: References: Message-ID: On Sat, 14 Feb 2015 23:30:13 +0100, Lawrence Bottorff wrote: > .../Discrete/Stdm02142015.lhs:1036:40-46: > Not in scope: `catch' > > .../Discrete/Stdm02142015.lhs:1048:40-46: > Not in scope: `catch' > Failed, modules loaded: none. > > This is on ghci 7.6.3 The function "catch" is removed from Prelude, you need to add the line: import Control.Exception Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From ondra at nekola.cz Sun Feb 15 10:52:12 2015 From: ondra at nekola.cz (Ondrej Nekola) Date: Sun, 15 Feb 2015 11:52:12 +0100 Subject: [Haskell-beginners] Spec with QuickCheck generationg list of list of the same length Message-ID: <54E07A5C.60301@nekola.cz> I am playing with Test.Hspec and Test.QuickCheck and I am traying to implement KMeans algorithm as a training. I use very simple representation of vectors: type LVector=[Double] I have no problems to write testcases with some concreate examples of input and expected output: it "sum of vectors is computed field by field" $ do (*sumVect* [[1.0, 2.0], [3.0, 4.0], [4, 5]]) `shouldBe` [8.0, 11.0] or simple properties based tests: it "zeroVector contains just zeroes" $ property (\(Positive d) -> [] == filter (/= 0.0) (*zeroVector*d) ) but I get sticked, when I try to create QuickCheck test, for example for the first case (*sumVect*). How can I generate list of lists, where all the included lists are of the same length? Link for some tutorial *) can be, I believe, enough but I would be glad for any help. Thanks Ondra @satai Nekola ondra at nekola.cz *) Maybe I have not trained my google good enough yet, but lack of tutorials describing more than the most basic usecase is probably the most problematic point in re-learning Haskell so far. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dontdieych at gmail.com Sun Feb 15 11:08:29 2015 From: dontdieych at gmail.com (YCH) Date: Sun, 15 Feb 2015 20:08:29 +0900 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E05E28.1020806@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> Message-ID: On Sun, Feb 15, 2015 at 5:51 PM, Roelof Wobben wrote: > YCH schreef op 15-2-2015 om 9:45: >> >> How about if I say "Actually target was c not b and here is one more >> disc. I put it on a. Now you should move all to c" >> >> > > Hanoi 1 a b c > > A -> C > > Hanoi 2 a b c > > A -> B > A -> C > B -> C > > Hanoi 3 a b c > > A -> C -- Compare these three lines to 'hanoi 2 ...'. > A -> B -- If you could find pattern here, > C -> B -- you can swap these lines to 'hanoi 2 ...'. > A -> C > B -> A > B -> C > A -> C From joel.neely at gmail.com Sun Feb 15 12:04:11 2015 From: joel.neely at gmail.com (Joel Neely) Date: Sun, 15 Feb 2015 06:04:11 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E05E28.1020806@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> Message-ID: Hint: So each of your has an odd number of lines. What do all the center lines have in common? What is common about all of the prefixes (groups of lines before the center) and suffixes (groups of lines following the center)? On Sun, Feb 15, 2015 at 2:51 AM, Roelof Wobben wrote: > YCH schreef op 15-2-2015 om 9:45: > >> How about if I say "Actually target was c not b and here is one more >> disc. I put it on a. Now you should move all to c" >> >> >> > Hanoi 1 a b c > > A -> C > > Hanoi 2 a b c > > A -> B > A -> C > B -> C > > Hanoi 3 a b c > > A -> C > A -> B > C -> B > A -> C > B -> A > B -> C > A -> C > > > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondra at nekola.cz Sun Feb 15 20:53:32 2015 From: ondra at nekola.cz (Ondrej Nekola) Date: Sun, 15 Feb 2015 21:53:32 +0100 Subject: [Haskell-beginners] Spec with QuickCheck generationg list of list of the same length In-Reply-To: <87vbj3e2ea.fsf@Chladni.home> References: <54E07A5C.60301@nekola.cz> <87vbj3e2ea.fsf@Chladni.home> Message-ID: <54E1074C.3070504@nekola.cz> Thanks, it sent me to the (higly probably) right direction: newtype RectList = RectList [LVector] deriving Show instance Arbitrary RectList where arbitrary = do m <- getPositive <$> arbitrary n <- getPositive <$> arbitrary RectList <$> replicateM n (vector m) and the test can look like this: it "average times number is sum" $ property (\(RectList x) -> null $ nozeroMembers $ zipWith (-) ( map (* (fromIntegral $ length x)) (average x)) (sumVect x) ) Thanks again Ondrej > On 2015-02-15 at 10:52, Ondrej Nekola wrote: >> How can I generate list of lists, where all the included lists are of >> the same length? > The general approach is to make a newtype, the Arbitrary instance of > which does what you want. For example, QucickCheck includes newtypes > Positive[1] and NonNegative[2], that generate restricted numbers. > > For your case, I'd write something like (untested): > > ``` > newtype RectList a = RectList [[a]] > > instance Arbitrary a => Arbitrary RectList a where > arbitrary = do > -- length of inner lists > m <- getPositive <$> arbitrary > -- length of outer list, can be zero > n <- getNonNegative <$> arbitrary > RectList <$> replicateM n (vector m) > ``` > > vector here is another function provided by QuickCheck: [3]. > > Hope this helps. > > bergey > >> Link for some tutorial *) can be, I believe, enough but I would be glad >> for any help. >> >> Thanks >> Ondra @satai Nekola >> ondra at nekola.cz >> >> *) Maybe I have not trained my google good enough yet, but lack of >> tutorials describing more than the most basic usecase is probably the >> most problematic point in re-learning Haskell so far. >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > Footnotes: > [1] http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/Test-QuickCheck.html#t:Positive > > [2] http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/Test-QuickCheck.html#t:NonNegative > > [3] http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/Test-QuickCheck-Arbitrary.html#v:vector > > From dbrooks at runforyourlife.org Sun Feb 15 20:54:36 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Sun, 15 Feb 2015 12:54:36 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E05E28.1020806@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> Message-ID: <54E1078C.5060303@runforyourlife.org> In my opinion, advising Mr Wobben to watch the pattern of moves will *not* lead him to the recursive solution, since the pattern of moves is really iterative. My hint would be to remember the very nature of recursion itself (for *any* problem): Do the first step. Then (to put it very dramatically) do *everything else* in *a single step*! (Realizing that "everything else" is really the same problem, just made slightly smaller.) Note: "A single step" might itself have more than one step. My point is that recursion consists of (to put it humorously): To do ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually be "last"! And remembering the story of the Gordian Knot might help too. (I apologize that trying not to be too explicit in the hint possibly makes it even more obscure.) Here's another hint that's useful for all kinds of programming problems, not just recursion: Most problems consist of not only what you're trying to solve, but also what the restrictions are on what you're allowed to do to solve it. Often some good insights come from imagining how you could solve the problem if you could ignore one or more of the restrictions (that's what I meant by the Gordian Knot reference). So for the Towers of Hanoi, think about what the restrictions are on what kind of moves you're allowed to make. Remove one of those restrictions. (Speaking of the iterative solution, the fun thing about actually physically doing the Towers of Hanoi is that, even though you're doing it by remembering the steps of the iterative pattern, as you watch the towers grow and shrink you can kind of "see" the recursion.) On 2/15/15 12:51 AM, Roelof Wobben wrote: > YCH schreef op 15-2-2015 om 9:45: >> How about if I say "Actually target was c not b and here is one more >> disc. I put it on a. Now you should move all to c" >> >> > > Hanoi 1 a b c > > A -> C > > Hanoi 2 a b c > > A -> B > A -> C > B -> C > > Hanoi 3 a b c > > A -> C > A -> B > C -> B > A -> C > B -> A > B -> C > A -> C > > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From hjgtuyl at chello.nl Sun Feb 15 23:45:15 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Mon, 16 Feb 2015 00:45:15 +0100 Subject: [Haskell-beginners] Getting "Discrete Mathematics Using a Computer" code to run In-Reply-To: References: Message-ID: There are several types of exceptions that could be caught here, but the compiler does not know which one to choose. You could specify a type, but it is easier to use 'onException' (also in Control.Exception) instead of 'catch', if you want to treat all exceptions the same way, without any info about the kind of exception. On Sun, 15 Feb 2015 17:49:21 +0100, Lawrence Bottorff wrote: > Thanks for the tip. Yes, I had tried that, but never got it right. Here's > my change: : > Stdm02142015.lhs:1037:40-46: > No instance for (Exception e1) arising from a use of `catch' > The type variable `e1' is ambiguous > Possible fix: add a type signature that fixes these type variable(s) > Note: there are several potential instances: > instance Exception NestedAtomically > -- Defined in `Control.Exception.Base' > instance Exception NoMethodError > -- Defined in `Control.Exception.Base' > instance Exception NonTermination > -- Defined in `Control.Exception.Base' > ...plus 7 others > In a stmt of a 'do' block: > filedata <- (readFile filename) `catch` (\ _ -> return "") : > et cetera, et cetera. Any idea where this import Control.Exception should > go. Or is there something else amiss? > > On Sun, Feb 15, 2015 at 5:06 AM, Henk-Jan van Tuyl > wrote: > >> On Sat, 14 Feb 2015 23:30:13 +0100, Lawrence Bottorff >> >> wrote: >> >> .../Discrete/Stdm02142015.lhs:1036:40-46: >>> Not in scope: `catch' >>> >>> .../Discrete/Stdm02142015.lhs:1048:40-46: >>> Not in scope: `catch' >>> Failed, modules loaded: none. >>> >>> This is on ghci 7.6.3 >>> >> >> The function "catch" is removed from Prelude, you need to add the line: >> import Control.Exception >> >> Regards, >> Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ From kc1956 at gmail.com Mon Feb 16 03:10:14 2015 From: kc1956 at gmail.com (KC) Date: Sun, 15 Feb 2015 19:10:14 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E1078C.5060303@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: The interesting way is to view the pegs not in a straight line but in another conic section ... -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Feb 15, 2015 12:54 PM, "Dudley Brooks" wrote: > In my opinion, advising Mr Wobben to watch the pattern of moves will *not* > lead him to the recursive solution, since the pattern of moves is really > iterative. > > My hint would be to remember the very nature of recursion itself (for > *any* problem): Do the first step. Then (to put it very dramatically) do > *everything else* in *a single step*! (Realizing that "everything else" is > really the same problem, just made slightly smaller.) > > Note: "A single step" might itself have more than one step. My point is > that recursion consists of (to put it humorously): To do > ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do > BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually be > "last"! And remembering the story of the Gordian Knot might help too. (I > apologize that trying not to be too explicit in the hint possibly makes it > even more obscure.) > > Here's another hint that's useful for all kinds of programming problems, > not just recursion: Most problems consist of not only what you're trying > to solve, but also what the restrictions are on what you're allowed to do > to solve it. Often some good insights come from imagining how you could > solve the problem if you could ignore one or more of the restrictions > (that's what I meant by the Gordian Knot reference). So for the Towers of > Hanoi, think about what the restrictions are on what kind of moves you're > allowed to make. Remove one of those restrictions. > > (Speaking of the iterative solution, the fun thing about actually > physically doing the Towers of Hanoi is that, even though you're doing it > by remembering the steps of the iterative pattern, as you watch the towers > grow and shrink you can kind of "see" the recursion.) > > On 2/15/15 12:51 AM, Roelof Wobben wrote: > >> YCH schreef op 15-2-2015 om 9:45: >> >>> How about if I say "Actually target was c not b and here is one more >>> disc. I put it on a. Now you should move all to c" >>> >>> >>> >> Hanoi 1 a b c >> >> A -> C >> >> Hanoi 2 a b c >> >> A -> B >> A -> C >> B -> C >> >> Hanoi 3 a b c >> >> A -> C >> A -> B >> C -> B >> A -> C >> B -> A >> B -> C >> A -> C >> >> >> Roelof >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 16 07:58:03 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 16 Feb 2015 08:58:03 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> Message-ID: <54E1A30B.4030202@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 16 07:59:41 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 16 Feb 2015 08:59:41 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E1078C.5060303@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: <54E1A36D.3010705@home.nl> Thanks, My way of working is one problem at the time. So first solve the itterate one and after that I gonna try to solve the recursion one. Otherwise I get confused. Roelof Dudley Brooks schreef op 15-2-2015 om 21:54: > In my opinion, advising Mr Wobben to watch the pattern of moves will > *not* lead him to the recursive solution, since the pattern of moves > is really iterative. > > My hint would be to remember the very nature of recursion itself (for > *any* problem): Do the first step. Then (to put it very > dramatically) do *everything else* in *a single step*! (Realizing > that "everything else" is really the same problem, just made slightly > smaller.) > > Note: "A single step" might itself have more than one step. My point > is that recursion consists of (to put it humorously): To do > ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do > BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually be > "last"! And remembering the story of the Gordian Knot might help > too. (I apologize that trying not to be too explicit in the hint > possibly makes it even more obscure.) > > Here's another hint that's useful for all kinds of programming > problems, not just recursion: Most problems consist of not only what > you're trying to solve, but also what the restrictions are on what > you're allowed to do to solve it. Often some good insights come from > imagining how you could solve the problem if you could ignore one or > more of the restrictions (that's what I meant by the Gordian Knot > reference). So for the Towers of Hanoi, think about what the > restrictions are on what kind of moves you're allowed to make. Remove > one of those restrictions. > > (Speaking of the iterative solution, the fun thing about actually > physically doing the Towers of Hanoi is that, even though you're doing > it by remembering the steps of the iterative pattern, as you watch the > towers grow and shrink you can kind of "see" the recursion.) > > On 2/15/15 12:51 AM, Roelof Wobben wrote: >> YCH schreef op 15-2-2015 om 9:45: >>> How about if I say "Actually target was c not b and here is one more >>> disc. I put it on a. Now you should move all to c" >>> >>> >> >> Hanoi 1 a b c >> >> A -> C >> >> Hanoi 2 a b c >> >> A -> B >> A -> C >> B -> C >> >> Hanoi 3 a b c >> >> A -> C >> A -> B >> C -> B >> A -> C >> B -> A >> B -> C >> A -> C >> >> >> Roelof >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From r.wobben at home.nl Mon Feb 16 08:00:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 16 Feb 2015 09:00:11 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: <54E1A38B.8010700@home.nl> KC schreef op 16-2-2015 om 4:10: > > The interesting way is to view the pegs not in a straight line but in > another conic section ... > Still no clue what you mean Roelof From joel.neely at gmail.com Mon Feb 16 13:07:58 2015 From: joel.neely at gmail.com (Joel Neely) Date: Mon, 16 Feb 2015 07:07:58 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E1078C.5060303@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: I'm sorry, but I must disagree with the generalization. You described "the very nature" of a typical recursion over a list: (1) deal with the head, then (2) deal with everything else. But lists are not the only recursive structure. Infix-order processing of a tree, for example, is more naturally described as: (1) deal with the left sub-tree (the first "everything else"), (2) deal with the parent (analogous to the head of a list), (3) deal with the right sub-tree (the second "everything else"). At the risk of a spoiler... . . . . One approach to the Towers of Hanoi problem emerges nicely from thinking of the moves as a tree. -jn- On Sun, Feb 15, 2015 at 2:54 PM, Dudley Brooks wrote: > In my opinion, advising Mr Wobben to watch the pattern of moves will *not* > lead him to the recursive solution, since the pattern of moves is really > iterative. > > My hint would be to remember the very nature of recursion itself (for > *any* problem): Do the first step. Then (to put it very dramatically) do > *everything else* in *a single step*! (Realizing that "everything else" is > really the same problem, just made slightly smaller.) > > Note: "A single step" might itself have more than one step. My point is > that recursion consists of (to put it humorously): To do > ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do > BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually be > "last"! And remembering the story of the Gordian Knot might help too. (I > apologize that trying not to be too explicit in the hint possibly makes it > even more obscure.) > > Here's another hint that's useful for all kinds of programming problems, > not just recursion: Most problems consist of not only what you're trying > to solve, but also what the restrictions are on what you're allowed to do > to solve it. Often some good insights come from imagining how you could > solve the problem if you could ignore one or more of the restrictions > (that's what I meant by the Gordian Knot reference). So for the Towers of > Hanoi, think about what the restrictions are on what kind of moves you're > allowed to make. Remove one of those restrictions. > > (Speaking of the iterative solution, the fun thing about actually > physically doing the Towers of Hanoi is that, even though you're doing it > by remembering the steps of the iterative pattern, as you watch the towers > grow and shrink you can kind of "see" the recursion.) > > > On 2/15/15 12:51 AM, Roelof Wobben wrote: > >> YCH schreef op 15-2-2015 om 9:45: >> >>> How about if I say "Actually target was c not b and here is one more >>> disc. I put it on a. Now you should move all to c" >>> >>> >>> >> Hanoi 1 a b c >> >> A -> C >> >> Hanoi 2 a b c >> >> A -> B >> A -> C >> B -> C >> >> Hanoi 3 a b c >> >> A -> C >> A -> B >> C -> B >> A -> C >> B -> A >> B -> C >> A -> C >> >> >> Roelof >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 16 13:14:08 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 16 Feb 2015 14:14:08 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: <54E1ED20.1020200@home.nl> An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Mon Feb 16 17:27:48 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Mon, 16 Feb 2015 09:27:48 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: <54E22894.7080308@runforyourlife.org> That definitely makes the iterative solution easier to see. Not sure if it helps with seeing the recursive solution, but you're right, it *is* the "natural" way to do the Towers. On 2/15/15 7:10 PM, KC wrote: > > The interesting way is to view the pegs not in a straight line but in > another conic section ... > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > On Feb 15, 2015 12:54 PM, "Dudley Brooks" > wrote: > > In my opinion, advising Mr Wobben to watch the pattern of moves > will *not* lead him to the recursive solution, since the pattern > of moves is really iterative. > > My hint would be to remember the very nature of recursion itself > (for *any* problem): Do the first step. Then (to put it very > dramatically) do *everything else* in *a single step*! (Realizing > that "everything else" is really the same problem, just made > slightly smaller.) > > Note: "A single step" might itself have more than one step. My > point is that recursion consists of (to put it humorously): To do > ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do > BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually > be "last"! And remembering the story of the Gordian Knot might > help too. (I apologize that trying not to be too explicit in the > hint possibly makes it even more obscure.) > > Here's another hint that's useful for all kinds of programming > problems, not just recursion: Most problems consist of not only > what you're trying to solve, but also what the restrictions are on > what you're allowed to do to solve it. Often some good insights > come from imagining how you could solve the problem if you could > ignore one or more of the restrictions (that's what I meant by the > Gordian Knot reference). So for the Towers of Hanoi, think about > what the restrictions are on what kind of moves you're allowed to > make. Remove one of those restrictions. > > (Speaking of the iterative solution, the fun thing about actually > physically doing the Towers of Hanoi is that, even though you're > doing it by remembering the steps of the iterative pattern, as you > watch the towers grow and shrink you can kind of "see" the recursion.) > > On 2/15/15 12:51 AM, Roelof Wobben wrote: > > YCH schreef op 15-2-2015 om 9:45: > > How about if I say "Actually target was c not b and here > is one more > disc. I put it on a. Now you should move all to c" > > > > Hanoi 1 a b c > > A -> C > > Hanoi 2 a b c > > A -> B > A -> C > B -> C > > Hanoi 3 a b c > > A -> C > A -> B > C -> B > A -> C > B -> A > B -> C > A -> C > > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Mon Feb 16 18:31:00 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Mon, 16 Feb 2015 10:31:00 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> Message-ID: <54E23764.4030203@runforyourlife.org> You're right, of course. I guess the more precise way to say what I meant is that you *separate* a single step from everything else, dealing with everything else as a lump ... or two lumps ... or three lumps ... or ... I did at least say that "a 'single step' might have more than one step." ;^) My mistake was the use of the word "first". On 2/16/15 5:07 AM, Joel Neely wrote: > I'm sorry, but I must disagree with the generalization. > > You described "the very nature" of a typical recursion over a list: > (1) deal with the head, then > (2) deal with everything else. > > But lists are not the only recursive structure. Infix-order processing > of a tree, for example, is more naturally described as: > (1) deal with the left sub-tree (the first "everything else"), > (2) deal with the parent (analogous to the head of a list), > (3) deal with the right sub-tree (the second "everything else"). > > At the risk of a spoiler... > > . > > . > > . > > . > > One approach to the Towers of Hanoi problem emerges nicely from > thinking of the moves as a tree. > > -jn- > > On Sun, Feb 15, 2015 at 2:54 PM, Dudley Brooks > > wrote: > > In my opinion, advising Mr Wobben to watch the pattern of moves > will *not* lead him to the recursive solution, since the pattern > of moves is really iterative. > > My hint would be to remember the very nature of recursion itself > (for *any* problem): Do the first step. Then (to put it very > dramatically) do *everything else* in *a single step*! (Realizing > that "everything else" is really the same problem, just made > slightly smaller.) > > Note: "A single step" might itself have more than one step. My > point is that recursion consists of (to put it humorously): To do > ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do > BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually > be "last"! And remembering the story of the Gordian Knot might > help too. (I apologize that trying not to be too explicit in the > hint possibly makes it even more obscure.) > > Here's another hint that's useful for all kinds of programming > problems, not just recursion: Most problems consist of not only > what you're trying to solve, but also what the restrictions are on > what you're allowed to do to solve it. Often some good insights > come from imagining how you could solve the problem if you could > ignore one or more of the restrictions (that's what I meant by the > Gordian Knot reference). So for the Towers of Hanoi, think about > what the restrictions are on what kind of moves you're allowed to > make. Remove one of those restrictions. > > (Speaking of the iterative solution, the fun thing about actually > physically doing the Towers of Hanoi is that, even though you're > doing it by remembering the steps of the iterative pattern, as you > watch the towers grow and shrink you can kind of "see" the > recursion.) > > > On 2/15/15 12:51 AM, Roelof Wobben wrote: > > YCH schreef op 15-2-2015 om 9:45: > > How about if I say "Actually target was c not b and here > is one more > disc. I put it on a. Now you should move all to c" > > > > Hanoi 1 a b c > > A -> C > > Hanoi 2 a b c > > A -> B > A -> C > B -> C > > Hanoi 3 a b c > > A -> C > A -> B > C -> B > A -> C > B -> A > B -> C > A -> C > > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Mon Feb 16 18:41:30 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Mon, 16 Feb 2015 10:41:30 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E23764.4030203@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> Message-ID: <54E239DA.1010606@runforyourlife.org> Plus I should say that the "first" (or whichever) step might also really be more than one step. The crucial idea is that there are individual step(s) versus "lumped" step(s), where the individual step(s) are the base case(s) and the "lumped" step(s) are the recursive invocation(s). On 2/16/15 10:31 AM, Dudley Brooks wrote: > You're right, of course. I guess the more precise way to say what I > meant is that you *separate* a single step from everything else, > dealing with everything else as a lump ... or two lumps ... or three > lumps ... or ... > > I did at least say that "a 'single step' might have more than one > step." ;^) My mistake was the use of the word "first". > > On 2/16/15 5:07 AM, Joel Neely wrote: >> I'm sorry, but I must disagree with the generalization. >> >> You described "the very nature" of a typical recursion over a list: >> (1) deal with the head, then >> (2) deal with everything else. >> >> But lists are not the only recursive structure. Infix-order >> processing of a tree, for example, is more naturally described as: >> (1) deal with the left sub-tree (the first "everything else"), >> (2) deal with the parent (analogous to the head of a list), >> (3) deal with the right sub-tree (the second "everything else"). >> >> At the risk of a spoiler... >> >> . >> >> . >> >> . >> >> . >> >> One approach to the Towers of Hanoi problem emerges nicely from >> thinking of the moves as a tree. >> >> -jn- >> >> On Sun, Feb 15, 2015 at 2:54 PM, Dudley Brooks >> > wrote: >> >> In my opinion, advising Mr Wobben to watch the pattern of moves >> will *not* lead him to the recursive solution, since the pattern >> of moves is really iterative. >> >> My hint would be to remember the very nature of recursion itself >> (for *any* problem): Do the first step. Then (to put it very >> dramatically) do *everything else* in *a single step*! >> (Realizing that "everything else" is really the same problem, >> just made slightly smaller.) >> >> Note: "A single step" might itself have more than one step. My >> point is that recursion consists of (to put it humorously): To >> do ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do >> BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might >> actually be "last"! And remembering the story of the Gordian >> Knot might help too. (I apologize that trying not to be too >> explicit in the hint possibly makes it even more obscure.) >> >> Here's another hint that's useful for all kinds of programming >> problems, not just recursion: Most problems consist of not only >> what you're trying to solve, but also what the restrictions are >> on what you're allowed to do to solve it. Often some good >> insights come from imagining how you could solve the problem if >> you could ignore one or more of the restrictions (that's what I >> meant by the Gordian Knot reference). So for the Towers of >> Hanoi, think about what the restrictions are on what kind of >> moves you're allowed to make. Remove one of those restrictions. >> >> (Speaking of the iterative solution, the fun thing about actually >> physically doing the Towers of Hanoi is that, even though you're >> doing it by remembering the steps of the iterative pattern, as >> you watch the towers grow and shrink you can kind of "see" the >> recursion.) >> >> >> On 2/15/15 12:51 AM, Roelof Wobben wrote: >> >> YCH schreef op 15-2-2015 om 9:45: >> >> How about if I say "Actually target was c not b and here >> is one more >> disc. I put it on a. Now you should move all to c" >> >> >> >> Hanoi 1 a b c >> >> A -> C >> >> Hanoi 2 a b c >> >> A -> B >> A -> C >> B -> C >> >> Hanoi 3 a b c >> >> A -> C >> A -> B >> C -> B >> A -> C >> B -> A >> B -> C >> A -> C >> >> >> Roelof >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> >> -- >> Beauty of style and harmony and grace and good rhythm depend on >> simplicity. - Plato > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 16 18:45:40 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 16 Feb 2015 19:45:40 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E239DA.1010606@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> Message-ID: <54E23AD4.8050203@home.nl> An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Mon Feb 16 20:01:32 2015 From: joel.neely at gmail.com (Joel Neely) Date: Mon, 16 Feb 2015 14:01:32 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E23AD4.8050203@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> Message-ID: Instead of thinking: 1. "Where do I move the top (smallest) disc?" and then 2. "How do I move everything else?" try thinking "Where do I move the bottom (largest) disc?" along with "What must happen before I move the bottom disc?" and "What must happen after I move the bottom disc?" -jn- On Mon, Feb 16, 2015 at 12:45 PM, Roelof Wobben wrote: > And Im still confused. > > Roelof > > > > Dudley Brooks schreef op 16-2-2015 om 19:41: > > Plus I should say that the "first" (or whichever) step might also really > be more than one step. The crucial idea is that there are individual > step(s) versus "lumped" step(s), where the individual step(s) are the base > case(s) and the "lumped" step(s) are the recursive invocation(s). > > On 2/16/15 10:31 AM, Dudley Brooks wrote: > > You're right, of course. I guess the more precise way to say what I meant > is that you *separate* a single step from everything else, dealing with > everything else as a lump ... or two lumps ... or three lumps ... or ... > > I did at least say that "a 'single step' might have more than one step." > ;^) My mistake was the use of the word "first". > > On 2/16/15 5:07 AM, Joel Neely wrote: > > I'm sorry, but I must disagree with the generalization. > > You described "the very nature" of a typical recursion over a list: > (1) deal with the head, then > (2) deal with everything else. > > But lists are not the only recursive structure. Infix-order processing > of a tree, for example, is more naturally described as: > (1) deal with the left sub-tree (the first "everything else"), > (2) deal with the parent (analogous to the head of a list), > (3) deal with the right sub-tree (the second "everything else"). > > At the risk of a spoiler... > > . > > . > > . > > . > > One approach to the Towers of Hanoi problem emerges nicely from thinking > of the moves as a tree. > > -jn- > > On Sun, Feb 15, 2015 at 2:54 PM, Dudley Brooks > wrote: > >> In my opinion, advising Mr Wobben to watch the pattern of moves will >> *not* lead him to the recursive solution, since the pattern of moves is >> really iterative. >> >> My hint would be to remember the very nature of recursion itself (for >> *any* problem): Do the first step. Then (to put it very dramatically) do >> *everything else* in *a single step*! (Realizing that "everything else" is >> really the same problem, just made slightly smaller.) >> >> Note: "A single step" might itself have more than one step. My point is >> that recursion consists of (to put it humorously): To do >> ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do >> BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might actually be >> "last"! And remembering the story of the Gordian Knot might help too. (I >> apologize that trying not to be too explicit in the hint possibly makes it >> even more obscure.) >> >> Here's another hint that's useful for all kinds of programming problems, >> not just recursion: Most problems consist of not only what you're trying >> to solve, but also what the restrictions are on what you're allowed to do >> to solve it. Often some good insights come from imagining how you could >> solve the problem if you could ignore one or more of the restrictions >> (that's what I meant by the Gordian Knot reference). So for the Towers of >> Hanoi, think about what the restrictions are on what kind of moves you're >> allowed to make. Remove one of those restrictions. >> >> (Speaking of the iterative solution, the fun thing about actually >> physically doing the Towers of Hanoi is that, even though you're doing it >> by remembering the steps of the iterative pattern, as you watch the towers >> grow and shrink you can kind of "see" the recursion.) >> >> >> On 2/15/15 12:51 AM, Roelof Wobben wrote: >> >>> YCH schreef op 15-2-2015 om 9:45: >>> >>>> How about if I say "Actually target was c not b and here is one more >>>> disc. I put it on a. Now you should move all to c" >>>> >>>> >>>> >>> Hanoi 1 a b c >>> >>> A -> C >>> >>> Hanoi 2 a b c >>> >>> A -> B >>> A -> C >>> B -> C >>> >>> Hanoi 3 a b c >>> >>> A -> C >>> A -> B >>> C -> B >>> A -> C >>> B -> A >>> B -> C >>> A -> C >>> >>> >>> Roelof >>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > > > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Mon Feb 16 23:55:23 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Mon, 16 Feb 2015 15:55:23 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E23AD4.8050203@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> Message-ID: <54E2836B.5080003@runforyourlife.org> (I hope that no one will think that this is too much of a hint.) There are three restrictions on how you can move: (1) You can only move one disc at a time. (2) You can only move the top disc of a stack. (3) You can't put a larger disc on a smaller one. What if (1) weren't true? What if you could move a whole bunch of discs at the same time? (Which would kind of mean that (2) wasn't true either.) What if, after you had removed a certain number of discs (I won't say how many, but think small!) from the top of a stack, you could simply pick up the entire remaining stack and move it? On 2/16/15 10:45 AM, Roelof Wobben wrote: > And Im still confused. > > Roelof > > > > Dudley Brooks schreef op 16-2-2015 om 19:41: >> Plus I should say that the "first" (or whichever) step might also >> really be more than one step. The crucial idea is that there are >> individual step(s) versus "lumped" step(s), where the individual >> step(s) are the base case(s) and the "lumped" step(s) are the >> recursive invocation(s). >> >> On 2/16/15 10:31 AM, Dudley Brooks wrote: >>> You're right, of course. I guess the more precise way to say what I >>> meant is that you *separate* a single step from everything else, >>> dealing with everything else as a lump ... or two lumps ... or three >>> lumps ... or ... >>> >>> I did at least say that "a 'single step' might have more than one >>> step." ;^) My mistake was the use of the word "first". >>> >>> On 2/16/15 5:07 AM, Joel Neely wrote: >>>> I'm sorry, but I must disagree with the generalization. >>>> >>>> You described "the very nature" of a typical recursion over a list: >>>> (1) deal with the head, then >>>> (2) deal with everything else. >>>> >>>> But lists are not the only recursive structure. Infix-order >>>> processing of a tree, for example, is more naturally described as: >>>> (1) deal with the left sub-tree (the first "everything else"), >>>> (2) deal with the parent (analogous to the head of a list), >>>> (3) deal with the right sub-tree (the second "everything else"). >>>> >>>> At the risk of a spoiler... >>>> >>>> . >>>> >>>> . >>>> >>>> . >>>> >>>> . >>>> >>>> One approach to the Towers of Hanoi problem emerges nicely from >>>> thinking of the moves as a tree. >>>> >>>> -jn- >>>> >>>> On Sun, Feb 15, 2015 at 2:54 PM, Dudley Brooks >>>> > wrote: >>>> >>>> In my opinion, advising Mr Wobben to watch the pattern of moves >>>> will *not* lead him to the recursive solution, since the >>>> pattern of moves is really iterative. >>>> >>>> My hint would be to remember the very nature of recursion >>>> itself (for *any* problem): Do the first step. Then (to put >>>> it very dramatically) do *everything else* in *a single step*! >>>> (Realizing that "everything else" is really the same problem, >>>> just made slightly smaller.) >>>> >>>> Note: "A single step" might itself have more than one step. >>>> My point is that recursion consists of (to put it humorously): >>>> To do ABCDEFGHIJKLMNOPQRSTUVWXYZ, first you do A, then you do >>>> BCDEFGHIJKLMNOPQRSTUVWXYZ. And, of course, "first" might >>>> actually be "last"! And remembering the story of the Gordian >>>> Knot might help too. (I apologize that trying not to be too >>>> explicit in the hint possibly makes it even more obscure.) >>>> >>>> Here's another hint that's useful for all kinds of programming >>>> problems, not just recursion: Most problems consist of not >>>> only what you're trying to solve, but also what the >>>> restrictions are on what you're allowed to do to solve it. >>>> Often some good insights come from imagining how you could >>>> solve the problem if you could ignore one or more of the >>>> restrictions (that's what I meant by the Gordian Knot >>>> reference). So for the Towers of Hanoi, think about what the >>>> restrictions are on what kind of moves you're allowed to make. >>>> Remove one of those restrictions. >>>> >>>> (Speaking of the iterative solution, the fun thing about >>>> actually physically doing the Towers of Hanoi is that, even >>>> though you're doing it by remembering the steps of the >>>> iterative pattern, as you watch the towers grow and shrink you >>>> can kind of "see" the recursion.) >>>> >>>> >>>> On 2/15/15 12:51 AM, Roelof Wobben wrote: >>>> >>>> YCH schreef op 15-2-2015 om 9:45: >>>> >>>> How about if I say "Actually target was c not b and >>>> here is one more >>>> disc. I put it on a. Now you should move all to c" >>>> >>>> >>>> >>>> Hanoi 1 a b c >>>> >>>> A -> C >>>> >>>> Hanoi 2 a b c >>>> >>>> A -> B >>>> A -> C >>>> B -> C >>>> >>>> Hanoi 3 a b c >>>> >>>> A -> C >>>> A -> B >>>> C -> B >>>> A -> C >>>> B -> A >>>> B -> C >>>> A -> C >>>> >>>> >>>> Roelof >>>> >>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>>> >>>> >>>> >>>> -- >>>> Beauty of style and harmony and grace and good rhythm depend on >>>> simplicity. - Plato >>> >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Feb 17 03:06:57 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 16 Feb 2015 22:06:57 -0500 Subject: [Haskell-beginners] tower hanoi problem Message-ID: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> > My way of working is one problem at the time. > So first solve the itterate one and after that I gonna try to solve the > recursion one. > Otherwise I get confused. This is the crux of the matter. You must strive to think those thoughts in the opposite order. Then you won't get confused. Recursion takes a grand simplifying view: "Are there smaller problems of the same kind, from the solution(s) of which we could build a solution of the problem at hand?" If so, let's just believe we have a solver for the smaller problems and build on them. This is the recursive step. Of course this can't be done when you are faced with the smallest possible problem. Then you have to tell directly how to solve it. This is the base case. [In Hanoi, the base case might be taken as how to move a pile of one disc to another post. Even more simply, it might be how to move a pile of zero discs--perhaps a curious idea, but no more curious than the idea of 0 as a counting number.] A trivial example: how to copy a list (x:xs) of arbitrary length. We could do that if we knew how to copy the smaller list tail, xs. All we have to do is tack x onto the head of the copy. Lo, the recipe copy (x:xs) = x : copy xs Final detail: when the list has no elements, there is no smaller list to copy. We need another rule for this base case. A copy of an empty list is empty: copy [] = [] With those two rules, we're done. No iterative reasoning about copying all the elements of the list. We can see that afterward, but that is not how we got to the solution. [It has been suggested that you can understand recursion thus > Do the first step. Then (to put it very dramatically) > do *everything else* in *a single step*! This point of view works for copy, and more generally for "tail recursion", which is trivially transformable to iteration. It doesn't work for Hanoi, which involves a fancier recursion pattern. The "smaller problem(s)" formulation does work.] In many harder problems a surefire way to get confused is to try to think about the sequence of elementary steps in the final solution. Hanoi is a good case in point. Eventually you will come to see recursion as a way to confidently obtain a solution, even though the progress of the computation is too complicated to visualize. It is not just a succinct way to express iteration! Doug McIlroy From r.wobben at home.nl Tue Feb 17 11:23:52 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 12:23:52 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> Message-ID: <54E324C8.8050803@home.nl> An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Tue Feb 17 12:05:59 2015 From: joel.neely at gmail.com (Joel Neely) Date: Tue, 17 Feb 2015 06:05:59 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E324C8.8050803@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> Message-ID: ?Let's tweak your answers? just a bit, calling the three pegs the "source", "goal", and "spare" pegs: On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben wrote: > - Where do I move the bottom (largest disk) ? > > To the last peg, which do not contain any disk then > ?. > >From the source peg to the goal peg, which will /must not contain any disks.? > ? > > > - What must happen before I can move the bottom disk ? > > I have to move the disk which above that disk. > Move everything else from ____ to ____.? > > - What must happen after I move the bottom disk ? > > All the other disk must be placed above that disk. > ?Move everything else from ____ to ____.? ?So more questions/hints: 1. How do you fill in the blanks? 2. How do you put the three statements in order? 3. How many disks does each statement talk about? -jn- ? -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 17 12:23:27 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 13:23:27 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> Message-ID: <54E332BF.3000107@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 17 15:09:32 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 17 Feb 2015 20:39:32 +0530 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E332BF.3000107@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> Message-ID: Think of the function, hanoi :: Integer -> Peg -> Peg -> Peg -> [Move] As printing the following moves: 1. Move (n - 1) discs from peg1 to peg2 using peg3 2. Move 1 disc from peg1 to peg3 using peg2 3. Move (n - 1) discs from peg2 to peg3 using peg1 The main idea behind towers of hanoi is that you are constrained, and cannot move many discs at once. But using an *intermediate peg*, you can eventually move all discs to the target peg. On 17 February 2015 at 17:53, Roelof Wobben wrote: > Joel Neely schreef op 17-2-2015 om 13:05: > > ?Let's tweak your answers? just a bit, calling the three pegs the > "source", "goal", and "spare" pegs: > > On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben wrote: > >> - Where do I move the bottom (largest disk) ? >> >> To the last peg, which do not contain any disk then >> ? . >> > > From the source peg to the goal peg, which will > /must > not contain any disks.? > > >> ? >> >> >> - What must happen before I can move the bottom disk ? >> >> I have to move the disk which above that disk. >> > > Move everything else from source to sparel peg.? > > >> >> - What must happen after I move the bottom disk ? >> >> All the other disk must be placed above that disk. >> > > ? Move everything else from spare to goal.? > > > ?So more questions/hints: > > 1. How do you fill in the blanks? > 2. How do you put the three statements in order? > 3. How many disks does each statement talk about? > > > -jn- > ? > > > 1. I did already. > 2. First move everything except the bottom one to the spare peg. > Move the bottom one to the goal peg. > Move everything else from the spare peg to the goal peg. > > 3. Only 2 > > Roelof > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Tue Feb 17 16:13:04 2015 From: joel.neely at gmail.com (Joel Neely) Date: Tue, 17 Feb 2015 10:13:04 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E332BF.3000107@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> Message-ID: Regarding your last answer... 3. Only 2 ...let me suggest a different perspective. If we begin with n disks, then: First move everything except the bottom one to the spare peg. ?"everything except the bottom one" refers to ?( n ? - 1)? disks Move the bottom one to the goal peg. ?"the bottom one" refers to 1 disk? Move everything else from the spare peg to the goal peg. ?"everything else" refers to ( n ? - 1)? disks So that moves the thought process toward the "fancier recursion pattern" per Doug McIlroy's excellent summary. On Tue, Feb 17, 2015 at 6:23 AM, Roelof Wobben wrote: > Joel Neely schreef op 17-2-2015 om 13:05: > > ?Let's tweak your answers? just a bit, calling the three pegs the > "source", "goal", and "spare" pegs: > > On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben wrote: > >> - Where do I move the bottom (largest disk) ? >> >> To the last peg, which do not contain any disk then >> ? . >> > > From the source peg to the goal peg, which will > /must > not contain any disks.? > > >> ? >> >> >> - What must happen before I can move the bottom disk ? >> >> I have to move the disk which above that disk. >> > > Move everything else from source to sparel peg.? > > >> >> - What must happen after I move the bottom disk ? >> >> All the other disk must be placed above that disk. >> > > ? Move everything else from spare to goal.? > > > ?So more questions/hints: > > 1. How do you fill in the blanks? > 2. How do you put the three statements in order? > 3. How many disks does each statement talk about? > > > -jn- > ? > > > 1. I did already. > 2. First move everything except the bottom one to the spare peg. > Move the bottom one to the goal peg. > Move everything else from the spare peg to the goal peg. > > 3. Only 2 > > Roelof > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 17 16:18:35 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 17:18:35 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> Message-ID: <54E369DB.7060602@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Tue Feb 17 16:47:55 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 17 Feb 2015 10:47:55 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E369DB.7060602@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> Message-ID: On Feb 17, 2015 10:18 AM, "Roelof Wobben" wrote: > > This part I understand well. > > So you could do something like this: > > hanoi n 1 2 3 > | n = 0 -> moves the last disk to the goal peg > | n != 0 -> moves all the other disk to the spare peg or to the moves n -1 to the goal peg What does n represent here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 17 16:50:32 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 17:50:32 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> Message-ID: <54E37158.4070501@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Tue Feb 17 16:57:14 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 17 Feb 2015 10:57:14 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E37158.4070501@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> <54E37158.4070501@home.nl> Message-ID: On Feb 17, 2015 10:50 AM, "Roelof Wobben" wrote: > > N reprent the number of disk So how does moving 0 disks happen? That is what your first case deals with. > Roelof > > > Mike Meyer schreef op 17-2-2015 om 17:47: >> >> >> On Feb 17, 2015 10:18 AM, "Roelof Wobben" wrote: >> > >> > This part I understand well. >> > >> > So you could do something like this: >> > >> > hanoi n 1 2 3 >> > | n = 0 -> moves the last disk to the goal peg >> > | n != 0 -> moves all the other disk to the spare peg or to the moves n -1 to the goal peg >> >> What does n represent here? >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 17 17:09:38 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 18:09:38 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> <54E37158.4070501@home.nl> Message-ID: <54E375D2.4080300@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 17 18:07:50 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 17 Feb 2015 23:37:50 +0530 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E375D2.4080300@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> <54E37158.4070501@home.nl> <54E375D2.4080300@home.nl> Message-ID: hanoi 1 p1 _ p3 = move 1 disc from p1 to p3 hanoi n p1 p2 p3 = move n discs from p1 to p3 using p2 in between The definition of the first equation is easy. To complete the second equation, you need to use hanoi again recursively. I detailed a way to complete the second equation in my previous mail (which hopefully didn't spoil it). Hope this helps. On 17 February 2015 at 22:39, Roelof Wobben wrote: > Stupid error > > Then it must be like this : > > hanoi n 1 2 3 > | n = 1 -> moves the last disk to the goal peg > | n > 1 -> moves all the other disk to the spare peg or to the moves > n -1 to the goal peg > > > Roelof > > > Mike Meyer schreef op 17-2-2015 om 17:57: > > On Feb 17, 2015 10:50 AM, "Roelof Wobben" wrote: > > > > N reprent the number of disk > > So how does moving 0 disks happen? That is what your first case deals with. > > > Roelof > > > > > > Mike Meyer schreef op 17-2-2015 om 17:47: > >> > >> > >> On Feb 17, 2015 10:18 AM, "Roelof Wobben" wrote: > >> > > >> > This part I understand well. > >> > > >> > So you could do something like this: > >> > > >> > hanoi n 1 2 3 > >> > | n = 0 -> moves the last disk to the goal peg > >> > | n != 0 -> moves all the other disk to the spare peg or to the > moves n -1 to the goal peg > >> > >> What does n represent here? > >> > >> > >> > >> _______________________________________________ > >> Beginners mailing list > >> Beginners at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > > > > _______________________________________________ > > Beginners mailing list > > Beginners at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 17 18:43:47 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 17 Feb 2015 19:43:47 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E332BF.3000107@home.nl> <54E369DB.7060602@home.nl> <54E37158.4070501@home.nl> <54E375D2.4080300@home.nl> Message-ID: <54E38BE3.2020205@home.nl> An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Tue Feb 17 19:42:59 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Tue, 17 Feb 2015 11:42:59 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> Message-ID: <54E399C3.5070704@runforyourlife.org> Um ... To the other people giving hints: Don't forget that in the sequence *of lines in the program* you have to state the base case(s) *first*, certainly in Haskell, which goes through the lines in order, until it finds a match. That's what I meant when I said "first do the base case(s), then the rest": first *in the program order*, if not necessarily in the conceptual structure. So for the depth-first binary tree which Joel Neely pointed out, *first* you must deal with the base case that the node being looked at is actually a leaf; *only then* can you deal with the fact that in general the algorithm has the structure . So if you try , the first part will either enter an endless loop or will generate an error, because it doesn't have a base case. (No pun on "base" intended.) On 2/17/15 4:05 AM, Joel Neely wrote: > ?Let's tweak your answers? just a bit, calling the three pegs the > "source", "goal", and "spare" pegs: > > On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben > wrote: > > - Where do I move the bottom (largest disk) ? > > To the last peg, which do not contain any disk then > ? . > > > From the source peg to the goal peg, which will > /must > not contain any disks.? > > ? > > > - What must happen before I can move the bottom disk ? > > I have to move the disk which above that disk. > > > Move everything else from ____ to ____.? > > > - What must happen after I move the bottom disk ? > > All the other disk must be placed above that disk. > > > ? Move everything else from ____ to ____.? > > ?So more questions/hints: > > 1. How do you fill in the blanks? > 2. How do you put the three statements in order? > 3. How many disks does each statement talk about? > > > -jn- > ? > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From guthrie at mum.edu Wed Feb 18 02:13:47 2015 From: guthrie at mum.edu (Gregory Guthrie) Date: Tue, 17 Feb 2015 20:13:47 -0600 Subject: [Haskell-beginners] Package access problem Message-ID: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6DC@MAIL.cs.mum.edu> I installed diagrams, and it seems to be there, but GHCi doesn't find it. I tried adding the local sandbox to the command line (-package-db), but still no luck Any suggestions? C:\Users\guthrie> C:\Users\guthrie>cabal install diagrams Resolving dependencies... All the requested packages are already installed: diagrams-1.2 Use --reinstall if you want to reinstall anyway. I find it in: C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d (diagrams-1.2, diagrams-contrib, -core, -lib, -svg) But running: "cabal repl" or using the GHC(i) flag "-package-db=..." fail to find it: C:\Users\guthrie>cabal repl GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Diagrams : Could not find module `Diagrams' It is not a module in the current program, or in any known package. Prelude> :m + Diagrams.Prelude : Could not find module `Diagrams.Prelude' It is not a module in the current program, or in any known package. Prelude> ---------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Feb 18 02:15:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 17 Feb 2015 21:15:05 -0500 Subject: [Haskell-beginners] Package access problem In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6DC@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6DC@MAIL.cs.mum.edu> Message-ID: On Tue, Feb 17, 2015 at 9:13 PM, Gregory Guthrie wrote: > : > > Could not find module `Diagrams' > > "Diagrams" is not a module in any of the packages; it's just a point in the namespace under which the actual modules reside. I see for example at http://hackage.haskell.org/package/diagrams-core - - Diagrams.Core - Diagrams.Core.Compile - Diagrams.Core.Envelope - Diagrams.Core.HasOrigin - Diagrams.Core.Juxtapose - Diagrams.Core.Names - Diagrams.Core.Points - Diagrams.Core.Query - Diagrams.Core.Style - Diagrams.Core.Trace - Diagrams.Core.Transform - Diagrams.Core.Types - Diagrams.Core.V - (Note that the top level "Diagrams" name on that page is italicized and not a link; this indicates that it's just a namespace.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Wed Feb 18 06:56:35 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Tue, 17 Feb 2015 22:56:35 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> Message-ID: <54E437A3.9000006@runforyourlife.org> On 2/16/15 7:06 PM, Doug McIlroy wrote: >> My way of working is one problem at the time. >> So first solve the itterate one and after that I gonna try to solve the >> recursion one. >> Otherwise I get confused. > This is the crux of the matter. You must strive to think those thoughts > in the opposite order. Then you won't get confused. > > Recursion takes a grand simplifying view: "Are there smaller problems of > the same kind, from the solution(s) of which we could build a solution of > the problem at hand?" If so, let's just believe we have a solver for the > smaller problems and build on them. This is the recursive step. > > Of course this can't be done when you are faced with the smallest > possible problem. Then you have to tell directly how to solve > it. This is the base case. > > [In Hanoi, the base case might be taken as how to move a pile > of one disc to another post. Even more simply, it might be how > to move a pile of zero discs--perhaps a curious idea, but no more > curious than the idea of 0 as a counting number.] > > A trivial example: how to copy a list (x:xs) of arbitrary length. > We could do that if we knew how to copy the smaller list tail, xs. > All we have to do is tack x onto the head of the copy. Lo, the recipe > copy (x:xs) = x : copy xs > Final detail: when the list has no elements, there is no smaller > list to copy. We need another rule for this base case. A copy > of an empty list is empty: > copy [] = [] > > With those two rules, we're done. No iterative reasoning about > copying all the elements of the list. We can see that afterward, > but that is not how we got to the solution. > > [It has been suggested that you can understand recursion thus > > Do the first step. Then (to put it very dramatically) > > do *everything else* in *a single step*! > This point of view works for copy, and more generally for > "tail recursion", which is trivially transformable to iteration. > It doesn't work for Hanoi, which involves a fancier recursion > pattern. The "smaller problem(s)" formulation does work.] I simplified it (or over-dramatized it) to the point of not-quite-correctness. I was trying to dramatize the point of how surprising the idea of recursion is, when you first encounter it (because I suspected that the OP had not yet "grokked" the elegance of recursion) -- and remembering my own Aha! moment at recursive definitions and proofs by induction in high school algebra, back when the only "high-level" programming language was assembly. I see that I gave the mistaken impression that that's the *only* kind of recursive structure. What I should have said, less dramatically, is Do the base case(s) Then do the recursion -- whatever steps that might involve, including possibly several recursive steps and possibly even several single steps, interweaved in various possible orders. You can't *start* with the recursion, or you'll get either an infinite loop or an error. I wouldn't quite call the conversion of tail-recursion to iteration trivial, exactly ... you still have to *do* it, after all! And when I did CS in school (a long time ago), the equivalence had only fairly recently been recognized. (By computer language designers, anyway. Maybe lambda-calculus mathematicians knew it long before that.) Certainly the idea that compilers could do it automatically was pretty new. If it were *completely* trivial, it would have been recognized long before! ;^) If you're younger you probably grew up when this idea was already commonplace. Yesterday's brilliant insight is today's trivia! > In many harder problems a surefire way to get confused is to > try to think about the sequence of elementary steps in the final > solution. Hanoi is a good case in point. > > Eventually you will come to see recursion as a way to confidently > obtain a solution, even though the progress of the computation is > too complicated to visualize. It is not just a succinct way to > express iteration! > > Doug McIlroy > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From dbrooks at runforyourlife.org Wed Feb 18 07:04:21 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Tue, 17 Feb 2015 23:04:21 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E437A3.9000006@runforyourlife.org> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> Message-ID: <54E43975.4040402@runforyourlife.org> On 2/17/15 10:56 PM, Dudley Brooks wrote: > On 2/16/15 7:06 PM, Doug McIlroy wrote: >>> My way of working is one problem at the time. >>> So first solve the itterate one and after that I gonna try to solve the >>> recursion one. >>> Otherwise I get confused. >> This is the crux of the matter. You must strive to think those thoughts >> in the opposite order. Then you won't get confused. >> >> Recursion takes a grand simplifying view: "Are there smaller problems of >> the same kind, from the solution(s) of which we could build a >> solution of >> the problem at hand?" If so, let's just believe we have a solver for the >> smaller problems and build on them. This is the recursive step. >> >> Of course this can't be done when you are faced with the smallest >> possible problem. Then you have to tell directly how to solve >> it. This is the base case. >> >> [In Hanoi, the base case might be taken as how to move a pile >> of one disc to another post. Even more simply, it might be how >> to move a pile of zero discs--perhaps a curious idea, but no more >> curious than the idea of 0 as a counting number.] >> >> A trivial example: how to copy a list (x:xs) of arbitrary length. >> We could do that if we knew how to copy the smaller list tail, xs. >> All we have to do is tack x onto the head of the copy. Lo, the recipe >> copy (x:xs) = x : copy xs >> Final detail: when the list has no elements, there is no smaller >> list to copy. We need another rule for this base case. A copy >> of an empty list is empty: >> copy [] = [] >> >> With those two rules, we're done. No iterative reasoning about >> copying all the elements of the list. We can see that afterward, >> but that is not how we got to the solution. >> >> [It has been suggested that you can understand recursion thus >> > Do the first step. Then (to put it very dramatically) >> > do *everything else* in *a single step*! >> This point of view works for copy, and more generally for >> "tail recursion", which is trivially transformable to iteration. >> It doesn't work for Hanoi, which involves a fancier recursion >> pattern. The "smaller problem(s)" formulation does work.] > > I simplified it (or over-dramatized it) to the point of > not-quite-correctness. I was trying to dramatize the point of how > surprising the idea of recursion is, when you first encounter it > (because I suspected that the OP had not yet "grokked" the elegance of > recursion) -- and remembering my own Aha! moment at recursive > definitions and proofs by induction in high school algebra, back when > the only "high-level" programming language was assembly. I see that I > gave the mistaken impression that that's the *only* kind of recursive > structure. What I should have said, less dramatically, is > > Do the base case(s) > Then do the recursion -- whatever steps that might involve, > including possibly several recursive steps and possibly even several > single steps, interweaved in various possible orders. > > You can't *start* with the recursion, or you'll get either an infinite > loop or an error. > > I wouldn't quite call the conversion of tail-recursion to iteration > trivial, exactly ... you still have to *do* it, after all! And when I > did CS in school (a long time ago), the equivalence had only fairly > recently been recognized. (By computer language designers, anyway. > Maybe lambda-calculus mathematicians knew it long before that.) > Certainly the idea that compilers could do it automatically was pretty > new. If it were *completely* trivial, it would have been recognized > long before! ;^) > > If you're younger you probably grew up when this idea was already > commonplace. Yesterday's brilliant insight is today's trivia! BTW, since, as you and several others point out, the recursive solution of Towers of Hanoi does *not* involve tail recursion, that's why it's all the more surprising that there actually is a very simple iterative solution, almost as simple to state as the recursive solution, and certainly easier to understand and follow by a novice or non-programmer, who doesn't think recursively. > >> In many harder problems a surefire way to get confused is to >> try to think about the sequence of elementary steps in the final >> solution. Hanoi is a good case in point. >> >> Eventually you will come to see recursion as a way to confidently >> obtain a solution, even though the progress of the computation is >> too complicated to visualize. It is not just a succinct way to >> express iteration! >> >> Doug McIlroy >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From r.wobben at home.nl Wed Feb 18 07:10:48 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 08:10:48 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E43975.4040402@runforyourlife.org> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> Message-ID: <54E43AF8.4030305@home.nl> That part I understand already. The only thing I do not see is what the base case in this exercise is because you are working with 3 things instead of 1 for example a list. As a example reversing a list recursive the base case is the not reversed list is empty. Roelof Dudley Brooks schreef op 18-2-2015 om 8:04: > On 2/17/15 10:56 PM, Dudley Brooks wrote: >> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>> My way of working is one problem at the time. >>>> So first solve the itterate one and after that I gonna try to solve >>>> the >>>> recursion one. >>>> Otherwise I get confused. >>> This is the crux of the matter. You must strive to think those thoughts >>> in the opposite order. Then you won't get confused. >>> >>> Recursion takes a grand simplifying view: "Are there smaller >>> problems of >>> the same kind, from the solution(s) of which we could build a >>> solution of >>> the problem at hand?" If so, let's just believe we have a solver for >>> the >>> smaller problems and build on them. This is the recursive step. >>> >>> Of course this can't be done when you are faced with the smallest >>> possible problem. Then you have to tell directly how to solve >>> it. This is the base case. >>> >>> [In Hanoi, the base case might be taken as how to move a pile >>> of one disc to another post. Even more simply, it might be how >>> to move a pile of zero discs--perhaps a curious idea, but no more >>> curious than the idea of 0 as a counting number.] >>> >>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>> We could do that if we knew how to copy the smaller list tail, xs. >>> All we have to do is tack x onto the head of the copy. Lo, the recipe >>> copy (x:xs) = x : copy xs >>> Final detail: when the list has no elements, there is no smaller >>> list to copy. We need another rule for this base case. A copy >>> of an empty list is empty: >>> copy [] = [] >>> >>> With those two rules, we're done. No iterative reasoning about >>> copying all the elements of the list. We can see that afterward, >>> but that is not how we got to the solution. >>> >>> [It has been suggested that you can understand recursion thus >>> > Do the first step. Then (to put it very dramatically) >>> > do *everything else* in *a single step*! >>> This point of view works for copy, and more generally for >>> "tail recursion", which is trivially transformable to iteration. >>> It doesn't work for Hanoi, which involves a fancier recursion >>> pattern. The "smaller problem(s)" formulation does work.] >> >> I simplified it (or over-dramatized it) to the point of >> not-quite-correctness. I was trying to dramatize the point of how >> surprising the idea of recursion is, when you first encounter it >> (because I suspected that the OP had not yet "grokked" the elegance >> of recursion) -- and remembering my own Aha! moment at recursive >> definitions and proofs by induction in high school algebra, back when >> the only "high-level" programming language was assembly. I see that >> I gave the mistaken impression that that's the *only* kind of >> recursive structure. What I should have said, less dramatically, is >> >> Do the base case(s) >> Then do the recursion -- whatever steps that might involve, >> including possibly several recursive steps and possibly even several >> single steps, interweaved in various possible orders. >> >> You can't *start* with the recursion, or you'll get either an >> infinite loop or an error. >> >> I wouldn't quite call the conversion of tail-recursion to iteration >> trivial, exactly ... you still have to *do* it, after all! And when >> I did CS in school (a long time ago), the equivalence had only fairly >> recently been recognized. (By computer language designers, anyway. >> Maybe lambda-calculus mathematicians knew it long before that.) >> Certainly the idea that compilers could do it automatically was >> pretty new. If it were *completely* trivial, it would have been >> recognized long before! ;^) >> >> If you're younger you probably grew up when this idea was already >> commonplace. Yesterday's brilliant insight is today's trivia! > > BTW, since, as you and several others point out, the recursive > solution of Towers of Hanoi does *not* involve tail recursion, that's > why it's all the more surprising that there actually is a very simple > iterative solution, almost as simple to state as the recursive > solution, and certainly easier to understand and follow by a novice or > non-programmer, who doesn't think recursively. >> >>> In many harder problems a surefire way to get confused is to >>> try to think about the sequence of elementary steps in the final >>> solution. Hanoi is a good case in point. >>> >>> Eventually you will come to see recursion as a way to confidently >>> obtain a solution, even though the progress of the computation is >>> too complicated to visualize. It is not just a succinct way to >>> express iteration! >>> >>> Doug McIlroy >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From bergey at alum.mit.edu Wed Feb 18 13:23:35 2015 From: bergey at alum.mit.edu (Daniel Bergey) Date: Wed, 18 Feb 2015 13:23:35 +0000 Subject: [Haskell-beginners] Package access problem In-Reply-To: References: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6DC@MAIL.cs.mum.edu> Message-ID: <87a90bnyjs.fsf@Chladni.home> On 2015-02-18 at 02:15, Brandon Allbery wrote: > On Tue, Feb 17, 2015 at 9:13 PM, Gregory Guthrie wrote: > >> : >> >> Could not find module `Diagrams' >> >> > "Diagrams" is not a module in any of the packages; it's just a point in the > namespace under which the actual modules reside. I see for example at > http://hackage.haskell.org/package/diagrams-core Expanding on Brandon's answer, Diagrams.Prelude[1] is probably what you want to import. You'll also need one of the Backends, to save files. See for instance this minimal example: [2] Footnotes: [1] http://hackage.haskell.org/package/diagrams-lib-1.2.0.8/docs/Diagrams-Prelude.html [2] http://projects.haskell.org/diagrams/doc/manual.html#getting-started From joel.neely at gmail.com Wed Feb 18 13:34:40 2015 From: joel.neely at gmail.com (Joel Neely) Date: Wed, 18 Feb 2015 07:34:40 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E399C3.5070704@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> Message-ID: I believe that the assertion that "*in the sequence *of lines in the program* you have to state the base case(s) *first**" is a bit too strong, although it is certainly correct to say that termination must be assured. For (a very trivial) example: dupEvens :: [Int] -> [Int] dupEvens (n:ns) | even n = n : n : dupEvens ns | otherwise = n : dupEvens ns dupEvens [] = [] which behaves as: *Main> dupEvens [3,1,4,1,5,9,2,6] [3,1,4,4,1,5,9,2,2,6,6] *Main> dupEvens [0..5] [0,0,1,2,2,3,4,4,5] the base case for list recursion (the empty list) is stated last. That is not a problem because the inductive case (non-empty list) contains a pattern that won't match an empty list. So I suggest modifying the beginners' advice to something like: *When evaluating a function, Haskell considers the parts of the definition in the order they are written, top-to-bottom, and uses the first one that matches. So make sure that your left-hand sides (patterns or guards) are precise enough to select the correct right-hand side is evaluated.* The (trivial *and horrible*) example: badDupEvens :: [Int] -> [Int] badDupEvens ns | even (head ns) = (head ns) : (head ns) : badDupEvens (tail ns) | otherwise = (head ns) : badDupEvens (tail ns) badDupEvens [] = [] violates that advice, and gets its just desserts: *Main> badDupEvens [0..5] [0,0,1,2,2,3,4,4,5*** Exception: Prelude.head: empty list And, (again for us beginners) a good tip to help avoid such things is to place: {-# OPTIONS_GHC -Wall #-} at the beginning of each source file. This allows the compiler to complain at me: trivialdemo.hs:12:1: Warning: Pattern match(es) are overlapped In an equation for ?badDupEvens?: badDupEvens [] = ... which (if I'm paying attention) makes me think about my patterns a bit more. For what it's worth, I tend to try to make my patterns and guards precise enough that they can prevent divergence without too much reliance on lexical ordering. I picked up that habit almost 40 years ago, thanks to Dijkstra's "guarded command" notation in *A Discipline of Programming*. I don't know to what extent that is (or isn't) idiomatic in the Haskell community. On Tue, Feb 17, 2015 at 1:42 PM, Dudley Brooks wrote: > Um ... To the other people giving hints: Don't forget that in the > sequence *of lines in the program* you have to state the base case(s) > *first*, certainly in Haskell, which goes through the lines in order, until > it finds a match. > > That's what I meant when I said "first do the base case(s), then the > rest": first *in the program order*, if not necessarily in the conceptual > structure. So for the depth-first binary tree which Joel Neely pointed > out, *first* you must deal with the base case that the node being looked at > is actually a leaf; *only then* can you deal with the fact that in general > the algorithm has the structure node>. > > So if you try bottom>, the first part will either enter an endless loop or will generate > an error, because it doesn't have a base case. (No pun on "base" intended.) > > > On 2/17/15 4:05 AM, Joel Neely wrote: > > ?Let's tweak your answers? just a bit, calling the three pegs the > "source", "goal", and "spare" pegs: > > On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben wrote: > >> - Where do I move the bottom (largest disk) ? >> >> To the last peg, which do not contain any disk then >> ? . >> > > From the source peg to the goal peg, which will > /must > not contain any disks.? > > >> ? >> >> >> - What must happen before I can move the bottom disk ? >> >> I have to move the disk which above that disk. >> > > Move everything else from ____ to ____.? > > >> >> - What must happen after I move the bottom disk ? >> >> All the other disk must be placed above that disk. >> > > ? Move everything else from ____ to ____.? > > > ?So more questions/hints: > > 1. How do you fill in the blanks? > 2. How do you put the three statements in order? > 3. How many disks does each statement talk about? > > > -jn- > ? > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 16:35:20 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 17:35:20 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4BB84.3060703@runforyourlife.org> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> Message-ID: <54E4BF48.8060107@home.nl> Oke, Im thinking of this way hanoi 3 source between end hanoi 1 source _ end = [ (source, end)] hanoi n source between end = hanoi (n-1) xxxx print move somehow. Roelof Dudley Brooks schreef op 18-2-2015 om 17:19: > There are three *locations*. But there is only one *thing* -- only > *one at a time*, that is, namely whichever one you are moving on any > given move, be it a disc or an entire stack. > > On 2/17/15 11:10 PM, Roelof Wobben wrote: >> That part I understand already. >> >> The only thing I do not see is what the base case in this exercise is >> because you are working with 3 things instead of 1 for example a list. >> >> As a example reversing a list recursive >> >> the base case is the not reversed list is empty. >> >> >> Roelof >> >> >> >> Dudley Brooks schreef op 18-2-2015 om 8:04: >>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>>> My way of working is one problem at the time. >>>>>> So first solve the itterate one and after that I gonna try to >>>>>> solve the >>>>>> recursion one. >>>>>> Otherwise I get confused. >>>>> This is the crux of the matter. You must strive to think those >>>>> thoughts >>>>> in the opposite order. Then you won't get confused. >>>>> >>>>> Recursion takes a grand simplifying view: "Are there smaller >>>>> problems of >>>>> the same kind, from the solution(s) of which we could build a >>>>> solution of >>>>> the problem at hand?" If so, let's just believe we have a solver >>>>> for the >>>>> smaller problems and build on them. This is the recursive step. >>>>> >>>>> Of course this can't be done when you are faced with the smallest >>>>> possible problem. Then you have to tell directly how to solve >>>>> it. This is the base case. >>>>> >>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>> of one disc to another post. Even more simply, it might be how >>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>> curious than the idea of 0 as a counting number.] >>>>> >>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>> All we have to do is tack x onto the head of the copy. Lo, the recipe >>>>> copy (x:xs) = x : copy xs >>>>> Final detail: when the list has no elements, there is no smaller >>>>> list to copy. We need another rule for this base case. A copy >>>>> of an empty list is empty: >>>>> copy [] = [] >>>>> >>>>> With those two rules, we're done. No iterative reasoning about >>>>> copying all the elements of the list. We can see that afterward, >>>>> but that is not how we got to the solution. >>>>> >>>>> [It has been suggested that you can understand recursion thus >>>>> > Do the first step. Then (to put it very dramatically) >>>>> > do *everything else* in *a single step*! >>>>> This point of view works for copy, and more generally for >>>>> "tail recursion", which is trivially transformable to iteration. >>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>> pattern. The "smaller problem(s)" formulation does work.] >>>> >>>> I simplified it (or over-dramatized it) to the point of >>>> not-quite-correctness. I was trying to dramatize the point of how >>>> surprising the idea of recursion is, when you first encounter it >>>> (because I suspected that the OP had not yet "grokked" the elegance >>>> of recursion) -- and remembering my own Aha! moment at recursive >>>> definitions and proofs by induction in high school algebra, back >>>> when the only "high-level" programming language was assembly. I >>>> see that I gave the mistaken impression that that's the *only* kind >>>> of recursive structure. What I should have said, less dramatically, is >>>> >>>> Do the base case(s) >>>> Then do the recursion -- whatever steps that might involve, >>>> including possibly several recursive steps and possibly even >>>> several single steps, interweaved in various possible orders. >>>> >>>> You can't *start* with the recursion, or you'll get either an >>>> infinite loop or an error. >>>> >>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>> trivial, exactly ... you still have to *do* it, after all! And >>>> when I did CS in school (a long time ago), the equivalence had only >>>> fairly recently been recognized. (By computer language designers, >>>> anyway. Maybe lambda-calculus mathematicians knew it long before >>>> that.) Certainly the idea that compilers could do it automatically >>>> was pretty new. If it were *completely* trivial, it would have >>>> been recognized long before! ;^) >>>> >>>> If you're younger you probably grew up when this idea was already >>>> commonplace. Yesterday's brilliant insight is today's trivia! >>> >>> BTW, since, as you and several others point out, the recursive >>> solution of Towers of Hanoi does *not* involve tail recursion, >>> that's why it's all the more surprising that there actually is a >>> very simple iterative solution, almost as simple to state as the >>> recursive solution, and certainly easier to understand and follow by >>> a novice or non-programmer, who doesn't think recursively. >>>> >>>>> In many harder problems a surefire way to get confused is to >>>>> try to think about the sequence of elementary steps in the final >>>>> solution. Hanoi is a good case in point. >>>>> >>>>> Eventually you will come to see recursion as a way to confidently >>>>> obtain a solution, even though the progress of the computation is >>>>> too complicated to visualize. It is not just a succinct way to >>>>> express iteration! >>>>> >>>>> Doug McIlroy >>>>> _______________________________________________ >>>>> Beginners mailing list >>>>> Beginners at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> > > From joel.neely at gmail.com Wed Feb 18 17:11:18 2015 From: joel.neely at gmail.com (Joel Neely) Date: Wed, 18 Feb 2015 11:11:18 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4BF48.8060107@home.nl> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> Message-ID: Why is 3 a special case? On Wed, Feb 18, 2015 at 10:35 AM, Roelof Wobben wrote: > Oke, > > Im thinking of this way > > hanoi 3 source between end > hanoi 1 source _ end = [ (source, end)] > hanoi n source between end = hanoi (n-1) xxxx > print move somehow. > > > Roelof > > > > > Dudley Brooks schreef op 18-2-2015 om 17:19: > >> There are three *locations*. But there is only one *thing* -- only *one >> at a time*, that is, namely whichever one you are moving on any given move, >> be it a disc or an entire stack. >> >> >> On 2/17/15 11:10 PM, Roelof Wobben wrote: >> >>> That part I understand already. >>> >>> The only thing I do not see is what the base case in this exercise is >>> because you are working with 3 things instead of 1 for example a list. >>> >>> As a example reversing a list recursive >>> >>> the base case is the not reversed list is empty. >>> >>> >>> Roelof >>> >>> >>> >>> Dudley Brooks schreef op 18-2-2015 om 8:04: >>> >>>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>> >>>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>> >>>>>> My way of working is one problem at the time. >>>>>>> So first solve the itterate one and after that I gonna try to solve >>>>>>> the >>>>>>> recursion one. >>>>>>> Otherwise I get confused. >>>>>>> >>>>>> This is the crux of the matter. You must strive to think those >>>>>> thoughts >>>>>> in the opposite order. Then you won't get confused. >>>>>> >>>>>> Recursion takes a grand simplifying view: "Are there smaller problems >>>>>> of >>>>>> the same kind, from the solution(s) of which we could build a >>>>>> solution of >>>>>> the problem at hand?" If so, let's just believe we have a solver for >>>>>> the >>>>>> smaller problems and build on them. This is the recursive step. >>>>>> >>>>>> Of course this can't be done when you are faced with the smallest >>>>>> possible problem. Then you have to tell directly how to solve >>>>>> it. This is the base case. >>>>>> >>>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>>> of one disc to another post. Even more simply, it might be how >>>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>>> curious than the idea of 0 as a counting number.] >>>>>> >>>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>>> All we have to do is tack x onto the head of the copy. Lo, the recipe >>>>>> copy (x:xs) = x : copy xs >>>>>> Final detail: when the list has no elements, there is no smaller >>>>>> list to copy. We need another rule for this base case. A copy >>>>>> of an empty list is empty: >>>>>> copy [] = [] >>>>>> >>>>>> With those two rules, we're done. No iterative reasoning about >>>>>> copying all the elements of the list. We can see that afterward, >>>>>> but that is not how we got to the solution. >>>>>> >>>>>> [It has been suggested that you can understand recursion thus >>>>>> > Do the first step. Then (to put it very dramatically) >>>>>> > do *everything else* in *a single step*! >>>>>> This point of view works for copy, and more generally for >>>>>> "tail recursion", which is trivially transformable to iteration. >>>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>>> pattern. The "smaller problem(s)" formulation does work.] >>>>>> >>>>> >>>>> I simplified it (or over-dramatized it) to the point of >>>>> not-quite-correctness. I was trying to dramatize the point of how >>>>> surprising the idea of recursion is, when you first encounter it (because I >>>>> suspected that the OP had not yet "grokked" the elegance of recursion) -- >>>>> and remembering my own Aha! moment at recursive definitions and proofs by >>>>> induction in high school algebra, back when the only "high-level" >>>>> programming language was assembly. I see that I gave the mistaken >>>>> impression that that's the *only* kind of recursive structure. What I >>>>> should have said, less dramatically, is >>>>> >>>>> Do the base case(s) >>>>> Then do the recursion -- whatever steps that might involve, >>>>> including possibly several recursive steps and possibly even several single >>>>> steps, interweaved in various possible orders. >>>>> >>>>> You can't *start* with the recursion, or you'll get either an infinite >>>>> loop or an error. >>>>> >>>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>>> trivial, exactly ... you still have to *do* it, after all! And when I did >>>>> CS in school (a long time ago), the equivalence had only fairly recently >>>>> been recognized. (By computer language designers, anyway. Maybe >>>>> lambda-calculus mathematicians knew it long before that.) Certainly the >>>>> idea that compilers could do it automatically was pretty new. If it were >>>>> *completely* trivial, it would have been recognized long before! ;^) >>>>> >>>>> If you're younger you probably grew up when this idea was already >>>>> commonplace. Yesterday's brilliant insight is today's trivia! >>>>> >>>> >>>> BTW, since, as you and several others point out, the recursive solution >>>> of Towers of Hanoi does *not* involve tail recursion, that's why it's all >>>> the more surprising that there actually is a very simple iterative >>>> solution, almost as simple to state as the recursive solution, and >>>> certainly easier to understand and follow by a novice or non-programmer, >>>> who doesn't think recursively. >>>> >>>>> >>>>> In many harder problems a surefire way to get confused is to >>>>>> try to think about the sequence of elementary steps in the final >>>>>> solution. Hanoi is a good case in point. >>>>>> >>>>>> Eventually you will come to see recursion as a way to confidently >>>>>> obtain a solution, even though the progress of the computation is >>>>>> too complicated to visualize. It is not just a succinct way to >>>>>> express iteration! >>>>>> >>>>>> Doug McIlroy >>>>>> _______________________________________________ >>>>>> Beginners mailing list >>>>>> Beginners at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>>> >>> >> >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 17:16:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 18:16:11 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> Message-ID: <54E4C8DB.6010605@home.nl> An HTML attachment was scrubbed... URL: From guthrie at mum.edu Wed Feb 18 17:22:10 2015 From: guthrie at mum.edu (Gregory Guthrie) Date: Wed, 18 Feb 2015 11:22:10 -0600 Subject: [Haskell-beginners] Beginners Digest, Vol 80, Issue 39 In-Reply-To: References: Message-ID: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6F8@MAIL.cs.mum.edu> Thank you for the clarification; I should not have included that example - but the issue is with the other names that should work as in the same example below; "import Diagrams.Prelude", import Diagrams.Backend.SVG.CmdLine, etc. ------------------------------------------- > I installed diagrams, and it seems to be there, but GHCi doesn't find it. I tried adding the > local sandbox to the command line (-package-db), but still no luck Any suggestions? > > C:\Users\guthrie> > C:\Users\guthrie>cabal install diagrams > Resolving dependencies... > All the requested packages are already installed: > diagrams-1.2 > Use --reinstall if you want to reinstall anyway. > > I find it in: > C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d (and C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3 ) > (diagrams-1.2, diagrams-contrib, -core, -lib, -svg) > > But running: "cabal repl" or using the GHC(i) flag "-package-db=...(as above)..." > fail to find it: > > C:\Users\guthrie>cabal repl > GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Diagrams.Prelude > > : > Could not find module `Diagrams.Prelude' > It is not a module in the current program, or in any known package. > Prelude> > ---------------------------------------------------------- From mwm at mired.org Wed Feb 18 17:18:43 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 18 Feb 2015 11:18:43 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4C8DB.6010605@home.nl> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> Message-ID: I think you've almost got it. Let me suggest something like: main = print $ hanoi 3 'a' 'b' 'c' hanoi n start temp end = ... for testing. On Wed, Feb 18, 2015 at 11:16 AM, Roelof Wobben wrote: > 3 is not a special case. > > I want to use the hanoi function with 3 pegs as a starting point. > > Roelof > > > > Joel Neely schreef op 18-2-2015 om 18:11: > > Why is 3 a special case? > > On Wed, Feb 18, 2015 at 10:35 AM, Roelof Wobben wrote: > >> Oke, >> >> Im thinking of this way >> >> hanoi 3 source between end >> hanoi 1 source _ end = [ (source, end)] >> hanoi n source between end = hanoi (n-1) xxxx >> print move >> somehow. >> >> >> Roelof >> >> >> >> >> Dudley Brooks schreef op 18-2-2015 om 17:19: >> >>> There are three *locations*. But there is only one *thing* -- only *one >>> at a time*, that is, namely whichever one you are moving on any given move, >>> be it a disc or an entire stack. >>> >>> >>> On 2/17/15 11:10 PM, Roelof Wobben wrote: >>> >>>> That part I understand already. >>>> >>>> The only thing I do not see is what the base case in this exercise is >>>> because you are working with 3 things instead of 1 for example a list. >>>> >>>> As a example reversing a list recursive >>>> >>>> the base case is the not reversed list is empty. >>>> >>>> >>>> Roelof >>>> >>>> >>>> >>>> Dudley Brooks schreef op 18-2-2015 om 8:04: >>>> >>>>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>>> >>>>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>>> >>>>>>> My way of working is one problem at the time. >>>>>>>> So first solve the itterate one and after that I gonna try to solve >>>>>>>> the >>>>>>>> recursion one. >>>>>>>> Otherwise I get confused. >>>>>>>> >>>>>>> This is the crux of the matter. You must strive to think those >>>>>>> thoughts >>>>>>> in the opposite order. Then you won't get confused. >>>>>>> >>>>>>> Recursion takes a grand simplifying view: "Are there smaller >>>>>>> problems of >>>>>>> the same kind, from the solution(s) of which we could build a >>>>>>> solution of >>>>>>> the problem at hand?" If so, let's just believe we have a solver for >>>>>>> the >>>>>>> smaller problems and build on them. This is the recursive step. >>>>>>> >>>>>>> Of course this can't be done when you are faced with the smallest >>>>>>> possible problem. Then you have to tell directly how to solve >>>>>>> it. This is the base case. >>>>>>> >>>>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>>>> of one disc to another post. Even more simply, it might be how >>>>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>>>> curious than the idea of 0 as a counting number.] >>>>>>> >>>>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>>>> All we have to do is tack x onto the head of the copy. Lo, the recipe >>>>>>> copy (x:xs) = x : copy xs >>>>>>> Final detail: when the list has no elements, there is no smaller >>>>>>> list to copy. We need another rule for this base case. A copy >>>>>>> of an empty list is empty: >>>>>>> copy [] = [] >>>>>>> >>>>>>> With those two rules, we're done. No iterative reasoning about >>>>>>> copying all the elements of the list. We can see that afterward, >>>>>>> but that is not how we got to the solution. >>>>>>> >>>>>>> [It has been suggested that you can understand recursion thus >>>>>>> > Do the first step. Then (to put it very dramatically) >>>>>>> > do *everything else* in *a single step*! >>>>>>> This point of view works for copy, and more generally for >>>>>>> "tail recursion", which is trivially transformable to iteration. >>>>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>>>> pattern. The "smaller problem(s)" formulation does work.] >>>>>>> >>>>>> >>>>>> I simplified it (or over-dramatized it) to the point of >>>>>> not-quite-correctness. I was trying to dramatize the point of how >>>>>> surprising the idea of recursion is, when you first encounter it (because I >>>>>> suspected that the OP had not yet "grokked" the elegance of recursion) -- >>>>>> and remembering my own Aha! moment at recursive definitions and proofs by >>>>>> induction in high school algebra, back when the only "high-level" >>>>>> programming language was assembly. I see that I gave the mistaken >>>>>> impression that that's the *only* kind of recursive structure. What I >>>>>> should have said, less dramatically, is >>>>>> >>>>>> Do the base case(s) >>>>>> Then do the recursion -- whatever steps that might involve, >>>>>> including possibly several recursive steps and possibly even several single >>>>>> steps, interweaved in various possible orders. >>>>>> >>>>>> You can't *start* with the recursion, or you'll get either an >>>>>> infinite loop or an error. >>>>>> >>>>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>>>> trivial, exactly ... you still have to *do* it, after all! And when I did >>>>>> CS in school (a long time ago), the equivalence had only fairly recently >>>>>> been recognized. (By computer language designers, anyway. Maybe >>>>>> lambda-calculus mathematicians knew it long before that.) Certainly the >>>>>> idea that compilers could do it automatically was pretty new. If it were >>>>>> *completely* trivial, it would have been recognized long before! ;^) >>>>>> >>>>>> If you're younger you probably grew up when this idea was already >>>>>> commonplace. Yesterday's brilliant insight is today's trivia! >>>>>> >>>>> >>>>> BTW, since, as you and several others point out, the recursive >>>>> solution of Towers of Hanoi does *not* involve tail recursion, that's why >>>>> it's all the more surprising that there actually is a very simple iterative >>>>> solution, almost as simple to state as the recursive solution, and >>>>> certainly easier to understand and follow by a novice or non-programmer, >>>>> who doesn't think recursively. >>>>> >>>>>> >>>>>> In many harder problems a surefire way to get confused is to >>>>>>> try to think about the sequence of elementary steps in the final >>>>>>> solution. Hanoi is a good case in point. >>>>>>> >>>>>>> Eventually you will come to see recursion as a way to confidently >>>>>>> obtain a solution, even though the progress of the computation is >>>>>>> too complicated to visualize. It is not just a succinct way to >>>>>>> express iteration! >>>>>>> >>>>>>> Doug McIlroy >>>>>>> _______________________________________________ >>>>>>> Beginners mailing list >>>>>>> Beginners at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Beginners mailing list >>>>> Beginners at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>> >>>>> >>>> >>> >>> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 17:20:58 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 18:20:58 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> Message-ID: <54E4C9FA.8090405@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 18:44:50 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 19:44:50 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4C9FA.8090405@home.nl> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> <54E4C9FA.8090405@home.nl> Message-ID: <54E4DDA2.4040507@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Feb 18 19:08:18 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 18 Feb 2015 13:08:18 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4DDA2.4040507@home.nl> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> <54E4C9FA.8090405@home.nl> <54E4DDA2.4040507@home.nl> Message-ID: Think about the three steps. Isn't it "move the top n-1 disks to temp, move the bottom disk to end, then move the top n-1 disks to the end"? Doesn't look like what your code does. BTW, you can replace the singleton list in the middle a call of "hanoi 1 ...". Not necessarily an improvement, but it makes each of the three elements have the same form. On Wed, Feb 18, 2015 at 12:44 PM, Roelof Wobben wrote: > I have now this : > > hanoi 1 start _ end = [ (start, end)] > hanoi n start temp end = hanoi (n-1) start temp end ++ [(start, temp)] ++ > hanoi (n-1) end start temp > > main = print $ hanoi 3 'a' 'b' 'c' > > and see this output : > [('a','c'),('a','b'),('c','b'),('a','b'),('c','b'),('c','a'),('b','a')] > where I was expected to see this : > [('a','c'),('a','b'),('c','b'),('a','c'),('b','a'),('b','c'),('a','c')] > > Roelof > > > > Roelof Wobben schreef op 18-2-2015 om 18:20: > > Thanks , and after the code that I have made ? > > Roelof > > > Mike Meyer schreef op 18-2-2015 om 18:18: > > I think you've almost got it. Let me suggest something like: > > main = print $ hanoi 3 'a' 'b' 'c' > > hanoi n start temp end = ... > > for testing. > > On Wed, Feb 18, 2015 at 11:16 AM, Roelof Wobben wrote: > >> 3 is not a special case. >> >> I want to use the hanoi function with 3 pegs as a starting point. >> >> Roelof >> >> >> >> Joel Neely schreef op 18-2-2015 om 18:11: >> >> Why is 3 a special case? >> >> On Wed, Feb 18, 2015 at 10:35 AM, Roelof Wobben wrote: >> >>> Oke, >>> >>> Im thinking of this way >>> >>> hanoi 3 source between end >>> hanoi 1 source _ end = [ (source, end)] >>> hanoi n source between end = hanoi (n-1) xxxx >>> print move >>> somehow. >>> >>> >>> Roelof >>> >>> >>> >>> >>> Dudley Brooks schreef op 18-2-2015 om 17:19: >>> >>>> There are three *locations*. But there is only one *thing* -- only >>>> *one at a time*, that is, namely whichever one you are moving on any given >>>> move, be it a disc or an entire stack. >>>> >>>> >>>> On 2/17/15 11:10 PM, Roelof Wobben wrote: >>>> >>>>> That part I understand already. >>>>> >>>>> The only thing I do not see is what the base case in this exercise is >>>>> because you are working with 3 things instead of 1 for example a list. >>>>> >>>>> As a example reversing a list recursive >>>>> >>>>> the base case is the not reversed list is empty. >>>>> >>>>> >>>>> Roelof >>>>> >>>>> >>>>> >>>>> Dudley Brooks schreef op 18-2-2015 om 8:04: >>>>> >>>>>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>>>> >>>>>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>>>> >>>>>>>> My way of working is one problem at the time. >>>>>>>>> So first solve the itterate one and after that I gonna try to >>>>>>>>> solve the >>>>>>>>> recursion one. >>>>>>>>> Otherwise I get confused. >>>>>>>>> >>>>>>>> This is the crux of the matter. You must strive to think those >>>>>>>> thoughts >>>>>>>> in the opposite order. Then you won't get confused. >>>>>>>> >>>>>>>> Recursion takes a grand simplifying view: "Are there smaller >>>>>>>> problems of >>>>>>>> the same kind, from the solution(s) of which we could build a >>>>>>>> solution of >>>>>>>> the problem at hand?" If so, let's just believe we have a solver >>>>>>>> for the >>>>>>>> smaller problems and build on them. This is the recursive step. >>>>>>>> >>>>>>>> Of course this can't be done when you are faced with the smallest >>>>>>>> possible problem. Then you have to tell directly how to solve >>>>>>>> it. This is the base case. >>>>>>>> >>>>>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>>>>> of one disc to another post. Even more simply, it might be how >>>>>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>>>>> curious than the idea of 0 as a counting number.] >>>>>>>> >>>>>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>>>>> All we have to do is tack x onto the head of the copy. Lo, the >>>>>>>> recipe >>>>>>>> copy (x:xs) = x : copy xs >>>>>>>> Final detail: when the list has no elements, there is no smaller >>>>>>>> list to copy. We need another rule for this base case. A copy >>>>>>>> of an empty list is empty: >>>>>>>> copy [] = [] >>>>>>>> >>>>>>>> With those two rules, we're done. No iterative reasoning about >>>>>>>> copying all the elements of the list. We can see that afterward, >>>>>>>> but that is not how we got to the solution. >>>>>>>> >>>>>>>> [It has been suggested that you can understand recursion thus >>>>>>>> > Do the first step. Then (to put it very dramatically) >>>>>>>> > do *everything else* in *a single step*! >>>>>>>> This point of view works for copy, and more generally for >>>>>>>> "tail recursion", which is trivially transformable to iteration. >>>>>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>>>>> pattern. The "smaller problem(s)" formulation does work.] >>>>>>>> >>>>>>> >>>>>>> I simplified it (or over-dramatized it) to the point of >>>>>>> not-quite-correctness. I was trying to dramatize the point of how >>>>>>> surprising the idea of recursion is, when you first encounter it (because I >>>>>>> suspected that the OP had not yet "grokked" the elegance of recursion) -- >>>>>>> and remembering my own Aha! moment at recursive definitions and proofs by >>>>>>> induction in high school algebra, back when the only "high-level" >>>>>>> programming language was assembly. I see that I gave the mistaken >>>>>>> impression that that's the *only* kind of recursive structure. What I >>>>>>> should have said, less dramatically, is >>>>>>> >>>>>>> Do the base case(s) >>>>>>> Then do the recursion -- whatever steps that might involve, >>>>>>> including possibly several recursive steps and possibly even several single >>>>>>> steps, interweaved in various possible orders. >>>>>>> >>>>>>> You can't *start* with the recursion, or you'll get either an >>>>>>> infinite loop or an error. >>>>>>> >>>>>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>>>>> trivial, exactly ... you still have to *do* it, after all! And when I did >>>>>>> CS in school (a long time ago), the equivalence had only fairly recently >>>>>>> been recognized. (By computer language designers, anyway. Maybe >>>>>>> lambda-calculus mathematicians knew it long before that.) Certainly the >>>>>>> idea that compilers could do it automatically was pretty new. If it were >>>>>>> *completely* trivial, it would have been recognized long before! ;^) >>>>>>> >>>>>>> If you're younger you probably grew up when this idea was already >>>>>>> commonplace. Yesterday's brilliant insight is today's trivia! >>>>>>> >>>>>> >>>>>> BTW, since, as you and several others point out, the recursive >>>>>> solution of Towers of Hanoi does *not* involve tail recursion, that's why >>>>>> it's all the more surprising that there actually is a very simple iterative >>>>>> solution, almost as simple to state as the recursive solution, and >>>>>> certainly easier to understand and follow by a novice or non-programmer, >>>>>> who doesn't think recursively. >>>>>> >>>>>>> >>>>>>> In many harder problems a surefire way to get confused is to >>>>>>>> try to think about the sequence of elementary steps in the final >>>>>>>> solution. Hanoi is a good case in point. >>>>>>>> >>>>>>>> Eventually you will come to see recursion as a way to confidently >>>>>>>> obtain a solution, even though the progress of the computation is >>>>>>>> too complicated to visualize. It is not just a succinct way to >>>>>>>> express iteration! >>>>>>>> >>>>>>>> Doug McIlroy >>>>>>>> _______________________________________________ >>>>>>>> Beginners mailing list >>>>>>>> Beginners at haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Beginners mailing list >>>>>> Beginners at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>> >>>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> >> >> >> -- >> Beauty of style and harmony and grace and good rhythm depend on >> simplicity. - Plato >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kc1956 at gmail.com Wed Feb 18 19:11:31 2015 From: kc1956 at gmail.com (KC) Date: Wed, 18 Feb 2015 11:11:31 -0800 Subject: [Haskell-beginners] Beginners Digest, Vol 80, Issue 39 In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6F8@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6F8@MAIL.cs.mum.edu> Message-ID: Where did you install the Haskell Platform? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Feb 18, 2015 9:18 AM, "Gregory Guthrie" wrote: > Thank you for the clarification; I should not have included that example - > but the issue is with the other names that should work as in the same > example below; > "import Diagrams.Prelude", import Diagrams.Backend.SVG.CmdLine, etc. > > ------------------------------------------- > > I installed diagrams, and it seems to be there, but GHCi doesn't find > it. I tried adding the > > local sandbox to the command line (-package-db), but still no luck Any > suggestions? > > > > C:\Users\guthrie> > > C:\Users\guthrie>cabal install diagrams > > Resolving dependencies... > > All the requested packages are already installed: > > diagrams-1.2 > > Use --reinstall if you want to reinstall anyway. > > > > I find it in: > > C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d > (and C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3 ) > > (diagrams-1.2, diagrams-contrib, -core, -lib, -svg) > > > > But running: "cabal repl" or using the GHC(i) flag "-package-db=...(as > above)..." > > fail to find it: > > > > C:\Users\guthrie>cabal repl > > GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > > Loading package ghc-prim ... linking ... done. > > Loading package integer-gmp ... linking ... done. > > Loading package base ... linking ... done. > > Prelude> :m + Diagrams.Prelude > > > > : > > Could not find module `Diagrams.Prelude' > > It is not a module in the current program, or in any known > package. > > Prelude> > > ---------------------------------------------------------- > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 20:02:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 21:02:11 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> <54E4C9FA.8090405@home.nl> <54E4DDA2.4040507@home.nl> Message-ID: <54E4EFC3.1080107@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Feb 18 20:03:51 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 18 Feb 2015 14:03:51 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E4EFC3.1080107@home.nl> References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> <54E4C9FA.8090405@home.nl> <54E4DDA2.4040507@home.nl> <54E4EFC3.1080107@home.nl> Message-ID: Yes, you're on the right track. You've got the parts put together properly, you just need to make the recursive calls and the middle move match the description you gave earlier. On Wed, Feb 18, 2015 at 2:02 PM, Roelof Wobben wrote: > pfff, tomorrow another day, > > Am I on the right track that the first hanoi is where the first step must > be done. > and the last step the move to the end is done ? > > Roelof > > > > Mike Meyer schreef op 18-2-2015 om 20:08: > > Think about the three steps. Isn't it "move the top n-1 disks to temp, > move the bottom disk to end, then move the top n-1 disks to the end"? > Doesn't look like what your code does. > > BTW, you can replace the singleton list in the middle a call of "hanoi 1 > ...". Not necessarily an improvement, but it makes each of the three > elements have the same form. > > On Wed, Feb 18, 2015 at 12:44 PM, Roelof Wobben wrote: > >> I have now this : >> >> hanoi 1 start _ end = [ (start, end)] >> hanoi n start temp end = hanoi (n-1) start temp end ++ [(start, temp)] ++ >> hanoi (n-1) end start temp >> >> main = print $ hanoi 3 'a' 'b' 'c' >> >> and see this output : >> [('a','c'),('a','b'),('c','b'),('a','b'),('c','b'),('c','a'),('b','a')] >> where I was expected to see this : >> [('a','c'),('a','b'),('c','b'),('a','c'),('b','a'),('b','c'),('a','c')] >> >> Roelof >> >> >> >> Roelof Wobben schreef op 18-2-2015 om 18:20: >> >> Thanks , and after the code that I have made ? >> >> Roelof >> >> >> Mike Meyer schreef op 18-2-2015 om 18:18: >> >> I think you've almost got it. Let me suggest something like: >> >> main = print $ hanoi 3 'a' 'b' 'c' >> >> hanoi n start temp end = ... >> >> for testing. >> >> On Wed, Feb 18, 2015 at 11:16 AM, Roelof Wobben wrote: >> >>> 3 is not a special case. >>> >>> I want to use the hanoi function with 3 pegs as a starting point. >>> >>> Roelof >>> >>> >>> >>> Joel Neely schreef op 18-2-2015 om 18:11: >>> >>> Why is 3 a special case? >>> >>> On Wed, Feb 18, 2015 at 10:35 AM, Roelof Wobben >>> wrote: >>> >>>> Oke, >>>> >>>> Im thinking of this way >>>> >>>> hanoi 3 source between end >>>> hanoi 1 source _ end = [ (source, end)] >>>> hanoi n source between end = hanoi (n-1) xxxx >>>> print move >>>> somehow. >>>> >>>> >>>> Roelof >>>> >>>> >>>> >>>> >>>> Dudley Brooks schreef op 18-2-2015 om 17:19: >>>> >>>>> There are three *locations*. But there is only one *thing* -- only >>>>> *one at a time*, that is, namely whichever one you are moving on any given >>>>> move, be it a disc or an entire stack. >>>>> >>>>> >>>>> On 2/17/15 11:10 PM, Roelof Wobben wrote: >>>>> >>>>>> That part I understand already. >>>>>> >>>>>> The only thing I do not see is what the base case in this exercise is >>>>>> because you are working with 3 things instead of 1 for example a list. >>>>>> >>>>>> As a example reversing a list recursive >>>>>> >>>>>> the base case is the not reversed list is empty. >>>>>> >>>>>> >>>>>> Roelof >>>>>> >>>>>> >>>>>> >>>>>> Dudley Brooks schreef op 18-2-2015 om 8:04: >>>>>> >>>>>>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>>>>> >>>>>>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>>>>> >>>>>>>>> My way of working is one problem at the time. >>>>>>>>>> So first solve the itterate one and after that I gonna try to >>>>>>>>>> solve the >>>>>>>>>> recursion one. >>>>>>>>>> Otherwise I get confused. >>>>>>>>>> >>>>>>>>> This is the crux of the matter. You must strive to think those >>>>>>>>> thoughts >>>>>>>>> in the opposite order. Then you won't get confused. >>>>>>>>> >>>>>>>>> Recursion takes a grand simplifying view: "Are there smaller >>>>>>>>> problems of >>>>>>>>> the same kind, from the solution(s) of which we could build a >>>>>>>>> solution of >>>>>>>>> the problem at hand?" If so, let's just believe we have a solver >>>>>>>>> for the >>>>>>>>> smaller problems and build on them. This is the recursive step. >>>>>>>>> >>>>>>>>> Of course this can't be done when you are faced with the smallest >>>>>>>>> possible problem. Then you have to tell directly how to solve >>>>>>>>> it. This is the base case. >>>>>>>>> >>>>>>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>>>>>> of one disc to another post. Even more simply, it might be how >>>>>>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>>>>>> curious than the idea of 0 as a counting number.] >>>>>>>>> >>>>>>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>>>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>>>>>> All we have to do is tack x onto the head of the copy. Lo, the >>>>>>>>> recipe >>>>>>>>> copy (x:xs) = x : copy xs >>>>>>>>> Final detail: when the list has no elements, there is no smaller >>>>>>>>> list to copy. We need another rule for this base case. A copy >>>>>>>>> of an empty list is empty: >>>>>>>>> copy [] = [] >>>>>>>>> >>>>>>>>> With those two rules, we're done. No iterative reasoning about >>>>>>>>> copying all the elements of the list. We can see that afterward, >>>>>>>>> but that is not how we got to the solution. >>>>>>>>> >>>>>>>>> [It has been suggested that you can understand recursion thus >>>>>>>>> > Do the first step. Then (to put it very dramatically) >>>>>>>>> > do *everything else* in *a single step*! >>>>>>>>> This point of view works for copy, and more generally for >>>>>>>>> "tail recursion", which is trivially transformable to iteration. >>>>>>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>>>>>> pattern. The "smaller problem(s)" formulation does work.] >>>>>>>>> >>>>>>>> >>>>>>>> I simplified it (or over-dramatized it) to the point of >>>>>>>> not-quite-correctness. I was trying to dramatize the point of how >>>>>>>> surprising the idea of recursion is, when you first encounter it (because I >>>>>>>> suspected that the OP had not yet "grokked" the elegance of recursion) -- >>>>>>>> and remembering my own Aha! moment at recursive definitions and proofs by >>>>>>>> induction in high school algebra, back when the only "high-level" >>>>>>>> programming language was assembly. I see that I gave the mistaken >>>>>>>> impression that that's the *only* kind of recursive structure. What I >>>>>>>> should have said, less dramatically, is >>>>>>>> >>>>>>>> Do the base case(s) >>>>>>>> Then do the recursion -- whatever steps that might involve, >>>>>>>> including possibly several recursive steps and possibly even several single >>>>>>>> steps, interweaved in various possible orders. >>>>>>>> >>>>>>>> You can't *start* with the recursion, or you'll get either an >>>>>>>> infinite loop or an error. >>>>>>>> >>>>>>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>>>>>> trivial, exactly ... you still have to *do* it, after all! And when I did >>>>>>>> CS in school (a long time ago), the equivalence had only fairly recently >>>>>>>> been recognized. (By computer language designers, anyway. Maybe >>>>>>>> lambda-calculus mathematicians knew it long before that.) Certainly the >>>>>>>> idea that compilers could do it automatically was pretty new. If it were >>>>>>>> *completely* trivial, it would have been recognized long before! ;^) >>>>>>>> >>>>>>>> If you're younger you probably grew up when this idea was already >>>>>>>> commonplace. Yesterday's brilliant insight is today's trivia! >>>>>>>> >>>>>>> >>>>>>> BTW, since, as you and several others point out, the recursive >>>>>>> solution of Towers of Hanoi does *not* involve tail recursion, that's why >>>>>>> it's all the more surprising that there actually is a very simple iterative >>>>>>> solution, almost as simple to state as the recursive solution, and >>>>>>> certainly easier to understand and follow by a novice or non-programmer, >>>>>>> who doesn't think recursively. >>>>>>> >>>>>>>> >>>>>>>> In many harder problems a surefire way to get confused is to >>>>>>>>> try to think about the sequence of elementary steps in the final >>>>>>>>> solution. Hanoi is a good case in point. >>>>>>>>> >>>>>>>>> Eventually you will come to see recursion as a way to confidently >>>>>>>>> obtain a solution, even though the progress of the computation is >>>>>>>>> too complicated to visualize. It is not just a succinct way to >>>>>>>>> express iteration! >>>>>>>>> >>>>>>>>> Doug McIlroy >>>>>>>>> _______________________________________________ >>>>>>>>> Beginners mailing list >>>>>>>>> Beginners at haskell.org >>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Beginners mailing list >>>>>>> Beginners at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>> >>> >>> >>> -- >>> Beauty of style and harmony and grace and good rhythm depend on >>> simplicity. - Plato >>> >>> >>> _______________________________________________ >>> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >>> >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 18 20:08:41 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 18 Feb 2015 21:08:41 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <201502170306.t1H36veW017282@coolidge.cs.dartmouth.edu> <54E437A3.9000006@runforyourlife.org> <54E43975.4040402@runforyourlife.org> <54E43AF8.4030305@home.nl> <54E4BB84.3060703@runforyourlife.org> <54E4BF48.8060107@home.nl> <54E4C8DB.6010605@home.nl> <54E4C9FA.8090405@home.nl> <54E4DDA2.4040507@home.nl> <54E4EFC3.1080107@home.nl> Message-ID: <54E4F149.1060301@home.nl> An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Thu Feb 19 01:16:18 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Wed, 18 Feb 2015 17:16:18 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> Message-ID: <54E53962.4040101@runforyourlife.org> On 2/18/15 5:34 AM, Joel Neely wrote: > I believe that the assertion that "/in the sequence *of lines in the > program* you have to state the base case(s) *first*/" is a bit too > strong, although it is certainly correct to say that termination must > be assured. For (a very trivial) example: > > dupEvens :: [Int] -> [Int] > dupEvens (n:ns) > | even n = n : n : dupEvens ns > | otherwise = n : dupEvens ns > dupEvens [] = [] > > > which behaves as: > > *Main> dupEvens [3,1,4,1,5,9,2,6] > [3,1,4,4,1,5,9,2,2,6,6] > *Main> dupEvens [0..5] > [0,0,1,2,2,3,4,4,5] > > > the base case for list recursion (the empty list) is stated last. That > is not a problem because the inductive case (non-empty list) contains > a pattern that won't match an empty list. Hmm. Well, I'd say that that's a feature of, specifically, Haskell's pattern-matching strategy and list-description syntax, rather than of recursion in general or the structure of this particular problem. In other languages with recursion you might have no choice except to start with the base case, even for this problem, or else you'd get the same kind of error you mention below (depending on the language). I think it's good when you're *learning* recursion to always start with the base case(s). > So I suggest modifying the beginners' advice to something like: > > /When evaluating a function, Haskell considers the parts of the > definition in the order they are written, top-to-bottom, and uses > the first one that matches. So make sure that your left-hand sides > (patterns or guards) are precise enough to select the correct > right-hand side is evaluated./ > > > The (trivial *and horrible*) example: > > badDupEvens :: [Int] -> [Int] > badDupEvens ns > | even (head ns) = (head ns) : (head ns) : badDupEvens (tail ns) > | otherwise = (head ns) : badDupEvens (tail ns) > badDupEvens [] = [] > > > violates that advice, and gets its just desserts: > > *Main> badDupEvens [0..5] > [0,0,1,2,2,3,4,4,5*** Exception: Prelude.head: empty list > > > And, (again for us beginners) a good tip to help avoid such things is > to place: > > {-# OPTIONS_GHC -Wall #-} > > > at the beginning of each source file. This allows the compiler to > complain at me: > > trivialdemo.hs:12:1: Warning: > Pattern match(es) are overlapped > In an equation for ?badDupEvens?: badDupEvens [] = ... > > > which (if I'm paying attention) makes me think about my patterns a bit > more. > > For what it's worth, I tend to try to make my patterns and guards > precise enough that they can prevent divergence without too much > reliance on lexical ordering. I picked up that habit almost 40 years > ago, thanks to Dijkstra's "guarded command" notation in /A Discipline > of Programming/. Always nice to hear the "pioneers" mentioned! > I don't know to what extent that is (or isn't) idiomatic in the > Haskell community. > > > > On Tue, Feb 17, 2015 at 1:42 PM, Dudley Brooks > > wrote: > > Um ... To the other people giving hints: Don't forget that in the > sequence *of lines in the program* you have to state the base > case(s) *first*, certainly in Haskell, which goes through the > lines in order, until it finds a match. > > That's what I meant when I said "first do the base case(s), then > the rest": first *in the program order*, if not necessarily in > the conceptual structure. So for the depth-first binary tree > which Joel Neely pointed out, *first* you must deal with the base > case that the node being looked at is actually a leaf; *only then* > can you deal with the fact that in general the algorithm has the > structure right descendants>. > > So if you try on bottom>, the first part will either enter an endless loop or > will generate an error, because it doesn't have a base case. (No > pun on "base" intended.) > > > On 2/17/15 4:05 AM, Joel Neely wrote: >> ? Let's tweak your answers? just a bit, calling the three pegs >> the "source", "goal", and "spare" pegs: >> >> On Tue, Feb 17, 2015 at 5:23 AM, Roelof Wobben > > wrote: >> >> - Where do I move the bottom (largest disk) ? >> >> To the last peg, which do not contain any disk then >> ? . >> >> >> From the source peg to the goal peg, which will >> /must >> not contain any disks.? >> >> ? >> >> >> - What must happen before I can move the bottom disk ? >> >> I have to move the disk which above that disk. >> >> >> Move everything else from ____ to ____.? >> >> >> - What must happen after I move the bottom disk ? >> >> All the other disk must be placed above that disk. >> >> >> ? Move everything else from ____ to ____.? >> >> ? So more questions/hints: >> >> 1. How do you fill in the blanks? >> 2. How do you put the three statements in order? >> 3. How many disks does each statement talk about? >> >> >> -jn- >> ? >> >> >> >> -- >> Beauty of style and harmony and grace and good rhythm depend on >> simplicity. - Plato >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Thu Feb 19 01:29:10 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 18 Feb 2015 19:29:10 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E53962.4040101@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> Message-ID: On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks wrote: > Hmm. Well, I'd say that that's a feature of, specifically, Haskell's > pattern-matching strategy and list-description syntax, rather than of > recursion in general or the structure of this particular problem. In other > languages with recursion you might have no choice except to start with the > base case, even for this problem, or else you'd get the same kind of error > you mention below (depending on the language). I think it's good when > you're *learning* recursion to always start with the base case(s). > > I disagree that this is a Haskell-specific feature. Any else-if like structure will have this property, no matter what language it's in. That Haskell provides a syntax as part of the function declaration is special, but that doesn't let you avoid the else-if construct when the problem requires it. It may be my fondness for proof by induction, but I think doing the base case first is a good idea for another reason. The code for the recursive cases assumes that you can correctly handle all the "smaller" cases. If that's wrong because some assumption about the base case turns out to be false when you actually write it, then you have to rewrite the recursive cases for the correct base case. So it's better to make sure your base case is going to work before you start writing the code that's going to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 19 07:11:00 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 08:11:00 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> Message-ID: <54E58C84.4070601@home.nl> An HTML attachment was scrubbed... URL: From mwm at mired.org Thu Feb 19 07:25:41 2015 From: mwm at mired.org (Mike Meyer) Date: Thu, 19 Feb 2015 01:25:41 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E58C84.4070601@home.nl> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E58C84.4070601@home.nl> Message-ID: On Thu, Feb 19, 2015 at 1:11 AM, Roelof Wobben wrote: > I think I found the answer by some trail and error, > > hanoi 1 start _ end = [ (start, end)] > hanoi n start temp end = hanoi (n-1) start end temp ++ [(start, end)] ++ > hanoi (n-1) temp start end > > main = print $ hanoi 3 'a' 'b' 'c' > I mentioned earlier that using "hanoi 1 start temp end" instead of "[(start, end)]" made things read a bit better to me. I figured out why. It isolates the final representation of a "move" to the base case only. So if you make that change, you could then write your base case as: hanoi 1 start _ end = "move 1 disk from " ++ start ++ " to " ++ end ++ ".\n" and the other case still works correctly if you used the "hanoi 1" version. You'll want to change "print" to "putStr" in main, but it will now print the list of moves in English instead of Haskell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 19 07:35:03 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 08:35:03 +0100 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E58C84.4070601@home.nl> Message-ID: <54E59227.1000800@home.nl> An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Thu Feb 19 08:56:33 2015 From: voldermort at hotmail.com (Jeremy) Date: Thu, 19 Feb 2015 08:56:33 +0000 (UTC) Subject: [Haskell-beginners] Haskell implementation of longest path algorithm Message-ID: Compared to the Nim code [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a longest path algorithm, Haskell [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks horrendously verbose and ugly, even if you ignore the pragmas and imports. Is this idiomatic Haskell style? Could it be clearer, but has to be written that way for performance - although it still takes 3.7x as long as the Nim version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md]? From dbrooks at runforyourlife.org Thu Feb 19 09:02:43 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Thu, 19 Feb 2015 01:02:43 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> Message-ID: <54E5A6B3.5040904@runforyourlife.org> On 2/18/15 5:29 PM, Mike Meyer wrote: > On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks > > wrote: > > Hmm. Well, I'd say that that's a feature of, specifically, > Haskell's pattern-matching strategy and list-description syntax, > rather than of recursion in general or the structure of this > particular problem. In other languages with recursion you might > have no choice except to start with the base case, even for this > problem, or else you'd get the same kind of error you mention > below (depending on the language). I think it's good when you're > *learning* recursion to always start with the base case(s). > > I disagree that this is a Haskell-specific feature. Any else-if like > structure will have this property, no matter what language it's in. > That Haskell provides a syntax as part of the function declaration is > special, but that doesn't let you avoid the else-if construct when the > problem requires it. I don't understand. I don't believe I said anything about avoiding else-if, or about not avoiding it. But I'm not quite sure what you mean. Are you referring to if condition1 then instruction1 elseif condition2 then instruction2 ? But what is condition1? Wouldn't it probably be the base case, and instruction1 the procedure on the base case? Is there something special about "elseif" that guarantees that instruction1 *before* it won't crash if condition1 isn't the base case??? I'm probably totally missing your intention here. But anyway, isn't it actually just Haskell's syntax "x:xs" that lets the pattern be tested and bypassed without crashing on an empty list, so that it *can* fall through to the base case at the end? If Haskell only had the syntax "(head xs), then that *would* crash on the empty list if the empty list had not previously been taken care of as a base case, as Joel Neely pointed out. I didn't mean that *no* other language might have such a syntactical construction. (I didn't mean "specifically Haskell", I meant "specifically the pattern matching". Sorry about the ambiguity.) So if some other language has such a construction, then it's still the *syntax* that lets you cheat on the base case; it's not the structure of the problem itself nor the basic underlying notion of recursion. I would also argue that in Mr Neely's first example, while the *explicit* base case [] is at the end, nevertheless the first line still *implicitly* refers to the base case: pattern matching on "x:xs" says "*if* the data has the structure x:xs", i.e. "if it is not a bunch of other stuff ... including *not the empty list*!)". Certainly you couldn't merely do the recursive step first without a condition like this particular one. The reason this syntax *seems* to let you avoid thinking about the base case first is because secretly it says "only try this step if we're not looking at the base case"! > It may be my fondness for proof by induction, but I think doing the > base case first is a good idea for another reason. The code for the > recursive cases assumes that you can correctly handle all the > "smaller" cases. If that's wrong because some assumption about the > base case turns out to be false when you actually write it, then you > have to rewrite the recursive cases for the correct base case. So it's > better to make sure your base case is going to work before you start > writing the code that's going to use it. I was a math major, not a CS major, so I'm also prejudiced in favor of base case first. And, as stated above, I think we *are* actually *considering* the base case first! (We're merely putting off telling what to *do* with that base case.) I think that the "syntactic sugar" of some languages obscures (intentionally, for purposes of convenience) what's really happening mathematically. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Thu Feb 19 12:47:02 2015 From: joel.neely at gmail.com (Joel Neely) Date: Thu, 19 Feb 2015 06:47:02 -0600 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E5A6B3.5040904@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> Message-ID: Just to clarify the point of my earlier comment... I suggest that the "separation of concerns" (SOC) principle has many applications. A common use shows up in the advice to represent each distinct concept exactly one place in the code, and to do so in a way that supports orthogonality (the freedom to mix-and-match). In this case, I used it to separate the thought process of designing the code from the lexical layout of the code. I have no business legislating the order in which someone else thinks about the cases (sometimes more than two!) encountered in decomposing a problem. However, in my experience, the order in which I think about parts of the code, and the order in which they are laid out in the source file, are separate concerns. And I have often found it useful to consider them separately. For example, in some problems (and language implementations) it may help performance to ensure that the most frequent case is considered first, especially when there are multiple cases to consider or when the distinguishing conditions are costly to evaluate. I find that making my guards (conditions) explicit allows me the freedom to order the alternatives in whatever way I find useful, without having to worry about introducing a defect in the code. Incidentally, I also find it interesting to see the subtle effects that our terminology has on the way we approach problems. Thinking of a list as "it may be empty or not" takes my thoughts in a different direction than if I think "it may have a head or not". By all means, think about your recursive functions any way you wish! Just please don't tell me that I must place them is a specific order in my code. Regards, -jn- On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks wrote: > On 2/18/15 5:29 PM, Mike Meyer wrote: > > On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks < > dbrooks at runforyourlife.org> wrote: > >> Hmm. Well, I'd say that that's a feature of, specifically, Haskell's >> pattern-matching strategy and list-description syntax, rather than of >> recursion in general or the structure of this particular problem. In other >> languages with recursion you might have no choice except to start with the >> base case, even for this problem, or else you'd get the same kind of error >> you mention below (depending on the language). I think it's good when >> you're *learning* recursion to always start with the base case(s). >> > I disagree that this is a Haskell-specific feature. Any else-if like > structure will have this property, no matter what language it's in. That > Haskell provides a syntax as part of the function declaration is special, > but that doesn't let you avoid the else-if construct when the problem > requires it. > > I don't understand. I don't believe I said anything about avoiding > else-if, or about not avoiding it. But I'm not quite sure what you mean. > Are you referring to > > if condition1 > then instruction1 > elseif condition2 > then instruction2 > > ? > > But what is condition1? Wouldn't it probably be the base case, and > instruction1 the procedure on the base case? > > Is there something special about "elseif" that guarantees that > instruction1 *before* it won't crash if condition1 isn't the base case??? > I'm probably totally missing your intention here. > > But anyway, isn't it actually just Haskell's syntax "x:xs" that lets the > pattern be tested and bypassed without crashing on an empty list, so that > it *can* fall through to the base case at the end? If Haskell only had the > syntax "(head xs), then that *would* crash on the empty list if the empty > list had not previously been taken care of as a base case, as Joel Neely > pointed out. > > I didn't mean that *no* other language might have such a syntactical > construction. (I didn't mean "specifically Haskell", I meant "specifically > the pattern matching". Sorry about the ambiguity.) So if some other > language has such a construction, then it's still the *syntax* that lets > you cheat on the base case; it's not the structure of the problem itself > nor the basic underlying notion of recursion. > > I would also argue that in Mr Neely's first example, while the *explicit* > base case [] is at the end, nevertheless the first line still *implicitly* > refers to the base case: pattern matching on "x:xs" says "*if* the data > has the structure x:xs", i.e. "if it is not a bunch of other stuff ... > including *not the empty list*!)". Certainly you couldn't merely do the > recursive step first without a condition like this particular one. The > reason this syntax *seems* to let you avoid thinking about the base case > first is because secretly it says "only try this step if we're not looking > at the base case"! > > It may be my fondness for proof by induction, but I think doing the base > case first is a good idea for another reason. The code for the recursive > cases assumes that you can correctly handle all the "smaller" cases. If > that's wrong because some assumption about the base case turns out to be > false when you actually write it, then you have to rewrite the recursive > cases for the correct base case. So it's better to make sure your base case > is going to work before you start writing the code that's going to use it. > > I was a math major, not a CS major, so I'm also prejudiced in favor of > base case first. And, as stated above, I think we *are* actually > *considering* the base case first! (We're merely putting off telling what > to *do* with that base case.) I think that the "syntactic sugar" of some > languages obscures (intentionally, for purposes of convenience) what's > really happening mathematically. > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 13:21:41 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 18:51:41 +0530 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBDBF.4020808@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> Message-ID: The trouble you're having with ghc is because you used Chars ('a', 'b', 'c') instead of Strings ("a", "b", "c") in the call to hanoi. The errors say something like: expected [Char] (String) but got Char. Also, you'll have to change the type signature (Move becomes String), but I think you took care of that already. If you are comfortable with the map function, then you can use a related function mapM_ to print lines. It basically allows you to map functions dealing with IO (and other stuff) on lists. So you can do something like main = mapM_ putStrLn $ hanoi 3 "peg 1" "peg 3" "peg 2" -- Transferring from 1 to 3 using 2 in between Hope this helps. On 19 February 2015 at 18:17, Joel Neely wrote: > Just to clarify the point of my earlier comment... > > I suggest that the "separation of concerns" (SOC) principle has many > applications. A common use shows up in the advice to represent each > distinct concept exactly one place in the code, and to do so in a way that > supports orthogonality (the freedom to mix-and-match). > > In this case, I used it to separate the thought process of designing the > code from the lexical layout of the code. > > I have no business legislating the order in which someone else thinks > about the cases (sometimes more than two!) encountered in decomposing a > problem. However, in my experience, the order in which I think about parts > of the code, and the order in which they are laid out in the source file, > are separate concerns. And I have often found it useful to consider them > separately. > > For example, in some problems (and language implementations) it may help > performance to ensure that the most frequent case is considered first, > especially when there are multiple cases to consider or when the > distinguishing conditions are costly to evaluate. > > I find that making my guards (conditions) explicit allows me the freedom > to order the alternatives in whatever way I find useful, without having to > worry about introducing a defect in the code. > > Incidentally, I also find it interesting to see the subtle effects that > our terminology has on the way we approach problems. Thinking of a list as > "it may be empty or not" takes my thoughts in a different direction than if > I think "it may have a head or not". > > By all means, think about your recursive functions any way you wish! Just > please don't tell me that I must place them is a specific order in my code. > > Regards, > -jn- > > > > On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks > wrote: > >> On 2/18/15 5:29 PM, Mike Meyer wrote: >> >> On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks < >> dbrooks at runforyourlife.org> wrote: >> >>> Hmm. Well, I'd say that that's a feature of, specifically, Haskell's >>> pattern-matching strategy and list-description syntax, rather than of >>> recursion in general or the structure of this particular problem. In other >>> languages with recursion you might have no choice except to start with the >>> base case, even for this problem, or else you'd get the same kind of error >>> you mention below (depending on the language). I think it's good when >>> you're *learning* recursion to always start with the base case(s). >>> >> I disagree that this is a Haskell-specific feature. Any else-if like >> structure will have this property, no matter what language it's in. That >> Haskell provides a syntax as part of the function declaration is special, >> but that doesn't let you avoid the else-if construct when the problem >> requires it. >> >> I don't understand. I don't believe I said anything about avoiding >> else-if, or about not avoiding it. But I'm not quite sure what you mean. >> Are you referring to >> >> if condition1 >> then instruction1 >> elseif condition2 >> then instruction2 >> >> ? >> >> But what is condition1? Wouldn't it probably be the base case, and >> instruction1 the procedure on the base case? >> >> Is there something special about "elseif" that guarantees that >> instruction1 *before* it won't crash if condition1 isn't the base case??? >> I'm probably totally missing your intention here. >> >> But anyway, isn't it actually just Haskell's syntax "x:xs" that lets the >> pattern be tested and bypassed without crashing on an empty list, so that >> it *can* fall through to the base case at the end? If Haskell only had the >> syntax "(head xs), then that *would* crash on the empty list if the empty >> list had not previously been taken care of as a base case, as Joel Neely >> pointed out. >> >> I didn't mean that *no* other language might have such a syntactical >> construction. (I didn't mean "specifically Haskell", I meant "specifically >> the pattern matching". Sorry about the ambiguity.) So if some other >> language has such a construction, then it's still the *syntax* that lets >> you cheat on the base case; it's not the structure of the problem itself >> nor the basic underlying notion of recursion. >> >> I would also argue that in Mr Neely's first example, while the *explicit* >> base case [] is at the end, nevertheless the first line still *implicitly* >> refers to the base case: pattern matching on "x:xs" says "*if* the data >> has the structure x:xs", i.e. "if it is not a bunch of other stuff ... >> including *not the empty list*!)". Certainly you couldn't merely do the >> recursive step first without a condition like this particular one. The >> reason this syntax *seems* to let you avoid thinking about the base case >> first is because secretly it says "only try this step if we're not looking >> at the base case"! >> >> It may be my fondness for proof by induction, but I think doing the >> base case first is a good idea for another reason. The code for the >> recursive cases assumes that you can correctly handle all the "smaller" >> cases. If that's wrong because some assumption about the base case turns >> out to be false when you actually write it, then you have to rewrite the >> recursive cases for the correct base case. So it's better to make sure your >> base case is going to work before you start writing the code that's going >> to use it. >> >> I was a math major, not a CS major, so I'm also prejudiced in favor of >> base case first. And, as stated above, I think we *are* actually >> *considering* the base case first! (We're merely putting off telling what >> to *do* with that base case.) I think that the "syntactic sugar" of some >> languages obscures (intentionally, for purposes of convenience) what's >> really happening mathematically. >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 19 13:50:10 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 14:50:10 +0100 Subject: [Haskell-beginners] hanoi 4 problem Message-ID: <54E5EA12.2080307@home.nl> Hello, I try now to make the optional exercise hanoi with 4 pegs, So I did on paper this : start temp1 temp2 end 3 2 1 first move : start -> temp2 start temp1 temp2 end 2 3 1 second move : start -> temp1 start temp1 temp2 end 1 2 3 now I tried to make this piece in code So I did : hanoi4 1 start _ _ end = "move 1 disk from " ++ [start] ++ " to " ++ [end] ++ ".\n" hanoi4 n start temp1 temp2 end = hanoi4 (n-1) start end temp1 temp2 ++ hanoi4 1 start end temp1 temp2 ++ hanoi4 (n-1) start temp1 end temp2 because on the first step start must be start and end must be temp1 and on the second step start must be start and end must be temp2 but when I run in I see this output : move 1 disk from a to b. move 1 disk from a to b. move 1 disk from a to b. move 1 disk from a to c. move 1 disk from a to d. move 1 disk from a to d. move 1 disk from a to d. Can anyone explain or let me see where my thinking took the wrong turn ? Roelof From r.wobben at home.nl Thu Feb 19 16:28:47 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 17:28:47 +0100 Subject: [Haskell-beginners] enumaratioin question Message-ID: <54E60F3F.4010906@home.nl> An HTML attachment was scrubbed... URL: From leza.ml at fecrd.cujae.edu.cu Thu Feb 19 16:36:51 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Thu, 19 Feb 2015 11:36:51 -0500 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: <54E60F3F.4010906@home.nl> References: <54E60F3F.4010906@home.nl> Message-ID: <54E61123.2070601@fecrd.cujae.edu.cu> Maybe you will want this: data Person = Person { name :: String, age :: Int, favThing :: String } And get the age: getAge :: Person -> Int getAge p = age p Or better: getAge = age On 02/19/2015 11:28 AM, Roelof Wobben wrote: > Hello, > > Im reading chapter 2 of the CIS 194 course about enumaratuin. > > Now they give this example : > > |-- Store a person's name, age, and favourite Thing. > data Person = Person String Int Thing > deriving Show > > brent :: Person > brent= Person "Brent" 31 SealingWax > > stan :: Person > stan= Person "Stan" 94 Cabbage > > getAge :: Person -> Int > getAge (Person _ a _)= a > > I understand how this works. > > But I wonder if there is no "better" way to get the Age. > > Is it now wise to make a person data like this : > > data Person = Name : String > | Age : Integer > | FavThing : String > > And if so , how can I get the age then ? > > Roelof > > > | > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 16:37:58 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:07:58 +0530 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: <54E60F3F.4010906@home.nl> References: <54E60F3F.4010906@home.nl> Message-ID: I can't understand what you mean by those colons in the second definition of Person. If you're thinking of type signatures, then that doesn't work in haskell. In an ADT, you give names to possible values. So "Name String" will work whereas "Name : String" won't work. data Person = Name String | Age Integer | FavThing String means that Person can be *one of* these things (which is not what you want). What you want is possible with record syntax. He'll detail it later I think. If you're interested in learning about it beforehand, look it up in the haskell wikibook (another great haskell resource). More about ADTs in general: http://en.wikibooks.org/wiki/Haskell/Type_declarations#data_and_constructor_functions The link to the specific section: http://en.wikibooks.org/wiki/Haskell/More_on_datatypes#Named_Fields_.28Record_Syntax.29 On 19 February 2015 at 21:58, Roelof Wobben wrote: > Hello, > > Im reading chapter 2 of the CIS 194 course about enumaratuin. > > Now they give this example : > > -- Store a person's name, age, and favourite Thing.data Person = Person String Int Thing > deriving Show > brent :: Person > brent = Person "Brent" 31 SealingWax > stan :: Person > stan = Person "Stan" 94 Cabbage > getAge :: Person -> Int > getAge (Person _ a _) = a > > I understand how this works. > > But I wonder if there is no "better" way to get the Age. > > Is it now wise to make a person data like this : > > data Person = Name : String > | Age : Integer > | FavThing : String > > And if so , how can I get the age then ? > > Roelof > > > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Thu Feb 19 16:38:21 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 19 Feb 2015 11:38:21 -0500 Subject: [Haskell-beginners] Package access problem In-Reply-To: <87a90bnyjs.fsf@Chladni.home> References: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E6DC@MAIL.cs.mum.edu> <87a90bnyjs.fsf@Chladni.home> Message-ID: It looks like OP tried doing ":m + Diagrams.Prelude" already... El Feb 18, 2015, a las 8:23, Daniel Bergey escribi?: > On 2015-02-18 at 02:15, Brandon Allbery wrote: >> On Tue, Feb 17, 2015 at 9:13 PM, Gregory Guthrie wrote: >> >>> : >>> >>> Could not find module `Diagrams' >> "Diagrams" is not a module in any of the packages; it's just a point in the >> namespace under which the actual modules reside. I see for example at >> http://hackage.haskell.org/package/diagrams-core > > Expanding on Brandon's answer, Diagrams.Prelude[1] is probably what you > want to import. You'll also need one of the Backends, to save files. > See for instance this minimal example: [2] > > Footnotes: > [1] http://hackage.haskell.org/package/diagrams-lib-1.2.0.8/docs/Diagrams-Prelude.html > > [2] http://projects.haskell.org/diagrams/doc/manual.html#getting-started > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From r.wobben at home.nl Thu Feb 19 16:57:54 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 17:57:54 +0100 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: References: <54E60F3F.4010906@home.nl> Message-ID: <54E61612.9060809@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 17:03:50 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:33:50 +0530 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: <54E61612.9060809@home.nl> References: <54E60F3F.4010906@home.nl> <54E61612.9060809@home.nl> Message-ID: When you use record syntax, accessors are automatically created for you. So, data Person = Person { name :: String , age :: Integer , favThing :: String } means that name, age and favThing are functions that do exactly what you want: name :: Person -> String age :: Person -> Integer favThing :: Person -> String So you just need to call age on a Person value to get the age. Due to this functionality, the names in record syntax can not start with an uppercase letter. On 19 February 2015 at 22:27, Roelof Wobben wrote: > Thanks, > > That is not what I mean , > > I mean this : > > data Person = Person > { name :: String , > Age :: Integer , > FavThing :: String } > > > and i want to get the Age I could do this : > > getAge (Person {age = ag}) = ag > > Roelof > > > Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 19-2-2015 om 17:37: > > I can't understand what you mean by those colons in the second > definition of Person. If you're thinking of type signatures, then that > doesn't work in haskell. > In an ADT, you give names to possible values. So "Name String" will work > whereas "Name : String" won't work. > > data Person = Name String > | Age Integer > | FavThing String > > means that Person can be *one of* these things (which is not what you > want). > > What you want is possible with record syntax. He'll detail it later I > think. > If you're interested in learning about it beforehand, look it up in the > haskell wikibook (another great haskell resource). > > More about ADTs in general: > http://en.wikibooks.org/wiki/Haskell/Type_declarations#data_and_constructor_functions > The link to the specific section: > http://en.wikibooks.org/wiki/Haskell/More_on_datatypes#Named_Fields_.28Record_Syntax.29 > > On 19 February 2015 at 21:58, Roelof Wobben wrote: > >> Hello, >> >> Im reading chapter 2 of the CIS 194 course about enumaratuin. >> >> Now they give this example : >> >> -- Store a person's name, age, and favourite Thing.data Person = Person String Int Thing >> deriving Show >> brent :: Person >> brent = Person "Brent" 31 SealingWax >> stan :: Person >> stan = Person "Stan" 94 Cabbage >> getAge :: Person -> Int >> getAge (Person _ a _) = a >> >> I understand how this works. >> >> But I wonder if there is no "better" way to get the Age. >> >> Is it now wise to make a person data like this : >> >> data Person = Name : String >> | Age : Integer >> | FavThing : String >> >> And if so , how can I get the age then ? >> >> Roelof >> >> >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > -- > Regards > > Sumit Sahrawat > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 19 17:17:38 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 19 Feb 2015 12:17:38 -0500 Subject: [Haskell-beginners] function to read file and return list of contents not compiling Message-ID: Haskellers: I want to write a function that takes a class name and reads from a file and then returns the list of String of the file lines. I have experimented with various return types, but GHC does not like any of them. Here is my function: readData :: String -> IO String -- what type here?? readData classNameP = do let fileName = classNameP ++ ".txt" contents <- readFile fileName lines contents Not to complain, but this would not be difficult in any other language I have tried, so I could use some explanation. I suspect it has to do with understanding the IO Monad. Many Thanks Geoffrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 19 17:20:51 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 18:20:51 +0100 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: References: <54E60F3F.4010906@home.nl> <54E61612.9060809@home.nl> Message-ID: <54E61B73.8020108@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 17:22:13 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:52:13 +0530 Subject: [Haskell-beginners] enumaratioin question In-Reply-To: <54E61B73.8020108@home.nl> References: <54E60F3F.4010906@home.nl> <54E61612.9060809@home.nl> <54E61B73.8020108@home.nl> Message-ID: Yes, "age p" gives the age of the person represented by "p". On 19 February 2015 at 22:50, Roelof Wobben wrote: > Oke, I read that part. > > Then I would be age p = ag > > Roelof > > > > Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 19-2-2015 om 18:03: > > When you use record syntax, accessors are automatically created for you. > So, > > data Person = Person { > name :: String > , age :: Integer > , favThing :: String > } > > means that name, age and favThing are functions that do exactly what you > want: > > name :: Person -> String > age :: Person -> Integer > favThing :: Person -> String > > So you just need to call age on a Person value to get the age. > Due to this functionality, the names in record syntax can not start with > an uppercase letter. > > On 19 February 2015 at 22:27, Roelof Wobben wrote: > >> Thanks, >> >> That is not what I mean , >> >> I mean this : >> >> data Person = Person >> { name :: String , >> Age :: Integer , >> FavThing :: String } >> >> >> and i want to get the Age I could do this : >> >> getAge (Person {age = ag}) = ag >> >> Roelof >> >> >> Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 19-2-2015 om >> 17:37: >> >> I can't understand what you mean by those colons in the second >> definition of Person. If you're thinking of type signatures, then that >> doesn't work in haskell. >> In an ADT, you give names to possible values. So "Name String" will work >> whereas "Name : String" won't work. >> >> data Person = Name String >> | Age Integer >> | FavThing String >> >> means that Person can be *one of* these things (which is not what you >> want). >> >> What you want is possible with record syntax. He'll detail it later I >> think. >> If you're interested in learning about it beforehand, look it up in the >> haskell wikibook (another great haskell resource). >> >> More about ADTs in general: >> http://en.wikibooks.org/wiki/Haskell/Type_declarations#data_and_constructor_functions >> The link to the specific section: >> http://en.wikibooks.org/wiki/Haskell/More_on_datatypes#Named_Fields_.28Record_Syntax.29 >> >> On 19 February 2015 at 21:58, Roelof Wobben wrote: >> >>> Hello, >>> >>> Im reading chapter 2 of the CIS 194 course about enumaratuin. >>> >>> Now they give this example : >>> >>> -- Store a person's name, age, and favourite Thing.data Person = Person String Int Thing >>> deriving Show >>> brent :: Person >>> brent = Person "Brent" 31 SealingWax >>> stan :: Person >>> stan = Person "Stan" 94 Cabbage >>> getAge :: Person -> Int >>> getAge (Person _ a _) = a >>> >>> I understand how this works. >>> >>> But I wonder if there is no "better" way to get the Age. >>> >>> Is it now wise to make a person data like this : >>> >>> data Person = Name : String >>> | Age : Integer >>> | FavThing : String >>> >>> And if so , how can I get the age then ? >>> >>> Roelof >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >>> >> >> >> -- >> Regards >> >> Sumit Sahrawat >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> > > > -- > Regards > > Sumit Sahrawat > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Thu Feb 19 17:22:25 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Thu, 19 Feb 2015 09:22:25 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> Message-ID: <54E61BD1.8040809@runforyourlife.org> And to clarify my point, I would say that mathematically you do always have to "take care of" (worry about) the base case first ... and you did! And in the code, not just in your thinking: Using "x:xs", rather than "(head xs)", in the first line acknowledges the base case by making sure to eliminate it first -- "x:xs" works precisely because it doesn't separate the *concerns*; it contains an implicit "if this is not the base case". What it does (why it's useful syntactic sugar) is let you separate (and reorder) the *actions*. A guard using "x:xs" does not actually have the very clean SOC which you recommend, with the result that the concept "base case" is actually represented in *two* places in your code. Question: Could you write it without the first line using "x:xs" or some other construction which has an implicit "if this is not the base case"? Probably yes ... probably some kind of "where" clause might put it typographically at the end. But that would be because Haskell's interpreter/compiler executes the test in the "where" clause first. Checking whether we're looking at the base case would still be the first major execution step. I suspect that there's no way to escape that ... the most that can be done is to "look like" you're escaping it. On 2/19/15 4:47 AM, Joel Neely wrote: > Just to clarify the point of my earlier comment... > > I suggest that the "separation of concerns" (SOC) principle has many > applications. A common use shows up in the advice to represent each > distinct concept exactly one place in the code, and to do so in a way > that supports orthogonality (the freedom to mix-and-match). > > In this case, I used it to separate the thought process of designing > the code from the lexical layout of the code. > > I have no business legislating the order in which someone else thinks > about the cases (sometimes more than two!) encountered in decomposing > a problem. However, in my experience, the order in which I think about > parts of the code, and the order in which they are laid out in the > source file, are separate concerns. And I have often found it useful > to consider them separately. > > For example, in some problems (and language implementations) it may > help performance to ensure that the most frequent case is considered > first, especially when there are multiple cases to consider or when > the distinguishing conditions are costly to evaluate. > > I find that making my guards (conditions) explicit allows me the > freedom to order the alternatives in whatever way I find useful, > without having to worry about introducing a defect in the code. > > Incidentally, I also find it interesting to see the subtle effects > that our terminology has on the way we approach problems. Thinking of > a list as "it may be empty or not" takes my thoughts in a different > direction than if I think "it may have a head or not". > > By all means, think about your recursive functions any way you wish! > Just please don't tell me that I must place them is a specific order > in my code. > > Regards, > -jn- > > > > On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks > > wrote: > > On 2/18/15 5:29 PM, Mike Meyer wrote: >> On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks >> > >> wrote: >> >> Hmm. Well, I'd say that that's a feature of, specifically, >> Haskell's pattern-matching strategy and list-description >> syntax, rather than of recursion in general or the structure >> of this particular problem. In other languages with >> recursion you might have no choice except to start with the >> base case, even for this problem, or else you'd get the same >> kind of error you mention below (depending on the language). >> I think it's good when you're *learning* recursion to always >> start with the base case(s). >> >> I disagree that this is a Haskell-specific feature. Any else-if >> like structure will have this property, no matter what language >> it's in. That Haskell provides a syntax as part of the function >> declaration is special, but that doesn't let you avoid the >> else-if construct when the problem requires it. > I don't understand. I don't believe I said anything about > avoiding else-if, or about not avoiding it. But I'm not quite > sure what you mean. Are you referring to > > if condition1 > then instruction1 > elseif condition2 > then instruction2 > > ? > > But what is condition1? Wouldn't it probably be the base case, > and instruction1 the procedure on the base case? > > Is there something special about "elseif" that guarantees that > instruction1 *before* it won't crash if condition1 isn't the base > case??? I'm probably totally missing your intention here. > > But anyway, isn't it actually just Haskell's syntax "x:xs" that > lets the pattern be tested and bypassed without crashing on an > empty list, so that it *can* fall through to the base case at the > end? If Haskell only had the syntax "(head xs), then that *would* > crash on the empty list if the empty list had not previously been > taken care of as a base case, as Joel Neely pointed out. > > I didn't mean that *no* other language might have such a > syntactical construction. (I didn't mean "specifically Haskell", > I meant "specifically the pattern matching". Sorry about the > ambiguity.) So if some other language has such a construction, > then it's still the *syntax* that lets you cheat on the base case; > it's not the structure of the problem itself nor the basic > underlying notion of recursion. > > I would also argue that in Mr Neely's first example, while the > *explicit* base case [] is at the end, nevertheless the first line > still *implicitly* refers to the base case: pattern matching on > "x:xs" says "*if* the data has the structure x:xs", i.e. "if it is > not a bunch of other stuff ... including *not the empty list*!)". > Certainly you couldn't merely do the recursive step first without > a condition like this particular one. The reason this syntax > *seems* to let you avoid thinking about the base case first is > because secretly it says "only try this step if we're not looking > at the base case"! >> It may be my fondness for proof by induction, but I think doing >> the base case first is a good idea for another reason. The code >> for the recursive cases assumes that you can correctly handle all >> the "smaller" cases. If that's wrong because some assumption >> about the base case turns out to be false when you actually write >> it, then you have to rewrite the recursive cases for the correct >> base case. So it's better to make sure your base case is going to >> work before you start writing the code that's going to use it. > I was a math major, not a CS major, so I'm also prejudiced in > favor of base case first. And, as stated above, I think we *are* > actually *considering* the base case first! (We're merely putting > off telling what to *do* with that base case.) I think that the > "syntactic sugar" of some languages obscures (intentionally, for > purposes of convenience) what's really happening mathematically. > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Thu Feb 19 17:23:38 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Thu, 19 Feb 2015 09:23:38 -0800 Subject: [Haskell-beginners] tower hanoi problem In-Reply-To: <54E61BD1.8040809@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> <54E61BD1.8040809@runforyourlife.org> Message-ID: <54E61C1A.3070303@runforyourlife.org> On 2/19/15 9:22 AM, Dudley Brooks wrote: > And to clarify my point, I would say that mathematically you do always > have to "take care of" (worry about) the base case first ... and you > did! And in the code, not just in your thinking: Using "x:xs", > rather than "(head xs)", in the first line acknowledges the base case > by making sure to eliminate it first -- "x:xs" works precisely because > it doesn't separate the *concerns*; it contains an implicit "if this > is not the base case". What it does (why it's useful syntactic sugar) > is let you separate (and reorder) the *actions*. A guard using "x:xs" > does not actually have the very clean SOC which you recommend, with > the result that the concept "base case" is actually represented in > *two* places in your code. > > Question: Could you write it without the first line using "x:xs" or > some other construction which has an implicit "if this is not the base > case"? Probably yes ... probably some kind of "where" clause might > put it typographically at the end. But that would be because > Haskell's interpreter/compiler executes the test in the "where" clause > first. Checking whether we're looking at the base case would still be > the first major execution step. I suspect that there's no way to > escape that ... the most that can be done is to "look like" you're > escaping it. In fact, you might say that this construction in Haskell let you separate your concerns from your actions! ;^) > On 2/19/15 4:47 AM, Joel Neely wrote: >> Just to clarify the point of my earlier comment... >> >> I suggest that the "separation of concerns" (SOC) principle has many >> applications. A common use shows up in the advice to represent each >> distinct concept exactly one place in the code, and to do so in a way >> that supports orthogonality (the freedom to mix-and-match). >> >> In this case, I used it to separate the thought process of designing >> the code from the lexical layout of the code. >> >> I have no business legislating the order in which someone else thinks >> about the cases (sometimes more than two!) encountered in decomposing >> a problem. However, in my experience, the order in which I think >> about parts of the code, and the order in which they are laid out in >> the source file, are separate concerns. And I have often found it >> useful to consider them separately. >> >> For example, in some problems (and language implementations) it may >> help performance to ensure that the most frequent case is considered >> first, especially when there are multiple cases to consider or when >> the distinguishing conditions are costly to evaluate. >> >> I find that making my guards (conditions) explicit allows me the >> freedom to order the alternatives in whatever way I find useful, >> without having to worry about introducing a defect in the code. >> >> Incidentally, I also find it interesting to see the subtle effects >> that our terminology has on the way we approach problems. Thinking of >> a list as "it may be empty or not" takes my thoughts in a different >> direction than if I think "it may have a head or not". >> >> By all means, think about your recursive functions any way you wish! >> Just please don't tell me that I must place them is a specific order >> in my code. >> >> Regards, >> -jn- >> >> >> >> On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks >> > wrote: >> >> On 2/18/15 5:29 PM, Mike Meyer wrote: >>> On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks >>> > >>> wrote: >>> >>> Hmm. Well, I'd say that that's a feature of, specifically, >>> Haskell's pattern-matching strategy and list-description >>> syntax, rather than of recursion in general or the structure >>> of this particular problem. In other languages with >>> recursion you might have no choice except to start with the >>> base case, even for this problem, or else you'd get the same >>> kind of error you mention below (depending on the >>> language). I think it's good when you're *learning* >>> recursion to always start with the base case(s). >>> >>> I disagree that this is a Haskell-specific feature. Any else-if >>> like structure will have this property, no matter what language >>> it's in. That Haskell provides a syntax as part of the function >>> declaration is special, but that doesn't let you avoid the >>> else-if construct when the problem requires it. >> I don't understand. I don't believe I said anything about >> avoiding else-if, or about not avoiding it. But I'm not quite >> sure what you mean. Are you referring to >> >> if condition1 >> then instruction1 >> elseif condition2 >> then instruction2 >> >> ? >> >> But what is condition1? Wouldn't it probably be the base case, >> and instruction1 the procedure on the base case? >> >> Is there something special about "elseif" that guarantees that >> instruction1 *before* it won't crash if condition1 isn't the base >> case??? I'm probably totally missing your intention here. >> >> But anyway, isn't it actually just Haskell's syntax "x:xs" that >> lets the pattern be tested and bypassed without crashing on an >> empty list, so that it *can* fall through to the base case at the >> end? If Haskell only had the syntax "(head xs), then that >> *would* crash on the empty list if the empty list had not >> previously been taken care of as a base case, as Joel Neely >> pointed out. >> >> I didn't mean that *no* other language might have such a >> syntactical construction. (I didn't mean "specifically Haskell", >> I meant "specifically the pattern matching". Sorry about the >> ambiguity.) So if some other language has such a construction, >> then it's still the *syntax* that lets you cheat on the base >> case; it's not the structure of the problem itself nor the basic >> underlying notion of recursion. >> >> I would also argue that in Mr Neely's first example, while the >> *explicit* base case [] is at the end, nevertheless the first >> line still *implicitly* refers to the base case: pattern >> matching on "x:xs" says "*if* the data has the structure x:xs", >> i.e. "if it is not a bunch of other stuff ... including *not the >> empty list*!)". Certainly you couldn't merely do the recursive >> step first without a condition like this particular one. The >> reason this syntax *seems* to let you avoid thinking about the >> base case first is because secretly it says "only try this step >> if we're not looking at the base case"! >>> It may be my fondness for proof by induction, but I think doing >>> the base case first is a good idea for another reason. The code >>> for the recursive cases assumes that you can correctly handle >>> all the "smaller" cases. If that's wrong because some assumption >>> about the base case turns out to be false when you actually >>> write it, then you have to rewrite the recursive cases for the >>> correct base case. So it's better to make sure your base case is >>> going to work before you start writing the code that's going to >>> use it. >> I was a math major, not a CS major, so I'm also prejudiced in >> favor of base case first. And, as stated above, I think we *are* >> actually *considering* the base case first! (We're merely >> putting off telling what to *do* with that base case.) I think >> that the "syntactic sugar" of some languages obscures >> (intentionally, for purposes of convenience) what's really >> happening mathematically. >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> >> -- >> Beauty of style and harmony and grace and good rhythm depend on >> simplicity. - Plato > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 17:25:39 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:55:39 +0530 Subject: [Haskell-beginners] function to read file and return list of contents not compiling In-Reply-To: References: Message-ID: The type should be IO [String]. You do IO, and it results in a list of Strings. Also, take a look at the following types: contents :: String lines :: String -> [String] Which means that, lines contents :: [String] But because you're dealing with a monad (IO in this case), this will not typecheck. You can convert a pure value to a monadic value using the return function: return :: Monad m => a -> m a Not specific to IO, but all monads. Hope this helps. On 19 February 2015 at 22:47, Geoffrey Bays wrote: > Haskellers: > > I want to write a function that takes a class name and reads from a file > and then returns the > list of String of the file lines. I have experimented with various return > types, but GHC does not like any of them. Here is my function: > > readData :: String -> IO String -- what type here?? > readData classNameP = do > let fileName = classNameP ++ ".txt" > contents <- readFile fileName > lines contents > > Not to complain, but this would not be difficult in any other language I > have tried, so I could use > some explanation. I suspect it has to do with understanding the IO Monad. > > Many Thanks > > Geoffrey > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 17:27:54 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:57:54 +0530 Subject: [Haskell-beginners] hanoi 4 problem In-Reply-To: <54E5EA12.2080307@home.nl> References: <54E5EA12.2080307@home.nl> Message-ID: What you did recursively is ... - Move (n - 1) from peg1 to peg3 - Move 1 from peg1 to peg3 - Move (n - 1) from peg1 to peg3 .. which is not what you want. Keep thinking, you will get it. Some things to consider: - Distribute the discs on two intermediates. - Keep track of the order in which discs are assembled on the intermediates. - Move 1 disc from peg1 to peg4. - Then, move the distributed discs back in the reverse order from how you put them there. By keeping track, I mean keep track of which peg is filled first. Hope this helps. On 19 February 2015 at 19:20, Roelof Wobben wrote: > Hello, > > I try now to make the optional exercise hanoi with 4 pegs, > > So I did on paper this : > > start temp1 temp2 end > > 3 > 2 > 1 > > first move : start -> temp2 > > start temp1 temp2 end > 2 3 > 1 > > second move : start -> temp1 > > start temp1 temp2 end > 1 2 3 > > now I tried to make this piece in code > > So I did : > > hanoi4 1 start _ _ end = "move 1 disk from " ++ [start] ++ " to " ++ > [end] ++ ".\n" > hanoi4 n start temp1 temp2 end = hanoi4 (n-1) start end temp1 temp2 ++ > hanoi4 1 start end temp1 temp2 ++ hanoi4 (n-1) start temp1 end temp2 > > because on the first step start must be start and end must be temp1 > and on the second step start must be start and end must be temp2 > > but when I run in I see this output : > > move 1 disk from a to b. > move 1 disk from a to b. > move 1 disk from a to b. > move 1 disk from a to c. > move 1 disk from a to d. > move 1 disk from a to d. > move 1 disk from a to d. > > Can anyone explain or let me see where my thinking took the wrong turn ? > > Roelof > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Thu Feb 19 17:29:00 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Thu, 19 Feb 2015 22:59:00 +0530 Subject: [Haskell-beginners] function to read file and return list of contents not compiling In-Reply-To: References: Message-ID: Thus, return (lines contents) will work. On 19 February 2015 at 22:55, Sumit Sahrawat, Maths & Computing, IIT (BHU) < sumit.sahrawat.apm13 at iitbhu.ac.in> wrote: > The type should be IO [String]. You do IO, and it results in a list of > Strings. > Also, take a look at the following types: > > contents :: String > lines :: String -> [String] > > Which means that, > > lines contents :: [String] > > But because you're dealing with a monad (IO in this case), this will not > typecheck. You can convert a pure value to a monadic value using the return > function: > > return :: Monad m => a -> m a > > Not specific to IO, but all monads. > Hope this helps. > > On 19 February 2015 at 22:47, Geoffrey Bays wrote: > >> Haskellers: >> >> I want to write a function that takes a class name and reads from a file >> and then returns the >> list of String of the file lines. I have experimented with various return >> types, but GHC does not like any of them. Here is my function: >> >> readData :: String -> IO String -- what type here?? >> readData classNameP = do >> let fileName = classNameP ++ ".txt" >> contents <- readFile fileName >> lines contents >> >> Not to complain, but this would not be difficult in any other language I >> have tried, so I could use >> some explanation. I suspect it has to do with understanding the IO Monad. >> >> Many Thanks >> >> Geoffrey >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > -- > Regards > > Sumit Sahrawat > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 19 17:30:53 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 19 Feb 2015 18:30:53 +0100 Subject: [Haskell-beginners] hanoi 4 problem In-Reply-To: References: <54E5EA12.2080307@home.nl> Message-ID: <54E61DCD.3020601@home.nl> An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Thu Feb 19 18:00:08 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Thu, 19 Feb 2015 13:00:08 -0500 Subject: [Haskell-beginners] function to read file and return list of contents not compiling In-Reply-To: References: Message-ID: Thanks. I played around some more with return and came up with this which compiles fine: readData :: String -> IO [String] readData classNameP = do let fileName = classNameP ++ ".txt" contents <- readFile fileName return $ lines contents Geoffrey On Thu, Feb 19, 2015 at 12:25 PM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > The type should be IO [String]. You do IO, and it results in a list of > Strings. > Also, take a look at the following types: > > contents :: String > lines :: String -> [String] > > Which means that, > > lines contents :: [String] > > But because you're dealing with a monad (IO in this case), this will not > typecheck. You can convert a pure value to a monadic value using the return > function: > > return :: Monad m => a -> m a > > Not specific to IO, but all monads. > Hope this helps. > > On 19 February 2015 at 22:47, Geoffrey Bays wrote: > >> Haskellers: >> >> I want to write a function that takes a class name and reads from a file >> and then returns the >> list of String of the file lines. I have experimented with various return >> types, but GHC does not like any of them. Here is my function: >> >> readData :: String -> IO String -- what type here?? >> readData classNameP = do >> let fileName = classNameP ++ ".txt" >> contents <- readFile fileName >> lines contents >> >> Not to complain, but this would not be difficult in any other language I >> have tried, so I could use >> some explanation. I suspect it has to do with understanding the IO Monad. >> >> Many Thanks >> >> Geoffrey >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > -- > Regards > > Sumit Sahrawat > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Feb 20 02:27:10 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 19 Feb 2015 21:27:10 -0500 Subject: [Haskell-beginners] tower hanoi problem Message-ID: <201502200227.t1K2RAqW020739@coolidge.cs.dartmouth.edu> On 2/19/15 4:47 AM, Joel Neely wrote: > Incidentally, I also find it interesting to see the subtle effects > that our terminology has on the way we approach problems. Thinking of > a list as "it may be empty or not" takes my thoughts in a different > direction than if I think "it may have a head or not". A telling aphorism. It will stick with me for a long time. Regarding the problem that sparked this discussion, Hanoi: if you think first about the base case, it's likely to be this: to transfer a oone-disc pile from A to B using C as an intermediate, move A to B. If you think first about the recursive step, you'll likely come up with a different base case: to transfer zero discs, do nothing. With this insight, you've generalized your original understanding of the problem. Doug From r.wobben at home.nl Fri Feb 20 07:32:17 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 20 Feb 2015 08:32:17 +0100 Subject: [Haskell-beginners] pattern matching on strings ? Message-ID: <54E6E301.4080604@home.nl> Hello, Im try to the solve the exercise which does the following : "E 2 562 help he and convert it into (Error 2) 562 "help help First I thought to split the string on the " " but according to google Haskell do not have a split function. Can I use pattern matching on some way ? Roelof From mwm at mired.org Fri Feb 20 08:00:48 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 20 Feb 2015 02:00:48 -0600 Subject: [Haskell-beginners] pattern matching on strings ? In-Reply-To: <54E6E301.4080604@home.nl> References: <54E6E301.4080604@home.nl> Message-ID: On Fri, Feb 20, 2015 at 1:32 AM, Roelof Wobben wrote: > Hello, > > Im try to the solve the exercise which does the following : > > "E 2 562 help he > > and convert it into > > (Error 2) 562 "help help > > First I thought to split the string on the " " but according to google > Haskell do not have a split function. > > Can I use pattern matching on some way ? > You can do pattern matching on lists, and strings are lists of chars, so you can always do it that way. I'm not sure what you mean by "Haskell do not have a split function". It may not have one by that name, but it has a bunch of functions for splitting up lists and strings. If you want a list of words, then words will give it to you. If you want to split it into two halves, then either span or break will do that for you. Neither discards the dividing character, since they take a predicate to determine the split rather than a value, which means the dividing character may not be obvious after the split. It's common to find that where procedural languages take a value to test against, functional ones take a predicate that does the test, as it's trivial to create a predicate to test for equality with a specific value. You might also want to look through Data.Char for interesting predicates (like isSpace) to use with those functions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Fri Feb 20 08:21:01 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Fri, 20 Feb 2015 10:21:01 +0200 Subject: [Haskell-beginners] pattern matching on strings ? In-Reply-To: <54E6E301.4080604@home.nl> References: <54E6E301.4080604@home.nl> Message-ID: Roelof, If you are working with a String type, you should remember that its just a list of chars: type String = [Char] So, you can take a look at different split functions at Data.List module. If your strings are of type Text, look at Data.Text module for split functions. Cheers. 20 ???. 2015 08:32, ?????????? "Roelof Wobben" ???????: > Hello, > > Im try to the solve the exercise which does the following : > > "E 2 562 help he > > and convert it into > > (Error 2) 562 "help help > > First I thought to split the string on the " " but according to google > Haskell do not have a split function. > > Can I use pattern matching on some way ? > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raabe at froglogic.com Fri Feb 20 08:50:10 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Fri, 20 Feb 2015 09:50:10 +0100 Subject: [Haskell-beginners] =?utf-8?q?pattern_matching_on_strings_=3F?= In-Reply-To: <54E6E301.4080604@home.nl> References: <54E6E301.4080604@home.nl> Message-ID: On 2015-02-20 08:32, Roelof Wobben wrote: > Im try to the solve the exercise which does the following : > > "E 2 562 help he > > and convert it into > > (Error 2) 562 "help help > > First I thought to split the string on the " " but according to google > Haskell do not have a split function. > > Can I use pattern matching on some way ? Instead of using Google, I suggest to first think about this in terms of types. You're looking for a function which can turn a string into a list of strings, i.e. String -> [String] You can feed types like this to Hoogle ( http://www.haskell.org/hoogle ) to get function which match that type. Searching for the above type signature yields some very relevant hits. :-) -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From hjgtuyl at chello.nl Fri Feb 20 10:53:28 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 20 Feb 2015 11:53:28 +0100 Subject: [Haskell-beginners] pattern matching on strings ? In-Reply-To: <54E6E301.4080604@home.nl> References: <54E6E301.4080604@home.nl> Message-ID: On Fri, 20 Feb 2015 08:32:17 +0100, Roelof Wobben wrote: > First I thought to split the string on the " " but according to google > Haskell do not have a split function. If you use Hoogle[0] instead of Google, you will find that there are many split functions in Haskell libraries. Another Haskell package search engine is Hayoo[1]; Hayoo searches more packages, but Hoogle has the advantage that you can enter the type of a function that you are looking for. Met vriendelijke groet, Henk-Jan van Tuyl [0] https://www.fpcomplete.com/hoogle?q=split [1] http://hayoo.fh-wedel.de/ -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From chaddai.fouche at gmail.com Fri Feb 20 12:40:57 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Fri, 20 Feb 2015 13:40:57 +0100 Subject: [Haskell-beginners] pattern matching on strings ? In-Reply-To: References: <54E6E301.4080604@home.nl> Message-ID: > > On Fri, 20 Feb 2015 08:32:17 +0100, Roelof Wobben > wrote: > > First I thought to split the string on the " " but according to google >> Haskell do not have a split function. > > As others have already said, Haskell does in fact have a "split on spaces" function (words), and several others flavors of splitting that makes it possible to dissect your list as you wish. If you still want a split function ala Perl, there is a solid "split " package on hackage which propose several standard function and a very configurable generic version of the split concept for all lists. Also, Data.Text comes with several splitting functions for use with the Text datatype. -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 20 14:30:44 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 20 Feb 2015 15:30:44 +0100 Subject: [Haskell-beginners] pattern matching on strings ? In-Reply-To: References: <54E6E301.4080604@home.nl> Message-ID: <54E74514.5030103@home.nl> An HTML attachment was scrubbed... URL: From stuart.hungerford at gmail.com Fri Feb 20 23:58:36 2015 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Sat, 21 Feb 2015 10:58:36 +1100 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? Message-ID: Hi, I'm experimenting with Haskell typeclasses and could do with some advice on managing superclasses and instance declarations. Suppose I have these modules (please ignore any misunderstandings of abstract algebra concepts): -- in Semigroup.hs class Semigroup a where (|.|) :: a -> a -> a instance Semigroup Integer where (|.|) = (+) -- In Monoid.hs class (Semigroup a) => Monoid a where identity :: a instance Monoid Integer where identity = 0 -- In Group.hs class (Monoid a) => Group a where inverse :: a -> a instance Group Integer where (|.|) = (+) identity = 0 inverse = (-) In Group.hs I'm trying to create an (additive) group instance for Integer values but GHC complains that (|.|) and identity are not "visible" typeclass methods. I understand that if I explicitly recreate Semigroup and Monoid instances for Integer in Group.hs it will fix the visibility issue--at the cost of duplicating the instances already defined in Semigroup.hs and Monoid.hs. I'm starting to wonder whether it's a good idea to create typeclass instances in the same modules as the typeclass definitions? In my case I could create a separate Instances.hs with the instance declarations but how do Haskellers generally handle this situation? Thanks, Stu From michael at orlitzky.com Sat Feb 21 03:09:45 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Fri, 20 Feb 2015 22:09:45 -0500 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? In-Reply-To: References: Message-ID: <54E7F6F9.7050402@orlitzky.com> On 02/20/2015 06:58 PM, Stuart Hungerford wrote: > Hi, > > I'm experimenting with Haskell typeclasses and could do with some > advice on managing superclasses and instance declarations. Suppose I > have these modules (please ignore any misunderstandings of abstract > algebra concepts): > > -- in Semigroup.hs > > class Semigroup a where > (|.|) :: a -> a -> a > > instance Semigroup Integer where > (|.|) = (+) > > > -- In Monoid.hs > > class (Semigroup a) => Monoid a where > identity :: a > > instance Monoid Integer where > identity = 0 > > > -- In Group.hs > > class (Monoid a) => Group a where > inverse :: a -> a > > instance Group Integer where > (|.|) = (+) > identity = 0 > inverse = (-) > > > In Group.hs I'm trying to create an (additive) group instance for > Integer values but GHC complains that (|.|) and identity are not > "visible" typeclass methods. You only get one instance per type, so the Semigroup/Monoid instances for Integer are "set in stone." When you "import Semigroup" and "import Monoid", those instances come into scope. So in Group.hs, '|.|' and 'identity' are already defined for Integer. All you need is, instance Group Integer where inverse = negate To add different instances, you'll need a newtype wrapper around Integer. From joel.neely at gmail.com Sat Feb 21 15:50:22 2015 From: joel.neely at gmail.com (Joel Neely) Date: Sat, 21 Feb 2015 09:50:22 -0600 Subject: [Haskell-beginners] Fwd: tower hanoi problem In-Reply-To: <54E605D9.6010604@runforyourlife.org> References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> <54E605D9.6010604@runforyourlife.org> Message-ID: I personally find the assertion more confusing than helpful. Interpreting a pattern of "x:xs" as "acknowledging the base case" by eliminating it first reads to me as a double negative: "if it is not the case that this list does not have a first element" or some such. I simply prefer to read it as a positive assertion: the list has a head, and here's what to do with it. To my eye, this also scales nicely when there are multiple terminal cases. Here's a tiny example. Given a list of fractional numbers, produce a smoothed list, where each value is averaged with its immediate neighbors (except the first and last, which fail to have both neighbors), as shown below. [0.0,4.0,2.0,6.0,1.0,2.0] [ 2.0,4.0,3.0,3.0 ] It seems natural to my eye to express this as, "A list with at least three elements contributes a value to the result", as in: smooth :: Fractional n => [n] -> [n] smooth (a:z@(b:c:_)) = (a + b + c) / 3 : smooth z smooth _ = [] I prefer this to the alternatives (at least the ones that I came up with) that either explicitly compute the length to compare it to 3, or that explicitly fret over the (multiple!) cases that terminate the recursion. smooth' :: Fractional n => [n] -> [n] smooth' [] = [] smooth' [_] = [] smooth' [_,_] = [] smooth' (a:z@(b:c:_)) = (a + b + c) / 3 : smooth' z I don't care for having to wade through three terminal cases to get to the one that interests me, for multiple reasons: - It strikes my eye as visual noise that offers no useful information compared to the first (shorter) solution. - Depending on the intelligence of the compiler, it may waste run time by testing for cases that will only be true near the end of a long argument list. - I can argue termination by observing that the recursive evaluation (smooth z) is made on a shorter argument. - In a lazy language, termination may not be an issue! Evaluating *Main> take 10 $ smooth [0,1..] [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0] works just fine without smooth having to arrive at the end of its argument. Again, tastes may vary. I haven't thought of a way to do this with a fold or comprehension that seems as clear to me. I would be interested in seeing such a solution if someone else sees a way to do it. -jn- ---------- Forwarded message ---------- From: Dudley Brooks Date: Thu, Feb 19, 2015 at 9:48 AM Subject: Re: [Haskell-beginners] tower hanoi problem To: Joel Neely And to clarify my point, I would say that mathematically you do always have to "take care of" (worry about) the base case first ... and you did! And in the code, not just in your thinking: Using "x:xs", rather than "(head xs)", in the first line acknowledges the base case by making sure to eliminate it first -- "x:xs" works precisely because it doesn't separate the *concerns*; it contains an implicit "if this is not the base case". What it does (why it's useful syntactic sugar) is let you separate (and reorder) the *actions*. A guard using "x:xs" does not actually have the very clean SOC which you recommend, with the result that the concept "base case" is actually represented in *two* places in your code. Question: Could you write it without the first line using "x:xs" or some other construction which has an implicit "if this is not the base case"? Probably yes ... probably some kind of "where" clause might put it typographically at the end. But that would be because Haskell's interpreter/compiler executes the test in the "where" clause first. Checking whether we're looking at the base case would still be the first major execution step. I suspect that there's no way to escape that ... the most that can be done is to "look like" you're escaping it. On 2/19/15 4:47 AM, Joel Neely wrote: Just to clarify the point of my earlier comment... I suggest that the "separation of concerns" (SOC) principle has many applications. A common use shows up in the advice to represent each distinct concept exactly one place in the code, and to do so in a way that supports orthogonality (the freedom to mix-and-match). In this case, I used it to separate the thought process of designing the code from the lexical layout of the code. I have no business legislating the order in which someone else thinks about the cases (sometimes more than two!) encountered in decomposing a problem. However, in my experience, the order in which I think about parts of the code, and the order in which they are laid out in the source file, are separate concerns. And I have often found it useful to consider them separately. For example, in some problems (and language implementations) it may help performance to ensure that the most frequent case is considered first, especially when there are multiple cases to consider or when the distinguishing conditions are costly to evaluate. I find that making my guards (conditions) explicit allows me the freedom to order the alternatives in whatever way I find useful, without having to worry about introducing a defect in the code. Incidentally, I also find it interesting to see the subtle effects that our terminology has on the way we approach problems. Thinking of a list as "it may be empty or not" takes my thoughts in a different direction than if I think "it may have a head or not". By all means, think about your recursive functions any way you wish! Just please don't tell me that I must place them is a specific order in my code. Regards, -jn- On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks wrote: > On 2/18/15 5:29 PM, Mike Meyer wrote: > > On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks < > dbrooks at runforyourlife.org> wrote: > >> Hmm. Well, I'd say that that's a feature of, specifically, Haskell's >> pattern-matching strategy and list-description syntax, rather than of >> recursion in general or the structure of this particular problem. In other >> languages with recursion you might have no choice except to start with the >> base case, even for this problem, or else you'd get the same kind of error >> you mention below (depending on the language). I think it's good when >> you're *learning* recursion to always start with the base case(s). >> > I disagree that this is a Haskell-specific feature. Any else-if like > structure will have this property, no matter what language it's in. That > Haskell provides a syntax as part of the function declaration is special, > but that doesn't let you avoid the else-if construct when the problem > requires it. > > I don't understand. I don't believe I said anything about avoiding > else-if, or about not avoiding it. But I'm not quite sure what you mean. > Are you referring to > > if condition1 > then instruction1 > elseif condition2 > then instruction2 > > ? > > But what is condition1? Wouldn't it probably be the base case, and > instruction1 the procedure on the base case? > > Is there something special about "elseif" that guarantees that > instruction1 *before* it won't crash if condition1 isn't the base case??? > I'm probably totally missing your intention here. > > But anyway, isn't it actually just Haskell's syntax "x:xs" that lets the > pattern be tested and bypassed without crashing on an empty list, so that > it *can* fall through to the base case at the end? If Haskell only had the > syntax "(head xs), then that *would* crash on the empty list if the empty > list had not previously been taken care of as a base case, as Joel Neely > pointed out. > > I didn't mean that *no* other language might have such a syntactical > construction. (I didn't mean "specifically Haskell", I meant "specifically > the pattern matching". Sorry about the ambiguity.) So if some other > language has such a construction, then it's still the *syntax* that lets > you cheat on the base case; it's not the structure of the problem itself > nor the basic underlying notion of recursion. > > I would also argue that in Mr Neely's first example, while the *explicit* > base case [] is at the end, nevertheless the first line still *implicitly* > refers to the base case: pattern matching on "x:xs" says "*if* the data > has the structure x:xs", i.e. "if it is not a bunch of other stuff ... > including *not the empty list*!)". Certainly you couldn't merely do the > recursive step first without a condition like this particular one. The > reason this syntax *seems* to let you avoid thinking about the base case > first is because secretly it says "only try this step if we're not looking > at the base case"! > > It may be my fondness for proof by induction, but I think doing the base > case first is a good idea for another reason. The code for the recursive > cases assumes that you can correctly handle all the "smaller" cases. If > that's wrong because some assumption about the base case turns out to be > false when you actually write it, then you have to rewrite the recursive > cases for the correct base case. So it's better to make sure your base case > is going to work before you start writing the code that's going to use it. > > I was a math major, not a CS major, so I'm also prejudiced in favor of > base case first. And, as stated above, I think we *are* actually > *considering* the base case first! (We're merely putting off telling what > to *do* with that base case.) I think that the "syntactic sugar" of some > languages obscures (intentionally, for purposes of convenience) what's > really happening mathematically. > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Sat Feb 21 18:04:16 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sat, 21 Feb 2015 19:04:16 +0100 Subject: [Haskell-beginners] Fwd: tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> <54E605D9.6010604@runforyourlife.org> Message-ID: On Sat, Feb 21, 2015 at 4:50 PM, Joel Neely wrote: > Given a list of fractional numbers, produce a smoothed list, where each > value is averaged with its immediate neighbors (except the first and last, > which fail to have both neighbors), as shown below. > > [0.0,4.0,2.0,6.0,1.0,2.0] > [ 2.0,4.0,3.0,3.0 ] > > > It seems natural to my eye to express this as, "A list with at least three > elements contributes a value to the result", as in: > > smooth :: Fractional n => [n] -> [n] > smooth (a:z@(b:c:_)) = (a + b + c) / 3 : smooth z > smooth _ = [] > > > In Haskell, I would write this with higher-order functions though : smooth xs = zipWith3 (\a b c -> (a+b+c)/3) xs (drop 1 xs) (drop 2 xs) -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrooks at runforyourlife.org Sat Feb 21 19:19:18 2015 From: dbrooks at runforyourlife.org (Dudley Brooks) Date: Sat, 21 Feb 2015 11:19:18 -0800 Subject: [Haskell-beginners] Fwd: tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> <54E605D9.6010604@runforyourlife.org> Message-ID: <54E8DA36.3010505@runforyourlife.org> I guess I should refine my comment to say that *by the time the computer is actually executing the computation* (i.e. not in the programming stage), the base cases *must* be eliminated first, or the execution *will* either crash or enter an infinite loop when it encounters them. Certainly your point is correct, that languages like Haskell let you arrange this differently typologically and "conceptually". But I stand by my claim that the very reason you are able to do so is because the pattern is an implicit "if" statement: "If the input has the pattern a:z@(b:c:_) ... and therefore does not have any other pattern ... including the pattern of the base cases"! In testing what something is, you are also testing that it is not anything else. This may not be important to your thinking as a programmer, but it's definitely important to the computer. The first statement *does* eliminate the base cases (among many others which it eliminates). There could be lots of other first lines you could write which would *not* work, precisely because they don't eliminate the base cases. (As in the "bad" example you showed for comparison in the previous response.) You're certainly right about the fact that with lazy evaluation the base cases might never be reached (depending on what *subsequent* function calls this one). Nevertheless, your first line still *is* testing for (not) the base cases. So Haskell-like languages definitely give you the ability to "present" the algorithm in ways that are more intuitive for you (and possibly more efficient, too, as you point out) -- which is great! That's what high-level languages should do. But it doesn't give you a way to do so without the first line *somehow* taking care of the base cases, even if only by temporarily shunting them aside. At heart, the rearrangement really just changes If you're looking at the base case then process the base case else process the recursive case into if you're not looking at the base case then process the recursive case else process the base case. (Leaving out details ... including cases which are neither the base cases nor the recursive cases.) So you actually *did* program testing for the base cases first ... possibly without even thinking about that fact, because Haskell, being a very high-level language, did some of the thinking for you! ;^) Perhaps I'm speaking more like a language designer (which I certainly don't happen to be, btw) than like a language user. On 2/21/15 7:50 AM, Joel Neely wrote: > I personally find the assertion more confusing than helpful. > Interpreting a pattern of "x:xs" as "acknowledging the base case" by > eliminating it first reads to me as a double negative: "if it is not > the case that this list does not have a first element" or some such. > > I simply prefer to read it as a positive assertion: the list has a > head, and here's what to do with it. More precisely: "IF the list has a head, THEN here's what to do with it". Pattern matching is not an assertion, it's a test. > To my eye, this also scales nicely when there are multiple terminal > cases. Here's a tiny example. > > Given a list of fractional numbers, produce a smoothed list, where > each value is averaged with its immediate neighbors (except the first > and last, which fail to have both neighbors), as shown below. > > [0.0,4.0,2.0,6.0,1.0,2.0] > [ 2.0,4.0,3.0,3.0 ] > > > It seems natural to my eye to express this as, "A list with at least > three elements contributes a value to the result", as in: > > smooth :: Fractional n => [n] -> [n] > smooth (a:z@(b:c:_)) = (a + b + c) / 3 : smooth z > smooth _ = [] > Yes, this is definitely more elegant. BTW -- notice that here the first "[n]" also does part of the job that otherwise the first line would have to do, namely eliminate the bad cases (not even a list) that the first line would otherwise have to eliminate in languages without type checking. Once again, Haskell -- maybe *because* it's a high-level language? -- does not *quite* have a really clear SOC! (I'm treating "is it safe to do the recursion?" as *one* concern. But probably the question "are the concerns well separated?" is rather subjective.) > I prefer this to the alternatives (at least the ones that I came up > with) that either explicitly compute the length to compare it to 3, or > that explicitly fret over the (multiple!) cases that terminate the > recursion. > > smooth' :: Fractional n => [n] -> [n] > smooth' [] = [] > smooth' [_] = [] > smooth' [_,_] = [] > smooth' (a:z@(b:c:_)) = (a + b + c) / 3 : smooth' z > > > I don't care for having to wade through three terminal cases to get to > the one that interests me, for multiple reasons: > > * It strikes my eye as visual noise that offers no useful > information compared to the first (shorter) solution. > * Depending on the intelligence of the compiler, it may waste run > time by testing for cases that will only be true near the end of a > long argument list. > * I can argue termination by observing that the recursive evaluation > (smooth z) is made on a shorter argument. > * In a lazy language, termination may not be an issue! > > Evaluating > > *Main> take 10 $ smooth [0,1..] > [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0] > > > works just fine without smoothhaving to arrive at the end of its argument. > > Again, tastes may vary. > > I haven't thought of a way to do this with a fold or comprehension > that seems as clear to me. I would be interested in seeing such a > solution if someone else sees a way to do it. > > -jn- > > > ---------- Forwarded message ---------- > From: *Dudley Brooks* > > Date: Thu, Feb 19, 2015 at 9:48 AM > Subject: Re: [Haskell-beginners] tower hanoi problem > To: Joel Neely > > > > And to clarify my point, I would say that mathematically you do always > have to "take care of" (worry about) the base case first ... and you > did! And in the code, not just in your thinking: Using "x:xs", > rather than "(head xs)", in the first line acknowledges the base case > by making sure to eliminate it first -- "x:xs" works precisely because > it doesn't separate the *concerns*; it contains an implicit "if this > is not the base case". What it does (why it's useful syntactic sugar) > is let you separate (and reorder) the *actions*. A guard using "x:xs" > does not actually have the very clean SOC which you recommend, with > the result that the concept "base case" is actually represented in > *two* places in your code. > > Question: Could you write it without the first line using "x:xs" or > some other construction which has an implicit "if this is not the base > case"? Probably yes ... probably some kind of "where" clause might > put it typographically at the end. But that would be because > Haskell's interpreter/compiler executes the test in the "where" clause > first. Checking whether we're looking at the base case would still be > the first major execution step. I suspect that there's no way to > escape that ... the most that can be done is to "look like" you're > escaping it. > > > On 2/19/15 4:47 AM, Joel Neely wrote: >> Just to clarify the point of my earlier comment... >> >> I suggest that the "separation of concerns" (SOC) principle has many >> applications. A common use shows up in the advice to represent each >> distinct concept exactly one place in the code, and to do so in a way >> that supports orthogonality (the freedom to mix-and-match). >> >> In this case, I used it to separate the thought process of designing >> the code from the lexical layout of the code. >> >> I have no business legislating the order in which someone else thinks >> about the cases (sometimes more than two!) encountered in decomposing >> a problem. However, in my experience, the order in which I think >> about parts of the code, and the order in which they are laid out in >> the source file, are separate concerns. And I have often found it >> useful to consider them separately. >> >> For example, in some problems (and language implementations) it may >> help performance to ensure that the most frequent case is considered >> first, especially when there are multiple cases to consider or when >> the distinguishing conditions are costly to evaluate. >> >> I find that making my guards (conditions) explicit allows me the >> freedom to order the alternatives in whatever way I find useful, >> without having to worry about introducing a defect in the code. >> >> Incidentally, I also find it interesting to see the subtle effects >> that our terminology has on the way we approach problems. Thinking of >> a list as "it may be empty or not" takes my thoughts in a different >> direction than if I think "it may have a head or not". >> >> By all means, think about your recursive functions any way you wish! >> Just please don't tell me that I must place them is a specific order >> in my code. >> >> Regards, >> -jn- >> >> >> >> On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks >> > wrote: >> >> On 2/18/15 5:29 PM, Mike Meyer wrote: >>> On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks >>> > >>> wrote: >>> >>> Hmm. Well, I'd say that that's a feature of, specifically, >>> Haskell's pattern-matching strategy and list-description >>> syntax, rather than of recursion in general or the structure >>> of this particular problem. In other languages with >>> recursion you might have no choice except to start with the >>> base case, even for this problem, or else you'd get the same >>> kind of error you mention below (depending on the >>> language). I think it's good when you're *learning* >>> recursion to always start with the base case(s). >>> >>> I disagree that this is a Haskell-specific feature. Any else-if >>> like structure will have this property, no matter what language >>> it's in. That Haskell provides a syntax as part of the function >>> declaration is special, but that doesn't let you avoid the >>> else-if construct when the problem requires it. >> I don't understand. I don't believe I said anything about >> avoiding else-if, or about not avoiding it. But I'm not quite >> sure what you mean. Are you referring to >> >> if condition1 >> then instruction1 >> elseif condition2 >> then instruction2 >> >> ? >> >> But what is condition1? Wouldn't it probably be the base case, >> and instruction1 the procedure on the base case? >> >> Is there something special about "elseif" that guarantees that >> instruction1 *before* it won't crash if condition1 isn't the base >> case??? I'm probably totally missing your intention here. >> >> But anyway, isn't it actually just Haskell's syntax "x:xs" that >> lets the pattern be tested and bypassed without crashing on an >> empty list, so that it *can* fall through to the base case at the >> end? If Haskell only had the syntax "(head xs), then that >> *would* crash on the empty list if the empty list had not >> previously been taken care of as a base case, as Joel Neely >> pointed out. >> >> I didn't mean that *no* other language might have such a >> syntactical construction. (I didn't mean "specifically Haskell", >> I meant "specifically the pattern matching". Sorry about the >> ambiguity.) So if some other language has such a construction, >> then it's still the *syntax* that lets you cheat on the base >> case; it's not the structure of the problem itself nor the basic >> underlying notion of recursion. >> >> I would also argue that in Mr Neely's first example, while the >> *explicit* base case [] is at the end, nevertheless the first >> line still *implicitly* refers to the base case: pattern >> matching on "x:xs" says "*if* the data has the structure x:xs", >> i.e. "if it is not a bunch of other stuff ... including *not the >> empty list*!)". Certainly you couldn't merely do the recursive >> step first without a condition like this particular one. The >> reason this syntax *seems* to let you avoid thinking about the >> base case first is because secretly it says "only try this step >> if we're not looking at the base case"! >>> It may be my fondness for proof by induction, but I think doing >>> the base case first is a good idea for another reason. The code >>> for the recursive cases assumes that you can correctly handle >>> all the "smaller" cases. If that's wrong because some assumption >>> about the base case turns out to be false when you actually >>> write it, then you have to rewrite the recursive cases for the >>> correct base case. So it's better to make sure your base case is >>> going to work before you start writing the code that's going to >>> use it. >> I was a math major, not a CS major, so I'm also prejudiced in >> favor of base case first. And, as stated above, I think we *are* >> actually *considering* the base case first! (We're merely putting >> off telling what to *do* with that base case.) I think that the >> "syntactic sugar" of some languages obscures (intentionally, for >> purposes of convenience) what's really happening mathematically. >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> >> -- >> Beauty of style and harmony and grace and good rhythm depend on >> simplicity. - Plato > > > > > -- > Beauty of style and harmony and grace and good rhythm depend on > simplicity. - Plato > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.hungerford at gmail.com Sat Feb 21 21:15:53 2015 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Sun, 22 Feb 2015 08:15:53 +1100 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? Message-ID: >> -- in Semigroup.hs >> >> class Semigroup a where >> (|.|) :: a -> a -> a >> >> instance Semigroup Integer where >> (|.|) = (+) >> >> >> -- In Monoid.hs >> >> class (Semigroup a) => Monoid a where >> identity :: a >> >> instance Monoid Integer where >> identity = 0 >> >> >> -- In Group.hs >> >> class (Monoid a) => Group a where >> inverse :: a -> a >> >> instance Group Integer where >> (|.|) = (+) >> identity = 0 >> inverse = (-) >> >> >> In Group.hs I'm trying to create an (additive) group instance for >> Integer values but GHC complains that (|.|) and identity are not >> "visible" typeclass methods. > > You only get one instance per type, so the Semigroup/Monoid instances > for Integer are "set in stone." When you "import Semigroup" and "import > Monoid", those instances come into scope. So in Group.hs, '|.|' and > 'identity' are already defined for Integer. All you need is, > > instance Group Integer where > inverse = negate Thanks for that insight. Ignoring the instance issue for a minute, suppose I wanted to define a typeclass Additive where I'd like to set default implementations for the methods: class (Num a, Group a) => Additive a where (|.|) = (+) -- etc... In this situation GHC says (|.|) is not a visible method. If I add a type declaration for (|.|) am I effectively "shadowing" the method from Semigroup with a new method rather than supplying a default implementation? Thanks, Stu From michael at orlitzky.com Sat Feb 21 23:44:21 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Sat, 21 Feb 2015 18:44:21 -0500 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? In-Reply-To: References: Message-ID: <54E91855.7060803@orlitzky.com> On 02/21/2015 04:15 PM, Stuart Hungerford wrote: > > Thanks for that insight. Ignoring the instance issue for a minute, > suppose I wanted to define a typeclass Additive where I'd like to set > default implementations for the methods: > > class (Num a, Group a) => Additive a where > (|.|) = (+) > > -- etc... > > In this situation GHC says (|.|) is not a visible method. If I add a > type declaration for (|.|) am I effectively "shadowing" the method > from Semigroup with a new method rather than supplying a default > implementation? > I don't think you can do that, but I wouldn't swear to it. One problem would be that you could declare a Semigroup instance of Integer independently of the Additive instance, and GHC would have to choose which operation to use. In this case Additive is more specific than Semigroup, but my instinct would be to prefer the Semigroup "override." I think some of these things are addresses in, https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses but I've never made it through the whole document =) From allbery.b at gmail.com Sun Feb 22 00:04:02 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 21 Feb 2015 19:04:02 -0500 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? In-Reply-To: <54E91855.7060803@orlitzky.com> References: <54E91855.7060803@orlitzky.com> Message-ID: On Sat, Feb 21, 2015 at 6:44 PM, Michael Orlitzky wrote: > I don't think you can do that You can't, at present. (Note: Typeclasses are not OOP classes; `class (Num a, Group a) => Additive a` does not declare superclasses, but prerequisites.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.browne at dit.ie Sun Feb 22 07:53:12 2015 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Sun, 22 Feb 2015 07:53:12 +0000 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? In-Reply-To: References: <54E91855.7060803@orlitzky.com> Message-ID: On 22 February 2015 at 00:04, Brandon Allbery wrote: > You can't, at present. (Note: Typeclasses are not OOP classes; `class (Num > a, Group a) => Additive a` does not declare superclasses, but > prerequisites.) > In logic we would say (Num a AND Group a) is a necessary condition for ( Additive a) => (Num a AND Group a) to hold. -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.browne at dit.ie Sun Feb 22 08:07:44 2015 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Sun, 22 Feb 2015 08:07:44 +0000 Subject: [Haskell-beginners] How to manage typeclass hierarchies and instances? In-Reply-To: References: <54E91855.7060803@orlitzky.com> Message-ID: OPPS! My previous email should have be stated as a question rather than a statement! class (Num a, Group a) => Additive a Or maybe given ( Additive a) => (Num a AND Group a). Then (Num a AND Group a) is a necessary condition for (Additive a) to hold. On 22 February 2015 at 07:53, PATRICK BROWNE wrote: > > On 22 February 2015 at 00:04, Brandon Allbery wrote: > >> You can't, at present. (Note: Typeclasses are not OOP classes; `class >> (Num a, Group a) => Additive a` does not declare superclasses, but >> prerequisites.) >> > > In logic we would say (Num a AND Group a) is a necessary condition for ( > Additive a) => (Num a AND Group a) to hold. > > -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.neely at gmail.com Sun Feb 22 13:49:11 2015 From: joel.neely at gmail.com (Joel Neely) Date: Sun, 22 Feb 2015 07:49:11 -0600 Subject: [Haskell-beginners] Fwd: tower hanoi problem In-Reply-To: References: <54DE67FF.9020909@home.nl> <54DFBF9D.30704@home.nl> <54E05785.4000001@home.nl> <54E058F9.7010409@home.nl> <54E05E28.1020806@home.nl> <54E1078C.5060303@runforyourlife.org> <54E23764.4030203@runforyourlife.org> <54E239DA.1010606@runforyourlife.org> <54E23AD4.8050203@home.nl> <54E324C8.8050803@home.nl> <54E399C3.5070704@runforyourlife.org> <54E53962.4040101@runforyourlife.org> <54E5A6B3.5040904@runforyourlife.org> <54E605D9.6010604@runforyourlife.org> Message-ID: Nice! Just out of curiosity... I have no trouble accepting that the zipWith3 approach is more idiomatic, but it doesn't appear (to my eye) significantly shorter or significantly more obvious. So are the tradeoffs primarily cultural, or is there another issue that I'm missing? Thanks, -jn- On Sat, Feb 21, 2015 at 12:04 PM, Chadda? Fouch? wrote: > On Sat, Feb 21, 2015 at 4:50 PM, Joel Neely wrote: > >> >> smooth :: Fractional n => [n] -> [n] >> smooth (a:z@(b:c:_)) = (a + b + c) / 3 : smooth z >> smooth _ = [] >> >> >> > In Haskell, I would write this with higher-order functions though : > > smooth xs = zipWith3 (\a b c -> (a+b+c)/3) xs (drop 1 xs) (drop 2 xs) > > -- > Jeda? > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -------------- next part -------------- An HTML attachment was scrubbed... URL: From fr33domlover at riseup.net Sun Feb 22 16:26:42 2015 From: fr33domlover at riseup.net (fr33domlover) Date: Sun, 22 Feb 2015 18:26:42 +0200 Subject: [Haskell-beginners] Hello + Testing Framework Message-ID: First of all, hello! I'm a fresh Haskell beginner and this is my first message to Haskell MLs. I recently began a tiny dummy project. Its code is minimal and its purpose it to help me learn all the common developer tasks that aren't coding: debugging, releasing, testing and so on. Especially organizing the project repository, before I start "real" things. My first problem was choosing a test framework and integrating it with `cabal test`. There's a lot of info, sometimes contradicting due to changes in recent years. Anyway I'll just blog about this later and now get to the point. I chose Tasty as my test framework. In the cabal user guide I read about the test-suite type "detailed-0.9" being preferred for new projects. Later after choosing Tasty I started adding basic support to my dummy project, and in the cabal integration section I see it says to use the older "exitcode-stdio-1.0". I also don't see a clear way to use detailed, because Tasty supplies its "defaultMain" function meant to generate an executable. But I just tool a brief look, not touched internals of Tasty at all. The question: Should I use deatiled-0.9? If yes, how? Or should I just use exitcode-stdio-1.0 as the Tasty manual says? Thanks in advance! --- fr33domlover GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From michael at orlitzky.com Sun Feb 22 16:39:33 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Sun, 22 Feb 2015 11:39:33 -0500 Subject: [Haskell-beginners] Hello + Testing Framework In-Reply-To: <20150222162419.E6DB4BCAE7@haskell.org> References: <20150222162419.E6DB4BCAE7@haskell.org> Message-ID: <54EA0645.5010206@orlitzky.com> On 02/22/2015 11:26 AM, fr33domlover wrote: > > In the cabal user guide I read about the test-suite type "detailed-0.9" being > preferred for new projects. Later after choosing Tasty I started adding basic > support to my dummy project, and in the cabal integration section I see it says > to use the older "exitcode-stdio-1.0". > > I also don't see a clear way to use detailed, because Tasty supplies its > "defaultMain" function meant to generate an executable. But I just tool a brief > look, not touched internals of Tasty at all. > No one uses the detailed-0.9 interface, and there's not a single working example anywhere so no one ever will. Just stick with exitcode-stdio-1.0 and tasty (which works great, by the way). The recommendation in the users guide is wishful thinking. From r.wobben at home.nl Sun Feb 22 18:50:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 22 Feb 2015 19:50:11 +0100 Subject: [Haskell-beginners] how to check the format of a string ? Message-ID: <54EA24E3.4070008@home.nl> Hello, Im still busy with CIS 194 Now im facing this problem. There is a log file of strings. Most of them are of this format char Number [chars] What is the best way to check if the string has this format ? Regex or another way ? Roelof From edwards.benj at gmail.com Sun Feb 22 19:14:51 2015 From: edwards.benj at gmail.com (Benjamin Edwards) Date: Sun, 22 Feb 2015 19:14:51 +0000 Subject: [Haskell-beginners] how to check the format of a string ? References: <54EA24E3.4070008@home.nl> Message-ID: If the format is sufficiently simple a regex can be a very neat way to express the idea. Mostly people use parser combinators. Have a look at parsec / attoparsec on hackage. Ben On Sun Feb 22 2015 at 18:50:18 Roelof Wobben wrote: > Hello, > > Im still busy with CIS 194 > > Now im facing this problem. > > There is a log file of strings. > > Most of them are of this format char Number [chars] > > What is the best way to check if the string has this format ? > > Regex or another way ? > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sun Feb 22 19:22:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 22 Feb 2015 20:22:55 +0100 Subject: [Haskell-beginners] how to check the format of a string ? In-Reply-To: References: <54EA24E3.4070008@home.nl> Message-ID: <54EA2C8F.7000804@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Sun Feb 22 19:25:54 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Mon, 23 Feb 2015 00:55:54 +0530 Subject: [Haskell-beginners] how to check the format of a string ? In-Reply-To: <54EA2C8F.7000804@home.nl> References: <54EA24E3.4070008@home.nl> <54EA2C8F.7000804@home.nl> Message-ID: The exercise was meant to be done without using any library. Try it out, it will work. A parser combinator library, such as parsec or attoparsec is better learnt after you have some idea of monads, which is the last topic cis194 deals with. But, if it interests you, keep going. Parsec might be a better option as it has been there for a longer amount of time, and thus has more learning resources. Hope this helps. On 23 February 2015 at 00:52, Roelof Wobben wrote: > Thanks, > > Found this tutorial which works with log files like I have to do : > https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-frameworks/text-manipulation/attoparsec > > Roelof > > > > Benjamin Edwards schreef op 22-2-2015 om 20:14: > > If the format is sufficiently simple a regex can be a very neat way to > express the idea. Mostly people use parser combinators. Have a look at > parsec / attoparsec on hackage. > > Ben > > On Sun Feb 22 2015 at 18:50:18 Roelof Wobben wrote: > >> Hello, >> >> Im still busy with CIS 194 >> >> Now im facing this problem. >> >> There is a log file of strings. >> >> Most of them are of this format char Number [chars] >> >> What is the best way to check if the string has this format ? >> >> Regex or another way ? >> >> Roelof >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Sun Feb 22 19:27:19 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Mon, 23 Feb 2015 00:57:19 +0530 Subject: [Haskell-beginners] how to check the format of a string ? In-Reply-To: References: <54EA24E3.4070008@home.nl> <54EA2C8F.7000804@home.nl> Message-ID: Also, as far as I remember, cis194 made you build parser combinators like parsec and attoparsec when teaching applicative functors and other fancy stuff. You can opt to wait till then. On 23 February 2015 at 00:55, Sumit Sahrawat, Maths & Computing, IIT (BHU) < sumit.sahrawat.apm13 at iitbhu.ac.in> wrote: > The exercise was meant to be done without using any library. Try it out, > it will work. > A parser combinator library, such as parsec or attoparsec is better learnt > after you have some idea of monads, which is the last topic cis194 deals > with. > But, if it interests you, keep going. Parsec might be a better option as > it has been there for a longer amount of time, and thus has more learning > resources. > > Hope this helps. > > On 23 February 2015 at 00:52, Roelof Wobben wrote: > >> Thanks, >> >> Found this tutorial which works with log files like I have to do : >> https://www.fpcomplete.com/school/starting-with-haskell/libraries-and-frameworks/text-manipulation/attoparsec >> >> Roelof >> >> >> >> Benjamin Edwards schreef op 22-2-2015 om 20:14: >> >> If the format is sufficiently simple a regex can be a very neat way to >> express the idea. Mostly people use parser combinators. Have a look at >> parsec / attoparsec on hackage. >> >> Ben >> >> On Sun Feb 22 2015 at 18:50:18 Roelof Wobben wrote: >> >>> Hello, >>> >>> Im still busy with CIS 194 >>> >>> Now im facing this problem. >>> >>> There is a log file of strings. >>> >>> Most of them are of this format char Number [chars] >>> >>> What is the best way to check if the string has this format ? >>> >>> Regex or another way ? >>> >>> Roelof >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > -- > Regards > > Sumit Sahrawat > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From raabe at froglogic.com Sun Feb 22 19:38:38 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Sun, 22 Feb 2015 20:38:38 +0100 Subject: [Haskell-beginners] =?utf-8?q?how_to_check_the_format_of_a_string?= =?utf-8?b?ICA/?= In-Reply-To: <54EA24E3.4070008@home.nl> References: <54EA24E3.4070008@home.nl> Message-ID: <5a6708c3a8360b63e87e9229097fe87f@roundcube.froglogic.com> On 2015-02-22 19:50, Roelof Wobben wrote: > Now im facing this problem. > > There is a log file of strings. > > Most of them are of this format char Number [chars] > > What is the best way to check if the string has this format ? For this particular format I'd go for plain pattern matching and guards. Something like import Data.Char (isLetter, isDigit) isValid :: String -> Bool isValid s = go (words s) where go ([a]:b:_) = isLetter a && all isDigit b go _ = False This will accept lines starting with a letter followed by some number and then (optionally!) some more text. -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From r.wobben at home.nl Sun Feb 22 20:23:01 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 22 Feb 2015 21:23:01 +0100 Subject: [Haskell-beginners] how to check the format of a string ? In-Reply-To: <5a6708c3a8360b63e87e9229097fe87f@roundcube.froglogic.com> References: <54EA24E3.4070008@home.nl> <5a6708c3a8360b63e87e9229097fe87f@roundcube.froglogic.com> Message-ID: <54EA3AA5.70806@home.nl> Frerich Raabe schreef op 22-2-2015 om 20:38: > On 2015-02-22 19:50, Roelof Wobben wrote: >> Now im facing this problem. >> >> There is a log file of strings. >> >> Most of them are of this format char Number [chars] >> >> What is the best way to check if the string has this format ? > > For this particular format I'd go for plain pattern matching and > guards. Something like > > import Data.Char (isLetter, isDigit) > > isValid :: String -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > This will accept lines starting with a letter followed by some number > and then (optionally!) some more text. > Thanks, I can also check if a is equal to I , W or E. And in the main function check if A = I/W/E Roelof From stuart.hungerford at gmail.com Mon Feb 23 20:46:56 2015 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Tue, 24 Feb 2015 07:46:56 +1100 Subject: [Haskell-beginners] Tyepclasses and creating 'Num' instances Message-ID: Hi, Many thanks to everyone who responded to my earlier question about hierarchies of typeclasses. I have a followup question regarding creating instances. Suppose I have this additive semigroup typeclass: class (Num a) => AddSemigroup a where (|+|) :: a -> a -> a (|+|) = (+) I'd like to make 2-element tuples instances of AddSemigroup, provided their elements are: instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) GHC says it "Could not deduce (Num (a, b))" in this situation, which seems fair enough so I tried: instance (AddSemigroup a, Num a, AddSemigroup b, Num b) => AddSemigroup (a, b) With the same result. Separate instances seem to work though: instance (Num a, Num b) => Num (a, b) instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) At this point I feel like I must be duplicating instances that are provided in a standard way in the prelude somewhere, or more likely I've misunderstood the ideas around creating instances? Any advice much appreciated, Stu From michael at orlitzky.com Mon Feb 23 21:03:27 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 23 Feb 2015 16:03:27 -0500 Subject: [Haskell-beginners] Tyepclasses and creating 'Num' instances In-Reply-To: References: Message-ID: <54EB959F.7070806@orlitzky.com> On 02/23/2015 03:46 PM, Stuart Hungerford wrote: > > instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) > > GHC says it "Could not deduce (Num (a, b))" in this situation, which > seems fair enough so I tried: > > instance (AddSemigroup a, Num a, AddSemigroup b, Num b) => AddSemigroup (a, b) Since you've defined the "AddSemigroup plus" to be the "Num plus", when you attempt to make (a,b) an instance of AddSemigroup, GHC tries to use the "Num plus" on them; i.e. (x1,y1) + (x2,y2) = ??? Since (a,b) isn't an instance of Num, it doesn't know what to do here. It's obvious that you want, (x1,y1) + (x2,y2) = (x1+x2, y1+y2) (which is fine, since both 'a' and 'b' are instance of Num), but you could just as well declare, (x1,y1) + (x2,y2) = (x1*x2, y1*y2) The compiler doesn't know, so declaring 'a' and 'b' as instances of Num isn't enough. You really have to tell it how to add the pair. > > With the same result. Separate instances seem to work though: > > instance (Num a, Num b) => Num (a, b) > > instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) > Now it knows how to add (x1,y1) and (x2,y2), since (a,b) is an instance of Num. The compiler won't infer the pair instance from the individual ones though. From ahammel87 at gmail.com Mon Feb 23 21:08:28 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 23 Feb 2015 13:08:28 -0800 Subject: [Haskell-beginners] Tyepclasses and creating 'Num' instances In-Reply-To: <54EB959F.7070806@orlitzky.com> References: <54EB959F.7070806@orlitzky.com> Message-ID: Be careful with that. I seem to recall a StackOverflow post where a really confusing bug was eventually tracked down to a declaration of instance Num (Double,Double) somewhere in an imported package. On Mon, Feb 23, 2015 at 1:03 PM, Michael Orlitzky wrote: > On 02/23/2015 03:46 PM, Stuart Hungerford wrote: > > > > instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) > > > > GHC says it "Could not deduce (Num (a, b))" in this situation, which > > seems fair enough so I tried: > > > > instance (AddSemigroup a, Num a, AddSemigroup b, Num b) => AddSemigroup > (a, b) > > Since you've defined the "AddSemigroup plus" to be the "Num plus", when > you attempt to make (a,b) an instance of AddSemigroup, GHC tries to use > the "Num plus" on them; i.e. > > (x1,y1) + (x2,y2) = ??? > > Since (a,b) isn't an instance of Num, it doesn't know what to do here. > It's obvious that you want, > > (x1,y1) + (x2,y2) = (x1+x2, y1+y2) > > (which is fine, since both 'a' and 'b' are instance of Num), but you > could just as well declare, > > (x1,y1) + (x2,y2) = (x1*x2, y1*y2) > > The compiler doesn't know, so declaring 'a' and 'b' as instances of Num > isn't enough. You really have to tell it how to add the pair. > > > > > > With the same result. Separate instances seem to work though: > > > > instance (Num a, Num b) => Num (a, b) > > > > instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) > > > > Now it knows how to add (x1,y1) and (x2,y2), since (a,b) is an instance > of Num. The compiler won't infer the pair instance from the individual > ones though. > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 24 09:28:28 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 10:28:28 +0100 Subject: [Haskell-beginners] how to do this ? Message-ID: <54EC443C.9020904@home.nl> Hello, Im trying to solve exercise 2 of this course : http://www.seas.upenn.edu/~cis194/spring13/hw/02-ADTs.pdf I have this till so far : -- | Main entry point to the application. {-# OPTIONS_GHC -Wall #-} module LogAnalysis where import Data.Char (isDigit, isLetter) import Log -- | checks if the String is of the format char int isValid :: String -> Bool isValid s = case words s of [a]:b:_ -> isLetter a && all isDigit b _ -> False -- | Parse the String to make the right logmessage parse_line :: String -> LogMessage parse_line s = case words s of ("I":time:text) -> LogMessage Info (read time) (unwords text) ("W":time:text) -> LogMessage Warning (read time) (unwords text) ("E":errorcode:time:text) -> LogMessage (Error (read errorcode)) (read time) (unwords text) _ -> Unknown "This is not in the right format" -- | here the actual function which uses isValid and parse to make the right log messages parseMessage :: String -> LogMessage parseMessage s = if isValid(s) then parse_line(s) else Unknown "This is not the right format" parse :: String -> [logMessage] parse s = parse_line s -- | The main entry point. main :: IO () main = do print $ show (parseMessage "I 4681 ehci 0xf43d000:15: regista14: [0xbffff 0xfed nosabled 00-02] Zonseres: brips byted nored)") print $ show (parseMessage "W 3654 e8] PGTT ASF! 00f00000003.2: 0x000 - 0000: 00009dbfffec00000: Pround/f1743colled") print $ show (parseMessage "E 47 1034 'What a pity it wouldn't stay!' sighed the Lory, as soon as it was quite") But I do not see how I can get the output of the parse_line into a List. Can anyone give me a tip ? Roelof From r.wobben at home.nl Tue Feb 24 09:44:39 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 10:44:39 +0100 Subject: [Haskell-beginners] how to do this ? In-Reply-To: <20150224093709.GA10834@x60s.casa> References: <54EC443C.9020904@home.nl> <20150224093709.GA10834@x60s.casa> Message-ID: <54EC4807.2000600@home.nl> Yes, that is one of the books I have to read. For this exercises chapter 2 and 3 . Roelof Francesco Ariis schreef op 24-2-2015 om 10:37: > off list: try to give a more meaningful title to your posts > (i.e. "cis194 help exercise 2" instead of "how to do this"). > It might lead to more answers! > > Also, have you tried "Learn you a haskell for great good"? > > > On Tue, Feb 24, 2015 at 10:28:28AM +0100, Roelof Wobben wrote: >> Hello, >> >> Im trying to solve exercise 2 of this course : >> http://www.seas.upenn.edu/~cis194/spring13/hw/02-ADTs.pdf >> >> I have this till so far : >> >> -- | Main entry point to the application. >> {-# OPTIONS_GHC -Wall #-} >> >> module LogAnalysis where >> >> import Data.Char (isDigit, isLetter) >> import Log >> >> -- | checks if the String is of the format char int >> isValid :: String -> Bool >> isValid s = >> case words s of >> [a]:b:_ -> isLetter a && all isDigit b >> _ -> False >> >> -- | Parse the String to make the right logmessage >> parse_line :: String -> LogMessage >> parse_line s = >> case words s of >> ("I":time:text) -> LogMessage Info (read time) >> (unwords text) >> ("W":time:text) -> LogMessage Warning (read time) >> (unwords text) >> ("E":errorcode:time:text) -> LogMessage (Error (read >> errorcode)) (read time) (unwords text) >> _ -> Unknown "This is not in the >> right format" >> >> >> -- | here the actual function which uses isValid and parse to make >> the right log messages >> parseMessage :: String -> LogMessage >> parseMessage s = >> if isValid(s) then parse_line(s) else Unknown "This is not the >> right format" >> >> >> parse :: String -> [logMessage] >> parse s = parse_line s >> >> >> -- | The main entry point. >> main :: IO () >> main = do >> print $ show (parseMessage "I 4681 ehci 0xf43d000:15: regista14: >> [0xbffff 0xfed nosabled 00-02] Zonseres: brips byted nored)") >> print $ show (parseMessage "W 3654 e8] PGTT ASF! 00f00000003.2: >> 0x000 - 0000: 00009dbfffec00000: Pround/f1743colled") >> print $ show (parseMessage "E 47 1034 'What a pity it wouldn't >> stay!' sighed the Lory, as soon as it was quite") >> >> But I do not see how I can get the output of the parse_line into a List. >> >> Can anyone give me a tip ? >> >> Roelof >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From r.wobben at home.nl Tue Feb 24 13:48:11 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 14:48:11 +0100 Subject: [Haskell-beginners] How can I print the outcome with using main. Message-ID: <54EC811B.90606@home.nl> An HTML attachment was scrubbed... URL: From joel.s.williamson at gmail.com Tue Feb 24 14:10:02 2015 From: joel.s.williamson at gmail.com (Joel Williamson) Date: Tue, 24 Feb 2015 14:10:02 +0000 Subject: [Haskell-beginners] How can I print the outcome with using main. Message-ID: testParse returns an IO action. show expects an argument that is in Show. You will need to bind the result of testParse to a name and ensure that LogMessage is in Show. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 24 14:16:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 15:16:55 +0100 Subject: [Haskell-beginners] How can I print the outcome with using main. In-Reply-To: References: Message-ID: <54EC87D7.4070804@home.nl> An HTML attachment was scrubbed... URL: From joel.s.williamson at gmail.com Tue Feb 24 14:23:34 2015 From: joel.s.williamson at gmail.com (Joel Williamson) Date: Tue, 24 Feb 2015 09:23:34 -0500 Subject: [Haskell-beginners] How can I print the outcome with using main. In-Reply-To: <54EC87D7.4070804@home.nl> References: <54EC87D7.4070804@home.nl> Message-ID: Has the course covered `do` notation? On Tue, Feb 24, 2015 at 9:16 AM, Roelof Wobben wrote: > Joel Williamson schreef op 24-2-2015 om 15:10: > > testParse returns an IO action. show expects an argument that is in Show. > You will need to bind the result of testParse to a name and ensure that > LogMessage is in Show. > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > oke, and how do I do this ? > > Roelof > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From bergey at alum.mit.edu Tue Feb 24 14:44:55 2015 From: bergey at alum.mit.edu (Daniel Bergey) Date: Tue, 24 Feb 2015 14:44:55 +0000 Subject: [Haskell-beginners] How can I print the outcome with using main. In-Reply-To: <54EC811B.90606@home.nl> References: <54EC811B.90606@home.nl> Message-ID: <87pp8ztllk.fsf@Chladni.home> Try: | main :: IO () | main = do | msgs <- testParse parse 10 "error.log" | print msgs Your plan is good. GHCi handles IO values specially, for convenience, which blurs the distinction between values which can be fed to `print` directly, and those in IO, which need to be bound as above. On 2015-02-24 at 13:48, Roelof Wobben wrote: > Hello, > > According to the manual of the CIS 194 course I have to do this in GHCI :? testParse parse 10 "error.log" > This to test my code. > > Now my problem is that I cannot use GHCI because I use Fpcomplete. > So I thought I will use main for this : > > So I tried? this : > > main :: IO () > main = do > ?? print? $ testParse parse 10 "error.log" > > but then I see this error message : > > src/LogAnalysis.hs at 39:4-39:9 > No instance for (Show (IO [LogMessage])) arising from a use of > print > ? In the expression: print In a stmt of a 'do' block: print $ testParse parse 10 "error.log" In the expression: do { print $ > testParse parse 10 "error.log" } > > The testparse function looks like this : > > -- | @testParse p n f@ tests the log file parser @p@ by running it > --?? on the first @n@ lines of file @f at . > testParse :: (String -> [LogMessage]) > ????????? -> Int > ????????? -> FilePath > ????????? -> IO [LogMessage] > testParse parse n file = take n . parse <$> readFile file > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From r.wobben at home.nl Tue Feb 24 15:36:09 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 16:36:09 +0100 Subject: [Haskell-beginners] How can I print the outcome with using main. In-Reply-To: <87pp8ztllk.fsf@Chladni.home> References: <54EC811B.90606@home.nl> <87pp8ztllk.fsf@Chladni.home> Message-ID: <54EC9A69.2040908@home.nl> Daniel Bergey schreef op 24-2-2015 om 15:44: > main :: IO () > | main = do > | msgs <- testParse parse 10 "error.log" > | print msgs Thanks, Now Im busy reading how to make a tree withe recursion for the next exercise. Roelof From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 16:09:07 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 21:39:07 +0530 Subject: [Haskell-beginners] how to do this ? In-Reply-To: <54EC4807.2000600@home.nl> References: <54EC443C.9020904@home.nl> <20150224093709.GA10834@x60s.casa> <54EC4807.2000600@home.nl> Message-ID: The function show :: Show a => a -> String can be used with putStrLn :: String -> IO () to get the output on different lines. The function print :: Show a => a -> IO () print = putStr . show -- convert to string and then print (without newline) does not put a newline at the end, to get a newline you use putStrLn . show $ ... On 24 February 2015 at 15:14, Roelof Wobben wrote: > Yes, that is one of the books I have to read. > For this exercises chapter 2 and 3 . > > Roelof > > > Francesco Ariis schreef op 24-2-2015 om 10:37: > >> off list: try to give a more meaningful title to your posts >> (i.e. "cis194 help exercise 2" instead of "how to do this"). >> It might lead to more answers! >> >> Also, have you tried "Learn you a haskell for great good"? >> >> >> >> On Tue, Feb 24, 2015 at 10:28:28AM +0100, Roelof Wobben wrote: >> >>> Hello, >>> >>> Im trying to solve exercise 2 of this course : >>> http://www.seas.upenn.edu/~cis194/spring13/hw/02-ADTs.pdf >>> >>> I have this till so far : >>> >>> -- | Main entry point to the application. >>> {-# OPTIONS_GHC -Wall #-} >>> >>> module LogAnalysis where >>> >>> import Data.Char (isDigit, isLetter) >>> import Log >>> >>> -- | checks if the String is of the format char int >>> isValid :: String -> Bool >>> isValid s = >>> case words s of >>> [a]:b:_ -> isLetter a && all isDigit b >>> _ -> False >>> >>> -- | Parse the String to make the right logmessage >>> parse_line :: String -> LogMessage >>> parse_line s = >>> case words s of >>> ("I":time:text) -> LogMessage Info (read time) >>> (unwords text) >>> ("W":time:text) -> LogMessage Warning (read time) >>> (unwords text) >>> ("E":errorcode:time:text) -> LogMessage (Error (read >>> errorcode)) (read time) (unwords text) >>> _ -> Unknown "This is not in the >>> right format" >>> >>> >>> -- | here the actual function which uses isValid and parse to make >>> the right log messages >>> parseMessage :: String -> LogMessage >>> parseMessage s = >>> if isValid(s) then parse_line(s) else Unknown "This is not the >>> right format" >>> >>> >>> parse :: String -> [logMessage] >>> parse s = parse_line s >>> >>> >>> -- | The main entry point. >>> main :: IO () >>> main = do >>> print $ show (parseMessage "I 4681 ehci 0xf43d000:15: regista14: >>> [0xbffff 0xfed nosabled 00-02] Zonseres: brips byted nored)") >>> print $ show (parseMessage "W 3654 e8] PGTT ASF! 00f00000003.2: >>> 0x000 - 0000: 00009dbfffec00000: Pround/f1743colled") >>> print $ show (parseMessage "E 47 1034 'What a pity it wouldn't >>> stay!' sighed the Lory, as soon as it was quite") >>> >>> But I do not see how I can get the output of the parse_line into a List. >>> >>> Can anyone give me a tip ? >>> >>> Roelof >>> >>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondra at nekola.cz Thu Feb 26 12:42:03 2015 From: ondra at nekola.cz (Ondrej Nekola) Date: Thu, 26 Feb 2015 13:42:03 +0100 Subject: [Haskell-beginners] Random variable holding a function Message-ID: <54EF149B.1090309@nekola.cz> Hi I try to simulate some processes, that contain randomness and I would like do it idiomatic way and keep as much code not to know about randomness as possible. I have a following code (simplified to make email more readable): import Data.List import Data.Functor import Genes import Data.Random.RVar import Data.Random.Extras data Individual = Individual (Int, Int) deriving (Eq, Show) -- this part is a bit more complicated... data Population = Population { individuals :: [Individual] } deriving (Eq, Show) type Selection = Population -> Population so far, it's easy: allSurvive :: Selection allSurvive = id extinction :: Selection extinction _ = Population [] The issue comes, when I want to have some randomness in the process. I am able to write a "pick some individuals into next generation" sort of "Selection" fairChance :: Int -> Population -> RVar Population fairChance newSize p = Population <$> (Data.Random.Extras.sample newSize $ individuals p) But it obviously doesn't fit into the "Selection" type. I would like to have something like fairChance :: Int -> RVar Selection (e.g. fairChance :: Int -> RVar (Population -> Population)) Is there a way to do this? Or should I give up this way and try to give up some purity and go withtype Selection :: RVar Population -> RVar population? Thanks Ondrej From r.wobben at home.nl Thu Feb 26 13:21:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 26 Feb 2015 14:21:19 +0100 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? Message-ID: <54EF1DCF.40906@home.nl> Hello, Suppose we have this definition of a tree : data MessageTree = Leaf | Node MessageTree LogMessage MessageTree deriving (Show, Eq) let Message = LogMessage "E 1 this is a test error" let Message = LogMessage "e 2 this is the second test error " As I understand it right I can make the first entry like this : first_entry = Node Messagetree Message Messagetree And the second one like this second_entry = Node Message Messagetree Message2 Messagetree ?? Roelof From bergey at alum.mit.edu Thu Feb 26 13:35:17 2015 From: bergey at alum.mit.edu (Daniel Bergey) Date: Thu, 26 Feb 2015 13:35:17 +0000 Subject: [Haskell-beginners] Random variable holding a function In-Reply-To: <54EF149B.1090309@nekola.cz> References: <54EF149B.1090309@nekola.cz> Message-ID: <87mw40re22.fsf@Chladni.home> On 2015-02-26 at 12:42, Ondrej Nekola wrote: > type Selection = Population -> Population > > so far, it's easy: > > allSurvive :: Selection > allSurvive = id > > fairChance :: Int -> Population -> RVar Population > fairChance newSize p = Population <$> (Data.Random.Extras.sample newSize > $ individuals p) > > fairChance :: Int -> RVar Selection > (e.g. fairChance :: Int -> RVar (Population -> Population)) > > Is there a way to do this? Or should I give up this way and try to give > up some purity and go withtype Selection :: RVar Population -> RVar > population? > > Thanks > Ondrej > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From bergey at alum.mit.edu Thu Feb 26 13:40:06 2015 From: bergey at alum.mit.edu (Daniel Bergey) Date: Thu, 26 Feb 2015 13:40:06 +0000 Subject: [Haskell-beginners] Random variable holding a function In-Reply-To: <54EF149B.1090309@nekola.cz> References: <54EF149B.1090309@nekola.cz> Message-ID: <87lhjkrdu1.fsf@Chladni.home> On 2015-02-26 at 12:42, Ondrej Nekola wrote: > type Selection = Population -> Population > > so far, it's easy: > > allSurvive :: Selection > allSurvive = id > > fairChance :: Int -> Population -> RVar Population > fairChance newSize p = Population <$> (Data.Random.Extras.sample newSize > $ individuals p) > > fairChance :: Int -> RVar Selection > (e.g. fairChance :: Int -> RVar (Population -> Population)) > > Is there a way to do this? Or should I give up this way and try to give > up some purity and go withtype Selection :: RVar Population -> RVar > population? I would define Selection as | type Selection = Population -> RVar Population Then you can compose with >>=, which specializes to | (>>=) :: RVar Population -> Selection -> RVar Population or with any of the other Monad operators (eg, >=>). With this definition, you can keep your current definition of fairChance. There's no problem defining values of type `RVar (Population -> Population`. `fmap allSurvive` is one such. But defining fairChance this way seems a bit awkward to me. Daniel From k-bx at k-bx.com Thu Feb 26 13:56:59 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Thu, 26 Feb 2015 15:56:59 +0200 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: <54EF1DCF.40906@home.nl> References: <54EF1DCF.40906@home.nl> Message-ID: Hi Roelof, I think you misunderstood it. There are two things here: types and values (value-constructors). They exist in different world, not touching each other. In Haskell, you define a type as: data = You can create values as: let varName = You need to put of some type, not type name itself in place of those s. So, with datatype you provided, you have two data-constructors: Leaf and Node You can create a leaf: let leaf = Leav or a node: let node = Node Leaf "msg" Leaf You can see that Node is a data-constructor that takes 3 values, not type-names as it's parameters. Hope this helps. On Thu, Feb 26, 2015 at 3:21 PM, Roelof Wobben wrote: > Hello, > > Suppose we have this definition of a tree : > > data MessageTree = Leaf > | Node MessageTree LogMessage MessageTree > deriving (Show, Eq) > > let Message = LogMessage "E 1 this is a test error" > let Message = LogMessage "e 2 this is the second test error " > > As I understand it right I can make the first entry like this : > first_entry = Node Messagetree Message Messagetree > > And the second one like this second_entry = Node Message Messagetree > Message2 Messagetree ?? > > Roelof > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 26 14:01:22 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 26 Feb 2015 15:01:22 +0100 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: References: <54EF1DCF.40906@home.nl> Message-ID: <54EF2732.90005@home.nl> An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Thu Feb 26 14:08:37 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Thu, 26 Feb 2015 16:08:37 +0200 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: <54EF2732.90005@home.nl> References: <54EF1DCF.40906@home.nl> <54EF2732.90005@home.nl> Message-ID: In my second example you can see a minimal node with a message: node = Node Leaf "msg" Leaf Instead of either left or right Leaf you can put another value of type MessageTree, for example: node = Node Leaf "msg1" (Node Leaf "msg2" Leaf) On Thu, Feb 26, 2015 at 4:01 PM, Roelof Wobben wrote: > Oke, > > So a leaf is a node which has no "branch" > > I have made a exercise where I have to made the logMessages. > Now I have to turn them into a tree > > Where does the second entry goes then ? > > Roelof > > > Konstantine Rybnikov schreef op 26-2-2015 om 14:56: > > Hi Roelof, > > I think you misunderstood it. > > There are two things here: types and values (value-constructors). They > exist in different world, not touching each other. > > In Haskell, you define a type as: > > data = > > > You can create values as: > > let varName = > > You need to put of some type, not type name itself in place of > those s. > > So, with datatype you provided, you have two data-constructors: > > Leaf > > and > > Node > > You can create a leaf: > > let leaf = Leav > > or a node: > > let node = Node Leaf "msg" Leaf > > You can see that Node is a data-constructor that takes 3 values, not > type-names as it's parameters. > > Hope this helps. > > On Thu, Feb 26, 2015 at 3:21 PM, Roelof Wobben wrote: > >> Hello, >> >> Suppose we have this definition of a tree : >> >> data MessageTree = Leaf >> | Node MessageTree LogMessage MessageTree >> deriving (Show, Eq) >> >> let Message = LogMessage "E 1 this is a test error" >> let Message = LogMessage "e 2 this is the second test error " >> >> As I understand it right I can make the first entry like this : >> first_entry = Node Messagetree Message Messagetree >> >> And the second one like this second_entry = Node Message Messagetree >> Message2 Messagetree ?? >> >> Roelof >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> > > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 26 14:40:58 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 26 Feb 2015 15:40:58 +0100 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: References: <54EF1DCF.40906@home.nl> <54EF2732.90005@home.nl> Message-ID: <54EF307A.40204@home.nl> An HTML attachment was scrubbed... URL: From ondra at nekola.cz Thu Feb 26 15:48:24 2015 From: ondra at nekola.cz (Ondrej Nekola) Date: Thu, 26 Feb 2015 16:48:24 +0100 Subject: [Haskell-beginners] Random variable holding a function In-Reply-To: <87lhjkrdu1.fsf@Chladni.home> References: <54EF149B.1090309@nekola.cz> <87lhjkrdu1.fsf@Chladni.home> Message-ID: <54EF4048.1030806@nekola.cz> Thank you, it was very helpfull. For reference, this is the code, that reflect Daniel's recommendation (I hope I made no stupid mistake there): https://github.com/satai/FrozenBeagle/blob/32f22979d7ef8d5265aa9e49982fa394e2039cf3/src/Population.hs Thanks Ondrej > On 2015-02-26 at 12:42, Ondrej Nekola wrote: >> type Selection = Population -> Population >> >> so far, it's easy: >> >> allSurvive :: Selection >> allSurvive = id >> >> fairChance :: Int -> Population -> RVar Population >> fairChance newSize p = Population <$> (Data.Random.Extras.sample newSize >> $ individuals p) >> >> fairChance :: Int -> RVar Selection >> (e.g. fairChance :: Int -> RVar (Population -> Population)) >> >> Is there a way to do this? Or should I give up this way and try to give >> up some purity and go withtype Selection :: RVar Population -> RVar >> population? > I would define Selection as > > | type Selection = Population -> RVar Population > > Then you can compose with >>=, which specializes to > > | (>>=) :: RVar Population -> Selection -> RVar Population > > or with any of the other Monad operators (eg, >=>). > > With this definition, you can keep your current definition of > fairChance. > > There's no problem defining values of type `RVar (Population -> > Population`. `fmap allSurvive` is one such. But defining fairChance > this way seems a bit awkward to me. > > Daniel > From r.wobben at home.nl Thu Feb 26 18:32:05 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 26 Feb 2015 19:32:05 +0100 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: <54EF307A.40204@home.nl> References: <54EF1DCF.40906@home.nl> <54EF2732.90005@home.nl> <54EF307A.40204@home.nl> Message-ID: <54EF66A5.5050107@home.nl> An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Fri Feb 27 06:41:15 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Fri, 27 Feb 2015 08:41:15 +0200 Subject: [Haskell-beginners] trees on Haskell : Do I understand it right ? In-Reply-To: <54EF66A5.5050107@home.nl> References: <54EF1DCF.40906@home.nl> <54EF2732.90005@home.nl> <54EF307A.40204@home.nl> <54EF66A5.5050107@home.nl> Message-ID: Roelof, Do you get any type-errors with your code? On Thu, Feb 26, 2015 at 8:32 PM, Roelof Wobben wrote: > Oke, > > I send it a second time but now in plain text. > > So for 3 it will be like this : > > Node = Node (Node Leaf "msg1" Leaf) (Node Leaf "msg2") (Node "msg3" > Leaf) ??? > > > Roelof > > > > > > Konstantine Rybnikov schreef op 26-2-2015 om 15:08: > > In my second example you can see a minimal node with a message: > > node = Node Leaf "msg" Leaf > > Instead of either left or right Leaf you can put another value of type > MessageTree, for example: > > node = Node Leaf "msg1" (Node Leaf "msg2" Leaf) > > On Thu, Feb 26, 2015 at 4:01 PM, Roelof Wobben wrote: > >> Oke, >> >> So a leaf is a node which has no "branch" >> >> I have made a exercise where I have to made the logMessages. >> Now I have to turn them into a tree >> >> Where does the second entry goes then ? >> >> Roelof >> >> >> Konstantine Rybnikov schreef op 26-2-2015 om 14:56: >> >> Hi Roelof, >> >> I think you misunderstood it. >> >> There are two things here: types and values (value-constructors). They >> exist in different world, not touching each other. >> >> In Haskell, you define a type as: >> >> data = >> >> >> You can create values as: >> >> let varName = >> >> You need to put of some type, not type name itself in place of >> those s. >> >> So, with datatype you provided, you have two data-constructors: >> >> Leaf >> >> and >> >> Node >> >> You can create a leaf: >> >> let leaf = Leav >> >> or a node: >> >> let node = Node Leaf "msg" Leaf >> >> You can see that Node is a data-constructor that takes 3 values, not >> type-names as it's parameters. >> >> Hope this helps. >> >> On Thu, Feb 26, 2015 at 3:21 PM, Roelof Wobben wrote: >> >>> Hello, >>> >>> Suppose we have this definition of a tree : >>> >>> data MessageTree = Leaf >>> | Node MessageTree LogMessage MessageTree >>> deriving (Show, Eq) >>> >>> let Message = LogMessage "E 1 this is a test error" >>> let Message = LogMessage "e 2 this is the second test error " >>> >>> As I understand it right I can make the first entry like this : >>> first_entry = Node Messagetree Message Messagetree >>> >>> And the second one like this second_entry = Node Message Messagetree >>> Message2 Messagetree ?? >>> >>> Roelof >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> >> >> >> _______________________________________________ >> Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > > _______________________________________________ > Beginners mailing listBeginners at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efasckenoth at gmail.com Fri Feb 27 07:26:56 2015 From: efasckenoth at gmail.com (Stefan =?iso-8859-1?Q?H=F6ck?=) Date: Fri, 27 Feb 2015 08:26:56 +0100 Subject: [Haskell-beginners] Relatively simple undirected graph library? In-Reply-To: References: <20150105042659.GA804@hunter.iway.ch> <54ABA2F4.2030208@gmx.de> <20150106180346.GA809@hunter.iway.ch> Message-ID: <20150227072656.GD1127@hunter> Dear list Sorry that it took so long. The usual excuses apply: Two little children, other priorities at work, had to write two more monad tutorials. For better or worse, here is a first draft of a labeled graph library. https://github.com/stefan-hoeck/labeled-graph This is all highly experimental. No unit tests so far and lots of stuff is still missing, so feel free to contribute. In the next couple of days, I'll add some more type class instances to LGraphs (Foldable, Traversable, Bifunctor, Bifoldable, Bitraversable). The implementation might well still change. One implementation detail that is different compared to other graph libraries: Edges are represented as Ints internally, so the maximal vertex is limited by the square of the largest Int, which is rather low on 32 bit systems. This is a typical case of bad preliminary optimisation, since I hope that using this implementation we can use efficient IntMaps to store edge labels. It's well possible, that this will change in the future. Please note also that I will use the library mainly in a cheminformatics project, where graphs typically are small and sparse (vertices are almost always of degree four or lower). Gr?sse aus Z?rich Stefan On Wed, Feb 25, 2015 at 11:30:54PM +0100, Torsten Otto wrote: > I second that it would be terrific to see this posted. > > Regards from Hamburg, > Torsten > From apfelmus at quantentunnel.de Fri Feb 27 09:49:56 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri, 27 Feb 2015 10:49:56 +0100 Subject: [Haskell-beginners] Random variable holding a function In-Reply-To: <87lhjkrdu1.fsf@Chladni.home> References: <54EF149B.1090309@nekola.cz> <87lhjkrdu1.fsf@Chladni.home> Message-ID: Daniel Bergey wrote: > On 2015-02-26 at 12:42, Ondrej Nekola wrote: >> >> I try to simulate some processes, that contain randomness and I would >> like do it idiomatic way and keep as much code not to know about >> randomness as possible. >> >> type Selection = Population -> Population >> >> so far, it's easy: >> >> allSurvive :: Selection >> allSurvive = id >> >> fairChance :: Int -> Population -> RVar Population >> fairChance newSize p = Population <$> (Data.Random.Extras.sample newSize >> $ individuals p) >> >> fairChance :: Int -> RVar Selection >> (e.g. fairChance :: Int -> RVar (Population -> Population)) >> >> Is there a way to do this? Or should I give up this way and try to give >> up some purity and go withtype Selection :: RVar Population -> RVar >> population? > > I would define Selection as > > | type Selection = Population -> RVar Population > > Then you can compose with >>=, which specializes to > > | (>>=) :: RVar Population -> Selection -> RVar Population > > or with any of the other Monad operators (eg, >=>). > > With this definition, you can keep your current definition of > fairChance. This is pretty much the "probability monad". For more on this, my personal recommendations would be http://apfelmus.nfshost.com/articles/random-permutations.html http://web.engr.oregonstate.edu/~erwig/papers/PFP_JFP06.pdf Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From mwanikibusiness at gmail.com Fri Feb 27 15:35:21 2015 From: mwanikibusiness at gmail.com (Njagi Mwaniki) Date: Fri, 27 Feb 2015 18:35:21 +0300 Subject: [Haskell-beginners] Testing Yesod applications. Message-ID: <54F08EB9.4010208@gmail.com> Could I get help with testing yesod applications when it comes to situations requiring authentication and authorization? Here is my full question on stack overflow. http://stackoverflow.com/questions/28764807/performing-authentication-during-testing-browserid From charioteer7 at gmail.com Fri Feb 27 20:51:12 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Fri, 27 Feb 2015 15:51:12 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List Message-ID: Hi. An elementary question here about two functions in Data.List: how to use a value from findIndex which returns a Maybe Int, and then use that result in splitAt which takes a regular Int? This is in an IO() do Like so: (This is in an IO() do block) let gradeItemIndex = findIndex (\g -> (itemName g) == (itemName gradeItemP)) gradeItemList let twoListsTuple = splitAt gradeItemIndex gradeItemList // does not compile obviously Many Thanks, Geoffrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Fri Feb 27 21:16:19 2015 From: toad3k at gmail.com (David McBride) Date: Fri, 27 Feb 2015 16:16:19 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: Message-ID: You will probably do a case match on the result of findIndex to find out whether you want to split there. You will have to deal with the possibility that the item you are searching for is not in the list. Untested: let twoListsTuple = case findIndex (\g -> (itemName g) == (itemName gradeItemP)) gradeItemList of Nothing -> (gradeItemList,[]) Just newlists -> newlists On Fri, Feb 27, 2015 at 3:51 PM, Geoffrey Bays wrote: > Hi. > An elementary question here about two functions in Data.List: > how to use a value from findIndex which returns a Maybe Int, > and then use that result in splitAt which takes a regular Int? > This is in an IO() do > > Like so: (This is in an IO() do block) > > let gradeItemIndex = findIndex (\g -> (itemName g) == (itemName > gradeItemP)) gradeItemList > let twoListsTuple = splitAt gradeItemIndex gradeItemList > > // does not compile obviously > > Many Thanks, > > Geoffrey > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charioteer7 at gmail.com Fri Feb 27 21:41:17 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Fri, 27 Feb 2015 16:41:17 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: Message-ID: David: Thanks for putting me on the right track. This works: let twoListsTuple = case findIndex (\g -> (itemName g) == (itemName gradeItemP)) gradeItemList of Nothing -> (gradeItemList, []) Just x -> splitAt x gradeItemList I was not sure if the splitAt function would take a Just Int in place of a regular Int without complaint, but that seems to be the case. As it turns out, I can be certain from the context that the item will definitely be found in the list, but the case statement allows for the unpacking of the Maybe. Thanks, Geoffrey On Fri, Feb 27, 2015 at 4:16 PM, David McBride wrote: > You will probably do a case match on the result of findIndex to find out > whether you want to split there. You will have to deal with the > possibility that the item you are searching for is not in the list. > Untested: > > let twoListsTuple = case findIndex (\g -> (itemName g) == (itemName > gradeItemP)) gradeItemList of > Nothing -> (gradeItemList,[]) > Just newlists -> newlists > > On Fri, Feb 27, 2015 at 3:51 PM, Geoffrey Bays > wrote: > >> Hi. >> An elementary question here about two functions in Data.List: >> how to use a value from findIndex which returns a Maybe Int, >> and then use that result in splitAt which takes a regular Int? >> This is in an IO() do >> >> Like so: (This is in an IO() do block) >> >> let gradeItemIndex = findIndex (\g -> (itemName g) == (itemName >> gradeItemP)) gradeItemList >> let twoListsTuple = splitAt gradeItemIndex gradeItemList >> >> // does not compile obviously >> >> Many Thanks, >> >> Geoffrey >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Fri Feb 27 21:51:46 2015 From: toad3k at gmail.com (David McBride) Date: Fri, 27 Feb 2015 16:51:46 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: Message-ID: Ah yeah, I messed up a bit. Another way you can deal with this is using the maybe function. If you are absolutely positive that it can never fail, it doesn't hurt to choose a default index of 0. let gradeItemIndex = ... let twoListsTuple = splitAt (maybe 0 id gradeItemIndex) However if the code around it changes your assumption may become invalidated in the future, and your code will explode. On Fri, Feb 27, 2015 at 4:41 PM, Geoffrey Bays wrote: > David: > Thanks for putting me on the right track. This works: > > let twoListsTuple = case findIndex (\g -> (itemName g) == (itemName > gradeItemP)) gradeItemList of > Nothing -> (gradeItemList, []) > Just x -> splitAt x gradeItemList > > I was not sure if the splitAt function would take a Just Int in place of a > regular Int without complaint, but that seems to be the case. > As it turns out, I can be certain from the context that the item will > definitely be found in the list, but the case statement allows for the > unpacking of the Maybe. > > Thanks, > > Geoffrey > > On Fri, Feb 27, 2015 at 4:16 PM, David McBride wrote: > >> You will probably do a case match on the result of findIndex to find out >> whether you want to split there. You will have to deal with the >> possibility that the item you are searching for is not in the list. >> Untested: >> >> let twoListsTuple = case findIndex (\g -> (itemName g) == (itemName >> gradeItemP)) gradeItemList of >> Nothing -> (gradeItemList,[]) >> Just newlists -> newlists >> >> On Fri, Feb 27, 2015 at 3:51 PM, Geoffrey Bays >> wrote: >> >>> Hi. >>> An elementary question here about two functions in Data.List: >>> how to use a value from findIndex which returns a Maybe Int, >>> and then use that result in splitAt which takes a regular Int? >>> This is in an IO() do >>> >>> Like so: (This is in an IO() do block) >>> >>> let gradeItemIndex = findIndex (\g -> (itemName g) == (itemName >>> gradeItemP)) gradeItemList >>> let twoListsTuple = splitAt gradeItemIndex gradeItemList >>> >>> // does not compile obviously >>> >>> Many Thanks, >>> >>> Geoffrey >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >>> >> >> _______________________________________________ >> Beginners mailing list >> Beginners at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >> >> > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Fri Feb 27 22:18:47 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 27 Feb 2015 23:18:47 +0100 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: Message-ID: <20150227221847.GA6279@x60s.casa> On Fri, Feb 27, 2015 at 04:51:46PM -0500, David McBride wrote: > Another way you can deal with this is using the maybe function. > If you are absolutely positive that it can never fail, it doesn't > hurt to choose a default index of 0. > > let gradeItemIndex = ... > let twoListsTuple = splitAt (maybe 0 id gradeItemIndex) And if you don't trust your gut feelings, instead of `maybe 0...` place maybe (error "tlt") id gradeItemIndex as some kind of crude assertion. From ahammel87 at gmail.com Fri Feb 27 22:32:07 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Fri, 27 Feb 2015 14:32:07 -0800 Subject: [Haskell-beginners] Bounded STM Queues with load shedding Message-ID: Hi list, It would be handy for me to have a bounded STM Queue along the lines of TBQueue with the difference that when the queue is full, a call to writeTBQueue is a non-blocking no-op. This is in the context of an asynchronous logging system. If the load (somehow) gets heavy enough that the log message queue is taking up a lot of memory, It's better to lose a few log messages than to have processes block until the logger catches up. Are there any off-the-shelf solutions? Cheers, Allex -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjakway at nyu.edu Sat Feb 28 13:20:05 2015 From: tjakway at nyu.edu (Thomas Jakway) Date: Sat, 28 Feb 2015 08:20:05 -0500 Subject: [Haskell-beginners] FFI Problems Message-ID: <54F1C085.7020503@nyu.edu> I'm very new to Haskell and am trying to write a "real" program to motivate myself to learn it better (so far I've only gotten through Project Euler problems after reading LYAH and most of RWH). I'm using Taglib (https://github.com/taglib/taglib) to read the metadata from a music file and print it. I have a struct C-side (with C linkage) serving as the bridge between Taglib's C++ and Haskell's FFI. A small demo program (compiled with gcc and linked against the C++ object files) gives the correct results, but Haskell is weirdly only getting /some /of it right. Specifically, the C string fields are working but ints are not. The output from the C demo (what Haskell should be printing): music_metadata title: It's My Life, artist: Bon Jovi, album: Bon Jovi Greatest Hits - The Ultimate Collection comment: , genre: Rock, track: 3, length: 224, bitrate: 256, channels: 2, codec: 768 The output from Haskell: MusicMetadata {codec = UNKNOWN, length = 1099511628000, bitrate = 8589934848, channels = 12884901890, track = 8589934848, title = "It's My Life", artist = "Bon Jovi", album = "Bon Jovi Greatest Hits - The Ultimate Collection", comment = "", genre = "Rock"} I would have expected it to work or not work at all, but did not anticipate getting only some of it right. I was going to include snippets from my hsc file but given how new I am to Haskell I don't trust myself to assume where the problem is, so sorry if this is way too long: {-# LANGUAGE CPP, ForeignFunctionInterface #-} module MusicReader ( Codec, MusicMetadata, readMusicMetadata ) where import Control.Monad import Foreign import Foreign.C.Types import Foreign.C.String import System.IO.Unsafe as Unsafe #include "CodecDefines.h" #include "MusicReader.h" constantToCodec code | code == mp3 = MP3 | code == flac = FLAC | code == ogg = OGG_VORBIS | code == mp4 = MP4 | code == mpeg = MPEG | code == none = NONE | code == unknown = UNKNOWN | otherwise = UNKNOWN where mp3 = #const MP3_CODEC flac = #const FLAC_CODEC ogg = #const OGG_VORBIS_CODEC mp4 = #const MP4_CODEC mpeg = #const MPEG_CODEC none = #const NO_EXTENSION unknown = #const UNKNOWN_EXTENSION data Codec = MP3 | FLAC | OGG_VORBIS | MP4 | MPEG | NONE | UNKNOWN deriving (Show) data MusicMetadata = MusicMetadata { codec :: Codec, length :: Int, bitrate :: Int, channels :: Int, track :: Int, title :: String, artist :: String, album :: String, comment :: String, genre :: String } deriving (Show) instance Storable MusicMetadata where sizeOf _ = (#size struct music_metadata) alignment _ = alignment (undefined::CDouble) peek a = do codec <- liftM constantToCodec $ (((#peek struct music_metadata, codec) a) :: IO Int) length <- ((#peek struct music_metadata, length) a) :: IO Int bitrate <- ((#peek struct music_metadata, bitrate) a) :: IO Int channels <- ((#peek struct music_metadata, channels) a) :: IO Int track <- ((#peek struct music_metadata, bitrate) a) :: IO Int title <- ((#peek struct music_metadata, title) a) :: IO CString artist <- ((#peek struct music_metadata, artist) a) :: IO CString album <- ((#peek struct music_metadata, album) a) :: IO CString comment <- ((#peek struct music_metadata, comment) a) :: IO CString genre <- ((#peek struct music_metadata, genre) a) :: IO CString --FIXME: find replacement for temporary names marshalledTitle <- peekCString title marshalledArtist <- peekCString artist marshalledAlbum <- peekCString album marshalledComment <- peekCString comment marshalledGenre <- peekCString genre return (MusicMetadata codec length bitrate channels track marshalledTitle marshalledArtist marshalledAlbum marshalledComment marshalledGenre) poke a = undefined --This is the "primitive" FFI call--calls the C function and gets a pointer --in return --TODO: write a higher level function this module should export that calls --primReadMusicMetadata and converts the C Pointer into the Haskell data --MusicMetadata foreign import ccall unsafe "read_metadata" primReadMusicMetadata :: CString -> IO (Ptr MusicMetadata) --convert the Haskell string to a CString, call into the FFI then --dereference the resulting pointer readMusicMetadata a = join $ withCString a $ \cs -> ((liftM peek) $ primReadMusicMetadata cs) Here's the struct in MusicReader.h (in an extern C block): struct music_metadata { int codec; int length, bitrate, channels; int track; char *title, *artist, *album, *comment, *genre; }; with the corresponding call: struct music_metadata* read_metadata(char*); I've tried playing around with the alignment but it didn't do anything. I also tried declaring the struct's fields as int32_t which also did nothing. The C demo in question is a very simple: #include #include "MusicReader.h" #define FILENAME "Its_My_Life.m4a" int main() { struct music_metadata* metadata = read_metadata(FILENAME); printf("music_metadata\ntitle: %s,\tartist: %s,\talbum: %s\n", metadata->title, metadata->artist, metadata->album); printf("comment: %s,\tgenre: %s,\ttrack: %d,\n", metadata->comment, metadata->genre, metadata->track); printf("length: %d,\tbitrate: %d,\tchannels: %d,\n", metadata->length, metadata->bitrate, metadata->channels); printf("codec: %d\n"); } It just reads the metadata into the struct and prints the fields. I've gotten the impression of the Haskell FFI being very beginner-unfriendly, which isn't surprising but still disappointing because it would be a great opportunity to replace some projects with Haskell. Any help is appreciated, including general feedback on my code! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Sat Feb 28 14:08:46 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Sat, 28 Feb 2015 09:08:46 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: Message-ID: <54F1CBEE.5050806@orlitzky.com> On 02/27/2015 03:51 PM, Geoffrey Bays wrote: > Hi. > An elementary question here about two functions in Data.List: > how to use a value from findIndex which returns a Maybe Int, > and then use that result in splitAt which takes a regular Int? Once you understand why you can't feed a (Maybe Int) to a function that takes an Int, throw it all away and use `splitOn` from the "split" package instead =) https://hackage.haskell.org/package/split-0.2.2/docs/Data-List-Split.html From charioteer7 at gmail.com Sat Feb 28 15:02:27 2015 From: charioteer7 at gmail.com (Geoffrey Bays) Date: Sat, 28 Feb 2015 10:02:27 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: <54F1CBEE.5050806@orlitzky.com> References: <54F1CBEE.5050806@orlitzky.com> Message-ID: Michael: Thanks, split on would work nicely. I probably should have backed up in my reasoning process to say that my real task is to replace a data item in a list with another altered data item in the same position, or rather in FP, create a new list with the altered item in the same place. And I need a predicate to find the name of the item I want to replace. Any thoughts? Thanks, Geoffrey On Feb 28, 2015 9:08 AM, "Michael Orlitzky" wrote: > On 02/27/2015 03:51 PM, Geoffrey Bays wrote: > > Hi. > > An elementary question here about two functions in Data.List: > > how to use a value from findIndex which returns a Maybe Int, > > and then use that result in splitAt which takes a regular Int? > > Once you understand why you can't feed a (Maybe Int) to a function that > takes an Int, throw it all away and use `splitOn` from the "split" > package instead =) > > https://hackage.haskell.org/package/split-0.2.2/docs/Data-List-Split.html > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Feb 28 15:08:43 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 28 Feb 2015 10:08:43 -0500 Subject: [Haskell-beginners] FFI Problems In-Reply-To: <54F1C085.7020503@nyu.edu> References: <54F1C085.7020503@nyu.edu> Message-ID: On Sat, Feb 28, 2015 at 8:20 AM, Thomas Jakway wrote: > I'm very new to Haskell and am trying to write a "real" program to > motivate myself to learn it better (so far I've only gotten through Project > Euler problems after reading LYAH and most of RWH). I'm using Taglib ( > https://github.com/taglib/taglib) to read the metadata from a music file > and print it. I have a struct C-side (with C linkage) serving as the > bridge between Taglib's C++ and Haskell's FFI. A small demo program > (compiled with gcc and linked against the C++ object files) gives the > correct results, but Haskell is weirdly only getting *some *of it right. > Specifically, the C string fields are working but ints are not. > The raw FFI is unfriendly, but also not really intended for direct use except in very simple cases. You probably want to look into c2hs (or gtk2hsc2hs which is a fork that supports more complex C headers) to generate the FFI declarations, rather than try to manipulate structs directly. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Sat Feb 28 15:19:01 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Sat, 28 Feb 2015 16:19:01 +0100 Subject: [Haskell-beginners] Bounded STM Queues with load shedding In-Reply-To: References: Message-ID: You're probably not on the right mailing list, this seems more appropriate to Haskell-cafe than to Haskell-beginners. On Fri, Feb 27, 2015 at 11:32 PM, Alex Hammel wrote: > Hi list, > > It would be handy for me to have a bounded STM Queue along the lines of > TBQueue > > with the difference that when the queue is full, a call to writeTBQueue is > a non-blocking no-op. > > This is in the context of an asynchronous logging system. If the load > (somehow) gets heavy enough that the log message queue is taking up a lot > of memory, It's better to lose a few log messages than to have processes > block until the logger catches up. > > Are there any off-the-shelf solutions? > > Cheers, > Allex > > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Sat Feb 28 15:52:17 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Sat, 28 Feb 2015 10:52:17 -0500 Subject: [Haskell-beginners] Using findIndex and then splitAt in Data.List In-Reply-To: References: <54F1CBEE.5050806@orlitzky.com> Message-ID: <54F1E431.7000704@orlitzky.com> On 02/28/2015 10:02 AM, Geoffrey Bays wrote: > Michael: > Thanks, split on would work nicely. > > I probably should have backed up in my reasoning process to say that my > real task is to replace a data item in a list with another altered data > item in the same position, or rather in FP, create a new list with the > altered item in the same place. And I need a predicate to find the name of > the item I want to replace. > Any thoughts? > You can define a function to "fix" the thing that you want to alter, and then map that function over the list. Just make sure that the function only alters the thing that you want to alter. For example, suppose the other numbers are afraid of 7, so you want to change 7 into 8 in some list: -- Turn 7 into 8; leave everything else alone. fix_seven :: Int -> Int fix_seven 7 = 8 fix_seven x = x numbers :: [Int] numbers = [1..10] ghci> print $ map fix_seven numbers [1,2,3,4,5,6,8,8,9,10]