"cast away const" (was Re: Array of Variant Records Question...)

[Mark Lundquist <mark@rational.com>]

Matthew Heaney wrote:

> In article <37D96965.81045235@rational.com> , Mark Lundquist
> <mark@rational.com>  wrote:
>
> >> That seems just *too* kludgy to me, and very implemention
> >> dependent, wouldn't it be better to just introduce in out
> >> and out parameters for functions (but we know that one won't
> >> fly ...)
> >>
> >
> > Why would that be necessary, since functions already can have access
> > parameters?  OK, the actual must denote an aliased view...
>
> It's like I said in another post: sometimes you have an operation that is
> publicly in-mode, but privately in-out.
>
> The function Random is declared this way:
>
>   function Random (G : in Generator) return Result_Subtype;
>
> From an abstract point of view, Generator provides a stream of random
> numbers, and function Random simply returns successive values from this
> stream.  The stream is just out there, in the ether, and no modification of
> this stream is required.

At this level of abstraction, something like a self-advancing iterator would
look similar.  It's not that much of a stretch, even though everyone knows that
the iterator must have state and that the state must change when the iterator
advances.  But it's not like you really want to say "extract the value, and oh
by the way update the iterator, too..."  You really just mean, "I'm giving you
the iterator to operate on", i.e., in-mode.

>

> From an implementation point of view, however, invoking the function Random
> changes the state of the Generator.  That's why you need a way to "cast away
> const," to be able to change state of an object whose parameter mode is in.

I've been trying think from your "abstract point of view" about objects whose
type view is limited private.  What exactly can "state" mean from this
perspective?  You don't know about its components, can't assign it, can't test
equality.  Isn't the idea "state" of an opaque object kind of problematic?
Suppose that in the bodies of primitives of types whose partial view is limited
private, an in-mode parameter declared a variable view instead of a constant
view (in other words, if the differentiation of in-mode vs. in-out-mode were
annulled).  A bizzarre idea on the face of it, but -- what would be lost?
(Not that I think this would actually be a good idea...)

Why do we have parameter modes in the first place? It's so that intent is
communicated explicitly, esp. to programmers who are going to code against the
subprogram declaration.  We could have only mode in-out, as is the case in Java
-- then it's this expressiveness that would be lost, but in the case of limited
private types it sort of collapses.

If the language adopted your cast-away-const operation, should it be available
only for types whose partial view is limited private, and then only where the
full view is visible (i.e. in the body?)