Re^3: Functional Perl 6/PUGS

FWIW, the code is not meant to be efficient, or real-world useful. It is meant to be an example of the argument pattern matching style of ML with perl6.

As for "why the hell would anyone program like this" question, the answer is that (virtually) no one really would.

However, it does illustrate the style of programming which is free of both assignment statements and side effects. This style is an area of interest in the study of concurrent programming (both non-assignment and single assignment variables actually). By not introducing side effects and limiting assignment you can remove an entire class of concurrent programming issues.

It is also useful to not think of this style of programming the way you view procedural execution. If you were to write these functions in prolog (or something similar like Erlang) the code would be quite similar, but since the execution model is much different, they are not as in-efficient as you might think.

And if you were stranded on a deserted isle with only functions and simple logical and comparison operators, and all your assignment statements, for & while loops, if statements etc, were lost at sea. You would have to program like this too.

-stvn

Comment on Re^3: Functional Perl 6/PUGS

Replies are listed 'Best First'.
Re^4: Functional Perl 6/PUGS by BrowserUk (Patriarch) on Feb 28, 2005 at 18:38 UTC
FWIW, the code is not meant to be efficient, or real-world useful. It is meant to be an example of the argument pattern matching style of ML with perl6. I understand that. The problem is, whenever I look for any examples of FP-style programming, these are the same examples that are always given--like they exemplified the virtues of FP? However, it does illustrate the style of programming which is free of both assignment statements and side effects. This style is an area of interest in the study of concurrent programming (both non-assignment and single assignment variables actually). By not introducing side effects and limiting assignment you can remove an entire class of concurrent programming issues Thankyou for that last sentance! That is the first time in nearly 4 months of looking that I have seen, what appears to be--on the surface at least--a good reason for wanting to use "the style of programming which is free of both assignment statements and side effects". Most every other text I've read that attempts to justify this style of code--where they bother at all--attempts to do so on the basis of provability. An argument that simply doesn't hold water--but I think I debunked that claim enough elsewhere. I'm not entirely convinced that the concurrency argument works, but it certainly gives me another angle to research. Thanks. It is also useful to not think of this style of programming the way you view procedural execution. I hope you'll excuse me for saying this, but that sounds a bit like saying not to compare getting from Beachley, Wales to Aust, England by: following the left and right banks of the River Severn via the source. with: Crossing the Severn Bridge. Both would work, but even with the bridge toll, you probably won't get many takers for the former. If you were to write these functions in prolog (or something similar like Erlang) the code would be quite similar, but since the execution model is much different, they are not as in-efficient as you might think. This I would like to understand? Any pointers on how the mutually recursive is_odd()/is_even() method of determining a numbers oddness can be made efficient? Unless of course the interpreter/compiler recognises the pattern and optimises it to `x & 1`, in which case it is similar to perl5 sort in as much as `sort{ $a<=>$b }@array` [download] never actually sets $a or $b or transfers control to the block. In reality, the entire construct is simply recognised to mean `sortNumericallyAscending( @array )` [download] . Whilst that makes sense for Perl in terms of backwards compatibility, I don't follow the logic of creating entire languages that purport to hold to some ideal of academic purity, only to then need to create hugely complex optimising compilers with hardcoded recognition of the common, elegantly inefficient, idealised idioms and convert them wholesale to standard code. That just makes the idealism a source level sham. And if you were stranded on a deserted isle with only functions and simple logical and comparison operators, and all your assignment statements, for & while loops, if statements etc, were lost at sea. You would have to program like this too. Given those rather unlikely circumstances arose, I would spend my first week programming a string type that only needed to calculate it's length when assigned to--I guess I'd have to re-invent assignment first--bitwise and, for & while loops and if statements. And the next week writing a C compiler that could compile itself... Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply] [d/l] [select]
Re^5: Functional Perl 6/PUGS by stvn (Monsignor) on Feb 28, 2005 at 20:14 UTC
Thankyou for that last sentance! That is the first time in nearly 4 months of looking that I have seen, what appears to be--on the surface at least--a good reason for wanting to use "the style of programming which is free of both assignment statements and side effects". Look into Erlang. It is a highly concurrent language which looks a lot like prolog, and is designed for soft-real-time applications (Erisson designed it for their phone switches). It has single assignment variables and uses recursion quite heavily. It is also pretty efficient, especially in highly concurrent and distributed situations. I really do agree with you that most of the "purity of functional languages" talk tends to be overly acedemic and not very pragmatic from a "programmer in the trenches point of view". However, i do find it depressing to think that the style of programming we are all doing today is the best anyone can come up with. But that discussion is for another thread. -stvn	[reply]
Re^6: Functional Perl 6/PUGS by BrowserUk (Patriarch) on Feb 28, 2005 at 21:19 UTC
Thankyou once again. This time for the pointer to Erlang. I've seen reference to it before of course, but I looked it up and saw it was designed for writing phone software and it sounded a bit specialised for general use. Following your link and reading, I realise how wrong that conclusion was. It's downloading as I type. Perhaps the single most convincing thing that pursuaded me to look more closely was section 3 of their Programming Rules and Conventions document. The thing that struck me immediately, and came as a pleasent surprise as I was was expecting something completely different--which is why I started there--was the innate pragmatism, simplicity, and clarity of the advice offered. One or two of the pieces of that advice will take further thought, but most of it had me nodding in immediate agreement as I read it. Truely one the most concise and practical sets of programming guidelines I've ever read. However, i do find it depressing to think that the style of programming we are all doing today is the best anyone can come up with. But that discussion is for another thread. I agree. And that's a thread I'd very much like to see, and take part in. I'm not sure if it would be tolorated here, but I think it ought be, especially right now on the timeline of Perl. Examine what is said, not who speaks. Silence betokens consent. Love the truth but pardon error.	[reply]