From: Brian O. <br...@qi...> - 2003-08-11 04:33:01
|
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 |
From: Leandro F. C. D. <lgc...@te...> - 2003-08-11 08:10:09
|
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! |
From: <reh...@t-...> - 2003-08-11 17:32:45
|
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' |
From: Brian O. <br...@qi...> - 2003-08-11 20:50:54
|
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= |
From: <reh...@t-...> - 2003-08-12 19:14:57
|
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´ |