[Haskell-cafe] The (>|) function in Control.Parallel.Strategies

[Wei Hu]

The documentation of (>|) says that it "evaluates the first argument
before the second". The function is defined as
(http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/parallel/src/Control-Parallel-Strategies.html#%3E|):

(>|) :: Done -> Done -> Done
{-# INLINE (>|) #-}
(>|) = Prelude.seq

I'm curious why it's defined as Prelude.seq, instead of pseq? The
semantics seems to require pseq here. I also found the following
comment that doesn't make sense to me:

The operators >| and >|| are alternative names for `seq` and `par`.
With the introduction of a Prelude function `seq` separating the Prelude
function from the Strategy function becomes a pain. The notation also matches
the notation for strategic function application.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Sebastian Sylvan]

On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier  wrote:

> Gregory Collins wrote:
>
>> Tom Davie  writes:
>>
>>
>>
>>> On 10/31/09, Magicloud Magiclouds 
>>> wrote:
>>>
>>>
 After all, I never think OO as an oppsite way to all other things. The
 idea is so general that if you say I cannot use it in Haskell at all,
 that would make me feel weird. The only difference between languages
 is, some are easy to be in OO style, some are not.


>>> Wow, someone drank the cool aid!
>>>
>>>
>>
>> Doing OO-style programming in Haskell is difficult and unnatural, it's
>> true (although technically speaking it is possible). That said, nobody's
>> yet to present a convincing argument to me why Java gets a free pass for
>> lacking closures and typeclasses.
>>
>> G.
>>
>>
> Because most programmers have never heard of closures and typeclasses, and
> thus have no idea how useful they are? :-(
>
> BTW using existential types in Haskell you can mimic OO to a pretty decent
> degree, at least as far as interfaces are concerned.
>

I kind of wish we had some convenience notation for doing value-based
dispatch like that Something like

foo :: [  ] -> String
foo xs = concatMap show xs

> foo [ 5, True, 1.3 ]
"5True1.3"


(where wrapping a class up in angle brackets makes it into an existentially
qualified wrapper, which is instantiated in the class itself -- maybe we
need explicit conversion from e.g. Int to  though...)

You don't need it very often, but I wonder if that's because there genuinely
isn't a need, or if you tend to avoid writing code in ways which would need
it (ask a Java programmer, and they'll probably tell you that the need for
type classes and closures don't come up very often - which is clearly untrue
for a Haskell programmer).

-- 
Sebastian Sylvan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Michael Vanier]

Gregory Collins wrote:

Tom Davie  writes:

  

On 10/31/09, Magicloud Magiclouds  wrote:


After all, I never think OO as an oppsite way to all other things. The
idea is so general that if you say I cannot use it in Haskell at all,
that would make me feel weird. The only difference between languages
is, some are easy to be in OO style, some are not.
  

Wow, someone drank the cool aid!



Doing OO-style programming in Haskell is difficult and unnatural, it's
true (although technically speaking it is possible). That said, nobody's
yet to present a convincing argument to me why Java gets a free pass for
lacking closures and typeclasses.

G.
  
Because most programmers have never heard of closures and typeclasses, 
and thus have no idea how useful they are? :-(


BTW using existential types in Haskell you can mimic OO to a pretty 
decent degree, at least as far as interfaces are concerned.


Mike


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Gregory Collins]

Tom Davie  writes:

> On 10/31/09, Magicloud Magiclouds  wrote:
>> After all, I never think OO as an oppsite way to all other things. The
>> idea is so general that if you say I cannot use it in Haskell at all,
>> that would make me feel weird. The only difference between languages
>> is, some are easy to be in OO style, some are not.
>
> Wow, someone drank the cool aid!

Doing OO-style programming in Haskell is difficult and unnatural, it's
true (although technically speaking it is possible). That said, nobody's
yet to present a convincing argument to me why Java gets a free pass for
lacking closures and typeclasses.

G.
-- 
Gregory Collins 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: mecha-0.0.1

[Luke Palmer]

Neat!  What a cool idea.

On Sat, Oct 31, 2009 at 5:27 PM, Tom Hawkins  wrote:
> Mecha is a little solid modeling language intended for machine design.
>  Mecha has two layers: a pure functional layer for defining solids
> (aka. parts), and a monadic layer for arranging parts into assemblies.
>  Solids (parts) are built using set operations on solid primitives.  A
> solid primitives is simply a predicate that says whether a point in
> space is inside the solid:
>
> data Solid = Solid (Vector -> Bool)

With a type like this, how is it possible to make solids without hard edges?

> Mesh generation is performed by adaptive marching cubes.
>
> It's slow, especially if you don't have graphics hardware.  And solids
> with hard edges don't render very clean.  But the basics work.
>
> Here's a simple example:
>
> example :: IO ()
> example = view design
>
> design :: Asm ()
> design = do
>  a <- part 1   0.06 8 $ difference sphereCube cyl3
>  b <- part 1   0.08 8 $ sphereCube
>  c <- part 1.5 0.08 8 $ cyl3
>  color (0, 0, 0.8) $ place a
>  move (-4, 0, 0) $ color (0.8, 0, 0) $ place b
>  move ( 0, 4, 0) $ color (0, 0.8, 0) $ place c

Why did you choose a monadic interface?  Is there a technical or
semantic problem with a statement like:

design =
let a = part 1 0.06 8 $ difference sphereCube cyl3
b = part 1 0.08 8 $ sphereCube
c = part 1.5 0.08 8 $ cyl3
in mconcat [ color (0, 0, 0.8) a
   , move (-4, 0, 0) . color (0.8, 0, 0) $ b
   , move (0, 4, 0) . color (0, 0.8, 0) $ b
   ]

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newcomers question

[Daniel Peebles]

For some reason, Show and Eq are superclasses of Num (despite Num not
actually using any of their methods), meaning that the compiler forces
you to write instances of Eq and Show before it even lets you write a
Num instance. I don't think anybody likes this, but I think we're
stuck with it for the foreseeable future.

On Sat, Oct 31, 2009 at 7:31 PM, b1g3ar5  wrote:
> I'm trying:
>
> instance Num b => Num (a -> b) where
> fromInteger = pure . Prelude.fromInteger
> negate = fmap Prelude.negate
> (+) = liftA2 (Prelude.+)
> (*) = liftA2 (Prelude.*)
> abs = fmap Prelude.abs
> signum = fmap Prelude.signum
>
> but the compiler rejects it with:
>
> src\Main.hs:24:9:
>    Could not deduce (Show (a -> b), Eq (a -> b))
>      from the context (Num b)
>      arising from the superclasses of an instance declaration
>                   at src\Main.hs:24:9-29
>    Possible fix:
>      add (Show (a -> b), Eq (a -> b)) to the context of
>        the instance declaration
>      or add an instance declaration for (Show (a -> b), Eq (a -> b))
>    In the instance declaration for `Num (a -> b)'
>
> Could someone please explain this to me?
>
> I thought that it might be that it couldn't work out the functions
> necessary for (a->b) to be in the classes Show and Eq - so I tried
> adding definitions for == ans show, but it made no difference.
>
> Thanks
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newcomers question

[Henning Thielemann]

On Sat, 31 Oct 2009, b1g3ar5 wrote:


I'm trying:

instance Num b => Num (a -> b) where
fromInteger = pure . Prelude.fromInteger
negate = fmap Prelude.negate
(+) = liftA2 (Prelude.+)
(*) = liftA2 (Prelude.*)
abs = fmap Prelude.abs
signum = fmap Prelude.signum

but the compiler rejects it with:

src\Main.hs:24:9:
   Could not deduce (Show (a -> b), Eq (a -> b))
 from the context (Num b)
 arising from the superclasses of an instance declaration
  at src\Main.hs:24:9-29
   Possible fix:
 add (Show (a -> b), Eq (a -> b)) to the context of
   the instance declaration
 or add an instance declaration for (Show (a -> b), Eq (a -> b))
   In the instance declaration for `Num (a -> b)'

Could someone please explain this to me?

I thought that it might be that it couldn't work out the functions
necessary for (a->b) to be in the classes Show and Eq - so I tried
adding definitions for == ans show, but it made no difference.


You have to define instances for Show and Eq, that is methods 'show' and 
(==), because the Num class has these classes as superclasses. This has 
been criticised a lot and is e.g. not the case in NumericPrelude. However, 
I would not seriously define a Num instance for functions:

   http://www.haskell.org/haskellwiki/Num_instance_for_functions
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Advgame 0.1.1

[Tim Wawrzynczak]

Hey cafe,

If any of you were (or are) Common Lispers, you may be aware of Dr. Conrad
Barski's humorous and lighthearted
approach to Common Lisp.  As a little tribute to his CL evangelization
efforts, I ported his tutorial,
'Casting SPELs in Lisp' (http://www.lisperati.com/casting.html) to Haskell.
It works very similarly to his final program,
except it can be run in a loop, instead of one function at a time.  It's
available at http://hackage.haskell.org/package/Advgame-0.1.1
if anyone is interested.

Cheers,
 - Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Newcomers question

[b1g3ar5]

I'm trying:

instance Num b => Num (a -> b) where
fromInteger = pure . Prelude.fromInteger
negate = fmap Prelude.negate
(+) = liftA2 (Prelude.+)
(*) = liftA2 (Prelude.*)
abs = fmap Prelude.abs
signum = fmap Prelude.signum

but the compiler rejects it with:

src\Main.hs:24:9:
Could not deduce (Show (a -> b), Eq (a -> b))
  from the context (Num b)
  arising from the superclasses of an instance declaration
   at src\Main.hs:24:9-29
Possible fix:
  add (Show (a -> b), Eq (a -> b)) to the context of
the instance declaration
  or add an instance declaration for (Show (a -> b), Eq (a -> b))
In the instance declaration for `Num (a -> b)'

Could someone please explain this to me?

I thought that it might be that it couldn't work out the functions
necessary for (a->b) to be in the classes Show and Eq - so I tried
adding definitions for == ans show, but it made no difference.

Thanks


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: mecha-0.0.1

[Tom Hawkins]

Mecha is a little solid modeling language intended for machine design.
 Mecha has two layers: a pure functional layer for defining solids
(aka. parts), and a monadic layer for arranging parts into assemblies.
 Solids (parts) are built using set operations on solid primitives.  A
solid primitives is simply a predicate that says whether a point in
space is inside the solid:

data Solid = Solid (Vector -> Bool)

Mesh generation is performed by adaptive marching cubes.

It's slow, especially if you don't have graphics hardware.  And solids
with hard edges don't render very clean.  But the basics work.

Here's a simple example:

example :: IO ()
example = view design

design :: Asm ()
design = do
  a <- part 1   0.06 8 $ difference sphereCube cyl3
  b <- part 1   0.08 8 $ sphereCube
  c <- part 1.5 0.08 8 $ cyl3
  color (0, 0, 0.8) $ place a
  move (-4, 0, 0) $ color (0.8, 0, 0) $ place b
  move ( 0, 4, 0) $ color (0, 0.8, 0) $ place c

sphereCube = intersection sphere $ scaleXYZ 0.75 cube
cyl = scale (0.5, 0.5, 1.2) $ cylinder
cyl3 = unions [cyl, rotateX (pi / 2) cyl, rotateY (pi / 2) cyl]


Screenshot: http://tomahawkins.org/


Enjoy!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Suggested algorithm to control upper bound of space "leaks"

[Shelby Moore]

http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Shelby Moore wrote:
> One possible runtime optimization to provide an upper bound for cache
> control, might be to not cache thunks when the runtime computation time
> times number of cache hits, is less than the round-trip paging time
> multiplied by recent system paging load.
>
> Is this novel?  Is it useful?

Clarify and improve:

One possible idea for runtime optimization to provide a more deterministic
upper bound on paging load for cache control, might be to not cache
thunk-wise when for each thunk, the total tree of computation time under
the thunk multiplied by the number of cache hits on the thunk, is less
than the round-trip paging time of thunks under the tree multiplied by a
chosen factor of recent system paging load.  Or toggle the test on and off
on a chosen threshold of recent system paging load.

Obviously "heap size" could be substituted for "paging load", but my goal
is to make the optimization resolution independent, i.e. orthogonal to
system configuration such as RAM size, speed, virtual media size,
algorithm, etc..

The "catch-22" of the idea if any, probably derives from the permutations
of computation time from the lazy computation of thunks under the tree?

Note I realize this list is probably not the correct place to discuss
research.  I do not have time to do this research.  Any suggestion where I
could post or send this idea so people interested in this type of research
could see it?  Add a feature request to GHC bug tracker?  To the general
Haskell mailing list?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Shelby Moore]

Shelby Moore wrote:
> The most accurate question should be, "How do you add some numbers with
> minimized instructions?", because it forces them to realize they must
> order the set.
>
> An answer might be, "Zero if empty, else order the set, sum the first
> number with the sum of remainder of the set. Repeat for the sum of
> remainder."

Realize that I did not write "sort" order.  I am refering to "queue" order
that allows the "first" distinction.  Also by "remainder" means "remaining
portion of" (you are dividing the queue-ordered set by it's "tail" and
thus "head" is the remainder).

I just returned from 130 pushups and 1.2 mile run, and it was more
difficult since I've not gotten out my thinking-cap chair for past 2
weeks.  I wonder if our mental and physical exertion competes for the
limited velocity at which our body can convert fuel to glucose and dump
the cell waste products through the liver?  Many people are already
consumed by other exertions, many which are passive and compulsive (e.g.
TV, reading same topics over and over again which are presented with
superficial differences), which may atrophy their minds in terms of the
brain patterns needed for logical induction.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.

[Shelby Moore]

I found the post at the following link to be the most useful in explaining
declarative versus imperative:

http://www.haskell.org/pipermail/haskell-cafe/2009-September/067000.html


Here follows what I want to add to the discussion:

http://www.haskell.org/pipermail/haskell-cafe/2009-September/067094.html
John Dorsey wrote:
>> Well, try this: Go ask a random person how you add up a list of numbers.
>> Most of them will say something about adding the first two together,
>> adding the third to that total, and so forth. In other words, the step
>> by step instructions.
>
> You word the (hypothetical) question with a bias toward imperative
> thinking.  You're asking "How do you do this action?"

> Why isn't the question "What is the sum of a list of numbers?",
> which is biased toward the declarative?


Instead ask "How do you add some numbers?"

Then you will more likely get the answer, "add them together".

The disconnect is that most people do not think in terms of details, so if
you ask them to think in terms of how to declare "the order of the
operation over the set in minimized semantics", you will push them into an
area which they are not specialized.  I have read the claim that Haskell
tends to attract some of the most talented programmers, because it
resonates with the mindset of people who like to generalize details into
minimum rulesets.

The most accurate question should be, "How do you add some numbers with
minimized instructions?", because it forces them to realize they must
order the set.

An answer might be, "Zero if empty, else order the set, sum the first
number with the sum of remainder of the set. Repeat for the sum of
remainder."

The real leap for me (not using my college math recently), and I am sure
for most imperative programmers and people in general, is go from the
recursive declaration above, to the notion that the declaration __IS__ the
sum and does not just _return_ or output the sum.  That notion becomes
important when the declaration is not a single number result, instead a
set.  That is important because there is no way to _return_ an infinite
set.  The mind gets stuck on the recursive declaration of infinite sets,
such as fibonacci, unless one comes from a mathematical mindset.  Math is
a muscle, it atrophies if you do not exercise it.  And similarly to
competitive muscles and aerobic capacity (speaking from my own
experience), it only takes a little bit of exercise to get back to about
60% of former peak ability after a long period of no exercise.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] AND/OR Perceptron

[Chaddaï Fouché]

On Sat, Oct 31, 2009 at 8:09 PM, Ryan Ingram  wrote:
>
> "where" is just syntactic sugar for "let...in"

That's not perfectly true : "where" and "let...in" don't attach to the
same syntactic construction, "where" attaches to a definition and can
works for several guard clauses whereas "let ... in expression" is an
expression in itself.

-- 
Jedaï
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Applicative but not Monad

[Ryan Ingram]

On Sat, Oct 31, 2009 at 8:38 AM, David Menendez  wrote:

> On Sat, Oct 31, 2009 at 6:22 AM, Heinrich Apfelmus
>  wrote:
> > The only possible monad instance would be
> >
> >   return x = Const mempty
> >   fmap f (Const b) = Const b
> >   join (Const b)   = Const b
> >
> > but that's not just  ()  turned into a monad.
>
> This is inconsistent with the Applicative instance given above.
>
> Const a <*> Const b = Const (a `mappend` b)
>
> Const a `ap` Const b = Const a
>
> In other words, Const has at least two Applicative instances, one of
> which is not also a monad.
>

But this "Monad" instance isn't a monad either:

f True = Const [1]
f False = Const [2]

return True >>= f
{- by monad laws -}
= f True
= Const [1]

but by this code

return True >>= f
{- apply return, monoid [a] -}
= Const [] >>= f
{- definition of >>= -}
= join (fmap f (Const []))
{- apply join and fmap -}
= Const []
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] AND/OR Perceptron

[Ryan Ingram]

On Thu, Oct 29, 2009 at 1:32 PM, Hector Guilarte wrote:

> Thanks Tim! I got it! I have never declared a function before in a let ...
> in statement, I always do it in a where after I call it...


"where" is just syntactic sugar for "let...in"

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHC core packages: same core?

[Tim Chevalier]

On 10/13/09, Dimitry Golubovsky  wrote:
> Max,
>
>  Thanks for the explanation. So, the extcore library is expected to
>  match the spec in
>  http://www.haskell.org/ghc/docs/6.10.4/html/ext-core/core.pdf and the
>  core itself can be produced with -fext-core, correct? I think it might
>  be interesting for people working on alternative backends (inlcuding
>  myself).
>

Hi Dimitry,

Sorry for the late reply, but the External Core produced by any
version of GHC newer than 6.10.4 should match the document you cite,
and if it doesn't, I'd like to know about; in that event, please file
a bug report or post to the glasgow-haskell-users list with me CCed.

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"The higher you climb, the more you show your ass." -- Alexander Pope
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] creating documentation links failed with cabal install --haddock-options=--hyperlink-source. is this a bug?

[Thomas Hartman]

cabal haddock -–hyperlink-source

installs documentation with links to source code, which also be on by defualt.

cabal install –haddock-options=–hyperlink source

does not install hyperlinked source.

cabal install –haddock-options=-–hyperlink sourceblehblehbleh

doesn’t throw an error, which suggests to me that the first command
might also be passing the flags with an error.

Whatever the case, seems to me the examples section in cabal --help
should really include examples using --with-PROG and --PROG-options. I
can't find a good one online.

fwiw, cabal install --haddock-option=hyperlink-source DID generate an
error in the output: target `hyperlink-source' is not a module name or
a source file

also, blogged about this here:
http://blog.patch-tag.com/2009/10/23/cabal-install-a-package-with-documentation
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Applicative but not Monad

[David Menendez]

On Sat, Oct 31, 2009 at 6:22 AM, Heinrich Apfelmus
 wrote:
> Dan Weston wrote:
>> Can you elaborate on why Const is not a monad?
>>
>> return x = Const x
>> fmap f (Const x) = Const (f x)
>> join (Const (Const x)) = Const x
>>
>
> This is not  Const , this is the  Identity  monad.
>
> The real  Const  looks like this:
>
>   newtype Const b a = Const b
>
>   instance Monoid b => Applicative (Const b) where
>        pure x = Const mempty
>        (Const b) <*> (Const b') = Const (b `mappend` b')
>
> The only possible monad instance would be
>
>   return x = Const mempty
>   fmap f (Const b) = Const b
>   join (Const b)   = Const b
>
> but that's not just  ()  turned into a monad.

This is inconsistent with the Applicative instance given above.

Const a <*> Const b = Const (a `mappend` b)

Const a `ap` Const b = Const a

In other words, Const has at least two Applicative instances, one of
which is not also a monad.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ghci REPL output under Haskell Platform on Mac OS X

[Mark Lentczner]

My ghci installation has a very annoying behavior: When it takes  
input, the result is displayed on the same line as the input,  
overwriting the prompt and input.  Viz.:


[1015] : ghci
GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
7relude> 3 + 4
Prelude>

Note the 7 that overwrites the P in Prelude.

I have had several prior versions of ghci installed, most recently  
6.10.1, and they never had this problem. (In other words, I saw:


Prelude> 3 + 4
7
Prelude>

Those prior gchi's were installed from the GHC binaries. Most recently  
I decided to give Haskell Platform a try, and I installed that. That  
is the point at which this behavior started.


My environment:

Haskell Platform 2009.2.0.2
GHC 6.10.4 (installed w/Haskell Platform)
Mac OS X 10.6.1

Oddly, I have GHC 6.10.4 installed from GHC binaries on a Mac OS X  
10.5 machine at work, and the newline behavior is correct. So the  
issue could be Haskell Platform vs. GHC installs... or it could be  
10.5  vs. 10.6


Anyone seen anything like this?

- Mark



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Eugene Kirpichov]

Yoda Master tells understands he you not, inheritance naked can be
how, you clarify please asks he to.

2009/10/31 Magicloud Magiclouds :
> Somehow, I agree with you.
> I think inherit is not evil, the people use it wrong is. The problem
> here is, inherit is naked right now. So people could use it wrong.
>
> On Fri, Oct 30, 2009 at 7:42 PM, Yaakov Nemoy  
> wrote:
>> 2009/10/30 Peter Verswyvelen :
>>> The following is purely my own experience, I have no links to papers
>>> of clever people :)
>>>
>>> I think none of the inheritance techniques work perfectly. E.g.
>>> describing everything with OO interfaces (=a extensible record of
>>> function pointers) is also problematic IMHO, at least when you have
>>> side effects.
>>>
>>> The problem with an interface (with side effects) is that people using
>>> the interface tend to depend on the side effects that a particular
>>> implementation of that interface performs. So in order to describe the
>>> "contract" for implementers of an interface, one often has to go into
>>> great detail.
>>>
>>> Also in Haskell it is required that an implementers follows the
>>> "contract" when implementing a type class, e.g. when writing a monad,
>>> you must make sure it follows the monad laws. But  at least in
>>> Haskell, this can be proven, while in OO, one has to hope that the
>>> side effects of an implementation won't cause weird behavior
>>> elsewhere. In practice, this seems to work, most of the time :)
>>>
>>> The evolution of industrial OO the way I see it, is strange. You start
>>> with assembler, in which it is obvious to extend records. Then comes
>>> C, which makes extending records hard to do without casting and
>>> macros. Then C++, which offers insane ways of extending them (virtual
>>> base classes, multiple inheritance, mixins using templates, ...). Then
>>> to make software components more loosely coupled and maintainable,
>>> Corba & COM enters the picture, and you only use interfaces to
>>> communicate with other objects. Of course COM uses reference counting,
>>> so reusable components is actually just an illusion; in order to avoid
>>> memory leaks, you need to know how objects are connected, which
>>> depends on the implementation... In the meantime Java becomes a
>>> succes. Java is basically "back to basics": it tries to address some
>>> of the flaws of complicated OO, has garbage collection, promises
>>> multi-platform caps, and it is very easy to understand, so people
>>> embrace it. Then C# comes along, which initially is almost the same as
>>> Java, except is has closures, but it evolves towards a functional
>>> language with side effects (even Haskell's FRP will be available in
>>> .NET 4.0, with the Rx framework!). Then to manage large and
>>> complicated software, things like "dependency injection" and
>>> "inversion of control" are introduced, and... we're basically back to
>>> COM in a sense, but now with garbage collection.
>>>
>>> So I have the impression that OO is running in circles, and every
>>> iteration tries to pick up some goodies of the previous one, but where
>>> will it end?
>>>
>>> Luckily humans seem to have the ability to get things done, whatever
>>> primitive or flawed tools we get. I guess the brain itself it the best
>>> programming language ;)
>>
>> Looking at this from a feedback circuit perspective, it seems like
>> that industrial programming is just swinging back and forth between
>> two extremes. It appears that at every step someone runs into the
>> limitations of doing things one way and finds a way to orthogonally
>> combine other designs together. For example, there's been alot of work
>> on implementing other languages on top of Java, such as Jython, so
>> different programming methods can be mixed into enterprise Java code.
>> It all swings back and forth because more than one design and paradigm
>> is needed and no single language can really support it all at once.
>>
>> -Yaakov Nemoy
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Tom Davie]

On 10/31/09, Magicloud Magiclouds  wrote:
> After all, I never think OO as an oppsite way to all other things. The
> idea is so general that if you say I cannot use it in Haskell at all,
> that would make me feel weird. The only difference between languages
> is, some are easy to be in OO style, some are not.

Wow, someone drank the cool aid!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Magicloud Magiclouds]

After all, I never think OO as an oppsite way to all other things. The
idea is so general that if you say I cannot use it in Haskell at all,
that would make me feel weird. The only difference between languages
is, some are easy to be in OO style, some are not.

2009/10/31 Andrew Coppin :
> Rogan Creswick wrote:
>> On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
>>  wrote:
>>
>>>  My concern here is about the data member inheriting. In OOP, when I
>>> inherit a class, I also got the members of it. But in haskell, how to
>>> inherit a "data"?
>>>
>>
>> In my experience (almost entirely with Java), it is usually a bad idea
>> to inherit from a class in order to reuse data storage that the parent
>> class provides.  Encapsulation (or a decorator, if you prefer) is
>> often a safer choice.
>
> ...otherwise phrased in OO circles as "people over-use inheritance and
> under-use collaboration".
>
> That said, I'm sure I won't be the first person here to say that
> generally, if you want to write a Haskell program, you should forget all
> about OOP and figure out how to structure it to make the best use of
> Haskell. It's a very different approach to program construction, and it
> requires a different way of thinking.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Magicloud Magiclouds]

Somehow, I agree with you.
I think inherit is not evil, the people use it wrong is. The problem
here is, inherit is naked right now. So people could use it wrong.

On Fri, Oct 30, 2009 at 7:42 PM, Yaakov Nemoy  wrote:
> 2009/10/30 Peter Verswyvelen :
>> The following is purely my own experience, I have no links to papers
>> of clever people :)
>>
>> I think none of the inheritance techniques work perfectly. E.g.
>> describing everything with OO interfaces (=a extensible record of
>> function pointers) is also problematic IMHO, at least when you have
>> side effects.
>>
>> The problem with an interface (with side effects) is that people using
>> the interface tend to depend on the side effects that a particular
>> implementation of that interface performs. So in order to describe the
>> "contract" for implementers of an interface, one often has to go into
>> great detail.
>>
>> Also in Haskell it is required that an implementers follows the
>> "contract" when implementing a type class, e.g. when writing a monad,
>> you must make sure it follows the monad laws. But  at least in
>> Haskell, this can be proven, while in OO, one has to hope that the
>> side effects of an implementation won't cause weird behavior
>> elsewhere. In practice, this seems to work, most of the time :)
>>
>> The evolution of industrial OO the way I see it, is strange. You start
>> with assembler, in which it is obvious to extend records. Then comes
>> C, which makes extending records hard to do without casting and
>> macros. Then C++, which offers insane ways of extending them (virtual
>> base classes, multiple inheritance, mixins using templates, ...). Then
>> to make software components more loosely coupled and maintainable,
>> Corba & COM enters the picture, and you only use interfaces to
>> communicate with other objects. Of course COM uses reference counting,
>> so reusable components is actually just an illusion; in order to avoid
>> memory leaks, you need to know how objects are connected, which
>> depends on the implementation... In the meantime Java becomes a
>> succes. Java is basically "back to basics": it tries to address some
>> of the flaws of complicated OO, has garbage collection, promises
>> multi-platform caps, and it is very easy to understand, so people
>> embrace it. Then C# comes along, which initially is almost the same as
>> Java, except is has closures, but it evolves towards a functional
>> language with side effects (even Haskell's FRP will be available in
>> .NET 4.0, with the Rx framework!). Then to manage large and
>> complicated software, things like "dependency injection" and
>> "inversion of control" are introduced, and... we're basically back to
>> COM in a sense, but now with garbage collection.
>>
>> So I have the impression that OO is running in circles, and every
>> iteration tries to pick up some goodies of the previous one, but where
>> will it end?
>>
>> Luckily humans seem to have the ability to get things done, whatever
>> primitive or flawed tools we get. I guess the brain itself it the best
>> programming language ;)
>
> Looking at this from a feedback circuit perspective, it seems like
> that industrial programming is just swinging back and forth between
> two extremes. It appears that at every step someone runs into the
> limitations of doing things one way and finds a way to orthogonally
> combine other designs together. For example, there's been alot of work
> on implementing other languages on top of Java, such as Jython, so
> different programming methods can be mixed into enterprise Java code.
> It all swings back and forth because more than one design and paradigm
> is needed and no single language can really support it all at once.
>
> -Yaakov Nemoy
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Applicative but not Monad

[Daniel Fischer]

Am Samstag 31 Oktober 2009 12:25:17 schrieb Tom Davie:
> On 10/31/09, Heinrich Apfelmus  wrote:
> > The only possible monad instance would be
> >
> >return x = Const mempty
> >fmap f (Const b) = Const b
> >join (Const b)   = Const b
>
> Your join doesn't seem to have the right type... Unless I'm missing
> something.
>
> Bob

join (Const b :: Const b (Const b a)) = (Const b :: Const b a)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Applicative but not Monad

[Tom Davie]

On 10/31/09, Heinrich Apfelmus  wrote:
> The only possible monad instance would be
>
>return x = Const mempty
>fmap f (Const b) = Const b
>join (Const b)   = Const b

Your join doesn't seem to have the right type... Unless I'm missing something.

Bob
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Applicative but not Monad

[Conor McBride]

Hi

On 30 Oct 2009, at 16:14, Yusaku Hashimoto wrote:


Hello cafe,
Do you know any data-type which is Applicative but not Monad?


[can resist anything but temptation]

I have an example, perhaps not a datatype:
 tomorrow-you-will-know

Cheers

Conor

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Using HaskellDB on Tables that contain same column names

[R . Emre Başar]

Hi all,

I'm trying to create a HaskellDB application for keeping the inventory
of a set of devices. My database includes some tables which have some
columns with same names. Here is an example:

Server: id, name, vendor (fk), model(fk), system_id (always null)
Vendor: id, name
Model: id, name

I'm trying to join those three tables and create a result that contains
the names of the server, vendor and model. I use the projection:

project (Server.name << s!Server.name #
 Vendor.name << v!Vendor.name #
 Model.name << m!Model.name #
 Server.system_id << s!Server.system_id)

When I execute the query, the result contains just the name of the
servers repeated three times. When I check the generated SQL, I see that
it generates not what I expected.

Am I missing something here?

If you need, I can put the full source & generated SQL to somewhere.

-- 
R. Emre Başar
İstanbul Bilgi University
Department of Computer Science


signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Applicative but not Monad

[Heinrich Apfelmus]

Dan Weston wrote:
> Can you elaborate on why Const is not a monad?
> 
> return x = Const x
> fmap f (Const x) = Const (f x)
> join (Const (Const x)) = Const x
> 

This is not  Const , this is the  Identity  monad.

The real  Const  looks like this:

   newtype Const b a = Const b

   instance Monoid b => Applicative (Const b) where
pure x = Const mempty
(Const b) <*> (Const b') = Const (b `mappend` b')

The only possible monad instance would be

   return x = Const mempty
   fmap f (Const b) = Const b
   join (Const b)   = Const b

but that's not just  ()  turned into a monad.


Regards,
apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Bulding a library for C users on OS X

[Chris Eidhof]

Hey all,

I'm trying to call a Haskell function from C, on OS X. There's an  
excellent post [1] by Tomáš Janoušek that explains how to do this on  
Linux. However, on OS X, it's different. First of all, it looks like  
the -no-hs-main flag is ignored, because I get the following error:


> ghc -O2 --make   -no-hs-main -optl '-shared' -optc '- 
DMODULE=Test'   -o Test.so Test.hs module_init.c

> [1 of 1] Compiling Main ( Test.hs, Test.o )
>
> Test.hs:1:0: The function `main' is not defined in module `Main'

Second, I learned [2] that I have to pass in different flags on OS X,  
but unfortunately, GHC still wants me to have main. I'm probably doing  
something wrong here, is there anyone who can give me some pointers?  
(no pun intended).


I'm running GHC 6.10.2 on Leopard.

Thanks,
-chris

[1]: http://blog.haskell.cz/pivnik/building-a-shared-library-in-haskell/
[2]: 
http://www.mail-archive.com/haskell-cafe@haskell.org/msg51303.html___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe