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=