Everything Is References

Is there a language in which variables, function arguments, etc, are always references by default?

For example:

int x = 5;
int y = x;
y++;  // x and y are both 6

If you really did want a copy of something, you'd have to use a keyword:

int x = 5;
int y = copy(x);

And pass-by-value would also have to be done explicitly:

void func(int z)
{
   int w = copy(z); // now w is effectively "local"
}

It would force programmers to at least be aware of the fact that they're making a copy.

typedef int32_t int[1];

Java is like this if you use boxed primitives instead of primitives.

>>3
They were kept, in the beginning, to get around early version performance issues; however, primitives are retained in Java because they remain immensely useful.

>>3
So you're telling me that my idea was already done by Java.
This is possibly the saddest day of my life.

>>5
It was also done by some toy esolang, but in the way you described (but with no call or similar).

It's also been done by Lisp and all derivatives. See lambda.

Haskell

>>1
All Lisps are like this. Lots of other languages too, like Python and Smalltalk.

You don't notice it in Python (and friends) because many objects that look like value types are actually immutable references. So when you pass an integer to a function and it does "foo += 5", that's actually translated to "foo = foo + 5". This code means a new integer object is created which is the sum of foo and 5, and then the assignment changes the foo reference to point to the new object. This way it doesn't change the integer object you called it with.

In Lisps though (well except Clojure), there are no immutable objects. If someone passes you an int, you can set! or setf on it, and they get the change as well (since it's the same object). This makes it very flexible and powerful, but also difficult to compile efficiently. You need whole-program analysis to verify that a tree of functions will not modify your int in order to pass it on the stack or in a machine register; if the compiler can't prove that it won't be modified, then it needs to heap-allocate it and pass in a pointer (leaving it to be garbage collected later.)

>>5
No, your idea was already done in 1958 in the first version of Lisp. Don't feel bad though; it's a really good idea.

>>6,8
Well, I was clearly implying doing it in C and no one has done that, right?

>>9
#include "void.h"
mainstart;
union xy{
int x;
int y;
} xy;
xy.x=5;
xy.y++;  // x and y are both 6
printf("%d",xy.x);
mainend;

>>1
Even worse.  The Mac game "Avara" had a particularly nasty scripting system.  Imagine you ran the following code:

[code]
x = 3;
y = x + 1;
x = 5;
[code]

The value of "y" is now 6.

>>8
In Lisps though, there are no immutable objects. If someone passes you an int, you can set! or setf on it, and they get the change as well (since it's the same object).

Uh, no. That would be stupid. Especially considering that SETF operates on places, not values.

>>11
Nasty? Sounds fun to me!!
But really, lazy evaluation in a scripting language?

>>7

In Lisps though (well except Clojure), there are no immutable objects.
and Scheme
If someone passes you an int, you can set! or setf on it, and they get the change as well (since it's the same object)
Wait, what?
* (defvar x 1)
X
* (defun foo (x)
    (setf x 2)
    x)
FOO
* x
1
* (foo x)
2
* x
1
Am I missing something?
I think you have made a slight misjudgement on your part, what you are saying is that any identifier can conceivably be modified, which is true, but that isn't to say that the identifier cannot be referencing an immutable object. It's funny that you made this mistake in regard to Lisp, as you didn't with python.

As for examples of immutable objects in Scheme, one can argue that all the non-aggregate types e.g. symbols, numbers and characters are immutable, certainly there are no defined mutators for them. As for aggregates, Record types in both srfi 9 and r6rs can have immutable slots, srfi 69 hashtables can be immutable, as can the return value of hashtable-copy. Anything returned from a quoted expression is allowed to be immutable, but I don't think this is a requirement. And the draft srfi 101 (random access lists) is purely functional.

.NET languages like C# also support boxing.

in BCPL, the language on which C is based on, all variables are pointers

>>15
Bah, a number was a bad example to use here. (I don't actually know Lisp terribly well.) So correction: a few primitives are value types in Lisp (mainly numbers and symbols). It's somewhat like Java in that regard. Almost everything is passed by reference in Lisp, including cons cells, so the caller can modify them (although some implementations, e.g. Racket, don't implement set-car! and set-cdr!).

I realize this doesn't fit the OP's definition of *everything* anymore so nevermind Lisp. Python, Smalltalk, Ruby, etc. are much better examples.

>>1
What is the benefit of having this feature?

>>19
As he said, it's to make bad programmers aware that they're copying values instead of references — which is retarded, as is the concept of reference itself: inflexible syntatic sugar for idiots who don't know how to use something as simple as a pointer.

In this case, it also makes literals and variable names have totally different semantics, when they should obviously be interchangeable. For example, the statement 'y = 5;' means regular value assignment, as expected; but 'y = x;', despite looking much like the previous one, means changing the reference.

If they don't know that, they shouldn't be in this business of ``programming'' in the first place.

>>20
which is retarded, as is the concept of reference itself: inflexible syntatic sugar for idiots who don't know how to use something as simple as a pointer. [..] For example, the statement 'y = 5;' means regular value assignment, as expected; but 'y = x;', despite looking much like the previous one, means changing the reference.
That's not true of all programming languages. It's not even true of most languages. In fact that's only true of a certain class of statically typed languages: C, C++, C#, Java, D. And most of those languages don't even have pointers!

In a language like Python, when you type a literal 5, an immutable garbage-collected object is allocated on the heap with value 5. The line "x = 5" assigns the reference 'x' to the newly created object containing 5. The next line "y = x" assigns the reference 'y' to the reference in 'x', which is the same object.

I guess since you don't know that, you shouldn't be in the business of programming.

>>21
Excuse me, but I'm speaking about efficient languages and implementations, not toy dynamically-typed scripting languages.

when you type a literal 5, an immutable garbage-collected object is allocated on the heap with value 5

That's just so much more efficient than just moving a "five" to a 32-bit word in memory; also, GC. It's laughable that you attempted to make a point out of it.

Maybe you should keep yourself locked in the world of FIOC and Guido's S&M slave dungeon and not ever venture out of it again.

>>1
int x = 5;
int y = x;
y++;  // x, y, and 5 are all 6

>>20,22
Oh, Ctards. Will you ever learn?

Hating on C++ is so old skool.

In Perl 6 pass by ref is default. Also, immutable by default:

sub foo($x)         { $x++; } # error
sub bar($x is rw)   { $x++; } # ok
sub baz($x is copy) { $x++; } # ok

bar(2); # sorry no
baz(2); # ok

But assignment is still by copy. Except when it isn't.

>>9
Well, I was clearly implying doing it in C and no one has done that, right?
Is there a language in which variables, function arguments, etc, are always references by default?

>>27
Other Perls did it too.
sub butt { $_[0]++; }

>>29
Yeah, although that's not idiomatic... except in the case where you explicitly want to modify the passed value and do little else. Thanks to the lack of proper signatures, Perl 5 subs tend to be written with an assignment right off the hop.

>>22
Excuse me, but I'm speaking about efficient languages and implementations, not toy dynamically-typed scripting languages.
Efficiency does not matter for 99% of applications any more. It's 2010, there are more important considerations than speed.

REFERENCES

REFERENCES EVERYWHERE

>>31
That what OpenCobalt developers think. As results its slower than Second Life and occupies twice the ram.

>>33
OpenCobalt obviously falls into the 1% of applications where speed matters. It contains a 3D engine for fuck's sake, of course speed matters.

>>31
Are you on the Crysis dev team?
>>34
1% of applications where speed matters
Well, the entire gaming industry somehow manages to squeeze into that 1% of the world's applications, along with all embedded software that controls absolutely anything important, along with all operating systems...  even web browsers compete to see who loads a page faster.  So what is this remaining 99% of applications?  iPhone apps?

>>35
More like use the right tool for the job amirite? Some program applications have high effiency demands. Others are not worth the extra effort for efficient management of resources.

>>35
Surely you are trolling. Yes, all 3D games do fall into that 1%.

The vast majority of the applications on your computer are not performance critical. Just look at all the programs you have running right now. Look at your system tray. There are all sorts of apps and tools that just do not need to be written in a bare-metal language.

You are also forgetting that most software is actually internal business software; it is never made available to the general public. It's just software that businesses develop internally or have commissioned to be developed for internal use. Except for a few specific use cases (like high-speed trading), this shit does not need to be written in a bare-metal language; it is better off being written in something safe and high-level, because bugs are a far more important consideration than speed.

>>37
Wow, you are the reason that it's been so easy for me to get unexpectedly high-paying jobs, and I had no idea until now.  I shouldn't even argue with you...  I should encourage all developers to think like that.

Just look at all the programs you have running right now


Name     | Efficiency matters?
---------+--------------------
Firefox  | Yes
My IDE   | Yes


Those are all the applications that I have running.

I'll assume that you intended to include low-level shit so let's take a look at those:


Name            | Efficiency matters?
----------------+--------------------
Windows         | Yes
Explorer        | Yes
Network shit    | Yes
Video drivers   | Yes
Sound drivers   | Yes
Mouse driver    | Yes
USB drivers     | Yes
Keyboard driver | No

>>38
Wait, I just launched another app.


Name    | Efficiency matters?
--------+--------------------
Winamp  | Yes

>>37
A lot of Financial software is written in functional languages nowadays, so writing to the bare metal may be getting less important (or Ocaml has better performance than I thought)