Re: Functions in the relational context

From: Yagotta B. Kidding <>
Date: Fri, 7 Mar 2008 21:18:10 +0100 (CET)
Message-ID: <Xns9A5A9BC526A23vdghher_at_194.177.96.26>

Tegiri Nenashi <> wrote in

> On Mar 6, 7:14 pm, "Yagotta B. Kidding" <> wrote:

>> 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.

Let's not. I cannot decide for you and no one can explain in the contentious thread whether or not the FP toolset makes sense in your application domain, moreover, I have doubts w.r.t to its applicability in many cases myself. However, despite FP's real or perceived drawbacks, it has as solid theoretical foundation as the RA, something OOP lacks. Therefore, FP appears to be, arguably and at least theoretically, the only solid alternative/complement/extra tool to the RA in the data management area as of today. So, you may want to visit the Haskell page I gave earlier and you apparently ignored, look at the examples and decide if the FP way is suitable or not for whatever you are doing ;)

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

I am probably wasting my time, but here are some examples of high-order functions:

  1. 'map': map f1 list1 -- applying an arbitrary function to an arbitrary list (types have to match naturally)
  2. generic left 'fold' used to define other functions: sum = foldl(+) 0 product = foldl (*) 1
  3. anonymous function: map (2*) [1,2,3]


>> 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?
>> For ideas on how FP can be applied to data management,
>>  seehttp://citese 

> 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. )

I am not entirely happy with some issues in the referenced work myself although at much lower level, such as set/bag representation. I have the same doubts w.r.t. Libkin/Wong bag languages. I am pretty sure that the set as a data type primitive in any FP languages is pretty much an illusion.

Received on Fri Mar 07 2008 - 21:18:10 CET

Original text of this message