comp.lang.ada
 help / color / mirror / Atom feed
* Re: Freezing points
       [not found] <leschkes.824503590@ferret>
@ 1996-02-18  0:00 ` Tucker Taft
  1996-02-18  0:00   ` Robert Dewar
  0 siblings, 1 reply; 2+ messages in thread
From: Tucker Taft @ 1996-02-18  0:00 UTC (permalink / raw)


Scott Leschke (leschkes@ferret.cig.mot.com) wrote:

: Could somebody out there simply and clearly enumerate all the items that
: constitute a freezing point for me.

Although I admit RM95 13.14, Freezing Rules, is not my favorite part of 
the reference manual (big <grin>), it does enumerate the freezing 
points, starting at paragraph 3:

 1) The *end* of a declarative_part, protected_body, or declaration of
    a library package/generic package.

 2) A *body* causes freezing of everything declared before it in the
    same declarative part.

 3) Each name, expression, or range causes freezing when appearing within:

     a) generic instantation (including default actuals that 
        are used implicitly)

     b) object_declaration (that is not a deferred constant)

 4) A record extension freezes its parent type

 5) A static expression causes freezing of its type, etc., where it occurs

 6) A non-static expression causes freezing where it occurs, unless
    it is part of a default expression/name; defaults don't cause freezing 
    until they are "used."

: For example, from messing with GNAT it appears that a numeric subtype
: definition with a range constraint constitutes a freezing point.
: ...
: I'm assume this is all perfectly correct from an LRM standpoint but the
: freezing point stuff has me a bit confused.

A range constraint contains two expressions (in general).
Expressions cause freezing, unless they are non-static default expressions.
Hence, a range constraint freezes the type of the range (see 13.14(12))..

: Scott Leschke..................................ph: 708-632-2786
: Motorola, Inc.................................fax: 708-632-3145
: Cellular Infrastructure Group...............email: leschkes@cig.mot.com

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Freezing points
  1996-02-18  0:00 ` Freezing points Tucker Taft
@ 1996-02-18  0:00   ` Robert Dewar
  0 siblings, 0 replies; 2+ messages in thread
From: Robert Dewar @ 1996-02-18  0:00 UTC (permalink / raw)


To add to Tucker's comments on freezing, one thing you will find helpful
is to understand the model behind the rules. Think of code being generated
for various constructs. Now sometimes you need to know the size and
representation of something to generate code, e.g. to generate code to
initialize an object of a type. That's what the freezing is fore, before
you can generate such code for a type, it must be frozen.





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1996-02-18  0:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <leschkes.824503590@ferret>
1996-02-18  0:00 ` Freezing points Tucker Taft
1996-02-18  0:00   ` Robert Dewar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox