Re: Comments on generic stack?

Re: Comments on generic stack?

[David Wheeler]

Jean-Pierre Rosen (rosen@EMAIL.ENST.FR) wrote:
: At 14:11 13/03/1996 GMT, you wrote:
: >
: >  with Ada.Finalization; use Ada.Finalization;
: >
: >  generic
: >    type Item is private;
: >
: >  package Generic_Stack is
: >    type Stack is new Controlled with private; -- permit assignment.
: Why do you need to make it visibly derived from controlled ? Seems to me that
:      type  Stack is private;
: would be OK (even if completed as derived from Controlled).

Agreed, but by making it visibly derived you can derive controlled children
of the type. E.G.: Stacks that when created do something special.
It's a minor functionality; I think either way would be "right".

--- David

Re: Comments on generic stack?

[Michel Gauthier]

In article <4i6l2t$j1q@dmsoproto.ida.org>, wheeler@aphrodite.csed.ida.org
(David Wheeler) wrote:

>> [...]
>>  
>>  Below is yes, yet another implementation of an unbounded stack. This one
>>  supports assignment (:=), equality (=), and finalizes correctly, as
>>  well as supporting the tried and true Pop and Push operations.
>>  It's a generic that requires the Item to have := and =, but since the
>>  stack itself has those operations it is composable (you can have a
>>  Stack of Stacks of Integers).

Sorry to disturb, but I cannot understand what is a stack of stacks.

Stacks are designed to organise values, not objects. 
Stacks are objects, not values.
How can you define stacks of stacks ?

David probably means either stacks of (item=>references to stacks) or stacks of
(item=> some implementation of the stack abstract type with an initial algebra
behaviour). The latter actual type is an academic feature that has strictly no 
practical use.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

Re: Comments on generic stack?

[David Wheeler]

Michel Gauthier (gauthier@unilim.fr) wrote:
: In article <4i6l2t$j1q@dmsoproto.ida.org>, wheeler@aphrodite.csed.ida.org
: (David Wheeler) wrote:
....
: >>  It's a generic that requires the Item to have := and =, but since the
: >>  stack itself has those operations it is composable (you can have a
: >>  Stack of Stacks of Integers).

: Sorry to disturb, but I cannot understand what is a stack of stacks.

There are two issues here: (1) generality of a reusable component, and
(2) usability of stacks of stacks.  Let's talk about them one at a time.

(1) I strive to make reusable components general enough so that they can be
reused in many different contexts.  One way to _test_ the generality of
a component is to see if it's composable (i.e. can you build more
complex structures using it), and the simplest way to check that is
to try to compose it using itself.  I've written a paper that includes a 
discussion on the subject: "Analysis and Guidelines for Reusable Ada
Software", IDA Paper P-2765, August 1992.

Is composability of reusable components useful?  Well, are arrays of arrays
useful? If you believe the answer is "yes", then you know your answer.

(2) Are stacks of _stacks_ useful?  Well, not as useful as arrays of arrays.
However, if I can support stacks of stacks, I can also support other
combinations that are more likely to be useful.  And I _can_ imagine
"stacks of stacks" being useful in certain complicated parsing systems.

: Stacks are designed to organise values, not objects. 
: Stacks are objects, not values.

Not true.  This stack organizes Items. Items might be values, or they might
be references.  There is no reason to assume they must be one or the other.
For performance reasons you might choose to stack references instead of
the actual values, but there's no reason they MUST be one or the other.

: How can you define stacks of stacks ?

-- Easy; here's a stack of stacks of Integers:

with Generic_Stack, Stack_Int;

package Stack_Stack_Int is new Generic_Stack(Stack_Int.Stack);


with Generic_Stack;

package Stack_Int is new Generic_Stack(Integer);

: David probably means either stacks of (item=>references to stacks) or
: stacks of
: (item=> some implementation of the stack abstract type with an initial algebra
: behaviour).
: The latter actual type is an academic feature that has strictly no 
: practical use.

Disagree; see my example of arrays of arrays.

It _is_ true that my current implementation of adjust makes stack assignment
a big-ticket performance hit, but there are ways to reduce that cost in
most cases if you'd like to implement that.  You wouldn't even need to
change the visible specification.

In summary: the issue of having flexible reusable components is _NOT_
just an academic issue, and checking for composability helps you get there.

If I were _really_ serious about making my generic stack general I'd add
some iterators; for demonstration purposes I'm not sure I'll bother.

--- David
    wheeler@ida.org

Re: "Object" types vs. "Value" types

[John DiCamillo]

John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:

[a pretty darn good analysis of object vs. value types deleted]

>(Indeed, it's my humble (and perhaps radical) opinion that the very term
>"object-oriented" is a misnomer.  The paradigm that everybody is so
>gung-ho about these days should have been called "*CLASS*-oriented"
>programming.  A programming language could hypothetically give you
>_objects_ without necessarily giving you _classes_ as well.

Not hypothetically, it's been done: see Self, Cecil, and Obliq.

Given your analysis of object vs. value types, you might enjoy
reading the Obliq paper -- Obliq is a distributed scripting
language in which objects behave pretty much as you described
them.  Obliq objects are all 'network objects' which have not
just state but *location* in a distributed computing environment.
Objects can not be assigned, but they can be *cloned*, even
from one machine to another across a network.

>It's the
>_classes_, and the relationships between them, that give you all that
>juicy inheritance and polymorphism.)

Oh, and you were doing so well, too.  Prototypic object-oriented
languages frequently provide inheritance and polymorphism without
classes.  Some languages implement inheritance through 'delegation'
and effectively allow objects to change their 'type' at run time
by redirecting a 'parent' pointer.

-- 
    ciao,
    milo
================================================================
    John DiCamillo                         Fiery the Angels Fell 
    milod@netcom.com       Deep thunder rode around their shores

Re: Comments on generic stack?

[John G. Volan]

In article <milodDoKr88.876@netcom.com> John DiCamillo, milod@netcom.com
writes:
>John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:
>
>[a pretty darn good analysis of object vs. value types deleted]
>
>>(Indeed, it's my humble (and perhaps radical) opinion that the very term
>>"object-oriented" is a misnomer.  The paradigm that everybody is so
>>gung-ho about these days should have been called "*CLASS*-oriented"
>>programming.  A programming language could hypothetically give you
>>_objects_ without necessarily giving you _classes_ as well.
>
>Not hypothetically, it's been done: see Self, Cecil, and Obliq.

I knew that. No, really, I did, I did!  :-)

Seriously though, I had a feeling that someone would bring up
prototype/delegation-based languages.  However, what I really had in
mind was a hypothetical language that allowed you to encapsulate state
data together with state-changing operations, but that lacked any
notion of types/classes/prototypes. It would be something like a
brain-damaged Ada with packages but no record types. A package with
variables hidden in its body can act as a sort of "object", but it
would be a one-of-a-kind thing.  You wouldn't get any sense of having
many instances sharing common behavior and structural layout.  Yet
you'd still be able to claim you had a language that gave you
"objects."

>Given your analysis of object vs. value types, you might enjoy
>reading the Obliq paper -- Obliq is a distributed scripting
>language in which objects behave pretty much as you described
>them.  Obliq objects are all 'network objects' which have not
>just state but *location* in a distributed computing environment.
>Objects can not be assigned, but they can be *cloned*, even
>from one machine to another across a network.

Sounds interesting enough ... how about posting a pointer to this?

>>It's the
>>_classes_, and the relationships between them, that give you all that
>>juicy inheritance and polymorphism.)
>
>Oh, and you were doing so well, too.  Prototypic object-oriented
>languages frequently provide inheritance and polymorphism without
>classes.  Some languages implement inheritance through 'delegation'
>and effectively allow objects to change their 'type' at run time
>by redirecting a 'parent' pointer.

I guess what I was trying to say was that for those languages that do
use classes (Ada95, C++, Eiffel, Smalltalk, etc.) it's the classes, not
the objects, that make things so "sexy."  Likewise, you could say that
the sexy features of prototype-oriented languages are the prototyping
and delegation mechanisms; the "objects" by themselves are more prosaic.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------