Re: Constant as anonymous functions : the outer space beast is back

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

On 5 fév, 22:51, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Right, but that wouldn't be true in your suggested semantics, as the Count
> object would be overloadable. Even if you restricted that only to constants
> (of which Count is one).
As you noticed later, Adam better expressed my implicit though, when
he talked about the Constant keyword, so this wouldn't apply the Count
of the example.

> It's clear that you haven't thought this through very well. Adam notes
> that  you could just change the behavior of constants declared with
> "constant", but that makes no sense -- a renames of a constant object
> does not include the keyword constant. So such a "simple" rule
> wouldn't work.
I confess the rename case is a thorn there.

Good or bad, by the way ?

I not aware enough of some rationale, but I feel the Constant keyword
should be part of Constant renaming.

I'm not to suggest about it, I'm just noticing.

> Moreover, it doesn't make sense to treat constants and variables
> differently.
Does it make more sens to treat functions without parameter and
constants differently ?

> The only sane choice is to change the behavior of *all*
> objects -- there is nothing that special about constants. Treating constants
> and variables differently would introduce a major maintenance hazard. The
> current principle (and one that ever programmer would expect) is that
> changing a declaration from constant to variable (or the reverse) only
> changes whether or not it can be written.
My concurrent though was that programmer could expect that changing a
declaration from constant to pure function only change the
implementation.

> Otherwise it ought to behave
> identically. Making the visibility rules wildly different for constants and
> variables would not have that effect (it's quite likely changing a constant
> to a variable would make some if it's uses illegal using your rule).
Semantically, a constant is not a variable. Whenever you change a
constant to a variable, you are changing either the semantic or the
specification. This objection is thus unsuitable to me. There is no
legitimate reason to change a constant into a variable, unless you are
changing the specification (and in turn, everything relying on it
should be revised anyway). While changing a constant into a function
could be legitimate (this is just changing the implementation, not the
specification).

Why would you turn a constant into a variable, unless you are changing
some specifications ?

> And it is bizarre to say that you are trying to increase consistency and
> then try to treat things syntactically declared one way from equivalent
> things declared in another way. How that could *increase* consistency is
> beyond my comprehension.
Indeed, nothing is guaranteeing I'm right.

> I had seriously proposed making objects overloadable declarations for use
> clause purposes only (mainly to decrease the maintenance hazard inherent in
> use clauses - which is really what you are complaining about),
I don't have any trouble with Use clauses, I am never Using.

> but that idea
> didn't get any traction. So nothing is going to change in this area.
>
>                                  Randy.
I'm not aware of ADA Issues news (I use to receive it, but gave up as
there was too much mails to me), but I may have a look at what you are
talking about.

Thanks for your comments