> But Java isn't pass-by-reference
I didn't say it was. I said that insisting it is pass-by-value isn't helpful.
The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts.
I didn't say it was. I said that insisting it is pass-by-value isn't helpful.
The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts.
Having thought about it for a minute or two, it seems pretty silly to me . Types are all about restricting the set of values an expression can have, and restricting the set of operations you can perform on an expression, such that any operation you're allowed to perform on a value will always do something sensible. Untyped languages don't do that, which makes them quite different from typed languages. But then i've only thought about it for a minute or two.
I could imagine a genuinely unityped language. Perhaps one where every value is a vector of real numbers with an infinite number of zeroes on the end, and the operations are piecewise arithmetic, dot products, interleaving, appending, etc. That would behave quite differently to the languages where you get "undefined is not a function" and friends.
I think Harper would take issue with it being explained this way, but one can think of Ruby and Python being languages where everything is a pointer to a HashMap and everything else is just sugar on top of that (similar to the above argument about Java and the sugar with the pointers).
I don't think Harper would like that way of explaining it because it's over-focused on an example instead of sticking to the concept and because it conflates (statically-knowable) types with (runtime) classes, which is big no-no with him.
This is in contrast to, say, Java, where (2/3) can be part of a valid program, but ("abc"/3) cannot, so 2 and "abc" cannot belong to the same equivalence class.
Yes. Python e.g. is more unityped (union typed, things have a type, but are handled as a union among several options) than untyped. tcl, on the other hand, is more untyped (everything is the same thing: string-like).
The whole “pass by x” really confuses things. It’s really more “represented by foo” underlying the passing that is important.
It's still only two concepts, there's just the side effect of Java and friends' implicit pointers that makes things muddier. The Java function
void swap(Object x, Object y) {
Object temp = x;
x = y;
y = temp;
}
void swap(void *x, void *y)
{
void *temp = x;
x = y;
y = temp;
}
I think the best approach is to just call it what it is, pass by value, and then also remind people if need be that objects are always pointers so it's passing a pointer by value.
I respectfully disagree. Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion.
Its abstract computation model is entirely equivalent to if someone did `typedef object_val *Object`, made `.` do the same thing as `->` and got rid of `->`, and then said you could only have `Object` variables, not `object_val`s. Saying that that's enough to make it not pass-by-value anymore seems ridiculous (especially when Java does still have primitives). If that were enough to make it something else, then following a style guide for C could make your code not pass-by-value anymore.
I understand what you're saying about the helpfulness to learners, but I think that they would be better served by just learning that Java classes are all reference types, their value is a reference to an object that '.' dereferences and so on, and that even if you don't want to use the word 'pointer', they happen to behave exactly like pointers. The reason I think that's better is because it also covers other common mistakes, like initializing multiple variables to the same instance and expecting copy semantics. The same mistake is being made in both that and the swap function from earlier, but the term 'pass-by-value' could only be to blame for one of them. Once you have your head around reference types, there's no problem with calling it 'pass-by-value'.
0: https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html...
Dog d means "a pointer to a dog object"
By forcing "pass-by-reference" to mean two things you are creating ambiguity that is trivially resolved by correctly interpreting a java type signature.
Yes, but the two variants that matter most are both pass-by-value.
There is not a single language in common use today that is pass-by-reference by default. In fact, only C++ (and Pascal, but who uses Pascal any more?) even allows this as an option.
And they are perfectly distinguished by being value types or reference types.
You are insisting that the definition is changed. Emulating call-by-reference in a call-by-value environment does not change the semantics of the language.
Just accept that the meaning you project to these terms is different from their real meanings. Don't try do redefine them and convince the rest of the world that your meaning is the right one.
I do also think lisper is absolutely terrible at making that point.
Every single one of these arguments between call-by-value and call-by-reference I've seen always fall apart because the arguers never accept that there's (at least) 3 forms of calling, whatever we want to call them.
> and sometimes called pass-reference-by-value in some communities
Or call-by-value-of-reference. It's too much of a mouthful, but is the usual alternative I hear.
Furthermore, the term is so useless, that most people only encounter it in debates about its meaning.
As calling conventions, pass-by-value, pass-by-reference, pass-by-name.
Then there is another meaning that comes from misunderstanding the exact definition or trying to guess the meaning. Lisper is trying to argue for that. This definition is not used anywhere where programming language semantics is written down. It lives in the realm of blogging and forum postings.
Ask some linguists - language is not math, it is more like biology. Context matters. People decide for themselves. e have no UN body that defines for each and every person in the world what something means.
What you refer to is that some groups of people WILL indeed define something, but that is for their own special communication in their field. Nobody is bound to that definition either, even the very same people may use the same word much more loosely in a different context.
We have lots and lots of words that have different meanings in different context and/or to different people. That's okay -language is as human as we are.
Nobody owns language. People decide for themselves what they want and how they use it. The "authorities" - the linguists compiling things like dictionaries, do so by looking at how people use something, and then they document the many different usages as they appear. You can only dictate language when you have a means of control over people outside of language, or if you get others to agree.
.
In response to mark-r:
Meanings change all the time, often the original idea is not even part of a new meaning any more. So asking what someone who first used a word meant is useless too.