Imitation is the sincerest form of flattery

Imitation is the sincerest form of flattery

[Robert C. Leif]

Microsoft is imitating Ada generics in its proposed next version of C#.
Microsoft is now explaining what is wrong with Java. This again demonstrates
that those who switched from Ada to Java did not do it for good
technological reasons.
Bob Leif
--------------------------------------------------------
C# Programming Language Future Features
Prashant Sridharan
Microsoft Corporation

March 2003

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar
t/html/vbconCProgrammingLanguageFutureFeatures.asp

Re: Imitation is the sincerest form of flattery

[Warren W. Gay VE3WWG]

Robert C. Leif wrote:
> Microsoft is imitating Ada generics in its proposed next version of C#.
> Microsoft is now explaining what is wrong with Java. This again demonstrates
> that those who switched from Ada to Java did not do it for good
> technological reasons.
> Bob Leif
> --------------------------------------------------------
> C# Programming Language Future Features
> Prashant Sridharan
> Microsoft Corporation
> 
> March 2003
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar
> t/html/vbconCProgrammingLanguageFutureFeatures.asp

The problem with it IMHO, is that it uses a similarly ugly syntax
and form that C++ templates uses. Gak!

Does anyone know what, if anything, has happened with the research
that IBM was doing with Java generics?  I seem to recall a post
last year that said that a researcher at IBM had prior experience
with Ada, and was looking into generics for Java (perhaps my memory
has muddled this somewhat). Just curious.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Imitation is the sincerest form of flattery

[chris.danx]

Robert C. Leif wrote:
> Microsoft is imitating Ada generics in its proposed next version of C#.
> Microsoft is now explaining what is wrong with Java. This again demonstrates
> that those who switched from Ada to Java did not do it for good
> technological reasons.

If you don't classify the Java API as technology then yes, otherwise no. 
  The vastness of utility in the API is why I've considered Java alot 
over Ada. Only problem is that Suns' Java SDK is not fast enough for 
*me*.  (I suppose I could use gcc java, but ...).  The hell that is C is 
the only alternative open to me, so I'm sticking with Ada for the time 
being.

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Robert C. Leif wrote:
> Microsoft is imitating Ada generics in its proposed next version of C#.

On the referenced page, they lie and dissemble about C++ templates.

You are right about them imitating Ada generics, although I don't see
anything like generic formal pacakges which Ada uses to great effect.
They are not imitating C++'s template specialization abilities, so they
will lack any template metaprogramming capability.

It seems clear to me that in both the Java and C# cases, generics are
being added as an afterthought by people who don't really understand
them.

> Microsoft is now explaining what is wrong with Java.

That's rather like me "explaining" what's wrong with Ada.

> This again demonstrates that those who switched from Ada to Java
 > did not do it for good technological reasons.

Were there that many people who did this? Anyway, perhaps there were
enough good technological reasons to switch that the lack of generics
was outweighed.

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: It seems clear to me that in both the Java and C# cases, generics are
: being added as an afterthought by people who don't really understand
: them.

Wasn't that Norman Cohen in the Java case? Yes, according to
http://java.sun.com/javaone/javaone2001/pdfs/2733.pdf

The recent Java-with-generics compiler works fairly well.

:> Microsoft is now explaining what is wrong with Java.

Eiffel has generics too, Bertrand Meyer travelled the world
in order to explain .NET. Is one to draw conclusions from this?

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Georg Bauhaus wrote:
> Wasn't that Norman Cohen in the Java case? Yes, according to
> http://java.sun.com/javaone/javaone2001/pdfs/2733.pdf

He's listed as a "member of the expert group". The Java generics
are particularly bad. While that presentation likes to make the
usual lies about C++ templates, what they don't tell you is that
in the Java generics the type parameters can't be fundamental
types, only Object-derived ones (look at all their examples), and
that you can't overload on generics:
     class Joe {
         void f(List<Integer> l) { }
         void f(List<Byte> l)    { }
     }
I stand by my claim.

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: He's listed as a "member of the expert group". The Java generics
: are particularly bad. While that presentation likes to make the
: usual lies about C++ templates, what they don't tell you is that
: in the Java generics the type parameters can't be fundamental
: types, only Object-derived ones (look at all their examples), and
: that you can't overload on generics:
:     class Joe {
:         void f(List<Integer> l) { }
:         void f(List<Byte> l)    { }
:     }

Yes and no. Perhaps it's the bad habit of many a C++
program to not give names to types, that is use abstraction,
and instead use "in place generics", that leads to this
expectation?
     class LI extends LinkedList<Integer> {}
     class LB extends LinkedList<Byte> {}
     class Joe {
         void f(LI l) { }
         void f(LB l) { }
     }
(Not that easy exposing just the List interface, which I've just learned
is easily accomplished in Eiffel, using a "join feature".)
I'd guess that Betrand Meyer will tell you that OO is in many cases
about *avoiding* overloading.
     class Joe ... {
         void f(List<Integer> l) {}
     }
     class Jane ... {
         void f(List<Byte> l) {}
     }
As for fundamental types, in a true OO language there shouldn't be
non-OO types in the first place, so some true OO-languages
don't have them :-)
I'm not saying that any language should be a true OO-language and
nothing more.

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Tue, 18 Mar 2003 10:37:12 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>As for fundamental types, in a true OO language there shouldn't be
>non-OO types in the first place, so some true OO-languages
>don't have them :-)
>I'm not saying that any language should be a true OO-language

[ If I correctly read between the lines, "any" should include Ada ]

However, what if we replace "OO" with "ADT", and then ask this
question again?

> and nothing more.

You meant "and nothing less", I suppose. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: However, what if we replace "OO" with "ADT", and then ask this
: question again?

What can you do with ADTypes, in the way that you can do something
with extensible types?

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Wed, 19 Mar 2003 11:12:05 +0000 (UTC), Georg Bauhaus
<sb463ba@d2-hrz.uni-duisburg.de> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: However, what if we replace "OO" with "ADT", and then ask this
>: question again?
>
>What can you do with ADTypes, in the way that you can do something
>with extensible types?

To inherit the type interface. For example, an array type implemented
by a record type:

   -- This is not Ada!
   type Unbounded_String is
      private array (Integer range <>) of Character;

private
   type Unbounded_String is record
      ...
   end record;
   -- Definition of implemented abstract array opeartions follows

BTW. Extensibility is not the only way to create new types. It is not
the whole OO and there is no reason why it is not ADT.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p2vi7vs64p33mpnbsfsn43cvh72l44tm95@4ax.com...
> To inherit the type interface. For example, an array type implemented
> by a record type:
>
>    -- This is not Ada!
>    type Unbounded_String is
>       private array (Integer range <>) of Character;
>
> private
>    type Unbounded_String is record
>       ...
>    end record;
>    -- Definition of implemented abstract array opeartions follows

I'm a little unclear about what you're asking for here. In your envisioned
vision of Ada, what does this code do? How would it differ from doing
something like this:

   -- This is Ada!
   type Unbounded_String ( First, Last : Integer ) is private;

private
   type Unbounded_String is record
      ...
   end record;

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Thu, 20 Mar 2003 14:27:12 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:p2vi7vs64p33mpnbsfsn43cvh72l44tm95@4ax.com...
>> To inherit the type interface. For example, an array type implemented
>> by a record type:
>>
>>    -- This is not Ada!
>>    type Unbounded_String is
>>       private array (Integer range <>) of Character;
>>
>> private
>>    type Unbounded_String is record
>>       ...
>>    end record;
>>    -- Definition of implemented abstract array opeartions follows
>
>I'm a little unclear about what you're asking for here. In your envisioned
>vision of Ada, what does this code do?

A private implementation of an array type. If the language have had
full ADT there would be no need predefined Unbounded_String. Or
consider the following:

type Sparse_Matrix is
   private array (Integer range <>; Integer <>) of Element;

It has an array interface, but internally it is also a record type
using a list to keep the array elements.

>How would it differ from doing
>something like this:
>
>   -- This is Ada!
>   type Unbounded_String ( First, Last : Integer ) is private;
>
>private
>   type Unbounded_String is record
>      ...
>   end record;

The above isn't an array. You cannot use it where an array is
expected. It has no 'First, 'Last, no slices etc.

-----
The problem with ADT in Ada is that technically there is only two (*)
type interfaces you can inherit from (implement privately):

type ... is private;
type ... is limited private;

At the same time Ada's set of built-in interfaces is far more richer:

type ... is access ...;
type ... is delta ...;
type ... is mod ...;
type ... is array ...;
type ... is record ...;
protected type ...;
task type ...;

etc.

In my view to fully support ADT would mean that any of such type
interfaces would be available for private implementation.

-----
(*) I intentionally omit type ... is tagged ..., because I believe
that *all* types have to be tagged.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Pascal Obry]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> A private implementation of an array type. If the language have had
> full ADT there would be no need predefined Unbounded_String. Or
> consider the following:
> 
> type Sparse_Matrix is
>    private array (Integer range <>; Integer <>) of Element;
> 
> It has an array interface, but internally it is also a record type
> using a list to keep the array elements.

But how do you access element into this array, what would be done
for:

   M : Sparse_Matix (1 .. 7, 1 .. 90);

   M (2, 6) := ...;

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Pascal Obry wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> A private implementation of an array type. If the language have had
>> full ADT there would be no need predefined Unbounded_String. Or
>> consider the following:
>> 
>> type Sparse_Matrix is
>>    private array (Integer range <>; Integer <>) of Element;
>> 
>> It has an array interface, but internally it is also a record type
>> using a list to keep the array elements.
> 
> But how do you access element into this array, what would be done
> for:
> 
>    M : Sparse_Matix (1 .. 7, 1 .. 90);
> 
>    M (2, 6) := ...;

I have to prove an implementation for Set_Element, I suppose. When I declare 
that Sparse_Matrix an array, I have to override all the abstract methods of 
the universal array type might have. Set_Element is one of them.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> > But how do you access element into this array, what would be done
> > for:
> > 
> >    M : Sparse_Matix (1 .. 7, 1 .. 90);
> > 
> >    M (2, 6) := ...;
> 
> I have to prove an implementation for Set_Element, I suppose. When I declare 
> that Sparse_Matrix an array, I have to override all the abstract methods of 
> the universal array type might have. Set_Element is one of them.

You mean that the compiler must generate a call to Set_Element/Get_Element for
every reference to an array item, right ?

So what you are looking for is a type with runtime support, a bit like
Ada.Finalization API with the Initialize/Adjust/Finalize routines, right ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Imitation is the sincerest form of flattery

[AG]

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:ubs03lcdz.fsf@wanadoo.fr...
>
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
> > > But how do you access element into this array, what would be done
> > > for:
> > >
> > >    M : Sparse_Matix (1 .. 7, 1 .. 90);
> > >
> > >    M (2, 6) := ...;
> >
> > I have to prove an implementation for Set_Element, I suppose. When I
declare
> > that Sparse_Matrix an array, I have to override all the abstract methods
of
> > the universal array type might have. Set_Element is one of them.
>
> You mean that the compiler must generate a call to Set_Element/Get_Element
for
> every reference to an array item, right ?

Well, I don't know what Dmitry meant of course :)

But my case would be that of the compiler knowing
pretty darn well what the index is - it could be just
a simple integer or so. The whole point is not about
hiding the info from the compiler (how could you?)
but about hiding/decoupling it from the clients of
the package. And keeping control of it. And being
able to change it without breaking all the clients ...

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

AG wrote:

> "Pascal Obry" <p.obry@wanadoo.fr> wrote in message
> news:ubs03lcdz.fsf@wanadoo.fr...
>
>> You mean that the compiler must generate a call to
>> Set_Element/Get_Element
> for
>> every reference to an array item, right ?
> 
> Well, I don't know what Dmitry meant of course :)
> 
> But my case would be that of the compiler knowing
> pretty darn well what the index is - it could be just
> a simple integer or so. The whole point is not about
> hiding the info from the compiler (how could you?)
> but about hiding/decoupling it from the clients of
> the package. And keeping control of it. And being
> able to change it without breaking all the clients ...

This is a more specialized problem. And yes, of course, there has to be 
universal index types. For example:

type My_Index is private index;
   -- Have to implement 'Succ, 'Pred, 'Range etc
type My_Array is array (My_Index range <>) of Something;

Here index is private, array is public. The most general case is when 
everything: index, element, and array are private:

type Item is private;
type Key is private index;
   -- Have to implement 'Succ, 'Pred, 'Range etc
type Table is private array (Key range <>) of Item;
   -- Have to implement Get, Set, Slice etc.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> > But how do you access element into this array, what would be done
>> > for:
>> > 
>> >    M : Sparse_Matix (1 .. 7, 1 .. 90);
>> > 
>> >    M (2, 6) := ...;
>> 
>> I have to prove an implementation for Set_Element, I suppose. When I
>> declare that Sparse_Matrix an array, I have to override all the abstract
>> methods of the universal array type might have. Set_Element is one of
>> them.
> 
> You mean that the compiler must generate a call to Set_Element/Get_Element
> for every reference to an array item, right ?

Surely

> So what you are looking for is a type with runtime support, a bit like
> Ada.Finalization API with the Initialize/Adjust/Finalize routines, right ?

There cannot be other mechanism I suppose. An universal array has some 
abstract primitive operations which has to be implemented. In case of 
built-in arrays, the implementeation is generated by the compiler. For 
user-defined ones, it is the programmer who implements them.

However, I am pretty aware that all unsolved problems with 
assignment/construction in Ada will inevitable show themselves for 
Set_Element.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> However, I am pretty aware that all unsolved problems with 
> assignment/construction in Ada will inevitable show themselves for 
> Set_Element.

Have you tried C++? In C++ you can provide an indexing operation
for a class (operator[]) that sounds just like what you want.

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> However, I am pretty aware that all unsolved problems with
>> assignment/construction in Ada will inevitable show themselves for
>> Set_Element.
> 
> Have you tried C++?

Surely. I have developed a whole class library with strings, dynamic arrays 
etc.

> In C++ you can provide an indexing operation
> for a class (operator[]) that sounds just like what you want.

Nope.

First of all, there is no contract. I want the compiler be aware that it is 
going to be an array and check if it is.

Secondly to make A[i]=X working you have to use a reference. Now, let I a 
have a packed bit array. What would be a reference to a bit? You would need 
to build a fat pointer class to fix this. The array has to represent an 
image in the video buffer. It has to be damn FAST. And where are 
multidimensional arrays in C++? And where are slices? Well, for them we 
need another class, etc. And what if A is a hash table, sparse array. It 
would be monstrous. And I want it on the stack!

IMO. The idea of treating

A[i]=X;

as

Assign (Index (A, i), X);

is a wrong one.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> First of all, there is no contract. I want the compiler be
 > aware that it is going to be an array and check if it is.

You have proxy classes that deal with all of this stuff.
Everything is typechecked.

> Secondly to make A[i]=X working you have to use a reference. Now, let I a 
> have a packed bit array. What would be a reference to a bit? You would need 
> to build a fat pointer class to fix this. The array has to represent an 
> image in the video buffer. It has to be damn FAST. And where are 
> multidimensional arrays in C++? And where are slices? Well, for them we 
> need another class, etc. And what if A is a hash table, sparse array. It 
> would be monstrous. And I want it on the stack!

It's not monstrous at all. First of all, as an Ada programmer,
you should not be complaining about having to write extra lines
of code to do what you want, as long as its all nice and readable.
Second of all, just because you need classes to handle all of this
doesn't prevent things from being on the stack, or from being fast.
Third of all, there is plenty of existing code to do this sort of
thing, in Boost and elsewhere.

Remembering some of our previous threads, I would caution you that
the proper way to implement all of this will eschew inheritance and
use templates heavily. If you try to do this using OO, then yes,
your code will be miserably slow.

> IMO. The idea of treating
>     A[i]=X;
> as
>     Assign (Index (A, i), X);
> is a wrong one.

Why? In particular, this technique is used very often in C++,
especially with expression templates. One has Index(A,i) just
return a proxy class which holds A and i, and implements the
Assign to take such a class. Inline expansion does the rest,
usually resulting in code that looks like an open-coded version.

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1048530794.5794@master.nyc.kbcfp.com>...
> Dmitry A. Kazakov wrote:
> > IMO. The idea of treating
> >     A[i]=X;
> > as
> >     Assign (Index (A, i), X);
> > is a wrong one.
> 
> Why? In particular, this technique is used very often in C++,
> especially with expression templates. One has Index(A,i) just
> return a proxy class which holds A and i, and implements the
> Assign to take such a class. Inline expansion does the rest,
> usually resulting in code that looks like an open-coded version.

It may be said that any access/reference is too strong contract.
Luckily it is available for free for one-address-space code and
comparatively safe for one-thread one and efficient and simple, yes.
For more complex cases there are property arrays thats don't have
reference semantics and can cover bits access as well.

Amir Yantimirov
http://www174.pair.com/yamir/programming/

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> First of all, there is no contract. I want the compiler be
>  > aware that it is going to be an array and check if it is.
> 
> You have proxy classes that deal with all of this stuff.
> Everything is typechecked.

The type is checked, not the class. It is same as in case of the formal 
parameters generics. That discussion we already had.

>> Secondly to make A[i]=X working you have to use a reference. Now, let I a
>> have a packed bit array. What would be a reference to a bit? You would
>> need to build a fat pointer class to fix this. The array has to represent
>> an image in the video buffer. It has to be damn FAST. And where are
>> multidimensional arrays in C++? And where are slices? Well, for them we
>> need another class, etc. And what if A is a hash table, sparse array. It
>> would be monstrous. And I want it on the stack!
> 
> It's not monstrous at all. First of all, as an Ada programmer,
> you should not be complaining about having to write extra lines
> of code to do what you want, as long as its all nice and readable.

I would complain. I do not like extra lines, especially any helper classes. 
Array is an old well known concept, which requires no baroque kinks.

> Second of all, just because you need classes to handle all of this
> doesn't prevent things from being on the stack, or from being fast.

Right, but not in C++, which is unable to handle unconstrained objects on 
the stack.

> Third of all, there is plenty of existing code to do this sort of
> thing, in Boost and elsewhere.
> 
> Remembering some of our previous threads, I would caution you that
> the proper way to implement all of this will eschew inheritance and
> use templates heavily. If you try to do this using OO, then yes,
> your code will be miserably slow.

But as you said it should not be slow.

>> IMO. The idea of treating
>>     A[i]=X;
>> as
>>     Assign (Index (A, i), X);
>> is a wrong one.
> 
> Why? In particular, this technique is used very often in C++,
> especially with expression templates. One has Index(A,i) just
> return a proxy class which holds A and i, and implements the
> Assign to take such a class. Inline expansion does the rest,
> usually resulting in code that looks like an open-coded version.

Even if this could work as expected, then why the compiler cannot do all 
that to me? But it does not work. If you want to pass an element as an 
in-out parameter (remember Ada has them), your nasty proxy class will show 
itself. Then to reconcile this with LSP you will have to make it derived 
from the type of the element. Ooch ... And this was supposed to be ADT, not 
OO!

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Array is an old well known concept, which requires no baroque kinks.

There are many old and well-known concepts.
Good programming languages allow you to build
them yourself instead of providing special
and unique support.

> Right, but not in C++, which is unable to handle unconstrained objects on 
> the stack.

True enough for now. I suspect C++ will eventually adopt a
form of C99's variable-length arrays, and then it will be
possible. Where supported, something could probably be
cobbled together with alloca.

> But as you said it should not be slow.

OO-style inheritance is the wrong concept for this.

> your nasty proxy class will show itself.
 > you will have to make it derived

Nope. The function will be a generic, instantiated
automatically on the proxy class.

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Tue, 25 Mar 2003 15:22:10 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Array is an old well known concept, which requires no baroque kinks.
>
>There are many old and well-known concepts.
>Good programming languages allow you to build
>them yourself instead of providing special
>and unique support.

I know such a language, one of the Turing machine. (:-))

>> Right, but not in C++, which is unable to handle unconstrained objects on 
>> the stack.
>
>True enough for now. I suspect C++ will eventually adopt a
>form of C99's variable-length arrays, and then it will be
>possible. Where supported, something could probably be
>cobbled together with alloca.
>
>> But as you said it should not be slow.
>
>OO-style inheritance is the wrong concept for this.

Wrong for what? There is no other way to specify a type set other than
through closures of a subtyping relation. That's what inheritance is
about.

>> your nasty proxy class will show itself.
> > you will have to make it derived
>
>Nope. The function will be a generic, instantiated
>automatically on the proxy class.

Let you declare:

   void Foo (Element& X);

then A[i] have to be of Element type to allow substitutability:

   Foo (A [i]);

If A [i] is of some proxy class then you need ether to make the class
a subtype of Element, or to write a wrapper for Foo.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Wrong for what? There is no other way to specify a type set other than
> through closures of a subtyping relation. That's what inheritance is
> about.

Yes there is. We've been through all this before.
The other way is through use patterns.

> Let you declare:
>    void Foo (Element& X);
> then A[i] have to be of Element type to allow substitutability:
> 
>    Foo (A [i]);
> If A [i] is of some proxy class then you need ether to make the class
> a subtype of Element, or to write a wrapper for Foo.

No, you declare
     template <typename Element> void Foo(Element &X);
and you just call
     Foo(A[i]);
As long as the proxy class has all of the operations
that Foo uses, everything works fine. No inheritance
is used.

Please, let's not recapitulate the whole inheritance
vs. generics thread.

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Wed, 26 Mar 2003 10:06:41 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Wrong for what? There is no other way to specify a type set other than
>> through closures of a subtyping relation. That's what inheritance is
>> about.
>
>Yes there is. We've been through all this before.
>The other way is through use patterns.

Pattern is not a language term. So it cannot be an other way. Other
way is cut'n'paste and patterns is a manual how to do it.

>> Let you declare:
>>    void Foo (Element& X);
>> then A[i] have to be of Element type to allow substitutability:
>> 
>>    Foo (A [i]);
>> If A [i] is of some proxy class then you need ether to make the class
>> a subtype of Element, or to write a wrapper for Foo.
>
>No, you declare
>     template <typename Element> void Foo(Element &X);
>and you just call
>     Foo(A[i]);

Exactly what I meant. It is no more a normal subroutine taking Element
a parameter. All users of my array have to know that it is not an
array; that they cannot index it is a normal way; that they have to
review and redesign all the code working with the type Element if
there is an array built on Element. Excellent.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> It is no more a normal subroutine taking Element a parameter.

Oh, sorry - I thought we were passing the array around.
Anyway, in C++ you just need to have a conversion to
reference to element type in the proxy class.

template <typename Element>
struct funky_array
{
     struct index_proxy
     {
         funky_array &a;
         int i;
         index_proxy(funky_array &a, int i) : a(a), i(i) { }
         operator Element &() { return a.get_element(i); }
     };
     Element &get_element(int i) { /* find and return the element */ }
     index_proxy operator[](int i) { return index_proxy(*this, i); }
};

Re: Imitation is the sincerest form of flattery

[Bill Findlay]

On 26/3/03 17:00, in article 1048698047.463797@master.nyc.kbcfp.com, "Hyman
Rosen" <hyrosen@mail.com> wrote:

> Anyway, in C++ you just need to have a conversion to
> reference to element type in the proxy class.
> 
> template <typename Element>
> struct funky_array
> {
>    struct index_proxy
>    {
>        funky_array &a;
>        int i;
>        index_proxy(funky_array &a, int i) : a(a), i(i) { }
>        operator Element &() { return a.get_element(i); }
>    };
>    Element &get_element(int i) { /* find and return the element */ }
>    index_proxy operator[](int i) { return index_proxy(*this, i); }
> };
> 

Hyman, 
could you explain what is going on in this rather obscure-looking code,
for the sake of C++ non-gurus like me?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Bill Findlay wrote:
> could you explain what is going on in this rather obscure-looking code,
> for the sake of C++ non-gurus like me?

The class funky_array can be treated like an array wrt indexing:
     funky_array<int> fa;
     fa[7] = 10;
This works because funky_array declares an 'operator[]', an
overloaded operator which is invoked through use of [].
Instead of returning the element itself, the indexing operator
returns an index_proxy object, which holds a reference to the
funky_array object itself and the index. This proxy object
has an 'operator Element &' member, that is, a user-defined
conversion operator from itself to a reference to an Element
(int, in our case). When you try to use the proxy object in a
place where an Element is expected, the compiler will use the
conversion operator to convert the proxy to an Element.

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<vqil7v81l8p8ocbv2ke9ectl8l33rr3gs8@4ax.com>...
> On Thu, 20 Mar 2003 14:27:12 GMT, "Frank J. Lhota"
> <NOSPAM.lhota.adarose@verizon.net> wrote:
> 
> >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> >news:p2vi7vs64p33mpnbsfsn43cvh72l44tm95@4ax.com...

<Snip>

> The above isn't an array. You cannot use it where an array is
> expected. It has no 'First, 'Last, no slices etc.
> 
> -----
> The problem with ADT in Ada is that technically there is only two (*)
> type interfaces you can inherit from (implement privately):
> 
> type ... is private;
> type ... is limited private;
> 
> At the same time Ada's set of built-in interfaces is far more richer:
> 
> type ... is access ...;
> type ... is delta ...;
> type ... is mod ...;
> type ... is array ...;
> type ... is record ...;
> protected type ...;
> task type ...;
> 
> etc.
> 
> In my view to fully support ADT would mean that any of such type
> interfaces would be available for private implementation.
> 

In my ideal world you don't need inhere anything:
http://www174.pair.com/yamir/programming/interfaces.htm

Sorry, if I annoy somebody.

> -----
> (*) I intentionally omit type ... is tagged ..., because I believe
> that *all* types have to be tagged.

Not rare opinion. But I found it somewhere contradicting with you background :).
Lots of types I works with has hardwired bits structure. 

Amir Yantimirov

> ---
> Regards,
> Dmitry Kazakov
> www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Amir Yantimirov wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message
> news:<vqil7v81l8p8ocbv2ke9ectl8l33rr3gs8@4ax.com>...

>> In my view to fully support ADT would mean that any of such type
>> interfaces would be available for private implementation.
> 
> In my ideal world you don't need inhere anything:
> http://www174.pair.com/yamir/programming/interfaces.htm

Maybe it is just a wording problem. Many dislike the word "inheritance". 
(:-))

>> -----
>> (*) I intentionally omit type ... is tagged ..., because I believe
>> that *all* types have to be tagged.
> 
> Not rare opinion. But I found it somewhere contradicting with you
> background :). Lots of types I works with has hardwired bits structure.

Yes, but this does not mean that a hardwired bits cannot be "tagged". You 
can have even Booleans "tagged". The idea is to have different 
representations for Boolean and Boolean'Class.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<b5jrs4$2a6fho$1@ID-77047.news.dfncis.de>...
> Amir Yantimirov wrote:
> 
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message
> > news:<vqil7v81l8p8ocbv2ke9ectl8l33rr3gs8@4ax.com>...
>  
> >> In my view to fully support ADT would mean that any of such type
> >> interfaces would be available for private implementation.
> > 
> > In my ideal world you don't need inhere anything:
> > http://www174.pair.com/yamir/programming/interfaces.htm
> 
> Maybe it is just a wording problem. Many dislike the word "inheritance". 
> (:-))

Oops. Sorry. Anyway, the idea is type functionality may be extended
freely so it don't have to be specified in type declaration.

> 
> >> -----
> >> (*) I intentionally omit type ... is tagged ..., because I believe
> >> that *all* types have to be tagged.
> > 
> > Not rare opinion. But I found it somewhere contradicting with you
> > background :). Lots of types I works with has hardwired bits structure.
> 
> Yes, but this does not mean that a hardwired bits cannot be "tagged". You 
> can have even Booleans "tagged". The idea is to have different 
> representations for Boolean and Boolean'Class.

Fine. But what's the gain? I rarely needs any _polymorphic_ feature
for such types above "this type is distinct four-byte thing".

Amir Yantimirov

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Amir Yantimirov wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:<b5jrs4$2a6fho$1@ID-77047.news.dfncis.de>...
>> Amir Yantimirov wrote:
>> 
>> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message
>> > news:<vqil7v81l8p8ocbv2ke9ectl8l33rr3gs8@4ax.com>...
>>  
>> >> In my view to fully support ADT would mean that any of such type
>> >> interfaces would be available for private implementation.
>> > 
>> > In my ideal world you don't need inhere anything:
>> > http://www174.pair.com/yamir/programming/interfaces.htm
>> 
>> Maybe it is just a wording problem. Many dislike the word "inheritance".
>> (:-))
> 
> Oops. Sorry. Anyway, the idea is type functionality may be extended
> freely so it don't have to be specified in type declaration.

If nothing specified then nothing can be checked at compile time. There are 
languages like SmallTalk for this, they have their place, but of little 
interest. Because the real challenge is: to check as much as possible, 
giving up as little as we can.

>> >> (*) I intentionally omit type ... is tagged ..., because I believe
>> >> that *all* types have to be tagged.
>> > 
>> > Not rare opinion. But I found it somewhere contradicting with you
>> > background :). Lots of types I works with has hardwired bits structure.
>> 
>> Yes, but this does not mean that a hardwired bits cannot be "tagged". You
>> can have even Booleans "tagged". The idea is to have different
>> representations for Boolean and Boolean'Class.
> 
> Fine. But what's the gain? I rarely needs any _polymorphic_ feature
> for such types above "this type is distinct four-byte thing".

And what is lost? You need no class-wide objects? Declare them specific!

BTW, Boolean is an enumeration type, check google, and you'll find periodic 
discussions in c.l.a concerning "extensionable" enumeration types:

type Four_State_Logical is new Boolean with (Uncertain, Contradictory);

Here you are!

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<b5nhiq$29oaug$2@ID-77047.news.dfncis.de>...
>Amir Yantimirov wrote:
>> Oops. Sorry. Anyway, the idea is type functionality may be extended
>> freely so it don't have to be specified in type declaration.

> If nothing specified then nothing can be checked at compile time. There are 
> languages like SmallTalk for this, they have their place, but of little 
> interest. Because the real challenge is: to check as much as possible, 
> giving up as little as we can.

Not that. I propose something alike this:

type TFoo = record ... end record;

procedure Bar ( Baz : in out TFoo);
  with TFoo:
    'First = 1;
    'Last = 32;
    [].Read = ReadBits;
    [].Write = WriteBits;
  end with;
begin
  Baz[40] := 0; -- compile error!

> > Fine. But what's the gain? I rarely needs any _polymorphic_ feature
> > for such types above "this type is distinct four-byte thing".
> 
> And what is lost? You need no class-wide objects? Declare them specific!
> 
> BTW, Boolean is an enumeration type, check google, and you'll find periodic 
> discussions in c.l.a concerning "extensionable" enumeration types:
> 
> type Four_State_Logical is new Boolean with (Uncertain, Contradictory);

Different levels of abstraction needs different solutions. So I argue
only that ALL types should be tagged.

Amir Yantimirov
http://www174.pair.com/yamir/programming/

Re: Imitation is the sincerest form of flattery

[Frank J. Lhota]

"Amir Yantimirov" <amir@iae.nsk.su> wrote in message
news:5115eb96.0303242148.57027600@posting.google.com...

> Not that. I propose something alike this:
>
> type TFoo = record ... end record;
>
> procedure Bar ( Baz : in out TFoo);
>   with TFoo:
>     'First = 1;
>     'Last = 32;
>     [].Read = ReadBits;
>     [].Write = WriteBits;
>   end with;
> begin
>   Baz[40] := 0; -- compile error!

I'm a little confused by this pseudo-code. Is Bar a derived type? Is it some
sort of constructor? And what does the "[].Write = WriteBits;" statement do?
You may very well have a quite valuable idea here, but this code sample does
not convey it. Now that you have piqued our curiousity, please clarify.

> Different levels of abstraction needs different solutions. So I argue
> only that ALL types should be tagged.

In a sense, you're absolutely right. The most consistent way to do OOP is to
allow a type hierarchy to be based on any type, including built-in scalar
types. An example of this is the Smalltalk language. Everything in Smalltalk
is part of a class hierarchy, including boolean values, integers,
characters, and even blocks of code. Smalltalk's consistent "everything is
an object" approach is elegant and provides unparalleled ability to apply
OOP techniques.

There is only one good reason, why Ada, C++, C# and Java have not adapted
the Smalltalk philosophy of having everything tagged: efficiency. Smalltalk,
for all of its virtues, has been terribly slow due to its need to use
indirection for nearly everything. Consider this:

    type My_Integer is new Integer;
    function "+" ( Left, Right : in My_Integer ) return My_Integer;
    function "*" ( Left, Right : in My_Integer ) return My_Integer;
    -- ...

    -- Currently not valid Ada, but this would be valid if Integer is
tagged.
    procedure Compute( A, B : in Integer'Class ) is
    begin
        -- ...
    end Compute;

Within Compute, arithmetic with A and B will depend on whether they are
Integer or My_Integer. As desirable as this may be, this certainly rules out
using the implicit versions of "+" and "*". A call to Compute would require
that, somehow, tags be attached to A and B. This requirement is why we have
the annoying boxing and unboxing stuff in C#.

If there is a way to get the effect of tagged scalar types without a big hit
on efficiency, however, it would certainly be helpful. Perhaps there is some
happy compromise between Smalltalk and C#.

Re: Imitation is the sincerest form of flattery

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> If there is a way to get the effect of tagged scalar types without a big hit
> on efficiency, however, it would certainly be helpful.

Well, I think efficiency per se is irrelevant to language design.
What matters is distributed overhead -- you don't want to pay
an efficiency cost for features you don't use.

If a feature is useful, then presumably implementers will implement it
in the most efficient way that's reasonable.  It doesn't make sense to
leave out a feature purely because it is inherently slow -- if it's
useful, then programmers will have to implement it themselves, and it
will *still* be slow.  It makes sense to leave out a feature if it makes
*other* features slower than they would otherwise need to be.

So the question is whether a language can provide extensible scalars
with dispatching calls without slowing code that doesn't need that
power.  I think the answer is yes: don't store the tag with every
object.  Instead, gin it up when calling a class-wide operation.
So "+" on normal (non-class-wide) integers can be a single machine
instruction, and integers can be stored as a single word.  The compiler
can determine when to gin up a tag -- no need for explicit boxing
operations.

- Bob

Re: Imitation is the sincerest form of flattery

[Frank J. Lhota]

You've got some very good points. Slow code is inefficient only if it is
unnecessarily slow, and the Ada paradigm of using class-wide programming
only when the programmer requests it should allow the quick implicit
operations to be used in all appropriate cases. Also, I believe that there
are changes that could be made to make the Ada treatment of scalars more OO.

For starters, many of the attributes should be functions, e.g. instead of
having the Attributes

    function Integer'Pred( X : Integer ) return Integer;
    function Integer'Max( X, Y : Integer ) return Integer;
    -- etc.

I wish that we had the following functions defined in the Standard package:

    function Pred( X : Integer ) return Integer;
    function Max( X, Y : Integer ) return Integer;
    -- etc.

This would allow the programmer to re-define any of these attributes for
types derived from Integer (or other predefined types).

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Frank J. Lhota wrote:

> I wish that we had the following functions defined in the Standard
> package:
> 
>     function Pred( X : Integer ) return Integer;
>     function Max( X, Y : Integer ) return Integer;
>     -- etc.
> 
> This would allow the programmer to re-define any of these attributes for
> types derived from Integer (or other predefined types).

True, but it is a very long way to go. For example, to have 'Max 
dispatching, you would immediately need true multiple dispatch - it has two 
parameters!

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b5qcnq$2bshmf$1@ID-77047.news.dfncis.de...
> Frank J. Lhota wrote:
>
> > I wish that we had the following functions defined in the Standard
> > package:
> >
> >     function Pred( X : Integer ) return Integer;
> >     function Max( X, Y : Integer ) return Integer;
> >     -- etc.
> >
> > This would allow the programmer to re-define any of these attributes for
> > types derived from Integer (or other predefined types).
>
> True, but it is a very long way to go. For example, to have 'Max
> dispatching, you would immediately need true multiple dispatch - it has
two
> parameters!

AFAIK (and my testing seems to confirm this) if we have the function

     function Max( X, Y : An_Integer_Type ) return An_Integer_Type;

defined in the same package as An_Integer_Type, and if we derive a type
New_Integer from An_Integer_Type, i.e.

    type New_Integer is new An_Integer_Type;

then New_Integer inherits Max from An_Integer_Type, i.e. there is an
implicit function

     function Max( X, Y : New_Integer ) return New_Integer;

that the programmer can either call or replace with his own version.

Multiple dispatching would only be an issue if we wanted to generate a
version of Max that compares and / or returns different integer types. By
the very nature of the Max function, we are unlikely to even want to do
that. This is not to dismiss the utility of multiple dispatching, but
unfortunately most OOPL's avoid it because of efficiency concerns.

Re: Imitation is the sincerest form of flattery

[Pascal Obry]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> AFAIK (and my testing seems to confirm this) if we have the function
> 
>      function Max( X, Y : An_Integer_Type ) return An_Integer_Type;
> 
> defined in the same package as An_Integer_Type, and if we derive a type
> New_Integer from An_Integer_Type, i.e.
> 
>     type New_Integer is new An_Integer_Type;
> 
> then New_Integer inherits Max from An_Integer_Type, i.e. there is an
> implicit function

That's right. An Ada feature often forgotten...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Thu, 27 Mar 2003 19:45:42 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:b5qcnq$2bshmf$1@ID-77047.news.dfncis.de...
>> Frank J. Lhota wrote:
>>
>> > I wish that we had the following functions defined in the Standard
>> > package:
>> >
>> >     function Pred( X : Integer ) return Integer;
>> >     function Max( X, Y : Integer ) return Integer;
>> >     -- etc.
>> >
>> > This would allow the programmer to re-define any of these attributes for
>> > types derived from Integer (or other predefined types).
>>
>> True, but it is a very long way to go. For example, to have 'Max
>> dispatching, you would immediately need true multiple dispatch - it has
>two
>> parameters!
>
>AFAIK (and my testing seems to confirm this) if we have the function
>
>     function Max( X, Y : An_Integer_Type ) return An_Integer_Type;
>
>defined in the same package as An_Integer_Type, and if we derive a type
>New_Integer from An_Integer_Type, i.e.
>
>    type New_Integer is new An_Integer_Type;
>
>then New_Integer inherits Max from An_Integer_Type, i.e. there is an
>implicit function
>
>     function Max( X, Y : New_Integer ) return New_Integer;
>
>that the programmer can either call or replace with his own version.

This is absolutely another story. type A is new B, "clones" types. The
result is a new type which is same as B. From this point of view Max
is not inherited by New_Integer. Consider:

X : Integer;
Y : New_Integer;

Max (X, Y); -- Illegal!

Should Max be inherited Max (X, Y) would be legal.

BTW it is pitty that type cloning is not allowed for tagged types. IMO
this restriction should be removed.

>Multiple dispatching would only be an issue if we wanted to generate a
>version of Max that compares and / or returns different integer types. By
>the very nature of the Max function, we are unlikely to even want to do
>that.

My point is *IF*:

1. Inheritance has to be supported for all types in the sense that
Integer'Class might refer to descendants of Integer

2. The attributes has to be declared as primitive operations

Then you have to support MD for all attributes with several arguments.

So 'Max would be declared as:

   function 'Max (Left, Right : Integer) return Integer'Class;


There is no other choice. The present situation when tags of both
arguments has to be same is unsatisfactory. It is not so bad now,
because the tagged types are too heavy (passed by reference, have
embedded tag) to use them for representation of numeric things. There
binary operations are very common. Should you make OO available there,
this will become a problem:

   function 'Max (Left : Integer; Right : Integer'Class)
      return Integer'Class;

+ manual dispatch on Right is awful!

>This is not to dismiss the utility of multiple dispatching, but
>unfortunately most OOPL's avoid it because of efficiency concerns.

There are many problems with MD, but I do not think that efficiency is
a big issue. It will probably cost one indirection more.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Frank J. Lhota]

It is not entirely clear how multiple dispatch would work with a function
such as Max. Consider this version of the function:

    -- Assuming Integer is tagged and MD is allowed
    function Max (Left, Right : Integer'Class) return Integer'Class is
    begin
        if Left < Right then
            return Right;
        else
            return Left;
        end if;
    end Max;

Now assume we have the following declarations:

    type X_Integer is new Integer;
    -- Specialized version of "<" for X_Integer ...
    function "<" ( Left, Right : in X_Integer ) return Boolean;
    X : X_Integer;

    type Y_Integer is new Integer;
    -- Specialized version of "<" for Y_Integer ...
    function "<" ( Left, Right : in Y_Integer ) return Boolean;
    Y : Y_Integer;

Within Max( X, Y ), which version of "<" is used?

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On Tue, 01 Apr 2003 14:38:08 GMT, "Frank J. Lhota"
<NOSPAM.lhota.adarose@verizon.net> wrote:

>It is not entirely clear how multiple dispatch would work with a function
>such as Max. Consider this version of the function:
>
>    -- Assuming Integer is tagged and MD is allowed
>    function Max (Left, Right : Integer'Class) return Integer'Class is
>    begin
>        if Left < Right then

I assume that "<" has to be MD and declared as:

   function "<" (Left, Right : Integer) return Boolean;

Here is the first problem. It cannot be a primitive operation of
Boolean, which is also "tagged". So it should to be:

   function "<" (Left, Right : Integer) return Boolean'Class;

But this is potentially inefficient because Boolean'Class is a large
object as compared with Boolean. It has the type tag. Probably one
should allow an explicit specification of contravariant /
non-dispatching parameters / results. Sort of:

   function "<" (Left, Right : Integer) return Boolean'Base;

Here the result is contravariant/non-dispatching.

>            return Right;
>        else
>            return Left;
>        end if;
>    end Max;
>
>Now assume we have the following declarations:
>
>    type X_Integer is new Integer;

I assume that this is actually

   type X_Integer is new Integer with null record;

>    -- Specialized version of "<" for X_Integer ...
>    function "<" ( Left, Right : in X_Integer ) return Boolean;

At the freezing point of X_Integer the compiler has to cry out: you
have overridden

   function "<" (Left, Right : X_Integer) return Boolean'Base;

so you have to do it for

   function "<" (Left : Integer; Right : X_Integer)
      return Boolean'Base;

and

   function "<" (Left : X_Integer; Right : Integer)
      return Boolean'Base;

Otherwise, it is not clear how to deal with:

X : Integer;
Y : X_Integer;
...
X < Y

One should probably allow something like

   function "<" (Left : X_Integer; Right : Integer)
      return Boolean'Base renames Integer."<";

>    X : X_Integer;
>
>    type Y_Integer is new Integer;
>    -- Specialized version of "<" for Y_Integer ...
>    function "<" ( Left, Right : in Y_Integer ) return Boolean;
>    Y : Y_Integer;
>
>Within Max( X, Y ), which version of "<" is used?

With siblings it becomes even worse. A solution as above, to require
that all possible combinations of parameter types be overriden, is
hard to imagine. X_Integer and Y_Integer might be declared in
different compilation units, so the error could appear only when the
units are with-ed. Freezing points passed. Nothing can be done. Full
stop.

Alternatives are:

1. It dispatches to Integer.">". I.e. it dispatches to the most
specific common base type.

2. It causes Constraint_Error. No dispatch on siblings.

Both are unsatisfactory in my view. There are indeed problems with MD.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccn0jjv1jo.fsf@shell01.TheWorld.com>...
> "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
> 
> > If there is a way to get the effect of tagged scalar types without a big hit
> > on efficiency, however, it would certainly be helpful.

<snip>

> So the question is whether a language can provide extensible scalars
> with dispatching calls without slowing code that doesn't need that
> power.  I think the answer is yes: don't store the tag with every
> object.  Instead, gin it up when calling a class-wide operation.
> So "+" on normal (non-class-wide) integers can be a single machine
> instruction, and integers can be stored as a single word.  The compiler
> can determine when to gin up a tag -- no need for explicit boxing
> operations.
> 
> - Bob

Exactly. Only in my C++ head it is sounds as "address of particular
interface dispatch routine" instead of "tag". :)

http://www174.pair.com/yamir/programming/interfaces.htm

Amir Yantimirov

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On 25 Mar 2003 23:48:40 -0800, amir@iae.nsk.su (Amir Yantimirov)
wrote:

>Exactly. Only in my C++ head it is sounds as "address of particular
>interface dispatch routine" instead of "tag". :)

Which is not the same. Tag is not an address of a routine. In C++ it
might be a pointer to a list of such addresses. But even this becomes
wrong in case of multiple dispatch. That's when the dispatch table of
a routine is mutli-dimensional and tags have to be mapped to the
indices of the table.

The point is that because Ada differentiates X / access X and X'Class
/ access X'Class types it is possible (*) to strip the tag away from a
specific object or pointer. Thus to make a type "tagged" would cost
absolutely nothing as long as no class-wide objects / pointers and
routines are used.

(*) If redispatch would be disallowed someday.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Amir Yantimirov]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<6Y_fa.5102$kU.534@nwrdny01.gnilink.net>...
> "Amir Yantimirov" <amir@iae.nsk.su> wrote in message
> news:5115eb96.0303242148.57027600@posting.google.com...
> 
> > Not that. I propose something alike this:
> >
> > type TFoo = record ... end record;
> >
> > procedure Bar ( Baz : in out TFoo);
> >   with TFoo:
> >     'First = 1;
> >     'Last = 32;
> >     [].Read = ReadBits;
> >     [].Write = WriteBits;
> >   end with;
> > begin
> >   Baz[40] := 0; -- compile error!
> 
> I'm a little confused by this pseudo-code. Is Bar a derived type? Is it some
> sort of constructor? And what does the "[].Write = WriteBits;" statement do?
> You may very well have a quite valuable idea here, but this code sample does
> not convey it. Now that you have piqued our curiousity, please clarify.

It is a poor attempt to show how can looks addition of array interface
with fixed index bounds (so compiler can do range check) to already
defined type and inside some scope (procedure Bar). I never used Ada
and attempt to make example looks Ada-like only adds confusion.

The previous poster wrote that extending of type interface exist only
in dynamic languages as Smalltalk and don't allow compile time checks
and I tried to show that (theoretically) compiler is capable to do
this statically if necessary information is provided.

More of that here:
http://www174.pair.com/yamir/programming/interfaces.htm

In a short, I think it is a serious restriction that we use one
language construct (type/class) for description of two completely
different things - concrete information storage and abstract behaviour
interface.

Amir Yantimirov

Re: Imitation is the sincerest form of flattery

[Matthew Heaney]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<p2vi7vs64p33mpnbsfsn43cvh72l44tm95@4ax.com>...
> 
> To inherit the type interface. For example, an array type implemented
> by a record type:
> 
>    -- This is not Ada!
>    type Unbounded_String is
>       private array (Integer range <>) of Character;
> 
> private
>    type Unbounded_String is record
>       ...
>    end record;
>    -- Definition of implemented abstract array opeartions follows


Can't you do this?

package P is

   type Unbounded_String (<>) is private;

private

   type Unbounded_String is
     array (Positive range <>) of Character;

end P;

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

On 20 Mar 2003 15:28:17 -0800, mheaney@on2.com (Matthew Heaney) wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<p2vi7vs64p33mpnbsfsn43cvh72l44tm95@4ax.com>...
>> 
>> To inherit the type interface. For example, an array type implemented
>> by a record type:
>> 
>>    -- This is not Ada!
>>    type Unbounded_String is
>>       private array (Integer range <>) of Character;
>> 
>> private
>>    type Unbounded_String is record
>>       ...
>>    end record;
>>    -- Definition of implemented abstract array opeartions follows
>
>Can't you do this?
>
>package P is
>
>   type Unbounded_String (<>) is private;
>
>private
>
>   type Unbounded_String is
>     array (Positive range <>) of Character;
>
>end P;

This would be a private type implemented by an array, but not an array
implemented by some other type.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>package P is
:>
:>   type Unbounded_String (<>) is private;
:>
:>private
:>
:>   type Unbounded_String is
:>     array (Positive range <>) of Character;
:>
:>end P;
: 
: This would be a private type implemented by an array, but not an array
: implemented by some other type.

Where will this leed coders and readers? If I understand correctly,
what you want is an option to have objects with array access (attributes
etc.) that need not be arrays, privately. The same for other "ADTs"
that are provided by the language. That is, an option to override the
compilers regular job?

I'd prefer considering a rule that said, 'No arrays at all, please,
in specs!' :-)

In Eiffel, the basic types can be extended, and you can have
a sparse matrix derived from an ARRAY2, if you want to provide
your own implementation details, I think.

If, for a moment, you do not insist on arrays being suitable ADTs
for public access in specs, you can do that in Ada too, of course.
(With tagged types or with formal generics describing the "array like"
interface, which is not possible in Eiffel other than using FUNCTION
types(?), afaics.)

Re: Imitation is the sincerest form of flattery

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> :>package P is
> :>
> :>   type Unbounded_String (<>) is private;
> :>
> :>private
> :>
> :>   type Unbounded_String is
> :>     array (Positive range <>) of Character;
> :>
> :>end P;
> : 
> : This would be a private type implemented by an array, but not an array
> : implemented by some other type.
> 
> Where will this leed coders and readers? If I understand correctly,
> what you want is an option to have objects with array access (attributes
> etc.) that need not be arrays, privately. The same for other "ADTs"
> that are provided by the language. That is, an option to override the
> compilers regular job?

When it is necessary. For example:

   type Handle is private access Object;
private :
   type Handle is record ...; -- A fat smart pointer implementation

With full ADT supported, the compiler might become even more lightweighted, 
because many things could be then moved to libraries. At least when one 
sees the invasion of gemetrically exploding Wide**N x {Unbounded | Bounded 
| Fixed} Strings...

> I'd prefer considering a rule that said, 'No arrays at all, please,
> in specs!' :-)

Well, the number of predefined interfaces (ADT) can be reduced. However, an 
array thing is a very fundamental concept which has its place. Array in 
specification should only mean that you can index, get slice, have 
aggregates, get bounds. String is definitely an array.

> In Eiffel, the basic types can be extended, and you can have
> a sparse matrix derived from an ARRAY2, if you want to provide
> your own implementation details, I think.

Yes, this is IMO a good approach, as opposed to C++'s riddle game: I wrote 
something, go figure out where it might fit.

However "extension" is a wrong word. Implementation of an interface is not 
an "extension". The language may have a sort of universal array type. The 
predefined array types and user-defined ones have to be derived from it and 
then cloned (by "type X is new Y;"):

   type My_Array is array ...;

a short cut for

   type <anonymous> is new Universal_Array with ...;
   type My_Array is new <anonymous>;

> If, for a moment, you do not insist on arrays being suitable ADTs
> for public access in specs, you can do that in Ada too, of course.
> (With tagged types or with formal generics describing the "array like"
> interface, which is not possible in Eiffel other than using FUNCTION
> types(?), afaics.)

If arrays are not suitable for specifications, then why the language has 
them? It is not a very good idea to have two different languages for 
specifications and implementation. At least because this separation is by 
no means absolute.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Imitation is the sincerest form of flattery

[AG]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:b5h8se$2a6gme$1@ID-77047.news.dfncis.de...
> Georg Bauhaus wrote:
>
> > Where will this leed coders and readers? If I understand correctly,
> > what you want is an option to have objects with array access (attributes
> > etc.) that need not be arrays, privately.

Yes. I've raised that point before too. Even more importantly (imho) is
that they may be real arrays. And the index may be a simple integer-thing,
and the compiler knows all the details etc etc. But, you can't have array
semantics unless you commit to some [visible] index type which should
not be there.

> > that are provided by the language. That is, an option to override the
> > compilers regular job?
>
> When it is necessary. For example:

Let me present another (even if a bit artificial) example:

Suppose you are trying to write a chess program (of all things :-)
You want to represent the board as ... well, what?
0 to 63 linear range? or 8 by 8 two-dimensional?

Can't say right now - need to think and try and make some mistakes
probably. However, it would be nice to hide the indexing inside
the package and be able to do things like  'range  *no matter how that
index is implemented*. Should be up to the implementor really - if it
can't be done, so be it. But if it's possible, why would the user care
about flat 0 to 63 or 8 by 8 convention?

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

AG <ang@xtra.co.nz> wrote:
: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
: 
:> > that are provided by the language. That is, an option to override the
:> > compilers regular job?
:>
:> When it is necessary. For example:
: 
: the package and be able to do things like  'range  *no matter how that
: index is implemented*. Should be up to the implementor really - if it
: can't be done, so be it. 

I trust compiler writers have their reasons for Ada arrays :)
(I vaguely remember an example by Tucker Taft where he showed how
you can have the effect of non-contigous indices, if that is of
interest here.)

Re: Imitation is the sincerest form of flattery

[AG]

"Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message
news:b5hv8e$m60$3@a1-hrz.uni-duisburg.de...
> AG <ang@xtra.co.nz> wrote:

> : the package and be able to do things like  'range  *no matter how that
> : index is implemented*. Should be up to the implementor really - if it
> : can't be done, so be it.
>
> I trust compiler writers have their reasons for Ada arrays :)

Well, yes, of course, I don't doubt that. However, from the point
of view of the language user it means that if you do need (or want)
array indexing like that you have to do it by hand, loose language
support in the process and generally obscure things (which seems
to run contrary to the language philosophy :-)

> (I vaguely remember an example by Tucker Taft where he showed how
> you can have the effect of non-contigous indices, if that is of
> interest here.)

Do you mean implemented by hand as an application code or
supported by the language? If later, I would be interested in
a reference please.

Re: Imitation is the sincerest form of flattery

[Vinzent Hoefler]

"AG" <ang@xtra.co.nz> wrote:

[arrays with index "holes"]
>Do you mean implemented by hand as an application code or
>supported by the language? If later, I would be interested in
>a reference please.

|type Enum is (One, Five, Six);
|for Enum use (One => 1, Five => 5, Six => 6);
|
|type Lookup is array(Enum'Range) of ...

Something like that?


Vinzent.

Re: Imitation is the sincerest form of flattery

[AG]

"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote in message
news:b5ilma$27ungi$1@ID-175126.news.dfncis.de...
"AG" <ang@xtra.co.nz> wrote:

[arrays with index "holes"]
>Do you mean implemented by hand as an application code or
>supported by the language? If later, I would be interested in
>a reference please.

|type Enum is (One, Five, Six);
|for Enum use (One => 1, Five => 5, Six => 6);
|
|type Lookup is array(Enum'Range) of ...

Something like that?

Well, no. Of course not. That's representation
clauses. I believe there were some threads in
this NG before about rep clauses for enums
being next to useless but that's not the point
in this case What I had in mind would be
something like:

[Somewhere in package spec:]

type x is limited private;
type y is array(x) of x;

-- Of, course, need to provide operations on x here:

"+"
"-"
'range

etc

Implementing them may be trivial or not.
But it's neither here nor there - can't
do the first part of the declaration anyway.

Re: Imitation is the sincerest form of flattery

[Robert A Duff]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> I'd prefer considering a rule that said, 'No arrays at all, please,
> in specs!' :-)

Then you must be annoyed to see type String declared as an array in a
package visible part -- in fact, the most visible visible part of all.
;-)

- Bob

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Robert A Duff <bobduff@shell01.theworld.com> wrote:
: Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:
: 
:> I'd prefer considering a rule that said, 'No arrays at all, please,
:> in specs!' :-)
: 
: Then you must be annoyed to see type String declared as an array in a
: package visible part -- in fact, the most visible visible part of all.
: ;-)

Bounded_String and Unbounded_String are private;-)

-- Georg 

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Georg Bauhaus wrote:
>      class LI extends LinkedList<Integer> {}
>      class LB extends LinkedList<Byte> {}

This just demonstrates that Java generics are
second-class citizens. They're just a hidden
version of the casting that needs to be done
now.

Re: Imitation is the sincerest form of flattery

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:>      class LI extends LinkedList<Integer> {}
:>      class LB extends LinkedList<Byte> {}
: 
: This just demonstrates that Java generics are
: second-class citizens. They're just a hidden
: version of the casting that needs to be done
: now.

Depends. If you wanted a list iterator for
LI, the information about what is in an LI isn't readily
available, as it is in List<Integer>. So, indeed, how does
one know that there should be a Iterator<Integer> type?
OTOH, you won't need casting if you know the hidden type
in LI ...

(I have to use them, absent a decent alternative ;-)

A related question (for me) is,
how does one implement nth with List as opposed to List<Any>
when there is just a generic List? So, in Java you can
have both generic and non-generic List interfaces, transparently.
And implement chaos :-)

Re: Imitation is the sincerest form of flattery

[Florian Weimer]

Hyman Rosen <hyrosen@mail.com> writes:

> what they don't tell you is that in the Java generics the type
> parameters can't be fundamental types, only Object-derived ones

The same is true for C# generics.  Look at the signatures extension
for C++, and you'll see where they get the idea.

Obivously, efficient implementation is a prime concern.  Using this
model, you get shared generics essentially for free.

Re: Imitation is the sincerest form of flattery

[Hyman Rosen]

Florian Weimer wrote:
> The same is true for C# generics.

The cited site specifically refutes this; C# generics may be instantiated
with fundamental types, and then the system actually generates code which
inlines the operations.

> Obivously, efficient implementation is a prime concern.  Using this
> model, you get shared generics essentially for free.

And they do use that for Object-derived types, but they do what I said
as well.

Re: Imitation is the sincerest form of flattery

[Florian Weimer]

"Robert C. Leif" <rleif@rleif.com> writes:

> Microsoft is imitating Ada generics in its proposed next version of C#.

It looks a lot like the C++ signatures extension.  I don't think this
hasn't got to do much with C++ templates or Ada generics.