gmane.comp.lang.haskell.beginners

Re: Help!,was Re: Trouble with "import qualified"

Michael Orlitzky — 2012-05-24T16:49:59

Try starting from a fresh file? I just tried the simplest thing I could
think of to reproduce this, but it worked:

jumba ~ $ echo "import qualified Data.Map as Map" >> test.hs
jumba ~ $ echo "main = print \"Hello, World\"" >> test.hs
jumba ~ $ runhaskell test.hs
"Hello, World"
jumba ~ $ ghci
GHCi, version 7.4.1: 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> :l test.hs
[1 of 1] Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
"Hello, World"
*Main>

Help!, was Re: Trouble with "import qualified"

Dudley Brooks — 2012-05-24T16:34:22

Hi.  I've had this up for over a week, and haven't received any 
response.  Any help would be greatly appreciated.

On 5/16/12 10:04 PM, Dudley Brooks wrote:

Re: Traverse tree with computing current level using Foldable instance.

Brent Yorgey — 2012-05-24T12:54:23

By the way, for this sort of pattern where you change the state for
some subcomputation and then restore it after the subcomputation
returns, it can be much nicer to use the Reader monad with the 'local'
function instead of the State monad.  That might actually go a long
way towards making the monadic version nicer to read. =)

-Brent

Re: Traverse tree with computing current level using Foldable instance.

Dmitriy Matrosov — 2012-05-24T11:09:24

Hi, Chaddaï. Thanks for the clarification!

Now i think i get it. Here is three my solutions. First one is (as you 
suggest)
without monads:

 > import Data.Monoid
 > import Control.Monad.State
 >
 > data Tape a             =  Tape a [Tape a]
 >
 > foldTape :: (a -> [b] -> b) -> Tape a -> b
 > foldTape f (Tape name ts)
 >                         = f name (map (foldTape f) ts)
 >
 > foldTapeD :: (Monoid m) => (Int -> a -> m) -> Tape a -> m
 > foldTapeD f t           = (foldTape (go f) t) 0
 >   where
 >     go :: (Monoid m) => (Int -> a -> m) -> a -> [(Int -> m)] -> (Int 
-> m)
 >     go f name xs        = \cs ->
 >                           foldr (mappend . ($ (cs + 1))) (f cs name) xs

second one with monadic go function:

 > foldTapeD1 :: (Monoid m) => (Int -> a -> m) -> Tape a -> m
 > foldTapeD1 f t          = fst $ runState (foldTape (go f) t) 0
 >   where
 >     go :: (Monoid m) => (Int -> a -> m) -> a -> [State Int m] -> 
State Int m
 >     go f name xs        = do
 >                             cs <- get
 >                             put (cs + 1)
 >                             foldr (go' (cs + 1)) (return (f cs name)) xs
 >     go' :: (Monoid m) => Int -> State Int m -> State Int m -> State Int m
 >     go' cs mx mz        = do
 >                             x <- mx
 >                             put cs
 >                             z <- mz
 >                             put cs
 >                             return (x `mappend` z)

and the last one with monadic go function and monadic user-defined folding
function:

 > foldTapeD2 :: (Monoid m) => (a -> State Int m) -> Tape a -> m
 > foldTapeD2 f t          = fst $ runState (foldTape (go f) t) 0
 >   where
 >     go :: (Monoid m) =>
 >           (a -> State Int m) -> a -> [State Int m] -> State Int m
 >     go f name xs        = do
 >                             cs <- get
 >                             z <- f name
 >                             put (cs + 1)
 >                             foldr (go' (cs + 1)) (return z) xs
 >     go' :: (Monoid m) => Int -> State Int m -> State Int m -> State Int m
 >     go' cs mx mz        = do
 >                             x <- mx
 >                             put cs
 >                             z <- mz
 >                             put cs
 >                             return (x `mappend` z)

and here is test functions:

 > testTape                :: Tape String
 > testTape                =  Tape "A" [ Tape "B"  [ Tape "C" []
 >                                                 , Tape "F" [Tape "G"
 >                                                               [Tape 
"H" []]]
 >                                                 , Tape "E" []
 >                                                 ]
 >                                     , Tape "D"  [ Tape "I" []]
 >                                     ]
 > testFoldTapeD :: ((Int -> a -> [a]) -> Tape a -> [a]) ->
 >                  Int -> Tape a -> [a]
 > testFoldTapeD ftD i t   = ftD (\cs x -> if cs == i then [x] else []) t
 > testFoldTapeD1 :: ((a -> State Int [a]) -> Tape a -> [a]) ->
 >                   Int -> Tape a -> [a]
 > testFoldTapeD1 ftD i t
 >     = ftD (\x -> get >>= \cs -> if cs == i then return [x] else 
return []) t

Is my answer correct? :)

And at the end it seems, that first (non-monadic) version is much 
simpler and
clearer, than all other. So.. should i use monads here?
Earlier i think, that it's better to use them, but now i doubt.

--
     Dmitriy Matrosov

_______________________________________________
Beginners mailing list
Beginners< at >haskell.org
http://www.haskell.org/mailman/listinfo/beginners

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Bardur Arantsson — 2012-05-24T03:33:38

I don't think anyone's disputing that, it's just that the form of many
of his/her messages + lack of threading means that they'll get ignored
(because they don't make sense without context... which is unavailable)
or that KC will get killfiled (after seeing enough "meaningless"
messages from a person this tends to happen). Which would be a shame.

Regards,

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Tom Murphy — 2012-05-24T03:24:04

Just to play devil's advocate, if you look back at the list, KC has
written a lot of helpful and informative messages in the past.

Tom

On 5/23/12, Bardur Arantsson <spam< at >scientician.net> wrote:

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Bardur Arantsson — 2012-05-24T02:39:34

Right. I was actually just about to respond to (only) KC in person, but
perhaps unwisely, decided to "hijack" your response to add a little
explanation for everyone.

You are of course right that not quoting context and just randomly
spewing out small bits of text is not really suitable for a mailing list.

Re: [Haskell-cafe] Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Brandon Allbery — 2012-05-24T02:31:32


That, however, ignores the rest of it; the lack of references in this case
forms a pattern with the other things I noted, in that a conversation is
apparently being held in the form of single observations emitted at the
point of observation instead of being collected and presented *as* a
conversation.

Re: Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

Brandon Allbery — 2012-05-24T02:13:33


Is it me or is this style of message — content broken between subject and
body, no reference information tying it to the presumed topic (or possibly
a /non sequitur/) — better suited to Twitter than a mailing list?

Most C++ compilers will not optimize x^2.0 as x*x but instead will do an expensive ...

KC — 2012-05-24T01:47:31

exponentiation and logarithm.

So, I believe this C++ versus Haskell versus (your language of choice) is a
Penn & Teller misdirection.

Whereas, another level of indirection solves everything.

Re: Traverse tree with computing current level using Foldable instance.

Chaddaï Fouché — 2012-05-23T16:48:27

So, you wrote it correctly :


This appears desperate since there's no mention of Int anywhere in
this function and the function applied stay the same whatever the
level : the initially given f parameter.
But there's a trick to this, we'll have to treat some of our type
variable like functions, here only b can vary freely (a is imposed by
the Tape a inputted), so let's see what it looks like if we make it a
functional type (with Int parameter):


much more promising wouldn't you say ? The solution now looks like that :


I let you write your solution (if you didn't find before tomorrow
evening, I'll give you the answer).

You can then call foldTapeD thus :


(much nicer than your initial solution, is it not ?)

Re: Traverse tree with computing current level using Foldable instance.

Dmitriy Matrosov — 2012-05-23T10:51:02

Hi, Brent, and thanks for the answer! I've tried to define foldTape and then
foldMapS2 using it, i've tried.. ugh, i think everything, with fold and with
map, but i still can't.

Well, this is the whole story. I repeat part of the previous message, 
since i
refer to it later. Here is my tree definition, test tree and test function:

import Data.Monoid
import Control.Monad.State

type TpName             =  String
type TpLevel            =  Int
type TpState a          =  State TpLevel a
data Tape a             =  Tape a [Tape a]

Found quote: "One of the ineradicable illusions about C++ is that the compiler should be able to see through ...

KC — 2012-05-23T06:48:21

all the abstractions and obfuscations an “advanced” C++ program contains.
First and foremost, C++ should be seen as a language that enables complexity
management. The features one has grown fond of in this concept, like
operator
overloading, object orientation, automatic construction/destruction, etc.,
are however
mostly unsuitable for efficient low-level code."

From "Introduction to High Performance Computing for Scientists and
Engineers" CRC Press, 2011.

So if one avoids such C++ complexity management features and a Haskell
compiler can see through most of the complexity management features of
Haskell; they should be comparable. :)


Casey

Re: From some "High-Performance Computing" book; "It is hard to eradicate from C++'ers the need for objects, classes, etc. ..."

Homero Cardoso de Almeida — 2012-05-22T19:20:14

Imho, the quote is slightly wrong.

A more correct one would be "It is hard to erradicate from *object-oriented
programmers* the need for objects, classes, etc...".

See, those who came to C++ with a background from C (me included) don't
have a lot of trouble filtering through useful abstractions and over
engineering. C++ is a multi-paradigm programming language after all, and
does not enforce an object-oriented architecture.

The problem is that much more of the C++ developers these days come with a
background of (almost) pure OO languages, looking for more performance.
Specially Java.

If you code C++ like you code in Java, you will have all the pitfalls of
over-engineering over you.

I haven't learned much of haskell myself, I have more of a curiosity than a
need to learn it. But just trying to solve some simple exercises and
forcing yourself to break your code into simpler, smaller function flows,
has already done marvels to me.

One of these days I started a new, private project in C++. I started
thinking with classes and suddenly got overwhelmed with all the flows and
small objects that had to be created and such. Then I stopped and thought
"What's the simplest way of doing it?" and then I remembered Haskell. God,
it's so much simpler working just with STL containers and plain old
functions!

Sooner or later I had to create a type myself, but after all it seemed just
right and just contributed to the application design, not getting in the
way of the code logic. This is the "right" way of programming: use the
right tools for the job.

Does it make sense to have a class to encapsulate something that could be
represented by a simple string object? Then create this class. Otherwise,
stick with the what you already have available and use functions.

Homero Cardoso de Almeida

--------------------------------------------------------------------------------
    B.el Ciência da Computação - UNIFEI 2006
--------------------------------------------------------------------------------

"Yeah. I can fly."
       -- Iron Man
+ homerocda< at >gmail.com
+ (19) 8139-3700


On Tue, May 22, 2012 at 4:04 PM, KC <kc1956< at >gmail.com> wrote:

From some "High-Performance Computing" book; "It is hard to eradicate from C++'ers the need for objects, classes, etc. ..."

KC — 2012-05-22T19:04:38

"For high-performance computing you want to avoid such software engineering
abstractions as classes, objects, etc...."

Therefore, I would say, since Haskell makes possible many fine-levels of
abstraction, if the compiler can strip most of these away, then it would
come close to the speed of C (i.e. C++ without most of the software
engineering abstractions).


Still, I remember that quote that, "Another level of indirection solves
everything."

Or

If you're Penn & Teller, "Another level of misdirection solves everything."

Casey

Re: Missing some functions in Hoogle

Paulo Pocinho — 2012-05-22T14:09:48

(...)

Hi.

Hoogle [1] can search by type as well as by name. This currently only
works for standard Haskell libraries.
Hayhoo [2] is a string-based search only but also covers hackage [3].

After testing Hoogle cabal package [4], it can either generate
databases for the current system or fetch the database from the
internet. However, database search only covered standard libraries.
Having search by type in hackage would be great though.

Hope this helps.

--
1. http://www.haskell.org/hoogle/
2. http://holumbus.fh-wedel.de/hayoo/hayoo.html
3. http://hackage.haskell.org/packages/hackage.html
4. http://hackage.haskell.org/package/hoogle

Regards,
Paulo

Re: Traverse tree with computing current level using Foldable instance.

Brent Yorgey — 2012-05-22T02:18:34

You cannot.  Foldable is not general enough; it does not allow you to
define folds which can observe the *structure* of the container being
folded over (such as the level in a tree, the number of children of a
given node, etc.).  It corresponds to simply "flattening" the
structure into a list of elements, turning each of them into a value
of some monoid, and then applying mconcat.

However, you should be able to define a general fold for Tape, with
type

  foldTape :: (a -> [b] -> b) -> Tape a -> b

and then define foldMapS2 in terms of foldTape.

-Brent

Re: [x] and (x:_) for lists -- did you everthink that odd?

Ertugrul Söylemez — 2012-05-22T01:04:30


While a discussion is going on off the list, I would like to publicly
apologize for my rough tone.  I felt offended by the last remark.

Of course I'm not taking back my statement, I just feel like it doesn't
really apply to Anthony's original post.

For questions like this I would recommend writing it in such a way that
the intention is clear.  It was somehow blurred by the rhetorical style.

I also hope that people aren't offended by my mail signature, which
indeed is a bit offensive. =)


Greets,
Ertugrul

Re: [x] and (x:_) for lists -- did youeverthink that odd?

Ertugrul Söylemez — 2012-05-22T01:02:10


I tend to use bracket notation for fixed-length list patterns.



Yes.  It's quite seldom that I use bracket notation, though.  That's
simply because it's seldom that I pattern-match against fixed-length
lists.


Greets,
Ertugrul

Re: [x] and (x:_) for lists -- did you everthink that odd?

AntC — 2012-05-22T00:49:40

[snip ..]

So Ertugrul, as an experienced Haskeller which of these do you put in your 
code for a singleton list (whether appearing in a pattern or as an expression):
    [x]
    (x: [])

Or perhaps you mix them, depending on whether you want to be more suggestive 
of an empty list [] or an unknown-length list (x: xs)?

[.. snippety-snip]

AntC



_______________________________________________
Beginners mailing list
Beginners< at >haskell.org
http://www.haskell.org/mailman/listinfo/beginners

Re: [x] and (x:_) for lists -- did you ever think that odd?

AntC — 2012-05-22T00:36:47

cons-like notation.

Good point Brandon, I should have asked what background and expectations 
people were coming from. From ALGOL, square brackets mean arrays, which are 
close-ish to lists(?)

(For Lispers: does it seem odd using colon? Does it seem odd that dot is 
function composition, not cons pairing?)

I was more getting at the oddness (or perhaps not) of having two different 
notations.


No, I wasn't anywhere near making a "suggestion" or "proposal". Just asking 
for people's impressions.


FWIW, the double-dot notation is not currently valid in a pattern.

I wanted to show something with square brackets. And to my mind, the double-
dot could be taken as an unknown-length tail of the list, like an ellipsis. 
But others (it seems) think of it as enumFrom.

AntC