Re: deductive databases

From: Christopher Browne <cbbrowne_at_acm.org>
Date: Sun, 15 May 2005 02:24:08 GMT
Message-ID: <cpyhe.49787$B82.1717445_at_news20.bellglobal.com>


Centuries ago, Nostradamus foresaw when "VC" <boston103_at_hotmail.com> would write:

> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message 
> news:xVQge.89347$4x.5404810_at_phobos.telenet-ops.be...

>> alex goldman wrote:
>>> While people who responded seem to disagree on whether SQL has recursion,
>>
>> ?? I didn't see any disagreement. What the different answers told you was
>> that this differs per SQL standard and per implementation.
>>
>>> what about functors?
>>>
>>> For example, can you express something like this with SQL?
>>>
>>> for_any X Y : car(cons(X, Y), X)
>>
>> That depends on what you mean by "can express". Since SQL is a
>> query language in which you formulate queries over tables it can
>> only formulate queries over tables and not over functors. So in
>> that sense the answer is "no" but that observation is about as
>> interesting as the fact that SQL also cannot make coffee. If you
>> reformulate it as a statement about tables by, for example,
>> modeling car as a binary table and cons as a ternary table then you
>> *can* express this and for that you don't even need recursion.
>>
>> -- Jan Hidders
>
> It actually depends on what <alex goldman> means by
>
> a. 'Functor',  the word that has different meaning in different PLs/contexts
>
> b. car(cons(X,Y), X).  If it's Lisp,  the expression does not make sense. 
> If it's a Prolog 'functor', it does not make any sense either.

I expect he's talking about the ML notion of functor, which is the type signature of a 'module.'

In C++, the analagous thing is a template, where, once you have defined a template, you can apply it to various types.

Thus, a template for a stack could be applied to various data types so you can have stacks of various sorts of objects. Similarly, a B-tree template allows having various B-trees for various object types.

In Ada, Modula-3, and Common Lisp this is called "generics."

In Java, the most nearly analagous thing is called an abstract class. In Objective C, they call things like this "protocols." And come to think of it, Keene's book on CLOS also uses the term "protocols" for Common Lisp...

So a functor for a stack would be some expression of certain vital data structures and functions, e.g.:

  • There's some place to store where the functions look to find the stack's objects.
  • There's some initialization function, which returns an empty stack.
  • There's a "push" function to put something on the stack
  • There's a "pop" function to pull an item off the stack
  • There's presumably some exception handling for cases of overflow (maybe) and underflow (for sure).

In ML, you characterize the API for such things as "modules."

The special "generic module" is known as a functor.

By using this, you can nail down definitions for important data structures and algorithms via functors and modules, and then be certain that code that uses them will be free of type errors.

Two contrasts...

  • Prolog, on the one hand, almost pretends to be type-free.
  • SQL, on the other hand, has wide variations in the degree to which typing is supported/noticed.

   At the most primitive end, SQLite takes the classic Tcl approach    where every data type is actually just a string.

   The object/relational systems (PostgreSQL, Illustra) have a pretty    strong idea about every bit of data having some sort of type, and    being strict about what closure they do support. For instance,    setting ridiculous dates like February 30th is rejected...

   More typical is for there to be a mixture of strictness and    weakness; most SQL systems aren't as strict about data typing,    though not so little as SQLite...

-- 
let name="cbbrowne" and tld="gmail.com" in String.concat "_at_" [name;tld];;
http://linuxdatabases.info/info/linuxdistributions.html
"More computing sins are committed  in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity."  -- W.A. Wulf
Received on Sun May 15 2005 - 04:24:08 CEST

Original text of this message