headers
Gregory Collins | 1 Nov 2009 02:57
Gravatar

Re: How to fulfill the "code-reuse" destiny of OOP?

Tom Davie <tom.davie <at> gmail.com> writes:

> On 10/31/09, Magicloud Magiclouds <magicloud.magiclouds <at> gmail.com> 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 <greg <at> gregorycollins.net>
Permalink | Reply | 12 comments |
headers
Michael Vanier | 1 Nov 2009 03:00
Picon

Re: How to fulfill the "code-reuse" destiny of OOP?

Gregory Collins wrote:
> Tom Davie <tom.davie <at> gmail.com> writes:
>
>   
>> On 10/31/09, Magicloud Magiclouds <magicloud.magiclouds <at> gmail.com> 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
Permalink | Reply | 1 comment |
headers
Sebastian Sylvan | 1 Nov 2009 03:39
Picon

Re: How to fulfill the "code-reuse" destiny of OOP?



On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier <mvanier42 <at> gmail.com> wrote:
Gregory Collins wrote:
Tom Davie <tom.davie <at> gmail.com> writes:

 
On 10/31/09, Magicloud Magiclouds <magicloud.magiclouds <at> gmail.com> 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 :: [ <Show> ] -> 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 <Show> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 0 comments |
headers
Wei Hu | 1 Nov 2009 04:08
Picon

The (>|) function in Control.Parallel.Strategies

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.
Permalink | Reply | 0 comments |
headers
Heinrich Apfelmus | 1 Nov 2009 13:12
Picon
Favicon
Gravatar

Re: Experiments with defunctionalization, church-encoding and CPS

Eugene Kirpichov wrote:
> I took a toy problem - find the first node satisfying a predicate in a
> binary tree, started with a naive Maybe-based implementation - and
> experimented with 3 ways of changing the program:
>  - Church-encode the Maybe
>  - Convert the program into CPS
>  - Defunctionalize the Church-encoded or CPS-transformed program
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10686
> 
> The link points to code, a benchmark and conclusion.
> 
> Conclusion:
>  - Haskell implements Maybe well enough that it is not possible to do better
>  - Defunctionalization and consequent optimization yields same
> performance as the one with Maybe
>  - Non-simplified CPS and Church-encoded representations do bad

I'm not sure your example program is enough to justify the conclusions.

The main advantage of the Church-encoding of  Maybe

    type Maybe' a = forall b . b -> (a -> b) -> b

is that the latter has the pattern match for failure / success built-in
when used as a monad

    m >>= g  = \nothing just -> m nothing (\x -> g x nothing just)

  VS

    m >>= g  = case m of
        Nothing -> Nothing
        Just x  -> g x

The algebraic data type has to check that the result was indeed  Just x
 whereas the Church-encoding can jump right to the success continuation.

The problem is that your tree doesn't really make use of this advantage.
For that, you need a completely left-biased tree, like for example

    Fork 1 (Fork 2 (Fork 3 ... Leaf) Leaf) Leaf

    testTree = fromList [1..100000]
    fromList = foldr (\x t -> Fork x t Leaf) Leaf

I've implemented this and posted it below your version at

    http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10686

I've used the  criterion  benchmarking package, so you can run this
straight out of the box.

Even then, the results are mixed. The Church-encoding shines in GHCi as
it should, but loses its advantage when the code is being compiled. I
guess we have to look at the core if we want to know what exactly is
going on.

PS: I'm not entirely sure I'm using  criterion  correctly, in particular
 concerning strictness. For instance, dropping the  fromJust  will
reduce the run-time of the "data Maybe" benchmark by 75%. Comments?

Regards,
apfelmus

--
http://apfelmus.nfshost.com
Permalink | Reply | 4 comments |
headers
Max Cantor | 1 Nov 2009 13:12
Picon
Gravatar

ATTN: Singapore based Haskellers - Singapore FP Users Group First Meeting

We are organizing a Functional Programming Users Group in Singapore  
and our first meeting is Monday, November 2nd at 6 pm.  We will meet  
initially in the Lobby of 8 Shenton Way.

Map:  http://bit.ly/1PzqlB   -or-  http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=8+Shenton+Way,+Singapore+068811&sll=37.0625,-95.677068&sspn=37.325633,79.101563&ie=UTF8&hq=&hnear=8+Shenton+Way,+Singapore+068811&ll=1.276047,103.847408&spn=0.01152,0.019312&z=16&iwloc=A

If you have any trouble, please feel free to call me at +65-9329-6139

Max
Permalink | Reply | 0 comments |
headers
Pasqualino "Titto" Assini | 1 Nov 2009 13:45
Picon

Re: ANNOUNCE: dbus-core 0.5 and dbus-client 0.1

I think that we should institute an award for "best documented haskell
package" and yours would be my first choice.

Congratulations,

               titto

2009/10/30 John Millikin <jmillikin <at> gmail.com>:
> These are pure-Haskell client libraries for using the D-Bus protocol.
> D-Bus is heavily used for inter-application IPC on Free and
> open-source desktop platforms, such as Linux, OpenSolaris, and
> FreeBSD. These libraries allow applications written in Haskell to
> inter-operate with other components of recent GNOME, KDE, and XFCE
> desktops.
>
> This is the first "real" release of these libraries; dbus-core has
> been published on Hackage for some time, but mostly just to make sure
> I got the Cabal bits right. I feel they are now stable / featureful
> enough for public use.
>
> Both are available on Hackage:
>
> http://hackage.haskell.org/package/dbus-core
> http://hackage.haskell.org/package/dbus-client
>
> ---------
>
> "dbus-core" is an implementation of the D-Bus protocol, specifically
> the parts relevant to clients. Eventually, it will probably grow some
> functions useful for implementing a message bus as well. It includes
> type mapping / conversion, an implementation of the wire format
> (marshaling / unmarshaling), data types for the currently defined
> message types (METHOD_CALL, METHOD_RETURN, ERROR, and SIGNAL) and a
> basic parser / generator for introspection documents. It is roughly
> equivalent in purpose to libdbus.
>
> By itself, a protocol implementation is somewhat cumbersome to use, so
> "dbus-client" is a high-level wrapper. It provides some abstractions
> like remote object proxies, exported object trees, synchronous method
> calls, signal reception, and name reservation. Messages are received
> and processed in separate IO threads, allowing asynchronous method
> call and signal handling.
>
> The purpose between splitting the library into two packages is
> stability; "dbus-core", ideally, will change only rarely --
> performance improvements, new message / data types, etc. It provides a
> base level of functionality which more specialised libraries may use.
> "dbus-client" is an example of what such a library could look like,
> though for now it's not very Haskell-y (IO everywhere, exceptions,
> explicit locking). By separating the protocol from the client libs,
> alternative client libs can safely depend on the protocol
> implementation.
>
> ---------
>
> To see a sample of the library working, there's a clone of the
> "dbus-monitor" utility in <dbus-core/Examples>. Documentation is
> currently a bit lacking, so for now, the best documentation is the PDF
> of the source code itself, and the (rather barren) Haddock output:
>
> https://dl.getdropbox.com/u/1947532/dbus-core_0.5.pdf
> https://dl.getdropbox.com/u/1947532/dbus-core_0.5/index.html
>
> https://dl.getdropbox.com/u/1947532/dbus-client_0.1.pdf
> https://dl.getdropbox.com/u/1947532/dbus-client_0.1/index.html
>
> Once more people have used it without any major API issues, I'll write
> up a manual and populate the Haddock entries.
>
> Please respond with any feedback, difficulties, or suggestions. I'm
> particularly interested in ways to improve the public API, since I
> would rather make any breaking changes *before* anything big depends
> on these libraries.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--

-- 
Pasqualino "Titto" Assini, Ph.D.
http://quicquid.org/
Permalink | Reply | 0 comments |
headers
Thomas Hartman | 1 Nov 2009 14:58
Picon

hackage is down.

http://hackage.haskell.org
Permalink | Reply | 12 comments |
headers
Günther Schmidt | 1 Nov 2009 15:31
Picon

Monad Comprehensions

Hi all,

once again I find myself merely scratching the surface of the power of  
Haskell, which is exciting and frustrating at the same time.

While real world demands require me to find / develop solutions quickly  
(abstractions for querying data sets) I keep catching glimpses of all this  
power.

But for someone like me it's difficult to assess from these glimpses alone  
which to study first. In the last few weeks I kept bugging people here on  
this list about DSLs, so I could create my own to express queries /  
relational algebra. I'd later choose then to compile this to SQL or to  
in-memory code.

Next thing I notice that I've overlooked list comprehension all this time,  
which already express quite a lot of what I'd need. And then, on top of it  
all, monad comprehension, or rather monads period. The thing that  
particularly set me off was a video from Dan Piponi:  
http://vimeo.com/6590617

It certainly made me realize how little I have understood how much power  
merely monads give you.

In short, I'm truly lost. If anyone else, with roughly the same starting  
point as me, has found their way through this jungle I'd certainly  
appreciate some tips. In particular I wonder if someone has been able to  
follow what Dan demonstrates in this video, or was it a jaw-dropping  
experience for everyone else just as me?

Günther
Permalink | Reply | 0 comments |
headers
Jochem Berndsen | 1 Nov 2009 15:59
Picon

Re: hackage is down.

On Sun, Nov 01, 2009 at 07:58:00AM -0600, Thomas Hartman wrote:
> http://hackage.haskell.org

Hackage is down currently, I am seeding the torrent by mauke from IRC on 
http://mauke.ath.cx/tmp/2009-10-19-hackage-archive.torrent

Cheers, Jochem
--

-- 
Jochem Berndsen | jochem <at> functor.nl | jochem <at> 牛在田里.com
Permalink | Reply | 7 comments |

Gmane