Instanciation in a package spec.

Instanciation in a package spec.

[Gautier direct_replies_not_read]

In a package specification, I have:

  generic
    what: String;
  package Ad_hoc is
    function Last return String;
    procedure Add;
    procedure Put_Last;
  end Ad_hoc;

  package Ad_hoc_type is new Ad_hoc("type");

* ObjectAda 7.2.1 compiles it fine. But link fails:
pascalhe.obj : error LNK2001: unresolved external symbol 
pascalhelp.default_instanciations__elab_bool
haddock.obj : error LNK2001: unresolved external symbol 
pascalhelp.ad_hoc_type.add
haddock.obj : error LNK2001: unresolved external symbol 
pascalhelp.ad_hoc_type.put_last
haddock.exe : fatal error LNK1120: 3 unresolved externals

* GNAT 3.15p issues:
  pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
  pascalhe.ads:135:03: warning: Program_Error will be raised at run time

Who is right ? Of course I would like to keep is as I've
programmed, although there is surely a workaround by making
a new package with the instanciations. I'd prefer to avoid it.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!


_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Instanciation in a package spec.

[Grein, Christoph]

> * GNAT 3.15p issues:
>   pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
>   pascalhe.ads:135:03: warning: Program_Error will be raised at run time

Believe Gnat. It's a RM rule to forbid instantiations before elaboration of the body.

Re: Instanciation in a package spec.

[Robert A Duff]

"Grein, Christoph" <christoph.grein@eurocopter.com> writes:

> > * GNAT 3.15p issues:
> >   pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
> >   pascalhe.ads:135:03: warning: Program_Error will be raised at run time
> 
> Believe Gnat. It's a RM rule to forbid instantiations before elaboration of the body.

A very annoying rule, indeed.

- Bob

Re: Instanciation in a package spec.

[Martin Dowie]

"Gautier direct_replies_not_read" <gautier_niouzes@hotmail.com> wrote in message news:<mailman.13.1043231049.4961.comp.lang.ada@ada.eu.org>...
> * ObjectAda 7.2.1 compiles it fine. But link fails:
> pascalhe.obj : error LNK2001: unresolved external symbol 
> pascalhelp.default_instanciations__elab_bool

Get the new version of OA (7.2.2) it produces:

ad_hoc_type.ads: Error: line 2 col 9 LRM:10.1.4, Generic body not
found to instantiate, recompile when generic body is available

The best of all the messages I would say.

Re: Instanciation in a package spec.

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]


"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news: wccel752ki5.fsf@shell01.TheWorld.com...
> "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
>
> > > * GNAT 3.15p issues:
> > >   pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
> > >   pascalhe.ads:135:03: warning: Program_Error will be raised at run time
> >
> > Believe Gnat. It's a RM rule to forbid instantiations before elaboration of the body.
>
> A very annoying rule, indeed.
>
????
Since the body of the instance is elaborated at the point of instanciation, the body of the
generic has better been elaborated already....

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Instanciation in a package spec.

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news: wccel752ki5.fsf@shell01.TheWorld.com...
> > "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
> >
> > > > * GNAT 3.15p issues:
> > > >   pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
> > > >   pascalhe.ads:135:03: warning: Program_Error will be raised at run time
> > >
> > > Believe Gnat. It's a RM rule to forbid instantiations before elaboration of the body.
> >
> > A very annoying rule, indeed.
> >
> ????
> Since the body of the instance is elaborated at the point of instanciation, the body of the
> generic has better been elaborated already....

I understand the *need* for the rule in Ada.  But it's still an annoying
restriction.  It's perfectly reasonable to want to export a generic and
an instance of that generic from the same package.  But Ada's
elaboration model prevents it.

It's also annoying that you can't call a function in the same package:

    package P is
        function F(...) return T;
        X: constant T;
    private
        X: constant T := F(...); -- raises P_E.
    end P;

The problem here is the elaboration model of Ada.  The *visibility* of
things is too closely tied to the *elaboration* order.  I have worked
out a different model of elaboration that doesn't have this problem (but
still retains all the advantages of the Ada model).  Unfortunately, it's
not Ada.

The end result of these restrictions is that you have to introduce all
kinds of extra packages and other declarations that are irrelevant to
the conceptual design.  And you pollute the clients with that bogus
structure.  I run into this problem fairly often, and I find it really
damages the structure of the software.

- Bob

Re: Instanciation in a package spec.

[Dmitry A. Kazakov]

On Thu, 23 Jan 2003 14:19:49 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>"Jean-Pierre Rosen" <rosen@adalog.fr> writes:
>
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news: wccel752ki5.fsf@shell01.TheWorld.com...
>> > "Grein, Christoph" <christoph.grein@eurocopter.com> writes:
>> >
>> > > > * GNAT 3.15p issues:
>> > > >   pascalhe.ads:135:03: warning: cannot instantiate "Ad_hoc" before body seen
>> > > >   pascalhe.ads:135:03: warning: Program_Error will be raised at run time
>> > >
>> > > Believe Gnat. It's a RM rule to forbid instantiations before elaboration of the body.
>> >
>> > A very annoying rule, indeed.
>> >
>> ????
>> Since the body of the instance is elaborated at the point of instanciation, the body of the
>> generic has better been elaborated already....
>
>I understand the *need* for the rule in Ada.  But it's still an annoying
>restriction.  It's perfectly reasonable to want to export a generic and
>an instance of that generic from the same package.  But Ada's
>elaboration model prevents it.
>
>It's also annoying that you can't call a function in the same package:
>
>    package P is
>        function F(...) return T;
>        X: constant T;
>    private
>        X: constant T := F(...); -- raises P_E.
>    end P;
>
>The problem here is the elaboration model of Ada.  The *visibility* of
>things is too closely tied to the *elaboration* order.  I have worked
>out a different model of elaboration that doesn't have this problem (but
>still retains all the advantages of the Ada model).  Unfortunately, it's
>not Ada.

Why it cannot become Ada?

In other words, what is the price of your model?

Can  X become static (in your model), when F is pure?

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

Re: Instanciation in a package spec.

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]


"Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news: wccn0lsvth6.fsf@shell01.TheWorld.com...
> "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> > Since the body of the instance is elaborated at the point of instanciation, the body of the
> > generic has better been elaborated already....
>
> I understand the *need* for the rule in Ada.  But it's still an annoying
> restriction.  It's perfectly reasonable to want to export a generic and
> an instance of that generic from the same package.  But Ada's
> elaboration model prevents it.
>
If you make the instance a child (and put a pragma Elaborate_Body in the parent's spec),
then it's OK.

Of course, you won't be able to use it from the body of the parent, but if you put it
in a visible part, it's presumabely for external use.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Instanciation in a package spec.

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> a �crit dans le message de news: wccn0lsvth6.fsf@shell01.TheWorld.com...
> > "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
> > > Since the body of the instance is elaborated at the point of instanciation, the body of the
> > > generic has better been elaborated already....
> >
> > I understand the *need* for the rule in Ada.  But it's still an annoying
> > restriction.  It's perfectly reasonable to want to export a generic and
> > an instance of that generic from the same package.  But Ada's
> > elaboration model prevents it.
> >
> If you make the instance a child (and put a pragma Elaborate_Body in the parent's spec),
> then it's OK.

That sometimes works, but not always.  It also requires the client to
"with" bits and pieces of the abstraction.  That's *sometimes* desirable
anyway, but in many cases, you want the client to get the whole
abstraction in one with_clause.  And you don't want to have extra names
polluting the namespace (sometimes you end up needing a name for the
child package, *and* names for some stuff inside it).

> Of course, you won't be able to use it from the body of the parent, but if you put it
> in a visible part, it's presumabely for external use.

It's likely for *both* internal and external use.

Instead of Elab_Body in the parent, you can put Elab_All(Parent) in the
child.  Then the parent body can 'with' the child (so long as it doesn't
call it during elaboration).

But often you want access to the instance in the private part of the
parent, so the child idea won't work.  For example, the private part has
a record component that is of a type declared in the instance.

A related problem is that you can't pass a private type to a generic (in
the same package visible part where the private type is declared).
I understand the reasons behind this rule, but it's still very
annoying.

- Bob

Re: Instanciation in a package spec.

[Robert A Duff]

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

> >The problem here is the elaboration model of Ada.  The *visibility* of
> >things is too closely tied to the *elaboration* order.  I have worked
> >out a different model of elaboration that doesn't have this problem (but
> >still retains all the advantages of the Ada model).  Unfortunately, it's
> >not Ada.
> 
> Why it cannot become Ada?

My model would require incompatible changes to Ada.
Therefore, it would be suitable for a from-scratch language design,
but it is not suitable for a modification to Ada as it stands today.

> In other words, what is the price of your model?
> 
> Can  X become static (in your model), when F is pure?

Well, I have ideas along those lines, but I think that's a separate
issue.  It depends exactly how "pure" is defined.  Are you willing to
tolerate pure functions with infinite loops?  So the compiler will go
into an infinite loop evaluating a call to F at compile time?
Sounds OK to me, but it might surprise some folks.

Ada currently has no pragma Pure for individual functions.  Just
packages.

Ada currently allows machine-code inserts in pure code.  Must the
compiler have access to the target machine during compilation?
Is it even meaningful?

- Bob

Re: Instanciation in a package spec.

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> >The problem here is the elaboration model of Ada.  The *visibility* of
>> >things is too closely tied to the *elaboration* order.  I have worked
>> >out a different model of elaboration that doesn't have this problem (but
>> >still retains all the advantages of the Ada model).  Unfortunately, it's
>> >not Ada.
>> 
>> Why it cannot become Ada?
> 
> My model would require incompatible changes to Ada.
> Therefore, it would be suitable for a from-scratch language design,
> but it is not suitable for a modification to Ada as it stands today.

One can call a surgeon now, or wait till a butcher comes. (:-))

>> In other words, what is the price of your model?
>> 
>> Can  X become static (in your model), when F is pure?
> 
> Well, I have ideas along those lines, but I think that's a separate
> issue.  It depends exactly how "pure" is defined.  Are you willing to
> tolerate pure functions with infinite loops?  So the compiler will go
> into an infinite loop evaluating a call to F at compile time?
> Sounds OK to me, but it might surprise some folks.

pragma Limit_Compile_Time (<time-in-seconds>); -- (:-))
 
> Ada currently has no pragma Pure for individual functions.  Just
> packages.

Yes, that is bad.

> Ada currently allows machine-code inserts in pure code.  Must the
> compiler have access to the target machine during compilation?

Target machine emulation, ooch. I'd better drop machine-code insertions for 
pure code.

> Is it even meaningful?

The problem is how far one could go. Compile-time static objects used at 
run-time may still require some sort of additional elaboration before first 
use. I.e. an object could be potentially elaborated twice. How to reconcile 
that.

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