Re: Anybody in US using ADA ? One silly idea..

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> with templates you never know if the actual type is "Hashable",
>  > until you instantiate all functions using all methods of "Hashable".
> 
> You also don't *care* if the actual type supports all methods of
> "Hashable" if you don't use them!

What of I don't care now, might become a nightmare for somebody other 5 
years later. What is [arguable] good for C++ is inacceptable for Ada.

But the point is: you cannot rely on specifications in case of templates. 
There are no specifications [of the type set] at all. To verify the code 
using templates, you have to look into the bodies of the template 
functions.

>> And even so, nobody can say whether these methods really comprise
>  > a "Hashable" type or they just have similar names and the profiles
>  > appropriate to go through the compiler.
> 
> Nobody can say whether something that inherits from "Hashable" has
> implemented the methods correctly. For example, I could have a type
> that I think will never actually go into a hashtable but must be
> "Hashable" for some reason, so I implement its hashing method to
> just return zero. Then someone decides to put it into a table after
> all...

This is an intentionally made semantic fault, sabotage if you want. (:-))

If you do not plan to put a type into a hash table, why should it be 
"Hashable"? That is the crucial point. If someone, later decides that your 
type has to be "Hashable" it will be his responsibility to do so. My idea 
(rather a dream (:-)), is that he will be able to create a "bridge" type, 
which will be a subtype of "Hashable" and a supertype of your type. Doing 
so, he will be obliged to override the abstract hashing method of 
"Hashable".

> By the way, you might find the following link interetsing.
> <http://spirit.sourceforge.net/index.php?doc=docs/v1_5/introduction.html>
> It's a recursive descent parsing system designed using C++ template
> metaprogramming. There are a few places where the code uses inheritance
> and virtual dispatch, but only to get around C++'s limitations in naming
> a type based on an expression. The author complains about how virtual
> methods get in the way of efficient code. The problem is that we want to
> abe able to say 'declare variable = expression' and have the type of the
> variable be the type of the expression. Because C++ instantiates generics
> automatically, and as you saw in the Unit code I posted, can synthesize
> return types, it's difficult to examine an expression and write out its
> type, even though the compiler has no trouble doing so. To work around
> this, you can create a placeholder type which can hold any kind of
> expression of interest, but then this forces you into dispatch mode
> instead of generic mode. It's especially annoying because all the
> facilities are already present in the language - if you declare
> template <typename T> void func(const T &) { }, and call func(expression),
> the compiler deduces the expression type, and it's available inside func.
> But there's no way to get it out, that is, to use the same type deduction
> to declare a variable of the appropriate type, outside of the function.

Thank you for the interesting reference.

BTW another almost-have-it in C++. Let, we want subtypes having alternative 
representations, like in case Ellipse<-Cricle. C++ almost has it:

class Ellipse
{
public :
   double X;
   double Y;

   Ellipse (double X, double Y) : X (X), Y (Y) {}
};

class Circle // Not derived from Ellipse to get rid of X and Y
{
public :
   double Radius;

   Circle (double Radius)         : Radius (Radius) {}
   Circle (const Circle& Object)  : Radius (Object.Radius) {}
   Circle (const Ellipse& Object) : Radius (Object.X)
   {
      if (Radius != Object.Y) throw NotACircle;
   }
   operator Ellipse () const
   {
      return Ellipse (Radius, Radius);
   }
};

Unfortunately in most cases Circle will never be converted to Ellipse and 
back, even though the compiler has everything for that.

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