"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sj3r92$pla$3@gioia.aioe.org...
> On 2021-09-30 02:16, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:sj2008$1cmo$1@gioia.aioe.org...
>> ...
>>> Random = unrelated to the object's life time.
>>
>> All objects have to disappear before their type disappears, so the object
>> *cannot* live longer than the access type for which it is allocated from.
>
> The type of the access type /= the type of object. Only access objects
> must disappear and they do.

?? There is nothing in a pool except unorganized memory. "Objects" only
exist outside of the pool for some access type. There has to be some
organizing type, else you would never know where/when things are finalized.

>> It's probably a lousy idea to share pool objects (as opposed to pool
>> types)
>> amongst access types.
>
> You need these for access discriminants.

Those (coextensions) are one of Ada's worst ideas; they have tremendous
overhead without any value. Almost everything has to take them into account.
Yuck. Access discriminants of existing objects are OK but really don't add
anything over a component of an access type.

>> If you do have a longer lived pool and a shorter lived access type, you
>> will
>> end up with a bunch of zombie objects in the pool that cannot be used in
>> any
>> way (as any access is erroneous). All that can happen is a memory leak.
>> Don't do that.
>
> Nope, this is exactly how it works with most specialized pools, like
> arenas, stacks, reference counting pools etc.

These things don't work as pools in Ada. You need to use the subpool
mechanism to make them safe, because otherwise the objects go away before
the type (given these sorts of mechanisms generally have some sort of block
deallocation). Again, the only thing in a pool is a chunk of raw memory; the
object lives elsewhere. Subpools take care of these lifetime issues (for
controlled types, no one wanted to try to make that work for tasks).

>> OTOH, object destruction happens before the type goes away, and
>> finalization
>> happens before that. That is the point here.
>
> See above, these are different objects of different types. The actual
> object type is alive and well (unless killed by some collection).

And completely irrelevant. Allocated objects can only be deallocated from
the same type as they were allocated. So they're zombie after the type goes
away. Only use global general access types for allocation, never, ever
anything nested.

Indeed, I now believe that any nested access type is evil and mainly is
useful to cause nasty cases for compilers. I'd ban them in an Ada-like
language (that would also simplify accessibility greatly).

Randy.

On 2021-10-01 02:04, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sj3r92$pla$3@gioia.aioe.org...
>> On 2021-09-30 02:16, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:sj2008$1cmo$1@gioia.aioe.org...
>>> ...
>>>> Random = unrelated to the object's life time.
>>>
>>> All objects have to disappear before their type disappears, so the object
>>> *cannot* live longer than the access type for which it is allocated from.
>>
>> The type of the access type /= the type of object. Only access objects
>> must disappear and they do.
>
> ??

type T is range 1..2;
type P is access T;

T /= P

> There is nothing in a pool except unorganized memory. "Objects" only
> exist outside of the pool for some access type.

No the objects exist in the pool and are *accessible* via one or more
access types, some of them could even be anonymous, BTW.

> There has to be some
> organizing type, else you would never know where/when things are finalized.

Yes, and that is up to the programmer.

>>> It's probably a lousy idea to share pool objects (as opposed to pool
>>> types)
>>> amongst access types.
>>
>> You need these for access discriminants.
>
> Those (coextensions) are one of Ada's worst ideas; they have tremendous
> overhead without any value. Almost everything has to take them into account.
> Yuck. Access discriminants of existing objects are OK but really don't add
> anything over a component of an access type.

Discriminants add safety when creating objects because the language
requires initialization of. For components one have to use an aggregate
which turns extremely difficult in practical cases or even impossible.

>>> If you do have a longer lived pool and a shorter lived access type, you
>>> will
>>> end up with a bunch of zombie objects in the pool that cannot be used in
>>> any
>>> way (as any access is erroneous). All that can happen is a memory leak.
>>> Don't do that.
>>
>> Nope, this is exactly how it works with most specialized pools, like
>> arenas, stacks, reference counting pools etc.
>
> These things don't work as pools in Ada.

Yes, they normally have Deallocate as a void operation or raise an
exception.

> You need to use the subpool
> mechanism to make them safe,

I do not see how that could change anything without destroying the whole
purpose of such pools, namely nearly zero-cost allocation and deallocation.

> because otherwise the objects go away before
> the type (given these sorts of mechanisms generally have some sort of block
> deallocation).

If controlled types need to be used, which rarely happens, a bookkeeping
is added to finalize them. Instead of IMO useless subpools, one could
add some allocation bookkeeping support etc.

> Allocated objects can only be deallocated from
> the same type as they were allocated.

You can perfectly deallocate any object by erasing its pool and you can
finalize the object before doing that too. Furthermore you can use a
local access type and instantiate Unchecked_Deallocation with it. There
are many ways to skin the cat.

The language must do no baseless assumptions about programmer's intentions.

> Indeed, I now believe that any nested access type is evil and mainly is
> useful to cause nasty cases for compilers. I'd ban them in an Ada-like
> language (that would also simplify accessibility greatly).

See where collections have led you! (:-))

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sj6gmg$1n1n$1@gioia.aioe.org...
> On 2021-10-01 02:04, Randy Brukardt wrote:
....
>>> Nope, this is exactly how it works with most specialized pools, like
>>> arenas, stacks, reference counting pools etc.
>>
>> These things don't work as pools in Ada.
>
> Yes, they normally have Deallocate as a void operation or raise an
> exception.

No, they don't, because they don't work with controlled types, tasks, etc.
And there is no good way to enforce that the things you allocate into them
don't have controlled or task components. So they are unsafe unless you use
the subpool mechanism.

>> You need to use the subpool
>> mechanism to make them safe,
>
> I do not see how that could change anything without destroying the whole
> purpose of such pools, namely nearly zero-cost allocation and
> deallocation.

It ties any finalization to the subpool, so all of the contained objects get
finalized when the subpool is freed. And lets the compiler know what's
happening so it doesn't finalize the objects twice. Of course, if no
finalization is involved, it doesn't do much of anything, but that's OK,
you're prepared if any later maintenance adds finalization somewhere.

....
>> because otherwise the objects go away before
>> the type (given these sorts of mechanisms generally have some sort of
>> block
>> deallocation).
>
> If controlled types need to be used, which rarely happens, a bookkeeping
> is added to finalize them. Instead of IMO useless subpools, one could add
> some allocation bookkeeping support etc.

That's again not safe in any sense. You shouldn't need to worry about
whether some abstraction that you use uses finalization, especially as you
can't know if someone adds it later.

....
>> Indeed, I now believe that any nested access type is evil and mainly is
>> useful to cause nasty cases for compilers. I'd ban them in an Ada-like
>> language (that would also simplify accessibility greatly).
>
> See where collections have led you! (:-))

No, that's mostly because of accessibility. I'd be happy if one banned doing
any allocations with general access types (mixing global/stack allocated
objects and allocated objects is pure evil IMHO), but that would be rather
hard to enforce.

Note that nested tagged types also cause many implementation problems,
adding a lot of unnecessary overhead. I'd probably go as far as banning all
nested types (as opposed to subtypes), as types are supposed to live the
entire life of the program (possibly anonymously) and that is weird when
applied to things in nested scopes whose definition could depend on dynamic
stuff.

Randy.

On 2021-10-02 11:06, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sj6gmg$1n1n$1@gioia.aioe.org...
>> On 2021-10-01 02:04, Randy Brukardt wrote:
> ...
>>>> Nope, this is exactly how it works with most specialized pools, like
>>>> arenas, stacks, reference counting pools etc.
>>>
>>> These things don't work as pools in Ada.
>>
>> Yes, they normally have Deallocate as a void operation or raise an
>> exception.
>
> No, they don't, because they don't work with controlled types, tasks, etc.

Of course they do. E.g. with void Deallocation. When an instance of
Unchecked_Deallocation is called, the object gets properly finalized,
while the memory stays occupied in the pool until all arena is cleared.

In the case of reference counted objects finalization is done using an
instance Unchecked_Deallocation. Subpools are totally useless there.

If necessary, I use a fake pool to run Unchecked_Deallocation on it
without reclaiming any memory from the original pool.

>>> You need to use the subpool
>>> mechanism to make them safe,
>>
>> I do not see how that could change anything without destroying the whole
>> purpose of such pools, namely nearly zero-cost allocation and
>> deallocation.
>
> It ties any finalization to the subpool, so all of the contained objects get
> finalized when the subpool is freed.

Yes, and there is no need doing that in most practical scenarios. Note
also that subpool allocations need to be handled in the user code. It is
highly undesirable and error-prone. So, whatever safety you might get
from subpool's bookkeeping, you lose it at that point.

> ...
>>> because otherwise the objects go away before
>>> the type (given these sorts of mechanisms generally have some sort of
>>> block
>>> deallocation).
>>
>> If controlled types need to be used, which rarely happens, a bookkeeping
>> is added to finalize them. Instead of IMO useless subpools, one could add
>> some allocation bookkeeping support etc.
>
> That's again not safe in any sense. You shouldn't need to worry about
> whether some abstraction that you use uses finalization, especially as you
> can't know if someone adds it later.

Why compiler assisted bookkeeping is safe for subpools, but unsafe as a
stand-alone mechanism?

> ...
>>> Indeed, I now believe that any nested access type is evil and mainly is
>>> useful to cause nasty cases for compilers. I'd ban them in an Ada-like
>>> language (that would also simplify accessibility greatly).
>>
>> See where collections have led you! (:-))
>
> No, that's mostly because of accessibility. I'd be happy if one banned doing
> any allocations with general access types (mixing global/stack allocated
> objects and allocated objects is pure evil IMHO), but that would be rather
> hard to enforce.

Yes, but there is an alternative option of fixing Unchecked_Deallocation
through general access types.

> Note that nested tagged types also cause many implementation problems,
> adding a lot of unnecessary overhead.

Sure, but again. there is a paramount use case that requires dynamic
elaboration of tagged types, i.e. the relocatable libraries. You cannot
ban them and you cannot forbid tagged extensions declared in a
relocatable library. So getting rid of nesting tagged types will ease
nothing.

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

I was thinking more along the lines of adding a classwide operation on the
root storage pool type. That shouldn't change anyone's implementation
ideally. Something like:

-- Parameter is mode "in out" to allow for it to clear itself if the implementation
-- so desires
function Is_First_Allocation(Self : in out Root_Storage_Pool'Class) return Boolean;

Added to System.Storage_Pools. Allow the implementation to implement it
however they like under the hood. They could, for example, add a boolean
to the private part of the root storage pool and add a child function/package that
sets it when the compiler implementation calls for the first allocation. It can be
implemented with a count. I'm sure there are a plethora of ways.

Since the operation is classwide and it is optional, it wouldn't affect anyone's
existing storage pools. it would basically just be there to give custom
storage pool designers a hook to know when it is portably safe to add
a custom header, regardless of the number of allocations an implementation
chooses to do.

It does place the burden on the compiler implementors to call it for the first
allocation, but I can't imagine that is a huge burden with today's IDE tools?

On Tuesday, September 28, 2021 at 12:42:16 AM UTC-4, Randy Brukardt wrote:
> "Jere" <> wrote in message
> news:6a073ced-4c3b-4e87...@googlegroups.com...
> ...
> > We can't change the Allocate specification since it is what it is, but is
> > there
> > any consideration to adding functionality to the root storage pool type,
> We tried that as a solution for the user-defined dereference problem, and it
> ended up going nowhere. Your problem is different but the issues of changing
> the Storage_Pool spec remain. Not sure it could be made to work (one does
> not want to force everyone to change their existing storage pools).
>
> Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sj9blb$1srp$1@gioia.aioe.org...
> On 2021-10-02 11:06, Randy Brukardt wrote:
....
>> That's again not safe in any sense. You shouldn't need to worry about
>> whether some abstraction that you use uses finalization, especially as
>> you
>> can't know if someone adds it later.
>
> Why compiler assisted bookkeeping is safe for subpools, but unsafe as a
> stand-alone mechanism?

There is no such stand-alone mechanism, and there cannot be one -- such
bookkeeping requires an object to store the bookkeeping into, and there is
none in the normal case. The only place to put such a thing is with the
access type, thus the collection mechanism. Pools are 100% user-defined, and
that can't be changed at this late date. (And if you did try to change it,
you'd end up with something almost the same as subpools anyway.)

....
> Sure, but again. there is a paramount use case that requires dynamic
> elaboration of tagged types, i.e. the relocatable libraries. You cannot
> ban them

I suppose, but you certainly don't have to use them. That sort of thing is
nonsense that simply makes programs more fragile than they have to be. I
just had a problem with Debian where some older programs compiled with GNAT
refused to run because an update had invalidated some library. Had to dig
out the source code and recompile.

....
> you cannot forbid tagged extensions declared in a relocatable library.

Of course you can. The only thing you need to be compatible with is a C
interface, which is the only thing you need to interface to existing
libraries that you can't avoid.

>So getting rid of nesting tagged types will ease nothing.

The problem is tagged types not declared at the library level. Relocatable
librarys are still library level (they have their own global address space).
So there wouldn't be the same problems as a tagged type declared in a
subprogram (which requires carrying around a static link or display, and
multiple part tags).

Randy.

On 2021-10-03 06:33, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sj9blb$1srp$1@gioia.aioe.org...
>> On 2021-10-02 11:06, Randy Brukardt wrote:
> ...
>>> That's again not safe in any sense. You shouldn't need to worry
>>> about whether some abstraction that you use uses finalization,
>>> especially as you can't know if someone adds it later.
>>
>> Why compiler assisted bookkeeping is safe for subpools, but unsafe
>> as a stand-alone mechanism?
>
> There is no such stand-alone mechanism, and there cannot be one

Huh, collections are stand-alone and exist already. Just do them
user-accessible and maintainable. The same is with the allocators. What
is the problem adding a generic package

generic
type User_Type (<>) is private;
type User_Pool is abstract new Root_Storage_Pool with private;
package Generic_Parametrized_Pool is
procedure User_Allocate
( Pool : in out User_Pool ;
Storage_Address : out Address;
Size : Storage_Count;
Alignment : Storage_Count;
Data : in out User_Type
) is abstract;
...

To handle "subpool" kludges:

P := new (Parameter) T;

Not that Generic_Parametrized_Pool would be more usable than subpools.
The problem with these is lack of Unchecked_Deallocation.

>> Sure, but again. there is a paramount use case that requires
>> dynamic elaboration of tagged types, i.e. the relocatable
>> libraries. You cannot ban them
>
> I suppose, but you certainly don't have to use them.

I must. It is impossible to maintain production grade software without
its components linked as relocatable libraries.

> That sort of
> thing is nonsense that simply makes programs more fragile than they
> have to be. I just had a problem with Debian where some older
> programs compiled with GNAT refused to run because an update had
> invalidated some library. Had to dig out the source code and
> recompile.

Yes, but static monolithic linking is even more fragile. Typically a
customer orders software off the shelf. It means that he says I need,
e.g. HTTP client, ModBus master, CANOpen etc. It is simply impossible to
re-link everything for each customer and run integration tests. So the
software is organized as a set of plug-in relocatable libraries, each of
them maintained, versioned and tested separately. You cannot turn clock
20 years back.

> ...
>> you cannot forbid tagged extensions declared in a relocatable
>> library.
>
> Of course you can.

How? Ada does not determine the way you link an executable. If I put a
package in a library it is there. If the package derives from a tagged type

> The only thing you need to be compatible with is a C interface, which
> is the only thing you need to interface to existing libraries that
> you can't avoid.

That would kill most of Ada libraries.

>> So getting rid of nesting tagged types will ease nothing.
>
> The problem is tagged types not declared at the library level.
> Relocatable librarys are still library level (they have their own
> global address space).

When the library is loaded dynamically, there is no way to know in the
executable the tag of the extension or prepare an extension of the
dispatching table. I think it is far worse than a nested declaration,
when is you have some information.

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

On 2021-10-03 01:19, Jere wrote:
> I was thinking more along the lines of adding a classwide operation on the
> root storage pool type.

You don't need that. As I proposed in another response, one add a new
primitive operations:

procedure Allocate_Segment
( Pool : in out Root_Storage_Pool;
Storage_Address : out Address;
Size : Storage_Count;
Alignment : Storage_Count;
Sequence_No : Positive
);

Note, it is not abstract. The implementation dispatches to Allocate:

procedure Allocate_Segment
( Pool : in out Root_Storage_Pool;
Storage_Address : out Address;
Size : Storage_Count;
Alignment : Storage_Count;
Head : Address; -- The first block address
Sequence_No : Positive
) is
begin
Root_Storage_Pool'Class (Pool).Allocate
( Storage_Address,
Size,
Alignment
);
end Allocate_Segment;

Similarly goes Deallocate_Segment.

The object allocation protocol:

Take mutex
Allocate (...); -- The head, passed down in further calls
Allocate_Segment (..., 1); -- First auxiliary block
...
Allocate_Segment (..., N); -- Last auxiliary block
Release mutex

Deallocation protocol:

Take mutex
Dellocate_Segment (..., 1); -- Last auxiliary block
...
Dellocate_Segment (..., N); -- First auxiliary block
Deallocate (...); -- The head
Release mutex

That is 100% backward compatible.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sjbq96$3cl$1@gioia.aioe.org...
> On 2021-10-03 06:33, Randy Brukardt wrote:
....
> Yes, but static monolithic linking is even more fragile. Typically a
> customer orders software off the shelf. It means that he says I need, e.g.
> HTTP client, ModBus master, CANOpen etc. It is simply impossible to
> re-link everything for each customer and run integration tests.

??? When you are dynamically loading stuff, you simply are assuming
everything is OK. (Which is usually nonsense, but for the sake of argument,
assume that it is OK to do.) When you statically link, you surely can make
the same assumption. It doesn't make sense to say you have to run
integration tests when you statically link and not do the same when you
dynamically load stuff.

Of course, when you statically link Ada code, you can include that code in
your static analysis (including, of course, the various guarantees that the
Ada language and compiler bring). When you dynamically load, you can have
none of that.

> So the software is organized as a set of plug-in relocatable libraries,
> each of them maintained, versioned and tested separately. You cannot turn
> clock 20 years back.

And you still have to do integration testing when using them together -- or
you could have done the same at the Ada source code level (that is, version,
maintain, and test separately) and still have the advantages of Ada
checking.

....
>> Of course you can.
>
> How? Ada does not determine the way you link an executable. If I put a
> package in a library it is there. If the package derives from a tagged
> type

This I don't understand at all. A dynamically loaded library necessarily has
a C interface (if it is generally useful, if not, it might as well be
maintained as Ada source code, there's no advantage to dynamic linking in
that case and lots of disavantages), and that can't export a tagged type.

In any case, a tagged type extension is a compile-time thing -- the compiler
has to know all of the details of the type.

>> The only thing you need to be compatible with is a C interface, which
>> is the only thing you need to interface to existing libraries that
>> you can't avoid.
>
> That would kill most of Ada libraries.

There's no use to an Ada dynamic library -- if it's only for your
organization's use, static linking is way better. And if it is for
everyone's use, it has to have a C interface, thus no tagged types.

>>> So getting rid of nesting tagged types will ease nothing.
>>
>> The problem is tagged types not declared at the library level.
>> Relocatable librarys are still library level (they have their own global
>> address space).
>
> When the library is loaded dynamically, there is no way to know in the
> executable the tag of the extension or prepare an extension of the
> dispatching table. I think it is far worse than a nested declaration, when
> is you have some information.

Ignoring that fact that this is useless construct, it is not at all hard to
do, because you have to know that the tag and subprograms are declared in
the dynamically loaded thing. Thus, one has to use a wrapper to call them
indirectly, but that's easy to do when everything is library level. It's
essentially the same as shared generics, which Janus/Ada has been doing for
decades -- including tagged type derivation.

The problem comes about when you have things whose lifetime is limited and
need to have a static link or display to access them. Managing that is a
nightmare, no matter how you try to do it.

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sjbr0j$am3$1@gioia.aioe.org...
> On 2021-10-03 01:19, Jere wrote:
....
> That is 100% backward compatible.

Not quite, as it would have problems if someone had declared a pool with
similar Allocate_Segment/Deallocate_Segment routines. Admittedly, a fairly
unlikely occurrence.

A secondary problem is that the mutex currently lives inside the pool; you
would have to expose some interface for that as well. (A set-up where the
mutex for allocations is global over the entire system is not going to fly.)

Randy.

On Wednesday, October 13, 2021 at 6:21:45 PM UTC-7, Randy Brukardt wrote:

> There's no use to an Ada dynamic library -- if it's only for your
> organization's use, static linking is way better. And if it is for
> everyone's use, it has to have a C interface, thus no tagged types.

A few months ago a customer requested Python for Windows support for a piece of hardware I sold him. The shortest path, which proved to be surprisingly elegant and very easy to implement, was to create a Windows .dll for him with a GNAT library project. I just wrote a few new Ada subprograms to encapsulate my existing (and substantial) Ada support code. Those wrapper subprograms do indeed present a C interface using "PRAGMA Export(Convention => C..."

On 2021-10-14 03:21, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sjbq96$3cl$1@gioia.aioe.org...
>> On 2021-10-03 06:33, Randy Brukardt wrote:
> ...
>> Yes, but static monolithic linking is even more fragile. Typically a
>> customer orders software off the shelf. It means that he says I need, e.g.
>> HTTP client, ModBus master, CANOpen etc. It is simply impossible to
>> re-link everything for each customer and run integration tests.
>
> ??? When you are dynamically loading stuff, you simply are assuming
> everything is OK.

A relocatable DLL is tested with a test application.

> (Which is usually nonsense, but for the sake of argument,
> assume that it is OK to do.) When you statically link, you surely can make
> the same assumption.

A static library is tested same way, true, but integration of a static
library is different and testing that is not possible without developing
some massive tool-chain, like Linux distributions had in early days.

> Of course, when you statically link Ada code, you can include that code in
> your static analysis (including, of course, the various guarantees that the
> Ada language and compiler bring). When you dynamically load, you can have
> none of that.

Yes, but maintainability trumps everything.

>> So the software is organized as a set of plug-in relocatable libraries,
>> each of them maintained, versioned and tested separately. You cannot turn
>> clock 20 years back.
>
> And you still have to do integration testing when using them together -- or
> you could have done the same at the Ada source code level (that is, version,
> maintain, and test separately) and still have the advantages of Ada
> checking.

Theoretically yes, in practice it is a combinatorial explosion. Dynamic
libraries flatten that. Yes, this requires normalization of plug-in
interfaces etc.

> ...
>>> Of course you can.
>>
>> How? Ada does not determine the way you link an executable. If I put a
>> package in a library it is there. If the package derives from a tagged
>> type
>
> This I don't understand at all. A dynamically loaded library necessarily has
> a C interface (if it is generally useful, if not, it might as well be
> maintained as Ada source code, there's no advantage to dynamic linking in
> that case and lots of disavantages), and that can't export a tagged type.

No C interfaces. Apart from maintenance, other issues are licensing and
security. A typical case is a component that is licensed in a different
way or may not be shipped to other customers at all. And you can have
alternative or mutually incompatible components.

> In any case, a tagged type extension is a compile-time thing -- the compiler
> has to know all of the details of the type.
>
>>> The only thing you need to be compatible with is a C interface, which
>>> is the only thing you need to interface to existing libraries that
>>> you can't avoid.
>>
>> That would kill most of Ada libraries.
>
> There's no use to an Ada dynamic library -- if it's only for your
> organization's use, static linking is way better.

You compare static vs. import library. The case I am talking about is
static vs. late dynamic loading, i.e. dlopen/dlsym stuff. And, yes, we
do dlsym on entries with Ada calling conventions. No C stuff.

> And if it is for
> everyone's use, it has to have a C interface, thus no tagged types.

We have close to a hundred of dynamically linked Ada libraries. Only one
of them has C interface, not surprisingly, with the sole functionality
to provide C API. But even that one library has tagged extensions of
inside of it. The standard Ada library is full of tagged types. Your
C-interfaced library is free to derive from any of them. You cannot
prevent that.

>>>> So getting rid of nesting tagged types will ease nothing.
>>>
>>> The problem is tagged types not declared at the library level.
>>> Relocatable librarys are still library level (they have their own global
>>> address space).
>>
>> When the library is loaded dynamically, there is no way to know in the
>> executable the tag of the extension or prepare an extension of the
>> dispatching table. I think it is far worse than a nested declaration, when
>> is you have some information.
>
> Ignoring that fact that this is useless construct, it is not at all hard to
> do, because you have to know that the tag and subprograms are declared in
> the dynamically loaded thing.

I do not see how this helps with, say, Ada.Tags.Expanded_Name getting a
tag from the library as an argument.

> Thus, one has to use a wrapper to call them
> indirectly, but that's easy to do when everything is library level. It's
> essentially the same as shared generics, which Janus/Ada has been doing for
> decades -- including tagged type derivation.

That is OK, but you still have to expand dispatching tables upon loading
the library and shrink them upon unloading (though the latter is not
supported, I guess).

> The problem comes about when you have things whose lifetime is limited and
> need to have a static link or display to access them. Managing that is a
> nightmare, no matter how you try to do it.

The lifetime of library objects in a dynamically loaded library is
limited by loading/unloading of the library.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sk8mbv$15ca$1@gioia.aioe.org...
> On 2021-10-14 03:21, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:sjbq96$3cl$1@gioia.aioe.org...
>>> On 2021-10-03 06:33, Randy Brukardt wrote:
>> ...
>>> Yes, but static monolithic linking is even more fragile. Typically a
>>> customer orders software off the shelf. It means that he says I need,
>>> e.g.
>>> HTTP client, ModBus master, CANOpen etc. It is simply impossible to
>>> re-link everything for each customer and run integration tests.
>>
>> ??? When you are dynamically loading stuff, you simply are assuming
>> everything is OK.
>
> A relocatable DLL is tested with a test application.

Testing cannot ensure that a contract hasn't been violated, especially the
implicit ones that get created by the runtime behavior of a library. At
best, you can test a few percent of the way a library can be used (and
people are good at finding unanticipated ways to use a library).

>> (Which is usually nonsense, but for the sake of argument,
>> assume that it is OK to do.) When you statically link, you surely can
>> make
>> the same assumption.
>
> A static library is tested same way, true, but integration of a static
> library is different and testing that is not possible without developing
> some massive tool-chain, like Linux distributions had in early days.

??? Your "test application" is just a way of running unit tests against a
library. You can surely do exactly the same testing with a statically-linked
library, it's hard to imagine how a library is packaged would make any
difference.

The problem with dynamically loaded libraries is exactly that they change
out of sync with the rest of the application, and thus tend to break that
application when some behavior of the original library is changed. It's
quite possible that the behavior in question should never have been depended
upon, but contracts aren't strong enough to really describe dynamic behavior
(especially use cases and timing). At least with a statically linked
library, you know it won't change without at least rerunning your acceptance
tests.

>> Of course, when you statically link Ada code, you can include that code
>> in
>> your static analysis (including, of course, the various guarantees that
>> the
>> Ada language and compiler bring). When you dynamically load, you can have
>> none of that.
>
> Yes, but maintainability trumps everything.

I agree with the sentiment, but the only way to get any sort of
maintenability is with strong contracts and lots of static analysis.
Otherwise, subtle changes in a library will break the users and there will
be no way to find where the dependency is. Nothing I've ever worked on has
ever been close to maintainable because there is so much that Ada cannot
describe (even though Ada itself is certainly a help in this area). You just
have to re-test to make sure that no major problems have been introduced
(there's a reason that compiler writer's rerun a huge test suite every day).

>>> So the software is organized as a set of plug-in relocatable libraries,
>>> each of them maintained, versioned and tested separately. You cannot
>>> turn
>>> clock 20 years back.
>>
>> And you still have to do integration testing when using them together --
>> or
>> you could have done the same at the Ada source code level (that is,
>> version,
>> maintain, and test separately) and still have the advantages of Ada
>> checking.
>
> Theoretically yes, in practice it is a combinatorial explosion.

Only if you don't use unit tests. But then how you can test a dynamic
library escapes me. (I've never used unit tests with Janus/Ada because it is
too hard to set up the initial conditions for a meaningful test. The easiest
way to do that is to compile something, but of course you no longer can do
unit tests as you have the entire rest of the system dragged along.)

> Dynamic libraries flatten that. Yes, this requires normalization of
> plug-in interfaces etc.

As noted above, I don't see how. If testing a dynamic library is possible,
surely running the same tests against a static library would give the same
results (and assurances).

....
>> There's no use to an Ada dynamic library -- if it's only for your
>> organization's use, static linking is way better.
>
> You compare static vs. import library. The case I am talking about is
> static vs. late dynamic loading, i.e. dlopen/dlsym stuff. And, yes, we do
> dlsym on entries with Ada calling conventions. No C stuff.

That sort of stuff is just plain evil. :-)

I don't see any way that such loading could work with Ada semantics; there
is an assumption that all of your ancestors exist before you can do
anything. The elaboration checks were intended to check that.

....

....
>> Ignoring that fact that this is useless construct, it is not at all hard
>> to
>> do, because you have to know that the tag and subprograms are declared in
>> the dynamically loaded thing.
>
> I do not see how this helps with, say, Ada.Tags.Expanded_Name getting a
> tag from the library as an argument.

Ada,Tags can be implemented dynamically; it's a lot easier to do so with
nested tagged types whose tags go away. Essentially, one registers tags when
they are declared, and deregisters them when they go away. That fits very
well with dynamically loaded libraries.

>> Thus, one has to use a wrapper to call them
>> indirectly, but that's easy to do when everything is library level. It's
>> essentially the same as shared generics, which Janus/Ada has been doing
>> for
>> decades -- including tagged type derivation.
>
> That is OK, but you still have to expand dispatching tables upon loading
> the library and shrink them upon unloading (though the latter is not
> supported, I guess).

??? The dispatching tables are defined statically by the compiler, and never
change. What I'd do for dynamically loaded libraries is use a wrapper that
indirectly calls the dynamically loaded libraries' subprograms. So loading
the library (actually, declaring the extension) simply has to set up an
array of pointers to the dynamically loaded subprograms. (You can't call
them statically because you don't know where they'll be.) The dispatch
tables never change.

>> The problem comes about when you have things whose lifetime is limited
>> and
>> need to have a static link or display to access them. Managing that is a
>> nightmare, no matter how you try to do it.
>
> The lifetime of library objects in a dynamically loaded library is limited
> by loading/unloading of the library.

They're still treated as library-level, and they can only be loaded before
anything that is going to use them. Otherwise, the Ada elaboration model is
hosed, and that is fundamental to compiling Ada code.

You could of course write an implementation that doesn't care about safe
code, and let people do whatever that they like even though it is nonsense
from an Ada perspective. Such code is simply user-beware, and has no
guarantee of working in the future (after a compiler change).

I won't do that, there are some principles that I won't compromise to get
customers.

Randy.

"Randy Brukardt" <randy@rrsoftware.com> writes:

>>
>> That is OK, but you still have to expand dispatching tables upon loading
>> the library and shrink them upon unloading (though the latter is not
>> supported, I guess).
>
> ??? The dispatching tables are defined statically by the compiler, and never
> change.

It would be nice if different variants of a dynamically loaded library
could introduce different derived types; that would support a "plugin"
model nicely.

For example, suppose an editor defines a library interface for computing
indent for various languages. Then one variant could provide Ada,
another Pascal, etc. Each could be a derived type.

I think you are saying this is simply not possible with Ada tagged types.

--
-- Stephe

On 2021-10-15 02:36, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sk8mbv$15ca$1@gioia.aioe.org...
>> On 2021-10-14 03:21, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:sjbq96$3cl$1@gioia.aioe.org...
>>>> On 2021-10-03 06:33, Randy Brukardt wrote:
>>> ...
>>>> Yes, but static monolithic linking is even more fragile. Typically a
>>>> customer orders software off the shelf. It means that he says I need,
>>>> e.g.
>>>> HTTP client, ModBus master, CANOpen etc. It is simply impossible to
>>>> re-link everything for each customer and run integration tests.
>>>
>>> ??? When you are dynamically loading stuff, you simply are assuming
>>> everything is OK.
>>
>> A relocatable DLL is tested with a test application.
>
> Testing cannot ensure that a contract hasn't been violated, especially the
> implicit ones that get created by the runtime behavior of a library. At
> best, you can test a few percent of the way a library can be used (and
> people are good at finding unanticipated ways to use a library).

Yes, high integrity system would likely have a monolithic design, but
this too is changing because the size of systems keeps on growing.

>>> (Which is usually nonsense, but for the sake of argument,
>>> assume that it is OK to do.) When you statically link, you surely can
>>> make
>>> the same assumption.
>>
>> A static library is tested same way, true, but integration of a static
>> library is different and testing that is not possible without developing
>> some massive tool-chain, like Linux distributions had in early days.
>
> ??? Your "test application" is just a way of running unit tests against a
> library. You can surely do exactly the same testing with a statically-linked
> library, it's hard to imagine how a library is packaged would make any
> difference.

It is linking static stuff alternately that need to be tested. If you
use a subset of statically linked components you need to change the code
that uses them correspondingly, unless you do an equivalent of
dynamically loaded components without any advantages of.

As an example, consider switching between GNUTLS and OpenSSL for
encryption of say MQTT connections.

>> Yes, but maintainability trumps everything.
>
> I agree with the sentiment, but the only way to get any sort of
> maintenability is with strong contracts and lots of static analysis.

Yes, contracts is a weak part of dynamically loaded stuff. In our case a
component registers itself after its library is loaded by providing an
instance of tagged object.

> Otherwise, subtle changes in a library will break the users and there will
> be no way to find where the dependency is. Nothing I've ever worked on has
> ever been close to maintainable because there is so much that Ada cannot
> describe (even though Ada itself is certainly a help in this area). You just
> have to re-test to make sure that no major problems have been introduced
> (there's a reason that compiler writer's rerun a huge test suite every day).

Yes, but it is not economically viable anymore. Nobody would pay for that.

> Only if you don't use unit tests. But then how you can test a dynamic
> library escapes me. (I've never used unit tests with Janus/Ada because it is
> too hard to set up the initial conditions for a meaningful test. The easiest
> way to do that is to compile something, but of course you no longer can do
> unit tests as you have the entire rest of the system dragged along.)

We test Ada packages statically linked and we have
semi-unit/semi-integration tests that load the library first. It is not
a big deal.

>> Dynamic libraries flatten that. Yes, this requires normalization of
>> plug-in interfaces etc.
>
> As noted above, I don't see how. If testing a dynamic library is possible,
> surely running the same tests against a static library would give the same
> results (and assurances).

Only if you create some equivalent of "static" plug-in with all
disadvantages of proper plug-in and none of the advantages.

>>> There's no use to an Ada dynamic library -- if it's only for your
>>> organization's use, static linking is way better.
>>
>> You compare static vs. import library. The case I am talking about is
>> static vs. late dynamic loading, i.e. dlopen/dlsym stuff. And, yes, we do
>> dlsym on entries with Ada calling conventions. No C stuff.
>
> That sort of stuff is just plain evil. :-)

Yes! (:-))

> I don't see any way that such loading could work with Ada semantics; there
> is an assumption that all of your ancestors exist before you can do
> anything. The elaboration checks were intended to check that.

We have a core libraries which are import libraries for the plug-in.
When a plug-in is loaded, the core libraries are elaborated unless
already loaded, the plug-in library itself is not elaborated, because
automatic elaboration would deadlock under Windows. Then a dedicated
entry point is called in the plug-in library. The first thing it does is
a call to the plug-in elaboration code. GNAT generates an
<library-name>init entry for that. After this the plug-in registers
itself providing a tagged object, which primitive operations are
basically the library's true interface.

I know it sounds horrific, but it works pretty well.

> ??? The dispatching tables are defined statically by the compiler, and never
> change. What I'd do for dynamically loaded libraries is use a wrapper that
> indirectly calls the dynamically loaded libraries' subprograms. So loading
> the library (actually, declaring the extension) simply has to set up an
> array of pointers to the dynamically loaded subprograms. (You can't call
> them statically because you don't know where they'll be.) The dispatch
> tables never change.

And how do you dispatch? Consider the case:

The core library:

package A is
type T is tagged ...;
procedure Foo (X : in out T);

procedure Trill_Me (X : in out T'Class);
end A;

package body A is
procedure Trill_Me (X : in out T'Class) is
begin
X.Foo; -- Dispatches to Foo overridden in a loadable library
end Trill_Me;
end A;

Inside the loadable library:

type S is new T with ...;
overriding procedure Foo (X : in out S);
...
X : B;
...
Trill_Me (X);

Do you keep a pointer to the dispatching table inside the object, like
C++ does? Because I had a more general model in mind, when dispatching
tables were attached to the primitive operations rather than objects.

>>> The problem comes about when you have things whose lifetime is limited
>>> and
>>> need to have a static link or display to access them. Managing that is a
>>> nightmare, no matter how you try to do it.
>>
>> The lifetime of library objects in a dynamically loaded library is limited
>> by loading/unloading of the library.
>
> They're still treated as library-level,

Right, and this is the problem, because semantically anything inside a
dynamically loaded library is not just nested, worse, it is more like
new/Unchecked_Deallocation, but with things like types etc.

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

On 2021-10-15 10:08, Stephen Leake wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>> That is OK, but you still have to expand dispatching tables upon loading
>>> the library and shrink them upon unloading (though the latter is not
>>> supported, I guess).
>>
>> ??? The dispatching tables are defined statically by the compiler, and never
>> change.
>
> It would be nice if different variants of a dynamically loaded library
> could introduce different derived types; that would support a "plugin"
> model nicely.
>
> For example, suppose an editor defines a library interface for computing
> indent for various languages. Then one variant could provide Ada,
> another Pascal, etc. Each could be a derived type.
>
> I think you are saying this is simply not possible with Ada tagged types.

This is exactly what we do. At least with GNAT it works just fine.

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

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:86v91ylnft.fsf@stephe-leake.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>>
>>> That is OK, but you still have to expand dispatching tables upon loading
>>> the library and shrink them upon unloading (though the latter is not
>>> supported, I guess).
>>
>> ??? The dispatching tables are defined statically by the compiler, and
>> never
>> change.
>
> It would be nice if different variants of a dynamically loaded library
> could introduce different derived types; that would support a "plugin"
> model nicely.
>
> For example, suppose an editor defines a library interface for computing
> indent for various languages. Then one variant could provide Ada,
> another Pascal, etc. Each could be a derived type.
>
> I think you are saying this is simply not possible with Ada tagged types.

The case Dmitry was talking about (or at least that I thought he was talking
about) is deriving a new type from a dynamically loaded type. That can be
implemented, but you have to know the type you are deriving from in the Ada
model (classwide parents are illegal in Ada). So it doesn't buy a huge
amount.

You are talking about exposing different implementations of the same Ada
type in a dynamically loaded library, and that of course works fine. You
can't have truly different types in the Ada model, since you are sharing the
specification (essentially, only the body is dynamically loaded; even if the
code for the spec is included in the dynamic loaded unit, the static
properties have to be the same).

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:skbdb5$u50$1@gioia.aioe.org...
> On 2021-10-15 02:36, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:sk8mbv$15ca$1@gioia.aioe.org...
>>> On 2021-10-14 03:21, Randy Brukardt wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:sjbq96$3cl$1@gioia.aioe.org...
>>>>> On 2021-10-03 06:33, Randy Brukardt wrote:
>>>> ...
>>> A static library is tested same way, true, but integration of a static
>>> library is different and testing that is not possible without developing
>>> some massive tool-chain, like Linux distributions had in early days.
>>
>> ??? Your "test application" is just a way of running unit tests against a
>> library. You can surely do exactly the same testing with a
>> statically-linked
>> library, it's hard to imagine how a library is packaged would make any
>> difference.
>
> It is linking static stuff alternately that need to be tested. If you use
> a subset of statically linked components you need to change the code that
> uses them correspondingly, unless you do an equivalent of dynamically
> loaded components without any advantages of.
>
> As an example, consider switching between GNUTLS and OpenSSL for
> encryption of say MQTT connections.

I guess I don't follow. The connections between units is static (in Ada, and
any dynamic loading in Ada has to follow the same model), so any unit
testing on a unit tests all of its dependencies as well. If you don't use a
unit at all, it isn't included in the closure, and whether or not it passes
any tests is irrelevant.

In the case you describe, you'd have a binding that abstracts the two
underlying libraries, and you'd unit test that. Assuming it passes with both
implementations, it shouldn't matter which is used in a particular program.
How the foreign langauge code is implemented (static or dynamic binding,
programming language, etc.) is irrelevant to the Ada program. So again I
don't see the problem.

.....
>> Otherwise, subtle changes in a library will break the users and there
>> will
>> be no way to find where the dependency is. Nothing I've ever worked on
>> has
>> ever been close to maintainable because there is so much that Ada cannot
>> describe (even though Ada itself is certainly a help in this area). You
>> just
>> have to re-test to make sure that no major problems have been introduced
>> (there's a reason that compiler writer's rerun a huge test suite every
>> day).
>
> Yes, but it is not economically viable anymore. Nobody would pay for that.

Really? They have no choice -- otherwise, your product will fail
periodically without any way to find out why. Has software gotten so bad
that no one cares about that? I certainly would never do that to our
customers (and I hate support anyway, I want to reduce it as much as
possible).

>> Only if you don't use unit tests. But then how you can test a dynamic
>> library escapes me. (I've never used unit tests with Janus/Ada because it
>> is
>> too hard to set up the initial conditions for a meaningful test. The
>> easiest
>> way to do that is to compile something, but of course you no longer can
>> do
>> unit tests as you have the entire rest of the system dragged along.)
>
> We test Ada packages statically linked and we have
> semi-unit/semi-integration tests that load the library first. It is not a
> big deal.

Which sounds like there is no reason to use dynamic linking except to make
your applications far more fragile. I suppose it doesn't matter as much if
the libraries are all under your control, but that is rarely the case in the
real world. (Your example of connection encryption is a good one; changes to
the underlying stuff tends to break existing programs. Not much that can be
done about it, of course, but those updates don't really fix anything by
themselves, the using programs tend to need to be repaired.)

>>> Dynamic libraries flatten that. Yes, this requires normalization of
>>> plug-in interfaces etc.
>>
>> As noted above, I don't see how. If testing a dynamic library is
>> possible,
>> surely running the same tests against a static library would give the
>> same
>> results (and assurances).
>
> Only if you create some equivalent of "static" plug-in with all
> disadvantages of proper plug-in and none of the advantages.

There's no plug-ins in a statically linked system. What would be the point?
I'm assuming that we're talking about Ada interfaced libraries here (C is a
different kettle of fish), so you're talking about switching implementations
of a single Ada spec. We've done that going back to the beginning of Ada
time; it's managed by decent build tools and has gotten pretty simple in
most Ada compilers. So what would a plug-in buy?

>>>> There's no use to an Ada dynamic library -- if it's only for your
>>>> organization's use, static linking is way better.
>>>
>>> You compare static vs. import library. The case I am talking about is
>>> static vs. late dynamic loading, i.e. dlopen/dlsym stuff. And, yes, we
>>> do
>>> dlsym on entries with Ada calling conventions. No C stuff.
>>
>> That sort of stuff is just plain evil. :-)
>
> Yes! (:-))
>
>> I don't see any way that such loading could work with Ada semantics;
>> there
>> is an assumption that all of your ancestors exist before you can do
>> anything. The elaboration checks were intended to check that.
>
> We have a core libraries which are import libraries for the plug-in. When
> a plug-in is loaded, the core libraries are elaborated unless already
> loaded, the plug-in library itself is not elaborated, because automatic
> elaboration would deadlock under Windows. Then a dedicated entry point is
> called in the plug-in library. The first thing it does is a call to the
> plug-in elaboration code. GNAT generates an <library-name>init entry for
> that. After this the plug-in registers itself providing a tagged object,
> which primitive operations are basically the library's true interface.
>
> I know it sounds horrific, but it works pretty well.

It does sound horrific, and it doesn't seem to buy much.

>> ??? The dispatching tables are defined statically by the compiler, and
>> never
>> change. What I'd do for dynamically loaded libraries is use a wrapper
>> that
>> indirectly calls the dynamically loaded libraries' subprograms. So
>> loading
>> the library (actually, declaring the extension) simply has to set up an
>> array of pointers to the dynamically loaded subprograms. (You can't call
>> them statically because you don't know where they'll be.) The dispatch
>> tables never change.
>
> And how do you dispatch? Consider the case:
>
> The core library:
>
> package A is
> type T is tagged ...;
> procedure Foo (X : in out T);
>
> procedure Trill_Me (X : in out T'Class);
> end A;
>
> package body A is
> procedure Trill_Me (X : in out T'Class) is
> begin
> X.Foo; -- Dispatches to Foo overridden in a loadable library
> end Trill_Me;
> end A;
>
> Inside the loadable library:
>
> type S is new T with ...;
> overriding procedure Foo (X : in out S);
> ...
> X : B;
> ...
> Trill_Me (X);
>
> Do you keep a pointer to the dispatching table inside the object, like C++
> does? Because I had a more general model in mind, when dispatching tables
> were attached to the primitive operations rather than objects.

A tag is a property of a type in Ada, and it includes the dispatch table.
You could have a model where the dispatch table didn't live in the object
(but that's not Ada, you have to be able to recover the original tag of the
object), but that wouldn't change anything about the structure of the
tables. I don't see any model that makes sense associated with the
operations. The whole point of a tagged type is that it is a set of
operations called in a consistent way, breaking that up makes no sense.

.....
>>>> The problem comes about when you have things whose lifetime is limited
>>>> and
>>>> need to have a static link or display to access them. Managing that is
>>>> a
>>>> nightmare, no matter how you try to do it.
>>>
>>> The lifetime of library objects in a dynamically loaded library is
>>> limited
>>> by loading/unloading of the library.
>>
>> They're still treated as library-level,
>
> Right, and this is the problem, because semantically anything inside a
> dynamically loaded library is not just nested, worse, it is more like
> new/Unchecked_Deallocation, but with things like types etc.

On 2021-10-16 00:44, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:skbdb5$u50$1@gioia.aioe.org...
>> On 2021-10-15 02:36, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message

> In the case you describe, you'd have a binding that abstracts the
> two underlying libraries, and you'd unit test that. Assuming it
> passes with both implementations, it shouldn't matter which is used
> in a particular program.

You need to test switching between implementations. In the case of
static linking that part is not even code and thus non-testable. You
must test each concrete assembly of components each time and each
assembly with have alternating code. Why do you think people keep on
asking for Ada preprocessor in c.l.a?

>> Yes, but it is not economically viable anymore. Nobody would pay
>> for that.
>
> Has software gotten so
> bad that no one cares about that?

Yes, and worse.

> I certainly would never do that to
> our customers (and I hate support anyway, I want to reduce it as
> much as possible).

Compilers are not ware anymore. We live in a post-market era with
neo-feudal economic relationships.

> There's no plug-ins in a statically linked system. What would be the
> point? I'm assuming that we're talking about Ada interfaced
> libraries here (C is a different kettle of fish), so you're talking
> about switching implementations of a single Ada spec. We've done that
> going back to the beginning of Ada time; it's managed by decent build
> tools and has gotten pretty simple in most Ada compilers. So what
> would a plug-in buy?

Yes, that is about build tools to develop and maintain, because
dependencies handling and adjusting the code invoking optional
components is specific to the problem domain. Such stuff does exist,
e.g. this is how VxWorks or Yokto Linux images are configured. No way
regular software could go this way.

>>> I don't see any way that such loading could work with Ada
>>> semantics; there is an assumption that all of your ancestors
>>> exist before you can do anything. The elaboration checks were
>>> intended to check that.
>>
>> We have a core libraries which are import libraries for the
>> plug-in. When a plug-in is loaded, the core libraries are
>> elaborated unless already loaded, the plug-in library itself is not
>> elaborated, because automatic elaboration would deadlock under
>> Windows. Then a dedicated entry point is called in the plug-in
>> library. The first thing it does is a call to the plug-in
>> elaboration code. GNAT generates an <library-name>init entry for
>> that. After this the plug-in registers itself providing a tagged
>> object, which primitive operations are basically the library's true
>> interface.
>>
>> I know it sounds horrific, but it works pretty well.
>
> It does sound horrific, and it doesn't seem to buy much.

We started with a monolithic solution and were forced to redesign it
when it became unmaintainable. Apart from the the fact that it bluntly
refused to fit in 256K RAM of a target platform ...

> A tag is a property of a type in Ada, and it includes the dispatch
> table.

No, it is just one possible implementation. It has a disadvantage that
you must search a global map tag->vptr and you must keep the whole table
per each tagged type. I suppose one could exchange the map tag->ptr with
ptr->tag. Then dispatching will be cheaper and X'Tag more expensive. In
any case you must adjust either map when elaborating the library.

> You can't unload a library until all of the things that depend upon
> it have been unloaded, so from the perspective of a compiler, it acts
> like library-level. The whole mess about loading/unloading is on the
> user (which is what I meant about "unsafe" yesterday), and if you get
> it wrong, your program is erroneous and can do any manner of things.
> It's no more worth it for a compiler to worry about bad unloading
> than it is to worry about dangling pointers.

Still arguing for collections, huh? (:-))

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Why do you think people keep on asking for Ada preprocessor in c.l.a?

Certainly not something I've noticed

On 2021-10-16 16:32, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Why do you think people keep on asking for Ada preprocessor in c.l.a?
>
> Certainly not something I've noticed

Comes periodically. People falsely believe that conditional compilation
could allow static linking for dynamically configured projects.

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

On Saturday, October 16, 2021 at 9:06:03 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2021-10-16 16:32, Simon Wright wrote:
> > "Dmitry A. Kazakov" <mai...> writes:
> >
> >> Why do you think people keep on asking for Ada preprocessor in c.l.a?
> >
> > Certainly not something I've noticed
> Comes periodically. People falsely believe that conditional compilation
> could allow static linking for dynamically configured projects.

Having worked on C/C++ projects that used a bunch of preprocessor stuff, esp IFDEF/IFNDEF, I have to say that even if it *were* theoretically possible the resultant mess would be so unmaintainable as to simply not be worth it.