http://www.perlmonks.org?node_id=401716

I am far from being an academic. I can live with academics, yes, but don't always understand their priorities. Sometimes I think I might just understand some of their diversions. For example: Functional Programming

Now, in trying to grasp some comments that were in Re^2: Behold! The power of recursion., there was mention of Haskell, Scheme and Standard ML. Am I right, Functional Programming languages? Academic in my opinion, but valuable in redirecting neuron patterns none-the-less. In Perl, map and grep are mentioned. Looking for a correlative in my experience.

Regular expressions. I recall writing a Regex file that converted from one CAI language to another in an editor/systemLang called QED. Is this not Functional Programming system? Reqex search and Replace.

Please educate me.

Update

Looks like I had it backwards: Functional Programming has NO side effects. s/// is nothing but side effects. But thanks to the great comments, I think there is a chance I will eventually grasp the concept.
perlcapt
-ben

Replies are listed 'Best First'.
Re: regex and "Functional Programming"
by BrowserUk (Patriarch) on Oct 22, 2004 at 23:13 UTC

    In it's simplest terms, functional programming is programming without side-effects. Functions take inputs and produce outputs, but the inputs are not modifed. Crudely, pass by value rather than pass by reference.

    Traditionally, regex modify their targets in-place rather then producing a modified copy of the original. I don't think that there is any technical reason why a regex-like find & replace facility couldn't be implemented in the functional style. Except maybe efficency, but as many will express, that can be a double edged sword.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

      JavaScript does this already.

      ... = foo.replace( / regex /g, 'replacement' );
Re: regex and "Functional Programming"
by Joost (Canon) on Oct 22, 2004 at 23:25 UTC

    disclaimer: this is just my inaccurate grasp of the subject - please feel free to comment

    As I understand it functional programming is a method of writing programs. It implies structuring programs based on functions that are supposed to have no side-effects:

    sub append_stuff { my ($input) = @_; $input . "stuff"; }
    In this case the function &append_stuff has no side-effects. it returns a new string composed of the $input argument appended with the string "stuff". Contrast with:
    sub modify_stuff { $_[0] .= "stuff"; }
    Which will return the $input argument appended with the string "stuff", but will also modify the $input string itself:
    my $input = "some"; print append_stuff($input),"\n"; print "$input\n"; print modify_stuff($input),"\n"; print "$input\n"; __END__ somestuff some somestuff somestuff

    The advantage of using the functional variant is that it's much easier to follow what the program is doing than in the second case. It is supposed to decrease action at a distance.

    All this leads to things like passing functions as arguments to functions and creating new functions at runtime (and closures). Perl supports all three, so perl might be considered a functional programming language.

    On the other hand, functional programming languages generally try to avoid side-effects in build-in functions or at least offer a choice between a modifying and a non-modifying variant. Perl doesn't really do that. In the case of regex-replace:

    my $input = "some"; print s/ome/tuff/; print $input; __END__ 1stuff

    So, the s/// operator is clearly not an example of a "clean" functional operator since it modifies its argument.

    I should probably be clear that it is very unpractical to force the "no side-effects" rule in the more broad sense - IO is one area where you're more or less forced to have side-effects - though most side effects occur "outside" the program itself - and most functional programming languages support some kind of modifying function calls (you could probably abuse closures if they don't offer any other way).

    Just my 2 cents. Another language you might want to take a look at is Lisp. Go read. There's more out there than Java :-)

    updated: reworded explanation of &modify_stuff

      I should probably be clear that it is very unpractical to force the "no side-effects" rule in the more broad sense - IO is one area where you're more or less forced to have side-effects - though most side effects occur "outside" the program itself - and most functional programming languages support some kind of modifying function calls (you could probably abuse closures if they don't offer any other way).

      This, I think, is a great example of theory vs. practice. In a pure-functional language (like Haskell), there is no way to do I/O without learning about Monads. Which means you need to learn about a fairly advanced functional programming concept just to read data from a file. In a language without this theoretical purity, basic I/O is covered within the first few chapters, and then you move along.

      Forcing learning of advanced concepts for simple and common tasks is bad Huffman coding.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        Clean is pure and doesn't use monads. They use so called "uniqueness typing". You basicaly pass along the "world" or some part of it and the type system makes sure you do not try to "clone" the world. That is you may only do one thing to the world you have, by which you create a new world and then you make another change to the new world and so on. I haven't written anything with the monads so I can't really say, but this looks to me a bit easier to understand and use.

        I don't think whether the books start with explaining how to print hello world or how to compute this or that is that important. Yes it's easier to impress the girls with something that displays a nice moving graphic than with a complex and elegant computation, but we are not in programming to impress girls are we. We'd be playing football (the europeans would play the game in which you kick the ball around all the time, americans the one in which you barely ever touch the ball with your foot. Whatever.) if that was what we were after.

        A more important reason why functional languages are not used more videly is that they usualy miss useable libraries. Let's see how the implementation that do interface with the .Net world will be doing. (Not that I would mean that the .Net framework library is too useable. But still better than nothing.)

        Jenda
        We'd like to help you learn to help yourself
        Look around you, all you see are sympathetic eyes
        Stroll around the grounds until you feel at home
           -- P. Simon in Mrs. Robinson

        In defense of Haskell, you don't need to know a lot about monads to do I/O, sorta like how you don't need to know a lot about streams to do I/O in C++. Of course, Haskell's type system makes it hard to ignore the IO monad, and eventually you're going to run into trouble if you try to obstinately ignore monads, but you're hardly forced to grok monads in fullness just to write "Hello, world!" to the screen.

        --
        Yours in pedantry,
        F o x t r o t U n i f o r m

        "Lines of code don't matter as long as I'm not writing them." -- merlyn

      Your comments have cleared some of the mist for me. But for me to look at Lisp! Shudder. It is enough for me to have to write Emacs macros. It just doesn't seem a natural process of programming for me. But then what I feel is natural is more a product of habit than anything else.
      perlcapt
      -ben

        Have a look at one of the more modern functional languages. Standard ML or OCaml come to mind from the "non-pure" group, Haskel and Clean from the purely functional group. Especialy the later two will definitely hurt because you'll have to break your programming habits completely, but the first two should not be that bad.

        Jenda
        We'd like to help you learn to help yourself
        Look around you, all you see are sympathetic eyes
        Stroll around the grounds until you feel at home
           -- P. Simon in Mrs. Robinson

Re: regex and "Functional Programming"
by FoxtrotUniform (Prior) on Oct 23, 2004 at 00:22 UTC

      There's a whole lot of iterating going on in functional languages; it's just going to tend to look like perl map or foreach loops and not like a while or C-style for loop.

      Generally, though, where applicable, one's more likely to choose a recursive algorithm than an iterative one, which is likely what you meant, but, well, yours in pedantry and all.

        There's a whole lot of iterating going on in functional languages; it's just going to tend to look like perl map or foreach loops and not like a while or C-style for loop.

        Heh. I can't speak for all functional languages, but the map function in Haskell is defined recursively in the Haskell Standard Prelude. So is iterate (which really means "repeat-compose"), as well as the folds. Hell, even the "iterative" sequenced monad operations are defined recursively. Mostly, this follows from the recursive definition of lists: a list is either an empty list, or a datum consed onto a list.

        There's probably some iteration going on in even the most standards-compilant Haskell implementation, but as far as I can tell none of it happens at the language level. Feel free to correct me, though, if you find any in the Prelude; I don't know it as well as I ought.

        Of course, the first example in my copy of ANSI Common Lisp isn't very "functional" at all:

        (defun sum (n) (let ((s 0)) (dotimes (i n s) (incf s i))))

        --
        Yours in pedantry,
        F o x t r o t U n i f o r m

        "Lines of code don't matter as long as I'm not writing them." -- merlyn