Functions in the relational context

#41

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#42

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#43

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#44

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#45

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#46

On Mar 6, 2:22*pm, Marshall <marshall.spi... (AT) gmail (DOT) com> wrote:

Quote:

"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?

* being passable as a parameter to a procedure/function

OK, function callbacks. In my last 2 years of Java programming I used
abstract class with an abstract method once. Contrast this to bread-
and-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 off-
the 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?

Quote:

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.

Quote:

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?

#47

On Mar 6, 7:14*pm, "Yagotta B. Kidding" <y... (AT) mymail (DOT) com> wrote:

Quote:

FP is a specific programming toolset usually described as having features
like higher-order functions (functions accepting other functions as
arguments),

Again, I'm very conservative, so let's go through your post line-by-
line.

Callbacks? Again this is a rare feature, and rare features don't
define language success.

Quote:

no side effects/ref transparency,

No side effects it is a protection/defence feature. I suggest that it
doesn't elevate the programming level.

ref transparency: to what extent java references are transparent or
not?

Quote:

For ideas on how FP can be applied to data management, *seehttp://citeseer.ist.psu.edu/474871.html.

This (the referenced PhD thesis, to be more precise) was quite an
overwhelming read. However, it seems to emphasise category theory
methods, while lambda calculus is barely mentioned. The query
optimization part is quite ambitious, not only he covers grouping,
aggregation, query unnesting, but he even includes complex datatypes
and OQL! Knowing how challenging laying down theoretical framework for
optimisation of even simple select-project-join makes me highly
suspicious. Query transformations are based on heuristic rules like
push-select-through-project. Does he indicate that he get's these
axioms for free by just leveraging category theory framework? (This is
a rethoric question: no matter how abstract your framework is, some
low level work streamlining the underlying algebra and identifying its
axioms has to be done. )

#48

On Mar 6, 7:14*pm, "Yagotta B. Kidding" <y... (AT) mymail (DOT) com> wrote:

Quote:

FP is a specific programming toolset usually described as having features
like higher-order functions (functions accepting other functions as
arguments),

Again, I'm very conservative, so let's go through your post line-by-
line.

Callbacks? Again this is a rare feature, and rare features don't
define language success.

Quote:

no side effects/ref transparency,

No side effects it is a protection/defence feature. I suggest that it
doesn't elevate the programming level.

ref transparency: to what extent java references are transparent or
not?

Quote:

For ideas on how FP can be applied to data management, *seehttp://citeseer.ist.psu.edu/474871.html.

This (the referenced PhD thesis, to be more precise) was quite an
overwhelming read. However, it seems to emphasise category theory
methods, while lambda calculus is barely mentioned. The query
optimization part is quite ambitious, not only he covers grouping,
aggregation, query unnesting, but he even includes complex datatypes
and OQL! Knowing how challenging laying down theoretical framework for
optimisation of even simple select-project-join makes me highly
suspicious. Query transformations are based on heuristic rules like
push-select-through-project. Does he indicate that he get's these
axioms for free by just leveraging category theory framework? (This is
a rethoric question: no matter how abstract your framework is, some
low level work streamlining the underlying algebra and identifying its
axioms has to be done. )

#49

On Mar 6, 7:14*pm, "Yagotta B. Kidding" <y... (AT) mymail (DOT) com> wrote:

Quote:

FP is a specific programming toolset usually described as having features
like higher-order functions (functions accepting other functions as
arguments),

Again, I'm very conservative, so let's go through your post line-by-
line.

Callbacks? Again this is a rare feature, and rare features don't
define language success.

Quote:

no side effects/ref transparency,

No side effects it is a protection/defence feature. I suggest that it
doesn't elevate the programming level.

ref transparency: to what extent java references are transparent or
not?

Quote:

For ideas on how FP can be applied to data management, *seehttp://citeseer.ist.psu.edu/474871.html.

This (the referenced PhD thesis, to be more precise) was quite an
overwhelming read. However, it seems to emphasise category theory
methods, while lambda calculus is barely mentioned. The query
optimization part is quite ambitious, not only he covers grouping,
aggregation, query unnesting, but he even includes complex datatypes
and OQL! Knowing how challenging laying down theoretical framework for
optimisation of even simple select-project-join makes me highly
suspicious. Query transformations are based on heuristic rules like
push-select-through-project. Does he indicate that he get's these
axioms for free by just leveraging category theory framework? (This is
a rethoric question: no matter how abstract your framework is, some
low level work streamlining the underlying algebra and identifying its
axioms has to be done. )

#50

On Mar 6, 7:14*pm, "Yagotta B. Kidding" <y... (AT) mymail (DOT) com> wrote:

Quote:

FP is a specific programming toolset usually described as having features
like higher-order functions (functions accepting other functions as
arguments),

Again, I'm very conservative, so let's go through your post line-by-
line.

Callbacks? Again this is a rare feature, and rare features don't
define language success.

Quote:

no side effects/ref transparency,

No side effects it is a protection/defence feature. I suggest that it
doesn't elevate the programming level.

ref transparency: to what extent java references are transparent or
not?

Quote:

For ideas on how FP can be applied to data management, *seehttp://citeseer.ist.psu.edu/474871.html.

This (the referenced PhD thesis, to be more precise) was quite an
overwhelming read. However, it seems to emphasise category theory
methods, while lambda calculus is barely mentioned. The query
optimization part is quite ambitious, not only he covers grouping,
aggregation, query unnesting, but he even includes complex datatypes
and OQL! Knowing how challenging laying down theoretical framework for
optimisation of even simple select-project-join makes me highly
suspicious. Query transformations are based on heuristic rules like
push-select-through-project. Does he indicate that he get's these
axioms for free by just leveraging category theory framework? (This is
a rethoric question: no matter how abstract your framework is, some
low level work streamlining the underlying algebra and identifying its
axioms has to be done. )