Dan,
I've been playing around with type families off and on in 6.8, but,
what with
the implementation therein being reportedly incomplete, it's hard to
know
what I'm getting right and wrong, or what should work but doesn't
and so on.
So, I finally decided to take the plunge and install 6.9
A friend and I were working on a Haskell version of
Towers of Hanoi yesterday, and I tried writing out the
program today, but got stuck on outputting newlines as
part of the string; viz:
hanoi :: Int - String
hanoi n = hanoi_helper 'a' 'b' 'c' n
hanoi_helper :: Char - Char - Char - Int
Hi
On Mon, Apr 14, 2008 at 8:22 AM, Benjamin L. Russell
[EMAIL PROTECTED] wrote:
A friend and I were working on a Haskell version of
Towers of Hanoi yesterday, and I tried writing out the
program today, but got stuck on outputting newlines as
part of the string; viz:
| n == 1 =
Benjamin L. Russell wrote:
but got stuck on outputting newlines as part of the string;
quoting is done by the show function in Haskell, so you have to take
care to avoid calling show. your code calls show at two positions:
(1) when you insert the newline into the string
(2) when you output
Ok; much better. Here's my new type signature and
definition:
hanoi.hs:
hanoi :: Int - IO ()
hanoi n = mapM_ putStrLn (hanoi_helper 'a' 'b' 'c' n)
hanoi_helper :: Char - Char - Char - Int -
[String]
hanoi_helper source using dest n
| n == 1 = [Move ++ show source ++ to ++
show
Pablo Nogueira wrote:
This has certainly been taken into account when comparing approaches to
generic programming. I quote from page 18/19 from the work you and Bulat
Indeed I was not aware of it. Missed that. Thanks for pointing it out!
Thus, full reflexivity of an approach is taken into
Hi
mapM_ putStrLn (hanoi 2) -- outputs each move
in a new line
putStrLn (unlines (hanoi 2)) -- same as
previous line
putStr (unlines (hanoi 2))
is what you want. Unlines puts a trailing new line at the end of every
line, including the final one. putStrLn puts an additional
Benjamin L. Russell wrote:
Ok; much better. Here's my new type signature and
definition:
hanoi :: Int - IO ()
hanoi_helper :: Char - Char - Char - Int - [String]
If you want, you can separate the algorithm and the output processing
even more by providing three functions of these types:
Hi
mapM_ putStrLn == putStr . unlines
I'm wondering which (==) you mean here ;)
Expression equality, defined by:
instance (Arbitrary a, Eq b) = Eq (a - b) where
f == g = forall x :: a, f x == g x
Using QuickCheck to generate the values, and an Eq over IO (), which
can be defined
Neil Mitchell wrote:
Unlines puts a trailing new line at the end of every
line, including the final one. putStrLn puts an additional trailing
new line, so you get 2 at the end.
Thanks for that clarification.
mapM_ putStrLn == putStr . unlines
I'm wondering which (==) you mean here ;)
This has certainly been taken into account when comparing approaches to
generic programming. I quote from page 18/19 from the work you and Bulat
Indeed I was not aware of it. Missed that. Thanks for pointing it out!
Thus, full reflexivity of an approach is taken into account. This suggests
When reading the section 10.3 Controlling Evaluation Order in History
of Haskell I thought that the example that justified the 'seq' to be
unrestricted polymorphic was mainly a debugging problem. I wondered if the
better solution would have been to provide an 'unsafeSeq' which has no
type
Hi
unrestricted polymorphic was mainly a debugging problem. I wondered if the
better solution would have been to provide an 'unsafeSeq' which has no type
restriction but must be absent from production code just like 'trace'.
That would be very neat!
type constraints accordingly.
| type constraints accordingly. (Analogously there could be an unsafeShow that
| allows showing offending values in an 'error' without adding a Show
| constraint to the type signature.)
|
| Ideally, unsafeShow could also show types as they are underneath, not
| as a pretty-printing Show might
On 14/04/2008, at 12:19, Simon Peyton-Jones wrote:
| type constraints accordingly. (Analogously there could be an
unsafeShow that
| allows showing offending values in an 'error' without adding a
Show
| constraint to the type signature.)
|
| Ideally, unsafeShow could also show types as
Wow, that's very general. So you want to divide hanoi
into a main function, a helper function, and a display
function.
I tried it out, and got this far so far:
hanoi :: a - a - a - Int - [(a, a)]
hanoi a b c n = hanoi_helper a b c n
hanoi_helper :: a - a - a - Int - [(a, a)]
On Mon, Apr 14, 2008 at 3:27 AM, Adam Langley [EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 6:32 PM, Chris Smith [EMAIL PROTECTED] wrote:
Does old code that handled these headers stop working, just because it
was looking in the other section, but now needs to check a field
Hello,
In describing the Handle type, the GHC documentation says (in the System.IO
documentation):
GHC note: a Handle will be automatically closed when the garbage collector
detects that it has become unreferenced by the program. However, relying on
this behaviour is not generally recommended:
Yes, they are. That's what perhaps Neil Mitchell means by
mapM_ putStrLn == putStr . unlines
And whether the trailing newline is to be called the last blank line depends
upon the convention; The string that is output in both the cases contains a
single newline character. Are you calling that a
On Apr 14, 2008, at 7:51 , Benjamin L. Russell wrote:
hanoi_shower :: Show a = [(a, a)] - String
hanoi_shower [(a, b)] = Move ++ show a ++ to ++ show b ++ .
You've just specified via pattern match that hanoi_shower always gets
a 1-element list. Is that really what you intended?
--
Hi
hanoi_shower [] = ...
hanoi_shower ((a, b) : moves) = ...
or (preferably) with map
hanoi_shower moves = unlines (map show_move moves) where
show_move (a, b) = ...
A nice list comprehension works wonders in these situations:
hanoi_shower moves = unlines [Move ++ show a ++ to
Benjamin L. Russell wrote:
Wow, that's very general. So you want to divide hanoi
into a main function, a helper function, and a display
function.
I tried it out, and got this far so far:
[...]
hanoi_shower :: Show a = [(a, a)] - String
hanoi_shower [(a, b)] = Move ++ show a ++ to ++
On Mon, Apr 14, 2008 at 4:54 AM, Daniel Yokomizo
[EMAIL PROTECTED] wrote:
Both request and response accept any entity headers and 7.1 (of RFC
2616) says that a valid entity header is an extension header, which
can be any kind of header.
Is wasn't suggesting that other headers be dropped,
Is form based file upload supported in HTTP module (HTTP-3001.0.4)?
Adam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
2008/4/14 Abhay Parvate [EMAIL PROTECTED]:
Hello,
In describing the Handle type, the GHC documentation says (in the
System.IO documentation):
GHC note: a Handle will be automatically closed when the garbage collector
detects that it has become unreferenced by the program. However, relying
hanoi :: a - a - a - Int - [(a, a)]
hanoi a b c n = hanoi_helper a b c n
Note that now hanoi is exactly the same function as hanoi_helper, so you may
as well just get rid of hanoi_helper. =)
-Brent
___
Haskell-Cafe mailing list
Hi Haskellers,
today I scrached an itch that was icking for a while: When I submit
patches to some project or person, I’m never sure that I won’t forget
checking that the patch will actually be applied. But if I forget, and
the maitainer forgets (or decides against), my patch would be lost.
Here's part of a pencil-and-paper proof of laws for a state monad.
Before doing so, I've got a question of my own about the *other* laws:
Is there a place where somebody has explicitly written the laws that
non-proper morphisms of commonly used monads?
Back to the original question...
Beware.
On Mon, 2008-04-14 at 16:52 -0700, [EMAIL PROTECTED] wrote:
Here's part of a pencil-and-paper proof of laws for a state monad.
Before doing so, I've got a question of my own about the *other* laws:
Is there a place where somebody has explicitly written the laws that
non-proper morphisms of
I'm new to Haskell and trying to get a better understanding of sharing
(and ultimately memoization). I've read SOE and various of the
tutorials, as well as browsing around the wiki and old mailing lists.
Most of the examples of memoization seem to revolve around Fibonacci,
and are based
Patrick Surry wrote:
I've seen other discussions that suggest that lists are always shared
while in scope (so the fibs trick works). But is that just a feature of
the standard compilers, or is it somewhere mandated in the Hakell spec
(I don't see anything obvious in the Haskell Report tho
Now it works; viz (in response to Brent Yorgey's
suggestion, I have merged hanoi and hanoi_helper):
hanoi_general_list_comprehension_unwords.hs (based on
Neil Mitchell's suggestion, except for the trailing
'.'):
hanoi :: a - a - a - Int - [(a, a)]
hanoi source using dest n
| n == 1 =
On 14/04/2008, at 9:22 PM, pepe wrote:
Alternatively, with some effort one can create a type-agnostic
version of unsafeShow, which would print things in a more raw
format, but probably sufficient anyway. I don't think it would work
with unboxed values in general, although it can be made to
I'm running into this in some code I wrote. What does it mean? It says
to look at -fspec-constr-count, but that flag doesn't seem to be in the
GHC documentation.
This isn't critical; the code still seems to work fine. It just makes
the build uglier.
Thanks. Message below.
SpecConstr:
On Apr 14, 2008, at 23:45 , Benjamin L. Russell wrote:
hanoi_shower :: Show a = [(a, a)] - String
hanoi_shower ((a, b) : moves)
| null moves = Move ++ show a ++ to ++ show b ++ .
| otherwise == Move ++ show a ++ to ++ show b ++ . ++
hanoi_shower moves
`==' after the
On Tue, Apr 15, 2008 at 3:45 AM, Benjamin L. Russell
[EMAIL PROTECTED] wrote:
hanoi_shower ((a, b) : moves)
| null moves = Move ++ show a ++ to ++ show
b ++ .
| otherwise == Move ++ show a ++ to ++ show
b ++ . ++ hanoi_shower moves
More idiomatic pedantry: the way you will see
36 matches
Mail list logo
