*start*
01729 00024 US
Date: 26 Sep 1979 4:57 pm (Wednesday)
From: Lampson
Subject: Re: Short Operator for Narrow
In-reply-to: Your message of 26 Sep 1979 1:15 pm (Wednesday)
To: Horning
cc: Deutsch, Cedar-Lang↑, McKeeman
I don't like it. Another piece of oddball syntax is the last thing we need. It
seems to me that most of the time the TypeSpec and CatchSeries will be empty, so
that brackets are not needed. In fact, as I have said several times before, I think
it is a BIG mistake to require any explicit operator in going from ANY to a
specific variant. There should be automatic narrowing on assignment of ANY to
a specific variant (of course including opaque types and REF TO ANY), and I
don't see anything wrong with the full form in other cases.
I think that the language committee has been very dense about this issue, and
about the issue of VAR parameters, and I am getting increasingly upset about it
over the last couple of months (I am now shouting, in case you didn't notice).
You are making decisions which are going to make the language substantially
clumsier and more irritating to write programs in, solely on methodological
grounds which are extremely flaky and poorly supported. Why not require a
catch phrase to check for overflow on every addition, anyway?
I also want to strongly reinforce a remark of Ed Satterthwaite's: there is an
unfortunate tendency to choose longer keywords. We shouldn't have
REFERENCE when we can have REF; because it's like Algol 68 is no reason to
be against it. I would like to see brackets instead of, or in addition to, BEGIN
and END, like Bcpl; we already have that for records. And NAR for NARROW
will do if nothing better comes to mind. Or, how about FIX?
*start*
00667 00024 US
Date: 26 Sep 1979 2:54 pm (Wednesday)
From: Horning
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 4:57 pm (Wednesday)
To: Lampson
cc: Horning, Deutsch, Cedar-Lang↑, McKeeman
Butler,
I'm having great difficulty reconciling Ed Satterthwaite's position that we could
easily dispense with BOTH internal references (i.e., @ applied to frame variables)
and VAR parameters, and your position that we have reached the point where
VAR parameters are ESSENTIAL.
Ed bases his claim on examination of existing Mesa code, not on methodological
grounds. Would you care to elaborate the (non-methodological) case for VAR?
Jim H.
*start*
01066 00024 US
Date: 26 Sep 1979 6:29 pm (Wednesday)
Sender: Horning
Subject: VAR Parameters
To: CSL↑, PE-Interest↑
From: Cedar-Lang↑
Mesa does not have VAR (or "reference") parameters: all parameters are "passed
by value," although the value may itself be a pointer.
It has been proposed that Cedar Mesa should add the VAR mode of parameter
passing. The implementation issues are reasonably understood. The real point of
dispute is how much leverage this feature would give us in increasing
programmer productivity, relative to other changes we are considering.
Although we do not propose to settle the matter democratically, we are interested
to know how many potential users of Cedar (or present users of Mesa) feel that
this is an important feature. If you care, please send me a message, which can
be as simple as a number from 0 (wouldn't use it if you gave it to me) to 10
(most important language change being considered for Cedar), or can be a
diatribe of any length for or against.
Jim H., for the
Cedar Language Features Design Committee
*start*
00296 00024 US
Date: 26 SEP 1979 1905-PDT
From: AYERS
Subject: VAR parameters
To: horning
Life is basically complicated. I'd be happiest if parameters
were always "by value" or always "by reference". Since Mesa
already has the former, I'd just soon not see the latter.
Bob
-------
*start*
00843 00024 US
Date: 26 Sep 1979 9:26 pm (Wednesday)
From: MBrown
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
Since we now understand that the @ operator is safe, the only issue is its cost in
the frequently-used cases when it is used to simulate VAR parms. This is a
question that will not benefit much from speculation on my part. My feeling on
a gut level is that procedure invocations must be kept as inexpensive as possible
so that programming styles won't be adversely affected. On this basis I would
vote for VAR parms. But other changes (like eliminating the diversity of array
constructs while allowing "sequences", and simplifying the language in other
ways (when I think about CARDINALs I get a headache)) might increase overall
productivity more.
--mark
*start*
00198 00024 US
Date: 27 Sep 1979 8:27 am (Thursday)
From: Levin
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
Importance rating: 2.
*start*
00187 00024 US
Date: 27 Sep 1979 8:32 am (Thursday)
From: Nutt
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
Jim,
3
Gary
*start*
02587 00024 US
Date: 26 SEP 1979 2036-PDT
From: CROWTHER
Subject: Re: VAR Parameters
To: Horning
cc: CROWTHER
In response to your message sent 26 Sep 1979 6:29 pm (Wednesday)
Jim,
A. I don't really know what VAR parameters are, so this answer is
a bit soft, but here goes anyway:
B. If VAR parameters are a means of preventing me from screwing
myself by making certain operations on the parameters
illegal, I rate them 0 on your scale of 0-10. I never make
that kind of error.
C. If VAR parameters are part of the handle concept, by which I
can create an interface with handles of unique but
unspecified type, then they are very important. Mesa objects
are a good idea, but unfortunately the present mesa does not
support them because the details of the innards of your
implementation of an object must be right out
there in the interface itself. I cannot rate this on your scale of
0-10 because I don't know the other contenders.
D. As far as I am concerned, the mesa language is just fine as
it is. The environment, on the other hand, is shitty.
So the features I want most to see in the compiler are those
which aid in the improvement of the environment. This in turn
consists of three parts:
1) The building up of a super library of useful building
blocks - blocks which will fit together!! And that means
mostly clean interface definitions.
2) Making the "system" features accessable to the programmer
from somewhere other than the command line. In particular
giving the programmer access to the compiler and the editor.
3) The creation of a useful debugger. This, I believe, means
bringing the dirty innards of the compiler out into the
sunshine, where the creative implementer can get at them.
The present system, where the debugger people had to create
a new language which looks a lot like mesa, and then figure
out how to interpert it in a mesa programs context, is quite
insane.
4) (I know I said three, but what the hell) Getting the type
definitions out of the compiler and into the run time
-- somehow -- so that things like remote procedure
calls and data base stuff and debugger stuff can work.
I don't mean system automatically checking types for me, I
mean letting my program ask the compiler for
a data structure which will represent the type of something,
and later asking the compiler (at run time!) to
give me code for dealing with that type.
-------
*start*
00471 00024 US
Date: 27 Sep 1979 9:39 am (Thursday)
From: Purvy
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
I think it's of no importance; rate it 1 (I'd probably use it, but wouldn't miss it a
bit if it were absent). I've used languages both with and without, and Mesa
doesn't throw any roadblocks in my path that I'm aware of.
Incidentally, I'm not a potential user of Cedar, if that matters.
Bob
*start*
01390 00024 US
Date: 27 Sep 1979 9:45 am (Thursday)
From: Horning
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 SEP 1979 2036-PDT
To: CROWTHER
cc: Horning
Will,
A. VAR parameters would be an ADDITIONAL mode of parameter passing, in
which the address, rather than the value, was passed to the procedure. Of
course, pointer-valued parameters already give you the capability of doing this,
but they have two drawbacks:
-At the point of call, you must say @V, rather than just V.
-Within the procedure, the pointer values can be treated like ordinary pointers
(in particular, copied), which means that the frames into which they point must
be reference-counted, whereas (as long as ports and coroutines aren't used), all
uses of a VAR parameter are guaranteed to expire before the frame of the caller,
so reference-counting isn't needed.
B. No, they don't keep you from doing anything you can do now. They might
make some things somewhat more convenient/efficient.
C. They are independent of the handle concept, which is something we are
working on anyhow, under the general heading "exported types and objects."
D. We are working on all these things, but consider them independent (except as
demands on our time and creativity) from the VAR parameter question.
With these clarifications, am I correct in interpreting your response as
approximately a 1?
Jim H.
*start*
00790 00024 US
Date: 27 Sep 1979 9:57 am (Thursday)
From: DaveSmith
Subject: Re: VAR Parameters
To: Horning
Jim,
I am astonished that the Cedar group is seriously considering putting call by
name into Mesa! That was the single biggest mistake of Algol. Far from
increasing programmer productivity, it's use often has disasterous consequences
which REDUCE programmer productivity. I am very much against the school of
language design that says "Since we know how to do it, let's do it." I urge you
to resist the trap of call by name. I give it a fat zero on my scale of langauage
features. I assure you I will never use it.
But even more, I am very disappointed in you guys. You're supposed to be
designing new, innovative features, not resurrecting old dinosaurs.
Dave
*start*
00309 00024 US
Date: 27 SEP 1979 0958-PDT
From: MCGREGOR
Subject: VAR parameters
To: Horning
1.
Seems of marginal value, since it wouldn't let you do anything you
couldn't do now, and there's the added complexity to the user of parameters
that can be passed in more than one way.
Scott.
-------
*start*
00432 00024 US
Date: 27 Sep 1979 10:11 am (Thursday)
From: Karlton
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
This piece of syntactic sugar (given that a parameter now could be a pointer) is
worth about a two (2). It might cause more confusion that it is worth as people
ponder over some implementation wondering if a parameter should be a pointer
or a VAR.
PK
*start*
00246 00024 US
Date: 27 Sep 1979 10:12 am (Thursday)
From: Sapsford
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
Given that Mesa provides substitute functions, VAR gets only a 3.
*start*
00782 00024 US
Date: 27 Sep 1979 10:37 am (Thursday)
From: Masinter
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
Cc: Masinter
I think that adding VAR parameters to Cedar is a bad idea.
VAR parameters introduce the possibility of hidden aliasing. Although aliasing is
possible with pointers, at least the possibility is explicit when pointer variables
are used; one has some indication that they might point to the same thing.
Second, it complicates a language which is already too complex, adds more
syntax and removes one of the few pleasing sources of uniformity in the
language.
These indicate that adding VAR parameters might REDUCE programmer
productivity rather than increase it.
My number is: -5.
Larry
*start*
01061 00024 US
Date: 27 Sep 1979 10:46 am (Thursday)
From: Sturgis
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
If the language is planning to restrict the use of pointers, and supplied VAR, I
would use it heavily. Certainly many (if not most) pointer constructs I use in
calling a procedure are really either VAR or to avoid passing many words by
value, but I dont want the called procedure to modify the pointed to record. I
dont think this last is in the spirit of VAR (read only VAR?).
If I had to guess, most of my procedure calls of the form P[..., @foo, ...] are for
the purpose of avoiding actually copying words, and not to allow the caller to
modify the contents of foo.
Normally, If I am passing a pointer for purposes of allowing modification, it is of
some type named something like FooHandle, and I already have it in that
form.
(notice that my first sentence does not exactly agree with the body of this
message. I leave it up to you to figure out what I ment to say.)
*start*
00659 00024 US
Mail-from: Arpanet host MIT-XX rcvd at 27-SEP-79 1127-PDT
Date: 27 Sep 1979 1427-EDT
From: Guttag at MIT-XX
Subject: var parameters
To: horning at PARC
cc: guttag
Jim,
One needs "var" parameters only in langauges in
which the location of a variable is not an expressible
in the denotational semantics terminology) value. My
impression is that in Mesa all locations are expressible.
Hence, it strikes me that var parameters buy very little.
I can't give it a zero rating, since I might use it if it
were there. However, I think adding yet another construct
(when it is clearly redundant) is not a good idea.
John
-------
*start*
00215 00024 US
Date: 27 Sep 1979 11:29 am (Thursday)
From: Maxion
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
I'd use it if it were there.
Roy
*start*
00330 00024 US
Date: 27 Sep 1979 11:44 am (Thursday)
From: Horning
Subject: Re: VAR Parameters
In-reply-to: Your message of 27 Sep 1979 9:57 am (Thursday)
To: DaveSmith
cc: Horning
Dave,
There is an enormous difference between "call by name" (Algol 60), and "call by
reference" (FORTRAN, Pascal, Euclid, ...).
Jim H.
*start*
00769 00024 US
Date: 27 Sep 1979 11:44 am (Thursday)
From: Lauer
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
cc: Lauer
Jim,
I kind of liked the VAR parameters of Euclid and thought they were a good
idea. I suppose that my vote would be a 6. We do simulate VAR parameters in
Pilot a lot by passing a pointer to the thing we really we are really interested
in. We do NOT do this across the public interfaces of Pilot, however, because
we are worried about the client passing in (bad) pointers to unmapped virtual
memory, then getting hysterical when Pilot drops into the debugger from deep
inside itself. Perhaps VAR parameters in the safe language would help use get
around these problems.
/Hugh
*start*
00283 00024 US
Date: 27 Sep 1979 4:14 pm (Thursday)
From: Lampson
Subject: Re: VAR Parameters: Early Returns
In-reply-to: Your message of 27 Sep 1979 11:53 am (Thursday)
To: Horning
I sure am glad it's you that has to correct the respondents' worst misconceptions,
not I.
*start*
00413 00024 US
Date: 27 Sep 1979 12:58 pm (Thursday)
From: Cattell
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
cc: Cattell
0!
[Of COURSE we would use it if you gave it to us! However, it's not only
another feature to a feature-laden language, it's nice NOT having it because this
makes it considerably easier to understand people's programs.]
*start*
00244 00024 US
Date: 27 SEP 1979 1324-PDT
From: DEUTSCH
Subject: VAR parameters
To: horning
I am inclined to think that the dangers of aliasing outweigh the advantages.
However, if they were there I would use them. Value=3.
------
*start*
00352 00024 US
Date: 27 Sep 1979 3:43 pm (Thursday)
From: Mitchell
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
cc: Lampson
Jim,
I would give about a 5 to 6 for VAR parameters. If their implementation is not
too difficult, this would raise my evaluation a point or so.
Jim Mitchell
*start*
00866 00024 US
Date: 27 SEP 1979 1638-PDT
From: CROWTHER
Subject: Re: VAR Parameters
To: Horning
cc: CROWTHER
In response to your message sent 27 Sep 1979 9:45 am (Thursday)
Jim,
Yes, my response is about 0.5 on a scale of 0 to 10. I do understand it
better after your message. As far as I am concerned, it now seems to be
related to efficiency more than anything else. The compiler people
are saying that if I paint some of my pointers yellow I will
win because they can compile safe code for yellow pointers much easier
than they can for regular pointers.
But of course it is pretty easy for them to notice the pointer is yellow
themselves (no pointer↑ in the code).
I suspect in the back of somebodys head is the idea that normal pointers are
bad and should go away. That would scare me, except I can't imagine it
happening here.
-------
*start*
00176 00024 US
Date: 27 Sep 1979 4:53 pm (Thursday)
From: Hon
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
1
*start*
00978 00024 US
Date: 27 Sep 1979 5:30 pm (Thursday)
From: Morrison
Subject: Poll on VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning (cc: Cedar-Lang↑)
If you implement VAR parameters, I would use them. I say this mainly because
I tend to use any such feature that can pass a little work from my shoulders onto
the compiler et al. However, given that they can be simulated easily by passing
an explicit pointer to something, I rate the implementation of VAR parameters as
low in priority -- if you want a number in [0..10], use 1.
It is possible that I could change my mind about the priority and consider them
more useful, if it turns out that the ability to make something become a VAR
parameter by editing the callee and not the caller provides substantial
advantages. I tend to doubt this, particularly in light of the more general issues
of object-orientation styles and multiple pointer dereferencing schemes. -- Jerry
*start*
00699 00024 US
Date: 28 Sep 1979 11:26 am (Friday)
From: Horning
Subject: Re: VAR Parameters
In-reply-to: Your message of 28 Sep 1979 10:34 am (Friday)
To: Birrell
cc: Horning
Andrew,
I agree that, in languages allowing aliasing, VALUE-RESULT is not functionally
equivalent to VAR, and there can be cases where one might prefer one to the
other.
I claim that passing references by value IS, however, a generalization of the
power of VAR; i.e., the only reason one might "need" the latter, given the
availability of the former, is to optimize based on the knowledge of the restricted
nature of VAR (this is the basis of Butler's argument). There are also notational
advantages.
Jim H.
*start*
00623 00024 US
Date: 28 Sep 1979 11:31 am (Friday)
From: Horning
Subject: Re: VAR Parameters
In-reply-to: Your message of 28 Sep 1979 2:10 pm (Friday)
To: Lampson
cc: Cedar-Lang↑, McKeeman
Butler,
I think I understood all that, at least from the time of our conversation in June.
I remain unconvinced that this has a high payoff relative to the other changes
planned for 5C1 (particularly our scaled-down list). The massive indifference
shown by the replies to my message to CSL↑ and PE-Interest↑ at least supports
the belief that most Mesa programmers aren't chafing from this particular
deficiency.
Jim H.
*start*
01081 00024 US
Date: 28 Sep 1979 10:34 am (Friday)
From: Birrell
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
In Boulder this summer I discussed with WG2.4 members (mainly Bill Wulf and
Steve Schuman) about whether VAR parameters needed to be added to ADA,
which at present has only (in AlgolW terms) VALUE, RESULT and
VALUE-RESULT. The arguments for VAR were: (1) in the presence of parallel
processing, it has semantics that are otherwise unobtainable; (2) the theory that a
compiler can optimise VALUE-RESULT into passing an address instead of
copying is not very well supported. I convinced Schuman, but not Wulf, that
programs taking advantage of (1) were not correct programs - they assume
atomicity properties that are not guaranteed; I'm not sure about (2). If you
include VAR in Cedar, you'd better be very careful about the implications of
parallel processing with pre-emptive scheduling. On the other hand, VAR is
immensely better than @ if people feel that they need to pass by reference.
Andrew
*start*
03722 00024 US
Date: 28 Sep 1979 2:10 pm (Friday)
From: Lampson
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 2:54 pm (Wednesday)
To: Horning
cc: Cedar-Lang↑, McKeeman
What Ed said to me is that HIS code is written in such a way that it doesn't
benefit from var parameters, i.e. everything is either passed by value or is in the
heap and a pointer is passed. He also said that he doesn't like var params
because you can't tell at the call site that the param might be modified, while
with @ you can. Of course with @ you can't tell at the called proc that this
isn't a general pointer. The heap scheme gets the worst of both methodological
worlds, since you can't tell anything on either side by looking at the
declarations.
To repeat, pragmatically var is good because
1) Lots of existing programs (and programming styles) using @ will become
catastrophically less efficient if they all end up with internal references and
garbage-collected caller's frames.
2) In many common cases it is both clearer and cheaper to allocate storage in a
local frame and pass a var parameter than to allocate it in the heap and let it be
garbage collected: clearer because it expresses the programmer's intentions about
who is responsible for the storage and how it is to be used; cheaper because none
of the collection machinery needs to be invoked.
Ed and I also discussed the problem of var parameters for processes and
coroutines. In these cases care must be taken, since the simple rule that the
caller always exists when the callee is running does not hold. For ports, the
problem is that the parameters of the port are only valid between the time control
comes in over that port and the time it goes out again. Making sure that the
parameters are properly initialized before control has come in is necessary
regardless of var parameters, and the only other action needed seems to be that
the vars should be set to NIL on exit through the port. The source of the
parameters cannot go away, since he is stuck waiting for control to come back
in. (This begs some questions about how to take down collections of coroutines,
but I believe that all these problems exist simply in trying to keep the return
links from dangling, and are independent of var parameters. It may be that the
proper solution in Cedar is always to garbage-collect these frames. In any case,
this is a longstanding problem area regardless of vars).
For a process the caller can disappear, and the mechanism is carefully set up so
that this causes no trouble with the return link. The simplest thing would be to
force a fork with var parameters to make the caller's frame collectible.
These remarks led us to something else: I had been assuming that there would be
a flag in a frame indicating that it should not be freed automatically by a
return, but rather should be left to the collector. Ed had been considering
trying to make the compiler detect the cases in which automatic freeing is
unsafe, but I think I talked him out of that.
Interesting somewhat related observation: Mesa currently has a kind of
dynamically typed variable (much like REF ANY). It is frames. Unfortunately
the discrimination mechanism is not available in the normal runtime, but only to
the debugger, and involves some rather fancy footwork in a variety of complex
data structures, but logically the situation is exaclty like REF ANY: there is a
well-defined procedure which, given an address and the information that it is a
frame, will come up with the type (i.e. the record declaration in the symbol
table). Brad and I set up his interface with this in mind.
Mostly unrelated observation: REF is what Russell calls VAR.
*start*
04682 00024 US
Date: 28 Sep 1979 1:52 pm (Friday)
From: Satterthwaite
Subject: More on VAR parameters
To: Lampson, Cedar-Lang↑
At the risk of belaboring the point, I pass along the following thoughts:
WHY IS CALL-BY-REFERENCE USED/NEEDED IN MESA?
(1) I talked some to Howard about this, since Juniper passes addresses of local
variables more than any other Mesa program I know of. Howard claimed that, in
95+% of the cases, references were being used to implement a cheap form of
call-by-value for relatively large objects -- the callee is not supposed to update
the argument. (In fact, if we do VAR at all, Howard would like READONLY
VAR as a way of enforcing this.) Also, the coding of Juniper was somewhat
distorted by the very inefficient construction and passing of large argument
records in early versions of Mesa - (partially) rectified in more recent versions.
This suggests to me that, whatever the decision about VAR parameters, some
work on more efficient passing of "large" arguments by value is justified. For
procedures private to a single module (ignoring SHARES, which now seems like
a bad idea), the compiler can probably collect enough information to decide
when call-by-value can be replaced by call-by-reference (nearly enough
information to do so is already collected to control the expansion of inline
procedures).
There are other uses of call-by-reference that seem crucial, and I haven't seen
them mentioned in recent exchanges on VAR parameters.
(2) My preferred mode of programming (at least in the compiler) is to write
x ← f[x]
when my intention is to have f update x. If, however, x is a pointer and f
invalidates the old value of x↑, storage is ill-formed until f returns. This is a
particular problem for a programmer trying to maintain the GC invariants in an
unchecked region; for example, if f frees the old value of x↑ and returns NIL.
In general, I think finalization routines will have this problem and will want to
receive the variable to be finalized by reference.
The current Mesa compiler has this problem when, e.g., updating the parse
tree to reflect constant folding. Unfortunately, call by reference doesn't help
because the parse tree is relocatable. I guess we are punting this problem in
Cedar.
(3) In initialization code, there is a related problem. If Mesa ever allows
arbitrary computations to be associated with initialization, an initialization
procedure will want to receive the identity of the new variable by reference
(simply returning a properly initialized value seems to require more special rules
to avoid circularity). Similarly, call by reference is essential for user-defined
procedures intended to overload assignment.
WHAT SYNTACTIC FORM SHOULD BE USED FOR CALL-BY-REFERENCE?
This is mostly a religious issue. I think the advantages and disadvantages are
reasonably balanced:
Use of pointer parameters:
In the caller:
must apply @ to variables (possible updating obvious, but too general(?))
passes pointers (handles) directly
In the callee:
must use ↑ (but unnecessary before '. and '] because of dereferencing rules)
easy to assign value to pointer variables (including more global ones)
Use of var parameters:
In the caller:
passes variables directly
must apply ↑ to pointers (handles)
In the callee:
no need for ↑ (but no local hint of the potential for aliasing)
must use @ to generate a value assignable to pointer variables (incl. globals).
CAN VAR PARAMETERS BE IMPLEMENTED MORE EFFICIENTLY?
The above considerations (especially points (2) and (3)) convince me that good
support for call-by-reference is necessary. I consider the syntactic and
methodological issues a toss-up. VAR parameters therefore seem attractive to me
(at least at the moment) if they offer a more attractive implementation than
internal pointers. Butler's message discusses most of the points that had been
worrying me, but there seems to be at least one further complication:
Suppose that a pointer to a local variable is passed (as a VAR parameter) through
several levels of call and then is converted to an internal pointer by some
callee's applying @ to its VAR parameter. Must the VAR parameter have been
an internal pointer all along? Must the originator's frame have been marked for
GC in the first instance? With the Deutsch design for internal references, it
seems possible to do a conversion (and to mark the originator's frame) on the fly,
but at quite high cost.
If we had VAR parameters, could we consider discarding @ (and internal
references), thereby achieving simplification from the other direction?
*start*
01791 00024 US
Date: 28 Sep 1979 4:37 pm (Friday)
From: Horning
Subject: Re: More on VAR parameters
In-reply-to: Your message of 28 Sep 1979 1:52 pm (Friday)
To: Satterthwaite
cc: Lampson, Cedar-Lang↑
(1) READONLY VAR is pretty wierd. Maybe SHARED? Anyhow, if this is a
compiler hint, rather than a semantic issue, we should perhaps treat it
differently--after all, we just got through being dumped on by our Design
Reviewers for cluttering up Mesa with too many efficiency-oriented distinctions.
(2) (3) I guess I don't see how these bear on this issue of VAR vs. REF value
parameters, which seem to work equally well in these situations.
SYNTAX: I agree with your summary, except I had been assuming that @
wouldn't be allowed on VAR parameters.
EFFICIENCY: If the VAR parameter must be an internal reference, and the frame
marked, all along, then there is no efficiency difference--therefore I assume that
Butler's efficiency arguments are bassed on the assumption that the conversion
and marking are done at the time the @ is applied (if we allow it at all on VAR
parameters). This is nice, because we have to do it for frame variables just
when @ is applied (again, with VAR parameters in the language, we might
decide we needn't allow this). As long as this is rare, we presumably don't mind
paying the high overhead associated with the Deutsch design--it's still probably
less than the incremental cost of garbage collecting the frame.
Certainly, it was my original position that we should ban @ from the safe subset.
I thought I heard arguments for creating internal references to things like arrays
(even if not to frame variables) and storing them in data structures, as well as
passing them as parameters. I'll let Peter and Danny comment on this one.
Jim H.
*start*
00926 00024 US
Date: 28 Sep 1979 5:17 pm (Friday)
From: Satterthwaite
Subject: Re: More on VAR parameters
In-reply-to: Your message of 28 Sep 1979 4:37 pm (Friday)
To: Horning
cc: Satterthwaite, Lampson, Cedar-Lang↑
Points (2) and (3) weren't intended to favor either VAR or REF -- only to
convince me that having some efficient mechanism for passing references to
fields embedded within frames (or other allocation units) is more important than I
had previously thought. Maybe this was completely obvious to everyone else,
but I didn't hear anyone pointing it out when I claimed that internal references
and var parameters were BOTH frills.
I agree with your analysis of the efficiency issues. I would just like to feel a
little more confident that VAR parameters will not turn out to be equivalent to
internal references in this resepect when all the interactions with the rest of the
language are worked out.
*start*
01374 00024 US
Date: 28 SEP 1979 1905-PDT
From: DEUTSCH
Subject: Internal references and VAR
To: Cedar Language Features Design Committee:
cc: lampson
The design for reference-counting internal references that I currently favor
is to do the first-object-in-quantum trick I mentioned to the language
committee, but only do it at the time of reclamation -- that is, internal
references will be reference-counted in their own right, and the counts
will only be merged in with the counts for allocated objects at sweep time.
If it turns out to be a good idea, we can even sort the table of counts
for internal references by location at sweep time, which would make the
search for the enclosing object very efficient.
It is true that constructing an internal reference to a frame requires
marking the frame as needing garbage collection rather than the
ordinary stack discipline. It seems to me that this is just a particularly
unfortunate example of the tension we have felt all along between a totally
dynamic method of detecting dead objects (reference counting) and more
sophisticated methods of compile-time analysis. I personally believe that
the ultimate solution has a considerably larger component of the latter,
but I also have faith (at this point) that we can get garbage collection
to be efficient enough that we won't feel hampered by it.
-------
*start*
00351 00024 US
Date: 30 Sep 1979 10:15 pm (Sunday)
From: Suzuki
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
I would like to have it badly. My preference number is 8.
Nori
P.S. Laurel Answer mechanism seems not optimal. By answering your mail it
gave Cedar-Lang as the addressee.
*start*
00258 00024 US
Date: 1 Oct 1979 8:36 am (Monday)
From: Swinehart
Subject: Re: VAR Parameters
In-reply-to: Your message of 26 Sep 1979 6:29 pm (Wednesday)
To: Horning
For each x|<x is a proposed language change, not enabling a new capability>: 5.