In an attempt to throw the authorities off his trail, seunosewa (AT) inaira (DOT) com (Seun Osewa) transmitted:
SELF isn't "typeless;" the only language I recall that _claimed_ to be
such was BCPL (predecessor to B and C), and even there, that wasn't
honestly typeless; it was instead pretty "loose" about them.

Perl and TCL both have a history of pretending "typelessness;" their
scalars can be coerced into pretending that they are strings or
numbers depending on what operation you use on them. Mind you, since
they have aggregate 'types' it's again not honest to call them
"typeless;" they are more 'schizophrenic about types.' (Which is
sometimes a big pain.)

What could be of _some_ merit would be to have a system that is 'type
agnostic;' that is, you have containers/slots in which you can put any
type. That's sort of what Self does; that's _certainly_
characteristic of the Lisp family. The latter is strongly typed, but
common data structures allow plunking in data of any type, in contrast
with (say) ML.

Whether or not this is any good for databases is another question. The
_problem_ with being open to a "loose" set of types is that there then
needs to be code to interpret the different types.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/unix.html
Signs of a Klingon Programmer - 16. "Klingon programs don't do
accountancy. For that, you need a Ferengi."

Hi,

I would like to know how you generate those introductory phrases
attached to your quotations of other people!

Christopher Browne <cbbrowne (AT) acm (DOT) org> wrote

that Self is not what I thought it would be while leaving for the
night. Don't you see the potential calue of allowing objects to join
and leave classes as necessary over time? It is all about letting
data last long even if its accessed differently. "Large Shared Data
Banks" anyone?

What I am really trying to say is, if a single object can present
itself as a member of any class to which it is supposed to belong, and
we use special constraints to model other concepts like type
inheritance, the system would be interesting and very flexible. If an
circle can wake up and say, "ok I am changing my dimensions I am no
longer a circle". if the DBA can say "all right employees no longer
have to be managers". Will get back to it. I have done little frther
development of the ideas.

Interesting food for thought. In other words, implemention
difficulties. Its notable that a special index structure would have
to be created just to be able to tell what objects in a system belong
to a particular class. It'll no longer be as simple as a sequential
scan on a file. So its good to be able to rearrange the objects based
on read patterns and that's where log-structured data storage might be
useful.

But at the right stage I would investigate to see if by taking
advantage flexibility of the scheme we can in some cases buy back some
of the lost performance. And make programs simpler. But meanwhile
maybe I should work on the object model? I do not yet se how to link
this with the idea that the database is essentially a colection of
assertions unless I say a collection of assertions about the existence
of an object with certain properties. Seems like a restriction in the
general case which means the relational model may be even more of a
restriction.

Best Regards,

Seun Osewa.

seunosewa (AT) inaira (DOT) com (Seun Osewa) wrote:
Gnus is really, really, really powerful.

(setq *random-headers*
'(("The world rejoiced as " " wrote")
("In an attempt to throw the authorities off his trail, "
" transmitted")
("Oops! " " was seen spray-painting on a wall")
("In the last exciting episode, " " wrote")
("Quoth " "")
("Martha Stewart called it a Good Thing when" "wrote")
("A long time ago, in a galaxy far, far away, " " wrote")
("After takin a swig o' Arrakan spice grog, " " belched out...")
("After a long battle with technology," ", an earthling, wrote")
("Centuries ago, Nostradamus foresaw when " " would write")
("" " wrote")))

(defun insert-random-header ()
(let* ((r (random (length *random-headers*)))
(headers (elt *random-headers* r))
(pre (car headers))
(post (cadr headers)))
(insert pre (mail-header-from message-reply-headers) post ":\n")))
--
output = reverse("gro.mca" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/unix.html
"Windows95, Word97, Office98: With all the criticisms of MICROS~1, at
least they include ``best-before'' dating on many of their
products..." -- cbbrowne (AT) hex (DOT) net

Reference news:<ba87a3cf.0310091820.50180857 (AT) posting (DOT) google.com>...

Hi,

I have decided to post examples about the proposed data model and the
language, to show how everything may work together.

====================================
EXAMPLE 1: Circles and Ellipse
====================================
//Class Definitions are meant to last as long as the database
//They can change though each object may implement them differently
Define Class Circle {
in:
Radius (int)
out:
Radius (int)
Area (int)
)

Define Class Ellipse {
//Note that Inheritance is not "mentioned" above.
//Each class is allowed to be mutually exclusive of all others
in:
Radius01 (int);
Radius02 (int);
out:
Radius01 (int);
Radius02 (int);
Area (int);
}

//Object Templates are used to create new Objects
//Standard OO uses the class definition as object template.
Define Template RoundShape {
variables:
//variables represent the physical structure for all objects created
with
//this template.
radius01 (int) DEFAULT 0;
radius02 (int) DEFAULT 0;

construct:
RoundShape(int a, int b) {
radius01=a;
radius02=b;
object_set_classes(Circle if (a==b), Ellipse);
}

RoundShape(int radius) {
radius01=radius02=radius;
object_set_classes(Circle, Ellipse);
}

in:
Radius (int) {
radius01 = in;
radius02 = in;
}

Radius01 (int) {
radius01=in;
//dynamic join and leave class based on properties.
if (radius01==radius01) object_join_class (Circle);
else object_leave_class (Circle);
}

Radius02 (int) {
radius01=in;
//dynamic join and leave class based on properties.
if (radius01==radius01) object_join_class (Circle);
else object_leave_class (Circle);
}

out:
Radius (int) {
//should only happen if we are a circle
assert (radius01==radius02);
out = radius01;
}

Area (int) {
out = radius01 * radius02; //deliberately wrong formular
}
}

USER COMMANDS:
**************

20 400
40 1600

20 20 400
20 40 800
40 20 800
40 40 1600

20 40 800
40 20 800


Remarks:
Yes, its longer than SQL but arguable more flexible.


================================================== ===============
EXAMPLE 2: Involving Pointers
================================================== ===============
Define Class Employee {
in:
Name (string);
Dept (Department);
out:
Name (string);
Dept (Department);
}

Define Class Department {
in:
Name (string)
Head (Employee)
out:
Name (string)
Head (Employee)
}

///
[exclude Object Template definitions]
///
SAMPLE USER-LEVEL QUERIES:
**************************
//select each department's name and name of head
//select each employee's departmet name and Head of Department
===============================
EXAMPLE 3:Equivalent query for challenge thrown by Lauri:
===============================
SELECT FOR GROUPING //group by following 'fields'
customer->name,
details->product->name
AND ALSO //aggregate functions
SUM(Details->quantity * Details->product->price)
FROM EACH
Order //always choose a base class for query
==
Important aspects of Class Definition:
Define Class Customer {
in: name(int);
}
Define Class Details {
in: product(Product); quantity (int);
}
Define Class Order {
in: customer(Customer); details(Details);
}
Define Class Product {
in: name(String); price(Decimal);
}
============

I hope I have been able to illustrate some of my concepts. Please ask
questions to clarify the fuzzy aspects and give your insights.

Best Regards,
Seun Osewa

The Proposed Query Language: Some Observations
**********************************************
- Always assumes the presence of a "home class" from which joins are
"radiated", and therefore every line in the returned set is associated
with one object belonging to the "home class"
- An object does not statically belong to a class, but it may be
_views as a member of one or more classes_. For example, in the
circles/ellipse example each of the created objects could be viewed as
a circle (in which case it had radius and area) or viewed as an
ellipse (two radii, area).
- The storage format of each object is independent of the visible
format of each of the classes it belongs to at a particular point in
time.
- Reference fields are used to link one Object to another. Each
reference has a particular Class where the object it points to is
supposed to belong.
- The clause analogous to the SQL GROUP BY clause separates fields
used for grouping the return values of the query from fields
containing aggregate functions applied to each group. Seems much
neater that way.

Regards,
Seun

In message <ba87a3cf.0310091820.50180857 (AT) posting (DOT) google.com>, Seun Osewa
<seunosewa (AT) inaira (DOT) com> writes

I asked about such a system a while ago, the concepts you are looking
for are multiple-inheritance and dynamic reclassification. I was pointed
in the direction of Mumps.



--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

Thanks. Mumps might has features I would like to integrate but I did
not
find any information about multiple inheritance and dynamic
reclassification. I also could not find your previous post in the
google archives; can you give me a link? Please look at my two
previous posts under this same topic.

Regards,
Seun Osewa

Bernard Peek <bap (AT) shrdlu (DOT) com> wrote

Bernard Peek wrote:



Sadly enough, Mumps does not support inheritance and also nothing you
call dynamic reclassification. Mumps is a strictly PROCEDURAL language.
I've used it for some years (> 5 to be specific).

There are no classes in Mumps. There is even no schema. All there is
(OK - most notable) is a persistent B* tree that allows for index
entries that are strings, a strong support of string function and
some ways to dynamically interpret strings/variables as code.


Objects and Mumps are two different worlds ...

Just my 2 cents
Jürgen

Juergen,

Since I have been working with Mumps now for quite a while (> 10 years) I
can agree with you. Standard implementations of Mumps (e.g. DSM, MSM, DTM,
GT.M, etc...) are as you describe.

But, I have to say that although Mumps itself does not have objects - this
does not prevent you from using either Intersystems Cache or ESI Objects as
the DBMS layered on top of Mumps. Cache and ESI Objects both provide Object
access to a Mumps global.

In fact - if you have not looked at Cache, you might be surprised at the
capabilities of this system. Using this system, you can now provide both
Object and SQL access to your database quite easily. It is - IMHO, worth
looking at...

"Juergen Kindler" <jkindler (AT) freenet (DOT) de> wrote