Re^4: GHC shuffle more efficient than Perl5.

The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

That is not correct at all. All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run. This is true for all programming languages of all times, FP or not.

The distinction that a pure FP language makes, is merely that pure functions and side-effectful actions are separated, because the former is always inlinable and memoizable, and the latter always executed sequentially. In contrast, in a language that does not make this distinction, both are executed in some arbitary order.

In other words, functions never have side-effects, but a program does. In Haskell and other pure FP languages, you can write functions that defines composable actions, and group them under the main function. The action defined by main will then be executed as the program itself.

Personally, if I was to implement a fair shuffle in real-world situations, I also would choose Perl instead of Haskell, since it would save me some time, to the order of one minute versus ten minutes. But if memory use (or, sometimes, speed) is of critical importance, as often demanded in my paying work, then GHC is a much more elegant alternative than GCC to me. Which is why I'm working on Inline::GHC after all...

Also, I have no doubt that Perl 6, as compiled by Pugs to Parrot, can be even more efficient than GHC here. :-)

Comment on Re^4: GHC shuffle more efficient than Perl5.

Replies are listed 'Best First'.
Re^5: GHC shuffle more efficient than Perl5. by BrowserUk (Patriarch) on Apr 23, 2005 at 04:05 UTC
Thankyou Autrijus for clarifying what I was (clumsily) trying to say. Once you accept that side-effects are impossible to avoid, you can conceal them, segregate them, and move them to other places, but you cannot avoid them. You have to deal with them. The distinction between Haskell (and FP languages in general) and imperative languages (exempified by Perl), are in how you choose to deal with them. My only statement that could be considered "against" Haskell, is that personally, I prefer the permissive syntax and semantics of Perl as my tool for doing so, than I do, (what I consider to be, in my admittedly breif experiences of them), the restrictive syntax and semantics of Haskell and other FP languages. That is a biased viewpoint. In part by my greater experience with imperative langauges in general and Perl in particular. In part, by my feelings and opinions regarding the barrier that is formed between the general (and even the programming) population by viewing the world through opaque glasses of mathematical notation. I see the need for mathematical notation. Just as I believe that it is necessary for programmers to read, understand and use the full expressive power of their chosen computer languages, so I see that for the mathematician, the short-hand of math notation is their tool that allows them to express and convey (to other equally conversant practitioners) their ideas and concepts. But, just as the artist has no need for the constraints and precision of the draughtsmans tools to express and encapsulate his/her ideas, I don't think that the programmer needs the tools and nomenclature of the mathematician to express and encapsulate theirs. It may be mathematically correct to view the length of a string as a recursive function that processes the string as a list of characters counting them until the list is empty. And it may well be that a compiler can optimise this operation to the point where the counting is only ever done once. And the fact that the compiler actually reduces the operation to storing the length, as state in concert with the string, and adjusts it whenever the length of that string changes, whether through visible or concealed side-effect, is actually exactly what Perl does. It just advertises that fact rather than conceals it. At the final analysis, it comes down to which syntax you prefer to use. Through my inherent bias, which we all have, I prefer the imperative view of the world to the functional. I find it more natural. But my preference, nor my stating of that preference on this site, dedicated as it is to Perl, in no way belittles the power of FP, anyones preference for FP, or the frankly awe-inspiring use you have made of that power to the good of Perl. I am in awe. Of it, and you, and the use you have made of it. You have my thanks for your work and the benefits that it has already accrued and continues to accrue to the future of Perl. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. Rule 1 has a caveat! -- Who broke the cabal?	[reply]
Re^6: GHC shuffle more efficient than Perl5. by audreyt (Hermit) on Apr 23, 2005 at 08:01 UTC
Thanks for your kind words. In light of this thread's topic, I'd like to add that, because functions in pure FP never have side-effects, their reduction order can be entirely undefined. Actions defined by those pure functions, however, are defined as always sequential when `main` is executed. This fact makes concurrency and automatic parallelization much, much easier to reason about; as an example, you can trivially write deadlock-free, composable, highly efficient concurrent code, using shared variables and inter-thread channels, without worrying about side effects going astray. See http://homepages.inf.ed.ac.uk/wadler/linksetaps/slides/peyton-jones.ppt for more information... I think it will be enlightening :-)	[reply]
Re^7: GHC shuffle more efficient than Perl5. by BrowserUk (Patriarch) on Apr 23, 2005 at 10:29 UTC
I read the STM slides you linked and I have a follow up question: Slide 26 says "STM is aimed at shared memory [applications]..." and slide 31 says "You can't do IO in a memory transaction...", which leads me to ask, what is the point of concurrency that cannot do IO? The basic premise of concurrency is to overlap communications with computations. You utilise the time spent communicating to do something else useful. In the case of the example used in the slides, that of a banking system, the instructions for increasing and decreasing an account's total would, in the real world, be coming from external systems--clearing houses, ATM's, check processing in branch work rooms etc.--and any but the smallest bank would have to be using multiple (many) systems to process the volumes of transactions and accounts in real time. If STM is restricted to dealing only with in-memory concurrency, it seems to be of little real-world application beyond simulations? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. Rule 1 has a caveat! -- Who broke the cabal?	[reply] [d/l]
Re^8: GHC shuffle more efficient than Perl5. by audreyt (Hermit) on Apr 23, 2005 at 15:00 UTC
Re^8: GHC shuffle more efficient than Perl5. by Anonymous Monk on May 05, 2005 at 21:22 UTC
Re^9: GHC shuffle more efficient than Perl5. by BrowserUk (Patriarch) on May 06, 2005 at 04:18 UTC
Re^7: GHC shuffle more efficient than Perl5. by BrowserUk (Patriarch) on Apr 23, 2005 at 08:54 UTC
... because functions in pure FP never have side-effects, their reduction order can be entirely undefined. Actions defined by those pure functions, however, are defined as always sequential when main is executed. Yes. In one sentence you have summed up the requirement for defined EO in languages, or those parts of a langauge, that have side-effects. Where it gets awkward, is to see how that enables the parallelisation of functions that can have side-effects, when they are a part of the same expression. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. Rule 1 has a caveat! -- Who broke the cabal?	[reply]
Re^6: GHC shuffle more efficient than Perl5. by Anonymous Monk on Apr 23, 2005 at 14:09 UTC
One way in which Haskell is potentially less restrictive is the freedom to define your own monads - while some need a degree of compiler or FFI support (IO, ST, STM etc etc), many other useful monads can be built on top of existing language features and provide useful semantics for whichever problem you have at hand. For a couple of domain-specific examples, the Parsec library is good and many type checkers use a monad to provide unification and related services.	[reply]
Re^5: GHC shuffle more efficient than Perl5. by tlm (Prior) on Apr 23, 2005 at 18:28 UTC
All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run. Well, if they take any time to run, then they must have side effects somewhere. the lowliest monk	[reply]