Talk:Language Comparison Table

Is Haskell standardized by some standards body, ISO, IEC etc? (Language report certainly does not qualify as a standard. All languages have reports, since Algol 68 times...) --Dmitry-kazakov 17:48, 22 July 2008 (UTC)

No, it isn't, but the Haskell 98 Report is the standard definition for the language -- all compilers support it, and all compilers have switches to distinguish between Haskell 98 and their own extensions. Like all C compilers support ANSI C. Compare to, say, OCaml, where the current INRIA implementation of the compiler is the standard :-) Or Lisp, or Smalltalk, with their plethora of different implementations. And since it is one of the design goals of Haskell to have the language completely formally specified, I guess one should mention it somewhere.

Is there any reason to distinguish between standards enforced by "official" standard bodies, and those enforced by, hm, "community standard bodies"? --Dirkt 08:14, 23 July 2008 (UTC)

Yes. Standards bodies are here to standardize. So it is up to them to decide what is a standard - an officially published document, which title starts with "ISO" followed by a decimal number... (:-)). Established, commonly recognized practice is not a standard. Neither a formal language specification is. One can formally specify very different languages. However, these two are probably premises for some standards body to start the process of standardization.

A user community cannot serve as a standards body for the same reason why language preferences cannot do as a language definition. But a community can organize itself in order to bring a new standard to some standard body. AFAIK, for example, ISO actually does not design the standards, it only approves ones designed by some groups of interests, communities. It is a long and painstaking process (which does not necessarily makes the programming language better). So it is unfair to call other things "standards." --Dmitry-kazakov 09:09, 23 July 2008 (UTC)

Sorry to disagree, but 'standards' are just 'established, commonly recognized practice'. For examples, RFCs are standards for the internet, even though they are not certified by ISO. And the 'standards bodies' are only there to put more pressure on industry, which otherwise likes to ignore the standards, because vendor lock-in increases their profit. It's mainly a political difference. And it's only a long a painstaking process if there are too many entities who have a political interest in it. (And actually, the results are not always so thrilling -- the ANSI C++ standard leaves many dark corners for, say, templates unspecified, unintentionally, and compiler implementations promptly disagree in their behaviour). I just fail to see why anything is better just because it carries some letters. But then, maybe I'm just not cowed enough by presumed authority :-)

For me, a standard is anything that I can rely on being supported by an overwhelming majority of whichever products it affects. No matter if it has ISO, ANSI, DIN, or any other letters in it :-)

If you for some reason want the table to contain just "official" standards, fine with me -- just clearly say so on the page, and make explicit how to find out if a standard is "official" or not. But I think for practical purposes, that would be the wrong approach: What is really interesting for a programming language is if one can rely on some common core constructs supported by virtually all implementations, and where to find the information which these constructs are. At least that's what would interest me when learning a new language.

Or, if you for some reason think that standards with some letters in it are "worth" more and should stand out, why not just use green/yellow/red as background? That should give people like me the information they are looking for, and keep the distinction. --Dirkt 10:31, 23 July 2008 (UTC)

It seems that you are confusing a practice with the means to enforce, codify, etc it.

As for RFC notes, they are edited and published by the Internet Engineering Task Force (IETF). IETF has a defined procedure of discussing and approval the documents they publish, an organizational structure, and last but not least, it declares standardization one of its goals [see RFC 2418]. This makes IETF a standards body, and only so RFC notes standards. Implied usefulness or acceptance of RFC notes plays here no role whatsoever. --Dmitry-kazakov 17:18, 23 July 2008 (UTC)

C and C++ have only by-value passing mode. See an explanation in Parameter Passing --Dmitry-kazakov 17:03, 25 July 2008 (UTC)

That's not true for C++: In C++, pass by reference is possible by just using a reference for the argument, f.ex.

<cpp> void foo(int& i) {

 i = 0

}

int main() {

 int rc = 1;
 foo(rc); // sets rc to 0
 return rc;

} </cpp>

Note that the explanation for C++ references in Parameter Passing is not correct: Objects are not converted to references, they are bound to references. Reference types in C++ are fundamentally different to all other types, as they do not denote objects, but, well, references to objects. The references themselves are not objects (you cannot have a pointer or reference to them, you cannot assign them — using them on the left hand of an assignment assigns to the object they refer to —, you cannot determine their size, etc.). Logically they just give a name to an existing object (the compiler may store the address to the object named by the reference, but that's an implementation detail). --Ce 13:15, 5 August 2008 (UTC)

Reference T& is a data type distinct from T. As such it has values and objects of its own. The semantics of reference values is such that they refer to objects of T. Reference objects are passed by their values. For the example you provided, consider:

<cpp>

int A;

int& B = A;

Foo (B); // The object B is passed to Foo, by its value

Foo (A); // The object A has to be converted because formal and actual types differ

B = A; // Reference assignment (defined as deep copy)

</cpp>

The issue that some operations (like operator&) might not be pre-defined on the type T& is irrelevant. It does not have operator* as well. But assignment is defined on a LHS reference, as the code sample shows. This is why B = A; is perfectly legal when B is of int& and A is of int. When a reference like B is declared, this is a declaration of an object B. C++ is a typed language, thus B need to have a type. This type is obviously not T, it is T&. --Dmitry-kazakov 13:55, 5 August 2008 (UTC)

From the C++ standard (well, actually the last public draft of the 1998 standard), 8.3.2 References [dcl.ref]:

1 In a declarationT D where D has the form

& D1

and the type of the identifier in the declarationT D1 is “deriveddeclaratortypelist T,” then the type of the

identifier of D is “deriveddeclaratortypelist reference to T.” [...] [Note: a reference can be thought of as a name of an object. ]

I cannot see where it follows from that C++ references are names. Do you mean "name", a syntactical element, "identifier", member of a name space? This is obviously wrong, because references can be created dynamically as most of other objects, while names are static. --Dmitry-kazakov 15:16, 5 August 2008 (UTC)

And later:

3 It is unspecified whether or not a reference requires storage (3.7).

Given that objects do require storage, this clearly shows that references are not objects.

Wrong. The compiler is free to optimize any objects out, while preserving the program semantics. C++ merely gives an explicit permission to do so for reference objects. --Dmitry-kazakov 15:16, 5 August 2008 (UTC)

Also note that the standard always mentions references explicitly after objects, where both objects and references can be used.

But of course you are invited to quote relevant parts of the standard (of a draft of your choice) to try to disproof me. --Ce 14:46, 5 August 2008 (UTC)

Garbage Collection?

I'm not sure how interesting the stat would be, but how do you guys feel about adding a "Has Garbage Collection" column to the table? I don't know how many modern language don't have it. The only languages I can be sure of are Java and C/C++. --Mwn3d 16:39, 1 February 2009 (UTC)

About this page

Wow, I believe that for a site like RosettaCode this comparison table is a great efforts... luckly a lot of programming languages are missing :D. Scattered notes:

• About paradigm and C: if C++ has generic programming, the same must have C (and languages derived from this)
• About parameter passing and C: I've read the talk above; let me specify that the only way C I know allows parameter passing is by value. You can pass a pointer to (and the pointer is passed "by value", being the pointer itself a value), and intend it like a "reference" to a type; but there's no something like "passing by reference"; this features is in C++, not in C, AFAIK.
• About C and type safety: A language is type-safe if any improperly typed program is illegal in the sense that it may not pass the compiler... why C is unsafe? you can tune compiler with options so that it raises errors instead of warning... cast exists... then here the same as C++ (safe, but unsafe allowed)...?

(I won't modify anything since I am not able to correctly classify any programming lang, so these are just opinions) --ShinTakezou 17:06, 1 February 2009 (UTC)

About pass-by-reference

The terminology of pass-by-value vs. pass-by-reference is really confusing, because different languages and sources use it to mean different things. I propose that we adopt a consistent definition as I will define below.

Let's start by considering Java. The consensus is that Java is only pass-by-value (you can search the Internet, official Java forums, etc. and they all agree on this). The argument is that Java has only two types of values -- primitives and references (Java "references" are basically what you would call "pointers" in C, except safer) -- "objects" are not values in Java, you only manipulate them through references (when you create it it returns a reference, the operator "." only operates on references; in short the language has no concept of "objects" as values). And so, often when a beginner claims to be "passing an object", they are actually passing a reference to the object, by value.

Why is this not pass-by-reference? Yes, you can modify the object that is pointed to by the reference, and someone else with a reference to the same object will see it; but that is irrelevant. The real thing that you are passing -- the reference -- you cannot somehow modify the caller's copy of. So this is what I consider the defining characteristic of pass-by-reference. If you pass a variable as an argument to a function. And that function is somehow able to effectively perform an assignment to that variable (if the variable is a reference, then this means changing the reference so it points to a different (distinct) object, not modifying the object it points to) as if the assignment was made in the caller. <lang> a = somevalue func(a) // it had the same effect as if you did // a = someothervalue </lang>

Under this definition, then, languages like Python and Ruby are also pass-by-value only. In those languages, all values are what Java would call "references" -- different variables can share views of the same object, and variables can be changed to point to different objects without affecting the object it pointed to. And when you pass them, you get the same situation as references in Java. You can still modify the object that the reference points to -- which is shared with the reference passed in -- but you cannot change the caller's reference itself. So you always pass references, by value.

C is also pass-by-value only for the same reason. You can pass pointers by value, but that does not count as pass-by-reference. To have a function be able to modify one of your variables, you have to explicitly take the address of it. C++ and PHP's "references" (different from Java's references above), however, do allow pass-by-reference. You just need to declare a parameter of the function to be a reference (with the "&" symbol), and it allows you to modify the caller's variable. The calling code looks just like they are passing a variable; they do not have to explicitly take the address or anything like that, even if that is what the compiler does behind the scenes.

One instructive resource is the Generic swap task. The languages that can perform a swap of two argument variables, without any special caller intervention, like taking the address or putting them in an auxiliary data structure, and affect the caller's variables (instead of just returning the new values), and not doing something like switching the object contents to look like the references to them have been swapped when they really haven't; such languages I would consider pass-by-reference. --Spoon! 20:15, 1 February 2009 (UTC)

I agree with the fact that the "feature" that makes the difference between the two ways of passing arguments to a function is if the callee is able to modify the "original" thing "owned" by the caller (if I've understood well what you've written) or not. Nonetheless there are proper definitions in literature; as far as I know, these say that "passing by reference" allows the modification of the caller copy, while "passing by value" allows it not, since what you have in the callee is just a (local) copy of the original.

How exactly these ways are implemented are different; in C, to allow the modification of a caller "object", one must pass the pointer to it (the pointer itself is passed by value...); dereferencing the pointer one can modify the local copy of the caller. But other languages may use different terminology and what's going on is hidden by abstraction. As far as I know, in C++ (or was it another lang I am confonding C++ with?:D) the "references" are none but aliases for the same object; so told, I would say the pass-by-reference can be implemented at compile time creating a symbol in the compiler symbol table that is linked to the same "content" of another symbol (roughly speaking).

Anyway, C has no language syntax for referencing like C++; it is less abstract, more "low level", and the only thing one can do is to pass pointers; if the "number" N points to memory "cell" N containing e.g. an int, "dereferencing" the pointer from inside a func or another one "reads" the same memory "cell", i.e. the same int... and so it is for writing. All the arguments passed to a function are a (local) copy, and maybe we can say all are passed-by-value.

In C, there's the convention of considering a pointer like a reference. More abstract languages can call "reference" something different (the underlying implementation likely uses pointers, but this is hidden as said; in C, it can't be hidden: it must be done explicity, and it is why I consider C like it has no pass-by-reference, but only a pass-a-pointer, that is a type as int, float or another, except that we can "take" what the pointer is pointing to, which is the most common operation we do on pointers, altogether with incrementing and decrementing it ---and C does not check bounds:D)

There's another difference (between C and C++): in C, "pass-by-reference" needs awareness by the caller, which must obtain the pointer of the object it wants the callee can modify. In C++, pass-by-reference does not need the "help" of the caller, it is a request of the callee, by declaration. --ShinTakezou 23:03, 1 February 2009 (UTC)