Useful: putCharLn {inspire by the Int->[Char] thread

The thread on the use of "show" and print to display an Int value, brought up a problem I had early on... the one of cleanly displaying a Char value, on a line all by itself.. My first attempts: This was just plain hard to read: with the character t being where it was: Prelude> putChar $ head "this and that" tPrelude> ----------------------- So I tried this and of course ... type mismatch: Prelude> putStrLn $ head "this and that" <interactive>:1:16: Couldn't match `String' against `Char' Expected type: [String] Inferred type: [Char] In the first argument of `head', namely `"this and that"' In the second argument of `($)', namely `head "this and that"' ---------------------- So I did this... to manually turn it to a string and it does work, but a little cumbersome to work into other function calls: Prelude> putStrLn $ (head "this and that"):[] t ------------- so the definition of putCharLn came to life {may be in some library already and I just haven't found it yet.. but it is in my toolbox now}: Prelude> let putCharLn c = putStrLn (c:[]) Prelude> and an application of it: Prelude> putCharLn $ head "this and that" t --------------- now I also have the char to string conversion alone: c2Str c = c:[] Prelude> let c2Str c = c:[] Prelude> c2Str 'A' "A" ------------------ Now this is almost too trivial a thing to mention these gizmos... what with all the monadic constructions that greater minds toss about on this list.. and I am trying to get understanding of that still, but .... sometimes we just accept the unacceptable little irritants rather than just code a solution, no matter how simple it is. There are probably troves of simple workarounds out there that seem too trivial to mention but hey, share 'em... might hit a guy like me that says. "now why didn't I think to do that?" happy days, gene

c2Str c = c:[]
This function is often known as box, its much more general than char to string, it puts any single element in a list like box
... or 'return', which is in the Prelude already, but which is even more general, it puts any single element into any (dare I say it) monad, where a list is one example. :-) /Niklas

On Sat, 19 Aug 2006 19:21:36 +0200, Gene A
Prelude> putStrLn $ (head "this and that"):[]
Or you could use: putStrLn [head "This and that"] -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ -- Using Opera's revolutionary e-mail client: https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433

On 8/19/06, Henk-Jan van Tuyl
Or you could use: putStrLn [head "This and that"]
Gotta say I really like this ... running the head function inside of the list... Okay so I can really learn something here... what would that look like in "raw" monadic notation? using bind and such notation... >>= etc.. hey, mention was made of lists being monads.. so .... gene

yumagene:
On 8/19/06, Henk-Jan van Tuyl
wrote: Or you could use: putStrLn [head "This and that"]
Gotta say I really like this ... running the head function inside of the list... Okay so I can really learn something here... what would that look like in "raw" monadic notation? using bind and such notation... >>= etc.. hey, mention was made of lists being monads.. so ....
Perhaps: putStrLn . return . head $ "This and that" -- Don

This might be easier: Prelude> putStrLn $ return $ head "this and that" t Prelude> Gene A wrote:
The thread on the use of "show" and print to display an Int value, brought up a problem I had early on... the one of cleanly displaying a Char value, on a line all by itself.. My first attempts:
This was just plain hard to read: with the character t being where it was:
Prelude> putChar $ head "this and that" tPrelude> ----------------------- So I tried this and of course ... type mismatch:
Prelude> putStrLn $ head "this and that" <interactive>:1:16: Couldn't match `String' against `Char' Expected type: [String] Inferred type: [Char] In the first argument of `head', namely `"this and that"' In the second argument of `($)', namely `head "this and that"' ---------------------- So I did this... to manually turn it to a string and it does work, but a little cumbersome to work into other function calls: Prelude> putStrLn $ (head "this and that"):[] t ------------- so the definition of putCharLn came to life {may be in some library already and I just haven't found it yet.. but it is in my toolbox now}:
Prelude> let putCharLn c = putStrLn (c:[]) Prelude> and an application of it:
Prelude> putCharLn $ head "this and that" t --------------- now I also have the char to string conversion alone:
c2Str c = c:[]
Prelude> let c2Str c = c:[] Prelude> c2Str 'A' "A" ------------------ Now this is almost too trivial a thing to mention these gizmos... what with all the monadic constructions that greater minds toss about on this list.. and I am trying to get understanding of that still, but .... sometimes we just accept the unacceptable little irritants rather than just code a solution, no matter how simple it is. There are probably troves of simple workarounds out there that seem too trivial to mention but hey, share 'em... might hit a guy like me that says. "now why didn't I think to do that?"
happy days, gene _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

hi, Now, is there a speed or "cleaness of code" advantage to using the function composition method using (.) : putStrLn . return . head $ "This and that" over the application method...using ($): putStrLn $ return $ head "this and that" some thoughts on that ... they both work.. but any advantage or disadvantage to one over the other.. I find a lot of these kind of things in Haskell, and it is purely wonderful.. but always go away wondering if I am really using the most efficient, or most acceptable method.. gene

On Mon, Aug 21, 2006 at 04:31:42PM -0700, Gene A wrote:
hi, Now, is there a speed or "cleaness of code" advantage to using the function composition method using (.) : putStrLn . return . head $ "This and that" over the application method...using ($): putStrLn $ return $ head "this and that"
some thoughts on that ... they both work.. but any advantage or disadvantage to one over the other.. I find a lot of these kind of things in Haskell, and it is purely wonderful.. but always go away wondering if I am really using the most efficient, or most acceptable method.. gene
There is no difference with any good compiler. (.) is always inlined and the types are fixed by the 'putStrLn' so all the overloaded will be gotten rid of. You can pretty much write code in whatever style you want in haskell and count on the compiler to optimize it to be as efficient as possible. The things the compiler can't optimize are usually general inefficient algorithms, not matters of style. There is no need to second guess the compiler for the most part. And certainly not until after you have done profiling or looked at the core and actually seen there is an issue. John -- John Meacham - ⑆repetae.net⑆john⑈

John, Thanks very much for that bit of insight. I am not really writing anything right now that is in more hurry than what Haskell can handle nicely. I was feeling a bit guilty as, Shao said, I use $ over (.) and thought that my code could get some amount of ridicule as to style... when it gets a look by guru types.. Now I can just say, "Hey, it is just my style!".. I have written things that involved lists, where it was building and rebuilding lists of some length that took lots of time.. but that had nothing to do, as you had said with the syntax I chose to use. it would seem that the big ones are things like ordering placements to take advantage of tail recursion and such are more the issue.. and using more efficient data structures than a "straight" list when appropriate. Since you know this sort of thing... Point Free, does that end up being the exact same code after the compiler gets done with it.. I assume it must, but ... ?? Does it cause the compiler less or more work to get to that resultant code.. hmmm thanks, gene
participants (7)
-
dons@cse.unsw.edu.au
-
Gene A
-
Henk-Jan van Tuyl
-
John Meacham
-
Neil Mitchell
-
Niklas Broberg
-
Shao Chih Kuo