gmane.comp.lang.haskell.cafe

Re: Can Haskell outperform C++?

Chris Dornan — 2012-05-24T16:17:19

Noooooooooooo! You had the right idea the first time. :-)
 
(Please excuse us while we chide you as humorously as we can into putting this thread out of its misery.)

Chris

Re: Can Haskell outperform C++?

Ryan Newton — 2012-05-24T14:51:18

Oops, forgot to reply-to-all.  This was a minor clarification on Wren's
behalf (he can correct me if I'm wrong).  But I agree with Bryan that it's
time for the thread to die:



I believe this was referring to the fact that javac isn't an aggressive
optimizing compiler on the way from source to bytecode, i.e. it's the
bytecode->asm leg where the optimization effort is focused.

As an outsider to things Java that's something I've had trouble
understanding, actually.  It doesn't seem like an either-or choice to me...

   -Ryan


On Wed, May 23, 2012 at 4:26 PM, Isaac Gouy <igouy2< at >yahoo.com> wrote:

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Fundeps and overlapping instances

Twan van Laarhoven — 2012-05-24T14:03:12

Have you considered the alternative notation where multiple guards are allowed, 
as in normal function definitions? Something like:

     type instance F a
         | a ~ Int   = Bool
         | Otherwise = [a]

The last 'otherwise' clause is mandatory, matching should never fall through. 
Perhaps it could be an error if that were to happen, which would allow you to 
write closed type functions. Note that Otherwise could be declared in the library as
     type Otherwise = () :: Constraint

I think this variant is almost equivalent to your proposal (so maybe it's just 
bikeshedding). It is also very similar to the IFEQ proposal, and you can desugar 
one in terms of the other.

I also don't know how hard something like this would be to implement. The 
matching of type instances would be done in the same way as now, only their 
expanding is changed. The compiler will at this point have to look which guards 
are satisfied. In this example the first guard is a~Int, and this can not be 
checked until more is known about a. So, even though we have a known matching 
instance, it can not yet be expanded. Perhaps the notation "instance F a | a /~ 
Int" is better, because then a type family application can be expanded iff there 
is a matching instance.


Twan

Re: Formalisation for types of monads

Yves Parès — 2012-05-24T13:50:50

encoding" to beginning students.

Be reassured, that was not my intention ^^.
I just pointed that out to support the fact that foldr was *the*
fundamental folding operator for lists.


2012/5/24 Brent Yorgey <byorgey< at >seas.upenn.edu>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Converting wiki pages into pdf

Dirk Hünniger — 2012-05-24T13:50:54

I invested an enormous amount of time into this problem. Accordingly I 
got a very well working solution.

http://de.wikibooks.org/wiki/Benutzer:Dirk_Huenniger/wb2pdf
http://en.wikibooks.org/wiki/File:Haskell.pdf

I am happy If you find it useful.
Yours Dirk Hünniger

Re: Formalisation for types of monads

Brent Yorgey — 2012-05-24T13:43:30

That's pretty much what a Church encoding is.  Though I agree it's
probably best not to mention the phrase "Church encoding" to beginning
students.

-Brent

Re: Fundeps and overlapping instances

AntC — 2012-05-24T12:14:36


I'm not going to talk about Fundeps. This is about introducing overlapping 
instances into type families. But I mean dis-overlapped overlaps, with dis-
equality guards on the instances:
http://www.haskell.org/pipermail/haskell-prime/2012-May/003689.html
This is essentially the same proposal as the July 2011 discussion, but a 
little updated with actual experience of type families in their more mature 
form.

Example type family equations:
        type instance F Int = Bool
        type instance F a | a /~ Int = [a]  -- explicit dis-equality guard


The July 2010 thread shows how prescient SPJ was about introducing overlaps 
into type families (or FunDeps). The requirements he ends up with are spot-on, 
and I believe I have anticipated them in the proposal for dis-overlapped 
overlaps.

exploit

GHC 7.2.1 still rejects this program, but accepts a version re-written to use 
type families:
    type family CF a
    type instance CF Int = Bool

    newtype N2 a = N2 (CF a)    -- could be = N2 (forall b. b ~ CF a => b)

    t2 :: N2 Int
    t2 = N2 True

SPJ works through 4 examples, gathering "tricky" and "nasty" situations that 
are unsound.

The examples involve overlaps, so can't be rewritten to use type families. 
(And GHC rejects attempts to encode them with type classes avoiding fundeps 
+ "a functional-dependency-like mechanism (but using equalities) for the 
result type".)

So let me cut to SPJ's conclusions, and compare them against dis-overlapped 
overlaps ...
     (Type families already implement this, SPJ notes below.)

     Yes: I expect dis-overlapped overlaps to do this.
     (Eager checking is Hugs' approach FWIW, and although at first it seems
      a nuisance, it leads to more 'crisp' development.
      Contrast GHC compiles inconsistent instances, but then you find
      you can't reach them, or get obscure failures.)
     Eager checking also detects and blocks the irksome imported-instances-
     silently-changing-behaviour behaviour.

     Yes-ish -- instance matching doesn't have to be as strict as that:
     type inference must gather evidence of the dis-equality(s)
     in the guards before matching to the type function equation.
     Because the instances can't overlap, it's safe to apply the instance,
     as soon as the dis-equality(s) are discharged, and the head matches.

     I don't think we need this, providing each instance 'stands alone'
     with its dis-equality guards.
     Instead, for each imported module, we validate that its instances,
     do not overlap, taking the guards into account.
     [SPJ admits that such a restriction "loses part of the point of
      overlap in the first place."]
families would

AntC


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: What is the difference between runhaskell andcompile?

Vincent Ambo — 2012-05-24T12:15:11

Can you paste your code somewhere? I'm using the LDAP package at work (for authenticating a Yesod app) and a quick test of the basic LDAP package in GHCi works for me:

λ> import LDAP
λ> ldap <- ldapInit "10.0.0.12" ldapPort 
λ> ldapSimpleBind ldap "geva" "**********"
λ> let desiredAttr = LDAPAttrList ["name"]
λ> let searchDN = Just "OU=Redacted,DC=redacted,DC=com"
λ> let searchFilter = Just "sAMAccountName=geva"
λ> ldapSearch ldap searchDN LdapScopeSubtree searchFilter desiredAttr False
[LDAPEntry {ledn = "CN=Vincent Ambo,OU=Redacted,DC=redacted,DC=com", leattrs = [("name",["Vincent Ambo"])]}]

It also works in compiled applications and in source files run with runhaskell. 

Our directory server runs Active Directory.

On May 24, 2012, at 11:36 AM, Magicloud Magiclouds wrote:



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

What is the difference between runhaskell andcompile?

Magicloud Magiclouds — 2012-05-24T09:36:26

Hi,
  I am writing a small program using LDAP hackage. A weird problem occured.
  When the code was run by runhaskell, things were fine, worked as expected.
  But when ghc compiled (no any args), and ran, I got this: LDAP
error: ldapSimpleBind: LDAPException LdapServerDown(-1): Can't contact
LDAP server.
  There is sure no problem with the server.
  So I am confused. I thought the two supposed to be the same.

Re: Typed TemplateHaskell?

Simon Peyton-Jones — 2012-05-24T08:47:37

Maybe take a look at
   http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal

| -----Original Message-----
| From: haskell-cafe-bounces< at >haskell.org [mailto:haskell-cafe-
| bounces< at >haskell.org] On Behalf Of Tillmann Rendel
| Sent: 23 May 2012 18:20
| To: Haskell Café
| Subject: Re: [Haskell-cafe] Typed TemplateHaskell?
| 
| Hi Ilya,
| 
| Ilya Portnov wrote:
| > As far as can I see, using features of last GHC one could write typed
| > TH library relatively easily, and saving backwards compatibility.
| >
| > For example, now we have Q monad and Exp type in "template-haskell"
| > package. Let's imagine some new package, say "typed-template-haskell",
| > with new TQ monad and new polymorphic type Exp :: * -> *. Using last
| > GHC's features, one will easily write something like "expr :: Exp
| > String", which will mean that "expr" represents a string expression.
| > And we will need a new function, say runTQ :: TQ a -> Q a (or some
| > more complicated type), which will turn TypedTemplateHaskell's
| > constructs into plain TH.
| 
| That would be a good thing to have. But it might be quite hard to
| implement. For example, I guess you might want to have functions like
| this one:
| 
|    apply :: Exp (a -> b) -> Exp a -> Exp b
| 
| This function takes two typed expressions and produces an application.
| The types ensure that the generated application will typecheck. Cool.
| 
| But can you do the same thing for lambdas? Lambdas create functions, so
| the type would be something like the following:
| 
|    lambda :: ... -> Exp (a -> b)
| 
| But what would you put instead of the ...?
| 
| I fear that overall, you would have to reimplement Haskell's type system
| in Haskell's type system. Which sounds like a cool thing to do, but
| maybe not so easily.
| 
|    Tillmann
| 
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe< at >haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: question about linking with sqlite3

Canhua — 2012-05-24T08:37:48

I know it. I used a sqlite.dll file that is compiled for 32bit, while
my computer is 64bit.
sorry for this stupid question.



On Thu, May 24, 2012 at 10:04 AM, Canhua <dreameration< at >gmail.com> wrote:

Re: Can Haskell outperform C++?

Isaac Gouy — 2012-05-24T07:00:28

Sorry Bryan, there are a couple of comments I should make a final reply to - I'll ignore the rest.





-snip-

It isn't an ad hominem attack to ask you who's the authority that made some recommendation.


-snip-

Because you omitted basic information about the measurements you presented.


-snip-

No, it's an echo of the words you used - "...insanely difficult in Fortran 77.  This century's Fortran is of course another matter."

Re: Parallel cooperative multithreading?

Ketil Malde — 2012-05-24T06:32:12


I'm not convinced this will be better than using STM - the critique
against STM seems (as always) not to apply to implementations where
transactional data are segregated by the type system.  I'm not sure
about the non-composability of retry and orElse that the authors refer
to, anybody know?

-k

Re: Can Haskell outperform C++?

Bryan O'Sullivan — 2012-05-24T06:16:29


Do you fine gentlemen absolutely have to continue this endless, offtopic,
unedifying back-and-forth in public? Please.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Can Haskell outperform C++?

Richard O'Keefe — 2012-05-24T05:52:13

On 24/05/2012, at 4:39 AM, Isaac Gouy wrote:


No.  Amongst other things, I have my own ByteString and ByteStringBuilder
classes that are basically clones of String and StringBuilder, and using
them makes surprisingly little direct difference; the point is saving
memory.

I have obtained large speedups in Java using Java by dodging around the
Java libraries.  Other people have reported the same to me.


It looks increasingly as though there is no point in this discussion.
Is there ANY conceivable criticism of Java that will not elicit
ad hominem attacks from you?

I have read more Java textbooks than I wished to.  I was on Sun's
Java techniques and tips mailing list for years.  I could go on,
but is there, *really*, any point?

Why?  On various benchmarks, sometimes VisualWorks is better,
sometimes my system is better.  My system is utterly naive,
incorporating almost none of the classic Smalltalk optimisations.

I redid the test using VisualWorks NonCommercial.
It took about twice as long as my Smalltalk did.
According to 'TimeProfiler profile: [...]',
98% of the time is in the load phase; half of that
is down to the hash table.  A surprisingly small part
of the rest is due to actual input (ExternalReadStream>>next);
quite a bit goes into building strings and testing characters.

Why the difference?
With all due respect, VisualWorks still has the classic Smalltalk
implementation of hash tables.  Mine is different.  This is a
library issue, not a language issue.
One of the tasks in reading is skipping separators.
Since it's used a lot in parsing input, my library pushes that
right down to the bottom level of ReadStream and ChannelInputStream.
VisualWorks uses a single generic implementation that doesn't get
up to the low level dodges mine does.  And so on.

All *library* issues, not *compiler* or *language* issues.

Which is the whole point of this thread, as far as I am concerned.
C, Java, Smalltalk: this real example is dominated by *library*
level issues, not language issues or compiler issues.

Because that would be insane.

This is a program I originally whipped up in less than an hour
for two reasons:

(A) I wanted to provide some students with an example of a
    "work-list" algorithm that had some realism to it.
    For that purpose, the program had to be READABLE.

(B) To my astonishment, the tsort(1) programs in OpenSolaris
    and Mac OS X 10.6.8 turned out to be grotesquely slow for
    non-toy graphs.  I was expecting to have a use for the
    program myself, so as it stood, the Java version was
    already quite fast enough to be useful.  (As in, a LOT
    faster than the system version, even though the system
    version was written in C.)

The one issue I had with the first version was not time, but
space, so I explored two ways of making it take less space.

There is no NEED to rewrite the program to use java.nio;
having replaced the system version of the command the Java
version was no longer the bottleneck in my intended use.

For me personally, having no experience with java.nio,
it was *easier* to rewrite the program from scratch in C
than to overcome the java.nio learning curve.  And in any
case, I knew very well that I could get near enough to the
same order of improvement using InputStream and wrapping
my own buffering code over that (I've done that before).
Above all, since the students were even less familiar with
nio than I am, using nio would have destroyed the program's
utility for purpose (A).

As for the Smalltalk version, I often rewrite small things
into Smalltalk in order to find out what I'm doing wrong in
my implementation.



No, I chose to
 - use the official Java plain text I/O library
 - the way the official Java series books and tutorials
   say it should be used
 - with a MINIMUM of wrapper layers.

And it was FAST ENOUGH TO BE USEFUL.
No, I chose to use that library THE WAY IT IS INTENDED TO BE USED.
It is the simplest most straightforward way to go.
It's the *same* "algorithm" that the C and Smalltalk versions use.


"Past century"?  Insults, is it?

As for "how much better programs using other data structures and algorithms
perform", this whole thread is about how well programs using the SAME data
structures and algorithms perform, and whether we can assign much meaning
to that.  How could it possibly be better to do something irrelevant to the
topic?

Re: Parallel cooperative multithreading?

Mario Blažević — 2012-05-24T03:41:52

     I have, which is why the monad-coroutine library comes with support 
for running multiple coroutines in parallel, meaning that their steps 
are run in parallel rather than interleaved. Unfortunately, I never 
managed to extract any actual speedup out of this feature in my tests.

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

Bardur Arantsson — 2012-05-24T02:19:35

This has come up before -- this KC person probably has a broken mail
client which doesn't set appropriate References headers.

< at >KC: Which mail client are you using?

... and could you please 1) (ideally) use a mail client which doesn't
screw up threading, or 2) (less ideally) avoid messing with the subject
line so that at least everybody else's mail client has that to go on for
threading purposes?

Regards,

question about linking with sqlite3

Canhua — 2012-05-24T02:04:11

Hi, I made a cabal package that use HDBC-sqlite3 on Windows.
When cabal install it, I got an error from ld.exe: cannot find -lsqlite3.
How can I tell ld.exe where sqlite3.dll is plcaed?

Thanks.

Re: A functional programming solution for Mr and MrsHollingberry

Richard O'Keefe — 2012-05-23T21:37:19

On 21/05/2012, at 5:33 AM, Andreas Pauley wrote:

Being unfamiliar with git, I've submitted an AWK answer by e-mail.

I've used quite a few OO languages.  I like to think that I *am*
an OO programmer.  But this exercise struck me from the beginning
as something where classes would add nothing but bulk.  As a fan
of Smalltalk, I have to say that the Smalltalk version confirmed
this for me; a Smalltalk solution for this exercise could be a lot
smaller than that one if it _didn't_ introduce new classes.

Re: Can Haskell outperform C++?

Isaac Gouy — 2012-05-23T20:26:47


-snip-

I have no difficulty believing that if you are talking about a 1996 Java reference implementation and a 1996 Smalltalk JIT VM.

I could believe that if you are comparing a naive Java program with a highly tweaked Smalltalk program.



It's possible because it's possible to write a Java program to be slower than it need be :-)



What are we supposed to make of that?

Why write that and not -- Do bear in mind that Smalltalk doesn't optimize that's the JIT's job -- or -- Do bear in mind that C doesn't optimize that's the compiler's job.


-snip-

Do you have a specific example that you can share?

Re: Typed TemplateHaskell?

Tillmann Rendel — 2012-05-23T17:20:16

Hi Ilya,

Ilya Portnov wrote:

That would be a good thing to have. But it might be quite hard to 
implement. For example, I guess you might want to have functions like 
this one:

   apply :: Exp (a -> b) -> Exp a -> Exp b

This function takes two typed expressions and produces an application. 
The types ensure that the generated application will typecheck. Cool.

But can you do the same thing for lambdas? Lambdas create functions, so 
the type would be something like the following:

   lambda :: ... -> Exp (a -> b)

But what would you put instead of the ...?

I fear that overall, you would have to reimplement Haskell's type system 
in Haskell's type system. Which sounds like a cool thing to do, but 
maybe not so easily.

   Tillmann