comp.lang.ada
 help / color / mirror / Atom feed
* Why no abstract non-tagged types?
@ 2014-02-21  3:04 Britt
  2014-02-21  8:33 ` Dmitry A. Kazakov
  2014-02-24 23:12 ` Shark8
  0 siblings, 2 replies; 6+ messages in thread
From: Britt @ 2014-02-21  3:04 UTC (permalink / raw)


Recently I've been wishing I could declare some otherwise conventional enumeration types as "abstract" so they could only be used as a template for derived types.
Such abstract types couldn't be used directly for object declarations.  For example:

   type Valve_State_Base_Type is abstract (Unknown, Open, Closed);  -- in Ada 202X

   Valve_State : Valve_State_Base_Type;  -- illegal, type is abstract

   type Vent_Valve_State_Type is new Valve_State_Base_Type;  -- a legal derivation

   Vent_Valve_State : Vent_Valve_State_Type;  -- a legal object declaration

I think subtypes of such an abstract type should be implicitly abstract as well:

   subtype Valve_Cmd_Base_Type is Valve_State_Base_Type range Open .. Closed;

   Valve_Cmd : Valve_Cmd_Base_Type;  -- illegal,  base type is abstract

   subtype Vent_Valve_Cmd_Type is Vent_Valve_State_Type range Open .. Closed;

   Vent_Valve_Cmd : Vent_Valve_Cmd_Type;  -- legal

Perhaps this has been asked before but I couldn't find an earlier discussion. Is there any reason why the "abstract" concept couldn't be extended to enumeration and other non-tagged types in Ada 202X?

- Britt

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Why no abstract non-tagged types?
  2014-02-21  3:04 Why no abstract non-tagged types? Britt
@ 2014-02-21  8:33 ` Dmitry A. Kazakov
  2014-02-26 18:52   ` Dan'l Miller
  2014-02-24 23:12 ` Shark8
  1 sibling, 1 reply; 6+ messages in thread
From: Dmitry A. Kazakov @ 2014-02-21  8:33 UTC (permalink / raw)


On Thu, 20 Feb 2014 19:04:08 -0800 (PST), Britt wrote:

> Recently I've been wishing I could declare some otherwise conventional
> enumeration types as "abstract" so they could only be used as a template
> for derived types.

Abstract enumeration is a different thing. That is when elements of the
enumeration are abstract primitive operations as well as T'Pos, T'Val etc
to be defined by derived implementation types.

> Such abstract types couldn't be used directly for object declarations.  For example:
> 
>    type Valve_State_Base_Type is abstract (Unknown, Open, Closed);  -- in Ada 202X

Why not:

   type Valve_State_Base_Type is [abstract] private;  -- Legal Ada
[  function Unknown return Valve_State_Base_Type is abstract;
   function Open return Valve_State_Base_Type is abstract;
   function Closed return Valve_State_Base_Type is abstract; ]

>    type Vent_Valve_State_Type is new Valve_State_Base_Type;  -- a legal derivation

Classes of scalar and by-value types is my no.1 wish for Ada 20XX. That
would cover enumerations as well.

It will never happen, I am afraid.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Why no abstract non-tagged types?
  2014-02-21  3:04 Why no abstract non-tagged types? Britt
  2014-02-21  8:33 ` Dmitry A. Kazakov
@ 2014-02-24 23:12 ` Shark8
  1 sibling, 0 replies; 6+ messages in thread
From: Shark8 @ 2014-02-24 23:12 UTC (permalink / raw)


On Thursday, February 20, 2014 8:04:08 PM UTC-7, Britt wrote:
> Recently I've been wishing I could declare some otherwise conventional enumeration types as "abstract" so they could only be used as a template for derived types.
> 
> Such abstract types couldn't be used directly for object declarations.  For example:
> 
>    type Valve_State_Base_Type is abstract (Unknown, Open, Closed);  -- in Ada 202X
> 
>    Valve_State : Valve_State_Base_Type;  -- illegal, type is abstract

You already have this ability in Ada... in fact you've had it since Ada 83:

Generic
Package Abstract_Enumeration is
  Type Enumeration is (Value_1, Value_2, Value_3, Value_4, Value_5);
End Abstract_Enumeration;

If you WITH Abstract_Enumeration you cannot directly use Abstract_Enumeration.Enumeration, you need to instantiate it first:

Package Enums is new Abstract_Enumeration;
Package Other_Enums is new Abstract_Enumeration;

Defines two instances of Enumeration, one fore Enums and another for Other_Enums, although they have the same names they are incompatible w/o type-casting.

-----
[More recent Ada-specs]
If you wanted something like subtypes, you could have a generic something like:

Generic
  with Package AE is new Abstract_Enumeration(<>);
  First : AE.Enumeration := AE.Enumeration'First;
  Last  : AE.Enumeration := AE.Enumeration'Last;
Package Enumeration_Subtype is
  Subtype Enumeration_Subtype is AE.Enumeration range First..Last; 
End Enumeration_Subtype;


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Why no abstract non-tagged types?
  2014-02-21  8:33 ` Dmitry A. Kazakov
@ 2014-02-26 18:52   ` Dan'l Miller
  2014-02-26 20:55     ` Dmitry A. Kazakov
  2014-02-26 21:40     ` Eryndlia Mavourneen
  0 siblings, 2 replies; 6+ messages in thread
From: Dan'l Miller @ 2014-02-26 18:52 UTC (permalink / raw)


Please give some Ada202X mock-up of precisely what by-value types and scalar classes would wisely enable that are inexpressible throughout Ada2012.  This is a two-part request:  1) explicitly, the proposed feature/syntax and 2) implicitly, the claim that no portion of Ada2012 can be utilized to accomplish that feature adequately with a different syntax (e.g., counter-claim:  another branch of this thread shows that generic enumerations sufficiently accomplish the OP's desired abstract enumerations, hence obviating the need for a 2nd syntax to accomplish the desired effect).


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Why no abstract non-tagged types?
  2014-02-26 18:52   ` Dan'l Miller
@ 2014-02-26 20:55     ` Dmitry A. Kazakov
  2014-02-26 21:40     ` Eryndlia Mavourneen
  1 sibling, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2014-02-26 20:55 UTC (permalink / raw)


On Wed, 26 Feb 2014 10:52:31 -0800 (PST), Dan'l Miller wrote:

> Please give some Ada202X mock-up of precisely what by-value types and
> scalar classes would wisely enable that are inexpressible throughout
> Ada2012.

None are. See RM 6.2(5)

> This is a two-part request:  1) explicitly, the proposed feature/syntax
> and

There exist several AIs regarding extensible enumerations that could cover
abstract enumerations as well, theoretically. If you are interested you can
search for them. All were rejected, and rightfully so. In my view the
problem can be resolved only if by-value classes were supported.

> 2) implicitly, the claim that no portion of Ada2012 can be utilized to
> accomplish that feature adequately with a different syntax

Depends on the feature.

As the subject suggests, the OP wished abstract non-tagged types. That
requires the type tag not stored in the type specific object (non-tagged =
no tag). Naturally, the tag must be present in the class-wide object in
order to support dispatch to the implementations of abstract operations
(abstract type has abstract operations).

This would make it possible (as a prerequisite) to have classes of by-value
types, such as enumerations.

> (e.g.,
> counter-claim:  another branch of this thread shows that generic
> enumerations sufficiently accomplish the OP's desired abstract
> enumerations, hence obviating the need for a 2nd syntax to accomplish the
> desired effect).

Generics cannot implement abstract enumeration, per definition of abstract
type, see RM 3.9.3(1/2).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Why no abstract non-tagged types?
  2014-02-26 18:52   ` Dan'l Miller
  2014-02-26 20:55     ` Dmitry A. Kazakov
@ 2014-02-26 21:40     ` Eryndlia Mavourneen
  1 sibling, 0 replies; 6+ messages in thread
From: Eryndlia Mavourneen @ 2014-02-26 21:40 UTC (permalink / raw)


On Wednesday, February 26, 2014 12:52:31 PM UTC-6, Dan'l Miller wrote:
> Please give some Ada202X mock-up of precisely what by-value types and scalar classes would wisely enable that are inexpressible throughout Ada2012.

Would something like the following work for you?

    package Abstract_Color is
       type Color is (Red, Green, Blue);
       package Literal is
          function Red   return Color is abstract;
          function Green return Color is abstract;
          function Blue  return Color is abstract;
       end Literal;
    end Abstract_Color;

Then, you can reference Abstract_Color.Literal.Red, etc.

You also can make it generic, as Shark suggested.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-02-26 21:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-21  3:04 Why no abstract non-tagged types? Britt
2014-02-21  8:33 ` Dmitry A. Kazakov
2014-02-26 18:52   ` Dan'l Miller
2014-02-26 20:55     ` Dmitry A. Kazakov
2014-02-26 21:40     ` Eryndlia Mavourneen
2014-02-24 23:12 ` Shark8

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox