On 08/12/2021 15:36, David Brown wrote:
> On 08/12/2021 12:55, Bart wrote:
>> On 08/12/2021 11:07, David Brown wrote:
>>> On 08/12/2021 10:45, Bart wrote:
>>
>>>> C of course prefers to use unsigned for mixed arithmetic (although the
>>>> precise rules are complex). So here:
>>>
>>> The precise rules are simple, not complex.  Pretending they are
>>> difficult does not help.
>>
>
> What is it with you and your campaign to claim everything C is bad, and
> everything in your useless little private language is good? It doesn't
> matter what anyone writes - you /always/ twist the facts, move the
> goalposts or deliberately misinterpret what others write. (And yes,
> your language is useless - no one else will ever use it. You've had
> made useful software with it and used it in your work in the past.
> That's great, and genuinely praise-worthy. But it is dead now. Move
> along.)
>
>
> So - let's start with some kindergarten logic. Claiming that your rules
> are simpler than C's does not make C's rules complex.
>
> In a binary arithmetic expression with integer types, any type smaller
> than "int" is first converted to an "int". Then if the two parts have
> different types, they are converted to the bigger type with "unsigned"
> types being treated as slightly bigger than the signed types.
>
> It is /not/ hard. It is /not/ complex. You might not think it is
> ideal, and I'd agree. But it really is not rocket science, and it
> doesn't need a complicated table of inappropriate made-up types to make
> it look more complicated.
>
> Oh, and your method will screw up too, for some cases. /Any/ method
> will in some cases, unless you have unlimited ranges for your integers
> (like Python) or point-blank refuse mixed signed expressions (like Ada).
> And your language will still screw up on overflows.
>
> (And before you post your knee-jerk response, the fact that C gets
> things wrong on overflow does not mean your language is right or better.)
>
>
> <snip more pointless and annoying drivel>
>
>>> In particular, what does your language give for :
>>>
>>>       int a := 2
>>>       int b := 3
>>>       real c := b / a;
>>>
>>>       println c
>>>
>>>
>>> Does it print 1, or 1.5 ?
>>
>> My languages have two divide operators: "/" and "%".
>>
>> "%" means integer divide. "/" is supposed to be for floating point
>> divide, but that's only on one language; the static one will still do
>> integer divide when both operands are integers.
>
> Genius. Does it also use "and" as a keyword for the remainder after
> division? Nothing says "simple" and "intuitive" like picking different
> meanings for your operators than all other languages.
>
>>
>> So M will give 1.0, Q will give 1.5.
>>
>
> That's your two languages that are proudly the same syntax, but handle
> expressions in completely different ways?
>
>
> If you want to keep posting about your own language, please feel free -
> only you can tell if you are making things up as you go along. But
> /please/ stop posting shite about other languages that you refuse to
> understand.
>
> Understand me correctly here - I really don't care if you like C or not.
> I don't care if anyone else here likes it or not, uses it or not. I am
> not interested in promoting C or any other language - I'll use what I
> want to use, and others will use what they want.
>
> But what I /do/ react against is lies, FUD, and misrepresentations. I
> am not "pro-C" - I am "anti-FUD", and it just so happens that your
> bizarre hatred of C means it is C you post rubbish about.

I post criticisms of quite a few languages I come across, although in
this group it might be largely C and Algol68 that come up.

C figures highly because I can't really get away from it; it's
everywhere. It's also the one whose purpose and use-cases most closely
match my own.

But it also annoys me that it is so deified despite being a such a
dreadful language.

That is not surprising given when it was created, nearly 50 years ago.
But it hasn't moved on. Its aficionados seem to treat every misfeature
as an advantage.

> I'd react
> against anyone else deliberately and repeatedly writing nonsense about
> other topics too.

You mention lots of things you don't like about C. But it sounds like
you don't have much of a choice about it; you have to rely on external
tools to make it useful. That's OK, many people are stuck with languages
they don't like.

But some of us can do something about it, yet that seems to annoy you
and you are constantly belittling people's efforts, especially mine.

On 08/12/2021 20:05, Bart wrote:

>
> I post criticisms of quite a few languages I come across, although in
> this group it might be largely C and Algol68 that come up.
>
> C figures highly because I can't really get away from it; it's
> everywhere. It's also the one whose purpose and use-cases most closely
> match my own.
>
> But it also annoys me that it is so deified despite being a such a
> dreadful language.

This is where the communication problem lies - your annoyance is based
on two incorrect ideas.

First, you think C is "deified" - it is /not/. I really wish you could
understand that, as it would make discussions so much easier. You seem
to be fundamentally incapable of distinguishing between people who
understand C and use it (of which there are vast numbers), and people
who think C is the best language ever and completely flawless (of which
there are, to my knowledge, none).

Take me, as an example - because it's a lot easier to speak for myself
than for other people! I have a good understanding of the main C
language, and a subset of the standard library (there is a great deal in
it that I never use). I have read the standards, I keep up with changes
to the new standards. I have written a great deal of C code over the
years, almost all for small embedded systems (and a little for Linux).
I have used a wide range of C compilers for a wide range of
microcontrollers. Far and away the best C compiler I have seen is gcc,
which I know well and use for several targets.

I have worked in many different languages (I have at least some
experience with perhaps 20 programming languages, ranging from
functional programming, assembly, hardware description languages,
scripting languages, imperative languages, and more). I have used
assembly on a couple of dozen architectures over the years. I regularly
use several different languages for different types of programming.

I like programming in C. I think is a good language for a lot of what I
do, and I think it is a good language for a lot of what other people do.
But I also think it is /not/ an appropriate language for many uses
people make of it, and it is not an appropriate language for people who
are not able or willing to learn it properly. It is a language that
trusts the programmer to know what they are doing - if you are not
worthy of that trust, don't use C.

I would drop it in a heartbeat if I had something better. I /do/ drop
it without a backwards glance when I have something better for the task
at hand. Thus on some embedded systems, C++ is more appropriate and I
use that. (On occasions that are thankfully rare now, assembly was a
better choice.) On PC's or bigger systems, I often use Python - but
sometimes other languages.

C is not perfect. I have never heard anyone suggest it is - though you,
Bart, repeatedly accuse people (including me) of saying so. There are a
number of sub-optimal aspects in C that there is quite general agreement
about, and a large number where some people think it could have been
better, but different people have different opinions. For the most
part, those who know about the language understand why things are the
way they are - whether it be for historical reasons, compatibility,
limitations of old systems, or for more modern reasons and uses. No one
is in any doubt that if a language were being designed today to do the
job of C, many aspects would be different. No one is in any doubt that
C is not perfect for their needs or desires. Nonetheless, it is a good
language that works well for many programmers.

It takes effort, skill, knowledge and experience to use any language
well. You need to understand the subset that is appropriate for your
usage - all languages, bar a few niche or specialist ones, have features
and flexibility well outside what makes sense for any particular
programmer's needs. You need to understand how to use the tools for the
language as an aid to developing good code, avoiding problems, and
getting good results in the end. If you fight with the tools, you will
fail. If you fight with the language, you will lose. If you avoid the
useful features of the language, you will only make life harder for
yourself. If you are determined to find fault and dislike in every
aspect of a language, you will not like the language and you will not be
productive with it.

Your second mistake is to think C is a "dreadful language". It is not.
You place artificial limitations on it that make it a poorer language,
you misunderstand its philosophy and design, you fail to make good use
of proper tools (and C was always intended to be used with helpful
tools), and in general your emphasis is on finding faults rather than
uses. You appear unable to believe that people can successfully use the
language.

There is certainly a place for criticism, especially constructive
criticism, in all languages - /none/ are anywhere close to being
universally perfect. But there is no benefit to anyone in a repetitive,
out of context and biased stream of abuse and negativity towards a
language (or anything else, for that matter).

>
> That is not surprising given when it was created, nearly 50 years ago.
> But it hasn't moved on. Its aficionados seem to treat every misfeature
> as an advantage.

I treat things I see in C as misfeatures, as misfeatures. So does
everyone else. I don't treat things /you/ see as misfeatures that way.
In reality, there are very few misfeatures in C that cannot be avoided
by good use of tools, good general development practices, and
occasionally a little extra effort. This is the same in all programming
languages, though of course the details vary. For some reason, you
insist on avoiding good tools (and avoiding good use of tools), and
prefer to find ways to misuse every feature of C that you can.

(The primary reason I have for moving to C++ is to gain additional
features, not to move away from misfeatures.)

>
>>  I'd react
>> against anyone else deliberately and repeatedly writing nonsense about
>> other topics too.
>
> You mention lots of things you don't like about C. But it sounds like
> you don't have much of a choice about it; you have to rely on external
> tools to make it useful. That's OK, many people are stuck with languages
> they don't like.

I /do/ like C - I just don't think it is perfect (and certainly not
perfect for every task). And with good tools used well, it is a very
pleasant and effective language to work with. The same applies to any
good software developer with any language - you find a language that is
suitable for the task and fits your style, you find good tools that help
with the job, and development processes that work well. If you don't
have that, you won't like what you are doing and won't do it well. The
choice of programming language is irrelevant outside its suitability for
the task.

Perhaps you are just envious that I can happily and successfully work
with C, while you have failed? That would be a shame - I am happy, not
envious, that you have a language that you enjoy working with. And I
think it would be better if you avoided dealing with a language that you
clearly don't appreciate or enjoy.

>
> But some of us can do something about it, yet that seems to annoy you
> and you are constantly belittling people's efforts, especially mine.
>

People can choose whatever language they like, and use it as they want.
I don't belittle your effort or your language - I belittle your
attitude to your language and to C, your egotism and narcissistic
viewpoint. When you say you prefer to code in your own language, and
had success with it, that's fine. When you say your language is an
alternative to C, you are wrong. When you say it is "better" than C,
you are wrong. When you say a particular given aspect is "better" than
the equivalent aspect of C, then you /might/ be /subjectively/ right -
i.e., it could be better in some ways for some people or some use-cases.
(And I have regularly agreed on such points.)

On Tuesday, December 7, 2021 at 8:40:03 AM UTC-6, David Brown wrote:
> On 07/12/2021 13:52, Rod Pemberton wrote:

> > As for C, variable declarations within the for() loop is not valid
> > for ANSI C (C89), i.e., valid for C99 or C11 or later.
> C18 is the current standard - without other qualifications, that is what
> is meany by "C". If you want to pick an older standard, it is best to
> specify it explicitly. (And I don't recommend using the term "ANSI C"
> at all - people often use it to mean C89, when in fact it means "the
> current ISO C standard" - i.e., C18 at the time of writing.)
>
> Of course you are correct that putting declarations in the "for" loop
> was introduced in C99. Rounded to the nearest percentage, 100% of C
> code has been written since the introduction of C99, and probably at
> least 98% since it became widely supported by common tools. There are a
> few very niche situations where it makes sense to use pre-C99 today,
> other than for maintaining old programs in the style in which they were
> written. Other than that, C99 syntax is standard.
> > So, one could
> > argue, that to ensure backwards code compatibility, hence portability
> > of C code, that declaring a variable somewhere within a procedure, such
> > as within a for() loop, should be avoided, yes? Think of C style guide
> > suggestions.
> >
> No.
>
> That's like saying software should be published as printouts in a
> magazine, rather than, say, on a web page, for backwards compatibility.

Also going with 'no'. If you need backwards compatibility, wrap some extra
braces in there making a new compound statement extending to the end
of the function. Then you can declare new variables in the middle of a
function even in old timey C.

For loops require a slight adjustment. Pull the declaration out front and
wrap the whole thing in extra braces.

{
int i;
for( i=0; ...){ ... }
}

Now you're cookin' with gas.

On 10/12/2021 06:00, luserdroog wrote:
> On Tuesday, December 7, 2021 at 8:40:03 AM UTC-6, David Brown wrote:
>> On 07/12/2021 13:52, Rod Pemberton wrote:
>
>>> As for C, variable declarations within the for() loop is not valid
>>> for ANSI C (C89), i.e., valid for C99 or C11 or later.
>> C18 is the current standard - without other qualifications, that is what
>> is meany by "C". If you want to pick an older standard, it is best to
>> specify it explicitly. (And I don't recommend using the term "ANSI C"
>> at all - people often use it to mean C89, when in fact it means "the
>> current ISO C standard" - i.e., C18 at the time of writing.)
>>
>> Of course you are correct that putting declarations in the "for" loop
>> was introduced in C99. Rounded to the nearest percentage, 100% of C
>> code has been written since the introduction of C99, and probably at
>> least 98% since it became widely supported by common tools. There are a
>> few very niche situations where it makes sense to use pre-C99 today,
>> other than for maintaining old programs in the style in which they were
>> written. Other than that, C99 syntax is standard.
>>> So, one could
>>> argue, that to ensure backwards code compatibility, hence portability
>>> of C code, that declaring a variable somewhere within a procedure, such
>>> as within a for() loop, should be avoided, yes? Think of C style guide
>>> suggestions.
>>>
>> No.
>>
>> That's like saying software should be published as printouts in a
>> magazine, rather than, say, on a web page, for backwards compatibility.
>
> Also going with 'no'. If you need backwards compatibility, wrap some extra
> braces in there making a new compound statement extending to the end
> of the function. Then you can declare new variables in the middle of a
> function even in old timey C.
>
> For loops require a slight adjustment. Pull the declaration out front and
> wrap the whole thing in extra braces.
>
> {
> int i;
> for( i=0; ...){ ... }
> }
>
> Now you're cookin' with gas.
>

Yes, you certainly /can/ do this with C90. But it quickly becomes quite
ugly if your functions are big. It is better, where possible, to split
things into smaller functions.

If you are still coding in C90 today (other than small changes to
maintain legacy code), it is likely to be because you are stuck with an
ancient compiler with poor optimisation - it's going to be poor at
inlining so you need to write big functions (and horrendous
function-like macros) if speed is an issue. There isn't really a good
solution here if you like clear code - just options that are bad in
different ways.

As far as I am concerned, the habit of putting all variable definitions
at the start of a function, before any statements, is as legacy and
out-dated as non-prototype function declarations or the explicit use of
"auto" for local variables.

We don't use Latin to talk about science. We don't program in Algol 68.
Let's leave C90's limitations to the history books too, as much as we
reasonably can.

On 10/12/2021 08:17, David Brown wrote:
> On 10/12/2021 06:00, luserdroog wrote:

>> For loops require a slight adjustment. Pull the declaration out front and
>> wrap the whole thing in extra braces.
>>
>> {
>> int i;
>> for( i=0; ...){ ... }
>> }
>>
>> Now you're cookin' with gas.
>>
>
> Yes, you certainly /can/ do this with C90. But it quickly becomes quite
> ugly if your functions are big. It is better, where possible, to split
> things into smaller functions.
>
> If you are still coding in C90 today (other than small changes to
> maintain legacy code), it is likely to be because you are stuck with an
> ancient compiler with poor optimisation - it's going to be poor at
> inlining so you need to write big functions (and horrendous
> function-like macros) if speed is an issue. There isn't really a good
> solution here if you like clear code - just options that are bad in
> different ways.
>
>
> As far as I am concerned, the habit of putting all variable definitions
> at the start of a function, before any statements, is as legacy and
> out-dated as non-prototype function declarations or the explicit use of
> "auto" for local variables.

Yet it makes for tidier looking code. There is a separation between the
logic of the code, and the less important details of the types of
variables, which now no longer clutter up the logic.

To find a variable's type, you just glance up at the 'cast-list' at the
top of the function.

If transfering code between languages, the executable code is likely to
be more portable sans its type declarations, which are going to be
language-specific. The other language may not even need types.

You also don't need to worry about block scope: declare that 'int i'
right here, and then you find you can't access 'i' beyond the next '}',
or find (eventually) that it is using a more outer 'i' - the wrong one.

And you don't need to worry about rearranging code where you'd need to
keep ensuring that the first use of a variable is that one with the
declaration.

I wonder if, when declaring module-scope variables, macros, enums, types
and so on, whether you place these before all the functions, or
intersperse them between the functions, to have them as close as
possible to where they are first used?

> We don't use Latin to talk about science. We don't program in Algol 68.
> Let's leave C90's limitations to the history books too, as much as we
> reasonably can.

Factual books still tend to have glossaries at one end of the book or
the other.

(BTW Algol68 allowed declarations interspersed with statements before C did.

I allow the same now (though with function-wide scope to avoid the
problems above), but tend to use that ability as often as I use 'goto';
something that is normally best avoided.)

On 10/12/2021 12:16, Bart wrote:
> On 10/12/2021 08:17, David Brown wrote:
>> On 10/12/2021 06:00, luserdroog wrote:
>
>>> For loops require a slight adjustment. Pull the declaration out front
>>> and
>>> wrap the whole thing in extra braces.
>>>
>>>    {
>>>      int i;
>>>      for( i=0; ...){ ... }
>>>    }
>>>
>>> Now you're cookin' with gas.
>>>
>>
>> Yes, you certainly /can/ do this with C90.  But it quickly becomes quite
>> ugly if your functions are big.  It is better, where possible, to split
>> things into smaller functions.
>>
>> If you are still coding in C90 today (other than small changes to
>> maintain legacy code), it is likely to be because you are stuck with an
>> ancient compiler with poor optimisation - it's going to be poor at
>> inlining so you need to write big functions (and horrendous
>> function-like macros) if speed is an issue.  There isn't really a good
>> solution here if you like clear code - just options that are bad in
>> different ways.
>>
>>
>> As far as I am concerned, the habit of putting all variable definitions
>> at the start of a function, before any statements, is as legacy and
>> out-dated as non-prototype function declarations or the explicit use of
>> "auto" for local variables.
>
> Yet it makes for tidier looking code. There is a separation between the
> logic of the code, and the less important details of the types of
> variables, which now no longer clutter up the logic.

The type of variables is a critical part of their usage - not some extra
feature.

To be fair, there are certainly languages with weak or no typing, which
can be useful for simple tasks. And it's not unreasonable to use
generic integer types that are big enough for most purposes without
being fussy about the type.

But outside of that, types are vital information. A strong typing
system in a language /hugely/ reduces the risks of errors, as well as
improving the efficiency of the language, and is particularly important
for larger programs.

So moving types away from the use of a variable is hiding useful
information, not making the code "tidier".

Having all the local variables at the start of a function arguably made
sense long ago, with weaker compilers that needed a list of variables
and allocated a fixed stack frame for them. Re-using the same variables
for different purposes in the code was useful for efficiency. Those
days are long gone. Compilers allocate as and when needed, with
variables in registers, stack slots, optimised out entirely, or
combinations as the code progresses. Mixing declarations and statements
means you can freely split code in logical sections, naming things
usefully whenever it is convenient. You make your variables when you
have something to put in them - there is no need to stock up on
variables in advance. You can often avoid changing the value of a
variable - you just make a new one with the new value.

All this makes it far easier to understand code, analyse it, and be sure
it is correct. Your variables can have invariants - established as soon
as the variable is created. You no longer have a period where the
variable exists and could be used accidentally, but does not have an
appropriate value.

It's no surprise that many new languages make variables constant by
default, and functional programming languages - famous for letting you
write provably correct code in many cases - don't let you change
variables at all.

>
> To find a variable's type, you just glance up at the 'cast-list' at the
> top of the function.
>
> If transfering code between languages, the executable code is likely to
> be more portable sans its type declarations, which are going to be
> language-specific. The other language may not even need types.
>

That would only be the case if you are transferring code between
languages that are extremely similar, where one of them is limited to
defining variables at the start of the function (or at least the start
of the block), where you want to do the conversion manually, where you
want to keep an identical structure to the code, and where you are
willing to write sub-standard code in a riskier manner to make this all
work more simply.

/If/ all that is true, then I agree it is simpler - obviously
translating code directly between two languages is going to be simpler
if you stick to a common subset of the features of the languages.

But I would not judge such cases to be even a vaguely significant
fraction of code written. It is too obscure to bother considering.

> You also don't need to worry about block scope: declare that 'int i'
> right here, and then you find you can't access 'i' beyond the next '}',
> or find (eventually) that it is using a more outer 'i' - the wrong one.
>

It is easier to find the definition of the variable when it is close by.
If that is not the case, your function is too big and messy in the
first place.

> And you don't need to worry about rearranging code where you'd need to
> keep ensuring that the first use of a variable is that one with the
> declaration.
>

I agree that that can occasionally be a disadvantage. It is not a big
enough matter to change my overall opinion - not by a /long/ way. (And
note that more often than not, having the declaration at the usage site
makes it easier to re-arrange or copy-and-paste the code between
different functions, since everything is in one place.)

One thing that would help here would be if the language allowed
something like :

int x = ...
...
int x = ...

without starting a new block. C (and C++) do not allow this. But in my
idea of a "perfect" language, it /would/ be allowed. (Of course such a
feature could be abused to write confusing code - that's a risk with any
feature. But it would be good in some circumstances, such as
copy-and-pasted similar code sections.

> I wonder if, when declaring module-scope variables, macros, enums, types
> and so on, whether you place these before all the functions, or
> intersperse them between the functions, to have them as close as
> possible to where they are first used?

I put them where I feel they are appropriate. If they are "exported"
from the unit, I put them in "file.h" rather than "file.c".

If they are local to the file, I put them where it makes sense according
to the grouping of the functionality within the file. Declarations in C
have to come before their use, and I don't forward declare things unless
I have a particularly good reason. Thus static variables or local types
will often come just before the functions that use them, after other
functions that happened to come earlier and didn't need them. They may
also happen to be placed earlier in the file, if it makes more logical
sense to place them alongside other declarations that come there.

So if you are asking if I put all my module-scope variables and stuff at
the start of a module before the code, the answer is no.

(I'm using C as an example here, I do similar things in other languages,
adapted according to the language.)

>
>> We don't use Latin to talk about science.  We don't program in Algol 68.
>>   Let's leave C90's limitations to the history books too, as much as we
>> reasonably can.
>
> Factual books still tend to have glossaries at one end of the book or
> the other.
>
> (BTW Algol68 allowed declarations interspersed with statements before C
> did.
>
> I allow the same now (though with function-wide scope to avoid the
> problems above), but tend to use that ability as often as I use 'goto';
> something that is normally best avoided.)

I agree with you about "goto" :-)

On 10/12/2021 16:51, David Brown wrote:
> On 10/12/2021 12:16, Bart wrote:
>> On 10/12/2021 08:17, David Brown wrote:
>>> On 10/12/2021 06:00, luserdroog wrote:
>>
>>>> For loops require a slight adjustment. Pull the declaration out front
>>>> and
>>>> wrap the whole thing in extra braces.
>>>>
>>>>    {
>>>>      int i;
>>>>      for( i=0; ...){ ... }
>>>>    }
>>>>
>>>> Now you're cookin' with gas.
>>>>
>>>
>>> Yes, you certainly /can/ do this with C90.  But it quickly becomes quite
>>> ugly if your functions are big.  It is better, where possible, to split
>>> things into smaller functions.
>>>
>>> If you are still coding in C90 today (other than small changes to
>>> maintain legacy code), it is likely to be because you are stuck with an
>>> ancient compiler with poor optimisation - it's going to be poor at
>>> inlining so you need to write big functions (and horrendous
>>> function-like macros) if speed is an issue.  There isn't really a good
>>> solution here if you like clear code - just options that are bad in
>>> different ways.
>>>
>>>
>>> As far as I am concerned, the habit of putting all variable definitions
>>> at the start of a function, before any statements, is as legacy and
>>> out-dated as non-prototype function declarations or the explicit use of
>>> "auto" for local variables.
>>
>> Yet it makes for tidier looking code. There is a separation between the
>> logic of the code, and the less important details of the types of
>> variables, which now no longer clutter up the logic.
>
> The type of variables is a critical part of their usage - not some extra
> feature.
>
> To be fair, there are certainly languages with weak or no typing, which
> can be useful for simple tasks. And it's not unreasonable to use
> generic integer types that are big enough for most purposes without
> being fussy about the type.
>
> But outside of that, types are vital information. A strong typing
> system in a language /hugely/ reduces the risks of errors, as well as
> improving the efficiency of the language, and is particularly important
> for larger programs.
>
> So moving types away from the use of a variable is hiding useful
> information, not making the code "tidier".

With an algorithm in a dynamic language, you don't need explicit types.

When in a complex macro, or in a template body, then precise types don't
matter much either.

Concrete types will be needed when such code is instantiated or
expanded, or when that dynamic code is actually run. But need not be
essential for understanding the code.

On 10/12/2021 19:37, Bart wrote:
> On 10/12/2021 16:51, David Brown wrote:
>> On 10/12/2021 12:16, Bart wrote:
>>> On 10/12/2021 08:17, David Brown wrote:
>>>> On 10/12/2021 06:00, luserdroog wrote:
>>>
>>>>> For loops require a slight adjustment. Pull the declaration out front
>>>>> and
>>>>> wrap the whole thing in extra braces.
>>>>>
>>>>>     {
>>>>>       int i;
>>>>>       for( i=0; ...){ ... }
>>>>>     }
>>>>>
>>>>> Now you're cookin' with gas.
>>>>>
>>>>
>>>> Yes, you certainly /can/ do this with C90.  But it quickly becomes
>>>> quite
>>>> ugly if your functions are big.  It is better, where possible, to split
>>>> things into smaller functions.
>>>>
>>>> If you are still coding in C90 today (other than small changes to
>>>> maintain legacy code), it is likely to be because you are stuck with an
>>>> ancient compiler with poor optimisation - it's going to be poor at
>>>> inlining so you need to write big functions (and horrendous
>>>> function-like macros) if speed is an issue.  There isn't really a good
>>>> solution here if you like clear code - just options that are bad in
>>>> different ways.
>>>>
>>>>
>>>> As far as I am concerned, the habit of putting all variable definitions
>>>> at the start of a function, before any statements, is as legacy and
>>>> out-dated as non-prototype function declarations or the explicit use of
>>>> "auto" for local variables.
>>>
>>> Yet it makes for tidier looking code. There is a separation between the
>>> logic of the code, and the less important details of the types of
>>> variables, which now no longer clutter up the logic.
>>
>> The type of variables is a critical part of their usage - not some extra
>> feature.
>>
>> To be fair, there are certainly languages with weak or no typing, which
>> can be useful for simple tasks.  And it's not unreasonable to use
>> generic integer types that are big enough for most purposes without
>> being fussy about the type.
>>
>> But outside of that, types are vital information.  A strong typing
>> system in a language /hugely/ reduces the risks of errors, as well as
>> improving the efficiency of the language, and is particularly important
>> for larger programs.
>>
>> So moving types away from the use of a variable is hiding useful
>> information, not making the code "tidier".
>
> With an algorithm in a dynamic language, you don't need explicit types.
>
> When in a complex macro, or in a template body, then precise types don't
> matter much either.
>
> Concrete types will be needed when such code is instantiated or
> expanded, or when that dynamic code is actually run. But need not be
> essential for understanding the code.

Fair enough - when you have polymorphism, you are defining a function
over a range of types. Even then, however, particular types or part of
the types are important. Maybe you want variables in the function to
have the same type as those of the parameter, or perhaps be related to
them (such as a list of that type). Maybe you want to restrict the
types available, such as accepting any type as long as it is an
arithmetic type or a string type. (How you restrict things is often as
useful as what you support.)

I do a fair amount of programming in Python, which is very dynamic (in
many senses). It is quick and easy to write functions that work on
multiple types, but more often than not you only have one type in mind
for each function you write. In my bigger Python programs, I
desperately miss the ability to specify types (Python type annotations
were introduced long after these programs had already grown huge and
unwieldy - it's hard to add these things afterwards).

Sometimes it is nice to be able to write code that works with /any/
type. But often it is better to be able to explicitly say what you need
of the type - it lets you catch certain kinds of problems faster,
earlier in the compile process (and long before running), and it lets
you make your intentions clear to the reader.

On Thu, 9 Dec 2021 13:58:49 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 08/12/2021 20:05, Bart wrote:

> > I post criticisms of quite a few languages I come across, although
> > in this group it might be largely C and Algol68 that come up.
> >
> > C figures highly because I can't really get away from it; it's
> > everywhere. It's also the one whose purpose and use-cases most
> > closely match my own.
> >
> > But it also annoys me that it is so deified despite being a such a
> > dreadful language.
>
> This is where the communication problem lies - your annoyance is based
> on two incorrect ideas.
>
> First, you think C is "deified" - it is /not/.

Yes, it is. I think it's the God language. I have yet to need another
language, unlike BASIC, Pascal, Fortran, ... The only other language
that comes close to C's power, that I'm familiar with, was a early
version of PL/1, which was like Pascal with pointers. (Pascal
apparently now has pointers.)

There isn't anything you can't program in C with enough effort. And,
most other languages, at one time or another, compiled directly into C
or had apps to convert their code into C to be compiled, including C++.
You can even, with a touch of creativity, do object-oriented
programming in C.

> people who think C is the best language ever

Yes.

> completely flawless (of which there are, to my knowledge, none).

No. C has a bunch of mistakes and dark corners. It's best to program
in a limited "safe" subset of C. Some would argue "portable" instead
of "safe", but whatever ... There are obviously a number of safe C
standards and compilers out there e.g., MISRA, CompCert.

An old post to James, in the middle lists things I think C got correct:
https://groups.google.com/g/comp.lang.misc/c/4VNii2cQ_Zo/m/7SkgWMit_iIJ

> But I also think it is /not/ an appropriate language for
> many uses people make of it, and it is not an appropriate language
> for people who are not able or willing to learn it properly.

C is /always/ an appropriate language choice for a few reasons:

1) C is available everywhere, ready-to-go, works reliably and
consistently, and requires no need to learn a new language
2) C compilers produce highly optimized code or quick binaries
3) C is known by an entire generation programmers or a few gens
4) C consistently ranks high on the TIOBE index for usage

C is like English of the programming world. Before that, BASIC.
Arguably, nothing has quite replaced C, although some now recommend
Python. Python looks C-like to me, e.g., C meets Pascal.

> There is certainly a place for criticism, especially constructive
> criticism, in all languages - /none/ are anywhere close to being
> universally perfect. But there is no benefit to anyone in a
> repetitive, out of context and biased stream of abuse and negativity
> towards a language (or anything else, for that matter).

This isn't a language criticism group. It's a language development
group. Bart is developing. I was. James is. Others reading and
posting here are or have, or are interested in the theories.

> >>  I'd react
> >> against anyone else deliberately and repeatedly writing nonsense
> >> about other topics too.
> >
> > You mention lots of things you don't like about C. But it sounds
> > like you don't have much of a choice about it; you have to rely on
> > external tools to make it useful. That's OK, many people are stuck
> > with languages they don't like.
>
> I /do/ like C - I just don't think it is perfect (and certainly not
> perfect for every task). And with good tools used well, it is a very
> pleasant and effective language to work with. The same applies to any
> good software developer with any language - you find a language that
> is suitable for the task and fits your style, you find good tools
> that help with the job, and development processes that work well. If
> you don't have that, you won't like what you are doing and won't do
> it well. The choice of programming language is irrelevant outside
> its suitability for the task.

I would argue that you need to find a solution to coding a program that
fits the functionality of the language, then the outcome will be good.

What I usually see with people who dislike C is that they attempt to
code their program the way they want to, or they attempt to implement
their program according to the design that they want, instead of
thinking, "How can this best be implemented in C?" C is a
general-purpose programming language that is exceptional with low-level
constructs, such as integers, pointers, and characters. IMO, it's not
good with floating point, and it's missing complex numbers, etc. So,
it's a language you wouldn't choose to do math intensive stuff, like is
done with Fortran or MatLab etc. If you move beyond those few things
in C, you probably need to redesign your program significantly to fit
that model. E.g., you may need to restructure the program to use more
integers or strings.

--

On Wed, 8 Dec 2021 16:36:33 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 08/12/2021 12:55, Bart wrote:
> > On 08/12/2021 11:07, David Brown wrote:
> >> On 08/12/2021 10:45, Bart wrote:

> >>> C of course prefers to use unsigned for mixed arithmetic
> >>> (although the precise rules are complex). So here:
> >>
> >> The precise rules are simple, not complex.  Pretending they are
> >> difficult does not help.
> >
>
> What is it with you and your campaign to claim everything C is bad,
> and everything in your useless little private language is good?

Does he know C better than you? Is that why he makes you angry? ...

> It doesn't matter what anyone writes - you /always/ twist the facts,
> move the goalposts or deliberately misinterpret what others write.
> (And yes, your language is useless - no one else will ever use it.
> You've had made useful software with it and used it in your work in
> the past. That's great, and genuinely praise-worthy. But it is dead
> now. Move along.)
>

Sigh, that really reminds me of some (incorrect) but pedantic C guys on
comp.lang.c from decades ago.

> So - let's start with some kindergarten logic. Claiming that your
> rules are simpler than C's does not make C's rules complex.

Who knows C's rules besides you? If I seriously need them, I look them
up in a book ... Otherwise, I code around them to not need to know
them, as that leads to fewer coding mistakes than using what I
remember. How long have you been on Usenet? Has it been over 3 or 4
decades? If so, you'll notice that people who "authoritatively" make
statements from memory, almost always get them wrong. (Yeah, like you
just did recently on comp.compilers in regards to C type-punning.)

> >> In particular, what does your language give for :
> >>
> >>       int a := 2
> >>       int b := 3
> >>       real c := b / a;
> >>
> >>       println c
> >>
> >>
> >> Does it print 1, or 1.5 ?
> >
> > My languages have two divide operators: "/" and "%".
> >
> > "%" means integer divide. "/" is supposed to be for floating point
> > divide, but that's only on one language; the static one will still
> > do integer divide when both operands are integers.
>
> Genius. Does it also use "and" as a keyword for the remainder after
> division? Nothing says "simple" and "intuitive" like picking
> different meanings for your operators than all other languages.
>

....

> > So M will give 1.0, Q will give 1.5.
> >
>
> That's your two languages that are proudly the same syntax, but handle
> expressions in completely different ways?
>
>
> If you want to keep posting about your own language, please feel free
> - only you can tell if you are making things up as you go along. But
> /please/ stop posting shite about other languages that you refuse to
> understand.
>
> Understand me correctly here - I really don't care if you like C or
> not. I don't care if anyone else here likes it or not, uses it or
> not. I am not interested in promoting C or any other language - I'll
> use what I want to use, and others will use what they want.

Genius. Pick a dead language to program in. That way there is no
chance whatsoever that you'll encounter a new and unknown bug.
Better yet, code your own language so you never have to come across
any unknown bug or only bugs you can fix. Oh, well, that's what Bart
did ... Imagine that. You two are actually in sync.

Did you know that TIOBE ranks programming languages by usage so your
skills aren't obsolete? TIOBE currently ranks C++ at 7.73% and ranks C
at 11.80%.

While picking a dead language is genius for code development, it's
horrible if your code is to be maintained by others. Then, they'll
need some obscure, bit-rotted, uncompilable piece of crud in order to
compile the project. That will make everyone want to hang you. This
problem seriously affects Linux, as I recently had the "pleasure" of
recompiling from code over numerous software packages, probably over
two hundred.

> But what I /do/ react against is lies, FUD, and misrepresentations. I
> am not "pro-C" - I am "anti-FUD", and it just so happens that your
> bizarre hatred of C means it is C you post rubbish about. I'd react
> against anyone else deliberately and repeatedly writing nonsense about
> other topics too.

Well, that would be you.

Your recent incorrect post to comp.compilers about type-punning and
your insistence that arrays in C aren't actually just pointers, i.e.,
pass-by-reference, but instead magically "decay into" pointers.
You need to learn about how the subscript operator [] in C actually
works. It takes a pointer and an index in either order. It
doesn't take arrays. Then, read up on Dennis Ritchie's papers where he
states that make the language syntax appear to match variable
declarations, because not doing so confusing to newbs. You should then
realize that C only has array declarations to allocate storage and
check type, and no actual arrays in C, as they are pointers, and array
syntax is simulated by the subscript operator.

--

On Wed, 8 Dec 2021 18:13:56 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 08/12/2021 17:58, Bart wrote:
> > On 08/12/2021 15:36, David Brown wrote:
> >> On 08/12/2021 12:55, Bart wrote:

> >> What is it with you and your campaign to claim everything C is
> >> bad, and everything in your useless little private language is
> >> good?
> >
> > I said the rules are complex. You said they are simple. I
> > disagreed, and illustrated my point with a chart.
>
> A chart designed purely to make the simple rules of C appear complex -
> it is FUD.

And, some of the simple rules of C ...

C has 14 casting rules.
C has 11 assignment conversion rules.
C has 16 precedence levels.
C has 11 input conversion specifiers.
C has 12 output conversion specifiers.
....

Yeah, I see exactly where you're coming from on C's simple rules.

> You added those of your own language, which is utterly
> irrelevant to C, purely to be able to claim that the rules of your
> language are simple.

Um, no offense, but that seems rather far fetched.

> Note that even if your language's rules are
> simpler in some way, that does /not/ make C's rules complex!

....

> > Are you sure you aren't twisting and making up things yourself?
> >
> >> to make
> >> it look more complicated.
> >
> > I think most people would be surprised at how untidy that chart is.
> > /I/ was.
>
> You seem to find just about everything in C surprising.
>
> But let's be clear here. Do you think people familiar and experienced
> with C programming will find C's rules surprising?

Yes. Some of C's rules are rather bizarre, especially casting rules.

Haven't you ever read Harbison and Steele's "C: A Reference Manual".
It has plenty of tables describing C's rules for all sorts of things.

> >>>> Does it print 1, or 1.5 ?
> >>>
> >>> My languages have two divide operators: "/" and "%".
> >>>
> >>> "%" means integer divide. "/" is supposed to be for floating point
> >>> divide, but that's only on one language; the static one will
> >>> still do integer divide when both operands are integers.
> >>
> >> Genius.  Does it also use "and" as a keyword for the remainder
> >> after division?  Nothing says "simple" and "intuitive" like
> >> picking different meanings for your operators than all other
> >> languages.
> >
> > "%" was used for integer divide in Pascal. I adopted it in the 1980s
> > when I needed distinct operators.
> >
> > And I use "rem" for integer REMainder instead of "%"; "ixor"
> > instead of "^"; "ior" instead of "|" and "or" instead of "||".
> > Maybe it's just me, but I find them more readable.
> >
> > Why, what do other languages use for integer divide?
>
> Most use /. And in most languages, if they have % operator for
> integers, it means modulus. (Conventions differ regarding rounding
> and signs when dividing by negative integers.)
>

As Bart proved, not "**ALL** other languages" as you claimed (emphasis
added), i.e., that was FUD. You can't dismiss Pascal as some
unimportant language.

--

On Wed, 8 Dec 2021 16:58:54 +0000
Bart <bc@freeuk.com> wrote:

> On 08/12/2021 15:36, David Brown wrote:
> > On 08/12/2021 12:55, Bart wrote:

> >>> Does it print 1, or 1.5 ?
> >>
> >> My languages have two divide operators: "/" and "%".
> >>
> >> "%" means integer divide. "/" is supposed to be for floating point
> >> divide, but that's only on one language; the static one will still
> >> do integer divide when both operands are integers.
> >
> > Genius. Does it also use "and" as a keyword for the remainder after
> > division? Nothing says "simple" and "intuitive" like picking
> > different meanings for your operators than all other languages.
>
> "%" was used for integer divide in Pascal. I adopted it in the 1980s
> when I needed distinct operators.

I knew I'd seen that somewhere, but it wasn't Forth or Postscript.
Pascal was 1980s the last time I used it. It was too limited. It
didn't have pointers back then. You were restricted to the Pascal
scope or space, and usually couldn't program the machine it was running
on.

> And I use "rem" for integer REMainder instead of "%"; "ixor" instead
> of "^"; "ior" instead of "|" and "or" instead of "||". Maybe it's
> just me, but I find them more readable.
>

As I think I might've mentioned to James, I happen to prefer C's method
of symbolic operators for math, logical, and binary operations, as it
makes it easier for me to read the variables, keywords, and procedure
names, etc. I.e., easier to separate. This probably came from Algol,
but that was before my time.

--

On 19/12/2021 02:19, Rod Pemberton wrote:
> On Wed, 8 Dec 2021 16:58:54 +0000
> Bart <bc@freeuk.com> wrote:
>
>> On 08/12/2021 15:36, David Brown wrote:

>>> Genius. Does it also use "and" as a keyword for the remainder after
>>> division? Nothing says "simple" and "intuitive" like picking
>>> different meanings for your operators than all other languages.
>>
>> "%" was used for integer divide in Pascal. I adopted it in the 1980s
>> when I needed distinct operators.
>
> I knew I'd seen that somewhere, but it wasn't Forth or Postscript.
> Pascal was 1980s the last time I used it. It was too limited. It
> didn't have pointers back then. You were restricted to the Pascal
> scope or space, and usually couldn't program the machine it was running
> on.

The DEC Pascal I used in the late 70s had pointers.

What it didn't have was a useful treatment of arrays, and some other
things necessary in a real world language. But ours was for teaching
purposes.

On 19/12/2021 03:18, Rod Pemberton wrote:
> On Wed, 8 Dec 2021 16:36:33 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>

>> But what I /do/ react against is lies, FUD, and misrepresentations. I
>> am not "pro-C" - I am "anti-FUD", and it just so happens that your
>> bizarre hatred of C means it is C you post rubbish about. I'd react
>> against anyone else deliberately and repeatedly writing nonsense about
>> other topics too.
>
> Well, that would be you.
>
> Your recent incorrect post to comp.compilers about type-punning and
> your insistence that arrays in C aren't actually just pointers, i.e.,
> pass-by-reference, but instead magically "decay into" pointers.
> You need to learn about how the subscript operator [] in C actually
> works. It takes a pointer and an index in either order. It
> doesn't take arrays. Then, read up on Dennis Ritchie's papers where he
> states that make the language syntax appear to match variable
> declarations, because not doing so confusing to newbs. You should then
> realize that C only has array declarations to allocate storage and
> check type, and no actual arrays in C, as they are pointers, and array
> syntax is simulated by the subscript operator.
>
>

I see you have recently made a lot of posts in replies to things I have
written here, much of it in a rather confrontational tone.

I don't really want to reply to them all, point for point - it would be
a lot of time and effort and of little interest to most people. Some of
what you write is your own opinion, and I can't argue with it - if /you/
want to deify C and consider it the appropriate choice for all
situations, I guess that's up to you. Some of it was fact - Bart was
right about operators in Pascal. Much of it, however, is piddle. If
you don't understand the details of C, but are convinced that you /do/,
then I doubt if there is anything I can write that will change your
mind. If you want to understand what "array" means in C, then I
recommend you read up about them in the C standards. The same goes for
type punning.

Don't rely on ideas you vaguely remember someone saying in your youth -
read the /standards/. That is what defines the language - not mistaken
ideas or misunderstandings, or things that "always worked that way
before", or what someone wrote about it in the past. It doesn't even
matter if the person in question wrote the first book on C, or the first
compiler, or the first draft of the language, or worked on earlier
versions of the standards. The ghost of Dennis Ritchie could post here
saying what he intended C to be if he likes - the C standards valid
today (C18) say what the language /is/. The poster in comp.compilers
completely failed that test - his own personal opinion about older C
standards does not trump the written text of current standards. (Of
course he is free to have an opinion on what C /should/ have been - just
because the standards committee agrees as a whole on particular wording
for the standard does not mean individuals agree on each point.)

And I'd prefer it if you didn't set up imaginary straw men in your
attempts to prove me wrong in some manner. I know how the [] operator
works in C. (I make as many real mistakes as the next person, and don't
need you to invent more in my name.)

On 12/1/21 4:11 PM, Andy Walker wrote:
> On 01/12/2021 08:43, David Brown wrote:
>> [I wrote:]
>>>    Zero, as a number, was invented
>>> in modern times [FSVO "modern"!].
>> (Historical note:
>> It reached Europe around 1200, but had been around in India, amongst
>> other countries, for a good while before that.
>
>     Yes, but that's nearly always zero as a placeholder, not
> as a number in its own right.  [I'm not convinced by many of the
> claimed exceptions, which often smack of flag-waving.]

Note that Indian mathematicians such as Brahmgupta used negative
numbers as early as 7th century. Earlier (3-2 century BC) Pingala
used "shunya" to refer to zero. The *notation* of zero as a place
value came later (by 5-7th century). This makes me thing that the
understanding of zero as a number came earlier than the notation.
[Though, as in many things in Sanskrit, there are multiple meanings
of "shunya" (emptiness, for example) as well as multiple words for
describing the concept of zero!]

David Brown <david.brown@hesbynett.no> wrote:
>
> Whatever kind of numbers you use, you have to apply a few brain cells.
> You can't represent 1/3 with an integer, no matter how big it is. You
> can't represent negative numbers with unsigned types. It's common
> sense, not a "problematic limit".

But common sense is wrong here. One can represent fractions using
integers and it is quite useful when you need exact result but
do not want to deal with explicit fractions. More precisely,
one uses modular integers (so in C that would be unsigned type).
Modulo 2^n odd numbers like 3 are invertible. So you get
171 with 8 bit representation, 43691 with 16 bit, 2863311531
with 32 bit and 12297829382473034411 with 64 bit. That
is really not much different than using 2-complement to
represent negative numbers. Of course, in C there is no
special support for this, '+', '-' and '*' work OK, but
for division and I/O you need extra routines. And, if you
want to stick to machine operations then 1/2 (in fact, any even
number) is problematic because such numbers are not ivertible
modulo 2^n (one could use different modulus, but then all
operations get more complicated).

> Anyone who finds it surprising that
> you can't subtract 3 from 2 without signed numbers should give up their
> programming career and go back to primary school. We have to have
> /some/ standard of education in this profession!

I am affraid that we need _much_ more than primary school...

--
Waldek Hebisch

On 23/01/2022 15:34, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> Whatever kind of numbers you use, you have to apply a few brain cells.
>> You can't represent 1/3 with an integer, no matter how big it is. You
>> can't represent negative numbers with unsigned types. It's common
>> sense, not a "problematic limit".
>

I'm trying to figure out what you are talking about here when you are
resurrecting a long-finished thread.

> But common sense is wrong here.

No, it is not.

Introducing new operations, or new ways to interpret numbers, does not
help. Being able to do something in /theory/ does not necessarily help
in /practice/.

The rationals are countably infinite. It is therefore possible to
represent any rational number (including negative ones) using a
non-negative integer, by producing an appropriate coding scheme. That
does not help in any real use, however. Similarly, you could call a 1
MB executable an 8-million bit integer, but to what purpose? It's
wonderful for proving results about computable problems, but not for
practical programming.

Invertible numbers in modulo arithmetic are equally useless for normal
arithmetic. (They certainly have their uses in encryption and other
fields.) Who cares if 171 is the inverse of 3 modulo 256? What does it
give you? Calculating that 171 is a time-consuming process. You can't
use it to divide by 3 - you only get a useful answer if the numerator
happens to be divisible by 3. You can't find the inverse of 6. You
can't distinguish it from 171, despite 171 being an entirely different
number from 1/3. It does not give you a useful way to represent fractions.

If I remember this thread correctly, the point was that any finite and
limited representation is going to have limits on what it can represent.

David Brown <david.brown@hesbynett.no> wrote:
> On 23/01/2022 15:34, antispam@math.uni.wroc.pl wrote:
> > David Brown <david.brown@hesbynett.no> wrote:
> >>
> >> Whatever kind of numbers you use, you have to apply a few brain cells.
> >> You can't represent 1/3 with an integer, no matter how big it is. You
> >> can't represent negative numbers with unsigned types. It's common
> >> sense, not a "problematic limit".
> >
>
> I'm trying to figure out what you are talking about here when you are
> resurrecting a long-finished thread.
>
> > But common sense is wrong here.
>
> No, it is not.
>
> Introducing new operations, or new ways to interpret numbers, does not
> help. Being able to do something in /theory/ does not necessarily help
> in /practice/.
>
> The rationals are countably infinite. It is therefore possible to
> represent any rational number (including negative ones) using a
> non-negative integer, by producing an appropriate coding scheme. That
> does not help in any real use, however. Similarly, you could call a 1
> MB executable an 8-million bit integer, but to what purpose? It's
> wonderful for proving results about computable problems, but not for
> practical programming.
>
> Invertible numbers in modulo arithmetic are equally useless for normal
> arithmetic. (They certainly have their uses in encryption and other
> fields.) Who cares if 171 is the inverse of 3 modulo 256? What does it
> give you? Calculating that 171 is a time-consuming process.

Sure, like any computation it needs time.

> You can't
> use it to divide by 3 - you only get a useful answer if the numerator
> happens to be divisible by 3.

Not only. If you have apropriate bounds, say numerator has absolute value
less than 10 and denominator is between 1 and 12 you can _uniqely_
reconstruct fraction from such representation. Of course, range of
fractions representable in single byte is small, if you need more
use bigger integer type.

> You can't find the inverse of 6.

Yes, here one needs different modulus, so no longer can directly
use machine arithmetic.

> You
> can't distinguish it from 171,

Well, you need enough bits to have unique representation, there is
no way around this.

> despite 171 being an entirely different
> number from 1/3. It does not give you a useful way to represent fractions.

It is useful as in "used by actual programs" which produce fractions
as results.

> If I remember this thread correctly, the point was that any finite and
> limited representation is going to have limits on what it can represent.

Sure. However, IMO your wording was unfortunate. You probably do
not need such representation and normal programming languages have
no support for it. But this is tradof based on popular needs
and not an absolute impossibility.

--
Waldek Hebisch

On 24/01/2022 17:08, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 23/01/2022 15:34, antispam@math.uni.wroc.pl wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> Whatever kind of numbers you use, you have to apply a few brain cells.
>>>> You can't represent 1/3 with an integer, no matter how big it is. You
>>>> can't represent negative numbers with unsigned types. It's common
>>>> sense, not a "problematic limit".
>>>
>>
>> I'm trying to figure out what you are talking about here when you are
>> resurrecting a long-finished thread.
>>
>>> But common sense is wrong here.
>>
>> No, it is not.
>>
>> Introducing new operations, or new ways to interpret numbers, does not
>> help. Being able to do something in /theory/ does not necessarily help
>> in /practice/.
>>
>> The rationals are countably infinite. It is therefore possible to
>> represent any rational number (including negative ones) using a
>> non-negative integer, by producing an appropriate coding scheme. That
>> does not help in any real use, however. Similarly, you could call a 1
>> MB executable an 8-million bit integer, but to what purpose? It's
>> wonderful for proving results about computable problems, but not for
>> practical programming.
>>
>> Invertible numbers in modulo arithmetic are equally useless for normal
>> arithmetic. (They certainly have their uses in encryption and other
>> fields.) Who cares if 171 is the inverse of 3 modulo 256? What does it
>> give you? Calculating that 171 is a time-consuming process.
>
> Sure, like any computation it needs time.
>
>> You can't
>> use it to divide by 3 - you only get a useful answer if the numerator
>> happens to be divisible by 3.
>
> Not only. If you have apropriate bounds, say numerator has absolute value
> less than 10 and denominator is between 1 and 12 you can _uniqely_
> reconstruct fraction from such representation. Of course, range of
> fractions representable in single byte is small, if you need more
> use bigger integer type.
>
>> You can't find the inverse of 6.
>
> Yes, here one needs different modulus, so no longer can directly
> use machine arithmetic.
>
>> You
>> can't distinguish it from 171,
>
> Well, you need enough bits to have unique representation, there is
> no way around this.

Yes, and that is a key point.

Another important point is that if you want to represent rationals in a
practical and useful manner, this is not the way to do it - a pair of
integers (of some fixed size, or of variable size) is vastly more
convenient for most purposes.

>
>> despite 171 being an entirely different
>> number from 1/3. It does not give you a useful way to represent fractions.
>
> It is useful as in "used by actual programs" which produce fractions
> as results.

No, it will not be - the format is too inconvenient for most purposes.
There may be niche cases where it is useful (I am guessing that
cryptography could be one area, but I am not an expert there).

The same applies to other types of "number", such as doing your
arithmetic over the Galois Field GF(2⁸). Now every number from 1 to 255
has a unique multiplicative inverse. This can let you do marvellous
things - such as guaranteeing a solution to the simultaneous equations
used to restore RAID6 disk sets when two drives are dead. But it also
means that while 20 / 5 is 4, 20 / 3 is 12 and 20 / 6 is 6. It is
useless for "normal" division (or normal multiplication, addition or
subtraction).

>
>> If I remember this thread correctly, the point was that any finite and
>> limited representation is going to have limits on what it can represent.
>
> Sure. However, IMO your wording was unfortunate. You probably do
> not need such representation and normal programming languages have
> no support for it. But this is tradof based on popular needs
> and not an absolute impossibility.
>

I'll agree with that.

David Brown <david.brown@hesbynett.no> wrote:
> On 24/01/2022 17:08, antispam@math.uni.wroc.pl wrote:
> > David Brown <david.brown@hesbynett.no> wrote:
> >> On 23/01/2022 15:34, antispam@math.uni.wroc.pl wrote:
> >>> David Brown <david.brown@hesbynett.no> wrote:
> >>>>
> >>>> Whatever kind of numbers you use, you have to apply a few brain cells.
> >>>> You can't represent 1/3 with an integer, no matter how big it is. You
> >>>> can't represent negative numbers with unsigned types. It's common
> >>>> sense, not a "problematic limit".
> >>>
> >>
> >> I'm trying to figure out what you are talking about here when you are
> >> resurrecting a long-finished thread.
> >>
> >>> But common sense is wrong here.
> >>
> >> No, it is not.
> >>
> >> Introducing new operations, or new ways to interpret numbers, does not
> >> help. Being able to do something in /theory/ does not necessarily help
> >> in /practice/.
> >>
> >> The rationals are countably infinite. It is therefore possible to
> >> represent any rational number (including negative ones) using a
> >> non-negative integer, by producing an appropriate coding scheme. That
> >> does not help in any real use, however. Similarly, you could call a 1
> >> MB executable an 8-million bit integer, but to what purpose? It's
> >> wonderful for proving results about computable problems, but not for
> >> practical programming.
> >>
> >> Invertible numbers in modulo arithmetic are equally useless for normal
> >> arithmetic. (They certainly have their uses in encryption and other
> >> fields.) Who cares if 171 is the inverse of 3 modulo 256? What does it
> >> give you? Calculating that 171 is a time-consuming process.
> >
> > Sure, like any computation it needs time.
> >
> >> You can't
> >> use it to divide by 3 - you only get a useful answer if the numerator
> >> happens to be divisible by 3.
> >
> > Not only. If you have apropriate bounds, say numerator has absolute value
> > less than 10 and denominator is between 1 and 12 you can _uniqely_
> > reconstruct fraction from such representation. Of course, range of
> > fractions representable in single byte is small, if you need more
> > use bigger integer type.
> >
> >> You can't find the inverse of 6.
> >
> > Yes, here one needs different modulus, so no longer can directly
> > use machine arithmetic.
> >
> >> You
> >> can't distinguish it from 171,
> >
> > Well, you need enough bits to have unique representation, there is
> > no way around this.
>
> Yes, and that is a key point.
>
> Another important point is that if you want to represent rationals in a
> practical and useful manner, this is not the way to do it - a pair of
> integers (of some fixed size, or of variable size) is vastly more
> convenient for most purposes.

Rationals as pairs of integers of fixed size are a toy, useless
if you want to do serious computations. Basic point about rationals
is that there is tendency to have very big numerators and denominators.
Without simplifying common factors in many cases one gets exponential
growth of length of numerators and denominators. Canceling common
factors is expensive and still there is growth (but only linear).
If _intermediate_ numbers exceed representable range, the best you
can hope is modular result. But if you are after modular result
why bother with numerators and denominators?

Note: there are important special cases when final result is small
but intermediate results if represented in naive way would be
prohibitively big. And even is final result is big there are
cases when one can relatively easily increase modulus so that
modulus is big enough to uniquely reconstruct result.

Variable size numerators and denominators are general way, relatively
easy to program but may be inefficient. Sometimes there are no
better way. But there are important cases when modular calculations
gives result that would be essentially imposible to obtain using
general representation (think of using several TB of memory instead
of say 1G).

> >
> >> despite 171 being an entirely different
> >> number from 1/3. It does not give you a useful way to represent fractions.
> >
> > It is useful as in "used by actual programs" which produce fractions
> > as results.
>
> No, it will not be - the format is too inconvenient for most purposes.
> There may be niche cases where it is useful (I am guessing that
> cryptography could be one area, but I am not an expert there).

I wrote my sentence in present tense, future is too hard to predict...
You may consider exact computations as a niche. But by this token
probably most programs are niche: there is small number of widely
used popular programs and long tail of specialized programs that each
have relativly small number of users. It is pretty clear that
when you count programs (as opposed to users) most programs will
be in this long tail.

BTW: I am not aware of serious use of Z(2^n) in crypthography
(I am not saying it is not used, just that I mainstream
cryptosystem that heard about do not use it)
From my point of view crypthography is good because thanks to
crypthography processor makers got more serious about performance
of multiprecision arithmetic. But I am really not going deep
into crypthography...

> The same applies to other types of "number", such as doing your
> arithmetic over the Galois Field GF(2?). Now every number from 1 to 255
> has a unique multiplicative inverse. This can let you do marvellous
> things - such as guaranteeing a solution to the simultaneous equations
> used to restore RAID6 disk sets when two drives are dead. But it also
> means that while 20 / 5 is 4, 20 / 3 is 12 and 20 / 6 is 6.

Not sure what you mean here: GF(2^n) is different than Z(2^n) and
there is no natural correspondence between elements of GF(2^n)
and Z(2^n). In particular in GF(2^n) we have 1 + 1 = 0, so natural
image of 2 = 1 + 1 definitely is not invertible. If you fix irreducible
polynomial there is correspondence between bitstrings of length n
and elements of GF(2^n). But to multiply bitstrings you should
do "carryless mutiplication" and then reduce modulo irreducible
polynomial...

> It is
> useless for "normal" division (or normal multiplication, addition or
> subtraction).

GF(2^n) has uses when you deal with polynomials. But unless
hardware efficiently supports carryless mutiplication it is
usually more efficient to use Z(p) for prime p > 2. That
is assuming that you care only about polynomials with rational
cofficients (if you deal with Z(2) you may be forced to use GF(2^n)).

--
Waldek Hebisch

On 29/01/2022 03:21, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 24/01/2022 17:08, antispam@math.uni.wroc.pl wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 23/01/2022 15:34, antispam@math.uni.wroc.pl wrote:
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>>
>>>>>> Whatever kind of numbers you use, you have to apply a few brain cells.
>>>>>> You can't represent 1/3 with an integer, no matter how big it is. You
>>>>>> can't represent negative numbers with unsigned types. It's common
>>>>>> sense, not a "problematic limit".
>>>>>
>>>>
>>>> I'm trying to figure out what you are talking about here when you are
>>>> resurrecting a long-finished thread.
>>>>
>>>>> But common sense is wrong here.
>>>>
>>>> No, it is not.
>>>>
>>>> Introducing new operations, or new ways to interpret numbers, does not
>>>> help. Being able to do something in /theory/ does not necessarily help
>>>> in /practice/.
>>>>
>>>> The rationals are countably infinite. It is therefore possible to
>>>> represent any rational number (including negative ones) using a
>>>> non-negative integer, by producing an appropriate coding scheme. That
>>>> does not help in any real use, however. Similarly, you could call a 1
>>>> MB executable an 8-million bit integer, but to what purpose? It's
>>>> wonderful for proving results about computable problems, but not for
>>>> practical programming.
>>>>
>>>> Invertible numbers in modulo arithmetic are equally useless for normal
>>>> arithmetic. (They certainly have their uses in encryption and other
>>>> fields.) Who cares if 171 is the inverse of 3 modulo 256? What does it
>>>> give you? Calculating that 171 is a time-consuming process.
>>>
>>> Sure, like any computation it needs time.
>>>
>>>> You can't
>>>> use it to divide by 3 - you only get a useful answer if the numerator
>>>> happens to be divisible by 3.
>>>
>>> Not only. If you have apropriate bounds, say numerator has absolute value
>>> less than 10 and denominator is between 1 and 12 you can _uniqely_
>>> reconstruct fraction from such representation. Of course, range of
>>> fractions representable in single byte is small, if you need more
>>> use bigger integer type.
>>>
>>>> You can't find the inverse of 6.
>>>
>>> Yes, here one needs different modulus, so no longer can directly
>>> use machine arithmetic.
>>>
>>>> You
>>>> can't distinguish it from 171,
>>>
>>> Well, you need enough bits to have unique representation, there is
>>> no way around this.
>>
>> Yes, and that is a key point.
>>
>> Another important point is that if you want to represent rationals in a
>> practical and useful manner, this is not the way to do it - a pair of
>> integers (of some fixed size, or of variable size) is vastly more
>> convenient for most purposes.
>
> Rationals as pairs of integers of fixed size are a toy, useless
> if you want to do serious computations. Basic point about rationals
> is that there is tendency to have very big numerators and denominators.
> Without simplifying common factors in many cases one gets exponential
> growth of length of numerators and denominators. Canceling common
> factors is expensive and still there is growth (but only linear).

I am aware of this, and I agree that rationals as pairs of integers
don't have a lot of uses, and in particular you don't want to do a lot
of arithmetic with them or you have a good chance of getting really
large numbers.

The points is that /if/ you need rationals, that is the way to hold them
and use them.

When you are using other types of arithmetic and division, such as
modular arithmetic or Galois fields, you are not using rational numbers.
It's a different field - a different mathematical structure. They can
often be useful, and much more efficient than rationals, and sometimes
you can use them for calculations that give results which correspond to
results from rational numbers (but calculated more efficiently).

>
>>>
>>>> despite 171 being an entirely different
>>>> number from 1/3. It does not give you a useful way to represent fractions.
>>>
>>> It is useful as in "used by actual programs" which produce fractions
>>> as results.
>>
>> No, it will not be - the format is too inconvenient for most purposes.
>> There may be niche cases where it is useful (I am guessing that
>> cryptography could be one area, but I am not an expert there).
>
> I wrote my sentence in present tense, future is too hard to predict...
> You may consider exact computations as a niche. But by this token
> probably most programs are niche: there is small number of widely
> used popular programs and long tail of specialized programs that each
> have relativly small number of users. It is pretty clear that
> when you count programs (as opposed to users) most programs will
> be in this long tail.

I suppose you could say that, yes.

>
> BTW: I am not aware of serious use of Z(2^n) in crypthography
> (I am not saying it is not used, just that I mainstream
> cryptosystem that heard about do not use it)

Modular arithmetic turns up a lot in cryptography, but not over 2^n.
Normally you are using bases that are calculated from large prime
numbers. (RSA public/private key systems are a popular example.)

> From my point of view crypthography is good because thanks to
> crypthography processor makers got more serious about performance
> of multiprecision arithmetic. But I am really not going deep
> into crypthography...
>

Does the hardware here have other uses? I've seen hardware accelerators
for things like 3DES and AES symmetric cyphers, and for SHA hashes.
I've also seen dedicated chips for elliptical-curve cryptography (of
which I know almost nothing). But I don't know how these could be of
any use for multiprecision integer arithmetic.

>> The same applies to other types of "number", such as doing your
>> arithmetic over the Galois Field GF(2?). Now every number from 1 to 255
>> has a unique multiplicative inverse. This can let you do marvellous
>> things - such as guaranteeing a solution to the simultaneous equations
>> used to restore RAID6 disk sets when two drives are dead. But it also
>> means that while 20 / 5 is 4, 20 / 3 is 12 and 20 / 6 is 6.
>
> Not sure what you mean here: GF(2^n) is different than Z(2^n) and
> there is no natural correspondence between elements of GF(2^n)
> and Z(2^n).

Correct.

> In particular in GF(2^n) we have 1 + 1 = 0, so natural
> image of 2 = 1 + 1 definitely is not invertible.

Exactly as you say, you do your multiplications modulo an irreducible
polynomial.

The most important practical choice of representation and polynomial,
since it is used to give efficient RAID6 implementations, is to reduce
modulo x⁸ + x⁴ + x³ + x² + 1. Then your "multiply by 2" operation is :

def times_g(x) :
# Multiply mod x⁸ + x⁴ + x³ + x² + 1
if (x & 0x80) :
return ((x << 1) ^ 0x1d) & 0xff
else :
return (x << 1) & 0xff

"2" is /not/ the sum of "1" and "1" - you don't have an additive
generator. You have a multiplicative generator "g" which corresponds to
2. The inverse of 2 corresponds to 0x8e. Since every non-zero number
raised to the power 255 is 1, you can calculate 2^-1 as 2^254, using the
"times_g" operation 254 times to get 0x8e.

> If you fix irreducible
> polynomial there is correspondence between bitstrings of length n
> and elements of GF(2^n). But to multiply bitstrings you should
> do "carryless mutiplication" and then reduce modulo irreducible
> polynomial...
>

Yes.

>> It is
>> useless for "normal" division (or normal multiplication, addition or
>> subtraction).
>
> GF(2^n) has uses when you deal with polynomials. But unless
> hardware efficiently supports carryless mutiplication it is
> usually more efficient to use Z(p) for prime p > 2. That
> is assuming that you care only about polynomials with rational
> cofficients (if you deal with Z(2) you may be forced to use GF(2^n)).
>

On 02/12/2021 22:38, Bart wrote:
> On 02/12/2021 21:25, James Harris wrote:
>> On 02/12/2021 20:11, Bart wrote:

....

> Continuous measurements need to start from 0.0.

Surely you mean 0.1. ;-)

>
> Discrete entities are counted, starting at 0 for none, then 1 for 1 (see
> Xs below).

Counting and indexing are different things. Whether one indexes from 0
or 1 or 197 the count will still be the count.

I agree with you about /discreet/ entities being identifiable starting
from 1 but if any subdivision of the units is possible (either at the
time a program is written or later) then labelling starting from 1 could
well become awkward. That's why indexing from zero is more natural
mathematically, even though it is less natural societally.

>
> Some are in-between, where continuous quantities are represented as lots
> of small steps. (Example: money in steps of £0.01, or time measured in
> whole seconds.)

Again, if one indexes from zero in all cases then the issues of
subdivision no longer apply.

Don't get me wrong. I agree that indexing is more familiar to humans as
starting from 1. We learn to deal in discreet quantities.

....

>> But do you see the point of it? The first century /naturally/ had
>> century number zero, not one, and the N'th century has century number
>>
>>    N - 1
>>
>> IOW the numbering begins at zero.
>
> Define what you mean by numbering first.

By numbering in this case I mean indexing, labelling.

>
> For me it means assigning sequential integers to a series of entities.

Sure.

> But you need an entity to hang a number from. With no entities, where
> are you going to stick that zero?

In terms of centuries we call the first "zero". Why? Because it's
mathematically /natural/ to do so. That's despite it being more familiar
to us as humans to begin counting from 1.

I would add that it takes mental effort to say what century is the 15th,
for example, because it's not labelled 15.

Similarly, it's awkward to refer to the "15th element" of a zero-based
array so I prefer to call it "element 14" then there's no discrepancy.

....

> I'm not sure what you're trying to argue here; that because 0 is used to
> mean nothing, then that must be the start point for everything?

I'm not trying to argue or to win an argument, BTW, just to challenge
your view and explore the issue.

>
> Here are some sets of Xs increasing in size:
>
>              How many X's?   Numbered as?  Number of the Last?
>   --------
>    -         0               -             -
>   --------
>    X         1               1             1
>   --------
>    X X       2               1 2           2
>   --------
>    X X X     3               1 2 3         3
>   --------
>
> How would /you/ fill in those columns? I'd guess my '1 2 3' becomes '0 1
> 2', and that that last '3' becomes '2'.
>
> But what about the first '3' on that last line; don't tell me it becomes
> '2'! (Because then what happens to the '0'?)

In human terms I'd number them as you do but when writing software I've
found that a different way is more consistent, more scalable and more
mathematically natural.

Your How Many column I would have the same as you do.

Your Numbered As column I'd have as 0, 1, 2.

>
> Using you scheme (as I assume it will be); there is too much disconnect:
> a '0' in the first row, and two 0s the second; a '1' in the second, and
> two 1s in the third. Everything is out of step!
>
>> Yes, you are talking about discreet units which are not made of parts.
>
> Yes, arrays of elements that are computer data with no physical dimensions.

Indeed, although if there's even any chance of later subdivision then
1-based indexing becomes mathematically unnatural.

As a compiler writer you will be aware of having to work in zero-based
/offsets/ rather than 1-based indexes.

--
James Harris

On 03/12/2021 00:08, David Brown wrote:
> On 02/12/2021 22:25, James Harris wrote:

....

>> That's not a convention, by the way, but how all numbering works: things
>> with partial phases begin at zero.
>>
> Note, however, that the first century began with year 1 AD (or 1 CE, if
> you prefer). The preceding year was 1 BC. There was no year 0. This
> means the first century was the years 1 to 100 inclusive.
>
> It really annoyed me that everyone wanted to celebrate the new
> millennium on 01.01.2000, when in fact it did not begin until 01.01.2001.

I never understood that annoyance. The exact length of the millennium
was messed up by the Julian calendar (i.e. you may still have been a day
out) and the supposed start point was somewhat arbitrary anyway, with
Jesus likely being born a year or two /before/ what came to be called
year 1 and certainly not at midnight on 31 December!

So to me the notable point was when the calendar rolled over. It was
always going to be an artificial date so why not go with the numbering?

>
> It would have been so much simpler, and fitted people's expectations
> better, if years have been numbered from 0 onwards instead of starting
> counting at 1.

Indeed.

--
James Harris

On 03/12/2021 09:08, David Brown wrote:
> On 02/12/2021 22:42, James Harris wrote:
>> On 02/12/2021 20:49, Dmitry A. Kazakov wrote:
>>> On 2021-12-02 21:31, James Harris wrote:
>>
>> ...
>>
>>>> But to the point, are you comfortable with the idea of the A(2) in
>>>>
>>>>    x = A(2) + 0
>>>>
>>>> meaning the same mapping result as the A(2) in
>>>>
>>>>    A(2) = 0
>>>>
>>>> ?
>>>
>>> Yes, in both cases the result is the array element corresponding to
>>> the index 2. That is the semantics of A(2).
>>
>> Cool. If A were, instead, a function that, say, ended with
>>
>>   return v
>>
>> then what would you want those A(2)s to mean and should they still mean
>> the same as each other? The latter expression would look strange to many.
>>
>
> Do you mean like returning a reference in C++ style?

Hi David, apologies for not replying before. I was just now looking for
old posts that were outstanding in some way. (There may be many which I
have yet to reply to like your one.)

I probably left your post until I found out about C++ references and
never got round to reading up on them.

>
>
> int a[10];
>
> void foo1(int i, int x) {
> a[i] = x;
> }
>
> int& A(int i) {
> return a[i];
> }
>
> void foo2(int i, int x) {
> A(i) = x;
> }
>
> foo1 and foo2 do the same thing, and have the same code. Of course,
> foo2 could add range checking, or offsets (for 1-based array), or have
> multiple parameters for multi-dimensional arrays, etc. And in practice
> you'd make such functions methods of a class so that the class owns the
> data, rather than having a single global source of the data.

I see at https://www.geeksforgeeks.org/references-in-cpp/ code which
includes

void swap(int& first, int& second)
{ int temp = first;
first = second;
second = temp;
}

That's not what I was thinking about. I don't care for it because in a
call such as

swap(a, b)

it's not clear in the syntax that the arguments a and b can be modified
- a calamity of a design, IMO. :-(

But in your case you are referring to a /returned/ value. That appears
to be OK except that to match what I had in mind I think there should be
a const in there somewhere. To illustrate, I was proposing that in a
function, f, one could have

return h

which would /conceptually/ return the address of h (which I guess in
Algol terms means it would return h rather than the value of h).
Crucially, and perhaps at variance with Algol (I don't know) the value
of h (i.e. the value at the returned address) would be read-only to the
caller.

The caller would be able to use the address returned as it could any
other address, but it could not write over the referenced value. If the
callee returned with something like

return a[4]

then it would conceptually return the address of a[4] and, again, the
value at the returned address would be read-only in the caller.

What I've said so far is by default but overwriting would be possible.
To conceptually return the address of a variable which /could/ be
overwritten one would use the rw modifier as in

return rw h

or

return rw a[4]

I'll say no more just now as this is an old topic but I wanted to at
least make a reply.

--
James Harris

On 08/12/2023 20:28, James Harris wrote:
> On 03/12/2021 09:08, David Brown wrote:
>> On 02/12/2021 22:42, James Harris wrote:
>>> On 02/12/2021 20:49, Dmitry A. Kazakov wrote:
>>>> On 2021-12-02 21:31, James Harris wrote:
>>>
>>> ...
>>>
>>>>> But to the point, are you comfortable with the idea of the A(2) in
>>>>>
>>>>>     x = A(2) + 0
>>>>>
>>>>> meaning the same mapping result as the A(2) in
>>>>>
>>>>>     A(2) = 0
>>>>>
>>>>> ?
>>>>
>>>> Yes, in both cases the result is the array element corresponding to
>>>> the index 2. That is the semantics of A(2).
>>>
>>> Cool. If A were, instead, a function that, say, ended with
>>>
>>>    return v
>>>
>>> then what would you want those A(2)s to mean and should they still mean
>>> the same as each other? The latter expression would look strange to
>>> many.
>>>
>>
>> Do you mean like returning a reference in C++ style?
>
> Hi David, apologies for not replying before. I was just now looking for
> old posts that were outstanding in some way. (There may be many which I
> have yet to reply to like your one.)
>
> I probably left your post until I found out about C++ references and
> never got round to reading up on them.
>

I saw my post was dated 03.12 (or 12.03, for any date-backwards
Americans in the audience) and thought it was strange that I'd forgotten
the post from 5 days ago. Then I noticed the year...

I'll try to reply, but forgive me if I've forgotten details of the thread!

>>
>>
>> int a[10];
>>
>> void foo1(int i, int x) {
>>      a[i] = x;
>> }
>>
>> int& A(int i) {
>>      return a[i];
>> }
>>
>> void foo2(int i, int x) {
>>      A(i) = x;
>> }
>>
>> foo1 and foo2 do the same thing, and have the same code.  Of course,
>> foo2 could add range checking, or offsets (for 1-based array), or have
>> multiple parameters for multi-dimensional arrays, etc.  And in practice
>> you'd make such functions methods of a class so that the class owns the
>> data, rather than having a single global source of the data.
>
> I see at https://www.geeksforgeeks.org/references-in-cpp/ code which
> includes
>
> void swap(int& first, int& second)
> {
>     int temp = first;
>     first = second;
>     second = temp;
> }
>
> That's not what I was thinking about. I don't care for it because in a
> call such as
>
>   swap(a, b)
>
> it's not clear in the syntax that the arguments a and b can be modified
> - a calamity of a design, IMO. :-(
>

That is a reasonable view. It is not uncommon in C++ programming to
have a rule that you use pointers when the operands will be changed, and
only use references as "const T&" types. Since the function can't
change data that is passed by const reference, from the caller viewpoint
it is just like passing by value. The only real difference is the
efficiency - whether a real value is passed, or an address pointing to
the value.

> But in your case you are referring to a /returned/ value. That appears
> to be OK except that to match what I had in mind I think there should be
> a const in there somewhere. To illustrate, I was proposing that in a
> function, f, one could have
>
>   return h
>
> which would /conceptually/ return the address of h (which I guess in
> Algol terms means it would return h rather than the value of h).
> Crucially, and perhaps at variance with Algol (I don't know) the value
> of h (i.e. the value at the returned address) would be read-only to the
> caller.

That would be returning a const reference, in C++ terms. And like const
reference parameters, it is semantically very similar to returning a
value, but with possible efficiency differences. The only thing you
need to be careful about is whether the object pointed to still exists -
you don't want to return a reference to a local object!

>
> The caller would be able to use the address returned as it could any
> other address, but it could not write over the referenced value. If the
> callee returned with something like
>
>   return a[4]
>
> then it would conceptually return the address of a[4] and, again, the
> value at the returned address would be read-only in the caller.
>
> What I've said so far is by default but overwriting would be possible.
> To conceptually return the address of a variable which /could/ be
> overwritten one would use the rw modifier as in
>
>   return rw h
>
> or
>
>   return rw a[4]
>
> I'll say no more just now as this is an old topic but I wanted to at
> least make a reply.
>
>
>