in reply to regex and "Functional Programming"

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

Replies are listed 'Best First'.
Re^2: regex and "Functional Programming"
by hardburn (Abbot) on Oct 23, 2004 at 13:24 UTC

    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

Re^2: regex and "Functional Programming"
by perlcapt (Pilgrim) on Oct 23, 2004 at 02:13 UTC
    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