It is not so much a dislike of multidimensional arrays as a concept, but rather, the hair they add to the compiler and typesystem.
Granted, one would still have other complex types, like structs and
function pointers, so potentially the complexity savings would be limited.
[...]
Though, the major goal for this sort of thing is mostly to try to limit
the complexity required to write a compiler (as opposed to programmer convenience).
Like, for example, I had tried (but failed) to write a usable C compiler
in less than 30k lines (and also ideally needing less than 4MB of RAM).
But, if the language design is simplified some, this might be a little closer. Might still be doable, but a C compiler in 50-75k lines is much
less impressive.
[...]
The PDP-10 had 36-bit words and could operate on bit fields of any size
from 1 to 36 bits. A conforming PDP-10 C compiler might have
CHAR_BIT==9, for example. But yes, it would be awkward to deal with
arrays of 6-bit quantities.
On Fri, 5 Jul 2024 14:31:44 +0100, bart wrote:
C also is the only language that is supposed to work on any kind of
processor ...
I don’t think there is anything innate in the design of C to ensure that. It was simply its popularity that meant it was usually the first language implemented on a new processor.
For example, C assumes byte addressability. So that causes awkwardness on architectures like the PDP-10, for example. It just so happened such architectures became extinct at about the time the rise of 8-bit microprocessors (and their more advanced successors) made byte- addressability essentially universal.
bart <[email protected]> writes:
On 10/07/2024 00:35, Ben Bacarisse wrote:
bart <[email protected]> writes:
On 09/07/2024 18:22, Ben Bacarisse wrote:
bart <[email protected]> writes:
On 09/07/2024 16:58, Ben Bacarisse wrote:
bart <[email protected]> writes:
Arrays are passed by reference:
void F(int a[20]) {}
int main(void) {
int x[20];
F(x);
Parameter passing is relatively simple though since there is only oneAn address value is passed by value. C has only one parameter passing >>>>> mechanism. You can spin it as much as you like, but C's parameter}This is the sort of thing that bad tutors say to students so that they >>>>>>> never learn C properly. All parameter passing in C is by value. All of
it. You just have to know (a) what the syntax means and (b) what values
get passed.
The end result is that a parameter declared with value-array syntax is >>>>>> passed using a reference rather than by value.
And it does so because the language says, not because the ABI requires >>>>>> it. A 2-byte array is also passed by reference.
passing is simple to understand, provided learner tune out voices like >>>>> yours.
Little about C's type system is simple.
mechanism -- pass by value.
Except when it comes to arrays.
The oddity is that, in C, one can't pass arrays to functions at all.
That is one of the quirks that people learning C need to learn. It does
not alter the fact that there is only parameter passing mechanism -- by value.
Your plan, of course, is to take that one place where C is relatively
simple and complicate by pretending that C as pass by reference as well
as by value.
On 10/07/2024 14:32, Ben Bacarisse wrote:
Except when it comes to arrays.
The oddity is that, in C, one can't pass arrays to functions at all.
That is one of the quirks that people learning C need to learn. It does
not alter the fact that there is only parameter passing mechanism -- by
value.
Your plan, of course, is to take that one place where C is relatively
simple
It is not that simple. It is confusing. It is error prone.
I earlier asked this:
"So if arrays aren't passed by value in C, and they aren't passed by reference, then how the hell ARE they passed?!"
I haven't had a reply yet. I still consider arrays in C to be 'passed'
by a mechanism which is near-indistinguishable from actual
pass-by-reference.
If somebody had proposed adding pass-by-reference for arrays, you'd say
C doesn't need it, because whatever benefits it might have you, C
already has!
[...]
I can understand when someone new to C gets mixed up about how arrays
work.
I don't understand how someone can remain so stubbornly confused
when they have been told how C /actually/ works.
On 11/07/2024 21:29, Keith Thompson wrote:
bart <[email protected]> writes:
This my first comment on the subject:
"Arrays are passed by reference:
...
Although ..."
And that statement was incorrect, even with the "Although".
So arrays are passed by value? Gotcha.
On 10/07/2024 15:54, Janis Papanagnou wrote:
Values passed (including values of pointers [used for arrays]) are
handled (in the functions) as copies and cannot change the original
entities (values or dereferenced objects) in the calling environment.
To make it possible to change entities in the calling environment
in "C" you have to implement the necessary indirection by pointers.
You don't have to do anything at all:
[ snip source code ]
Here it looks superficially as though 'v' is passed by value (and it is
of a size that the ABI /would/ pass by value), yet F changes its
caller's data, perhaps unintentionally.
Your insistence is amazing./I/ am amazed at everyone's insistence that there is nothing remarkable
about this, and that it is nothing at all like pass-by-reference.
So, how do I write F in C so that the caller's data is unchanged?
Sure, true pass-by-reference has some extra properties,
[...]
KT has chosen not to answer, and now you are evading it too. I'm asking
why this:
void F(int* B) {}
is 'not C' according to KT.
To be clear, I was proposing that:
void F(int B[20])
is an error, and requiring people to write:
void F(int* B) {}
instead.
[...]
I don't share your optimistic belief that the term "pass by reference"
is really established. Very few terms in computer science (science?
really?) are established firmly. Except, may be, in more theoretical
branches of it.
On 12/07/2024 12:12, Janis Papanagnou wrote:
On 12.07.2024 08:00, David Brown wrote:
[...]
I can understand when someone new to C gets mixed up about how arrays
work.
I can't understand that if I presume that the person has read any
basic textbook about "C".
I don't understand how someone can remain so stubbornly confused
when they have been told how C /actually/ works.
Especially if the one has said to have written an own language that
is close enough to "C" where I'd expect the knowledge to be there
already before that person is designing and implementing his project.
I wonder why he refuses to look up things if he thinks that all the
experts here are wrong about a well documented fact.
If you had to describe to someone how a function accesses array data in
its caller, what would you say?
It's clearly not by value. It's apparently not by reference. You can't
get away with saying they are not passed, as clearly functions *can*
access array data via parameters.
Or would you merely refer to the relevant section in the language
reference?
Just curious.
On 12/07/2024 12:44, Janis Papanagnou wrote:
On 11.07.2024 22:37, bart wrote:
On 11/07/2024 21:29, Keith Thompson wrote:
bart <[email protected]> writes:
This my first comment on the subject:
"Arrays are passed by reference:
...
Although ..."
And that statement was incorrect, even with the "Although".
So arrays are passed by value? Gotcha.
Neither is true. - Tertium datur!
"Array passing" is in "C" realized using a pointer passing
mechanism where the pointer is passed "by value".
Neither an array is passed [by value] nor there's a "call
by reference" mechanism in "C".
So how are the elements of the caller's array accessed?
No copies have been supplied to the caller. So access is by ... ?
Look, there are only two choices: 'pointer' and 'reference', which in C
are more or less the same thing:
"6.2.5p20 ... A pointer type describes an object whose value provides a reference to an entity of the referenced type."
So I said 'arrays are passed by reference'; maybe I should have said
'array elements are passed by reference' (which suggests that each has
its own reference), so shoot me.
But everyone was so keen to prove me wrong and incapable of understanding.
On Fri, 12 Jul 2024 15:07:53 +0200
Janis Papanagnou <[email protected]> wrote:
On 12.07.2024 14:42, Michael S wrote:
I don't share your optimistic belief that the term "pass by
reference" is really established. Very few terms in computer
science (science? really?) are established firmly. Except, may be,
in more theoretical branches of it.
I don't know of any "standard" describing that - if that's what you
are aiming at - but I also wouldn't expect an international standard
document. And newer sources (specifically including blogs and bots!)
certainly may muddy waters.
I would expect that thousands of occurrences of phrase "passed by
reference" in relationship with passing explicit pointer to object can
be found in old books, including books not authorized by Herbert
Schildt.
[...]
Janis Papanagnou <[email protected]> writes:
On 12.07.2024 15:59, bart wrote:[...]
So how are the elements of the caller's array accessed?
No copies have been supplied to the caller. So access is by ... ?
...by an implicit pointer value dereferentiation and a global
access to the pointed to storage area.
A small quibble: I suggest "indirect" would be clearer than "global".
For example, a function can define a local array object and use
its name as an argument in a call to another function.
[...]
As an end point to the discussion (just for some recreational
reading) I suggest "The Development of the C Language" by D.
Ritchie.
Available at <https://www.bell-labs.com/usr/dmr/www/chist.pdf>.
Pass-by-reference can mean almost anything. Many languages and their implementations are too diverse for it to have a precise meaning.
All you might assume about pass-by-reference is that the data you're accessing has not been passed by value!
In Python [...]
I don't consider that [...]
My dynamic language allows [...]
On 7/13/2024 4:01 AM, Tim Rentsch wrote:
Michael S <[email protected]> writes:
On Fri, 12 Jul 2024 13:12:53 +0200
Janis Papanagnou <[email protected]> wrote:
But maybe he has looked up some things, since lately he's squirming
by introducing terms like "_true_ pass-by-reference" [emphasis by me]
obviously trying to bend the semantics of the established technical
"pass-by-reference" term to fit his argument. (Introducing new terms
for existing mechanisms or bending semantics of existing terms with
well established meaning is certainly not helpful in any way.)
[...]
I don't share your optimistic belief that the term "pass by reference"
is really established. [...]
The terms
call by name
call by value
call by reference
call by value-result
are all well-defined and firmly established, going back more than
60 years. I learned all of these in standard early course in
computer science sometime in the early 1970s. Of course I can't
be sure about the source after all these years, but I expect
they were defined in the textbook we were using in the class.
[...]
As I see it, they are not exactly the same:
"call by reference", is from the POV of how arguments themselves are
passed to functions during a function call;
"pass by reference" has more to do with the data or object being
conveyed (usually means that a pointer to the object is being passed,
but generally used in cases where no explicit pointer exists).
[...]
Ben Bacarisse <[email protected]> writes:
Keith Thompson <[email protected]> writes:[...]
I'm mildly disappointed. Since arguments are *passed* and
functions/procedures are *called*, surely it would have made more sense
to use "pass by value" rather than "call by value", especially in a
language where the mechanism can vary per parameter.
All that is, I think, due to subsequent changes in (English) language
use. In Algol 60, procedures were invoked and /parameters/ were called
by value or name. Maybe the term was intended to reflect the idea that
the code in the body "called for the value" of the parameter.
The word "call" now refers, almost universally, to invoking a function
or procedure. As a result, the idea of "calling a parameter" reads
oddly, but at the time I'm sure it seemed perfectly reasonable.
I just searched the Algol 60 report for all occurrences of the word
"call". It does refer to both procedures and parameters being "called",
but parameters are only "called by value" or "called by name", never
just "called".
It's difficult to tell what the idiomatic usage would have been at the
time.
Tim Rentsch <[email protected]> writes:
[ snip nice write-up ]
I honestly do not understand the argument you're making in favor of
"call by" over "pass by". ("Hoi polloi"? Seriously?)
Procedures and functions are "called", yes? They're not "passed",
except perhaps as an argument to another procedure or function.
Arguments to procedures and functions are "passed", yes? Would it make
sense to say that an argument is "called"? (I note that the Algol 60
report never refers to parameters being "called" other than in the
phrases "call by value" and "call by name".)
If you think that "calling an argument" or "calling a parameter" makes
sense, perhaps that's the root of the disagreement. Do you?
[ snip example and associated explanation ]
Other than historical precedent from Algol and friends, why do you think
it's better to use "call by value" and "call by reference" rather than
"pass by value" and "pass by reference", when the mechanism applies individually to each argument, not to the call as a whole?
Do you object to using the word "pass" (without "by ...") to refer to
the arguments to a function? If not, why do you object to "pass by ..."
to refer to the mechanism?
Janis Papanagnou <[email protected]> writes:
[excerpted for brevity]
In the domain of German speaking countries - isn't Tim located there?
(I somehow got the impression) - we've heard about "Parameterubergabe";
[..] means passing, transferring, handing over, transmitting, etc.
Because of that - and because I could not follow the thoughts of Tim's
last paragraph with his conclusion; I didn't find it convincing - I'd
think that "passing" would fit better, also in the light of historic
usage [hereabouts], even though I've often heared (and also used) the
phrase "call by" in the English CS domain in the past (and probably
still used to it).
If you have something to say to me please respond to my posting
directly.
[...]
In the function call, there are two different argument passing
mechanisms, but only one *call*. The call itself is not by
value or by reference. The call includes passing two arguments,
one by value and one by reference. This is one reason I don't
think it makes sense to use "call by" rather than "pass by"
for arguments/parameters. (In Algol 60 terms, parameters were
"called", so that terminology made sense.)
The "call by name" semantics turned out to be more complicated
than expected,
and as far as I can tell was never adopted by any
language other than Algol 60.
[...]
I don't know whether the idea of "calling" parameters originated in
the Algol 60 report, or whether it was just common usage at the time. Studying the early documentation for languages like Fortran, Cobol,
and perhaps PL/I might be illuminating, but I have not (yet) done so.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 154:01:12 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,674 |