Re: By value-result vs by reference

I wrote:
>Background: in Ada programs that depend on whether a parameter is passed
>by reference or value/result (mode in out only) are considered erroneous.


>: The biggest weasel hole around is in Ada, which refuses to take a stand at
>: all, and therefore if your program can tell the difference, it is
>: 'erroneous'.


nebbe@lglsun.epfl.ch (Robb Nebbe) writes:
>The difference only comes up when you start aliasing variables by doing
>things like nesting a procedure in another procedure and using the fact
>that the parameters of the enclosing procedure are global to the enclosed
>procedure and the fact that later on the enclosing procedure will call the
>enclosed procedure thus providing two different ways to access the same
>entity.


Yes. So what's the matter with that? All of object-oriented programming
is predicated on the fact that this aliasing will happen, and it will
work. 'Aliasing' is also not well-defined. If a substructure at _any_
depth is aliased to a global or another parameter, will it be handled
properly? Perhaps not...


>Any time you have concurrent access to a single entity you run into
>synchonization problems if precautions are not taken. The fact that this
>can happen in the same thread of control because of the method of passing
>parameters is unfortunate.


True, but prohibiting aliasing of parameters with each other and with
global variables won't fix this problem with _concurrent_ access.


>As another poster mentioned you have to look at the semantics of the whole
>language. The problem I see is that aliasing makes the difference between
>reference and value/result evident. To what extent aliasing is needed
>(especially aliasing without any precautions) is open to debate but I
>don't think we can leave all the blame on the door step of value/result.


The issue is one of semantic consistency. There is no easy place to draw
the line, so the only solution is not to draw one in the first place.
Type systems that have 'nonlinear/potentially aliased' objects will have
to allow such aliasing, and make sure that it works correctly. If you
don't want to allow such aliasing, build the restriction into your type
system with 'linear types', and then you have a much cleaner and more
portable solution to the aliasing problem.


>A good question would be how often a programmer can unknowingly alias a
>variable thus creating an implicit dependency of the method of parameter
>passing.


I have shown how _any_ use of pass-by-value/result can be used to
compromise an Ada 'limited private' type for which assignment by the user
is not allowed. It is true that the way I compromise it is 'erroneous',
but I am not aware of any compiler or interpreter which performs the
necessary checks to detect the error. The reference is:


Baker, H.G. "How to Steal from a Limited Private Account -- Why Mode IN
OUT Parameters for Limited Types _Must_ be Passed by Reference". ACM Ada
Letters XIII,3 (May/June 1993), 91-95.


A better question is how many people are going to get killed when a
compiler substitutes copying semantics for by-reference semantics in the
name of 'efficiency'. The program may be erroneous, but the people will
be just as dead. I think that 'semantic consistency' has the capability
to save lives in mission-critical systems.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.