tagged types extensions - language design question

tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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

Re: tagged types extensions - language design question

[Charles Hixson]

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

Re: tagged types extensions - language design question

[Fraser]

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.

Re: tagged types extensions - language design question

[Laurent Guerby]

"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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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.

Re: tagged types extensions - language design question

[Charles Hixson]

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.

Re: tagged types extensions - language design question

[Matthew Heaney]

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.

Re: tagged types extensions - language design question

[Vladimir Olensky]

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.

Re: tagged types extensions - language design question

[Andy]

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)

Re: tagged types extensions - language design question

[Tucker Taft]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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;

Re: tagged types extensions - language design question

[Andy]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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>

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Mark Lundquist]

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

Re: tagged types extensions - language design question

[Simon Wright]

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.

Re: tagged types extensions - language design question

[Charles Hixson]

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.

Re: tagged types extensions - language design question

[Charles Hixson]

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

Re: tagged types extensions - language design question

[Matthew Heaney]

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?

Re: tagged types extensions - language design question

[Matthew Heaney]

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.

Re: tagged types extensions - language design question

[Brian Rogoff]

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

Re: tagged types extensions - language design question

[Vladimir Olensky]

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

Re: tagged types extensions - language design question

[Ehud Lamm]

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!

scripting/extension language for Ada (was : Re: tagged types extensions)

[root]

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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Brian Rogoff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ray Blaak]

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.

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Robert A Duff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Stanley R. Allen]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (was : Re: tagged typesextensions)

[Lionel Draghi]

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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Lionel Draghi]

"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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Lionel Draghi]

"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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[blaak]

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.

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ray Blaak]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Brian Rogoff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ehud Lamm]

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!

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ehud Lamm]

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!

Re: scripting/extension language for Ada

[Terry Westley]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Bryce Bardin]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Lionel Draghi]

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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Lionel Draghi]

"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/

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ehud Lamm]

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!

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Robert A Duff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ted Dennison]

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.

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Robert A Duff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Pascal Martin]

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.

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Ray Blaak]

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.

Re: scripting/extension language for Ada (we have an opportunity here)

[Tarjei T. Jensen]

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,

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[David Starner]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Robert I. Eachus]

"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?

Re: scripting/extension language for Ada (we have an opportunity here)

[root]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Pascal Martin]

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.

Re: scripting/extension language for Ada (we have an opportunity here)

[Pascal Martin]

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.

Re: scripting/extension language for Ada (we have an opportunity here)

[blaak]

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.

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[blaak]

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.

Re: scripting/extension language for Ada (we have an opportunity here)

[Tarjei Tj�stheim Jensen]

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,

Re: scripting/extension language for Ada (we have an opportunity here)

[Robert I. Eachus]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Robert A Duff]

"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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Robert A Duff]

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

Re: scripting/extension language for Ada (was : Re: tagged types extensions)

[Brian Rogoff]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Samuel T. Harris]

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

Re: scripting/extension ... [off topic]

[Nick Roberts]

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+

Re: scripting/extension ... [off topic]

[Ray Blaak]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Robert A Duff]

"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

Re: scripting/extension language for Ada (we have an opportunity here)

[Samuel T. Harris]

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

Re: scripting/extension language for Ada (we have an opportunity here)

[Robert A Duff]

"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

Re: scripting/extension language for Ada (we have an opportunity here)

[Samuel T. Harris]

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