Re: Functions in the relational context
Date: Fri, 7 Mar 2008 04:14:58 +0100 (CET)
Message-ID: <Xns9A59E26E37D51vdghher_at_194.177.96.26>
Tegiri Nenashi <TegiriNenashi_at_gmail.com> wrote in news:807ffc86-9840- 4a66-8e66-5c1409ad7f1f_at_s37g2000prg.googlegroups.com:
> On Mar 6, 12:45 pm, "Yagotta B. Kidding" <y..._at_mymail.com> wrote:
>> I do not see how your exercise, whilst no doubt cute, discredits the
>
>> idea that FP can be fruitfully applied to the data management field.
>
> To explore this in any depth, let's clarify what FP is. The function
> is considered as a data? I fail to see why this idea is significant.
> Care to support it with an example?
FP is a specific programming toolset usually described as having features like higher-order functions (functions accepting other functions as arguments), no side effects/ref transparency, advanced type system capable of automatic type inference, etc. Haskell or SML minus SML's imperative features are typical FP languages. See http://en.wikipedia.org/wiki/Haskell_(programming_language), for example. For ideas on how FP can be applied to data management, see http://citeseer.ist.psu.edu/474871.html. Libkin's work on bag comprehension is in a similar vein.
>
>> Care to provide the missing link/s in your logical chain, like, 'in
the
>
>> RA we can do such and so, but in FP we cannot, therefore, FP is real
> ly
>> no good'.
>
> Well, we are not talking completenes, are we? Certainly, in RA we
> can't express certain things that even primitive procedural language
> can do, yet we agree that algebraic approach is a good idea.
No, not at all. You stated that you do not think FP is a good idea as applied to data management but did not say why exactly it is not a good idea. Then, later you've apparently admitted that you do not have a clear idea of what FP is. So, I am confused as to what your point is vis-à-vis FP vs the rest ! But, I'm repeating myself and we can just let it go, therefore, unless you have a specific example to make your point clearer.
>
>> Besides, on its face, the exercise is not really relevant to
>> the RA data management. Are you talking about something like
constraint
>
>> databases where you operate with formulas rather than data ?
>
> I'm not certain where this observation leads to. Combined with an idea
> that function composition is nothing more than a relational join, the
> intuition might be that an extension of the relational model don't
> necessarily require functional programming ideas.
I am not sure what the 'f.c. as r.j.' viewpoint buys you, practically speaking, and why the viewpoint is more intuitive or useful or superior in any other imaginable way than manipulating predicates that represent possibly infinite sets (constraint databases) !
>
Received on Fri Mar 07 2008 - 04:14:58 CET