tutoriald-design

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

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

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