comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: 'Protected' abstract subprograms
Date: Mon, 20 Jan 2014 19:21:54 -0600
Date: 2014-01-20T19:21:54-06:00	[thread overview]
Message-ID: <lbki3h$3l0$1@loke.gir.dk> (raw)
In-Reply-To: wccob37vfxe.fsf@shell01.TheWorld.com

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccob37vfxe.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>> news:wccvbxje5sn.fsf@shell01.TheWorld.com...
>> ...
>>> The freezing rules make my brain hurt.  Even though I had a hand in
>>> writing them!  ;-)
>>>
>>> A better-designed language would not have anything like freezing rules.
>>
>> That's a facinating assertion from the guy that's responsible for most 
>> the
>> AARM notes describing the freezing rules. Especially as you guys pretty 
>> much
>> redesigned that area in Ada 95 -- you essentially created a whole new
>> language design for it.
>
> Not really.  Ada 83 had "forcing occurrences" regarding rep clauses.
> And I think a bunch of similar rules regarding premature use
> of private types.  IIRC, we decided that these two sets of rules
> should be combined.  Also, the rules were buggy, and we wanted
> to fix them.
>
> The actual rules in Ada 95 are almost the same as in Ada 83.  They
> don't look the same, because the wording was changed a lot.  But
> the things that are legal and illegal in Ada 83 didn't change
> much in Ada 95.
>
> In other words:  Don't mix up "the Ada language" with "the words we
> use to describe the Ada Language in the RM".  The latter can change
> without changing the former.  And in this case, the latter changed
> a lot while the former changed a little.

Of course, I know this, but I don't really think that this is relevant. You 
("you" meaning Ada 9x team here since I don't know for sure who did what) 
could have changed the language more (since you guys had already decided to 
change the wording drastically), but you didn't. I would say that was mainly 
because it wasn't really possible to change the language further without 
changing it's philosphosy. After all, you did make a number of cases illegal 
that were legal in Ada 83.

>>... It makes me wonder how a language could be better
>> designed and not "have anything like freezing rules".
>
> Well, I'm too lazy to give all the details, but here's one key point:
>
> It is obvious[*] that module specs should not be elaborated.  They should
> be purely a compile-time description of the interface, and should not
> exist at all at run time.
>
> [*] I'm just kidding about "obvious".  It took me years to figure that
> out.  But having done so, it's obvious (to me).
>
> Another point:  Something like Ada's aspect clauses are better than
> pragmas and separate syntax for rep clauses.  That's because aspect
> clauses are physically attached to the declaration, so there's less
> of an issue about when things are evaluated.  Also, you don't have
> to refer to the thing by name; you're just saying "this thing has
> so an so properties".  Every time you refer to something by name,
> you put a (slight) burden on the person reading the code, who has
> to match up uses with declarations.

Right. Aspect clauses eliminate quite a bit of the need for freezing rules. 
(Although we ended up using them to describe the semantics of aspect 
clauses, that was mainly historical in nature -- it would have been better 
to wait until the end of the unit for those determinations, but that would 
have not allowed various things legal in Ada.)

I believe your point that a purely compile-time description would eliminate 
freezing. I'm not convinced that such a restriction would really be 
usable -- I suppose it depends on what could actually be described that way. 
(Personally, I find Ada interfaces useless; I much prefer package 
specifications for abstraction. I'm not sure if that carries over to your 
idea.)

Anyway, not particularly relevant for Ada, since we're surely not reducing 
what is allowed in a package specification.

                            Randy. 




  parent reply	other threads:[~2014-01-21  1:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 22:00 'Protected' abstract subprograms sbelmont700
2014-01-10 22:30 ` Randy Brukardt
2014-01-11 16:12   ` sbelmont700
2014-01-14  3:45     ` Randy Brukardt
2014-01-14  9:05       ` Dmitry A. Kazakov
2014-01-15  0:36         ` Randy Brukardt
2014-01-15  9:17           ` Dmitry A. Kazakov
2014-01-15 14:11             ` Robert A Duff
2014-01-15 15:40               ` adambeneschan
2014-01-15 21:21                 ` Robert A Duff
2014-01-15 23:10                   ` Randy Brukardt
2014-01-16  0:51                     ` Robert A Duff
2014-01-16 10:43                       ` AdaMagica
2014-01-16 16:32                         ` adambeneschan
2014-01-17  1:49                         ` Robert A Duff
2014-01-17 23:23                           ` Randy Brukardt
2014-01-19 21:07                             ` Robert A Duff
2014-01-20  8:40                               ` Dmitry A. Kazakov
2014-01-21 14:37                                 ` Robert A Duff
2014-01-22  8:27                                   ` Dmitry A. Kazakov
2014-01-21  1:21                               ` Randy Brukardt [this message]
2014-01-21 14:35                                 ` Robert A Duff
2014-01-15 23:17               ` Randy Brukardt
2014-01-16  8:52               ` Dmitry A. Kazakov
2014-01-11  8:41 ` J-P. Rosen
2014-01-11  8:59 ` Dmitry A. Kazakov
2014-01-11 13:42   ` Niklas Holsti
2014-01-11 19:35     ` Dmitry A. Kazakov
2014-01-12  9:19       ` Niklas Holsti
2014-01-12 10:22         ` Dmitry A. Kazakov
replies disabled

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