Re: [tutoriald-design] D over an existing language?

[Brian O. - L. <mai...@qi...>]

P=E5 Sunday, 3. August 2003, kl. 14:30, skrev Leandro Guimar=E3es Faria=20=

Corsetti Dutra:

>> 	I hope people here are still subscribed to this list - maybe a
>> discussion (if nothing else) can spin-off from this.
>
> 	Here I am!
>
>
>> 	After reading a bit of C.J. Date's books (the manifesto, intro), =
I've
>> been pondering how a D-type language would fit into a existing
>> language. I see that there is the Duro library, but alas, I don't =
know
>
> 	Do you mean to create an extension to a traditional language?

Yeah, essentially. I am worried though that I might not meet the goals=20=

of D in an existing language. Maybe later on I will write a list of=20
what I think can be done in Python (I got a few ideas already,=20
interface-wise), and then maybe see how it is approached in Duro. Maybe=20=

it can then be possible to map Python to the Duro code if there is a=20
basic connection between what I am thinking, syntactically with Duro.

> I guess
> it can be useful, but traditionally one would implement a embeddable
> (sub)language, like SQL is or Tutorial D aims to do.  AFAIR, D4 is =
also
> meant to be embedded.

The reason is to provide an extension to an already existing language=20
is to allow one to integrate the relational database tools with other=20
APIs unrelated to database management - making it easier for people to=20=

learn and use proper data fundamentals within a familiar environment.

I thought D4 was meant to be a complete application development=20
language, along with the Dataphor environment. I have to look at the=20
docs again though.

The one major complaint OODBMS advocates complained about was that you=20=

are grafting another language into your code. Besides all the=20
marketing-buzzword-babble they were discussing, it has a small grain of=20=

truth in it, at least in terms of working with SQL. I hate writing SQL,=20=

and if I can have something that keeps me from writing it, I would=20
rather use that instead (which I am. :-)


> 	The trouble is, each language will have its own syntax, and it =
will be
> somewhat of a pain to learn one extension to each language and another
> for interactive usage.  I would favor using Tutorial D or D4 embedded
> everywhere except at functional languages, that are clearly different
> enough, and interesting enough, to warrant a tighter integration.

I think the same library can be used in applications as well as in an=20
interactive mode. Python is nice because the interactive part comes=20
"free" with it. The interactive part will allow you to use the same=20
library to create relations and query against them using the same=20
syntax as used in application development. I am figuring a simple query=20=

can be like such:

a =3D join(s,p) # or a =3D s + p
b =3D restrict(a, id=3D1)

(p has a foreign key from s, they join to create the relation for=20
relvar a. and then 'b' is created on a restriction on 'a')

This can be reasonably be done in both environments. (the syntax above=20=

is very simple though. :-)

I would like to see a free implementation of Tutorial D anyway, exactly=20=

how it is described in the manifesto and the intro. The other reason=20
for settling on a library instead of a new language implementation is=20
because that I feel I can do the library now over a new language=20
implementation. But I would like to be involved anyway, in whatever=20
capacity, in a Tutorial D implementation.

>> C to grok it (going back to school to learn it though. :-) I am
>> specifically interested in (even though not completely committed to,
>> yet) implementing a relational library in Python (because it is my
>> favorite language. :-)
>
> 	At the moment all bets are off, so you could have a winner.
>
>
>> 		- portability - I would start on Berkeley DB (like =
Duro), but make=20
>> it
>> portable, especially in case a true relational database engine comes=20=

>> out
>
> 	Ideally Duro or something the like would become that engine.  =
Given
> that something in Duro already exists, have you considered making your
> library a Python interface to Duro?

> 	Point is, I guess at this moment we win more by collaborating =
than by
> competing.

This is an idea that I had as well, since the implementation has=20
already started. How tied is it to Berkeley DB though? Can it be=20
unraveled from it to make it more portable? Since I am going to start=20
learning C very soon, this could be an interesting project to pick up=20
and learn once I understand the syntactic elements of C. (along with=20
the Python C-API :-)

Maybe there could be interest also to write a Tutorial D over Duro?=20
This would be awesome to see.


In the end of this, my goal is to learn more about the relational model=20=

by actually writing something that can possibly resemble it in the most=20=

complete form as possible. Maybe if I don't write, at least more=20
interest can be drawn up in understanding and implementing the=20
relational model completely.

Actually, to be honest, besides Duro, I am surprised there isn't more=20
interest in developing free tools that implement the relational model.=20=

Maybe just many enthusiastic programmers felt that sql dbms's like=20
MySQL and SQL were a perfect realization of the relational model ...=20
sigh ...

(Just thinking about open source DBMSs, maybe there could be interest=20
in bringing back the old Ingres source or old Postgres source hanging=20
on UC Berkeley's site and bring QUEL back from the dead ... hmmm ... )

>> 	Here is a *very* small implementation of relations:
>> 	=09
>> 	=
http://starship.python.net/crew/aaron_watters/kjbuckets/relalg.py
>
> 	Do you want to host it at tutoriald.sf.net?

Well, we can provide a link to it, if nothing else (since its not my=20
code ... :-)

> 	If so, I could transfer administration, or include you... I have =
to
> look for a job, so no time to do it myself.

Yes, I would like to be a part of it. (my SF username is brian0891.) I=20=

wouldn't mind being administration if you want me to.

Brian

----------------------------------------------------
Brian Olsen
Qinternet Corporation
Email: brian at qinternet dot com
----------------------------------------------------