controlled type in generic package?

controlled type in generic package?

[Nils Priebe]

 i tried to compile the following code example, but it does not work.
what did i wrong?

gnat error message :  controlled type must be declared at the library
level

has anybody a good idea?


generic

type Element_Type is private;
package ...

 type Collection_type is abstract tagged limited private;


private
-------------------------------------------------------------------------------

  type collection_Type is abstract new
Ada.Finalization.limited_Controlled with
     record
        Element_Counter : Natural;
     end record;

  procedure Initialize(Object : in out collection_Type);
  Procedure Finalize(Object : in out collection_Type);

Re: controlled type in generic package?

[Lutz Donnerhacke]

* Mark Lundquist wrote:
>Lutz Donnerhacke <lutz@iks-jena.de> wrote in message
>> Yep. The derivation tree must be public:
>
>That's not true!  There's nothing wrong with this code...
>
>The compilation error that was reported would have been due to the
>instantiation.  The instantiation is a copy of the generic template, so you
>can't instantiate a generic that does something that would be illegal to do
>in the same place if it weren't in a generic :-).  In this case, that
>something is to declare a type extension that's statically deeper than the
>parent.

I don't understand the reason, but will keep it in mind, until I came across
this situation.

>You certainly can derive privately -- and should, unless there's a reason
>not to.

Fine.

Re: controlled type in generic package?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 95p2ab$463$1@nnrp1.deja.com...
> Also, any instantiations of this generic will have to be done at the
> library level, since Limited_Controlled is declared at the library
> level, and types can't be declared at a lower level of scope than their
> parent types. (As a user, I hate that rule.)
>
I have sympathy for this feeling, and I see many people falling into that trap, but to be fair:
Do you know ANY language that allows it ?

Most OO languages (C++, Java, Eiffel, even Turbo-Pascal) do not allow declaring classes within a subprogram.
In Ada, all classes must be declared at the same level. In other languages, all classes must be declared at level 0.
So Ada is actually *more* permissive than other languages...

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: controlled type in generic package?

[Ted Dennison]

In article <95q1fa$9e$1@usenet.rational.com>,
  "Mark Lundquist" <mark@rational.com> wrote:
>
> Ted Dennison <dennison@telepath.com> wrote in message
> > Also, any instantiations of this generic will have to be done at the
> > library level, since Limited_Controlled is declared at the library
> > level, and types can't be declared at a lower level of scope than
> > their parent types.
...
> > (As a user, I hate that rule.)
>
> Do you hate it as much as what might happen if it weren't for the
> rule? :-)

I have to admit I'm a little unclear as to what nasty things could
happen to me if I were allowed to declare a derived tagged type at a
lower scope level than their parent type. The worst I can see that some
objects that are pointed to in a classwide aggregated data structure
might go invalid if I have things badly programmed. Since none of the
Ada compilers I use have garbage collection (and I can't use controlled
types as a general solution), I have to worry about deallocation issues
anyway, so its not like this is really saving me from anything.

On the other hand, I loose the ability to make use of the safer
controlled types in all but the most restrictive of circumstances. This
is not a theoretical issue; Its prevented me from using controlled types
in quite a few situations. In a very real sense, the baby got thrown out
with the bathwater. So perhaps this is just my ignorance speaking, but
yes, I do hate it more.

Of course there's nothing saying that there couldn't have been a
solution that keept the rule, but allowed non-library-level controlled
types. This whole situation is just an unfortunate side-effect of the
implementation method chosen for controlled types, and has nothing to do
with controlled types themselves. As such, I think its clear its a *bug*
in the Ada spec, which hopefully will be fixed in the next serious
revision. Making Ada.Controlled a generic would seem an obvious solution
(if a bit of a hack), but I'll leave the actual fix up to those who are
good at that sort of thing.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Brian Rogoff]

On Wed, 7 Feb 2001, Ted Dennison wrote:
> In article <95q1fa$9e$1@usenet.rational.com>,
>   "Mark Lundquist" <mark@rational.com> wrote:
> >
> > Ted Dennison <dennison@telepath.com> wrote in message
> > > Also, any instantiations of this generic will have to be done at the
> > > library level, since Limited_Controlled is declared at the library
> > > level, and types can't be declared at a lower level of scope than
> > > their parent types.
> ...
> > > (As a user, I hate that rule.)
> >
> > Do you hate it as much as what might happen if it weren't for the
> > rule? :-)
> 
> I have to admit I'm a little unclear as to what nasty things could
> happen to me if I were allowed to declare a derived tagged type at a
> lower scope level than their parent type. The worst I can see that some
> objects that are pointed to in a classwide aggregated data structure
> might go invalid if I have things badly programmed. Since none of the
> Ada compilers I use have garbage collection (and I can't use controlled
> types as a general solution), I have to worry about deallocation issues
> anyway, so its not like this is really saving me from anything.
> 
> On the other hand, I loose the ability to make use of the safer
> controlled types in all but the most restrictive of circumstances. This
> is not a theoretical issue; Its prevented me from using controlled types
> in quite a few situations. In a very real sense, the baby got thrown out
> with the bathwater. So perhaps this is just my ignorance speaking, but
> yes, I do hate it more.
> 
> Of course there's nothing saying that there couldn't have been a
> solution that keept the rule, but allowed non-library-level controlled
> types. This whole situation is just an unfortunate side-effect of the
> implementation method chosen for controlled types, and has nothing to do
> with controlled types themselves. As such, I think its clear its a *bug*
> in the Ada spec, which hopefully will be fixed in the next serious
> revision. Making Ada.Controlled a generic would seem an obvious solution
> (if a bit of a hack), but I'll leave the actual fix up to those who are
> good at that sort of thing.

I think that there is definitely a "usability" issue about Ada concerning 
nesting. In the AI on limited access types Bob Duff discussed allowing 
nested derivations as a substitute for funargs, just empowering the 
standard object as function trick. 

Tying Controlled to derivation has definitely been a pain for me as a
user too. I imagine it's less of a pain to C and C++ programmers who use Ada, 
since if you're used to "flat" languages you can program in "flat" Ada and 
you're mostly OK. It's a bit of a bummer when writing collection libaries
since if you make your collections controlled you pass on those
restrictions. 

I bet people who really get used to (a lexically scoped (not Emacs)) Lisp
or a modern functional language find this more irritating, because some
natural programming styles in those languages make use of nesting that
Ada doesn't have, just like people who get used to overloading in Ada
really miss it in ML. 

-- Brian

Re: controlled type in generic package?

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:95rpj5$gq7$1@nnrp1.deja.com...
> In article <95q1fa$9e$1@usenet.rational.com>,
>   "Mark Lundquist" <mark@rational.com> wrote:
> >
> > Ted Dennison <dennison@telepath.com> wrote in message
> > > Also, any instantiations of this generic will have to be done at the
> > > library level, since Limited_Controlled is declared at the library
> > > level, and types can't be declared at a lower level of scope than
> > > their parent types.
> ...
> > > (As a user, I hate that rule.)
> >
> > Do you hate it as much as what might happen if it weren't for the
> > rule? :-)
>
> I have to admit I'm a little unclear as to what nasty things could
> happen to me if I were allowed to declare a derived tagged type at a
> lower scope level than their parent type.

It is really very similar to the issue of an access value designating a
declared (aliased, on the stack) object.  For example, one could have an
access-to-classwide value designating an allocated value of a type derived
within a nested declarative region.  When that region "goes away", the type,
and hence, the primitive operations go away, and you don't want to try to
dispatch to them using that dangling pointer.

Consider:

package Graphics is

    type Shape is tagged
        record
            ...
    end record;

    type Any_Shape is access Shape'Class;

    procedure Dispatch( O : in Shape );

end Graphics;


with Graphics;  use Graphics;
procedure Illegal_Demo is

    Global : Any_Shape;

    procedure Bogus is

        package Shapes is
            type Circle is new Shape with ...
            procedure Dispatch( C : in Circle );
        end Shapes;

        package body Shapes is
            procedure Dispatch( C : in Circle ) is
            begin
                ...
            end Dispatch;
        end Shapes;

    begin
        Global := new Shapes.Circle;
    end Bogus;

begin
    Bogus;
    Dispatch( Global.all );
end Illegal_Demo;



Hoe this helps...

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com        Real-Time/OO Languages
progers@classwide.com          Hard Deadline Schedulability Analysis
(281)648-3165                          Software Fault Tolerance

Re: controlled type in generic package?

[Pat Rogers]

"Pat Rogers" <progers@NOclasswideSPAM.com> wrote in message
news:hQgg6.41$bZ4.1624@nnrp1.sbc.net...

<snip>

> Hoe this helps...

I never said I could spell!  :-)

Re: controlled type in generic package?

[Ted Dennison]

In article <%ghg6.61$bZ4.1846@nnrp1.sbc.net>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> "Pat Rogers" <progers@NOclasswideSPAM.com> wrote in message
> news:hQgg6.41$bZ4.1624@nnrp1.sbc.net...
>
> <snip>
>
> > Hoe this helps...
>
> I never said I could spell!  :-)

When I can put more than 4 sentences together without misspelling
something, I'll consider casting a stone or two.

Still, that's one name I don't think I've ever been called before...
:-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Mark Lundquist]

Lutz Donnerhacke <lutz@iks-jena.de> wrote in message
news:slrn9827l8.ml.lutz@taranis.iks-jena.de...
> * Mark Lundquist wrote:
> >The compilation error that was reported would have been due to the
> >instantiation.  The instantiation is a copy of the generic template, so
you
> >can't instantiate a generic that does something that would be illegal to
do
> >in the same place if it weren't in a generic :-).  In this case, that
> >something is to declare a type extension that's statically deeper than
the
> >parent.
>
> I don't understand the reason, but will keep it in mind, until I came
across
> this situation.

OK, here's the reason:

Suppose you have

    type T is tagged record
        .
        .

and

    procedure P (X : access T'Class);        -- (or a parameter of a named
access type)

Now suppose in a nested scope we say

    type D is new T with record
        .
        .

If we have an object of type D, we can pass a pointer to it in a call to P.
But maybe P does something squirrely with this pointer, like saving it on a
list.
Once the scope of D goes away, so have all objects of type D, so that
pointer is now dangling.  The result: The Kind Of Error That Is Not Supposed
To Happen To An Ada Program :-) :-)

I think Bob Duff's "limited access" proposal would fix this.  I really like
that proposal.

-- mark

Re: controlled type in generic package?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 95rpj5$gq7$1@nnrp1.deja.com...
> I have to admit I'm a little unclear as to what nasty things could
> happen to me if I were allowed to declare a derived tagged type at a
> lower scope level than their parent type.
OK, let's go:

package body Pack is
   type Parent is tagged ...;
   procedure Proc (X : Parent) is ... end Proc;

   type Ptr is access Parent'Class;
   V : Ptr;

   procedure P is
      type Child is new Parent with...;
      procedure Proc (X : Child) is... end Proc;
   begin
      V := new Child;
   end P;

begin
   P;
-- Now, V.all points to an object of type P.Child
-- We can call Proc (V.all) which will result in a dispatching call to P.Proc, but P is out of scope at this point !!!

Re: controlled type in generic package?

[dmitry6243]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

In article <95sjs9$ral$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> "Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
95rpj5$gq7$1@nnrp1.deja.com...
> > I have to admit I'm a little unclear as to what nasty things could
> > happen to me if I were allowed to declare a derived tagged type at a
> > lower scope level than their parent type.
> OK, let's go:
>
> package body Pack is
>    type Parent is tagged ...;
>    procedure Proc (X : Parent) is ... end Proc;
>
>    type Ptr is access Parent'Class;
>    V : Ptr;
>
>    procedure P is
>       type Child is new Parent with...;
>       procedure Proc (X : Child) is... end Proc;
>    begin
>       V := new Child;
>    end P;
>
> begin
>    P;
> -- Now, V.all points to an object of type P.Child
> -- We can call Proc (V.all) which will result in a dispatching call
> to P.Proc, but P is out of scope at this point !!!

This is an issue of how dispatch tables are implemented and maintained
at run-time. One could imagine a mechanism that would restore the
dispatch table, when a derived type goes away. The type tag could
be "redirected" to the base type tag, or the table slots corresponding
to the overriden methods could be restored etc. What is really nasty,
is that the semantic of V.Proc would depend on the context.

--
Regards,
Dmitry Kazakov


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Robert Dewar]

In article <3A82A66D.49DE7EBD@bton.ac.uk>,
  John English <je@bton.ac.uk> wrote:
> Brian Rogoff wrote:
> Not only that, but by deriving something from Controlled,
> you're giving up your ability to derive from anything else.

Right, this is usually a bad idea, instead it is better to have
a controlled component.


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Ted Dennison]

In article <95sgl2$3c8$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> ... but to be fair:
> Do you know ANY language that allows it ?
>
> Most OO languages (C++, Java, Eiffel, even Turbo-Pascal) do not allow
> declaring classes within a subprogram.
> In Ada, all classes must be declared at the same level. In other l
> anguages, all classes must be declared at level 0.
> So Ada is actually *more* permissive than other languages...

That's one way to put a positive spin on it. The negative spin is that
C++ allows users to create "controlled" classes everywhere a
non-controlled class can be declared, while Ada does not. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Florian Weimer]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> Most OO languages (C++, Java, Eiffel, even Turbo-Pascal) do not
> allow declaring classes within a subprogram.

C++ supports local classes (but prohibits static members, for obvious
reasons).

Re: controlled type in generic package?

[Florian Weimer]

John English <je@bton.ac.uk> writes:

> Not only that, but by deriving something from Controlled, you're
> giving up your ability to derive from anything else. If I want to
> derive a new type from an existing (non-Controlled) type and add
> a destructor (Finalize), I have to perform lots of acrobatics and
> commit all sorts of atrocities on my code to do it!

It's just an ordinary mixin construction.  Of course, there some
syntactical overhead involved, but it's straightforward.

Re: controlled type in generic package?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 95uens$rcf$1@nnrp1.deja.com...
> That's one way to put a positive spin on it. The negative spin is that
> C++ allows users to create "controlled" classes everywhere a
> non-controlled class can be declared, while Ada does not. :-)
>
Simply because Ada allows you to declare classes in more places than C++ does...

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: controlled type in generic package?

[Mark Lundquist]

J.P.'s example is much better than the one I gave (in a followup to Lutz
Donnerhacke), because it does not involve a dangling pointer.  It shows that
you would have a problem (beserk dispatching call) even though the object
still exists.

There would be a real problem with allowing an object to "outlive its
own type"!

Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote in message
news:95sjs9$ral$1@wanadoo.fr...
>
>[...]

Re: controlled type in generic package?

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2067 bytes --]

On Wed, 7 Feb 2001, Jean-Pierre Rosen wrote:
> "Ted Dennison" <dennison@telepath.com> a écrit dans le message news: 95p2ab$463$1@nnrp1.deja.com...
> > Also, any instantiations of this generic will have to be done at the
> > library level, since Limited_Controlled is declared at the library
> > level, and types can't be declared at a lower level of scope than their
> > parent types. (As a user, I hate that rule.)
> >
> I have sympathy for this feeling, and I see many people falling into that trap, but to be fair:
> Do you know ANY language that allows it ?

Yes (*). But the real issue in my mind is not so much the issue of nested
derivations as the fact that Controlled is a special kind of tagged type. 
I'm not saying that there is a better solution, just that from the user
point of view it's a real PITA. 

It's also the case that "controlledness" is infectious in the same way as 
"limitedness" which allows getting around single inheritance issues for 
controlledness but is still inelegant in my view. 
> 
> Most OO languages (C++, Java, Eiffel, even Turbo-Pascal) do not allow declaring classes within a subprogram.
> In Ada, all classes must be declared at the same level. In other languages, all classes must be declared at level 0.
> So Ada is actually *more* permissive than other languages...

Yes, C++, Java and Eiffel are fairly "flat" languages, like Python and
unlike Ada. Anyone remember what CLOS does? 

-- Brian

(*) Why, OCaml of course! Not that I'd ever likely write code like this...

class point x_init =
  object (self)
    val mutable x = x_init
    method get_x = x
    method private move d = x <- x + d
    method bump = self#move 1
  end

let f x = 
  let module M = (* nested module necessary for nested class decl *)
    struct
      class colored_point x (c : string) =
	object 
	  inherit point x
	  val c = c
	  method color = c
	end
      let cp = new colored_point x "blue"
      let foo = cp#get_x
    end in 
  print_endline ("val = " ^ (string_of_int M.foo))

Re: controlled type in generic package?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]


<dmitry6243@my-deja.com> a �crit dans le message news: 95tpba$9va$1@nnrp1.deja.com...
>[...]
> >    procedure P is
> >       type Child is new Parent with...;
> >       procedure Proc (X : Child) is... end Proc;
> >    begin
> >       V := new Child;
> >    end P;
> >
>
> This is an issue of how dispatch tables are implemented and maintained
> at run-time. One could imagine a mechanism that would restore the
> dispatch table, when a derived type goes away. The type tag could
> be "redirected" to the base type tag, or the table slots corresponding
> to the overriden methods could be restored etc. What is really nasty,
> is that the semantic of V.Proc would depend on the context.
>
No, you miss the point. A (dispatching) call to P.Proc could access P's local variables, but such variables would not exist at the
time P.Proc is called.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: controlled type in generic package?

[John English]

Florian Weimer wrote:
> 
> John English <je@bton.ac.uk> writes:
> 
> > Not only that, but by deriving something from Controlled, you're
> > giving up your ability to derive from anything else. If I want to
> > derive a new type from an existing (non-Controlled) type and add
> > a destructor (Finalize), I have to perform lots of acrobatics and
> > commit all sorts of atrocities on my code to do it!
> 
> It's just an ordinary mixin construction.  Of course, there some
> syntactical overhead involved, but it's straightforward.

Not hard to do, but annoying. A type declaration for the controlled
type, a separate type declaration for the derived type with a controlled
component added in, and if the controlled component's primitives need to
look at any components of the original record, some magic spells involving
access discriminants and view conversions.

This might not bother you, but it feels like acrobatics and atrocities to me.
IMHO this is straightforward in the same sense as OOP in C is straightforward:
"It's just an ordinary pointer-to-array-of-functions construction. Of course,
there's some syntactical overhead involved, but it's straightforward." :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: controlled type in generic package?

[Florian Weimer]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> Yes, C++, Java and Eiffel are fairly "flat" languages, like Python and
> unlike Ada.

Python permits class declarations anywhere a statement is allowed (in
fact, a class declaration *is* a statement).  Python classes are
usually used to implement closures:

def add_something(something):
    class Add_Something_Class:
        def __init__(self, something):
            self.something = something

        def __call__(self, arg):
            return arg + self.something

    return Add_Something_Class(something)

add_1 = add_something(1)

print add_1(2)

In this particular case, you could use a function declaration as well
(which is just another statement ;-), but in more complicated cases,
the class approach is better.

Python is not a flat language at all.

Re: controlled type in generic package?

[dmitry6243]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

In article <f1c069.v1e.ln@skymaster.axlog.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> <dmitry6243@my-deja.com> a �crit dans le message news:
95tpba$9va$1@nnrp1.deja.com...
> >[...]
> > >    procedure P is
> > >       type Child is new Parent with...;
> > >       procedure Proc (X : Child) is... end Proc;
> > >    begin
> > >       V := new Child;
> > >    end P;
> > >
> >
> > This is an issue of how dispatch tables are implemented and
> > maintained
> > at run-time. One could imagine a mechanism that would restore the
> > dispatch table, when a derived type goes away. The type tag could
> > be "redirected" to the base type tag, or the table slots
> > corresponding to the overriden methods could be restored etc. What
> > is really nasty, is that the semantic of V.Proc would depend on the
> > context.
> >
> No, you miss the point. A (dispatching) call to P.Proc could access
> P's local variables, but such variables would not exist at the
> time P.Proc is called.

No dispatch to P.Proc happens, if the dispatch table is corrected after
leaving P.Proc declaration scope (i.e. upon return from P). The
correction might be replacing address of P.Proc by address Pack.Proc.
Then V.Proc is dispatched to Pack.Proc.

Such approach has several drawbacks (starting from the necessity to have
dispatch dynamic tables). But I see no better way to allow local
overrides.

Another nasty thing with unlimited local overrides is that virtually
no expression involving methods will be static. If we write (this is
not Ada):

package MyNumbers is
   type MyNumber is tagged ...
   function "not" (X : MyNumber) return MyNumber;
   ...
end MyNumbers;

Then

procedure Foo is
   X : constant MyNumber := 1;     -- Static
   Y : constant MyNumber := not X; -- Not static!
begin
   ...
end Foo;

No matter the Y type tag is statically known, it cannot be static,
because "not" could be overriden at the call point of Foo!

--
Regards,
Dmitry Kazakov


Sent via Deja.com
http://www.deja.com/

Re: controlled type in generic package?

[Brian Rogoff]

On 9 Feb 2001, Florian Weimer wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > Yes, C++, Java and Eiffel are fairly "flat" languages, like Python and
> > unlike Ada.
> 
> Python permits class declarations anywhere a statement is allowed (in
> fact, a class declaration *is* a statement).  Python classes are
> usually used to implement closures:
[...snip...]
> Python is not a flat language at all.

Unless it has changed since I last used it (~ v1.5), Python does not have
nested scopes, so it's relatively flat. Even C has nested scopes, just not 
nested function definitions. 

Ada allows you to define classes at arbitrarily deep levels of
scope. Python doesn't even allow you to create deeper levels of scope. 

OK, I just hit the Python page and

http://python.sourceforge.net/peps/pep-0227.html
http://www.amk.ca/python/2.1/index.html#SECTION000300000000000000000

confirm that 2.1 will no longer be a "flat" language. 

-- Brian

Re: controlled type in generic package?

[Florian Weimer]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> Unless it has changed since I last used it (~ v1.5), Python does not have
> nested scopes, so it's relatively flat. Even C has nested scopes, just not 
> nested function definitions. 

I think you can pass around scopes freely with a few hacks. ;-)

> Ada allows you to define classes at arbitrarily deep levels of
> scope. Python doesn't even allow you to create deeper levels of scope. 

Even this can be solved with current Python versions.  I even used
such a trick in production code, but it's certainly ugly.

Re: controlled type in generic package?

[Brian Rogoff]

On Fri, 9 Feb 2001, John English wrote:
> Florian Weimer wrote:
> > It's just an ordinary mixin construction.  Of course, there some
> > syntactical overhead involved, but it's straightforward.
> 
> Not hard to do, but annoying. A type declaration for the controlled
> type, a separate type declaration for the derived type with a controlled
> component added in, and if the controlled component's primitives need to
> look at any components of the original record, some magic spells involving
> access discriminants and view conversions.
> 
> This might not bother you, but it feels like acrobatics and atrocities to me.
> IMHO this is straightforward in the same sense as OOP in C is straightforward:
> "It's just an ordinary pointer-to-array-of-functions construction. Of course,
> there's some syntactical overhead involved, but it's straightforward." :-)

Maybe even worse, since the OOP in C idiom is entirely explicit, whereas 
Controlledness has some implicitness about it. 

Oh well, I agree it's annoying, but I'm not even sure it's a misfeature. Any 
better ideas on a design for finalization, assuming you can't change Ada 
dramatically? 

-- Brian

Re: controlled type in generic package?

[Thomas Wolf]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

On Wed, 7 Feb 2001 23:52:36 +0100, "Jean-Pierre Rosen"
<rosen.adalog@wanadoo.fr> wrote:

>
>"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 95rpj5$gq7$1@nnrp1.deja.com...
>> I have to admit I'm a little unclear as to what nasty things could
>> happen to me if I were allowed to declare a derived tagged type at a
>> lower scope level than their parent type.
>OK, let's go:
>
>package body Pack is
>   type Parent is tagged ...;
>   procedure Proc (X : Parent) is ... end Proc;
>
>   type Ptr is access Parent'Class;
>   V : Ptr;
>
>   procedure P is
>      type Child is new Parent with...;
>      procedure Proc (X : Child) is... end Proc;
>   begin
>      V := new Child;
>   end P;
>
>begin
>   P;
>-- Now, V.all points to an object of type P.Child
>-- We can call Proc (V.all) which will result in a dispatching call to P.Proc, but P is out of scope at this point !!!

Dabbling in language design is fun :-)

It seems to me that this case could be handled by the already existing
accessibility level rules for access types. After all, type Child has
a level that is statically deeper than that of type Ptr, so the
assignment might simply be disallowed. Of course, one could still play
tricks with 'Unchecked_Access, but then, it's always been the
developers' responsibility to get things right when using
'Unchecked_Access!

As to P.Proc being out of scope: I guess this could be detected at
run-time. At least an implementation using static links could detect
that the static link in a call Proc (V.all) is null, and raise an
exception. A similar solution probably also exists for implementations
using displays.

I see a more serious problem with

package body Pack is
   type Parent is tagged ...;
   
   function Create return Parent'Class
   is
      type Child is new Parent with ...;
      Result : Child;
   begin
      return Result;
   end;

   P : Parent'Class := Create;

end Pack;

But even this could perhaps be handled by extending the accessibility
rule to class-wide types, too.

Are you aware that there is an AI on downward closures for subprogram
access types and limited tagged types (AI-00254)? It seems to me that
this AI has some relevance to this issue.

As for downward closures on subprogram access types: IIRC, Oberon
(from Wirth at ETH Zurich) had this.


-- 
Dr. Thomas Wolf <t_wolf@my-deja.com>

Re: controlled type in generic package?

[Nick Roberts]

Python is an interpreted language, and whilst classes can apparently be
declared within nested blocks, they all effectively exist at the same level
_within the interpreter_. In this sense, Python is a 'flat' language. A
compiled language cannot handle things in this way. Similar comments apply
to the LISP family and others.

--
Nick Roberts
http://www.AdaOS.org


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:871yt8rvhq.fsf@deneb.enyo.de...
> ...
> Python permits class declarations anywhere a statement is allowed (in
> fact, a class declaration *is* a statement).  Python classes are
> usually used to implement closures:
> ...
> Python is not a flat language at all.

Re: controlled type in generic package?

[Jon S Anthony]

Nick Roberts wrote:
> 
> "Florian Weimer" <fw@deneb.enyo.de> wrote in message
> news:871yt8rvhq.fsf@deneb.enyo.de...
> > ...
> > Python permits class declarations anywhere a statement is allowed (in
> > fact, a class declaration *is* a statement).  Python classes are
> > usually used to implement closures:
> > ...
> > Python is not a flat language at all.
>
> Python is an interpreted language, and whilst classes can apparently
> be declared within nested blocks, they all effectively exist at the
> same level _within the interpreter_. In this sense, Python is a
> 'flat' language. A compiled language cannot handle things in this
> way. Similar comments apply to the LISP family and others.

To the extent this says anything it is plainly rubbish.  "Exist at the
same level within the interpreter" has no sense.  Presumably you are
trying to say that there are no "packages" for large scale lexical
scoping.  However, this is incorrect.  Python does have packages,
though no nested scoping (in a package/module it's either global or
outer function scope - which is why you it does _NOT_ have closures).
OTOH, the class hierarchy is just that - a hierarchy (as in "not
flat").  Python definitely sucks, but not for any "flatness" reasons.

Beyond this, whether the language is compiled or not is also
irrelevant. For example, Common Lisp implementations are typically
compiled (to machine code and are _extremely_ efficient).  Common Lisp
has a multiply nesting hierarchical package structure which is also
dynamic (you can change package structure, importations, shadowing,
etc. at runtime, though this is typically _not_ something you would
do).


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: controlled type in generic package?

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> In article <x7vg0hd20cm.fsf@smaug.pushface.org>, Simon Wright says...
> >
> >This came as a Severe Blow to me after the ESR promotion of Python! I
> 
> Knowing his silly position on Ada, you should know better than to
> take ESR's recommendations on other languages.
> 
> RMS seems to prefer Scheme for such tasks. I haven't had a chance to
> try it myself, but I'd trust his judgement before I'd trust
> Raymod's.

What I ended up doing was completing my initial itcl ([incr tcl]???)
code -- a reasonably clean result, I thought. Elisp would have been an
alternative, but I needed simple XML support.

I wonder if there's a SAX-like parser for Scheme? the more languages
in a project the better, after all ..