* tagged types extensions - language design question @ 2000-01-27 0:00 Vladimir Olensky 2000-01-27 0:00 ` Fraser ` (4 more replies) 0 siblings, 5 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-01-27 0:00 UTC (permalink / raw) The question is : Why in Ada it is not allowed to extend both public and private part of the tagged type at one step ( using kind of syntax as in the following example ): package P is type T is tagged private; type T1 is new T with record with private something: some_type; and record; private type T is tagged with record ID : Integer; end record; type T1 is new T with record thing : some_other_type; end record; end P; Instead I should do this in two steps. 1. to extend private part and then 2. to extend public part or vice versa. Due to that type T1 has inheritance_depth = 3 instead of inheritance_depth = 2. LRM (3.9.1) says: Every type extension is a tagged type, and is EITHER a record extension OR a private extension of some other tagged type. It would be interesting to know what were the reasons not to allow to have BOTH a record extension AND a private extension at the same time. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky @ 2000-01-27 0:00 ` Fraser 2000-01-27 0:00 ` Matthew Heaney ` (3 subsequent siblings) 4 siblings, 0 replies; 80+ messages in thread From: Fraser @ 2000-01-27 0:00 UTC (permalink / raw) paene lacrimavi postquam Vladimir Olensky scripsit: >The question is : > > Why in Ada it is not allowed to extend both public > and private part of the tagged type at one step ( using > kind of syntax as in the following example ): Ada doesn't have "partially private" records -- what you're talking about seems to be a special case of that. There are several reasons for this: it doesn't fit with the idea of 'private' (if you can fiddle with part of a record, it breaks the abstraction) and it's extra syntax for something with much cleaner alternatives (accessor functions), Private tagged types have effective public bits (the tag) but this is a Good Thing. In any case, why would you ever have non private tagged type? Doesn't that defeat the purpose? Fraser. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky 2000-01-27 0:00 ` Fraser @ 2000-01-27 0:00 ` Matthew Heaney 2000-01-27 0:00 ` Charles Hixson 2000-01-28 0:00 ` Vladimir Olensky 2000-01-27 0:00 ` Laurent Guerby ` (2 subsequent siblings) 4 siblings, 2 replies; 80+ messages in thread From: Matthew Heaney @ 2000-01-27 0:00 UTC (permalink / raw) In article <s90mu0hg7q538@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: Why don't you just declare these types in separate packages? package P is type T is tagged private; private type T is tagged record ...; end P; package P.C is type T1_Public is abstract new T with record Something : Some_Other_Type; end record; type T1 is new T1_Public with private; private type T1 is new T1_Public with record ... ; end P.C; > package P is > > type T is tagged private; > > type T1 is new T with > record with private > something: some_type; > and record; > > private > > type T is tagged with > record > ID : Integer; > end record; > > type T1 is new T with > record > thing : some_other_type; > end record; > > end P; > > Instead I should do this in two steps. > 1. to extend private part and then > 2. to extend public part > or vice versa. > > Due to that type T1 has inheritance_depth = 3 > instead of inheritance_depth = 2. > > LRM (3.9.1) says: > Every type extension is a tagged type, > and is EITHER a record extension OR a private > extension of some other tagged type. > > It would be interesting to know what were > the reasons not to allow to have BOTH a record > extension AND a private extension at the same time. > > Regards, > Vladimir Olensky > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 ` Matthew Heaney @ 2000-01-27 0:00 ` Charles Hixson 2000-01-28 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 80+ messages in thread From: Charles Hixson @ 2000-01-27 0:00 UTC (permalink / raw) That should work, but the question was why couldn't it be done in one step. (I don't know.) Matthew Heaney wrote: > In article <s90mu0hg7q538@corp.supernews.com> , "Vladimir Olensky" > <vladimir_olensky@yahoo.com> wrote: > > Why don't you just declare these types in separate packages? > > package P is > > type T is tagged private; > > private > type T is tagged record ...; > end P; > > package P.C is > > type T1_Public is > abstract new T with record > Something : Some_Other_Type; > end record; > > type T1 is new T1_Public with private; > > private > type T1 is new T1_Public with record ... ; > end P.C; > > > package P is > > > > type T is tagged private; > > > > type T1 is new T with > > record with private > > something: some_type; > > and record; > > > > private > > > > type T is tagged with > > record > > ID : Integer; > > end record; > > > > type T1 is new T with > > record > > thing : some_other_type; > > end record; > > > > end P; > > > > Instead I should do this in two steps. > > 1. to extend private part and then > > 2. to extend public part > > or vice versa. > > > > Due to that type T1 has inheritance_depth = 3 > > instead of inheritance_depth = 2. > > > > LRM (3.9.1) says: > > Every type extension is a tagged type, > > and is EITHER a record extension OR a private > > extension of some other tagged type. > > > > It would be interesting to know what were > > the reasons not to allow to have BOTH a record > > extension AND a private extension at the same time. > > > > Regards, > > Vladimir Olensky > > > > ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 ` Matthew Heaney 2000-01-27 0:00 ` Charles Hixson @ 2000-01-28 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Matthew Heaney 1 sibling, 1 reply; 80+ messages in thread From: Vladimir Olensky @ 2000-01-28 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >In article <s90mu0hg7q538@corp.supernews.com> , "Vladimir Olensky" ><vladimir_olensky@yahoo.com> wrote: > >Why don't you just declare these types in separate packages? This is : 1. an additional step 2. an additional package 3. an additional level of inheritance. That's why I was asking why it is not allowed to do this in one step as in other OOP languages. Probably there exist some reasons for that. Though GNAT provides efficient dispatching mechanism it is better to minimize inheritance depth for derived types when possible. Also creating additional packages just to provide visible fields for private tagged type is not handy. Actually I was using additional packages but to my point of view this is not very convenient. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Vladimir Olensky @ 2000-01-28 0:00 ` Matthew Heaney 2000-01-28 0:00 ` Charles Hixson 2000-01-29 0:00 ` Vladimir Olensky 0 siblings, 2 replies; 80+ messages in thread From: Matthew Heaney @ 2000-01-28 0:00 UTC (permalink / raw) In article <s91denm47q5148@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >>Why don't you just declare these types in separate packages? > > This is : > 1. an additional step > 2. an additional package > 3. an additional level of inheritance. But you'd have the "additional package" in other OOP languages too. In another language you'd have to declare two "classes," which means two modules. Same as Ada. (Although I think you can nest classes in C++, right?) Because of the separation of module and type, it's possible to declare intimately-relate types together in a single Ada package. In the normal case --no public attributes-- this can be done quite easily: package P is type T is tagged private; type T1 is new T with private; ... end P; However, when you extend a type, the full view of the type has to be known. That's why this: package P is type T is tagged private; type T1 is new T with record I : Integer; end record; ... end P; is illegal. There's no way to know what components T1 has, because the full view of T hasn't been seen yet. Normally there isn't a problem. But in your case, you want to have a public component. If you're committed to declaring the types together in one package, then you can declare the derived type without a public component, and then: 1) declare a selector function if you want to let clients query the attribute 2a) declare a modifier procedure, to let clients set the attribute; or 2b) declare a modifier function, to let clients set the attribute package P is type T is tagged private; type T1 is new T with private; function Get_I (O : T1) return Integer; procedure Set_I (O : in out T1; I : in Integer); type IA is access all Integer; for IA'Storage_Size use 0; function Set_I (O : access T1) return IA; ... end P; > That's why I was asking why it is not allowed to do this in one step as in > other OOP languages. Probably there exist some reasons for that. Mainly historical. Tucker can speak for himself, but his philosophy was to use existing syntax as much as possible. So instead of bolting a new "object-oriented corner" onto the language, he just took the existing syntax for inheritance: type NT is new T; and slightly modified it to add type extension: type NT is new T with private; > Though GNAT provides efficient dispatching mechanism it is better to > minimize inheritance depth for derived types when possible. If you want to have some attributes public and some attributes private, then you have to declare intermediate (abstract) types in which to do it. That's just happens to be the syntax. Forget about that fact that it increases the inheritance depth; that is irrelevant here. > Also creating additional packages just to provide visible fields for > private tagged type is not handy. That's not the reason for needing an additional package. Normally you wouldn't need the other package. Your problem is that you're trying to derive a type from a parent whose full view hasn't been declared yet. > Actually I was using additional packages but to my point of view this is not > very convenient. It's hard to make hard and fast rules here, but in general, you should use a package hierarchy to declare a type hierarchy. (This would be required in other OOP languages as well.) The exception is when you have a single abstraction that comprises more than one type: package Subjects_And_Observers is type Subject is tagged limited private; type Observer is tagged limited private; procedure Attach (Obs : access Observer; Sub : access Subject); ... end Subjects_And_Observers; Here co-location of the two types makes sense, because each type depends on the other's representation. It's one abstraction (the "observer" pattern, sometimes called "publish/subscribe") that is implemented as a pair of types. However, this is less common than the situation where the dependency is in one direction only. For a typical class (maybe broad, and hopefully shallow), it makes sense to declare the root type in a package, and each derived type in its own child package. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Matthew Heaney @ 2000-01-28 0:00 ` Charles Hixson 2000-01-28 0:00 ` Matthew Heaney 2000-01-29 0:00 ` Vladimir Olensky 1 sibling, 1 reply; 80+ messages in thread From: Charles Hixson @ 2000-01-28 0:00 UTC (permalink / raw) Matthew Heaney wrote: > In article <s91denm47q5148@corp.supernews.com> , "Vladimir Olensky" > <vladimir_olensky@yahoo.com> wrote: > > >>Why don't you just declare these types in separate packages? > > > > This is : > > 1. an additional step > > 2. an additional package > > 3. an additional level of inheritance. > > But you'd have the "additional package" in other OOP languages too. In > another language you'd have to declare two "classes," which means two > modules. Same as Ada. (Although I think you can nest classes in C++, > right?) > My understanding of Eiffel (not the greatest!) is that it would handle THIS PROBLEM gracefully in one step. My problem with it is the lack of control over direct (random access) I/O. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Charles Hixson @ 2000-01-28 0:00 ` Matthew Heaney 2000-02-01 0:00 ` Charles Hixson 0 siblings, 1 reply; 80+ messages in thread From: Matthew Heaney @ 2000-01-28 0:00 UTC (permalink / raw) In article <3891B5B3.7430F96B@earthlink.net> , Charles Hixson <charleshixsn@earthlink.net> wrote: >> But you'd have the "additional package" in other OOP languages too. In >> another language you'd have to declare two "classes," which means two >> modules. Same as Ada. (Although I think you can nest classes in C++, >> right?) >> > > My understanding of Eiffel (not the greatest!) is that it would handle THIS > PROBLEM gracefully in one step. My problem with it is the lack of control > over direct (random access) I/O. I don't understand why everything has to be "done in one step." In Ada95, you have to declare an intermediate (abstract) type, in order to declare some attributes as public. It's really not that big a deal. If you follow that guideline that a type hierarchy should be declared in a package hierarchy, then there is no problem. This is exactly what you'd have to do in other OOP languages (because different classes are each declared in their own module). There seem to be two issues: 1) The relationship between types and modules. 2) The syntax of public versus private attributes. In issue #1, Ada95 gives you *more* than you get in other OOP languages, and that's the ability to declare different types in the same module. You can't do that in many other languages, so there's no limitation in Ada95. In issue #2, Ada95 does require you to declare an intermediate type. Yes, that's "extra" work, but how much are we really talking about? It's only one extra declaration, comprising a mere 2 SLOCS: package P.C is type NT_Public is abstract new T with record Public_Attribute : Public_Attribute_Type; end record; type NT is new NT_Public with private; ... end P.C; Why is everyone getting heartburn about having to declare type NT_Public? In C++, I'd have to use the keyword "public:" before listing the public members, so there's syntactic overhead in that language too. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Matthew Heaney @ 2000-02-01 0:00 ` Charles Hixson 2000-02-01 0:00 ` Matthew Heaney 0 siblings, 1 reply; 80+ messages in thread From: Charles Hixson @ 2000-02-01 0:00 UTC (permalink / raw) Matthew Heaney wrote: > In article <3891B5B3.7430F96B@earthlink.net> , Charles Hixson > <charleshixsn@earthlink.net> wrote: > > >> But you'd have the "additional package" in other OOP languages too. In > >> another language you'd have to declare two "classes," which means two > >> modules. Same as Ada. (Although I think you can nest classes in C++, > >> right?) > >> > > > > My understanding of Eiffel (not the greatest!) is that it would handle THIS > > PROBLEM gracefully in one step. My problem with it is the lack of control > > over direct (random access) I/O. > > I don't understand why everything has to be "done in one step." In > Ada95, you have to declare an intermediate (abstract) type, in order to > declare some attributes as public. It's really not that big a deal. > I can't speak for him (Vladimir Olensky) but my reason is so that I need to keep track of fewer names. I frequently pick up projects for short periods of time, and then put them down for several months before the next time that I pick them up. If I have to keep track of fewer names then I find it easier to reposition myself in the project. Of course, if anything was ever really completed, then the private sections would never need to be thought about again. This, however, doesn't seem to map well into my perceived reality. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-02-01 0:00 ` Charles Hixson @ 2000-02-01 0:00 ` Matthew Heaney 0 siblings, 0 replies; 80+ messages in thread From: Matthew Heaney @ 2000-02-01 0:00 UTC (permalink / raw) In article <38970C27.5362779A@earthlink.net> , Charles Hixson <charleshixsn@earthlink.net> wrote: > I can't speak for him (Vladimir Olensky) but my reason is so that I need to > keep track of fewer names. I frequently pick up projects for short periods of > time, and then put them down for several months before the next time that I > pick them up. If I have to keep track of fewer names then I find it easier to > reposition myself in the project. Of course, if anything was ever really > completed, then the private sections would never need to be thought about > again. This, however, doesn't seem to map well into my perceived reality. There are no names that you need to remember. Suppose I declare an abstraction comprising some public and some private attributes, like this: package P is type T_Public is abstract tagged record Public_Attribute : Public_Attribute_Type; end record; type T is new T_Public with private; ... end P; That type T_Public is part of the hierarchy is irrelevant. This just happens to be the syntax for declaring public attributes in type T, which is the only type you care about. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Matthew Heaney 2000-01-28 0:00 ` Charles Hixson @ 2000-01-29 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Matthew Heaney 2000-01-29 0:00 ` Matthew Heaney 1 sibling, 2 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-01-29 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >In article <s91denm47q5148@corp.supernews.com> , "Vladimir Olensky" ><vladimir_olensky@yahoo.com> wrote: > >>>Why don't you just declare these types in separate packages? >> >> This is : >> 1. an additional step >> 2. an additional package >> 3. an additional level of inheritance. > >But you'd have the "additional package" in other OOP languages too. In >another language you'd have to declare two "classes," which means two >modules. Same as Ada. > (Although I think you can nest classes in C++, right?) Yes, I can nest classes in C++ and in Java. --- Two classes not always equal to two packages. Two classes could be in one file or in one enclosing class but two Ada packages are different files for which I should invent names. Also if I have an abstract root type with private and I extend it to another abstract tagged type with additional private fields and the last one is a parent to two concrete types both of them having the same public attributes then I should put that derived types in additional child package and duplicate that public attributes in each derived type instead of putting them (public attributes) in the abstract parent class. Also I should duplicate primitive operations on that attributes for each derived type instead of defining only one operation in the parent class or even at upper level root class. Or I should first create intermediate package in which public attributes are added to the abstract parent (name it as Root.Parent.PubAttr) and then in the final package to extend that abstract parent with private fields and then in the same package I can create non-abstract derived classes. I could not tell that it is very convenient. It would be better to have all this in one package. In C++ I can do that in just one step. Below is simple working C++ example (just created and tested): Type T is parent that has both public and protected part; Type T1 is a child that extends T with public and protected members in one step. No need in any additional intermediate class. -------------------------------------------------------- -- protected fields and members are the same as private -- but are visible in derived classes - the same as private -- components are visible in the child packages ------------------------- #include "stdafx.h"; class T { protected: // visible only in the derived classes int s ; public: int x,y; T() { s =2; x=3; y=4;}; // constructor }; class T1 : T { protected: int s1 ; public: int x1,y1; int Calculate () { return (s+s1)*(x+x1+y+y1); } T1() { s1 =3; x1=6; y1=7;}; }; int main(int argc, char* argv[]) { int result; T1 P; result = P.Calculate(); printf("result is %d \n", result); // result is 100 return 0; } ----------------------------------------------- >Because of the separation of module and type, it's possible to declare >intimately-relate types together in a single Ada package. In the normal >case --no public attributes-- this can be done quite easily: > >package P is > type T is tagged private; > type T1 is new T with private; ... >end P; This is exactly what I am doing for descendants that extend only private part of their parent and what I would like to have for derived types with both public and private attributes. >However, when you extend a type, the full view of the type has to be >known. That's why this: > >package P is > type T is tagged private; > type T1 is new T with record > I : Integer; > end record; >... >end P; > >is illegal. There's no way to know what components T1 has, >because the full view of T hasn't been seen yet. From formal (LRM) point of view this is right. But from practical point of view this is right if we have only one pass compiler that does not know what it will have further in the compiled file. For two or more pass compiler this is not a problem. It gathers needed information during first pass and uses it at the next pass. (at least for Modula compilers that I know this is not a problem as well as for C++). >Normally there isn't a problem. But in your case, you want to have a >public component. If you're committed to declaring the types together >in one package, then you can declare the derived type without a public >component, and then: >1) declare a selector function if you want to let clients query the attribute >2a) declare a modifier procedure, to let clients set the attribute; or >2b) declare a modifier function, to let clients set the attribute >package P is > type T is tagged private; > type T1 is new T with private; > function Get_I (O : T1) return Integer; > procedure Set_I (O : in out T1; I : in Integer); > type IA is access all Integer; > for IA'Storage_Size use 0; > function Set_I (O : access T1) return IA; >end P; This is all good and well but all this is an additional work that could be avoided. >If you want to have some attributes public and some attributes private, >then you have to declare intermediate (abstract) types in which to do it. I had to do that and that's why I was asking my question. >It's hard to make hard and fast rules here, but in general, you should >use a package hierarchy to declare a type hierarchy. (This would be >required in other OOP languages as well.) This is what I am doing in reality but additional intermediate packages for derived types with public attributes break naming scheme in this chain. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-29 0:00 ` Vladimir Olensky @ 2000-01-29 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Matthew Heaney 1 sibling, 1 reply; 80+ messages in thread From: Matthew Heaney @ 2000-01-29 0:00 UTC (permalink / raw) In article <s94522bcq0s54@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > Two classes not always equal to two packages. Yes, I think we agree on this. My example of this was the implementation of the Observer pattern. > Two classes could be in one file or in one enclosing class but two Ada > packages are different files for which I should invent names. Not necessarily. The relationship of packages ("program units") to files isn't specified by the language. Some compilers require that they be in separate files, but not all compilers do. If you do want to put multiple program units in a single file, then you can just use gnatchop to automatically create separate files for each unit. > Also if I have an abstract root type with private and I extend it to another > abstract tagged type with additional private fields and the last one is a > parent to two concrete types both of them having the same public attributes > then I should put that derived types in additional child package and duplicate > that public attributes in each derived type instead of putting them (public > attributes) in the abstract parent class. If I understand you correctly, I showed how to do this in my last message. You do not have to duplicate public attributes. The intermediate type in which the public attributes are declared can be shared among derived types, and without upsetting the "natural" package hierarchy. > Also I should duplicate primitive operations on that attributes for each > derived type instead of defining only one operation in the parent class > or even at upper level root class. The primitive operations for the intermediate type can be declared together with the declaration of the type. No duplication is necessary. > Or I should first create intermediate package in which public attributes are > added to the abstract parent (name it as Root.Parent.PubAttr) and then in > the final package to extend that abstract parent with private fields and then > in the same package I can create non-abstract derived classes. I could not > tell that it is very convenient. It would be better to have all this in one > package. I'm not sure what you're trying to say here, but it sounds similar the the example I posted in my last message. If you're trying to declare public and private attributes, then you're going to have to declare (abstract) intermediate types. Yes, this carries a syntactic burden, but we disagree about its severity. In any kind of design problem (here, the design of a computer language), one rule of thumb is "design for the common case." In other words, common things should be easy to do. Don't make the uncommon case easy, if that means making the common case harder. As Tucker pointed out, declaring an abstraction with both public and private attributes is not a common thing to do, and so they didn't design for that case specifically. This keeps the language simple. Yes, as a consequence, in this particular case you have to work a little harder in order to implement the abstraction, but you can get the job done. > class T { > protected: // visible only in the derived classes > int s ; > public: > int x,y; > T() { s =2; x=3; y=4;}; // constructor > }; package P is type T_Public is abstract tagged record X : Integer := 3; Y : Integer := 4; end record; type T is new T_Public with private; private type T is new T_Public with record S : Integer := 2; end record; end P; > class T1 : T { > protected: > int s1 ; > public: > int x1,y1; > int Calculate () > { > return (s+s1)*(x+x1+y+y1); > } > T1() { s1 =3; x1=6; y1=7;}; > }; package P.C is type T1_Public is abstract new T with record X1 : Integer := 6; Y1 : Integer := 7; end record; type T1 is new T1_Public with private; function Calculate (O : T1) return Integer; private type T1 is new T1_Public with record S1 : Integer := 3; end record; end P.C; > int main(int argc, char* argv[]) > { > int result; > T1 P; > result = P.Calculate(); > printf("result is %d \n", result); // result is 100 > return 0; > } with P.C; use P.C; procedure Main is O : T1; Result : constant Integer := Calculate (O); begin Put_Line ("Result is " & Integer'Image (Result)); end Main; ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-29 0:00 ` Matthew Heaney @ 2000-01-31 0:00 ` Vladimir Olensky 2000-01-31 0:00 ` Matthew Heaney 0 siblings, 1 reply; 80+ messages in thread From: Vladimir Olensky @ 2000-01-31 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... > >If you're trying to declare public and private attributes, then you're >going to have to declare (abstract) intermediate types. Yes, this >carries a syntactic burden, but we disagree about its severity. > >In any kind of design problem (here, the design of a computer language), >one rule of thumb is "design for the common case." In other words, >common things should be easy to do. Don't make the uncommon case easy, >if that means making the common case harder. > >As Tucker pointed out, declaring an abstraction with both public and >private attributes is not a common thing to do, and so they didn't >design for that case specifically. This keeps the language simple. > >Yes, as a consequence, in this particular case you have to work a little >harder in order to implement the abstraction, but you can get the job >done. Yes, as a matter of fact this is not a big deal. Actually everything needed could be declared in one package. One need just to remember the right sequence - first to declare abstract public extension of the root type, then it's abstract private extension and then concrete final extensions (in my case two of them). Very similar to the case when one wants to declare deallocation procedure for some private type in the same package where this private type is declared. Here right sequence is also very important and might be even less obvious for those who encounter that need for the first time. In fact it is a little bit surprising when you first time encounter this tagged type extension restriction but when you get used to it does not seem that unusual. Now when I get used to it I feel nothing strange about that. Thanks to all who responded. Others point of view is always very useful. Sometimes it is a little bit difficult to overcome thinking inertia in adopting some things that seem strange at a first glance. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-31 0:00 ` Vladimir Olensky @ 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 80+ messages in thread From: Matthew Heaney @ 2000-01-31 0:00 UTC (permalink / raw) In article <s9av7kh45io46@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > Yes, as a matter of fact this is not a big deal. > Actually everything needed could be declared in one package. > One need just to remember the right sequence - first to declare > abstract public extension of the root type, then it's abstract private > extension and then concrete final extensions (in my case two of them). Yes, you have to declare the public part of abstraction first. > Very similar to the case when one wants to declare deallocation > procedure for some private type in the same package where this > private type is declared. Here right sequence is also very important > and might be even less obvious for those who encounter that need > for the first time. If you have a "by-reference" abstraction, that is, an abstraction designated by a pointer, then there's an idiom for that too. (You need to put objects on the heap when you have "containment by reference," instead of "containment by value," as is often the case when doing class-wide programming.) Basically, you declare the type as limited and indefinite, and declare all primitive operations with access parameters: package P is type T (<>) is abstract tagged limited private; type T_Access is access all T'Class; for T_Access'Storage_Size use 0; procedure Op (O : access T); ... end P; Non-abstract types in the class declare a constructor for the type: package P.C is type NT is new T with private; function New_NT return T_Access; -- possibly NT_Access procedure Op (O : access NT); ... end P.C; That all types in the class are limited and indefinite prevents clients from declaring their own instances directly. You want to force them to use your constructor. In general, a client should never invoke an allocator ("new T") directly. Give them a constructor, and invoke the allocator internally. The other issue is how to reclaim instances. You can either provide: 1) a classwide Free operation (declared in the root package, and implemented by calling an instantiation of Unchecked_Deallocation, or by calling a private dispatching deconstructor) 2) instead of using an access type, use a smart pointer, and let deallocation be automatically Both of these techniques are in the patterns archive (which I'm about to do some maintenance of). <http://www.acm.org/archives/patterns.html> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-31 0:00 ` Matthew Heaney @ 2000-01-31 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-01-31 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >In article <s9av7kh45io46@corp.supernews.com> , "Vladimir Olensky" ><vladimir_olensky@yahoo.com> wrote: > >Yes, you have to declare the public part of abstraction first. > >> Very similar to the case when one wants to declare deallocation >> procedure for some private type in the same package where this >> private type is declared. Here right sequence is also very important >> and might be even less obvious for those who encounter that need >> for the first time. <...> >The other issue is how to reclaim instances. You can either provide: > >1) a classwide Free operation (declared in the root package, and >implemented by calling an instantiation of Unchecked_Deallocation, or by >calling a private dispatching deconstructor) > >2) instead of using an access type, use a smart pointer, and let >deallocation be automatically As a matter of fact I am using both techniques when appropriate. For private types I frequently use inlined public classwide Free procedure that calls private Free_Obj classwide procedure: package P is type Root is abstract new Limited_Controlled with private; type Root_Ref is access all Root'Class; procedure Free (obj_Ref : in out Root_Ref); pragma Inline (Free); private type Root is abstract new Limited_Controlled with record Ref_Count : Integer := 0; -- for "smart pointer" when it is used; <some root common private fields>; record; procedure Free_Obj is new Ada.Unchecked_Deallocation ( Root'Class, Root_Ref ); end P; package body P is procedure Free (obj_Ref : in out T_Ref) is Free_Obj (obj_Ref); end Free; end P; That's it. It works for any descendants of the root class. >In general, a client should never invoke an allocator ("new T") >directly. Give them a constructor, and invoke the allocator internally. Constructor for any descendants of Controlled type is it's Initialize procedure. With controlled types one does not need to create special public constructor for the derived class. Everything is done automatically by the Initialize. Yes, if one does not want to use controlled type then one may want to provide his/her own public constructor. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-29 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Matthew Heaney @ 2000-01-29 0:00 ` Matthew Heaney 1 sibling, 0 replies; 80+ messages in thread From: Matthew Heaney @ 2000-01-29 0:00 UTC (permalink / raw) In article <s94522bcq0s54@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >>It's hard to make hard and fast rules here, but in general, you should >>use a package hierarchy to declare a type hierarchy. (This would be >>required in other OOP languages as well.) > > > This is what I am doing in reality but additional intermediate packages > for derived types with public attributes break naming scheme in this chain. The intermediate type (the one with the public attributes) need not break the naming scheme. You can declare the intermediate type in its own package, and then types that derive from that one simply 'with' the package, instead of becoming a child. Here's some code: package P is type T is tagged private; private type T is tagged record I : Integer; end record; end P; package P.C is type NT is abstract new T with record F : Float; end record; end P.C; with P.C; package P.C1 is type NT1 is new P.C.NT with private; private type NT1 is new P.C.NT with record B : Boolean; end record; end P.C1; with P.C; package P.C2 is type NT2 is new P.C.NT with private; private type NT2 is new P.C.NT with record Another_Float : Long_Float; end record; end P.C2; with P.C1; with P.C2; procedure Test_Public is O1 : P.C1.NT1; O2 : P.C2.NT2; begin O1.F := 2.5; O2.F := 3.4; end Test_Public; This is an example of a type hierarchy *not* following the package hierarchy. Types NT1 and NT2 both derive from intermediate type P.C.NT, but they are declared in child packages of P, not P.C. As they say, the exception proves the rule. Does this meet your needs? -- Philosophy may be ignored but not escaped; and those who most ignore least escape. David Hawkins ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky 2000-01-27 0:00 ` Fraser 2000-01-27 0:00 ` Matthew Heaney @ 2000-01-27 0:00 ` Laurent Guerby 2000-01-28 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Tucker Taft 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist 4 siblings, 1 reply; 80+ messages in thread From: Laurent Guerby @ 2000-01-27 0:00 UTC (permalink / raw) "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > The question is : > > Why in Ada it is not allowed to extend both public > and private part of the tagged type at one step ( using > kind of syntax as in the following example ): > > package P is > > type T is tagged private; > > type T1 is new T with > record with private > something: some_type; > and record; > > private > > type T is tagged with > record > ID : Integer; > end record; > > type T1 is new T with > record > thing : some_other_type; > end record; > > end P; What about: type T1_Private is private; type T1 is new T with record something_public : some_type; something_private : T1_Private; end record; private type T1_Private is record -- whatever... end record; > It would be interesting to know what were > the reasons not to allow to have BOTH a record > extension AND a private extension at the same time. Looks like it's easy to emulate, at least in the simple case you provided. > Regards, > Vladimir Olensky --LG ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 ` Laurent Guerby @ 2000-01-28 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Andy 0 siblings, 1 reply; 80+ messages in thread From: Vladimir Olensky @ 2000-01-28 0:00 UTC (permalink / raw) Laurent Guerby wrote in message <867lgvs47x.fsf@ppp-112-253.villette.club-internet.fr>... >"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes: > >> The question is : >> >> Why in Ada it is not allowed to extend both public >> and private part of the tagged type at one step ( using >> kind of syntax as in the following example ): >> >> package P is >> >> type T is tagged private; >> >> type T1 is new T with >> record with private >> something: some_type; >> and record; >> >> private >> >> type T is tagged with >> record >> ID : Integer; >> end record; >> >> type T1 is new T with >> record >> thing : some_other_type; >> end record; >> >> end P; > >What about: > > type T1_Private is private; > > type T1 is new T with record > something_public : some_type; > something_private : T1_Private; > end record; > >private > > type T1_Private is record > -- whatever... > end record; > >> It would be interesting to know what were >> the reasons not to allow to have BOTH a record >> extension AND a private extension at the same time. > >Looks like it's easy to emulate, at least in the simple case you >provided. This is not very good as in this case the layout oh the descendant (common part) will be different from the layout of it's private parent type that serves as a common root to several different "children" and some of them may have additional public (visible fields) together with additional private fields. Better way is just to use two extension steps but here we are back to my original question - why it is not allowed to do this in one step as in other OOP languages. Regards, Vladimir Olensky Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Vladimir Olensky @ 2000-01-28 0:00 ` Andy 2000-01-28 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 80+ messages in thread From: Andy @ 2000-01-28 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > > Laurent Guerby wrote in message > <867lgvs47x.fsf@ppp-112-253.villette.club-internet.fr>... --- snipped --- > >What about: > > > > type T1_Private is private; > > > > type T1 is new T with record > > something_public : some_type; > > something_private : T1_Private; > > end record; > > > >private > > > > type T1_Private is record > > -- whatever... > > end record; > > > >> It would be interesting to know what were > >> the reasons not to allow to have BOTH a record > >> extension AND a private extension at the same time. > > > >Looks like it's easy to emulate, at least in the simple case you > >provided. > > This is not very good as in this case the layout oh the descendant > (common part) will be different from the layout of it's private parent > type that serves as a common root to several different "children" > and some of them may have additional public (visible fields) > together with additional private fields. Not sure what you mean by the 'layout'. The private parts are private, the child types should not care about the layout of the private data (unless they themselves are located in child packages and therefore have visibility to their parent's private bits). In regards to your original question: why isn't both a public and private extention allowed at the same time? I expect it is to avoid an overley complicated syntax to acheive something that can effectively be acheived by other (at least two suggested in this thread) means. ___________________________________________ Andy ___________________________________________ (sorry if this is a duplicate - I had an error on the first attempt) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Andy @ 2000-01-28 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Andy 0 siblings, 1 reply; 80+ messages in thread From: Vladimir Olensky @ 2000-01-28 0:00 UTC (permalink / raw) Andy wrote in message <38918156.7C35@nospam.com.tj>... >Not sure what you mean by the 'layout'. The private parts are private, >the child types should not care about the layout of the private data >(unless they themselves are located in child packages and therefore >have visibility to their parent's private bits). This is exactly my case. I am creating a "tree" of child packages from one root (which has only private components) and children have access to the private fields of their parents. Some of the extensions have public attributes (some of them do not) and I have to to create additional intermediate package for components with public attributes. This is not a big problem, it is just inconvenience. Actually the problem is that naming scheme becomes more complicated as I need to invent names for such intermediate packages and everything should be clean and easily understandable. Regards, Vladimir Olensky > >In regards to your original question: why isn't both a public and >private >extention allowed at the same time? I expect it is to avoid an overley >complicated syntax to acheive something that can effectively be acheived >by other (at least two suggested in this thread) means. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Vladimir Olensky @ 2000-01-29 0:00 ` Andy 2000-01-31 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 80+ messages in thread From: Andy @ 2000-01-29 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > Actually the problem is that naming scheme becomes more > complicated as I need to invent names for such intermediate > packages and everything should be clean and easily understandable. > Although it is good practice to have each child class type in its own package, if the intermediate type is just to allow a double extension (one public, one private), why not just do so in the one package, something like: -- Root class -- package P1 is type Root is abstract tagged null record; procedure Method (X : in Root) is abstract; end P1; -- Child class -- package P1.P2 is -- public extension -- this is abstract so we don't have to override any -- abstract operations defined by the paraent class. -- type Intermediates is abstract new P1.Root with record F : Float; -- etc. end record; type Objects is new Intermediates with private; procedure Method (X : in Objects); private type Objects is new Intermediates with record I : Integer; -- etc. end record; end P1.P2; Cheers Andy ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-29 0:00 ` Andy @ 2000-01-31 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-01-31 0:00 UTC (permalink / raw) Andy wrote in message <3892BABB.290D@nospam.com.tj>... >Although it is good practice to have each child class type in its >own package, if the intermediate type is just to allow a double >extension (one public, one private), why not just do so in the one >package, something like: > >-- Root class >-- >package P1 is > type Root is abstract tagged null record; > procedure Method (X : in Root) is abstract; >end P1; > >-- Child class >-- >package P1.P2 is > > -- public extension > -- this is abstract so we don't have to override any > -- abstract operations defined by the paraent class. > -- > type Intermediates is abstract new P1.Root with record > F : Float; -- etc. > end record; > > type Objects is new Intermediates with private; > > procedure Method (X : in Objects); > >private > > type Objects is new Intermediates with record > I : Integer; -- etc. > end record; > >end P1.P2; Yes, that's fine. Creating one intermediate type with public attributes is not a big deal. It looks strange at first glance that one can not extend both public and private part in one step but then one get used to it and it does not seem to be a problem any more. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky ` (2 preceding siblings ...) 2000-01-27 0:00 ` Laurent Guerby @ 2000-01-28 0:00 ` Tucker Taft 2000-01-31 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Charles Hixson 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist 4 siblings, 2 replies; 80+ messages in thread From: Tucker Taft @ 2000-01-28 0:00 UTC (permalink / raw) Vladimir Olensky wrote: > > The question is : > > Why in Ada it is not allowed to extend both public > and private part of the tagged type at one step ( using > kind of syntax as in the following example ): > ... > > It would be interesting to know what were > the reasons not to allow to have BOTH a record > extension AND a private extension at the same time. When designing a language there are hundreds of tradeoffs. We chose a "building block" approach to Ada 95. Rather than trying to anticipate all uses, and make every feature have several bells and whistles, we tried to provide features that can be combined in an infinite number of ways to solve whatever problems are encountered. In general, if you start comparing languages, you are working in the "solution" space rather than the "problem" space, and you will generally be frustrated if you try to find an exact match in the solution space. The more important issue is whether you can solve the problems of interest efficiently and effectively using the features of the language you are evaluating. Personally, I would be more interested in real-world examples of problems that in some sense require an abstraction whose implementation is partly private and partly visible. In some of the problems I have seen, a natural solution in Ada is to implement the abstraction with a fully public record type, but make certain components of the record be of a private type. More often, I have found it better to implement the abstraction using a fully private type, and then add set/get operations as needed to expose certain components where appropriate. Quite often I end up discovering that either the "set" or "get" ends up requiring more than a simple assignment or load from the corresponding component of the underlying record, and I congratulate myself for having the "foresight" (yeah, right) to use a fully-private type in the first place. I suppose the ultimate answer is that the need for a partly private/ partly visible abstraction was thought to be rare enough that it was felt to be better to keep the set of language primitives simpler, and allow the programmer to combine them as needed to handle the more complicated problems. As usual, your mileage may vary... > Regards, > Vladimir Olensky -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Tucker Taft @ 2000-01-31 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Charles Hixson 1 sibling, 0 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-01-31 0:00 UTC (permalink / raw) Tucker Taft wrote in message <389207CC.C16D80E8@averstar.com>... >Vladimir Olensky wrote: >> >> The question is : >> >> Why in Ada it is not allowed to extend both public >> and private part of the tagged type at one step ( using >> kind of syntax as in the following example ): >> ... >> It would be interesting to know what were >> the reasons not to allow to have BOTH a record >> extension AND a private extension at the same time. ------------------- > I suppose the ultimate answer is that the need for a partly private/ >partly visible abstraction was thought to be rare enough that it >was felt to be better to keep the set of language primitives simpler, and >allow the programmer to combine them as needed to handle the more >complicated problems. As usual, your mileage may vary... >Personally, I would be more interested in real-world examples >of problems that in some sense require an abstraction whose >implementation is partly private and partly visible. Below is my example: Having now some spare time I started to create general purpose communication subsystem for WinNT which gives it's users unified access to any communication tool/device. So far everything regarding communications is scattered around in WinAPIs and I know only one implementation of such high-level communication class library and this is Adaptive Communication Environment -ACE created by Doug Schmidt. This is very good one but it is written entirely in C++. I decided to create Ada based communication subsystem using more simple and traditional approach how to combine everything in one communication class library that provides unified access to any needed mean of communication regardless of it's nature (serial communications, parallel communications, USB, pipes, mailslots, memory mapped files, sockets and any other device/tool that may appear later). All these communication "bricks" could allow quickly build any control application that needs easy communication between it's loosely coupled parts that could work on the same machine or on the different ones. This allows to use more lightweighted and easy approach than CORBA. On the other hand higher level abstractions (as used in ACE ) could be easily built using such general purpose communication library. This idea was eating me for quite some time not allowing me to concentrate on some other interesting things so I felt that it is time to give it it's way out. Now it is beginning to take shape. I started with Win IPC and implemented memory mapped files, mailslots, named pipes (only sync mode so far). And this library will grow with the time. My design model is as follows: Any mean of communication could be considered as communication controller that handles underlying communication device. Controller provides standard set of operations for the client and translation of these commands into low level communication device primitives. Communication device handles communication on the physical level. In this model communication device can be considered as set of correspondent OS or driver API calls or as direct device implementation as in case of memory mapped files (it does not really matter ). On the other hand in any communication process there are two sides. One is a Server process and the other is a Client process. Or in the communication terms one side is DTE and the other is DCE. DTE/DCE corresponds not only to the physical ports but also to the logical role of each side ( e.g in X.25 or Frame Relay two stations can communicate with each other having direct connection of DTI physical ports where one side plays logical DCE role and the other is logical DTE role). What's interesting there is nothing new in all that. This is a standard way to build communication systems hardware and software but surprisingly this approach is rarely used in design of most of the operating systems user libraries and in software development systems. At least Java libraries come close to that in some extent. I know only one system which has clever implementation of that model. This is a communication subsystem of OS/400 for IBM AS/400 midframe. May be there exist others but I do not know. According to this model I have abstract communication controller root type which is Limited_Controlled type (RHT) with private part and set of standard non abstract communication primitives - Open,Close,Read, Write, Peek, Get_Controller_State, Get_Device_State, Get_Config, Set_Config, Initialize etc. There are two kinds of operations in a root package: 1. first type is primitive RHT operations : procedure Op (hComm: in out RHT) is begin raise Not_Implemented; end Op; 2. the others are class wide operations procedure Op (hComm_Ref : in out RHT_Ref_Type) is begin Op (hComm.all); end Op; where RHT_Ref_Type is access all RHT'Class; Each concrete controller and it's underlying device are initialized implicitly by creating the instance of particular controller: sPipe : Server_Named_Pipe; sPipe_Ref : Server_Named_Pipe_Ref_Type := new Server_Named_Pipe; and then one can use any of the standard communication controller primitives. So far everything is OK. Problem arise when we come to the run time communication device properties that we do not know in advance. The idea of the communication controller is that all the communication primitives are defined at the top level and we do not want to break this model by adding some new operations later (may be only some very limited number). But on the other hand for some of the communication devices we should allow client to know some of the low level device properties ( view access) to take some client dependant decisions ( One of the examples is simplex communication of two applications via memory mapped file or async operational mode where one may want to know the state of related events for the particular device ) . This means that these properties should have public access. First I did that as a separate (from the controller) Device Property Record type defined in each concrete device controller package but then I come to conclusion that this is bad approach as all the information about device should be contained in the device controller and be available to the controller client only via this device controller interface. There are also some other things that makes first approach (with separate RT property record variable) very inflexible. As a result of that I moved these run time device properties record into controller record as a Device_RT_Properties record entry (with public view ). At this point I found that I could not extend both public and private part of the tagged type in one step and that's why I asked my question - why it not allowed in Ada to extend both public and private part in one step. Another question regarding this issue is how can I make this properties to have read only access for clients and read-write access internally without any low level unchecked programming. The last one is easy but it is always better to avoid any low level tricks. As a matter of fact I started all these as Windows NT communication subsystem and called it as WinCMN. Actually this is some kind of universal approach and that unified communication interface could be used to access any communication resources in any other operating system and be a kind of general purpose Ada class library ( for any OS) that allows to dynamically create, deallocate, use, insert that controllers in chains/lists , query available communication resources etc. May be it is worth until it is not too late to change the name of the root package to ACMN and have OS dependant child packages named after each OS ( e.g. ACMN.Win - for WinNT communication subsystem, ACMN.Linux - for Linux, ACMN.NR_OS - for Nick Roberts AdaOS etc.) ??? I have now only three concrete controller classes and it is not very difficult to change naming scheme at this moment. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-28 0:00 ` Tucker Taft 2000-01-31 0:00 ` Vladimir Olensky @ 2000-02-01 0:00 ` Charles Hixson 2000-02-01 0:00 ` Matthew Heaney 1 sibling, 1 reply; 80+ messages in thread From: Charles Hixson @ 2000-02-01 0:00 UTC (permalink / raw) Tucker Taft wrote: > -- snip > > In general, if you start comparing languages, you are working in > the "solution" space rather than the "problem" space, and you will > generally be frustrated if you try to find an exact match in the > solution space. The more important issue is whether you can solve > the problems of interest efficiently and effectively using the > features of the language you are evaluating. > > -- snip Along this line, what would be nice would be a language that merged the capabilities of the dynamic binding languages [e.g., Smalltalk] and the capabilities of the static binding languages [e.g., Ada]. So far the closest match that I've found is Python/C, though that has a lot of limitations. Closer to what I am contemplating would be a merger of Ada95 and Java, without the Ada code being required to be executing on the JVM. Is there any good way to call native Ada methods from Ada-for-the-JVM? (Of course, Java is no Smalltalk, or even a Python. But it does have a rather nice library with lots of dynamic methods in it.) To be real specific about what I would like: Is there any reasonable way to call GNAT routines from Squeak? The idea here is that code would be prototyped in Smalltalk, and then transferred to Ada if it turned out to be used with much frequency (and it was reasonably easy to convert, of course: Some dynamic features just don't convert well). ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-02-01 0:00 ` Charles Hixson @ 2000-02-01 0:00 ` Matthew Heaney 2000-02-01 0:00 ` Brian Rogoff 0 siblings, 1 reply; 80+ messages in thread From: Matthew Heaney @ 2000-02-01 0:00 UTC (permalink / raw) In article <38971028.BB16D8A2@earthlink.net> , Charles Hixson <charleshixsn@earthlink.net> wrote: > Along this line, what would be nice would be a language that merged the > capabilities of the dynamic binding languages [e.g., Smalltalk] and the > capabilities of the static binding languages [e.g., Ada]. So far the closest > match that I've found is Python/C, though that has a lot of limitations. Isn't that what Objective-C tries to do? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-02-01 0:00 ` Matthew Heaney @ 2000-02-01 0:00 ` Brian Rogoff 2000-02-03 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) root 0 siblings, 1 reply; 80+ messages in thread From: Brian Rogoff @ 2000-02-01 0:00 UTC (permalink / raw) On Tue, 1 Feb 2000, Matthew Heaney wrote: > In article <38971028.BB16D8A2@earthlink.net> , Charles Hixson > <charleshixsn@earthlink.net> wrote: > > Along this line, what would be nice would be a language that merged the > > capabilities of the dynamic binding languages [e.g., Smalltalk] and the > > capabilities of the static binding languages [e.g., Ada]. So far the closest > > match that I've found is Python/C, though that has a lot of limitations. > > Isn't that what Objective-C tries to do? Objective-C allows you to nail down the binding of some object types, but doesn't come close to Ada in this regard. I would suggest Dylan if you want these capabilities in one language, though pragmatically speaking the implementations aren't mature enough for me yet. Charles did mention Python/C, and that's something I've been thinking about a lot lately; a scripting language written in Ada. Of course, one of the reasons for the success of C as a host for scripting languages is the enormous base of C code out there, which Ada doesn't have. Nonetheless, a scripting/extension language for Ada is an appealing idea. Dylan-over-Ada anyone? Yikes, that acronym is horrible :-) -- Brian ^ permalink raw reply [flat|nested] 80+ messages in thread
* scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-01 0:00 ` Brian Rogoff @ 2000-02-03 0:00 ` root 2000-02-03 0:00 ` Brian Rogoff 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Ehud Lamm 0 siblings, 2 replies; 80+ messages in thread From: root @ 2000-02-03 0:00 UTC (permalink / raw) Brian Rogoff wrote: > ... > Charles did mention Python/C, and that's something I've been thinking > about a lot lately; a scripting language written in Ada. Of course, one of > the reasons for the success of C as a host for scripting languages is the > enormous base of C code out there, which Ada doesn't have. Nonetheless, a > scripting/extension language for Ada is an appealing idea. "scripting/extension language in Ada" and "scripting/extension language for Ada" are different issues. I agree that the later is an appealing idea. I also feel that there is a need for : 1 - a scripting language : it could be a dramatic evolution over the various shell languages. We all have experienced small shell scripts that become bigger and bigger and cause stupid bugs that could be easily avoided by a more strongly typed language. Current scripting languages are unreadable and dangerous! Some Ada influence in this area would be great. 2 - an extension language : [x]emacs, autocad, etc... are witnesses of its importance. Some of the extensions are so big that we can consider those as small software. How many development effort could be saved using a language such as Ada? My feeling is that a small Ada subset interpreter could meet both needs. Obviously, file and process management, pattern matching, etc.. should be addressed in this subset. I am aware of the potential challenge that could be creating an interpreter of a to ambitious subset of the language, but we don't need the full Ada power. I think such an interpreter could be of a reasonable size. > > Dylan-over-Ada anyone? Yikes, that acronym is horrible :-) The most important progress is to have a readable and safe language. So why Dylan, Perl? Why not something close to Ada syntax? Each time i need to modify some shell/awk/... scripts written one year ago, i dream of this Ada Shell! :-) > > -- Brian ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-03 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) root @ 2000-02-03 0:00 ` Brian Rogoff 2000-02-04 0:00 ` Ray Blaak 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged typesextensions) Lionel Draghi 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Ehud Lamm 1 sibling, 2 replies; 80+ messages in thread From: Brian Rogoff @ 2000-02-03 0:00 UTC (permalink / raw) On Thu, 3 Feb 2000, root wrote: > Brian Rogoff wrote: > > > ... > > Charles did mention Python/C, and that's something I've been thinking > > about a lot lately; a scripting language written in Ada. Of course, one of > > the reasons for the success of C as a host for scripting languages is the > > enormous base of C code out there, which Ada doesn't have. Nonetheless, a > > scripting/extension language for Ada is an appealing idea. > > "scripting/extension language in Ada" and "scripting/extension language > for Ada" are different issues. Not that different. Typically, the language of extension is the language the scripting language is written in. Most people using Python or Tcl won't write extensions in Ada, since they'd have to use Ada's C interface to hook'em up. > I agree that the later is an appealing idea. > > I also feel that there is a need for : > > 1 - a scripting language : it could be a dramatic evolution over the > various shell languages. We all have experienced small shell scripts > that become bigger and bigger and cause stupid bugs that could be easily > avoided by a more strongly typed language. Current scripting languages > are unreadable and dangerous! Some Ada influence in this area would be > great. A (mostly) strongly typed scripting language sounds good, as long as you don't have to explicitly write type annotations everywhere. > My feeling is that a small Ada subset interpreter could meet both needs. I disagree. A scripting language has different needs. > Obviously, file and process management, pattern matching, etc.. should > be addressed in this subset. I am aware of the potential challenge that > could be creating an interpreter of a to ambitious subset of the > language, but we don't need the full Ada power. I think such an > interpreter could be of a reasonable size. > > > > > Dylan-over-Ada anyone? Yikes, that acronym is horrible :-) > The most important progress is to have a readable and safe language. > So why Dylan, Perl? Why not something close to Ada syntax? Each time i How dare you compare Dylan and Perl for readability! Shame on you! :-) -- Brian ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-03 0:00 ` Brian Rogoff @ 2000-02-04 0:00 ` Ray Blaak 2000-02-04 0:00 ` Stanley R. Allen 2000-02-04 0:00 ` Robert A Duff 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged typesextensions) Lionel Draghi 1 sibling, 2 replies; 80+ messages in thread From: Ray Blaak @ 2000-02-04 0:00 UTC (permalink / raw) I think that Ada as a scripting language is not a good idea. The philosophy of Ada caters to careful design and implementation, strong typing, etc. Ada is a language useful for making well crafted software. Scripting languages, on the other hand, tend to be used for small, quickly written programs, and good ones tend to have a succinct powerful notation. I consider scsh (Scheme shell) to be an ideal scripting language: small definition, succinct notation, high order functions and lexical closures, garbage collection, etc. It has the full power of Scheme with a well designed interface to system services, as well as an interesting regular expression notation. Alternatively, Perl does just fine in a pinch. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Ray Blaak @ 2000-02-04 0:00 ` Stanley R. Allen 2000-02-04 0:00 ` Samuel T. Harris ` (2 more replies) 2000-02-04 0:00 ` Robert A Duff 1 sibling, 3 replies; 80+ messages in thread From: Stanley R. Allen @ 2000-02-04 0:00 UTC (permalink / raw) Ray Blaak wrote: > > I think that Ada as a scripting language is not a good idea. > > The philosophy of Ada caters to careful design and implementation, strong > typing, etc. Ada is a language useful for making well crafted software. > > Scripting languages, on the other hand, tend to be used for small, quickly > written programs, and good ones tend to have a succinct powerful notation. This is bad reasoning, probably based on poor observation. Scripts are becoming a much bigger part of the software development scene, and it's a shame that the script languages in use now are based so heavily on the hacker mentality. In our project, scripts have gotten very large and are used for many critical capabilities. Some are thousands of lines long. We maintain these scripts in our CM database just like the Ada, C, and FORTRAN code. They have long life -- over 5 years. They must be documented because they are updated by many hands over a long period of time. Sound familiar? The philosophy of Ada, if not all its details, needs to migrate to the world of script languages, because scripts ARE software -- the same rules and pitfalls apply. I question your criterion for a "good" script language -- "succinct powerful notation". Isn't this what we've come to learn as a receipe for incomprehensibility? > > I consider scsh (Scheme shell) to be an ideal scripting language: > > [cut] > > Alternatively, Perl does just fine in a pinch. > I can't comment on scsh, but I've seen enough Perl to know that it is a hacker's language front-to-back. I've heard rumors that Python is better than most in terms of supporting "software engineering" in a script language. -- Stanley Allen mailto:Stanley_R_Allen@raytheon.com ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Stanley R. Allen @ 2000-02-04 0:00 ` Samuel T. Harris 2000-02-05 0:00 ` Lionel Draghi 2000-02-05 0:00 ` Ray Blaak 2000-02-05 0:00 ` Lionel Draghi 2 siblings, 1 reply; 80+ messages in thread From: Samuel T. Harris @ 2000-02-04 0:00 UTC (permalink / raw) "Stanley R. Allen" wrote: > > Ray Blaak wrote: > > > > I think that Ada as a scripting language is not a good idea. > > > > The philosophy of Ada caters to careful design and implementation, strong > > typing, etc. Ada is a language useful for making well crafted software. > > > > Scripting languages, on the other hand, tend to be used for small, quickly > > written programs, and good ones tend to have a succinct powerful notation. > > This is bad reasoning, probably based on poor observation. Scripts > are becoming a much bigger part of the software development scene, and > it's a shame that the script languages in use now are based so heavily > on the hacker mentality. In our project, scripts have gotten very large > and are used for many critical capabilities. Some are thousands of lines > long. We maintain these scripts in our CM database just like the Ada, C, > and FORTRAN code. They have long life -- over 5 years. They must be > documented because they are updated by many hands over a long period of > time. Sound familiar? > > The philosophy of Ada, if not all its details, needs to migrate to > the world of script languages, because scripts ARE software -- the same > rules and pitfalls apply. > > I question your criterion for a "good" script language -- "succinct powerful > notation". Isn't this what we've come to learn as a receipe for > incomprehensibility? My feelings exactly. I remember working on the good old Rational R1000 in the Air Force and for Link then Hughes now Raytheon. The entire operating system interface was in Ada with the speed of execution of an interpreter. I was impressed how the total immersion into Ada for the most basic user needs rapidly increased new programmer capabilties in the language. I suppose that is supported by the notion that one learns French much faster by living in France as compared to taking college courses. I have toyed with Ada/Ed as an script interpreter but its requirements to pre-analyze the code does not make it a viable candidate for shell-script replacements. Its just not fast enough. It occurs to me that an Ada interpreter can dispense with many of the compile-time checks, relying instead upon a real compiler to "verify" the script source is correct Ada. This alone would enable an interpreter to simply expand generics like macros and not bother with all the checks concerning the instantiation. If I recall correctly, the old Ada-Sage (now Sage-ST) did include a very limited Ada interpreter. This allowed one to quickly prototype the database interface with simple controlling code with very rapid turn-around. Just the sort of thing one needs with hashing out the user interface on-line with the customer. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Samuel T. Harris @ 2000-02-05 0:00 ` Lionel Draghi 2000-02-05 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 80+ messages in thread From: Lionel Draghi @ 2000-02-05 0:00 UTC (permalink / raw) "Samuel T. Harris" wrote: > ... > My feelings exactly > > I remember working on the good old Rational R1000 in the Air Force > and for Link then Hughes now Raytheon. The entire operating system > interface was in Ada with the speed of execution of an interpreter. > I was impressed how the total immersion into Ada for the most > basic user needs rapidly increased new programmer capabilties > in the language. I suppose that is supported by the notion that > one learns French much faster by living in France as compared > to taking college courses. > > I have toyed with Ada/Ed as an script interpreter but its > requirements to pre-analyze the code does not make it a viable > candidate for shell-script replacements. Its just not fast > enough. > > It occurs to me that an Ada interpreter can dispense with > many of the compile-time checks, relying instead upon a real > compiler to "verify" the script source is correct Ada. > This alone would enable an interpreter to simply expand > generics like macros and not bother with all the checks > concerning the instantiation. This is a good idea. But i am not optimist enough to think that even Ada run time checks could be enforced in a reasonably sized interpreter. But this is the goal. Another question is : should this script language be strictly compatible with Ada? Isn't there any short form that could be effective, and that prevent from direct recompilation with an Ada compiler? For example, it could make sense to consider Ada.Text_IO, or a Pattern Matching package implicitly "whithed" (and maybe even "used"!). > > If I recall correctly, the old Ada-Sage (now Sage-ST) did > include a very limited Ada interpreter. This allowed one > to quickly prototype the database interface with simple > controlling code with very rapid turn-around. Just the > sort of thing one needs with hashing out the user > interface on-line with the customer. Is it available? ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` Lionel Draghi @ 2000-02-05 0:00 ` Samuel T. Harris 2000-02-06 0:00 ` Bryce Bardin 2000-02-06 0:00 ` Lionel Draghi 0 siblings, 2 replies; 80+ messages in thread From: Samuel T. Harris @ 2000-02-05 0:00 UTC (permalink / raw) Lionel Draghi wrote: > > "Samuel T. Harris" wrote: > > > ... > > > > It occurs to me that an Ada interpreter can dispense with > > many of the compile-time checks, relying instead upon a real > > compiler to "verify" the script source is correct Ada. > > This alone would enable an interpreter to simply expand > > generics like macros and not bother with all the checks > > concerning the instantiation. > This is a good idea. But i am not optimist enough to think that even Ada > run time checks could be enforced in a reasonably sized interpreter. But > this is the goal. > Another question is : should this script language be strictly compatible > with Ada? Isn't there any short form that could be effective, and that > prevent from direct recompilation with an Ada compiler? > For example, it could make sense to consider Ada.Text_IO, or a Pattern > Matching package implicitly "whithed" (and maybe even "used"!). Taking a convenience lesson from the Rational R1000, when one opened a command window (i.e. where one would enter operating system commands) it the window initialized with a template of a parameter-less Ada procedure with the most common packages already withed. One simply enter the bits of Ada code to fill in the procedure and away you went. To this day I don't know how they compiled/linked/ran such things so fast, but it was the fastest turn-around I've ever seen. Given the now antiquated hardware Rational used, I am still impressed with its performance as compared to contemporary compilation/linking systems of today. As to you questions, I'd say YES! Why would I want anything similar to Ada. A subset would be acceptable, but any script must be compilable. In this way, the scripting language could be used for rapid prototyping things which will eventually be compiled. Also, how many scripts have your written which you wished would run faster? Ada scripts can be later compiled for greater performance, albeit taking more disk space :) > > > > If I recall correctly, the old Ada-Sage (now Sage-ST) did > > include a very limited Ada interpreter. This allowed one > > to quickly prototype the database interface with simple > > controlling code with very rapid turn-around. Just the > > sort of thing one needs with hashing out the user > > interface on-line with the customer. > Is it available? There is an Sage-ST site which provides downloads but INEL which produced AdaSage was a contract based organization. They would port the system to any compiler/system for a fee. I haven't been to the site lately so you'll have to check yourself. Last time I looked the supported compiler list was getting rather obsolete. > > ________________________________________________________________________ > Lionel Draghi http://attac.org/ -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` Samuel T. Harris @ 2000-02-06 0:00 ` Bryce Bardin 2000-02-08 0:00 ` Samuel T. Harris 2000-02-06 0:00 ` Lionel Draghi 1 sibling, 1 reply; 80+ messages in thread From: Bryce Bardin @ 2000-02-06 0:00 UTC (permalink / raw) "Samuel T. Harris" wrote: > ... > > Taking a convenience lesson from the Rational R1000, when one > opened a command window (i.e. where one would enter operating > system commands) it the window initialized with a template > of a parameter-less Ada procedure with the most common > packages already withed. One simply enter the bits of > Ada code to fill in the procedure and away you went. > To this day I don't know how they compiled/linked/ran > such things so fast, but it was the fastest turn-around > I've ever seen. Given the now antiquated hardware Rational > used, I am still impressed with its performance as compared > to contemporary compilation/linking systems of today. > I believe the R1000 system used incremental compilation and dynamic linking. Unfortunately, it didn't scale well for large development. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-06 0:00 ` Bryce Bardin @ 2000-02-08 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 80+ messages in thread From: Samuel T. Harris @ 2000-02-08 0:00 UTC (permalink / raw) Bryce Bardin wrote: > > "Samuel T. Harris" wrote: > > > ... > > > > Taking a convenience lesson from the Rational R1000, when one > > opened a command window (i.e. where one would enter operating > > system commands) it the window initialized with a template > > of a parameter-less Ada procedure with the most common > > packages already withed. One simply enter the bits of > > Ada code to fill in the procedure and away you went. > > To this day I don't know how they compiled/linked/ran > > such things so fast, but it was the fastest turn-around > > I've ever seen. Given the now antiquated hardware Rational > > used, I am still impressed with its performance as compared > > to contemporary compilation/linking systems of today. > > > > I believe the R1000 system used incremental compilation and dynamic > linking. Unfortunately, it didn't scale well for large development. I got a similar description from Rational techies at the time. In addition, they explained to me that compilation resulted in a "object" already positioned in the "link" memory space. So linking was a rather simple affair. They also described some special attributed of the commonly used operating system stuff which enable even faster execution of command shells. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` Samuel T. Harris 2000-02-06 0:00 ` Bryce Bardin @ 2000-02-06 0:00 ` Lionel Draghi 1 sibling, 0 replies; 80+ messages in thread From: Lionel Draghi @ 2000-02-06 0:00 UTC (permalink / raw) "Samuel T. Harris" wrote: > ... > > As to you questions, I'd say YES! Why would I want anything > similar to Ada. A subset would be acceptable, but any script > must be compilable. In this way, the scripting language > could be used for rapid prototyping things which will > eventually be compiled. Also, how many scripts have your > written which you wished would run faster? Ada scripts > can be later compiled for greater performance, albeit > taking more disk space :) > To promote easy write, some Ada syntax should probably be changed. An example is the need for dynamic arrays. To achieve that Ada compatibility goal and the possibility to have different deal on some feature, the solution could be to have a standard pre-processor. Some of the facilities could be provided as Ada package, as Ehud said, and available for Ada code. Those facilities could be integrated in the script language syntax to ease writing, and the pre-processor could generate standard Ada code with call to those packages. BTW, Some of the new Ada 00 features could be check this way! > > > ... -- ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Stanley R. Allen 2000-02-04 0:00 ` Samuel T. Harris @ 2000-02-05 0:00 ` Ray Blaak 2000-02-05 0:00 ` Lionel Draghi 2 siblings, 0 replies; 80+ messages in thread From: Ray Blaak @ 2000-02-05 0:00 UTC (permalink / raw) "Stanley R. Allen" <Stanley_R_Allen@raytheon.com> writes: > In our project, scripts have gotten very large and are used for many critical > capabilities. Some are thousands of lines long. We maintain these scripts > in our CM database just like the Ada, C, and FORTRAN code. They have long > life -- over 5 years. They must be documented because they are updated by > many hands over a long period of time. Sound familiar? Ada seems perfectly fine to me for such scripts -- that is, for real software. I, however, tend to use scripts for small little jobs that I can put together quickly. > I question your criterion for a "good" script language -- "succinct powerful > notation". Isn't this what we've come to learn as a receipe for > incomprehensibility? Not at all. Succinct does not mean obfuscated or cryptic. I mean an economy of expression such that things are actually easier to understand since more of the expression is dedicated to the real solution, rather than setting up an infrastructure of declarations. Essentially this is just programming at a higher level of abstraction. See my other post in this thread for an example. In any reasonably sized program, Ada's verbosity is a key feature to aid maintainability. For small very dedicated programs it can be a real pain. > I can't comment on scsh, but I've seen enough Perl to know that > it is a hacker's language front-to-back. Well, Scheme is generally considered to be a Lisp that is about are "pure" as one can get. Common Lispers, however, hate it, since they believe 1) it is not Lisp 2) one cannot do anything real with it, and 3) there is no other language necessary besides Common Lisp. Perl programs tend to be written in a hacky way, but fortunately has features that allow some reasonable semblance of software engineering. One can enable stricter checking and protection styles to the appropriate level of paranoia, and make use of packages. I know I try to write my Perl scripts with good expressive names and strict checking on. At least Perl has garbage collection (mostly) and closures. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Stanley R. Allen 2000-02-04 0:00 ` Samuel T. Harris 2000-02-05 0:00 ` Ray Blaak @ 2000-02-05 0:00 ` Lionel Draghi 2 siblings, 0 replies; 80+ messages in thread From: Lionel Draghi @ 2000-02-05 0:00 UTC (permalink / raw) "Stanley R. Allen" wrote: > ... > > This is bad reasoning, probably based on poor observation. Scripts > are becoming a much bigger part of the software development scene, and > it's a shame that the script languages in use now are based so heavily > on the hacker mentality. In our project, scripts have gotten very large > and are used for many critical capabilities. Some are thousands of lines > long. We maintain these scripts in our CM database just like the Ada, C, > and FORTRAN code. They have long life -- over 5 years. They must be > documented because they are updated by many hands over a long period of > time. Sound familiar? > > The philosophy of Ada, if not all its details, needs to migrate to > the world of script languages, because scripts ARE software -- the same > rules and pitfalls apply. > ... This is my exact feeling. I wonder why there is so many chat about OS in Ada, and no one is interested in this issue? ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Ray Blaak 2000-02-04 0:00 ` Stanley R. Allen @ 2000-02-04 0:00 ` Robert A Duff 2000-02-05 0:00 ` Ehud Lamm ` (2 more replies) 1 sibling, 3 replies; 80+ messages in thread From: Robert A Duff @ 2000-02-04 0:00 UTC (permalink / raw) Ray Blaak <blaak@infomatch.com> writes: > Scripting languages, on the other hand, tend to be used for small, quickly > written programs, and good ones tend to have a succinct powerful notation. I've seen way too much long-lived software written in Perl, csh, awk, make, etc. Anyway, "quickly written" is irrelevant. The only time it can possibly make sense to use languages that are difficult to maintain is when you're going to quickly throw away the code after writing it. - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Robert A Duff @ 2000-02-05 0:00 ` Ehud Lamm 2000-02-05 0:00 ` blaak 2000-02-10 0:00 ` Pascal Martin 2 siblings, 0 replies; 80+ messages in thread From: Ehud Lamm @ 2000-02-05 0:00 UTC (permalink / raw) On Fri, 4 Feb 2000, Robert A Duff wrote: |Anyway, "quickly written" is irrelevant. The only time it can possibly |make sense to use languages that are difficult to maintain is when |you're going to quickly throw away the code after writing it. | Quite. Actually one of my question for SE students is "what is the impact of glue programs written in non-safe scripting languages, on overal system reliability" (well it is phrased differently, but this is the point of the question). It is always worth repeating that there is nothing as perpetual as the temporary... Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Robert A Duff 2000-02-05 0:00 ` Ehud Lamm @ 2000-02-05 0:00 ` blaak 2000-02-05 0:00 ` Brian Rogoff 2000-02-09 0:00 ` Robert A Duff 2000-02-10 0:00 ` Pascal Martin 2 siblings, 2 replies; 80+ messages in thread From: blaak @ 2000-02-05 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> wrote: > Ray Blaak <blaak@infomatch.com> writes: > > Scripting languages, on the other hand, tend to be used for > > small, quickly written programs, and good ones tend to have a > > succinct powerful notation. > > I've seen way too much long-lived software written in Perl, > csh, awk, make, etc. There is always room for a better language. Is Ada right for a scripting language, though? > Anyway, "quickly written" is irrelevant. The only time it can > possibly make sense to use languages that are difficult to > maintain is when you're going to quickly throw away the code > after writing it. Nobody (at least not me) is advocating the use of scripting languages that are difficult to maintain. The usefulness of a good scripting language is that it is well designed for invoking OS services (expressing the piping of a chain of processes, for example), interactive and easy to debug, and tends to have small programs. E.g. a few K at most for a reasonably complex script -- that's it! No build steps, object files, link times. Just run it. One tends to use scripting languages to implement small little tasks (munge a few files, spit out some email, walk a few websites,...) Scripting languages should encourage programs that are easy to write, easy to understand, and easy to change. Most scripting languages are atrocious (esp. sh and friends). They don't have to be. What I like about scsh is that one has a real programming language (Scheme) focused on tasks such that the limitations of Scheme don't apply (i.e. the lack of a module or package system for programming "in the large"). Now Ada is a fine language, and my language of choice for real software systems. The problem with Ada for scripting purposes, however, is that there is too much declarative infrastructure needed to do simple tasks. Ada's strong static typing requires ones abstractions to be carefully specified. Dynamic typing in a scripting language, on the other hand, allows one to just "whip off" a solution, and yet still have strong type checking for good runtime error detection. Consider this scsh snippet: ;; Mail myself files matching some criteria (with-cwd "~/myfiles" (for-each (lambda (file) (if (run (grep "some pattern" ,file)) (run (mail -s "found it" blaak@home) (< ,file)))) (directory-files))) Boom! That's it. A few lines and the job is done. The equivalent Ada, even assuming a reasonable high-level API to OS services, is more tedious to set up. Perhaps: with AdaScript; use AdaScript; program Main is files : FileList := DirectoryFilesOf("~/myfiles"); begin for i in FirstOf(files) .. LastOf(files) loop if Run (("grep", "some pattern", FileNameAt(files, i))) = Success then Run (Args => ("mail", "-s", "found it", "blaak@home"), Stdin => FileAt(files, i)); end if; end loop; end; Not too bad, but a little noisy. Or perhaps: with AdaScript; use AdaScript; package ThisJob is -- Objects (tagged types) can only be declared in packages. Pain pain! type FileVisitor is new AdaScript.FileVisitor; procedure Visit (withVisitor : in out FileVisitor; theFile : in out File); end ThisJob; package body ThisJob is procedure Visit (withVisitor : in out FileVisitor; theFile : in out File) is begin if Run (("grep", "some pattern", FileNameOf(theFile))) = Success then Run (Args => ("mail", "-s", "found it", "blaak@home"), Stdin => theFile); end if; end; end ThisJob; with AdaScript; use AdaScript; with ThisJob; program Main is visitor : ThisJob.FileVisitor; files : FileList := DirectoryFilesOf("~/myfiles"); begin Traverse(files, withVisitor => visitor); -- dispatches on visitor end; The latter example I include to show the tediousness of setting up a mapping function in Ada. In a real system, tedious declarations are lost in the noise of the actual solution. Also, in a real system, the declarations give much valuable information to the compiler, allowing for good error checking and efficient code generation. In a real system I am a firm believer in tedious declarations. In the kinds of programs one needs scripting languages for, however, these declarations will often tend to dominate, and just make things, well, tedious. In short: Ada is too much of a general purpose language to serve as a scripting language. Use one designed for the purpose. Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` blaak @ 2000-02-05 0:00 ` Brian Rogoff 2000-02-09 0:00 ` Robert A Duff 1 sibling, 0 replies; 80+ messages in thread From: Brian Rogoff @ 2000-02-05 0:00 UTC (permalink / raw) On Sat, 5 Feb 2000 blaak@infomatch.com wrote: > Robert A Duff <bobduff@world.std.com> wrote: > > Ray Blaak <blaak@infomatch.com> writes: > > > Scripting languages, on the other hand, tend to be used for > > > small, quickly written programs, and good ones tend to have a > > > succinct powerful notation. > > > > I've seen way too much long-lived software written in Perl, > > csh, awk, make, etc. Me too. > There is always room for a better language. Is Ada right for a > scripting language, though? IMO, no. That's why I suggested embedding a language in Ada, with that languages implementation being startlingly clear Ada code. > > Anyway, "quickly written" is irrelevant. The only time it can > > possibly make sense to use languages that are difficult to > > maintain is when you're going to quickly throw away the code > > after writing it. I've never observed the phenomena described, IME code is never quickly thrown away. > Nobody (at least not me) is advocating the use of scripting > languages that are difficult to maintain. > > The usefulness of a good scripting language is that it is well > designed for invoking OS services (expressing the piping of a > chain of processes, for example), interactive and easy to debug, > and tends to have small programs. E.g. a few K at most for a > reasonably complex script -- that's it! No build steps, object > files, link times. Just run it. All languages are pushed outside their original design limitations, so a scripting language had better be capable of growing beyond "a few KLOC". > One tends to use scripting languages to implement small little > tasks (munge a few files, spit out some email, walk a few > websites,...) > > Scripting languages should encourage programs that are easy to > write, easy to understand, and easy to change. > > Most scripting languages are atrocious (esp. sh and > friends). They don't have to be. > > What I like about scsh is that one has a real programming > language (Scheme) focused on tasks such that the limitations of > Scheme don't apply (i.e. the lack of a module or package system > for programming "in the large"). Scsh uses Scheme48, which has a fascinating and powerful module system IMO. > Now Ada is a fine language, and my language of choice for real > software systems. The problem with Ada for scripting purposes, > however, is that there is too much declarative infrastructure > needed to do simple tasks. OK so far... > Ada's strong static typing requires ones abstractions to be carefully > specified. Wrong. *Explicit* static typing, *explicit* instantiation, and a heavyweight (some say more readable :-) syntax are what make Ada painful as a scripting language. See ML, Haskell, or the DrScheme environment for counterexamples. > Dynamic typing in a scripting language, on the other hand, allows one > to just "whip off" a solution, and yet still have strong type checking > for good runtime error detection. There are good arguments for dynamic typing, but this isn't one of them. > Consider this scsh snippet: > > ;; Mail myself files matching some criteria > (with-cwd "~/myfiles" > (for-each (lambda (file) > (if (run (grep "some pattern" ,file)) > (run (mail -s "found it" blaak@home) (< ,file)))) > (directory-files))) ML or Haskell would require a few more lines to make the types right, like checking that the result of your grep isn' a null string. -- Brian ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` blaak 2000-02-05 0:00 ` Brian Rogoff @ 2000-02-09 0:00 ` Robert A Duff 2000-02-09 0:00 ` Ted Dennison 1 sibling, 1 reply; 80+ messages in thread From: Robert A Duff @ 2000-02-09 0:00 UTC (permalink / raw) blaak@infomatch.com writes: > There is always room for a better language. Is Ada right for a > scripting language, though? No. > > Anyway, "quickly written" is irrelevant. The only time it can > > possibly make sense to use languages that are difficult to > > maintain is when you're going to quickly throw away the code > > after writing it. > > Nobody (at least not me) is advocating the use of scripting > languages that are difficult to maintain. Maybe *you're* not, but lots of people do so advocate. ;-) > Scripting languages should encourage programs that are easy to > write, easy to understand, and easy to change. Maybe we're not using "script" in the same way. For example, I consider the make files and whatnot that are used to build a program and run its regression tests, to be scripts. But these are long-lived pieces of software, and therefore need to be maintainable. So "easy to write" is mostly irrelevant. "easy to understand, and easy to change" are key. - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-09 0:00 ` Robert A Duff @ 2000-02-09 0:00 ` Ted Dennison 2000-02-10 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 80+ messages in thread From: Ted Dennison @ 2000-02-09 0:00 UTC (permalink / raw) In article <wcc3dr2mq9z.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > blaak@infomatch.com writes: > > For example, I consider the make files and whatnot that are used to > build a program and run its regression tests, to be scripts. But these > are long-lived pieces of software, and therefore need to be > maintainable. So "easy to write" is mostly irrelevant. > "easy to understand, and easy to change" are key. I realized while taking an AI class a while back that make is basicly a special-purpose AI inference engine. In effect, makefiles constitue the rules and knowledge base in an expert system that knows how to build a program. AI folks will readily admit productivity as measured in SLOC/hour is *way* lower for expert system development than it is in normal imperitive languages. I'm not sure what can be done about this, though. If you were to try to write something in Ada that was even half as flexible, you'd basicly end up writing your own custom expert system. In that case you'd be subject to the same productivity hit, with the inference engine development time tacked onto the front to boot. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-09 0:00 ` Ted Dennison @ 2000-02-10 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 80+ messages in thread From: Samuel T. Harris @ 2000-02-10 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <wcc3dr2mq9z.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > blaak@infomatch.com writes: > > > > For example, I consider the make files and whatnot that are used to > > build a program and run its regression tests, to be scripts. But > these > > are long-lived pieces of software, and therefore need to be > > maintainable. So "easy to write" is mostly irrelevant. > > "easy to understand, and easy to change" are key. > > I realized while taking an AI class a while back that make is basicly a > special-purpose AI inference engine. In effect, makefiles constitue the > rules and knowledge base in an expert system that knows how to build a > program. Good point. > > AI folks will readily admit productivity as measured in SLOC/hour is > *way* lower for expert system development than it is in normal > imperitive languages. Having done expert systems in the past, I attribute the productivity hit not to the domain of inference rules, but to the sometimes aggrevating process of "knowledge engineering" which involves getting the domain expert(s) to tell you why they know something when they usually just know! > > I'm not sure what can be done about this, though. If you were to try to > write something in Ada that was even half as flexible, you'd basicly end > up writing your own custom expert system. In that case you'd be subject > to the same productivity hit, with the inference engine development time > tacked onto the front to boot. > -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-04 0:00 ` Robert A Duff 2000-02-05 0:00 ` Ehud Lamm 2000-02-05 0:00 ` blaak @ 2000-02-10 0:00 ` Pascal Martin 2000-02-10 0:00 ` Ray Blaak 2 siblings, 1 reply; 80+ messages in thread From: Pascal Martin @ 2000-02-10 0:00 UTC (permalink / raw) In article <wccwvoe3tzw.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >> As Robert A Duff said : >> "Scripting languages should encourage programs that are easy to >> write, easy to understand, and easy to change." > > I don't think *I* said that. In fact, my opinion is that "easy to > write" not important; the other two goals I agree with. It seems to me that everytime I chose to use a scripting rather than a compiled language, it was for a subset of the following reasons: 1- Execution speed is less important than development comfort. 2- Very flexible string manipulation is highly important, which means support for transparent string resizing, concatenation and data- driven split (for example, split a string into a list of words). 3- Easy to use regular expression engine. The drawback is that it seems there is no such engine that is also easy to debug with, including expect. 4- System operations must be easy: execute a program, retrieve its output, control its input. 5- Symbolic indexing (aka strings indexes, or hash tables). 6- Dynamic table resizing. 7- Very portable. Which means that the components of the environment must be available on all platforms. Not so easy when considering item 4, or when using commercial packages. 8- Include a GUI toolkit. We are in 2000: echo "Please enter..."/read don't cut it anymore. But the GUI must be optional. All these features must be 100% interoperable, of course. Which mandates using the same basic dynamic string package all over. Garbage collection is basically mandatory. I am sure there are ways to implement a dynamic string package in Ada, it just appears that putting togethers many packages from separate sources is always complicated, because it is frequent that these packages do not define compatible types. Using generic packages is somewhat incompatible with development comfort, because you have to do the package integration work all by yourself. So, all the environment support should come as one single set. Among the scripting languages/interpreters I have used: the ugliest: command.com the slowest: sh the most confusing: perl the most difficult to debug: Tcl (still using it, through, because of Tk :-) the most obscure: VAX/VMS DCL (all these optional parameters.. ) the worst limitations: Microsoft Basic on TRS80 (I liked it at the time) ------------------------------------------------------------------ Pascal F. Martin. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-10 0:00 ` Pascal Martin @ 2000-02-10 0:00 ` Ray Blaak 2000-02-11 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei T. Jensen ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Ray Blaak @ 2000-02-10 0:00 UTC (permalink / raw) Pascal Martin <pascal.martin@iname.com.nospam> writes: >Robert A Duff <bobduff@world.std.com> wrote: > >> As Robert A Duff said : > >> "Scripting languages should encourage programs that are easy to > >> write, easy to understand, and easy to change." > > > > I don't think *I* said that. In fact, my opinion is that "easy to > > write" not important; the other two goals I agree with. Actually, I wrote that. I agree that maintenance is the most important consideration, but I want it all. By easy to write, I do not mean the using a terse symbology of C-like or APL operators. By mean the ability to naturally express powerful high-level abstractions with a minimum of effort. That is, the language style encourages such things. Lispy, functional languages usually do well for me here. By writing things at a higher level, I believe that code is actually clearer and easier to maintain. > It seems to me that everytime I chose to use a scripting rather than > a compiled language, it was for a subset of the following reasons: > > 1- [...] development comfort. 2- Very flexible string manipulation [...] > 3- Easy to use regular expression engine. 4- System operations must be easy > 5- Symbolic indexing [...] 6- Dynamic table resizing. 7- Very portable [...] > 8- Include a GUI toolkit. [...] Plus: Garbage collection is basically > mandatory Very important considerations for me too. I would add flexible data structure manipulation in general, with strings being one of the most important. Perl is my favourite for regular expressions, although there are drawbacks for clarity and maintenance. > Among the scripting languages/interpreters I have used: > > the ugliest: command.com > the slowest: sh I believe these are the worst simply because it is so difficult to express any reasonable programming task. > the most confusing: perl > the most difficult to debug: Tcl (still using it, through, because of Tk :-) > the most obscure: VAX/VMS DCL (all these optional parameters.. ) > the worst limitations: Microsoft Basic on TRS80 (I liked it at the time) I use Visual Basic for testing scripts. While it is actually fairly readable, and one can do Windows COM stuff fairly easily, I despise it, due to major stupidities in the language (a = b vs Set a = b, line continuations -- for comments too! one can do "Set a = Nothing" and then "Doit a" but not "Doit Nothing", etc.). I actually like Perl a fair bit, since at least one can take the trouble to write clear code and it is powerful. My current favourite is scsh due to its coolness. Do ML or Haskell shells exist? It would be interesting to see how implicit static strong typing makes things more correct while style allowing for easy writing of command scripts. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-10 0:00 ` Ray Blaak @ 2000-02-11 0:00 ` Tarjei T. Jensen 2000-02-11 0:00 ` Robert I. Eachus 2000-02-11 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) David Starner 2000-02-14 0:00 ` Robert A Duff 2 siblings, 1 reply; 80+ messages in thread From: Tarjei T. Jensen @ 2000-02-11 0:00 UTC (permalink / raw) Ray Blaak wrote: >I actually like Perl a fair bit, since at least one can take the trouble to >write clear code and it is powerful. According to the December issue of Linux Journal the use of Python is increasing rapidly. Supposedly because of a reduced ETS (Effort To Solution) compared to Perl. I think it would be possible to write a command interpreter in Ada which could do useful stuff. Ideally it should work like Rexx (which really needs to be cleaned up) when embedded. I like the way Rexx can be used to enhance OS/2, but think parts of the syntax and semantics stinks. If the Ada community can create a command interpreter which can be extended at the user level without having to re-link or recompile then we have a winner. Especially if it can be used embedded into applications. It will simply be too conventient and powerful to ignore. Greetings, ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-11 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei T. Jensen @ 2000-02-11 0:00 ` Robert I. Eachus 2000-02-12 0:00 ` Pascal Martin ` (3 more replies) 0 siblings, 4 replies; 80+ messages in thread From: Robert I. Eachus @ 2000-02-11 0:00 UTC (permalink / raw) "Tarjei T. Jensen" wrote: > If the Ada community can create a command interpreter which can be extended at > the user level without having to re-link or recompile then we have a winner. > Especially if it can be used embedded into applications. It will simply be too > conventient and powerful to ignore. This sounds like a not too difficult project, in fact the most difficult part will probably be reaching a consensus on the requirements. Since I am a most intrepid sort of person, here is a first cut: Concept: Build a special version of gnat for scripting purposes. The syntax will be pure Ada, while there will be some modifications to the semantics to account for the special purpose. In particular, more implicit conversions will be allowed, and dynamic bindings to environment variables and executable programs. Requirements: 1) The tool shall target both Unix and Windows (95,98,2000,NT 4.0). 2) Procedure, function, (and entry?) calls which do not match a subprogram or entry declared in the script will be searched for using a search path. (Questions: Use the externally defined path, or a local path then the external path? Is there a way to call insure that a call is external?) 3) Conversions between Strings, Bounded_Strings, and Unbounded_Strings shall be implicit. (Should there be a "standard" instantiation of Bounded_Strings, or should it be possible to declare a variable as: Foo: Bounded_String(1024); or something similar?) 4) Environment variables shall be treated as String (Unbounded_String?) variables in an outer scope, and shall be hidden by identically named variables in inner scopes. (In other words, it must be possible to pass a modified set of environment variables to nested calls.) 5) It shall be possible to explicitly designate executable programs or scripts in the environment. (In other words it must be possible to bypass the search path to get to, say, /bin/sh, pragma External_Name is probably the best way to do this.) 6) Arguments passed to the script/program on the command line shall be accessable. (Special version of Ada.Command_Line if necessary.) Anything else? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-11 0:00 ` Robert I. Eachus @ 2000-02-12 0:00 ` Pascal Martin 2000-02-13 0:00 ` Robert I. Eachus 2000-02-12 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei Tj�stheim Jensen ` (2 subsequent siblings) 3 siblings, 1 reply; 80+ messages in thread From: Pascal Martin @ 2000-02-12 0:00 UTC (permalink / raw) In article <38A47E5A.42406034@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > Anything else? Simple to use list management. This is critical to scripts, where you often end processing list of files or other ressources. ------------------------------------------------------------------ Pascal F. Martin. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-12 0:00 ` Pascal Martin @ 2000-02-13 0:00 ` Robert I. Eachus 2000-02-16 0:00 ` scripting/extension ... [off topic] Nick Roberts 0 siblings, 1 reply; 80+ messages in thread From: Robert I. Eachus @ 2000-02-13 0:00 UTC (permalink / raw) Pascal Martin wrote: > Simple to use list management. This is critical to scripts, where you often end > processing list of files or other ressources. Yep, simplifying iteration over lists of files, names, and other objects would be necessary. But I think we need to "special case" the first two in the same way that Unbounded_Strings are specialized. I was assuming that specialized ADTs would be available for these. For example you would want a function which takes a path and a regular expression as arguments, and returns a list of files rooted at that path which match the regular expression... But what is really needed is an apply operation. And this is one of those things where you are tempted to work around it, until you realize how easy it is to write an apply in Ada 95. Try it! You will never use another iterator in Ada again... ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension ... [off topic] 2000-02-13 0:00 ` Robert I. Eachus @ 2000-02-16 0:00 ` Nick Roberts 2000-02-16 0:00 ` Ray Blaak 0 siblings, 1 reply; 80+ messages in thread From: Nick Roberts @ 2000-02-16 0:00 UTC (permalink / raw) I sent this (warning: highly discursive) post to Pascal as an e-mail by accident (instead of to the group), which very likely bewildered him entirely. I've got no reply from him, anyway! The kind of 'Ada interpreter' suggested has existed for a long time, albeit in a form that (to my knowledge) was never really finished off. It was called 'ACE' (the Ada Command Executive), and was was one of the (numerous) developments under the STARS programme. I have a copy of the source code and docs (somewhere on my hard disk, I think!), if anyone's interested. I think it was a nice idea, but surely the amount of typing you have to do to do something 'simple' would come a screaming culture shock to anyone used to the 'sh' family. I have invented, pretty well in my head, an Application eXtension System: AXS (pron. 'axis'). It's not a language. The idea is that every element that would make up a traditional script program (large or small) is replaced, in essence, by a dialog box, that garners the necessary information for the element, and which simply invokes further dialogs for component elements. For example, a sequence of actions would be entered in a dialog box that displayed the actions in a 'list box'; there would be a button to add a new action, one to insert an action, one to delete an action, and one to edit an action. Actions could be rearranged by drag-and-drop (or by two arrow buttons). Editing an action would pop up a dialog for that purpose; of course, one of the options would be another (nested) sequence. I shan't get deeply into the details, but I think I've dealt with the various problems associated with doing this sort of thing. AXS seems to be a great way of programming GUIs a la RAD. The main advantages of AXS could be set out as below. 1. No language has to remembered by the 'programmer'. Syntax errors are not generally possible. Selecting actions is generally a matter of 'point and click'. 2. Each dialog box ensures that all the necessary parameters are filled in, and can be validated (to some extent) at entry time. Entry of values can generally be made very easy (e.g. a calendar for dates). Variables can be selected by 'point and click'. 3. No distinction is made between actions and data values. This has the double advantage of making activity easily data-directed, and of making it particularly easy to program the automated manipulation (and construction) of procedures. 4. Certain data that would be difficult or impossible to encode in textual script language can be straightforwardly dealt with by AXS (until it comes to manifesting it in XML, of course). For example, in AXS, an icon could be entered by simply popping up an 'icon editor' dialog box, without the programmer having to deal with files or filenames in any way. The downside (there always is one :-) is that programming the sub-AXS modules is relatively elaborate. I don't think this is too much of a problem, so long as most modules have a reasonable expectation of a high level of re-use. Undoubtedly there will be some constructs that will actually be more easily entered and edited as text than by dialogs, e.g. complicated mathematical expressions. However, a textual alternative could always be offered by a dialog (further complicating the implementation, of course). An AXS procedure could be manifested in XML, if necessary. E.g. (I've used square instead of angle brackets here, so as not to confuse certain viewing software): [procedure] [identifier]activate_ppp[/identifier] [name]Activate a PPP session on a modem[/name] [desc]This procedure causes a modem to dial up an external ...[/desc] [help]/usr/axs/doc/ppp/activate_ppp.html[/help] [option] [identifier]debug[/identifier] [actuals][input][identifier]level[/identifier][value]3[/value][/input][/actu als] [/option] [parameters] [input] [type]string[/type] [identifier]phone_number[/identifier] [name]Telephone number to dial[/name] [desc]This is the telephone number the modem is to dial to get ...[/desc] [/input] ... [/parameters] [action] [sequence] [call] [identifier]reset_modem[/identifier] [name]Reset a modem to a known state[/name] [actuals] Okay, I've stopped there, but you get the flavour. I think I'm touching on something that Dr Robert Leif has being saying recently (about XML having great importance for the future of programming languages). There are some well-argued advantages to using XML for this sort of purpose (one of the most obvious being the flexibility in formatting and presenting printouts, but it goes much deeper than that). However, touching on the mention of Scheme in this thread (am I imagining that?), it seems to me that languages such as LISP and Prolog could be very readily used in place of 'traditional' script languages. Prolog could offer particularly powerful facilities when it comes to pattern-matching. If external procedures were to be provided such as env:obj(Obj) to instantiate with every object in the 'current object' (i.e. every file in the current directory), env:attr(Name,Attr) to instantiate with object attributes (e.g. "name", "mime-type", "mdate", etc.), and env:value(Obj,Attr,Val) to instantiate with the value of an attribute for an object, some pretty sophisticated searches could be programmed very concisely: mail_me_my_files(CO) :- my_email(Me), my_initials(Init), Search = "Author: "//Init, env:within(CO, ( env:attr("name",NameAttr), env:obj(Obj), env:value(Obj,NameAttr,Name), env:run("search",[Search,Name],0), Subj = "Found my file: "//Name, env:run("sendmail",["-s",Subj,Me,Name],0) ) ). A really good debugging environment would be important. Fifth generation languages like these could very aptly be used for implementing AXS. The potential exists for some rather 'intelligent' things to be done with software that isn't frozen in brick. It's strange, but I'm beginning to get a more concrete sensation that the days of 'programming', as such, are not so far from being over as many of us would prefer to think. It's an old idea (dating back to the sixties); computers are nearly getting to the point where they are actually powerful enough (while remaining affordable) to realise the dream. Maybe the little chip in The Terminator's* head isn't all that far away after all :-o -- Nick Roberts http://www.adapower.com/lab/adaos *TM Carolco, 1984+ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension ... [off topic] 2000-02-16 0:00 ` scripting/extension ... [off topic] Nick Roberts @ 2000-02-16 0:00 ` Ray Blaak 0 siblings, 0 replies; 80+ messages in thread From: Ray Blaak @ 2000-02-16 0:00 UTC (permalink / raw) "Nick Roberts" <nickroberts@callnetuk.com> writes: > I have invented, pretty well in my head, an Application eXtension System: > AXS (pron. 'axis'). > > It's not a language. The idea is that every element that would make up a > traditional script program (large or small) is replaced, in essence, by a > dialog box, that garners the necessary information for the element, and > which simply invokes further dialogs for component elements. Go for it. I know I dislike such systems since I am a code person, but enough people might find it useful. > I think I'm touching on something that Dr Robert Leif has being saying > recently (about XML having great importance for the future of programming > languages). There are some well-argued advantages to using XML for this sort > of purpose (one of the most obvious being the flexibility in formatting and > presenting printouts, but it goes much deeper than that). XML is great for portable communication and persistence formats. I would hate to be forced to use it to express a program, however. Its just too much work, with too many tools between me and the real code. The main advantage I see to using XML for describing a language (given that any language would already have a standard syntax) is that one can instrument the code with additional information (formatting hints, proof results, documentation, associated test cases, change histories, etc.) in a clean way that is amenable to processing by other tools. > However, touching on the mention of Scheme in this thread (am I imagining > that?), it seems to me that languages such as LISP and Prolog could be very > readily used in place of 'traditional' script languages. I was mentioning scsh, the Scheme Shell, which is based on Scheme48. Scheme has nice built-in extensibility mechanisms that lend themselves well to to these kind of problems. > It's strange, but I'm beginning to get a more concrete sensation that the > days of 'programming', as such, are not so far from being over as many of us > would prefer to think. It's an old idea (dating back to the sixties); > computers are nearly getting to the point where they are actually powerful > enough (while remaining affordable) to realise the dream. Computers are getting more powerful, but we will still program, but just at higher and higher levels. When (not if) things break, we will need to be able analyze and adjust software at arbitrarily low levels. I know I am continually disappointed by new CS grads who know how to use the latest component tools, but have little understanding of underlying mechanisms. > Maybe the little chip in The Terminator's* head isn't all that far away > after all :-o At the risk of starting a whole new thread, not a chance :-). We (as in humans) haven't really got a clue how to do real AI at all. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-11 0:00 ` Robert I. Eachus 2000-02-12 0:00 ` Pascal Martin @ 2000-02-12 0:00 ` Tarjei Tj�stheim Jensen 2000-02-12 0:00 ` Samuel T. Harris 2000-02-12 0:00 ` root 2000-02-12 0:00 ` Samuel T. Harris 2000-02-12 0:00 ` blaak 3 siblings, 2 replies; 80+ messages in thread From: Tarjei Tj�stheim Jensen @ 2000-02-12 0:00 UTC (permalink / raw) Robert I. Eachus wrote: > "Tarjei T. Jensen" wrote: > > > If the Ada community can create a command interpreter which can be extended at > > the user level without having to re-link or recompile then we have a winner. > > Especially if it can be used embedded into applications. It will simply be too > > conventient and powerful to ignore. > > This sounds like a not too difficult project, in fact the most > difficult part will probably be reaching a consensus on the > requirements. Since I am a most intrepid sort of person, here is a > first cut: > > Concept: Build a special version of gnat for scripting purposes. > The syntax will be pure Ada, while there will be some modifications to > the semantics to account for the special purpose. In particular, more > implicit conversions will be allowed, and dynamic bindings to > environment variables and executable programs. > You have started in the wrong direction. Such an interpreter should have an Ada-ish look and feel, but it should not be Ada. E.g. I strongly believe that it should use "[" and "]" for arrays. There should be reasonable defaults. The attribute system as found in ada should be simplified. It should be possible to write a := a'succ; or something similar and short. s1 : string; -- unbounded string s2 : string[5]; -- string of maximum length 5, but dynamically sizeable I think one should aim for to make it an integration tool. In windows it should use dcom, in Unix something else (or create something). If we get a way of letting scripts have dde/dcom/ole functionality I don't think we could be stopped in a Unix environment. Especially if it was inherently multithreaded. If it can be used to extend the desktop we have it made. The theory is that in such an environment people would want to use ada for the following reasons 1 in order to create extension modules 2 understand what it does 3 use its complementary library to get access to its services. It would be nice if it were possible to compile a script into Ada. > Requirements: > > 1) The tool shall target both Unix and Windows (95,98,2000,NT > 4.0). I think the primary target should be Unix with a bias towards making it windows compatible. > 2) Procedure, function, (and entry?) calls which do not match a > subprogram or entry declared in the script will be searched for using a > search path. > > (Questions: Use the externally defined path, or a local path then > the external path? Is there a way to call insure that a call is > external?) It should be possible to specify how to treat certain names and how to search. E.g. it should be possible to specify that if a command has a given name, then a given command should be executed as in alias in a bash/korn shell. It should be possible to specify that if a program cannot be found in a search path, then one should search for e.g. program.ksh, program.sh, program.pl, program.py, etc. in the path. > 3) Conversions between Strings, Bounded_Strings, and > Unbounded_Strings shall be implicit. > (Should there be a "standard" instantiation of Bounded_Strings, or > should it be possible to declare a variable as: Foo: > Bounded_String(1024); or something similar?) See above. > 4) Environment variables shall be treated as String > (Unbounded_String?) variables in an outer scope, and shall be hidden by > identically named variables in inner scopes. (In other words, it must > be possible to pass a modified set of environment variables to nested > calls.) It would be nice to be able to have drives like we have in VMS. E.g. define ada_config as /etc/ada and refer to files there with ada_config:global_setup.conf. I think it is better than ${ada_config}/global_setup.conf. These drives should be available as global environment variables. It would be very nice if these variables were available through a different mechanism than environment variables, so that changes affect all instantly. In VMS these variables are on several levels. They form a hierachy. Which level is the inquiry about a variable can be specified. One would have to decide whether these should be persistent or whether they should die when the system go down. If they are persistent, then we have a registry. Perhaps such a thing should be in a database to get access control and sql. > 5) It shall be possible to explicitly designate executable > programs or scripts in the environment. (In other words it must be > possible to bypass the search path to get to, say, /bin/sh, pragma > External_Name is probably the best way to do this.) > > 6) Arguments passed to the script/program on the command line > shall be accessable. (Special version of Ada.Command_Line if > necessary.) It should be possible to script enable programs. It should not be neccessary to link in the interpreter. Script enabled programs should not need to have file names expanded on the command line. They should be able to obtain these as needed by feeding the file specification to a file name generator service. The interpreter should be internationalized from the beginning. BTW Anybody contemplating on writing an command interpreter should 1. get a few books on script programs and make a list of the best features. E.g. books on the Korn shell or Bash, awk, rexx, perl, tcl and python (zope). 2. Decide on syntax. 3. Write scripts and see whether it works and looks right 4. repeat 1 .. 3 as neccessary Then you can design and code the interpreter. Greetings, ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-12 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei Tj�stheim Jensen @ 2000-02-12 0:00 ` Samuel T. Harris 2000-02-14 0:00 ` Robert A Duff 2000-02-12 0:00 ` root 1 sibling, 1 reply; 80+ messages in thread From: Samuel T. Harris @ 2000-02-12 0:00 UTC (permalink / raw) "Tarjei Tjøstheim Jensen" wrote: > > Robert I. Eachus wrote: > > > > > Concept: Build a special version of gnat for scripting purposes. > > The syntax will be pure Ada, while there will be some modifications to > > the semantics to account for the special purpose. In particular, more > > implicit conversions will be allowed, and dynamic bindings to > > environment variables and executable programs. > > > > You have started in the wrong direction. Such an interpreter should have an Ada-ish > look and feel, but it should not be Ada. E.g. I strongly believe that it should use > "[" and "]" for arrays. There should be reasonable defaults. > > The attribute system as found in ada should be simplified. It should be possible to > write a := a'succ; or something similar and short. > > s1 : string; -- unbounded string > s2 : string[5]; -- string of maximum length 5, but dynamically sizeable I have no problem with using [] instead of () for array indexing. The [] can be easily converted back to () for use in a conventional compiler. Along this line, {} can be used for aggregates. Parsing Ada is notoriously difficult because of the overloading of () for indexes, subprograms, and aggregates. <snip> > > > 2) Procedure, function, (and entry?) calls which do not match a > > subprogram or entry declared in the script will be searched for using a > > search path. > > > > (Questions: Use the externally defined path, or a local path then > > the external path? Is there a way to call insure that a call is > > external?) > > It should be possible to specify how to treat certain names and how to search. E.g. > it should be possible to specify that if a command has a given name, then a given > command should be executed as in alias in a bash/korn shell. It should be possible > to specify that if a program cannot be found in a search path, then one should > search for e.g. program.ksh, program.sh, program.pl, program.py, etc. in the path. See my previous post on package PATH. External command locations can be specified with pragma interface_name. External commands already know how to execute themselves whether they are bash/korn shell, sed scripts, whatever. <snip> -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-12 0:00 ` Samuel T. Harris @ 2000-02-14 0:00 ` Robert A Duff 2000-02-15 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 80+ messages in thread From: Robert A Duff @ 2000-02-14 0:00 UTC (permalink / raw) "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > I have no problem with using [] instead of () for array indexing. > The [] can be easily converted back to () for use in a conventional > compiler. > Along this line, {} can be used for aggregates. > Parsing Ada is notoriously difficult because of the overloading > of () for indexes, subprograms, and aggregates. But if you don't do the "notoriously difficult" stuff, then you can't automatically translate "[" into "(" (etc) and expect it to always work. - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-14 0:00 ` Robert A Duff @ 2000-02-15 0:00 ` Samuel T. Harris 2000-02-16 0:00 ` Robert A Duff 0 siblings, 1 reply; 80+ messages in thread From: Samuel T. Harris @ 2000-02-15 0:00 UTC (permalink / raw) Robert A Duff wrote: > > "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > > > I have no problem with using [] instead of () for array indexing. > > The [] can be easily converted back to () for use in a conventional > > compiler. > > Along this line, {} can be used for aggregates. > > Parsing Ada is notoriously difficult because of the overloading > > of () for indexes, subprograms, and aggregates. > > But if you don't do the "notoriously difficult" stuff, then you can't > automatically translate "[" into "(" (etc) and expect it to always work. > > - Bob Certainly I can. Since [] and {} are not legal Ada tokens, they many only appear in comments and string literals. A syntax to handle these so that other [] and {} are converted to () is trivial to do. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-15 0:00 ` Samuel T. Harris @ 2000-02-16 0:00 ` Robert A Duff 2000-02-16 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 80+ messages in thread From: Robert A Duff @ 2000-02-16 0:00 UTC (permalink / raw) "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > Certainly I can. Since [] and {} are not legal Ada tokens, > they many only appear in comments and string literals. > A syntax to handle these so that other [] and {} > are converted to () is trivial to do. No, I don't think it's trivial to do it right. Consider: procedure Main is function F return String is begin return "A"; end F; procedure Nested is function F(X: Integer) return Character is begin return 'B'; end F; begin Text_IO.Put(F[1]); -- Not Ada. end Nested; begin Nested; end Main; Presumably the F[1] above resolves to the outer F, which returns an array, so the program prints "A". If you "trivially" transform "[...]" into "(...)" you will get an illegal (ambiguous) Ada program. - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-16 0:00 ` Robert A Duff @ 2000-02-16 0:00 ` Samuel T. Harris 2000-02-16 0:00 ` Robert A Duff 0 siblings, 1 reply; 80+ messages in thread From: Samuel T. Harris @ 2000-02-16 0:00 UTC (permalink / raw) Robert A Duff wrote: > > "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > > > Certainly I can. Since [] and {} are not legal Ada tokens, > > they many only appear in comments and string literals. > > A syntax to handle these so that other [] and {} > > are converted to () is trivial to do. > > No, I don't think it's trivial to do it right. > > Consider: > > procedure Main is > function F return String is > begin > return "A"; > end F; > > procedure Nested is > function F(X: Integer) return Character is > begin > return 'B'; > end F; > begin > Text_IO.Put(F[1]); -- Not Ada. > end Nested; > begin > Nested; > end Main; > > Presumably the F[1] above resolves to the outer F, which returns an > array, so the program prints "A". If you "trivially" transform "[...]" > into "(...)" you will get an illegal (ambiguous) Ada program. > > - Bob In supporting [] for arrays and {} for aggregates, I did not mean to imply changing any Ada semantics. They simply make the recognizer grammar much simpler since () isn't used for so many things. Indeed, I have said previously that I want as much Ada semantics as is reasonbly feasible. If F(1) is ambiguous in Ada, then so should F[1] be ambiguous in the scripting language. Using [] for arrays is a syntactic short-cut enabling a much simpler grammar. Semantics don't have to be similarly "simplistic". Indeed, I'd expect the script interpreter to say something more than just that I have an ambiguous reference. I'd expect to say something like I have an ambiguous reference between an intended array subscript and an homogenenous function call. I failed to mention before that I feel the substitution of [] and {} would be akin to using % instead of ", : instead of #, and ! instead of | except that instead of being optional, [] and {} are mandatory. In this way, the syntax of array index does not have to be boggled with named notation since the explicit delimiters [] do not allow named notation. So I don't need syntax non-terminals such as function_call_or_array_index_or_qualified_aggregate with all the complexity involved. The semantics still have to verify the appropriate nature of the element. Given this, I believe you would agree that the substitution of () for [] and {} would now be trivial. Problem cases such as the one you cite above should not allowed by the semantics of the Ada interpreter. Otherwise, I see no benefit to using these special substitutions except to satisfy the expectations of prior experience with other languages. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-16 0:00 ` Samuel T. Harris @ 2000-02-16 0:00 ` Robert A Duff 2000-02-17 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 80+ messages in thread From: Robert A Duff @ 2000-02-16 0:00 UTC (permalink / raw) "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: >... So I don't need syntax non-terminals > such as function_call_or_array_index_or_qualified_aggregate > with all the complexity involved. The semantics > still have to verify the appropriate nature of > the element. > > Given this, I believe you would agree that the substitution > of () for [] and {} would now be trivial. Yes. But the simplification of the grammar is fairly minor, when compared with the complexity of overload resolution. There may be good and bad things about "[", but I wouldn't say "[" greatly simplifies the compiler/interpreter, as you've defined it. By the way, aggregates (qualified or not) can be syntactically distinguished from function calls and whatnot. The aggregate issue is the potential confusion between a parenthesized expression and a one-element positional aggregate. (I consider it a design flaw in Ada that there are no one-element and zero-element positional aggregates. But with you're "trivial substitution" model, you can't solve that problem.) - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-16 0:00 ` Robert A Duff @ 2000-02-17 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 80+ messages in thread From: Samuel T. Harris @ 2000-02-17 0:00 UTC (permalink / raw) Robert A Duff wrote: > > "Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes: > > >... So I don't need syntax non-terminals > > such as function_call_or_array_index_or_qualified_aggregate > > with all the complexity involved. The semantics > > still have to verify the appropriate nature of > > the element. > > > > Given this, I believe you would agree that the substitution > > of () for [] and {} would now be trivial. > > Yes. > > But the simplification of the grammar is fairly minor, when compared > with the complexity of overload resolution. I feel the simplification of the grammar is much more than minor. I get much closer to being able to apply the Ada syntax directly to aflex/ayacc with these special substitutions. I suppose we place a different priority on the ease of syntax translation. However, I do agree with you on the semantics. They are just as hard with or without special delimiters. > > There may be good and bad things about "[", but I wouldn't say "[" > greatly simplifies the compiler/interpreter, as you've defined it. > > By the way, aggregates (qualified or not) can be syntactically > distinguished from function calls and whatnot. The aggregate issue is > the potential confusion between a parenthesized expression and a > one-element positional aggregate. (I consider it a design flaw in Ada > that there are no one-element and zero-element positional aggregates. > But with you're "trivial substitution" model, you can't solve that > problem.) Yes, that is a stickler with me as well. All in all, when my short list of Ada peeves contains these kinds of things, I thinks that speaks very highly of the quality of the language. > > - Bob -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-12 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei Tj�stheim Jensen 2000-02-12 0:00 ` Samuel T. Harris @ 2000-02-12 0:00 ` root 1 sibling, 0 replies; 80+ messages in thread From: root @ 2000-02-12 0:00 UTC (permalink / raw) "Tarjei Tj�stheim Jensen" wrote: > ... > > You have started in the wrong direction. Such an interpreter should have an Ada-ish > look and feel, but it should not be Ada. E.g. I strongly believe that it should use > "[" and "]" for arrays. There should be reasonable defaults. > ... Someone said on this news group that this was envisioned for Ada 83, and at last abandoned because those character where not always available on keyboard at this time. This is obviously no more true. I believe this syntax should be used, because: 1 - i think sources will be more readable, 2 - sources could be easily pre-processed to be compiled by a regular compiler. Lionel. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-11 0:00 ` Robert I. Eachus 2000-02-12 0:00 ` Pascal Martin 2000-02-12 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei Tj�stheim Jensen @ 2000-02-12 0:00 ` Samuel T. Harris 2000-02-12 0:00 ` blaak 3 siblings, 0 replies; 80+ messages in thread From: Samuel T. Harris @ 2000-02-12 0:00 UTC (permalink / raw) "Robert I. Eachus" wrote: > > "Tarjei T. Jensen" wrote: > > > If the Ada community can create a command interpreter which can be extended at > > the user level without having to re-link or recompile then we have a winner. > > Especially if it can be used embedded into applications. It will simply be too > > conventient and powerful to ignore. > > This sounds like a not too difficult project, in fact the most > difficult part will probably be reaching a consensus on the > requirements. Since I am a most intrepid sort of person, here is a > first cut: > > Concept: Build a special version of gnat for scripting purposes. > The syntax will be pure Ada, while there will be some modifications to > the semantics to account for the special purpose. In particular, more > implicit conversions will be allowed, and dynamic bindings to > environment variables and executable programs. > > Requirements: > > 1) The tool shall target both Unix and Windows (95,98,2000,NT > 4.0). > > 2) Procedure, function, (and entry?) calls which do not match a > subprogram or entry declared in the script will be searched for using a > search path. > > (Questions: Use the externally defined path, or a local path then > the external path? Is there a way to call insure that a call is > external?) The shell engine can process the path and produce a PATH package containing subprogram specs for everything visible. A special classification for the required pragma interface can be used. The engine can be configured to "know" the argument profile of certain commands. Others can take a single string argument. > > 3) Conversions between Strings, Bounded_Strings, and > Unbounded_Strings shall be implicit. > (Should there be a "standard" instantiation of Bounded_Strings, or > should it be possible to declare a variable as: Foo: > Bounded_String(1024); or something similar?) I'd rather see a package with a rich set of predefined "+" operations for all th necessary conversions. > > 4) Environment variables shall be treated as String > (Unbounded_String?) variables in an outer scope, and shall be hidden by > identically named variables in inner scopes. (In other words, it must > be possible to pass a modified set of environment variables to nested > calls.) Again, the shell engine can produce a package ENV containing access to string variables representing the environment. Access to the environment must also be supported by subprograms because the environment is a dynamic association of ordered pairs of strings and cannot be entirely captures as a list of string variables. > > 5) It shall be possible to explicitly designate executable > programs or scripts in the environment. (In other words it must be > possible to bypass the search path to get to, say, /bin/sh, pragma > External_Name is probably the best way to do this.) Exactly. This fits with the predefined package PATH. A pragma interface classification will also be needed to specify the subprogram is an external executable. I'm not sure EXTERNAL really conveys the meaning here so other suggestions are solicited. > > 6) Arguments passed to the script/program on the command line > shall be accessable. (Special version of Ada.Command_Line if > necessary.) Why should the script program be a parameterless procedure. It can have parameters. Boolean parameters can be assumed to be switches. Other parameters can be command-line arguments. Named Ada notation fits nicely with UNIX switches which require arguments. The shell engine can parse the switches and arguments on the UNIX command line and fit them into the script programs parameter list. > > Anything else? -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (we have an opportunity here) 2000-02-11 0:00 ` Robert I. Eachus ` (2 preceding siblings ...) 2000-02-12 0:00 ` Samuel T. Harris @ 2000-02-12 0:00 ` blaak 3 siblings, 0 replies; 80+ messages in thread From: blaak @ 2000-02-12 0:00 UTC (permalink / raw) In article <38A47E5A.42406034@earthlink.net>, "Robert I. Eachus" <rieachus@earthlink.net> wrote: > Concept: Build a special version of gnat for scripting purposes [...] > Requirements: [...] > 2 Procedure, function, (and entry?) calls which do not match a > subprogram or entry declared in the script will be searched for > using a search path. I would recommend against this one. Procedures and processes are very different things. If nothing else, typos for an intended procedure call should not accidentally invoke a process. By using some lightweight invocation syntax, the distinction can be kept. Maybe even just Run(...). If you don't make a distinction between procedures and processes then you will be forced to have all these rules for the conversion of non-string parameters into process arguments, and process results back into Ada. Preserving the distinction lets this be unnecessary by using explicit interfaces to and from processes. The syntax should definitely be easy to express, but the distinction should be there. > 4) Environment variables shall be treated as String (Unbounded_String?) > variables in an outer scope, and shall be > hidden by identically > named variables in inner scopes. (In other > words, it must be > possible to pass a modified set of environment > variables to > nested calls.) Again I would preserve the distinction, since environment variables cross processes, but local variables don't. It would be a real drag if my local variables could accidentally be propagated to subprocesses (maybe I have one called DISPLAY). Note also that having environment variables be directly in the namespace of the Ada script implies that the scripting language must be case sensitive. I would suggest either a special package where environment variables can be read and set or a simple get/set routine pair. Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-10 0:00 ` Ray Blaak 2000-02-11 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei T. Jensen @ 2000-02-11 0:00 ` David Starner 2000-02-12 0:00 ` blaak 2000-02-12 0:00 ` Pascal Martin 2000-02-14 0:00 ` Robert A Duff 2 siblings, 2 replies; 80+ messages in thread From: David Starner @ 2000-02-11 0:00 UTC (permalink / raw) On 10 Feb 2000 13:35:57 -0800, Ray Blaak <blaak@infomatch.com> wrote: >Do ML or Haskell shells exist? It would be interesting to see how implicit >static strong typing makes things more correct while style allowing for easy >writing of command scripts. Given SML-NJ, what would it take for a ML shell besides some shell functions that could be written in ML? I.e. would just a ML library turn SML-NJ into what you're looking for? -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-11 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) David Starner @ 2000-02-12 0:00 ` blaak 2000-02-15 0:00 ` Brian Rogoff 2000-02-12 0:00 ` Pascal Martin 1 sibling, 1 reply; 80+ messages in thread From: blaak @ 2000-02-12 0:00 UTC (permalink / raw) In article <881hft$9ac1@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > Given SML-NJ, what would it take for a ML shell besides some shell > functions that could be written in ML? I.e. would just a ML library > turn SML-NJ into what you're looking for? I don't know. I suppose I would have to learn ML properly. Most lisps have decent macro systems with which one can write embedded languages fairly easily, allowing one to use, for example, a nice process invocation syntax. Can ML do this sort of thing? Ray Blaak blaak@infomatch.com Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-12 0:00 ` blaak @ 2000-02-15 0:00 ` Brian Rogoff 0 siblings, 0 replies; 80+ messages in thread From: Brian Rogoff @ 2000-02-15 0:00 UTC (permalink / raw) On Sat, 12 Feb 2000 blaak@infomatch.com wrote: > In article <881hft$9ac1@news.cis.okstate.edu>, > dstarner98@aasaa.ofe.org wrote: > > Given SML-NJ, what would it take for a ML shell besides some shell > > functions that could be written in ML? I.e. would just a ML library > > turn SML-NJ into what you're looking for? > > I don't know. I suppose I would have to learn ML properly. I would suggest learning OCaml rather than SML-NJ since the implementation has properties you want if you're looking for a scripting-like tool. > Most lisps have decent macro systems with which one can write embedded > languages fairly easily, allowing one to use, for example, a nice > process invocation syntax. Can ML do this sort of thing? There is a program called CamlP4 at http://caml.inria.fr/camlp4/index.html I quote: Camlp4 is a Pre-Processor-Pretty-Printer for Objective Caml. It offers tools for syntax (grammars) and the ability to modify the concrete syntax of the language (quotations, syntax extensions). I haven't used it, but you could try that. I believe that this kind of stuff is cutting edge research in statically typed FP, but old hat for Lispers (who don't worry about static typing). -- Brian ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-11 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) David Starner 2000-02-12 0:00 ` blaak @ 2000-02-12 0:00 ` Pascal Martin 1 sibling, 0 replies; 80+ messages in thread From: Pascal Martin @ 2000-02-12 0:00 UTC (permalink / raw) In article <881hft$9ac1@news.cis.okstate.edu>, dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) wrote: > On 10 Feb 2000 13:35:57 -0800, Ray Blaak <blaak@infomatch.com> wrote: >>Do ML or Haskell shells exist? It would be interesting to see how implicit >>static strong typing makes things more correct while style allowing for easy >>writing of command scripts. > > Given SML-NJ, what would it take for a ML shell besides some shell > functions that could be written in ML? I.e. would just a ML library > turn SML-NJ into what you're looking for? I looked a bit at ML. It seems the functional languages are rather more formal than convenient. Interfacing with the external world (or processes) cannot be defined formally, so these languages tend to be weak in that respect (because this was not the original intend of the design ?). As such, there are at least two of my criteria that are probably not met: process control and GUI. I am interested by a counterproof ! ------------------------------------------------------------------ Pascal F. Martin. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-10 0:00 ` Ray Blaak 2000-02-11 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei T. Jensen 2000-02-11 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) David Starner @ 2000-02-14 0:00 ` Robert A Duff 2 siblings, 0 replies; 80+ messages in thread From: Robert A Duff @ 2000-02-14 0:00 UTC (permalink / raw) Ray Blaak <blaak@infomatch.com> writes: > By easy to write, I do not mean the using a terse symbology of C-like or APL > operators. By mean the ability to naturally express powerful high-level > abstractions with a minimum of effort. That is, the language style encourages > such things. Lispy, functional languages usually do well for me here. > > By writing things at a higher level, I believe that code is actually clearer > and easier to maintain. In other words, by "easy to write", you mean "easy to read". ;-) ;-) Anyway, I think we basically agree... - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged typesextensions) 2000-02-03 0:00 ` Brian Rogoff 2000-02-04 0:00 ` Ray Blaak @ 2000-02-05 0:00 ` Lionel Draghi 1 sibling, 0 replies; 80+ messages in thread From: Lionel Draghi @ 2000-02-05 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > On Thu, 3 Feb 2000, root wrote: > > Brian Rogoff wrote: > > > ... > > > > > > Dylan-over-Ada anyone? Yikes, that acronym is horrible :-) > > The most important progress is to have a readable and safe language. > > So why Dylan, Perl? Why not something close to Ada syntax? Each time i > > How dare you compare Dylan and Perl for readability! Shame on you! :-) Sorry, i am on a slippery slope: i chat on a language i don't even know. I begin to be alike usual Ada enemy! you are right : Shame on me! > > -- Brian -- ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-03 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) root 2000-02-03 0:00 ` Brian Rogoff @ 2000-02-05 0:00 ` Ehud Lamm 2000-02-06 0:00 ` Lionel Draghi 1 sibling, 1 reply; 80+ messages in thread From: Ehud Lamm @ 2000-02-05 0:00 UTC (permalink / raw) The topic of scripting languages themselves and esp. with connection to Ada is a subject to which I gave much thought. My feeling is in accordance with those who think that scripting languages have a very different philosphy than Ada - like type safety issues, weaker emphesize (to say the least!) on readablity etc. So I wouldn't go in the direction of an Ada or Ada-like scripiting language, but rather in one or both of these directions: - packages that supply functionality useflu for scripting jobs. - embeddable little languages that can be used from inside Ada systems. Some idea of what I mean (but in a different context and hence not developed in full) can be found in my work on frameworks (URL below). 1. An Awk-alike frameowrk which allow Awk style processing to be done easily inside Ada systems (including the parsing to fields, records, implicit conversions etc. - but all done as subroutine invocation in Ada) 2. SEPI - the Simple Embeddable Parser and Interpeter (far from being ready for daylight...) which should allow you to put an interperter for a simple lagnuage inside you code. This topic is quite interesting, but since i don't have the time right now to write it up, I suggest those interested in some of my ideas on this look at: http://purl.oclc.org/NET/ehud-site/ada/frameworks.html Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Ehud Lamm @ 2000-02-06 0:00 ` Lionel Draghi 2000-02-06 0:00 ` Ehud Lamm ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Lionel Draghi @ 2000-02-06 0:00 UTC (permalink / raw) Ehud Lamm wrote: > > The topic of scripting languages themselves and esp. with connection to > Ada is a subject to which I gave much thought. > My feeling is in accordance with those who think that scripting languages > have a very different philosphy than Ada - like type safety issues, weaker > emphesize (to say the least!) on readablity etc. As Robert A Duff said : "Scripting languages should encourage programs that are easy to write, easy to understand, and easy to change." This is the goal. A lot of scripting language release language controls to achieve this goal, i think mainly for convenience. I don't think it is a goal (or a philosophy), but an easy way to achieve it. Another deal between verbosity and write ease is probably possible. > So I wouldn't go in the direction of an Ada or Ada-like scripiting > language, but rather in one or both of these directions: > - packages that supply functionality useflu for scripting jobs. > - embeddable little languages that can be used from inside Ada systems. With the former available for the later, i suppose? > ... ________________________________________________________________________ Lionel Draghi http://attac.org/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-06 0:00 ` Lionel Draghi @ 2000-02-06 0:00 ` Ehud Lamm 2000-02-06 0:00 ` scripting/extension language for Ada Terry Westley 2000-02-09 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Robert A Duff 2 siblings, 0 replies; 80+ messages in thread From: Ehud Lamm @ 2000-02-06 0:00 UTC (permalink / raw) On Sun, 6 Feb 2000, Lionel Draghi wrote: |As Robert A Duff said : |"Scripting languages should encourage programs that are easy to |write, easy to understand, and easy to change." This seems like a good goal for all kinds of languages... | |> So I wouldn't go in the direction of an Ada or Ada-like scripiting |> language, but rather in one or both of these directions: |> - packages that supply functionality useflu for scripting jobs. |> - embeddable little languages that can be usedfrom inside Ada systems. |With the former available for the later, i suppose? Or the other way arround... Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada 2000-02-06 0:00 ` Lionel Draghi 2000-02-06 0:00 ` Ehud Lamm @ 2000-02-06 0:00 ` Terry Westley 2000-02-09 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Robert A Duff 2 siblings, 0 replies; 80+ messages in thread From: Terry Westley @ 2000-02-06 0:00 UTC (permalink / raw) I've been experimenting with making both scripting type functionality and an embeddable scripting language (Tcl) available in Ada. For specifics, see http://www.adatcl.com. Having done a lot of programming in Tcl/Tk, I find that most of my bugs result from lack of typing. But, that's what is supposed to make scripting languages so easy to use! What I'm trying to accomplish with TASH is to provide the benefits of a scripting language (e.g. platform-independent graphical user interfaces, performing regular expression pattern matching and using associative arrays) in Ada. You can then mix the features of both Ada and Tcl to, hopefully, get a better program sooner. -- Terry J. Westley, Software Systems Engineering Supervisor Veridian Engineering, Calspan Operations twestley@buffalo.veridian.com http://www.veridian.com/ ------------------------------------------------------- Author of TASH, an Ada binding to Tcl/Tk. Visit the TASH web site at http://www.adatcl.com. ------------------------------------------------------- ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: scripting/extension language for Ada (was : Re: tagged types extensions) 2000-02-06 0:00 ` Lionel Draghi 2000-02-06 0:00 ` Ehud Lamm 2000-02-06 0:00 ` scripting/extension language for Ada Terry Westley @ 2000-02-09 0:00 ` Robert A Duff 2 siblings, 0 replies; 80+ messages in thread From: Robert A Duff @ 2000-02-09 0:00 UTC (permalink / raw) Lionel Draghi <Lionel.Draghi@free.fr> writes: > As Robert A Duff said : > "Scripting languages should encourage programs that are easy to > write, easy to understand, and easy to change." I don't think *I* said that. In fact, my opinion is that "easy to write" not important; the other two goals I agree with. But I think that's true of *any* application area, whether it be "scripts" or real-time systems or whatever. - Bob ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky ` (3 preceding siblings ...) 2000-01-28 0:00 ` Tucker Taft @ 2000-01-31 0:00 ` Mark Lundquist 2000-02-01 0:00 ` Vladimir Olensky ` (2 more replies) 4 siblings, 3 replies; 80+ messages in thread From: Mark Lundquist @ 2000-01-31 0:00 UTC (permalink / raw) To: vladimir_olenski Vladimir Olensky wrote: > The question is : > > Why in Ada it is not allowed to extend both public > and private part of the tagged type at one step Good question! None of the heavy hitters (Tucker et al) have weighed in, so let me venture my guess... I'd say the bottom line is, there isn't any really good reason. That's the short answer, stay with me if you want the details... :-) First of all, the way you phrased the question is likely to trip up some people. I think that Ada programmers aren't accustomed to thinking of an abstraction as having a "public" part that is extended by public extensions and a private part that is extended by private extensions. Not that it's incorrect or misleading to think that way in Ada; it's just that the way the language is defined doesn't encourage you to think in those terms. The way of thinking that's "natural" to Ada is to think of the derived type as providing an extension to the parent type, which extension is either public or private. So a more Ada-natural way to phrase your question might be, "why is there no syntax that combines both a public and private type extension?" But watch how this develops.. it gets deeper and more interesting! Onward to your example... > ( using > kind of syntax as in the following example ): > > package P is > > type T is tagged private; As others have pointed out, type T cannot be extended at this point because its full declaration isn't available. But I get the impression that T's being declared in P is not essential to your example. That is, you aren't concerned with the fact that T really has to come from another package. What you care about is that extending it in the way you want is going to require two type declarations, one to declare a public extension and another to declare the private extension. The first of these declarations is just "intermediate", in the sense that its only purpose is to be derived from by the second. You are just wondering why there couldn't have been a more streamlined way to do this in Ada, right? > type T1 is new T with > record with private > something: some_type; > and record; One possible reason could have been that there wasn't any good syntax for the feature. Good syntax would have to be clear to human readers, technically unambigous, and consistent with the rest of Ada. If the benefit of the feature would have been marginal, but the feature carries a cost of nastified syntax, then that feature is probably not going to make it into the language. For this reason, it's a worthwhile exercise to explore different syntax alternatives for features that you think should have gone into the language, or that you would like to see added to the language in the future. Sometimes the exercise exposes the fact that the feature doesn't really make sense after all. Other times, it can be a "proof by construction" that a good syntax is available, and that arguments against the feature on "no good syntax" grounds are unsound! So I will note in passing that in your example quoted above, having the record component list follow "with private" is poor, because it seems to say that "private" applies somehow to the list of components. A better alternative might be type T1 is new T with private with record Something_Public: Whatever; end record; This is clearer, because there is no "parenthetical" thing interposed between "record" and "end record". > > > private > > type T is tagged with > record > ID : Integer; > end record; > > type T1 is new T with > record > thing : some_other_type; > end record; > > end P; One of the rules of Ada syntax that you probably won't be able to break is that the full type declaration that completes a private type declaration (or extension declaration) has to be just that, _full_. In other words, you could remove the private type declaration and just _move_ the full declaration from the package private part to the visible part, and that would suffice to make the type visible. So for instance, if your private type declaration has (known) discriminants, then they have to be duplicated in the full type declaration. So your example syntax is no good because it in fact declares a completely different type, rather than completing the private declaration. It would at least have to say _something_ about the public part, and the most obvious thing, and also the way that would be most consistent with the existing feel of Ada, would be to duplicate it. Now, when you start trying to come up with a syntax that does this cleanly, you end up with something like this: type T1 is new T with record Something_Public: Whatever; private Something_Private: Whatever; end record; Now it becomes somewhat of a stretch to think of this as a syntax that combines a public extension and a private extension. We really now have to think of it as an extension that has both public and private components, and we were really committed to this once we decided to allow this in a single type derivation (it makes more sense to have one extension per derivation, after all... not two!) So if we change the language this way, we nullify 3.9.1(1) and change the definition of a type extension to something that in the general case has public and private components. This is really interesting. First of all, consider the full type declaration "rule" that I described earlier: the type extension shown above should be legal in the visible part, as well as the private part! And there is nothing that should really prevent this, since the private parts are private by virtue of the "private" in the extension -- it no longer depends on being in the private part of the package. All of this really begs the question of why this should be restricted to only extensions. Why should a simple tagged or non-tagged record declaration not also be able to have private components?: type Foo is record Public_Stuff: Whatever; private Private_Stuff: Whatever; end record; The syntax of protected declarations also is a precedent for this. Moreover, this takes us full circle to one of the original non-issues of not being able to extend a private or privately-extended type in the same package in which it's declared! If went all the way and allowed private components within a record declaration, the full type is now available within the visible part, and you can derive from it, if it makes sense logically to do it there! (i.e. the closely-related abstraction thing). So that allows packages to serve us naturally in one more situation, rather than forcing us to serve packages :-) So I think the real question is not, why can't you extend publicly and privately "all at once", but rather, why not let records and extensions have private components? It seems clear that any compromise of 3.9.1(1) is a very slippery slope that shoots you straight down to this. As I said before, I don't see any compelling reason why this couldn't have or shouldn't be done. Is there a compelling reason to do it (or to have done it)? I don't know. You could probably make a pretty good case for it. Back to "reality" :-)... > Instead I should do this in two steps. > 1. to extend private part and then > 2. to extend public part > or vice versa. > Right. Note that the first derived type can be abstract, which clarifies your intent. > Due to that type T1 has inheritance_depth = 3 > instead of inheritance_depth = 2. > Yeah... is there a problem with that? Cheers! Mark Lundquist Rational Software ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist @ 2000-02-01 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Simon Wright 2000-02-01 0:00 ` Ehud Lamm 2 siblings, 0 replies; 80+ messages in thread From: Vladimir Olensky @ 2000-02-01 0:00 UTC (permalink / raw) Mark Lundquist wrote in message <3895EC61.9B2157A8@rational.com>... >Vladimir Olensky wrote: > >> The question is : >> >> Why in Ada it is not allowed to extend both public >> and private part of the tagged type at one step > >Good question! > >None of the heavy hitters (Tucker et al) have weighed in, so let me >venture my guess... I'd say the bottom line is, there isn't any really >good reason. That's the short answer, stay with me if you want the >details... :-) First of all, thanks for your very interesting response. I've got real pleasure to follow your considerations. Sometimes question that popped out impulsively because your eyes were caught by something that seems unusual leads to very interesting results. <...> >The way of thinking that's "natural" to Ada is to think of the derived >type as providing an extension to the parent type, which extension >is either public or private. I always try not to put myself into the prison of any particular way of thinking. It helps to avoid becoming slave of some particular "club" and be open for anything that might be interesting which is outside the area covered by some particular way of thinking and also to avoid thinking "inertia". In this respect any programming language is just some tool to do some job. Ada is not exception from that rule. And as any other tool each one has it's advantages and drawbacks. Any master should not become the slave of any particular tool. He should be the master who knows what is the best way to use each of them. Tools should be the slaves of the master. Of course any master has the tool that he likes most of all and that's fine. <...> >So I think the real question is not, why can't you extend publicly and >privately "all at once", but rather, why not let records and extensions >have private components? It seems clear that any compromise of >3.9.1(1) is a very slippery slope that shoots you straight down to this. >As I said before, I don't see any compelling reason why this couldn't >have or shouldn't be done. Is there a compelling reason to do it (or to >have done it)? I don't know. You could probably make a pretty good >case for it. This twist is very interesting and exciting and I think it could be elaborated even further. We may ask several further questions that lead us very close to some notion that will be discussed a little bit later: 1. What if in some child package we will want to have parent public fields to be private and some parent private fields (not all of them) to be public. And having some declarations in the parent package we stick to them forever. There of course exists workaround but it is not very clean. 2. May be it is better to have most of the parent fields to be private and have the ability make some of them publicly available when needed ? These questions are not new and differently addressed in different existing languages. In C++ we have class access modifiers that allows to make public fields to be protected or private in the descendant classes. But this solves only one part of the above problem. First of all these modifies are applied to the whole class and not to the particular field. So if I use private or protected modifier in the derived class all the parent public members become private and protected in the child class. On the other hand there is no way to make some private parent components to be public in derived classes. C++ notion of friend does not help much in this issue. So C++ approach is not flexible at all regarding this issue. Another approach was taken in Modula-3 by introducing opaque types. They were discussed several times here in CLA and several times I gave a reference to very interesting article which discuss M3 opaque types. This is "Partial Revelation and Modula-3" at: http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html Most interesting thing about M3 opaque type is not the fact that their properties could be completely hidden in the implementation module. Some people tend to think that this is the main advantage of the opaque types but in fact it is not. This kind of property could be easily emulated in C++ and Ada. The main virtue of opaque types lies in their ability to reveal some of their hidden properties when needed - so called "partial revelation". This allows to have parent type to be completely hidden from the client and any descendant to reveal only those parent properties that needed for particular interface to the given implementation. Here again we come up to some more general design issues. For quite some time there exists the notion of the "Black Box" design approach that becomes more and more popular. Oberon even called their new product as "Black Box" framework. There are two approaches to the "Black Box" design model. 1. One is that we first create "Black Box" interface that describes it's functionality and then we implement that functionality in a way hidden from the client. In this model "Black Box" is the implementation of the given interface. This is approach that followed by the most programming languages that support the "Black Box" design approach in a way that allows to hide "Black Box" functionality implementation from the client. Ada, Java, C++, Modula-2 fall more or less in this category. 2. There exists another approach which was used so far more in hardware design than in software design and which is more close to real life model. Using this approach the main focus is the "Black Box" itself and it's functionality. "Black Box" is something that provides some kind of universal functionality in some domain which in turn could be provided by the set of some more small "Black Boxes". This functionality could be used by completely different clients that may need different interfaces to that functionality. So here we come to the point where we need to define more then one interface (for different clients) to the given "Black Box". There are not many languages that support directly this concept, but Modula-3 is among them. This is the area where Modular-3 opaque types and partial revelation shine most of all. This is exactly what is needed to support the second design model. In Modula-3 we can create "Black Box" component and define multiple interfaces for different clients using opaque types and partial revelation. I tend to think that Modular-3 designers were at least ten years ahead of their time regarding this issue. But who knows may be will see reincarnation of this idea pretty soon in some other real life language. May be in Ada , who knows :-). Though Ada does not support directly exporting several interfaces to the same implementations this could be partially done via child packages. The only question is how to reveal hidden/private details. As shown below this could be done using existing Ada syntax as well. The only one thing which could not be expressed using existing syntax is the partial type revelation. Namely this is ability to show in one interface that exported type is a descendant of some parent type and in another interface to show that it also has properties of another type. Some people may argue that the last approach does not differ much from the first one and even that the first one is more close to the real life development process. I can answer to this: Look around. Among all devices and appliances that are around us we see mostly the second model and not the first one. Not some boxes are built around their interfaces. Quite the contrary - all the interfaces are built to provide access to box functionality. Just look at a simple PC box which implements some general kind of functionality and provides many different interfaces to this functionality for different clients. It is interesting to note that CORBA and COM/DCOM technologies also tend to support more the second model. Both of them allow to use multiple interfaces to the distributed "Black Box" component . And again here I see that opaque types and partial revelation perfectly fit to and support these two modern technologies. So elaboration of the answer to my original question leads us to very interesting area indeed. Another interesting topic related to this subject is object/class properties (design and run time) that we want to make available to the client. Any "Black Box" component may have some properties the state of which could be needed to be available to the client. There again exists several approaches. The one of them used in Delphi Object Pascal (DOP) is very close to Ada syntax. In DOP we can just declare something type T = class (some_parent_class) private function Get_Property1 () : Integer; function Get_Property2 () : Integer; procedure Set_Property1 (prop :Integer); procedure Set_Property2 (prop: Integer); public property prop_1 : Integer read Get_Property1 write Set_Property1; published property prop_2 : Integer read Get_Property2 write Set_Property2; end; Then having an instance of type T , we can use that attributes directly : program Var obj : T; p1, p2 : Integer; begin p1 := obj.Prop_1; p2 := obj.Prop_2; { or } obj.Prop_1 := 2; obj.Prop_2 := 10; end; In Ada it seems that we can do something like that by overloading ":=" operator. But we can not do that for distinct type but not for particular property instance/field. So this is not perfect solution. On the other hand I see that current Ada rep syntax perfectly fits here. We can just declare: package P is type T is tagged private; type T1 is new T with record -- public properties A and B; -- they are public views of some internal states -- which in turn could be fields of some complex -- "Black Box" internal structures; A : [property] constant Integer; B : [property] Integer; end record; private type T is tagged record < some fields> end record; function Get_Property1 (obj : in out T ) : Integer; function Get_Property2 (obj : in out T ) : Integer; procedure Set_Property2 ( obj : in out T; prop: Integer); -- and then rep clause: for T.A'Get use Get_Property1 (obj : in out T ) : Integer; for T.B'Get use Get_Property1 (obj : in out T ) : Integer; for T.B'Set use Set_Property1 ( obj : in out T; prop: Integer); end P; No need to introduce any new keywords. Ada allows rep clauses for fully visible types to be in the private area. May be only property keyword could be introduced for clarity but generally there is no need of it at all; Everything fit perfectly into current Ada syntax; This approach can also could be used to reveal some private details of parent type in a new interface using direct mapping: package N is type T is new P with record A: some_type; B: some_type; end T; private for T.A use P.something; for T.B use P.something_else; -- or using renaming clause: T.A renames P.something; T.B renames use P.something_else; end N; All above is just brief description of what comes to mind when starting to elaborate the answer to "innocent" at the fist glance question. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist 2000-02-01 0:00 ` Vladimir Olensky @ 2000-02-01 0:00 ` Simon Wright 2000-02-01 0:00 ` Ehud Lamm 2 siblings, 0 replies; 80+ messages in thread From: Simon Wright @ 2000-02-01 0:00 UTC (permalink / raw) Mark Lundquist <mark@rational.com> writes: > type T1 is new T with > record > Something_Public: Whatever; > private > Something_Private: Whatever; > end record; Quite often I find that the full extension requires entities that I would much rather defer until the private part of the package. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: tagged types extensions - language design question 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist 2000-02-01 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Simon Wright @ 2000-02-01 0:00 ` Ehud Lamm 2 siblings, 0 replies; 80+ messages in thread From: Ehud Lamm @ 2000-02-01 0:00 UTC (permalink / raw) Perhaps another way of viewing this issue (following the discussion from Mark) is to ask who controls the private/public (i.e., data hiding) distinction. In Ada this is done on the package level, where as the example with private/public components ties the distinction to the type - as in C++ classes. In many cases the Ada approach is easier to understand, and enhances readability. But there can be other cases (perhaps like the one that prompted this discussion) that are more natural to express using the other approach. I am not sure that I can prove which is the better approach, but I agree that it seems like a core design principle of the language. Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2000-02-17 0:00 UTC | newest] Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-01-27 0:00 tagged types extensions - language design question Vladimir Olensky 2000-01-27 0:00 ` Fraser 2000-01-27 0:00 ` Matthew Heaney 2000-01-27 0:00 ` Charles Hixson 2000-01-28 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Matthew Heaney 2000-01-28 0:00 ` Charles Hixson 2000-01-28 0:00 ` Matthew Heaney 2000-02-01 0:00 ` Charles Hixson 2000-02-01 0:00 ` Matthew Heaney 2000-01-29 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Matthew Heaney 2000-01-27 0:00 ` Laurent Guerby 2000-01-28 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Andy 2000-01-28 0:00 ` Vladimir Olensky 2000-01-29 0:00 ` Andy 2000-01-31 0:00 ` Vladimir Olensky 2000-01-28 0:00 ` Tucker Taft 2000-01-31 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Charles Hixson 2000-02-01 0:00 ` Matthew Heaney 2000-02-01 0:00 ` Brian Rogoff 2000-02-03 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) root 2000-02-03 0:00 ` Brian Rogoff 2000-02-04 0:00 ` Ray Blaak 2000-02-04 0:00 ` Stanley R. Allen 2000-02-04 0:00 ` Samuel T. Harris 2000-02-05 0:00 ` Lionel Draghi 2000-02-05 0:00 ` Samuel T. Harris 2000-02-06 0:00 ` Bryce Bardin 2000-02-08 0:00 ` Samuel T. Harris 2000-02-06 0:00 ` Lionel Draghi 2000-02-05 0:00 ` Ray Blaak 2000-02-05 0:00 ` Lionel Draghi 2000-02-04 0:00 ` Robert A Duff 2000-02-05 0:00 ` Ehud Lamm 2000-02-05 0:00 ` blaak 2000-02-05 0:00 ` Brian Rogoff 2000-02-09 0:00 ` Robert A Duff 2000-02-09 0:00 ` Ted Dennison 2000-02-10 0:00 ` Samuel T. Harris 2000-02-10 0:00 ` Pascal Martin 2000-02-10 0:00 ` Ray Blaak 2000-02-11 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei T. Jensen 2000-02-11 0:00 ` Robert I. Eachus 2000-02-12 0:00 ` Pascal Martin 2000-02-13 0:00 ` Robert I. Eachus 2000-02-16 0:00 ` scripting/extension ... [off topic] Nick Roberts 2000-02-16 0:00 ` Ray Blaak 2000-02-12 0:00 ` scripting/extension language for Ada (we have an opportunity here) Tarjei Tj�stheim Jensen 2000-02-12 0:00 ` Samuel T. Harris 2000-02-14 0:00 ` Robert A Duff 2000-02-15 0:00 ` Samuel T. Harris 2000-02-16 0:00 ` Robert A Duff 2000-02-16 0:00 ` Samuel T. Harris 2000-02-16 0:00 ` Robert A Duff 2000-02-17 0:00 ` Samuel T. Harris 2000-02-12 0:00 ` root 2000-02-12 0:00 ` Samuel T. Harris 2000-02-12 0:00 ` blaak 2000-02-11 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) David Starner 2000-02-12 0:00 ` blaak 2000-02-15 0:00 ` Brian Rogoff 2000-02-12 0:00 ` Pascal Martin 2000-02-14 0:00 ` Robert A Duff 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged typesextensions) Lionel Draghi 2000-02-05 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Ehud Lamm 2000-02-06 0:00 ` Lionel Draghi 2000-02-06 0:00 ` Ehud Lamm 2000-02-06 0:00 ` scripting/extension language for Ada Terry Westley 2000-02-09 0:00 ` scripting/extension language for Ada (was : Re: tagged types extensions) Robert A Duff 2000-01-31 0:00 ` tagged types extensions - language design question Mark Lundquist 2000-02-01 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Simon Wright 2000-02-01 0:00 ` Ehud Lamm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox