runtine instanciation

runtine instanciation

[Immanuel Scholz]

Hello again,

In Ada, can create a class at runtime? Like the getClass().forClass() in 
Java.

As example create a variable from the type entered by the user at runtime.


Immanuel Scholz

Re: runtine instanciation

[Simon Wright]

Immanuel Scholz <news@kutzsche.net> writes:

> Hello again,
> 
> In Ada, can create a class at runtime? Like the getClass().forClass() in 
> Java.
> 
> As example create a variable from the type entered by the user at runtime.

No, though of course you can pre-program a Factory to do this.

Re: runtine instanciation

[Dmitry A.Kazakov]

Immanuel Scholz wrote:

> Hello again,
> 
> In Ada, can create a class at runtime? Like the getClass().forClass() in
> Java.
> 
> As example create a variable from the type entered by the user at runtime.

I am not sure what you want, but I suppose that Ada.Streams is what you 
need. In short it allows you to create a class-wide object from some 
external source (like user input) without a factory. Or better to say the 
factory is distributed over the implementations of 'Input/'Read attributes.

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

RE: runtine instanciation

[Robert C. Leif]

From: Bob Leif
To: Dmitry Kazakov et al.
I suspect that in many cases there is a very straightforward approach to
accomplish the equivalent of runtime instantiation. In my own work on
the creation of a new bioinformatics standard, CytometryML, I have a
requirement to create an array of records, which can have up to 15
fields. Each of the data types for the fields (parameters) will be
represented by a compiled package with a complete set of specific
operations. However, the user (customer) at runtime will have the
prerogative of selecting from 1 to 15 of these parameters to include in
the record. Fortunately, this is directly analogous to the creation of
the data type in a database. It does NOT have to occur instantaneously.
Conceivably, the user could wait about a minute for this to occur. I
would like to be able to compile and link the instantiation of the
record and the array. Parenthetically, I am quite willing, if need be,
to precompile 15 generic packages of records, which have from one to
fifteen fields and instantiate only one of them. The 15 generic records
perhaps could also be included in one package.

Another similar problem, is to create a calculation program in Ada that
is very general for evaluating a mathematical expression. If the
expression can be converted to an Ada function, why not just compile it?

I believe Rational and DEC had incremental compilers. Could this
facility be made available, even in a space inefficient form, in one of
the Ada 95 compilers? This approach has a significant potential
commercial benefit for the vendors. It would require a runtime version
of their compilers, which could be licensed for a fee to be ultimately
paid by the end users of the program.

Before any of the real-time enthusiasts become upset by this proposal,
please remember, that this is not to be applied to the run-time
operations of mission critical applications where execution time and
scheduling are important.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Dmitry A.Kazakov
Sent: Sunday, June 16, 2002 4:07 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: runtine instanciation

Immanuel Scholz wrote:

> Hello again,
> 
> In Ada, can create a class at runtime? Like the getClass().forClass()
in
> Java.
> 
> As example create a variable from the type entered by the user at
runtime.

I am not sure what you want, but I suppose that Ada.Streams is what you 
need. In short it allows you to create a class-wide object from some 
external source (like user input) without a factory. Or better to say
the 
factory is distributed over the implementations of 'Input/'Read
attributes.

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

RE: runtine instanciation

[Dmitry A.Kazakov]

Robert C. Leif wrote:

> From: Bob Leif
> To: Dmitry Kazakov et al.
> I suspect that in many cases there is a very straightforward approach to
> accomplish the equivalent of runtime instantiation. In my own work on
> the creation of a new bioinformatics standard, CytometryML, I have a
> requirement to create an array of records, which can have up to 15
> fields. Each of the data types for the fields (parameters) will be
> represented by a compiled package with a complete set of specific
> operations. However, the user (customer) at runtime will have the
> prerogative of selecting from 1 to 15 of these parameters to include in
> the record. Fortunately, this is directly analogous to the creation of
> the data type in a database. It does NOT have to occur instantaneously.
> Conceivably, the user could wait about a minute for this to occur. I
> would like to be able to compile and link the instantiation of the
> record and the array. Parenthetically, I am quite willing, if need be,
> to precompile 15 generic packages of records, which have from one to
> fifteen fields and instantiate only one of them. The 15 generic records
> perhaps could also be included in one package.
> 
> Another similar problem, is to create a calculation program in Ada that
> is very general for evaluating a mathematical expression. If the
> expression can be converted to an Ada function, why not just compile it?
> 
> I believe Rational and DEC had incremental compilers. Could this
> facility be made available, even in a space inefficient form, in one of
> the Ada 95 compilers? This approach has a significant potential
> commercial benefit for the vendors. It would require a runtime version
> of their compilers, which could be licensed for a fee to be ultimately
> paid by the end users of the program.
> 
> Before any of the real-time enthusiasts become upset by this proposal,
> please remember, that this is not to be applied to the run-time
> operations of mission critical applications where execution time and
> scheduling are important.

Well, if performance is not an issue, why not to use class-wide objects 
instead of genericity? Doing so you would not need to instantiate anything. 
In fact no automatic instantiation would help if the types are unknown in 
advance. A brute force, like an integrated compiler might help, but I think 
it would be better to advance ADT to solve problems like that. [ Those who 
disagree may just switch to SmallTalk. (:-)) ]

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

RE: runtine instanciation

[Robert C. Leif]

From: Bob Leif
To: Dmitry Kazakov et al.
1) I do not believe that sacrificing the reliability of the entire
program by switching to SmallTalk is a reasonable solution.

2) Even if I create a tagged type for my record, I still have to fill
its fields. As I previously stated, the allowable data types and their
methods have been previously compiled. I realize that one could use
access types. However, I am hoping for a very simple static solution
based on the use of the compiler. I believe that this is now well within
the capabilities of the combination of modern Ada compilers and our PCs,
which now have capabilities well beyond those envisaged by the original
creators and users of Ada. I ran RR on an 8088 based 4.88 megahertz PC
with I believe 256 K of RAM. I now, in order to run COTs products, have
a computer with half a Gig of RAM and a 1.6 Gigahertz CPU. The bus width
has now been expanded from 1 to 4 or 8 bytes. I suspect that the linker
technology is the part that may have to be modified.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Dmitry A.Kazakov
Sent: Monday, June 17, 2002 3:04 PM
To: comp.lang.ada@ada.eu.org
Subject: RE: runtine instanciation

Robert C. Leif wrote:

> From: Bob Leif
> To: Dmitry Kazakov et al.
> I suspect that in many cases there is a very straightforward approach
to
> accomplish the equivalent of runtime instantiation. In my own work on
> the creation of a new bioinformatics standard, CytometryML, I have a
> requirement to create an array of records, which can have up to 15
> fields. Each of the data types for the fields (parameters) will be
> represented by a compiled package with a complete set of specific
> operations. However, the user (customer) at runtime will have the
> prerogative of selecting from 1 to 15 of these parameters to include
in
> the record. Fortunately, this is directly analogous to the creation of
> the data type in a database. It does NOT have to occur
instantaneously.
> Conceivably, the user could wait about a minute for this to occur. I
> would like to be able to compile and link the instantiation of the
> record and the array. Parenthetically, I am quite willing, if need be,
> to precompile 15 generic packages of records, which have from one to
> fifteen fields and instantiate only one of them. The 15 generic
records
> perhaps could also be included in one package.
> 
> Another similar problem, is to create a calculation program in Ada
that
> is very general for evaluating a mathematical expression. If the
> expression can be converted to an Ada function, why not just compile
it?
> 
> I believe Rational and DEC had incremental compilers. Could this
> facility be made available, even in a space inefficient form, in one
of
> the Ada 95 compilers? This approach has a significant potential
> commercial benefit for the vendors. It would require a runtime version
> of their compilers, which could be licensed for a fee to be ultimately
> paid by the end users of the program.
> 
> Before any of the real-time enthusiasts become upset by this proposal,
> please remember, that this is not to be applied to the run-time
> operations of mission critical applications where execution time and
> scheduling are important.

Well, if performance is not an issue, why not to use class-wide objects 
instead of genericity? Doing so you would not need to instantiate
anything. 
In fact no automatic instantiation would help if the types are unknown
in 
advance. A brute force, like an integrated compiler might help, but I
think 
it would be better to advance ADT to solve problems like that. [ Those
who 
disagree may just switch to SmallTalk. (:-)) ]

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

Re: runtine instanciation

[Robert I. Eachus]

Robert C. Leif wrote:


> 2) Even if I create a tagged type for my record, I still have to fill
> its fields. As I previously stated, the allowable data types and their
> methods have been previously compiled. I realize that one could use
> access types. However, I am hoping for a very simple static solution
> based on the use of the compiler...


I am going to discuss this from a language lawyer viewpoint, so first I 
need to point out that in Ada, compile-time and link-time are some 
amorphous concepts dealing with time before the environment task is 
created, and static is a concept that has nothing to do with 
compile-time vs. run-time, but with error-checking requirements.  So be 
warned.

First, declaring a heterogenous tagged data type with up to fifteen 
potentially different compontents is not all that difficult in Ada.  In 
fact, in this case I actually prefer a more Ada 83ish solution:


type Field is (Name_Field, Address_Field, ...);

type Field_Set is array Field of Boolean;

type Field_Index is range 1..Field'Last + 1;

type Field_Record(F: Field) is record
   case F is... end case; end record;

type Field_Wrapper is record R: Field_Record; end record;

type Field_Array is array (Field_Index range <>) of Field_Wrapper;

type DB_Record (Fields: Field_Set) is record
   FA: Field_Array; end record;

A lot of gratutitous seeming declarations there, but the net result is 
that you can create a record containing any subset of the fifteen 
potentially different fields at run-time. Some compilers, notably Alsys 
went to a lot of trouble to create decent data structures to support 
such objects--but that is a compiler issue not a language issue.

However, as I understand your concerns, you don't want the field 
definitions wrapped up all in one place.  What I would do is create a 
data structure something like:

type Field_Name is (Name_Field, Address_Field, ...);

type Field (Name: Field_Name) is abstract tagged...;

type Field_Pointer is access all Field;

type Data_Record is array(Field) of Field_Pointer;
-- These only exist in memory, and then only when working with actual
-- records.  So having a fixed array size with meaningful indexes will 
-- probably shrink code size more than any additional memory usage for
-- active structures of this type.

Now when you read from the database, your routines unpack the records 
and fill in the correct access values.  Fields not used by that record 
will contain null pointers, and you should be able to get to and from a 
decent disk storage format with 'Read and 'Write.

Each field type can have its own dll, and users can redefine these as 
they will.  But please, if you are going to do this while the program is 
executing, remember the two primary rules about such records from Multics:

     1) Any record type that is subject to change shall have a version 
number in the record format.  This allows newly linked routines to tell 
if they are looking at the old or new format for any record.

     2) All persistant record types are subject to change. ;-)

RE: runtine instanciation

[Dmitry A.Kazakov]

Robert C. Leif wrote:

> From: Bob Leif
> To: Dmitry Kazakov et al.
> 1) I do not believe that sacrificing the reliability of the entire
> program by switching to SmallTalk is a reasonable solution.

It was just a joke, sorry. (:-))

> 2) Even if I create a tagged type for my record, I still have to fill
> its fields. As I previously stated, the allowable data types and their
> methods have been previously compiled. I realize that one could use
> access types. However, I am hoping for a very simple static solution
> based on the use of the compiler. I believe that this is now well within
> the capabilities of the combination of modern Ada compilers and our PCs,
> which now have capabilities well beyond those envisaged by the original
> creators and users of Ada. I ran RR on an 8088 based 4.88 megahertz PC
> with I believe 256 K of RAM. I now, in order to run COTs products, have
> a computer with half a Gig of RAM and a 1.6 Gigahertz CPU. The bus width
> has now been expanded from 1 to 4 or 8 bytes. I suspect that the linker
> technology is the part that may have to be modified.

In your example types are known, so at least theoretically there is no need 
to do anything dynamically. Robert Eacus showed that in his post.

But if you really-really want full sized dynamic instantiations etc, you 
must in the first place allow things like:

type X is tagged ...;
procedure Foo (A : X);
...
declare
   type Y is new X with ...; -- New derived type
   procedure Foo (A : Y) is ... -- Overrides X's Foo
begin
   ...
end;
-- All side effects gone

It is not easy to do. You must dynamically modify dispatch tables and other 
internal structures (Ada.Tags.Internal_Tag). There would be utterly nasty 
things:

type X is tagged ...;
type X_Ptr is access all X'Class;
procedure Foo (A : X);
...
declare
   Nasty : X_Ptr;
begin
   declare
      type Y is new X with ...;
      procedure Foo (A : Y) is ...
   begin
      Nasty := new Y;
   end;
   Foo (Nasty.all); -- Oops!
end;

I'd liked to have that, but how to avoid all possible pitfalls?

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

Re: runtine instanciation

[Antonio Duran]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aehr7g$716kk$1@ID-77047.news.dfncis.de>...
> Immanuel Scholz wrote:
> 
> > Hello again,
> > 
> > In Ada, can create a class at runtime? Like the getClass().forClass() in
> > Java.
> > 
> > As example create a variable from the type entered by the user at runtime.
> 
> I am not sure what you want, but I suppose that Ada.Streams is what you 
> need. In short it allows you to create a class-wide object from some 
> external source (like user input) without a factory. Or better to say the 
> factory is distributed over the implementations of 'Input/'Read attributes.

I'm not a Java expert I think that Java construct allows you to
provide the name of a .class file (or a jar) that was not binded to
your application at compile time, when you call that method, the
virtual machine searches the CLASSPATH and if the .class (or .jar) is
found they are loaded and binded to your application. This is not
supported by any Ada language construct.

That dynamic loading is a nice to have feature but has some problems.
For example, if you have more than one version of that class there is
the possibility of loading the wrong one.

Retrieving a persistent object by using Ada.Streams allows you to
create an object that was previously saved but the packages that
contain the code for that class must be previously compiled and linked
into your application. That is also true for C and C++.

You can achive dynamic object loading by using object models like COM
or CORBA (assuming the existence of support for these models as Ada
libraries). For example, COM provides support for dynamic object
loading (CreateObject) through what they call 'late binding'.
Registering a component attach a class name (or identification) to a
DLL, the DLL is brought to memory when CreateObject is invoked and by
employing an introspection mechanism the application is able to know
what are the properties, methods and events in the class and the
infraestructure provides support for dynamic dispatching function
calls (through RPC mechanisms) to the DLL functions. I think CORBA
works, more or less, in a similar way.

    Antonio Duran