Re: EXTERNAL: Re: [vhdl-200x] Modular types

On Fri, 2014-06-27 at 19:21 +0000, Jones, Andy D wrote:
> Brian,
> 
> It is no more, and no less, true in Ada and VHDL.
[snip]
>INTEGER does not "inherit" UNIVERSAL_INTEGER operators.
> Per the LRM, as soon as I define a new type with an integer range, 
> I automatically get the operators and subprograms that are defined 
> for UNIVERSAL_INTEGER, implicitly redefined, exclusively for my type. 

Thank you for correcting my sloppy wording.

> I do not get implicitly defined operators and subprograms that are 
> compatible between my type and INTEGER, and I do not get implicit 
> compatibility with operators defined (implicitly or explicitly) 
> for type INTEGER! I have to define those myself.

Right, and that was what I wasn't getting. As I thought, defining a
modular type automatically defines operators on the type itself. 

But if I now understand, your objection is that interoperation with
other types (such as Integer) requires either explicit conversions (with
Tristan's caveats about their semantics) or the user to define
overloaded operators such as those between numeric_std and integer.

If such operations were automatically defined for us, that would breach
type safety. And as Tristan points out, there are problems pressing the
resolution mechanism into service to help.

Perhaps as an alternative, the standard library could provide a generic
package, accepting two numeric types, providing the set of operators
required to interoperate between them. Then having declared a new type,
I can choose either to maintain type safety, or instantiate this package
and relax type safety.

> This is also why we have subtypes, rather than just defining new types with 
> different ranges, because we want compatibility with the infrastructure 
> already defined for the base type.

Now that raises a separate question : what is the meaning of a subtype
of a modular type? It is compatible with its base type, but does it
retain the original modulus or is that adjusted to the subtype range?

I have not investigated what Ada does here. (I think it has to retain
the original modulus, and wrap to 0, both values possibly being out of
the subtype's range)

> The question is, do we want a new type, with its own, duplicative infrastructure,
>  or do we want a way to use INTEGERs with an automatic, modulo behavior?

Remaining close to the original language where practical is also the Ada
way. Yet modular types were added in 1995, and the ramifications don't
seem to have been too serious. It might be an easier change than
significantly reworking the syntax of existing Integers without breaking
anything.

- Brian

> Before we run off and change the language, let's see if we can get what we want easily enough with the existing language. That's the VHDL way, not the SystemVerilog way.
> 
> Andy D Jones
> Electrical Engineering
> Lockheed Martin Missiles and Fire Control
> Dallas TX
> 
> 
> 
> 
> 
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brian Drummond
> Sent: Thursday, June 26, 2014 4:03 PM
> To: vhdl-200x@eda.org
> Subject: EXTERNAL: Re: [vhdl-200x] Modular types
> 
> On Thu, 2014-06-26 at 20:23 +0000, Jones, Andy D wrote:
> > I think we're in a pickle with a modular type, since operators would have to be declared for every different type declared..
> 
> If we're following the Ada model, surely this is no more true than when we declare a new integer type. As a new Integer inherits the operators on Universal_Integer, modular types inherit their own set of operators.
> 
> Where do resolution functions come into this at all?
> 
> Or perhaps I am misunderstanding in a big way...
> 
> - Brian
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> 
> 



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.