Re: Functions in the relational context
Date: Fri, 7 Mar 2008 10:41:55 -0800 (PST)
Message-ID: <bb804cbe-f445-4c7a-b144-16d300d08752_at_i12g2000prf.googlegroups.com>
On Mar 6, 2:22 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> "Functional programming" describes a family of languages with
> many attributes in common but no hard a fast definition. The
> name is evocative of the primary position that functions are
> given. Treating functions as data per se is not a statement
> I would consider particularly descriptive. Rather I would say
> that in FP, functions are considered *first class* entities,
> in this sense of the term:
>
> http://en.wikipedia.org/wiki/First-class_object
<quote>
Depending on the language, this can imply:
</quote>
Let's go through this list one by one.
- being expressible as an anonymous literal value
Unnamed functions? Any example where you actually benefit from this? I understand that we have unnamed relations, so certainly we can have unnamed functions, but is it really big deal?
- being storable in variables
OK, we have relation variables, why not functional variables too?
- being storable in data structures
?
- having an intrinsic identity (independent of any given name)
Do relations have identity?
- being comparable for equality with other entities
Any practical example where you can leverage this?
OK, function callbacks. In my last 2 years of Java programming I used abstract class with an abstract method once. Contrast this to bread- -butter loops, conditionals and assignment.
So this is rather rare feature. Exotic features are not critical for language success. Transitive closure, relational division are cute operations, but it is join and projection that are at the core of the RM success.
- being returnable as the result of a procedure/function
Ditto
- being constructable at runtime
Wow, I never use generated code. I even go that far that dumped offthe shelf parser generators to the point of designing a homegrown parser (on non-joke grammar)
- being printable
- being readable
Excuse me, is
int increment( int a ) {
rerurn a+1;
}
non printable?
- being transmissible among distributed processes
?
- being storable outside running processes
What this is about: Stored procedures, or verson control system? in what respect these two properties are fundamental?
Also is recursion hidden somwhere on this list?
> FP has a number of other connotations. Functions in FP
> typically (or in the case of pure FP *necessarily*) are free
> of side-effects. FPLs also usually make heavy use of
> algebraic data types
>
> http://en.wikipedia.org/wiki/Algebraic_data_types
This concept totally escapes me. What algebraic is about these datatypes? For something being algebraic the underlying operations have to at least remotely resemble the familiar ones plus and multiply, otherwise one quickly finds himself on unfamiliar slippery ground.
> and use structural recursion to operate on them.
Why structural recursion is important for practical programmer? A typical programmer's day (OK, that was actually my last week) is split into the following parts:
* designing an algorithm * coding * debugging it * optimizing performance
I didn't feel that I need to prove any assertions by induction -- intution during the coding phase and bug fix during debugging usually take care of correctness.
This Fortran programming style looks regressive, but may I ask again what are the benefits of functional programming. Is it really higher level abstraction? Received on Fri Mar 07 2008 - 19:41:55 CET