tutoriald-design

[tutoriald-design] D over an existing language?

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

Hello,

	I hope people here are still subscribed to this list - maybe a 
discussion (if nothing else) can spin-off from this.

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

	I think the most interesting things that can arise from such a library 
is:
		- the ability to create data types of arbitrary complexity (maybe 
through classes?
		- the ability to define relations via a DDL that enforces such things 
as the primary key requirement.
		- the ability to use the same "query language" within an application 
seamlessly as well as used in an ad-hoc query tool
		- portability - I would start on Berkeley DB (like Duro), but make it 
portable, especially in case a true relational database engine comes out
		- using relational algebra/calculus to express queries (no SQL - that 
language is a nuisance ... )
		- in line with the last one, easier to express queries.

	Given what is said by Date and others, a real implementation of the 
relational model will be a naturally superior alternative over SQL and 
I think it will particularly shine in application development. (I got 
that sense with Dataphor ... )
	
	Here is a *very* small implementation of relations:
		
	http://starship.python.net/crew/aaron_watters/kjbuckets/relalg.py

	There are some interesting ideas in here, in terms of implementation.

	I hope this spurs up a little conversation on the list, if nothing 
else.


Brian
	


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

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

[Leandro F. C. D. <lgc...@te...>]

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


> 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 it 
> portable, especially in case a true relational database engine comes 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.


> 	Here is a *very* small implementation of relations:
> 		
> 	http://starship.python.net/crew/aaron_watters/kjbuckets/relalg.py

	Do you want to host it at tutoriald.sf.net?

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


-- 
 _   Leandro Guimarães Faria Corsetti Dutra    +41 (21) 648 11 34
/ \  Lausanne, Vaud, Suisse                    +41 (78) 778 11 34
\ /  Brasil                                    +55 (11) 5686 2219
/ \  http://br.geocities.com./lgcdutra/          Soli Deo Gloria!

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

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

[Leandro F. C. D. <lgc...@te...>]

Em Dom, 2003-08-03 às 21:45, Brian Olsen - Lists escreveu:

> Yes, I would like to be a part of it. (my SF username is brian0891.) I 
> wouldn't mind being administration if you want me to.

	There you are...


-- 
 _   Leandro Guimarães Faria Corsetti Dutra    +41 (21) 648 11 34
/ \  Lausanne, Vaud, Suisse                    +41 (78) 778 11 34
\ /  Brasil                                    +55 (11) 5686 2219
/ \  http://br.geocities.com./lgcdutra/          Soli Deo Gloria!

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

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

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

Corsetti Dutra:

> Em Dom, 2003-08-03 =E0s 21:45, Brian Olsen - Lists escreveu:
>
>> Yes, I would like to be a part of it. (my SF username is brian0891.) =
I
>> wouldn't mind being administration if you want me to.
>
> 	There you are...


Excellent. Thanks.

I guess maybe we can start discussing a D implementation, maybe over=20
Duro (a complete turnaround from what I said before) ... all of this is=20=

really exciting, and I might start my C education a bit earlier than=20
planned to start learning the tools to get this working ...


Brian


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

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

[<reh...@t-...>]

Hello,

On Sat, 2 Aug 2003, Brian Olsen wrote:

[...]
>
> 	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
> 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. :-)
>
> 	I think the most interesting things that can arise from such a library
> is:
> 		- the ability to create data types of arbitrary complexity (maybe
> through classes?

The problem of implementing user-defined types using Python is that, to my
knowledge, Python is one of the languages that belong to the 'object
world', which is, sadly, incompatible with D in many respects.

These languages, for example, are heavily using references, which are not
allowed in a Database in D. This has important consequences for
user-defined types.

For example, read the discussion about the difference between D
selectors and object world constructors at the end of the informal
discussion of RM prescripion 4 in chapter 6 of the TTM.
You must be aware of these problems if you try to implement D using an OO
language like Python.

By the way, the next version of Duro (0.6) will contain support (although
still limited) for user-defined types, TTM style. That support is already
in the CVS.

> 		- the ability to define relations via a DDL that enforces such things
> as the primary key requirement.
> 		- the ability to use the same "query language" within an application
> seamlessly as well as used in an ad-hoc query tool
> 		- portability - I would start on Berkeley DB (like Duro), but make it
> portable, especially in case a true relational database engine comes out

Well, I am not sure what would be gained by starting to implement a D
system in Python using Berkeley DB, because that would very much repeat
the work which was already done (or will be done) to implement Duro. I
don't think the possibility to use the Berkeley DB Python API compensates
for this.

As Leandro suggested, it may be a better idea to write a Python interface
for Duro. This would have to be done in C, but would be much less work.

--
Rene´ Hartmann

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

[Brian O. <br...@qi...>]

> The problem of implementing user-defined types using Python is that, 
> to my
> knowledge, Python is one of the languages that belong to the 'object
> world', which is, sadly, incompatible with D in many respects.
>
> These languages, for example, are heavily using references, which are 
> not
> allowed in a Database in D. This has important consequences for
> user-defined types.

Yeah, I see what you mean here. That didn't occur to me.

> For example, read the discussion about the difference between D
> selectors and object world constructors at the end of the informal
> discussion of RM prescripion 4 in chapter 6 of the TTM.
> You must be aware of these problems if you try to implement D using an 
> OO
> language like Python.

Figuring the disparity between approaches, I was figuring that 
something would pop up. :-( Described in RM Prescription 4, this 
situation certainly complicates this issue a lot.

> Well, I am not sure what would be gained by starting to implement a D
> system in Python using Berkeley DB, because that would very much repeat
> the work which was already done (or will be done) to implement Duro. I
> don't think the possibility to use the Berkeley DB Python API 
> compensates
> for this.
>
> As Leandro suggested, it may be a better idea to write a Python 
> interface
> for Duro. This would have to be done in C, but would be much less work.

This could just be the best approach then. I'd rather learn than 
compete. :-)

Thanks.

Brian