* Re: Dynamic type system for Ada
2017-01-24 13:58 ` Victor Porton
@ 2017-01-24 14:26 ` Dmitry A. Kazakov
2017-01-24 18:07 ` Jeffrey R. Carter
2017-01-24 21:21 ` Randy Brukardt
2 siblings, 0 replies; 15+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-24 14:26 UTC (permalink / raw)
On 24/01/2017 14:58, Victor Porton wrote:
> It seems that you didn't understood me.
You should have asked about data definition layer, not type then. Types
have operations.
> All I ask is just an Ada type which would be so flexible that could store
> any kind of a value (just like as a variable in a dynamic language).
Task value, protected object value, a value from generic instance not
yet instantiated, subprogram value?
In languages you have in mind there are types which can be used that way
and not-so-much-types which cannot.
> This type could be a variant record which could store numbers, lists/arrays,
> strings, etc. (anything that can be stored in a variable in a dynamic
> language).
Then you should have asked about a variant type of some predefined set
of scalar types and predefined class of containers. It has little use in
Ada.
As an implementation consider stream attributes. For a stream take a
memory-located stream. Yes it is implemented in Ada. It has almost no
use because Ada lacks things I listed. You cannot hang an interface on a
stream object in order to access the object stored in the stream in the
same way the original type is accessed (AKA dynamic cast, AKA
polymorphic object). For this the stream object must inherit the
interface of the type it contains, and do that ad-hoc. Variant record
types do the job (dynamic cast is performed by variant selection per
discriminant), but they are very very limited in what they can do.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-24 13:58 ` Victor Porton
2017-01-24 14:26 ` Dmitry A. Kazakov
@ 2017-01-24 18:07 ` Jeffrey R. Carter
2017-01-24 21:21 ` Randy Brukardt
2 siblings, 0 replies; 15+ messages in thread
From: Jeffrey R. Carter @ 2017-01-24 18:07 UTC (permalink / raw)
On 01/24/2017 02:58 PM, Victor Porton wrote:
>
> All I ask is just an Ada type which would be so flexible that could store
> any kind of a value (just like as a variable in a dynamic language).
You might want to look at type System.Storage_Elements.Storage_Array (ARM
13.7.1). You can (unchecked) convert most values to and from a Storage_Array of
the correct size. Package Ada.Storage_IO (ARM A.9) makes it easy to do so for
definite, unlimited types.
--
Jeff Carter
"It is the German who is so uncourteous to his verbs."
A Scandal in Bohemia
122
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-24 13:58 ` Victor Porton
2017-01-24 14:26 ` Dmitry A. Kazakov
2017-01-24 18:07 ` Jeffrey R. Carter
@ 2017-01-24 21:21 ` Randy Brukardt
2017-01-24 22:01 ` J-P. Rosen
` (2 more replies)
2 siblings, 3 replies; 15+ messages in thread
From: Randy Brukardt @ 2017-01-24 21:21 UTC (permalink / raw)
"Victor Porton" <porton@narod.ru> wrote in message
news:o67mi7$v0f$1@gioia.aioe.org...
...
> All I ask is just an Ada type which would be so flexible that could store
> any kind of a value (just like as a variable in a dynamic language).
>
> This type could be a variant record which could store numbers,
> lists/arrays,
> strings, etc. (anything that can be stored in a variable in a dynamic
> language).
I'd suggest that it be defined as an abstract tagged type, with each of the
other kinds of things as a derived tagged type (one for holding integers,
one for holding floats, etc.). Then one could get a "variable that could
hold anything" by instantiating the Unbounded_Holder container (and that
would open uses of the other kinds of containers as well). That way, the
package wouldn't have to reinvent all of the memory management stuff that's
already in the containers. Plus, if one organized the hierarchy similar to
the chart in 3.2(12)
[http://www.ada-auth.org/standards/2xrm/html/RM-3-2.html#p12], you could
define shared operations at the appropriate levels to have some use beyond
just plain storage. (For instance, all of the numeric types would have math
this way.)
I do wonder how useful such a hierarchy would be, but I suppose someone
would have to build it to find out.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-24 21:21 ` Randy Brukardt
@ 2017-01-24 22:01 ` J-P. Rosen
2017-01-25 8:23 ` Dmitry A. Kazakov
2017-01-25 8:38 ` Georg Bauhaus
2 siblings, 0 replies; 15+ messages in thread
From: J-P. Rosen @ 2017-01-24 22:01 UTC (permalink / raw)
Le 24/01/2017 à 22:21, Randy Brukardt a écrit :
> I do wonder how useful such a hierarchy would be
Presumably, you'll need that if you write an interpreter for a
dynamically typed language in Ada...
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-24 21:21 ` Randy Brukardt
2017-01-24 22:01 ` J-P. Rosen
@ 2017-01-25 8:23 ` Dmitry A. Kazakov
2017-01-25 21:55 ` Randy Brukardt
2017-01-25 8:38 ` Georg Bauhaus
2 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2017-01-25 8:23 UTC (permalink / raw)
On 24/01/2017 22:21, Randy Brukardt wrote:
> I do wonder how useful such a hierarchy would be, but I suppose someone
> would have to build it to find out.
Not much. I did exactly this before.
The problem is that you get the "god-class" in the end. In order to be
able to re-interpret the value as a given scalar type you have to add a
primitive operation to the abstract base. E.g.
function As_Unsigned_32 (Value : Abstract_Variable)
return Unsigned_32 is abstract;
-- Raises Type_Error if not of the type
And so for each scalar type. And for arrays and records.
Otherwise you have to explicitly convert (upcast) to specific instance
derived from Abstract_Variable which is much worse.
P.S. I intended to use that on top of a stream exchange, but the
interface is so heavy that it adds no advantage to direct reading the
target object from the stream.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-25 8:23 ` Dmitry A. Kazakov
@ 2017-01-25 21:55 ` Randy Brukardt
0 siblings, 0 replies; 15+ messages in thread
From: Randy Brukardt @ 2017-01-25 21:55 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:o69n9s$ogk$1@gioia.aioe.org...
> On 24/01/2017 22:21, Randy Brukardt wrote:
>
>> I do wonder how useful such a hierarchy would be, but I suppose someone
>> would have to build it to find out.
>
> Not much. I did exactly this before.
>
> The problem is that you get the "god-class" in the end. In order to be
> able to re-interpret the value as a given scalar type you have to add a
> primitive operation to the abstract base. E.g.
>
> function As_Unsigned_32 (Value : Abstract_Variable)
> return Unsigned_32 is abstract;
> -- Raises Type_Error if not of the type
>
> And so for each scalar type. And for arrays and records.
I'd probably put such routines higher in the hierarchy (the above would
appear under "Root_Numeric", for instance), but you are correct that they
are needed (and the reverse as well, to give a way to import values, esp.
literals).
And I have no idea how to deal with most user-defined types (enumerations,
records, tasks, etc.) in such a scheme. (The interface of arrays is simple
enough that I can imagine some mechanism to deal with a subset of them.)
> Otherwise you have to explicitly convert (upcast) to specific instance
> derived from Abstract_Variable which is much worse.
That's how all of my hierarchies work. I doubt that I'd call it "much
worse"; it avoids "god-classes" and allows most of the checks to be made
statically (you can't use operations of the wrong type). It's often easy to
apply those upconverts when parameter passing, so they don't end up that
wide-spread.
But I definitely agree that this is a case where there is always going to be
a "bump under the carpet" (as Tucker Taft liked to say during Ada 9x) [you
can move the bump to different places under the carpet, but you can't get
rid of it (at least without total carpet replacement, which is where this
analogy breaks down - but I digress)]. There isn't going to be a totally
clean solution.
> P.S. I intended to use that on top of a stream exchange, but the interface
> is so heavy that it adds no advantage to direct reading the target object
> from the stream.
I suspect this sort of thing would work pretty well for a hierarchy of
numeric types, not so well if other kinds of types are included. There's
just not enough overlap of operations for it to make much sense in the
general case.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dynamic type system for Ada
2017-01-24 21:21 ` Randy Brukardt
2017-01-24 22:01 ` J-P. Rosen
2017-01-25 8:23 ` Dmitry A. Kazakov
@ 2017-01-25 8:38 ` Georg Bauhaus
2 siblings, 0 replies; 15+ messages in thread
From: Georg Bauhaus @ 2017-01-25 8:38 UTC (permalink / raw)
Randy Brukardt <randy@rrsoftware.com> wrote:
> if one organized the hierarchy similar to
> the chart in 3.2(12)
> [http://www.ada-auth.org/standards/2xrm/html/RM-3-2.html#p12], you could
> define shared operations at the appropriate levels to have some use beyond
> just plain storage. (For instance, all of the numeric types would have math
> this way.)
Objective-C class clusters seem to be of a similar kind, e.g. NSNumber.
The objects can then also participate in anything based on NSObject,
basically, such as being sent in a local or remote notification
or being part of a persistent object graph.
But then, Objective-C does not have so much in terms
of Ada generics, insofar as these permit specifying private
formal types, derived or not,
to have just the operations that are needed in instances.
> I do wonder how useful such a hierarchy would be, but I suppose someone
> would have to build it to find out.
^ permalink raw reply [flat|nested] 15+ messages in thread