tutoriald-design — Planning and design of an implementation of Tutorial D.

Re: [tutoriald-design] Design Goals

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

On 12 Aug 2003, Leandro Guimarães Faria Corsetti Dutra wrote:

> Em Ter, 2003-08-12 às 20:48, Rene Hartmann escreveu:
>
> > We might want to have some statement that changes the current database,
> > as Tutorial D doesn't provide that. But again this could be easily
> > added to the language. For the beginning, the current database
> > could be provided to the interpreter through command line arguments .
>
> 	AFAIR (without checking the books) that is because D&D want us to think
> distributed.  That is, there would be only one namespace that would be
> "THE" database; where it would reside would fall outside D, that must
> remain entirely logic.
>

Well, RM prescription 17 states that distinct databases shall not
be necessarily disjoint. As I understand it, this means that several
databases may exist within one namespace, sharing relvars.
Duro supports this by allowing the creation of several databases
within one "database environment", and these databases may share tables,
though there is currently no function that performs sharing user
tables between two databases - the only tables shared are the catalog tables.

It migth turn out to be helpful to have statements for creating additional
databases and sharing tables between these databases, for example,
to support the creation of application-specific databases
(I think there is some article from Date or Darwen which mentions
application-spcific databases, but I don't have it at hand).

But it's true that statements which deal with databases would be
outside of D - outside the "D part" of the language, so to say.

--
Rene´

Re: [tutoriald-design] Design Goals

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

On Mon, 11 Aug 2003, Brian Olsen wrote:
> >
> > In fact I was already planning to implement a Tutorial D interpreter
> > at some later time.
>
> This is excellent. Do you have a sketch or outline of how you are going
> to approach it?
>

Only a few ideas. I want Duro to support operators written in arbitrary
languages, so my idea is to implement the interpreter in form of a
function that can be passed to Duro when defining a user-defined operator.
That interpreter function will later be called with the code as an
argument. The interpreter program would simply read (or map) the
code into memory and pass it to the interpreter function.

>
> > But these are mainly two: I/O operations and error handling.
> > It should be not very difficult to add I/O operations, and
> > for the first version(s) the error handling could just be having the
> > interpreter exit with an error message. Later some TRY ... CATCH
> > construct could be added to the language.
>
>
> Besides the two things you mention, can there be anything else that can
> make it 'industrial strength'?

IMHO nothing that couldn't be added later. The TTM mentions sessions and
connections, but that doesn't apply to a 'embedded' DB engine like Duro.

We might want to have some statement that changes the current database,
as Tutorial D doesn't provide that. But again this could be easily
added to the language. For the beginning, the current database
could be provided to the interpreter through command line arguments .

--
Rene´

Re: [tutoriald-design] Design Goals

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

P=E5 Monday, 11. August 2003, kl. 13:27, skrev Rene Hartmann:

> On 11 Aug 2003, Leandro Guimar=E3es Faria Corsetti Dutra wrote:
>
>> Em Seg, 2003-08-11 =C3=A0s 06:32, Brian Olsen escreveu:
>>> In thinking about creating an implementation of Tutorial D, we =
should
>>> figure out what the design goals are, given the time, knowledge and
>>> other factors involved.
>>>
>>> - I think it makes sense, and it seems to be the consensus, to
>>> implement over Duro. The process of creating the language is then
>>> simplified to a degree.
>>
>> 	Agreed.  Actually, one can consider the language is already =
created,=20
>> if
>> we want *Tutorial* D.
>
> Yes, there is already a LALR(1) grammar available at the third=20
> manifesto
> website.

It has to be modified a little bit to get it to work with yacc though.=20=

:-)

> I would prefer implementing Tutorial D; it's a language which is both
> small and powerful, and I think it is the purest embodiment of the
> D concepts (As it apprears to me, purer than D4, which has cursors,
> as opposed to Tutorial D).

I am in agreement. I think if we find certain things that are missing,=20=

they can be tacked on as well. (Like what you mention below.)

I haven't read the arguments about cursors thoroughly. However, in RM=20
Very Strong Suggestion 9, which discusses SQL migration, in the=20
Manifesto, suggests what to do with cursors. What problems are with it?=20=

Does it impose an order on relations? What would be used instead?


>  When designing Duro, I tried to be as close
> to Tutorial D as possible.
>
> In fact I was already planning to implement a Tutorial D interpreter
> at some later time.

This is excellent. Do you have a sketch or outline of how you are going=20=

to approach it?

> I agree with Leandro that we should start with
> the data access parts. OK, Tutorial D is not industrial strength,
> which means it lacks some features required for a 'real' language.

> But these are mainly two: I/O operations and error handling.
> It should be not very difficult to add I/O operations, and
> for the first version(s) the error handling could just be having the
> interpreter exit with an error message. Later some TRY ... CATCH
> construct could be added to the language.


Besides the two things you mention, can there be anything else that can=20=

make it 'industrial strength'?

Brian=

Re: [tutoriald-design] Design Goals

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

On 11 Aug 2003, Leandro Guimarães Faria Corsetti Dutra wrote:

> Em Seg, 2003-08-11 às 06:32, Brian Olsen escreveu:
> > In thinking about creating an implementation of Tutorial D, we should
> > figure out what the design goals are, given the time, knowledge and
> > other factors involved.
> >
> > - I think it makes sense, and it seems to be the consensus, to
> > implement over Duro. The process of creating the language is then
> > simplified to a degree.
>
> 	Agreed.  Actually, one can consider the language is already created, if
> we want *Tutorial* D.

Yes, there is already a LALR(1) grammar available at the third manifesto
website.

I would prefer implementing Tutorial D; it's a language which is both
small and powerful, and I think it is the purest embodiment of the
D concepts (As it apprears to me, purer than D4, which has cursors,
as opposed to Tutorial D). When designing Duro, I tried to be as close
to Tutorial D as possible.

In fact I was already planning to implement a Tutorial D interpreter
at some later time.

I want to implement a Tcl interface to Duro for one the next versions,
and this interface is supposed to contain an interpreter for
relational expressions, to make using the relational algebra easier.
My idea was to extend this interpreter step by step to a
Tutorial D interpreter.

By the way, if the project is not implementing Tutorial D, it should
not be named Tutorial D.

So my idea would be to implement an interpreter for Tutorial D
as defined in the TTM. I agree with Leandro that we should start with
the data access parts. OK, Tutorial D is not industrial strength,
which means it lacks some features required for a 'real' language.

But these are mainly two: I/O operations and error handling.
It should be not very difficult to add I/O operations, and
for the first version(s) the error handling could just be having the
interpreter exit with an error message. Later some TRY ... CATCH
construct could be added to the language.

--
Rene'

Re: [tutoriald-design] Design Goals

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

Em Seg, 2003-08-11 às 06:32, Brian Olsen escreveu:
> In thinking about creating an implementation of Tutorial D, we should 
> figure out what the design goals are, given the time, knowledge and 
> other factors involved.
> 
> - I think it makes sense, and it seems to be the consensus, to 
> implement over Duro. The process of creating the language is then 
> simplified to a degree.

	Agreed.  Actually, one can consider the language is already created, if
we want *Tutorial* D.  If it is a generic D, then one has the choice of
Tutorial D, D4, even extending QUEL or BS12... or one can create
something, but then has to choose even style -- COBOL-like just as
Tutorial D, Pascal-like as D4, C-like, C#, functional?

	Just as a tip, Nathan Allan is considering "open sourcing" parts of
Dataphor, so perhaps D4 is as good a choice as any other, as he has some
support from Date & Darwen.


> - What should be the general design goal? I personally think we 
> shouldn't expect much from the first implementation. I think the goal 
> should be that the environment is conducive to just working with 
> Tutorial D - possibly as an educational tool first. What's the opinion 
> here?

	The idea of Tutorial D is exactly to be implemented as an educational
tool, it was never meant to be a "serious" language, even if its
COBOLesque flavour should make it accessible to SQL coders.

	I'd even favor implementing first the specific data access portions
first; computational completeness is needed to user-defined data types,
but it is lower priority than "getting it working", and can be reused if
one extends an existing language (such as Lisp) instead of going for the
syntax of Tutorial D.


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

[tutoriald-design] Design Goals

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

In thinking about creating an implementation of Tutorial D, we should 
figure out what the design goals are, given the time, knowledge and 
other factors involved.

- I think it makes sense, and it seems to be the consensus, to 
implement over Duro. The process of creating the language is then 
simplified to a degree.
- What should be the general design goal? I personally think we 
shouldn't expect much from the first implementation. I think the goal 
should be that the environment is conducive to just working with 
Tutorial D - possibly as an educational tool first. What's the opinion 
here?
- is there any other things that might be part of the language that 
could be useful?

I can't think of anything else for now. Basically, I would like the 
goals to be small, and from there, the course of events could be 
decided from there.

Brian

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?

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

[tutoriald-design] Date's AItDS, 8th ed

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

	To the lucky ones among you who are employed at the moment, you can
already buy the latest Date from http://aw.com./, including an appendix
on the TranRelational stuff.

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

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

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

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

[tutoriald-design] Relational C library available for download

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

Hello all,

the C library which I announced some months ago is now
available in full source from:

http://rehartmann.bei.t-online.de/duro

--
Rene´

[tutoriald-design] D and Logic Programming

[Richard R. M. <the...@ho...>]

Hello,

My name is McKinley and I actually live in Provo, UT and have recently =
been to a demonstration and discussion at Alphora.  Very interesting =
product.

Leandro, eu tambem falo portuguese.  Morei em Minas Gerais por um tempo.

I am interested in the project.  I will probably buy a license for =
Dataphor as it is a good price (for a corporation) and a good product.  =
I have no desire to compete with them, but I would like to help provide =
options to people who cannot use proprietary-license software.

Right now I do not have much to add except for this one thought:  Could =
and should D be created using an existing Logic Programming language?  =
It seems to me that D already lends itself to such a thing.  I have =
found one that seems to enjoy somewhat current support and modern =
status.  It is called Mercury, is GPL, and can be found at =
http://www.cs.mu.oz.au/research/mercury/

Just some thoughts.

Cheers,

McKinley

Re: [tutoriald-design] Relational C library

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

On Wed, 2002-10-09 at 23:13, Rene Hartmann wrote:
>=20
> I want to use an 'open source' license, but  haven't made up my mind
> yet which one (GNU, Apache, etc.) is best.

	Obviously it depends on which are your goals: dissemination, standards
setting, technology fostering, freedom sometimes are at odds.  May I
suggest a read of http://www.gnu.org./philosophy/ and
http://www.gnu.org./licenses/licenses.html?


--=20
  _   Leandro Guimar=E3es Faria Corsetti Dutra    +41 (21) 648 11 35
 / \  http://homepage.mac.com/leandrod/         +41 (21) 216 15 93
 \ /  Lausanne, Vaud, Suisse                 fx +41 (21) 216 19 04
 / \  Fita ASCII contra correio eletr=F4nico HTML             BRASIL

[tutoriald-design] Relational C library

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

Hello,

I am currently trying to write a relational C library on top of Berkeley DB.

The idea is to provide a library that provides tables(relvars), tuples etc.
together with a relational algebra. Transactions are available via Berkeley DB.

The final goal is to be as D compliant as it is possible for a C library.
D compliance has priority over performance, but I think the latter
will also improve over time.

The library could be used directly by a C/C++ programer (or even
from some other programming language) or to implement a
language like Tutorial D on top of it.

I work on it in my spare time and I don't know how far I will get
but in the moment I am quite optimistic that I can produce something
presentable in the next months.

--
René

Re: [tutoriald-design] RE: tutoriald-design digest, Vol 1 #3 - 3 msgs

[Leandro F. C. D. <lea...@ma...>]

On Thu, 2002-09-12 at 13:41, Spencer Olson wrote:
>=20
> One of the chief
> concerns that I have with the Alphora implementation is its reliance on t=
he=20
> language C#.  Not that I have anything against C# per se, but rather bein=
g
> cornered into using a language in the first place.=20

	Then I think you will like to learn that Alphora Dataphor does not
corner you into C#.  In fact, the Dataphor D, named D4, is more based on
Pascal.  It uses C# as one would use Java to create a new language, as a
libraries and virtual machine framework.

	BTW, welcome.  Sorry for the sorry state of the project, but just after
creating it I started travelling around like crazy, and ended up first
being fired, than being four months looking for a job, then emigrating
to Switzerland.  A rough road, but I hope to be settled in a few more
weeks and then do something more useful.

	Meanwhile, if anyone has done something, you are welcome to talk about
and even post!  I am the project owner, but if someone has something
real to show, I would be willing to accept co-owner or even transfer the
whole thing.

	About implementations: when I stopped thinking about it, I was
considering doing a Scheme implementation, kinda like SchemeQL but a
valid D.  For a storage engine, I was considering PostgreSQL, as it has
high relational pedigree, coming from University Ingres and its nice
QUEL relational calculus language perhaps it still has all the hooks to
support a second language.  But I would also consider using the alpha
GNU SQL Server, because I favor transferring copyrights to the FSF.

	Thanks a lot for livening this up!


--=20
  _   Leandro Guimar=E3es Faria Corsetti Dutra    +41 (21) 648 11 35
 / \  http://homepage.mac.com/leandrod/         +41 (21) 216 15 93
 \ /  Lausanne, Vaud, Suisse                 fx +41 (21) 216 19 04
 / \  Fita ASCII contra correio eletr=F4nico HTML             BRASIL

[tutoriald-design] RE: tutoriald-design digest, Vol 1 #3 - 3 msgs

[Spencer O. <so...@pr...>]

An LALR(1) grammar can be found at the www.thethirdmanifesto.com website.

As far as parser and parser generators go I have no inclination
to using one over the other (mostly because I've never done it before ;)).

I have been trying out the parser engine from GOLD simply because I like
the claims it makes regarding language independence. *shrug*.  One of the
chief
concerns that I have with the Alphora implementation is its reliance on the 
language C#.  Not that I have anything against C# per se, but rather being
cornered into using a language in the first place. 

From TTM:

"We remark that it would probably be desirable in practice to suport an
"external"
format of <user scalar op def> as well.  Syntactically, such a production
rule
would include, not a <statement> (as in the grammar), but rather a reference
to some
external file in which the code that implements the operator can be found".

This is what Alphora has done with the "class .." portion of their language
D4. However
I much prefer the second possibility from TTM.

"It might also be desirable to support a format of <user scalar op def> that
includes neither
a <statement> not an external erference; such a format would define merely
what 
Chapters 13 and 14 call a "specification signature" for the operator in
question, and
the implementation code would then have to be defined elsewhere."

-spencer

Re: [tutoriald-design] RE: tutoriald-design digest, Vol 1 #2 - 1 msg

[<ha...@pl...>]

On Tue, 10 Sep 2002, Spencer Olson wrote:

> Just a quick note.  There is an implementation of TMT by a company out in
> Provo, Utah.  The company is called Alphora and the product Dataphor. I have
> taken a quick look at their downloadable version (and they even sent me
> a free version of the product for finding a bunch of bugs ;) ) and am
> suitably impressed.   You can read Darwen's impression of the product
> on the Database Debunkings website (www.dbdebunk.com).

I have read about Alphora (I live very close to Provo), maybe I'll have to
download the eval, and go bug hunting :-).

>
> While I think they have done a superb job in some respects, I still think a
> better implementation can be achieved, and one that does not rely upon
> Microsoft's C# ( or at least if it does, not to expose it in tutorialD).
> There has been very little activity on this project, but just wanted
> to let you know that you are not alone out there, and someone is monitoring
> this list :)
>

Much as multiple implementations help out new and upcoming
network protocols I think an Open-source/libre/free-software
implementation of TTM would be a benifit to the community.

What are your thoughts on where such a project should start? With a
working parser? Perhaps we could start with something similar to Alphora
by implementing the language on top of an existing
transaction-capable data-store such as Postgres.

At any rate it's good to know there's others out there listening and
interested.

-- Dan

> -spencer
>
> -----Original Message-----
> From: tut...@li...
> [mailto:tut...@li...]
> Sent: Tuesday, September 10, 2002 3:11 PM
> To: tut...@li...
> Subject: tutoriald-design digest, Vol 1 #2 - 1 msg
>
>
> Send tutoriald-design mailing list submissions to
> 	tut...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/tutoriald-design
> or, via email, send a message with subject or body 'help' to
> 	tut...@li...
>
> You can reach the person managing the list at
> 	tut...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tutoriald-design digest..."
>
>
> Today's Topics:
>
>    1. Anything going on around here? (ha...@pl...)
>
> --__--__--
>
> Message: 1
> Date: Mon, 9 Sep 2002 14:49:59 -0600 (MDT)
> From: <ha...@pl...>
> To: <tut...@li...>
> Subject: [tutoriald-design] Anything going on around here?
>
> Hi folks, anybody out there?
>
> Just looking to stir some discussion up about all this stuff. I recently
> purchased Date and Darwen's Third Manifesto, and have been slowly moving
> through it. And in wondering about implementing a system such as they
> describe I'm wondering where to start? I noticed the single message on the
> mailing list in the last year mentioned a parser, and that's kind of the
> conclusion I came to. Hence I've started to read up on bison. :-).
>
> Any body actively monitoring this list?
>
> -- Dan Hanks
>
>
>
>
> --__--__--
>
> _______________________________________________
> tutoriald-design mailing list
> tut...@li...
> https://lists.sourceforge.net/lists/listinfo/tutoriald-design
>
>
> End of tutoriald-design Digest
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> tutoriald-design mailing list
> tut...@li...
> https://lists.sourceforge.net/lists/listinfo/tutoriald-design
>

[tutoriald-design] RE: tutoriald-design digest, Vol 1 #2 - 1 msg

[Spencer O. <so...@pr...>]

Just a quick note.  There is an implementation of TMT by a company out in
Provo, Utah.  The company is called Alphora and the product Dataphor. I have
taken a quick look at their downloadable version (and they even sent me
a free version of the product for finding a bunch of bugs ;) ) and am 
suitably impressed.   You can read Darwen's impression of the product 
on the Database Debunkings website (www.dbdebunk.com).

While I think they have done a superb job in some respects, I still think a
better implementation can be achieved, and one that does not rely upon 
Microsoft's C# ( or at least if it does, not to expose it in tutorialD). 
There has been very little activity on this project, but just wanted
to let you know that you are not alone out there, and someone is monitoring 
this list :)

-spencer

-----Original Message-----
From: tut...@li...
[mailto:tut...@li...]
Sent: Tuesday, September 10, 2002 3:11 PM
To: tut...@li...
Subject: tutoriald-design digest, Vol 1 #2 - 1 msg


Send tutoriald-design mailing list submissions to
	tut...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/tutoriald-design
or, via email, send a message with subject or body 'help' to
	tut...@li...

You can reach the person managing the list at
	tut...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tutoriald-design digest..."


Today's Topics:

   1. Anything going on around here? (ha...@pl...)

--__--__--

Message: 1
Date: Mon, 9 Sep 2002 14:49:59 -0600 (MDT)
From: <ha...@pl...>
To: <tut...@li...>
Subject: [tutoriald-design] Anything going on around here?

Hi folks, anybody out there?

Just looking to stir some discussion up about all this stuff. I recently
purchased Date and Darwen's Third Manifesto, and have been slowly moving
through it. And in wondering about implementing a system such as they
describe I'm wondering where to start? I noticed the single message on the
mailing list in the last year mentioned a parser, and that's kind of the
conclusion I came to. Hence I've started to read up on bison. :-).

Any body actively monitoring this list?

-- Dan Hanks




--__--__--

_______________________________________________
tutoriald-design mailing list
tut...@li...
https://lists.sourceforge.net/lists/listinfo/tutoriald-design


End of tutoriald-design Digest

[tutoriald-design] Anything going on around here?

[<ha...@pl...>]

Hi folks, anybody out there?

Just looking to stir some discussion up about all this stuff. I recently
purchased Date and Darwen's Third Manifesto, and have been slowly moving
through it. And in wondering about implementing a system such as they
describe I'm wondering where to start? I noticed the single message on the
mailing list in the last year mentioned a parser, and that's kind of the
conclusion I came to. Hence I've started to read up on bison. :-).

Any body actively monitoring this list?

-- Dan Hanks

[tutoriald-design] Re: TutorialD

[<lea...@ma...>]

Rick Morris escreveu:
>=20
> I read one of your posts on Slashdot, and found your=20
> sourceforge project on TutorialD. I see that there is really=20

	Good, that was really the ideal about posting at Slashdot, to get some=20
attention to Tutorial D and the sad state of DBMSs.



> nothing happening here, but I hope there are plans for the=20
> future.

	Depends on what you call plans.

	I have no deadlines, and am currently unable to do any useful work.  I=20
have moved from Brazil to Switzerland, and Swiss rules are almost=20
driving me crazy.

	Nevertheless, I intend to resume my studies RSN, and hope to be able to=20
start doing basics like an EBNF syntax, translating it into Lex or=20
Scheme code, etc, in two or three months.



> I speak not as a developer who is capable of programming a=20
> DBMS, but a developer who would love to be able to WORK=20
> with one. I am more familiar with the lightweight programming=20
> languages such as Perl, PHP, etc...

	Same position as me.  I realize I have lots to learn, so I'm making no=20
assumptions about anyone else's current knowledge.



> But, if there is anything I can do to help in the implementation=20
> of a true relational database, I will do what I can. Although I=20
> am not a C programmer, I do have a fairly good knowledge of=20
> the relational model, some mathematical background, and=20
> have been reading as much theory as possible from Date,=20
> Darwen, Pascal, etc... (and I have read every single article at=20
> DBDebunk.com (lol);-)

	Good!  Seems we have somewhat similar backgrounds.

	If you peradventure has more time in your hands than me at the present=20
moment, there are somethings that need be done.  One I already=20
mentioned, the EBNF syntax.  Or at least we could discuss it.  You could=20
subscribe to the list at http://tutoriald.sf.net./ that is now dormant,=20
so that at least our initial discussions aren't lost to posterity!  :-)

	Other thing that I intend to do sooner or later is the GNU paperwork.  I=
=20
wouldn't like to have the work in the public domain for software=20
hoarders to take, nor would like to be the copyright owner.



> So, I will be happy to help in such secondary tasks as setting=20
> up a website, documentation, assisting in forums, mail, etc...=20
> as well as testing.

	I have already set a SourceForge account.  I have considered moving to=20
http://savannah.gnu.org./, but there are contacts and paperwork to be=20
done.  You could start by either improving http://tutoriald.sf.net./, or=20
moving it to http://savannah.gnu.org./.



> I think there is a growing number of developers who are=20
> dissatisfied with existing SQL implementations, and would=20
> love to see a real relational implementation. See a thread=20

	I hope you are right.  When I participated in comp.database.theory the=20
newsgroup was seriously inundated with SQL help requests and stupid=20
questions from newbies who didn't want to do their reading.  There were=20
no more than two or three people posting sanely, and we were loosing our=20
time in byzantine discussions worse than Slashdot's.  Also, I tried to=20
submit stories to Slashdot about DBDebunk and Alphora Dataphor, to no=20
avail.  All in all I do think awareness is still very low.


> called "Object support in the relational model??" at=20
> comp.database.theory. I mentioned you in my post. I also=20

	Thanks for that!  I hope we can deal with our impending fame!  ;-)


> mentioned the PostgreSQL project. What do you think of the=20
> possibility to involve PostgreSQL developers in such an effort?

	When I was still at my home country I tried to start something involving=
=20
either PostgreSQL, or GNU SQL Server, or some other free DBMS like Leap,=20
Firebird=E2=80=A6 everyone has more interest in a "good" SQL implementati=
on than=20
in doing things right.  Come to think about that, that's why everyone's=20
coding in C, not Lisp!

	If you read pgsql-devel (I forget the real name of that list) you will=20
see the discussion.  It must have been last year, I think.


> Anyway, I think it is a good time to start a movement for such=20
> things, and I am ready to provide whatever help I can.

	Thanks for your offer, I hope we can make it into the start of something=
=20
real!


--=20
  _
/ \ Leandro Guimar=C3=A3es Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/        fax +41 (21) 216 19 04
  X  http://tutoriald.sf.net./               Orange Communications CH
/ \ ASCII Ribbon Campaign against HTML email      +41 (21) 216 15 93