Re: Dimensionality Checking (Ada 20XX)

Re: Dimensionality Checking (Ada 20XX)

[Mike Brenner]

Mark Lundquist said: 
> But the compiler only has to look at the generic *spec* to determine this.
> What you *never* see today, and what we'd really like to avoid in any
> language revision, is this: you make a change to the generic *body*, the
> change is legal (the generic body compiles), but suddenly one or more
> *instantiations* become illegal as a result.  That is the problem I'm
> talking about with units.

Is this the reason why non-generic packages have been forbidden as generic parameters? 

It seems that the benefits of a fully orthogonal implementation of generic (making them second-class objects by permitting passing object to objects) outweigh the benefits of keeping compatibility with all existing bodies. 

In particular, permitting non-generic package parameters would give a way to switch implementations without rewriting the code. In particular, a configuration manager could simply swap the spec and body of the package being used as a non-generic parameter to a generic, and that would change the device driver from being Linux-compatible to being COM-compatible. 

Now, a line of code has to be changed in order to swap devices supported, so it requires a PROGRAMMER rather than a CONFIGURATION MANAGER to make that kind of change to a large Ada system.

The disadvantage would be that certain programs might no longer compile, for example, if they used a feature of Linux that COM-objects did not implement.

It seems to me that this disadvantage, detected at compile time, might make up for the advantage?

Also, of course, making packages second class objects like that would be the penultimate step towards eventually making package first-class objects.

Re: non-generic generic parameters

[Wes Groleau]

Mike Brenner wrote:
> Is this the reason why non-generic packages have been forbidden as generic parameters?
> 
> It seems that the benefits of a fully orthogonal implementation of generic (making them second-class objects by permitting passing object to objects) outweigh the benefits of keeping compatibility with all existing bodies.
> 
> In particular, permitting non-generic package parameters would give a way to switch implementations without rewriting the code. In particular, a configuration manager could simply swap the spec and body of the package being 

You can write the two candidate packages as generics
with no parameters.  You get the same results, pretty much.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Dimensionality Checking (Ada 20XX)

[Mark Lundquist]

"Mike Brenner" <mikeb@mitre.org> wrote in message
news:mailman.1008076322.18644.comp.lang.ada@ada.eu.org...
> Mark Lundquist said:
> > But the compiler only has to look at the generic *spec* to determine
this.
> > What you *never* see today, and what we'd really like to avoid in any
> > language revision, is this: you make a change to the generic *body*, the
> > change is legal (the generic body compiles), but suddenly one or more
> > *instantiations* become illegal as a result.  That is the problem I'm
> > talking about with units.
>
> Is this the reason why non-generic packages have been forbidden as generic
parameters?

I don't think that's so much "forbidden" as it is "nonsensical" :-)

What exactly would such a construct look like, and what exactly would it
mean?

>[...]
> In particular, permitting non-generic package parameters would give a way
to switch implementations without rewriting the code. In particular, a
configuration manager could simply swap the spec and body of the package
being used as a non-generic parameter to a generic, and that would change
the device driver from being Linux-compatible to being COM-compatible.

Well, why can't you just "swap the spec and body" of a package today?  Why
do you need an enhancement to generics for this?

Maybe I don't understand the problem you're trying to solve... can you make
your example more specific, e.g. by including a source code example for the
feature you're envisioning?

Are you aware of the generic "signature" idiom?  Also, library-level
renames?  Perhaps those devices would help with what you're after...?

It could be that your Linux/COM example is not particulary illustrative,
since mulitplatform development is typically conducted by maintaining
multiple variants, not by "switching" something back and forth...

>
> Now, a line of code has to be changed in order to swap devices supported,
so it requires a PROGRAMMER rather than a CONFIGURATION MANAGER to make that
kind of change to a large Ada system.

Since I haven't seen how your feature would work, I can't see that this is
true :-)... but I can see how a configuration manager might select a
configuration with a different variant of a package spec and body, then
rebuild to create a different system.  This is in today's Ada, and it
wouldn't take a programmer to do that...

> Also, of course, making packages second class objects like that would be
the penultimate step towards eventually making package first-class objects.
>

Have you been sharing LSD with Nick Roberts?  Please, stop before it's too
late!  Also, you should know that Nick isn't even from our planet, he's
really a Tenet from the planet Contar.  He's the Distar of Contar, actually.
You should never, ever share mind-altering substances with a Tenet, it is
just too risky.

Now then... please study the relationships between the concepts of type,
value, and object in Ada.  That is the penultimate step towards eventually
understanding why your suggestion is bonkers :-).

http://www.ada-auth.org/~acats/arm-html/RM-3-2.html
http://www.ada-auth.org/~acats/arm-html/RM-3-3.html
http://www.na.org

Good luck... with everything :-)
-- mark