in reply to Re^6: Is it worth using Monads in Perl ? and what the Monads are ?
in thread Is it worth using Monads in Perl ? and what the Monads are ?

For your test, I ran this: 

#! perl -slw
use strict;

sub f {
    my $a = shift;
    my $term = 1;
    my $sum = 1;
    my $i;

    for( $i=0; $sum <= $a; $i++) {
        $term = $term + 2;
        $sum = $sum + $term;
#        print "i:$i term:$term sum:$sum";
    }
    return $i;
}

print "f($_) = ", f( $_ ) for -4 .. 36;

[download]

The terminating value for the test loop may indicate to you that I had a good idea of what it was doing before I ran it. I still haven't looked up the book. I'd term f as 'the integer root', but there is probably some proper term for that.

Now I'll turn the page...back.

So, not far wrong, but did I pass the test? I read on a few pages and it makes great play of how the Z axiomatic definition carries more information--such as the possible ranges of inputs and outputs from f()---but that ignores that the C definition could also have captured that information. 

unsigned int f( unsigned int a ) {
  unsigned int i, term, sum;
  
  term=1; sum=1;
  for (i=0; sum <= a; i++) {
       term=term+2;
       sum=sum+term;
  }
  return i;
}

[download]

And actually, that carries more information. For one thing, on practical computer systems, variables are of finite size and can therefore only deal with finite ranges of values. It maybe mathematically convenient to reason about functions in terms of the infinite range of natural numbers, but in practice, that reasoning falls down because real hardware overflows, underflows and otherwise does not behave as mathematical theory would have it behave.

The Z definition won't tell you that for inputs above 2**31, (using the original C formulation on a 32-bit processor) that you are going to get bizarre outputs because the intermediate term sum will overflow.

In the Total FP paper, the author says:

RULE 1) All case analysis must be complete. So where a function is defined by pattern matching, every constructor of the argument type must be covered and in a set of guarded alternatives, the terminating ‘otherwise’ case must be present. In the same spirit any built in operations must be total. This will involve some non-standard decisions - for example we will have

0 / 0 = 0

Yeah, right! Good luck with that.

Now how hard do I have to think to come up with a scenario where the undetected, unreported, silent conversion of erroneous input into a mathematically convenient lie causes the reactor to go critical or the patient to receive a massive dose of something lethal? But the mathematicians are happy, so what the hey! Again, just a dramatisation.

Have you taken a look at Prolog?

Yes. I did a Prolog course at college back before the dawn of time. And more recently, about 10 years ago, I had to do some real work with an inferencing engine that used a dialect of Prolog. It does take a very different mindset. And the last time I frequently wrote short brute force C programs to verify the results I was getting from the inferencing engine. They usually ran longer, but they were much faster to produce and I had far more confidence in the results.

Oh, sure, there are going to be some enthusiastic advocates of any language,

It's not "enthusiastic advocates" that disturb me.

IMO Haskell should be downplaying the arguments about whether the rules underlying Monads are correct, or whether MonadPlus is better. And whether Lazy is a good or a bad thing.

I didn't get to go through the Xmonad stuff, but there doesn't appear, at first glance at the page you linked, to be any tutorial associated with it? I did say show me the code, but went on to say "But more importantly, show me how you arrived at it."

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^8: Is it worth using Monads in Perl ? and what the Monads are ?
by Anonymous Monk on Jun 17, 2007 at 04:35 UTC
    • It's the claim...
    • It's the claim...
    • It's the claim...
    How many of the worlds programmers would successfully make the transition from imperative to functional programming?
    I'm still a little bit confused. Is someone trying to "convert" to the Haskell religion? Certainly I hope you don't think I am. Who cares how many people can transition from imperative to functional programming? Go with what works for you. I'm quite content that you at least tried something new, even if it didn't work out for you. In my previous postings, I was trying to get across the idea that there's no one-size-fits-all when it comes to programming languages. My personal experience has been that Haskell lets me write easier to understand programs with less fuss and fewer bugs. Other people have had similar experiences. YMMV.
    for those parts of Haskell programs that are purely functional
    Er, *All* Haskell programs are 100% referentially transparent and purely functional. You can substitute equals for equals anywhere and everywhere. Always. No Exceptions. Anyway, I also meant to link to the Q Lanugage in my previous post. Good luck and best wishes.
[reply]
[reply]
[reply]

In Section Seekers of Perl Wisdom