user-defined type conversion

user-defined type conversion

[Russ]

I am experimenting with a simple type system for physical units.
Suppose, for example, I have types for inches and feet, and I wish to
write an explicit conversion:

type inches is new float;
type feet is new float;

function inches ( arg: feet ) return inches is
    begin
    return inches ( 12.0 * float(feet) );
    end inches;

The problem is that I am not allowed to use the name inches for the
conversion function because it is already used for the type name. It
seems that the name should be overloadable for both the type and the
conversion function. Is there any way around this?

Re: user-defined type conversion

[martin.m.dowie]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0205182344.3602f20a@posting.google.com...
> I am experimenting with a simple type system for physical units.
> Suppose, for example, I have types for inches and feet, and I wish to
> write an explicit conversion:
>
> type inches is new float;
> type feet is new float;
>
> function inches ( arg: feet ) return inches is
>     begin
>     return inches ( 12.0 * float(feet) );
>     end inches;
>
> The problem is that I am not allowed to use the name inches for the
> conversion function because it is already used for the type name. It
> seems that the name should be overloadable for both the type and the
> conversion function. Is there any way around this?

Common approaches I've seen over the years are:

1. Change the name of the function to "To_Inches"
2. Change the type name to "An_Inch" or "Inches_Type"

Re: user-defined type conversion

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Russ" <18k11tm001@sneakemail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 2:44 AM
Subject: user-defined type conversion


<snip>
 The problem is that I am not allowed to use the name inches for the
> conversion function because it is already used for the type name. It
> seems that the name should be overloadable for both the type and the
> conversion function. Is there any way around this?

No, because a type conversion has the same syntax as a function, so
there's no way to "read the programmer's mind," as to what he intended.

The ususl way to do this is to name the conversion function with a
leading "To_", e.g., To_Inches.
 

Re: user-defined type conversion

[Russ]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021805103.320.comp.lang.ada@ada.eu.org>...
> ----- Original Message ----- 
> From: "Russ" <18k11tm001@sneakemail.com>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: May 19, 2002 2:44 AM
> Subject: user-defined type conversion
> 
> 
> <snip>
>  The problem is that I am not allowed to use the name inches for the
> > conversion function because it is already used for the type name. It
> > seems that the name should be overloadable for both the type and the
> > conversion function. Is there any way around this?
> 
> No, because a type conversion has the same syntax as a function, so
> there's no way to "read the programmer's mind," as to what he intended.

Type conversion IS a function! It seems to me that I should be able to
do it the same way it is done for the built-in types (float, integer,
etc.). C++ allows that nicely.

> The ususl way to do this is to name the conversion function with a
> leading "To_", e.g., To_Inches.

Re: user-defined type conversion

[sk]

Hi, 
18k11tm001@sneakemail.com (Russ) :
>type inches is new float;
>type feet is new float;

>function inches ( arg: feet ) return inches is
>    begin
>    return inches ( 12.0 * float(feet) );
>    end inches;

...

> Type conversion IS a function! ...

You are dealing with two different conversions, a type
conversion and a "units" conversion.

The other problem is Float(Feet), do you mean Float(Arg) ?

function To_inches ( arg: feet ) return inches is
begin
    return 
        Inches (           -- Type conversion
            12.0 * Arg     -- Unit conversion
        );
end To_inches;

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: user-defined type conversion

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Russ" <18k11tm001@sneakemail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 19, 2002 1:29 PM
Subject: Re: user-defined type conversion


<snip>
> Type conversion IS a function! It seems to me that I should be able to
> do it the same way it is done for the built-in types (float, integer,
> etc.). C++ allows that nicely.
> 
With all due respect, the word "function" does not appear at all in
section 4.6 (Type Conversions) in the LRM, so I'm not sure one can
truthfully make the blanket statement "Type conversion IS a function!"

Going back to your original code, you had:
type inches is new float;
type feet is new float;

function inches ( arg: feet ) return inches is
    begin
    return inches ( 12.0 * float(feet) );
    end inches;

First, one cannot multiply a type name by a number, so if we assume that
you meant to write
    return inches (12.0 * float(arg));
what we have is an argument of type Standard.Float (the result of the
multiplication) as the argument of a type conversion to the type Inches.

This type conversion differs from a function in that it will accept any
numeric expression (Integer, Float, Fixed, etc.) whereas a function
requires an argument of the specific type with which it was declared.

Thus, the conversion of arg to float is ineffectual in an expression
used as the argument of a type conversion to Inches, since any numeric
expression will do.

Since this is the case, overloading will not work, because an argument
of type feet is _required_ for the function Inches, and is _legal_ for
the type conversion Inches, hence overloading would be ambiguous.

I hope I have clarified the matter -- i.e. why a type conversion is
_not_ a function -- because its argument type is not fixed.

Re: user-defined type conversion

[Jeffrey Carter]

Russ wrote:
> 
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021805103.320.comp.lang.ada@ada.eu.org>...
> > No, because a type conversion has the same syntax as a function, so
> > there's no way to "read the programmer's mind," as to what he intended.
> 
> Type conversion IS a function!

Are you sure? Given

type Real is new Float;

F : Float;
R : Real;

a statement such as

R := Real (F);

probably has no code generated for the type conversion. No function
call, no inline expansion, nothing.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: user-defined type conversion

[Jeffrey Carter]

Russ wrote:
> 
> type inches is new float;
> type feet is new float;
> 
> function inches ( arg: feet ) return inches is
>     begin
>     return inches ( 12.0 * float(feet) );
>     end inches;

Assuming you meant Arg rather than Feet in the return statement, it
appears that this function attempts infinite recursion. This confusion
among the multiple meanings of "inches" might be part of why the
language does not allow this.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: user-defined type conversion

[Russ]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CE81644.D3B7CE25@acm.org>...
> Russ wrote:
> > 
> > type inches is new float;
> > type feet is new float;
> > 
> > function inches ( arg: feet ) return inches is
> >     begin
> >     return inches ( 12.0 * float(feet) );
> >     end inches;
> 
> Assuming you meant Arg rather than Feet in the return statement, it
> appears that this function attempts infinite recursion. This confusion
> among the multiple meanings of "inches" might be part of why the
> language does not allow this.

Yes, I meant "arg" rather than "feet", and I don't think it's an
infinite resursion. The "inches" function takes a "feet" argument,
whereas the call of "inches" within it takes a "float" argument.
That's two different functions.

I still don't see why I shouldn't be able to make my own type/unit
conversion that has the same simple syntax as the built-in type
conversions. Until I do, I consider it a minor deficiency of the
language.

Re: user-defined type conversion

[Russ]

sk <noname@myob.com> wrote in message news:<mailman.1021834982.12823.comp.lang.ada@ada.eu.org>...
> Hi, 
> 18k11tm001@sneakemail.com (Russ) :
> >type inches is new float;
> >type feet is new float;
>  
> >function inches ( arg: feet ) return inches is
> >    begin
> >    return inches ( 12.0 * float(feet) );
> >    end inches;
> 
> ...
> 
> > Type conversion IS a function! ...
> 
> You are dealing with two different conversions, a type
> conversion and a "units" conversion.
> 
> The other problem is Float(Feet), do you mean Float(Arg) ?

Yes.

> function To_inches ( arg: feet ) return inches is
> begin
>     return 
>         Inches (           -- Type conversion
>             12.0 * Arg     -- Unit conversion
>         );
> end To_inches;

The reason I meant to use "12.0 * float(arg)" rather than simply "12.0
* arg" is so that I avoid an infinite recursion (using the function
name "inches", the same as the type name).

It should work fine that way, except that Ada doesn't allow the same
name to be used for a type and a function. I contend that there is no
inherent reason that it shouldn't. I don't see how it is possible for
the compiler to confuse a type with a function. If Ada allowed that, I
could write my own type/unit conversions that have the same syntax as
built-in type conversions.

Re: user-defined type conversion

[Jeffrey Carter]

Russ wrote:
> 
> Yes, I meant "arg" rather than "feet", and I don't think it's an
> infinite resursion. The "inches" function takes a "feet" argument,
> whereas the call of "inches" within it takes a "float" argument.
> That's two different functions.

I thought you were trying to write a type conversion to complement or
replace the existing type conversion "inches". Type conversions of this
sort may have a value of any numeric type as the argument, so clearly
your user-defined equivalent must behave the same way, leading to
infinite recursion.

One cannot consider a numeric type declaration as declaring a number of
overloaded functions with the same name as the type and parameters of
every other numeric type because one can apply type conversions to
numeric types not known at the point of the declaration.

> I still don't see why I shouldn't be able to make my own type/unit
> conversion that has the same simple syntax as the built-in type
> conversions. Until I do, I consider it a minor deficiency of the
> language.

I don't see why I can't define subprograms in terms of pattern matching.
I don't see why I can't define new operators. I don't see why I can't
write natural English and have the Ada compiler generate appropriate
code. Are these deficiencies of Ada or of my understanding?

There are many features that it would be nice for Ada to have. The
ability to have user-defined type conversions with the same name as a
type is one of them. It's difficult to have a consistent language
definition that allows this and all the good things that Ada does allow,
so the language designers do not allow it.

Of course, you can define a function with the same name as the type in a
different declarative region, but you won't be able to refer to both the
type and the function in the same scope without a prefix on at least one
of them.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail

Re: user-defined type conversion

[Russ]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021892102.6644.comp.lang.ada@ada.eu.org>...
> ----- Original Message ----- 
> From: "Russ" <18k11tm001@sneakemail.com>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: May 19, 2002 10:25 PM
> Subject: Re: user-defined type conversion
> 
> 
> <snip>
> > Yes, I meant "arg" rather than "feet", and I don't think it's an
> > infinite resursion. The "inches" function takes a "feet" argument,
> > whereas the call of "inches" within it takes a "float" argument.
> > That's two different functions.
> >
> As has been pointed out, the call of "inches" within takes an argument of
> _any numeric type_, not just float, and it is this which makes the call
> ambiguous.
>  
> > I still don't see why I shouldn't be able to make my own type/unit
> > conversion that has the same simple syntax as the built-in type
> > conversions. Until I do, I consider it a minor deficiency of the
> > language.
> Do you understand now?

Yes, I understand now. But I think Ada should have been designed to
first check for a user-defined type conversion before using a
compiler-generated conversion. That would solve the ambiguity problem
and allow users to create their own type/unit conversions with the
same syntax as built-in type conversions. That, in turn, would allow
developers to create simple and elegant type/unit system for each
particular application.

Re: user-defined type conversion

[Randy Brukardt]

Russ <18k11tm001@sneakemail.com> wrote in message ...
>It should work fine that way, except that Ada doesn't allow the same
>name to be used for a type and a function. I contend that there is no
>inherent reason that it shouldn't. I don't see how it is possible for
>the compiler to confuse a type with a function. If Ada allowed that, I
>could write my own type/unit conversions that have the same syntax as
>built-in type conversions.

I had this same idea for Ada 200y back in January and proposed it to the
ARG. It was discussed extensively on Ada-Comment. It doesn't work (too
incompatible), it isn't going to happen. To read why, look at the AC for
it:
    http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AC-00026.TXT

           Randy Brukardt
           ARG Editor

Re: user-defined type conversion

[David C. Hoos]

----- Original Message ----- 
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, May 20, 2002 2:27 PM
Subject: Re: user-defined type conversion
<snip>
> I had this same idea for Ada 200y back in January and proposed it to the
> ARG. It was discussed extensively on Ada-Comment. It doesn't work (too
> incompatible), it isn't going to happen. To read why, look at the AC for
> it:
>     http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AC-00026.TXT
> 
The correct link is
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00026.TXT

Re: user-defined type conversion

[Dmitry A. Kazakov]

On Sun, 19 May 2002 21:12:56 GMT, Jeffrey Carter <jrcarter@acm.org>
wrote:

>Russ wrote:
>> 
>> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021805103.320.comp.lang.ada@ada.eu.org>...
>> > No, because a type conversion has the same syntax as a function, so
>> > there's no way to "read the programmer's mind," as to what he intended.
>> 
>> Type conversion IS a function!
>
>Are you sure? Given
>
>type Real is new Float;
>
>F : Float;
>R : Real;
>
>a statement such as
>
>R := Real (F);
>
>probably has no code generated for the type conversion. No function
>call, no inline expansion, nothing.

So what? A function that does nothing is still a function. More
interesting is the following:

   procedure Increment (X : in out Float);
   I : Integer := 1;
begin
   Increment  (Float (I));

Here Float is a pair of functions: To_Float and From_Float and
Increment  (Float (..)) is a composition:

To_Float o Increment o From_Float

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

Re: user-defined type conversion

[Dmitry A. Kazakov]

On Mon, 20 May 2002 06:21:24 GMT, Jeffrey Carter <jrcarter@acm.org>
wrote:

>One cannot consider a numeric type declaration as declaring a number of
>overloaded functions with the same name as the type and parameters of
>every other numeric type because one can apply type conversions to
>numeric types not known at the point of the declaration.

Yes, but there is a question, why one should need that conversions? I
see only backward compatibility issues here. It is clear why it was
good for Ada 83, but it is IMO a bit outdated for Ada 0x. A better way
would be an explicitly instantiatable function like
Unchecked_Conversion or even just Unchecked_Conversion.

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

Re: user-defined type conversion

[Dmitry A. Kazakov]

On 20 May 2002 12:26:06 -0700, 18k11tm001@sneakemail.com (Russ) wrote:

>Yes, I understand now. But I think Ada should have been designed to
>first check for a user-defined type conversion before using a
>compiler-generated conversion. That would solve the ambiguity problem
>and allow users to create their own type/unit conversions with the
>same syntax as built-in type conversions. That, in turn, would allow
>developers to create simple and elegant type/unit system for each
>particular application.

In short Ada should support user-defined type conversions and apply
them implicitly. I.e. new [sub]types should be defined in terms of
type conversions rather than representation. That would be nice, but
it would require a complete language redesign.

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

Re: user-defined type conversion

[Russ]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0205201126.572c9f09@posting.google.com>...
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1021892102.6644.comp.lang.ada@ada.eu.org>...
> > ----- Original Message ----- 
> > From: "Russ" <18k11tm001@sneakemail.com>
> > Newsgroups: comp.lang.ada
> > To: <comp.lang.ada@ada.eu.org>
> > Sent: May 19, 2002 10:25 PM
> > Subject: Re: user-defined type conversion
> > 
> > > I still don't see why I shouldn't be able to make my own type/unit
> > > conversion that has the same simple syntax as the built-in type
> > > conversions. Until I do, I consider it a minor deficiency of the
> > > language.
> > Do you understand now?
> 
> Yes, I understand now. But I think Ada should have been designed to
> first check for a user-defined type conversion before using a
> compiler-generated conversion. That would solve the ambiguity problem
> and allow users to create their own type/unit conversions with the
> same syntax as built-in type conversions. That, in turn, would allow
> developers to create simple and elegant type/unit system for each
> particular application.

After reading the replies here and thinking about it a bit more, I
have come to the conclusion that it is not such a great idea after all
to have user-defined type conversions with the same syntax as built-in
conversions.

The problem is that it is error prone. I could carelessly try to
invoke my user-defined conversion on a type that I have not defined it
for, and the compiler would not be able to detect the error (because
it would just use the built-in conversion).

There's hope for me after all.