Re: [Haskell-cafe] Non-technical Haskell question
Looks like your right, I thought cabal was just a library packaging standard, but it appears to have an on-line archive... I guess the real question is, can i do: cabal install <package> (or equivalent) and have all dependancies and the package I want downloaded, configured, compiled, and installed on my system, such that I only have to type the one command and then I can start using the library straight away? (like with install <blah> in CPAN....) Keean. Arthur van Leeuwen wrote:
Aren't the Hackage and Cabal projects supposed to lead to something like that? http://www.haskell.org/cabal
Doei, Arthur.
On Fri, Dec 03, 2004 at 11:26:49AM +0000, Keean Schupke wrote: <quoting was damaged>
Arthur van Leeuwen wrote:
Aren't the Hackage and Cabal projects supposed to lead to something like that? http://www.haskell.org/cabal Looks like your right, I thought cabal was just a library packaging standard, but it appears to have an on-line archive... I guess the real question is, can i do:
cabal install <package>
(or equivalent) and have all dependancies and the package I want downloaded, configured, compiled, and installed on my system, such that I only have to type the one command and then I can start using the library straight away? (like with install <blah> in CPAN....)
I think it's an absolutely horrible idea since it goes against strong package management. The mess CPAN makes is probably an even stronger reason for me hating perl than the language itself. That may of course just be an implementation problem. As long as it allows good packages to be made by vendors (and users, of course) easily it should cause no great damage.
[Newbie warning on] Here's a few random obeservations from my playing with Haskell: 1. Switched to exploring Haskell from SML after finding out that it supports polymorphism in contrast to SML and has nicer syntax. Good. 2. Frequently saw a "quick sort" implementation in Haskell as a proof for its nice syntax. Realized that an implementation in Smalltalk would have been as nice. 2. Tried to implement a "modular arithmetic" module. Soon realized that a type parameterized over the modulus would be cool. Found out that it could be done, is rather tricky (to an extent that I don't really understand it) and requires non-standard extensions to Haskell '98. 3. Considered Haskell as a replacement for an untyped DSL used in financial services. Soon realized that generic programming (e.g. sum premium over all covers) was not possible and everything would have to be explicit. Bad. Recently discovered "scrap your boilerplate". Sounds like the solution but again requires nonstandard extensions. 4. Tried to implement the "game of nim", my version of "hello world", in Haskell. My god, this even works out nicer than in Prolog! But: in order to make it efficient a function needs to be memoized. Tried to implement a generic function memoizer using FiniteMap and Monads. Didn't get it right, might be me lacking intellect. Recently found a memoization modulue in Hugs, but no docs. There's a reference to the Haskell '97 Report, but I didn't find it online. 5. Again Haskell as a replacement for DSL: the error messages give too little hint about what's wrong, thus inadequate for DSL users. This foils all the benefits of type inference. 6. While googeling for solutions w.r.t. Haskell I saw a lot of "papers" using scientific style. There's nothing wrong with papers but I'm glad that cooking receipts usually use a simpler style. 7. There's a lot of discussion w.r.t state, at least on this list. Is threading state through many functions respectivley polluting many functions with monads the solution? My overall impression is that Haskell has a very nice syntax and offers sophisticated concepts (i.e.non-strictness, type inference) making it attractive for computer science. But for most real-world applications it is intellectually too demanding (me included). There is hope though. Haskell seems to be in a state of adaptilbiliy. And it may influence other languages. BTW: here's that sweet (but inefficient) Haskell code for the "game of nim":
moves [] = [] moves (x:xs) = xs:[y:xs | y <- [1..x-1]] ++ [x:z | z <- moves xs] win [] = True win x = foldr ((||) . not . win) False (moves x)
To find your next move, consider
filter (not . win) (moves [1,2,2])
On 2004 December 05 Sunday 18:19, Rolf Wilms wrote:
[Newbie warning on] Here's a few random obeservations from my playing with Haskell: You've got into Haskell with unusual rapidity. Most of your observations are fairly aimed.
Recently found a memoization modulue in Hugs, but no docs. There's a reference to the Haskell '97 Report, but I didn't find it online. http://www.cse.ogi.edu/~jl/ACM/Haskell.html http://www.cse.ogi.edu/~byron/memo/dispose.ps
7. There's a lot of discussion w.r.t state, at least on this list. Is threading state through many functions respectivley polluting many functions with monads the solution? If a function is pure, there's never any need to involve it with a monad. Monads don't cause "pollution". They serve to indicate what functions have side effects, while the choice of monad tells what kinds of side effects may occur.
Haskell people enjoy pure functions, but are not shy of side effects, which are recognized as an essential feature of every program. Functions that return monadic values provide an excellent way to organize side effects.
Scott Turner reacts:
7. There's a lot of discussion w.r.t state, at least on this list. Is threading state through many functions respectivley polluting many functions with monads the solution? If a function is pure, there's never any need to involve it with a monad. Monads don't cause "pollution". They serve to indicate what functions have side effects, while the choice of monad tells what kinds of side effects may occur.
Haskell people enjoy pure functions, but are not shy of side effects, which are recognized as an essential feature of every program. Functions that return monadic values provide an excellent way to organize side effects.
===================== Please. DON'T reduce Monads to side effects. This is the domain of the IO Monad <<et consortes>>, but Monads have many other applications/faces you most certainly know about. Jerzy Karczmarczuk
participants (5)
-
Harri Haataja -
karczma＠info.unicaen.fr -
Keean Schupke -
Rolf Wilms -
Scott Turner