On 27/09/2023 17:35, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>
>>> (Nesting, indirection, and dimensioning are all related to each other).
>> No, they are not.
>>
> You haven't thought this through, have you?

Yes, I have.

I mean, obviously if you want to have an n-dimensional array and loop
through it all, you'll have n levels of nesting, and your array access
is technically through pointers with n levels of indirection.

However, your ideas that this is all about the sacred number 3 is nonsense.

I have no problem using perhaps five levels of indirection in my code.
I'd be fine with more too, but that would be very unlikely to occur
simply because the function would be too big and complex, and would
already be split up.

I don't like more than one level of indirection, at least as raw
pointers. "*p" is fine - "**p" is asking for confusion. "xs[1][2]"
could be okay, but I rarely see use of anything more that is not better
handled with local variables for the parts.

For dimensions, two is usually the easiest. Thinking in four dimensions
is possible to some extent, but definitely hard. (Thinking about more
is fine in some ways, but then it's all pretty abstract mathematics.)

For other people, the mixes and numbers might be entirely different,
depending on their usual practices.

The numbers don't line up. They are entirely different concepts. The
only thing they have in common is a general pattern of "more is harder".

On 27/09/2023 14:32, Bart wrote:
> On 27/09/2023 10:37, David Brown wrote:
>
>
>> I will even write something like this on occasion :
>>
>>      if (<complicated condition>) {
>>          // Everything is fine, nothing to do
>>      } else {
>>          do_something();
>>      }
>>
>> rather than
>>
>>      if (!(<complicated condition>)) {
>>          do_something();
>>      }
>>
>> It is all about what is clearest to read.
>
> I have a version of 'if' called 'unless', which sometimes reads better,
> but not always.
>
> In particular, although 'unless' can have an 'else' branch, it doesn't
> have 'else-unless'; I couldn't work out what it meant!

There are a few different varieties of conditionals that have been tried
in different programming languages. That includes syntaxes roughly like
"x = x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I
have remembered the details correctly. I don't think it really helps to
have too many ways of doing the same thing - there has to be very clear
gains to make it worth the effort.

>
> Also, while C has 'do...while', my equivalent is 'repeat...until', with
> the opposite logic.

That's fine - I think either works well.

>
> I can't have repeat...while as that is ambiguous: the 'while' could be
> starting a new loop. Actually I had some troubling figuring out how C
> manages to avoid the same problem.
>
>
> (Note that I can write C's
>
>     do {a;b;c;} while (cond);
>
> as:
>
>     while a;b;c; cond do end
>
> Ugly, though.)
>
>

On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
> On 27/09/2023 17:35, Malcolm McLean wrote:
> > On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
> >> On 27/09/2023 12:37, Malcolm McLean wrote:
> >>
> >>> (Nesting, indirection, and dimensioning are all related to each other).
> >> No, they are not.
> >>
> > You haven't thought this through, have you?
> Yes, I have.
>
> I mean, obviously if you want to have an n-dimensional array and loop
> through it all, you'll have n levels of nesting, and your array access
> is technically through pointers with n levels of indirection.
>
Exactly. Not exactly a controversial idea, is it?
Nesting, indirection, and dimensioning are all related to each other.
And we can visualise three dimensions easily enough, because we live
in a world with three dimensions of space. To visualise four dimensions,
you have to add time, which makes it a different sort of mental exercise.

So three is the magic number.

On 27/09/2023 19:46, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>
>>>>> (Nesting, indirection, and dimensioning are all related to each other).
>>>> No, they are not.
>>>>
>>> You haven't thought this through, have you?
>> Yes, I have.
>>
>> I mean, obviously if you want to have an n-dimensional array and loop
>> through it all, you'll have n levels of nesting, and your array access
>> is technically through pointers with n levels of indirection.
>>
> Exactly. Not exactly a controversial idea, is it?

No, but not particularly relevant. Being able to think of a single
situation where three things might be used together does not make them
particularly related.

Let me just ask you - have you ever written code with nesting that did
not use indirection or dimensions? Of course you have. Have you ever
had a 2 or more dimensional array, and used it in a way that did not
involve indirection in the source code? Of course you have - people
write "xs[1][2]", not some mess involving multiple pointer dereference
operators. Have you ever used a pointer without nesting? Of course you
have. These concepts are not closely related or tied together, even if
they sometimes happen to be used in the same code.

> Nesting, indirection, and dimensioning are all related to each other.

No.

> And we can visualise three dimensions easily enough, because we live
> in a world with three dimensions of space.

Yes.

> To visualise four dimensions,
> you have to add time, which makes it a different sort of mental exercise.

No. You don't have to use time as the fourth dimension. Sometimes it
can be convenient, but certainly not always. Sometimes you use time as
a second or third dimension, sometimes you don't use it at all. I am
quite happy imagining Klein bottles, hypercubes and 4-simplexes with
four spacial dimensions. I am quite happy doing some maths with
many-dimensional spheres (they have a few uses, and do weird things),
with no sign of a time dimension. On the other hand, some physicists
work with one physical dimension and three time dimensions. And
sometimes it makes sense to think of all kinds of different properties
of objects as "dimensions".

Perhaps /you/ can only think of a fourth dimension as time, but please
don't project your own limitations onto others.

>
> So three is the magic number.

No.

Seriously. Just "no".

Even if you were right that nesting, indirection and dimensioning were
strongly related - even though they most certainly are not - that would
not make three a magic number.

You really have to get off this hobby-horse you have invented. The more
you repeat it and spout increasingly unsubstantiated
post-rationalisations for your obsession, the more fanatical you look.

On 27/09/2023 18:46, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>
>>>>> (Nesting, indirection, and dimensioning are all related to each other).
>>>> No, they are not.
>>>>
>>> You haven't thought this through, have you?
>> Yes, I have.
>>
>> I mean, obviously if you want to have an n-dimensional array and loop
>> through it all, you'll have n levels of nesting, and your array access
>> is technically through pointers with n levels of indirection.
>>
> Exactly. Not exactly a controversial idea, is it?
> Nesting, indirection, and dimensioning are all related to each other.
> And we can visualise three dimensions easily enough, because we live
> in a world with three dimensions of space. To visualise four dimensions,
> you have to add time, which makes it a different sort of mental exercise.
>
> So three is the magic number.

I don't think it works. Computer source code is usually 2-dimensional,
tends to be limited horizontally, but has no particular limits vertically.

The code unit is the 'function', which are not usually that tall, as
they become unmanageable, and are not that wide either as people don't
like scrolling sideways. That's why text like this wraps onto the next
line, but that doesn't work for code which is line- not paragraph-oriented.

When talking about function nesting, my own magic number is 1, and
standard C doesn't allow more anyway. So people are welcome to limit
those to three, as I don't care!

But imagine applying the 'rule of three' to:

- The number of lines in a function

- The number of functions in a module

- The number of modules in a program

- The number of fields in a struct

It doesn't work, does it? Or is this more about nesting?

Was there also something about the number of nested parentheses in an
expression? You don't really need a rule, as it will be obvious when
there are far too many.

David Brown <david.brown@hesbynett.no> writes:
> On 27/09/2023 19:46, Malcolm McLean wrote:
[...]
>> So three is the magic number.
>
> No.
>
> Seriously. Just "no".
[...]

David, do you think you're going to change his mind?

This discussion will end at some point without a resolution.
I suggest that now would be a good time for that.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 27/09/2023 20:45, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 27/09/2023 19:46, Malcolm McLean wrote:
> [...]
>>> So three is the magic number.
>>
>> No.
>>
>> Seriously. Just "no".
> [...]
>
> David, do you think you're going to change his mind?
>

It seems unlikely, that's true. I am afraid my tactics may have been
inspired by watching too much Black Adder. (If anyone wants a break
from discussing C, look up "Advanced World War I Tactics with General
Melchett" on youtube.)

> This discussion will end at some point without a resolution.
> I suggest that now would be a good time for that.
>

You are almost certainly right.

Malcolm McLean:
> David Brown:
> > Malcolm McLean:
> >
> > > (Nesting, indirection, and dimensioning are all
> > > related to each other).
> >
> > No, they are not.
>
> You haven't thought this through, have you?

I agree with David. Dimensions entities on the level. They
are orthogonal and equal, that is you cannot place them into
any kind of hierarchy, in which, for example, height is
below or above width. Dimensions form an unordered set (the
tautology rhetorical). Not so with nesting and indirection,
which express a hierarchy and form an ordered sequence (the
tautology rhetorical).

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 9/26/2023 8:29 AM, Malcolm McLean wrote:
> On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote:
>> On 26/09/2023 13:37, Anton Shepelev wrote:
>>>
>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>> decreed that a function shall not have more then three
>>> levels of nesting, his enourmous tab serving as a dumb,
>>> primitive, mechanical, and ugly means of enforsing this
>>> decree.
>> No, Linus was wrong - as he is on many things. (He's right on many
>> things too, of course.) We are not using typewriters, we are not using
>> 80x25 character displays, and we do not need to have pointless
>> limitations. I don't advocate for deeply nested or overly complex
>> functions, of course - I advocate for clear code with immediately
>> obvious blocks indicated by braces /and/ indents. And if clear code
>> requires more than 3 levels of nesting, use that.
>>
> Rule of three. Three levels of nesting or indirection. Because we live in a three
> dimensional world.

Personally, I have never heard of that rule before Malcolm. However, if
I was working for you, I would learn about it and strive to follow it
because you would be my boss in this scenario. No problem.

Section 3.2 page 12:

https://www.stroustrup.com/JSF-AV-rules.pdf

On 9/27/2023 10:46 AM, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>
>>>>> (Nesting, indirection, and dimensioning are all related to each other).
>>>> No, they are not.
>>>>
>>> You haven't thought this through, have you?
>> Yes, I have.
>>
>> I mean, obviously if you want to have an n-dimensional array and loop
>> through it all, you'll have n levels of nesting, and your array access
>> is technically through pointers with n levels of indirection.
>>
> Exactly. Not exactly a controversial idea, is it?
> Nesting, indirection, and dimensioning are all related to each other.
> And we can visualise three dimensions easily enough, because we live
> in a world with three dimensions of space. To visualise four dimensions,
> you have to add time, which makes it a different sort of mental exercise.
>
> So three is the magic number.

Well, I have some 4d fractals that might interest you.

On 9/27/2023 2:19 PM, Chris M. Thomasson wrote:
> On 9/27/2023 10:46 AM, Malcolm McLean wrote:
>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>>
>>>>>> (Nesting, indirection, and dimensioning are all related to each
>>>>>> other).
>>>>> No, they are not.
>>>>>
>>>> You haven't thought this through, have you?
>>> Yes, I have.
>>>
>>> I mean, obviously if you want to have an n-dimensional array and loop
>>> through it all, you'll have n levels of nesting, and your array access
>>> is technically through pointers with n levels of indirection.
>>>
>> Exactly. Not exactly a controversial idea, is it?
>> Nesting, indirection, and dimensioning are all related to each other.
>> And we can visualise three dimensions easily enough, because we live
>> in a world with three dimensions of space. To visualise four dimensions,
>> you have to add time, which makes it a different sort of mental exercise.

Actually, how can time be a dimension in and of itself, when all
dimensions have time?

3d beings have time, 4d beings have time, ect...

>>
>> So three is the magic number.
>
> Well, I have some 4d fractals that might interest you.

On 2023-09-27, David Brown <david.brown@hesbynett.no> wrote:
> On 26/09/2023 18:40, Kaz Kylheku wrote:
>> Indeed, I myself sometimes writes in a style like the following:
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...) {
>>
>> }
>>
>> The else keyword needs a statement, and the for statement
>> satisfies it. It has braces of its own, so everything is cool.
>
> I would not go that far. "else if" in C is, to me, a short form for
> "elseif" or "elsif" found in other languages. I've never seen an
> "elsefor" or "elsewhile" keyword.
>
> "if, else if, else" chains are common and fit a nice pattern. But a
> "for" loop is completely different, breaking the pattern - I'd have it
> in its own braces :
>
> if (...) {
> ...
> } else {
> for ( ... ) {
> ...
> }
> }

Yes; this is the widely used, familiar way of writing this situation.

I think I grew tired of it at some point.

>> The for (...) header is effectively a statement prefix which indicates
>> iteration of that statement.
>>
>> In my style, I allow the braced statement to be prefixed not only
>> by if (...) but other, similar statement introducers/prefixes
>> like while (...) and switch.
>>
>> I don't think I've ever written a
>>
>> if (this) {
>>
>> } else do {
>>
>> } while(...);
>>
>> But I totally might. :)

I wrote the above unware that I'm lying. In the TXR project, I'm
somewhat astonished to see that an "else do" occurs. What's more,
it dates back to a commit, on Christmas Day, 2011. (Ho, ho, ho!)

https://www.kylheku.com/cgit/txr/commit/?id=894aec019d3ce82f861a5777236ac079c2f2388d

in the function lazy_flatten_scan.

static val lazy_flatten_scan(val list, val *escape)
{ for (;;) {
if (list) {
val a = car(list);
if (nilp(a)) {
list = cdr(list);
} else if (atom(a)) {
return list;
} else do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a));
return list;
} else if (*escape) {
list = pop(escape);
} else {
return nil;
}
}
}

I had no idea I've been doing it that long already, and that
a "do" might have started it.

In that code base there are two cases of "else for", and one "else
switch", which came later. It's far from frequent.

I can't find any instances of

else {
<for|while|switch|do> ...

>> What I wouldn't write is:
>>
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...)
>> body_expression_statement;
>>
>> Or, let alone:
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...)
>> /* empty */;
>>
>
> No, indeed.
>

The reason I wouldn't write that has nothing to do with that last
clause being an iteration statement. It's because of the same old
rule that all parts of the ladder have to be free of braces, or else all
have to have them:

This example is a "go":

if (condition)
simple_statement;
else while (--i)
foo(j++);

If simple_statement becomes a compound, then it's "no go".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 27/09/2023 23:12, Kaz Kylheku wrote:
> On 2023-09-27, David Brown <david.brown@hesbynett.no> wrote:

> https://www.kylheku.com/cgit/txr/commit/?id=894aec019d3ce82f861a5777236ac079c2f2388d
>
> in the function lazy_flatten_scan.
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (list) {
> val a = car(list);
> if (nilp(a)) {
> list = cdr(list);
> } else if (atom(a)) {
> return list;
> } else do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> } else if (*escape) {
> list = pop(escape);
> } else {
> return nil;
> }
> }
> }
>
> I had no idea I've been doing it that long already, and that
> a "do" might have started it.
>
> In that code base there are two cases of "else for", and one "else
> switch", which came later. It's far from frequent.

I don't know why this is remarkable. So, an 'else' branch has a
statement that happens to be a loop or switch statement? I'm sure that
happens all the time whether there's an intervening brace or not!

> I can't find any instances of
>
> else {
> <for|while|switch|do> ...

There are quite a few around. 25 instances in sqlite3 for example, and 5
in Lua sources. I mean, it might be 1 per 5-10K lines, but people do it.
In C, you can find instances of anything.

>>> What I wouldn't write is:
>>>
>>>
>>> if (condition) {
>>> /* loop not needed */
>>> } else for (...)
>>> body_expression_statement;
>>>
>>> Or, let alone:
>>>
>>> if (condition) {
>>> /* loop not needed */
>>> } else for (...)
>>> /* empty */;
>>>
>>
>> No, indeed.
>>
>
> The reason I wouldn't write that has nothing to do with that last
> clause being an iteration statement. It's because of the same old
> rule that all parts of the ladder have to be free of braces, or else all
> have to have them:
>
> This example is a "go":
>
> if (condition)
> simple_statement;
> else while (--i)
> foo(j++);
>
> If simple_statement becomes a compound, then it's "no go".

What about when simple_statement becomes:

if (condition) another_stmt;

Then that 'else' becomes bound to the wrong 'if'.

On 9/27/2023 10:46 AM, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>
>>>>> (Nesting, indirection, and dimensioning are all related to each other).
>>>> No, they are not.
>>>>
>>> You haven't thought this through, have you?
>> Yes, I have.
>>
>> I mean, obviously if you want to have an n-dimensional array and loop
>> through it all, you'll have n levels of nesting, and your array access
>> is technically through pointers with n levels of indirection.
>>
> Exactly. Not exactly a controversial idea, is it?
> Nesting, indirection, and dimensioning are all related to each other.
> And we can visualise three dimensions easily enough, because we live
> in a world with three dimensions of space. To visualise four dimensions,
> you have to add time, which makes it a different sort of mental exercise.
>
> So three is the magic number.

I personally think that time is an interesting form of quantitative
"special", and not a dimension as is simply because time exists in every
dimension. Is that kind of, fair enough?

On 9/27/2023 4:29 PM, Chris M. Thomasson wrote:
> On 9/27/2023 10:46 AM, Malcolm McLean wrote:
>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>>
>>>>>> (Nesting, indirection, and dimensioning are all related to each
>>>>>> other).
>>>>> No, they are not.
>>>>>
>>>> You haven't thought this through, have you?
>>> Yes, I have.
>>>
>>> I mean, obviously if you want to have an n-dimensional array and loop
>>> through it all, you'll have n levels of nesting, and your array access
>>> is technically through pointers with n levels of indirection.
>>>
>> Exactly. Not exactly a controversial idea, is it?
>> Nesting, indirection, and dimensioning are all related to each other.
>> And we can visualise three dimensions easily enough, because we live
>> in a world with three dimensions of space. To visualise four dimensions,
>> you have to add time, which makes it a different sort of mental exercise.
>>
>> So three is the magic number.
>
> I personally think that time is an interesting form of quantitative
> "special", and not a dimension as is simply because time exists in every
> dimension. Is that kind of, fair enough?

For instance, think of a 4d being looking into a 3d realm, and noticing
a clock hanging on a wall. Well, the 4d being can use the clock to sync
itself with the time in the 3d realm of that room that contains the
clock. Is this too out there? Sorry. ;^o

On 9/27/2023 12:19 PM, David Brown wrote:
> On 27/09/2023 20:45, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 27/09/2023 19:46, Malcolm McLean wrote:
>> [...]
>>>> So three is the magic number.
>>>
>>> No.
>>>
>>> Seriously.  Just "no".
>> [...]
>>
>> David, do you think you're going to change his mind?
>>
>
> It seems unlikely, that's true.  I am afraid my tactics may have been
> inspired by watching too much Black Adder.

Watch some mr flibble to attempt to try to cool any overheated jets:

https://youtu.be/9-pnA0orMFU?t=67

;^)

(If anyone wants a break
> from discussing C, look up "Advanced World War I Tactics with General
> Melchett" on youtube.)
>
>> This discussion will end at some point without a resolution.
>> I suggest that now would be a good time for that.
>>
>
> You are almost certainly right.
>

David Brown <david.brown@hesbynett.no> writes:

> On 27/09/2023 20:45, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 27/09/2023 19:46, Malcolm McLean wrote:
>> [...]
>>>> So three is the magic number.
>>>
>>> No.
>>>
>>> Seriously. Just "no".
>> [...]
>> David, do you think you're going to change his mind?
>
> It seems unlikely, that's true.

Also, does it matter? It's not as if a rule has been put forward with
such detail that someone new to C will come across the post and feel
they must alter the way they write code to follow it.

These things wind me up as well, but I just hit 'n' and I am all the
happier for it!

--
Ben.

On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote:
> On 27/09/2023 18:46, Malcolm McLean wrote:
> > On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
> >> On 27/09/2023 17:35, Malcolm McLean wrote:
> >>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
> >>>> On 27/09/2023 12:37, Malcolm McLean wrote:
> >>>>
> >>>>> (Nesting, indirection, and dimensioning are all related to each other).
> >>>> No, they are not.
> >>>>
> >>> You haven't thought this through, have you?
> >> Yes, I have.
> >>
> >> I mean, obviously if you want to have an n-dimensional array and loop
> >> through it all, you'll have n levels of nesting, and your array access
> >> is technically through pointers with n levels of indirection.
> >>
> > Exactly. Not exactly a controversial idea, is it?
> > Nesting, indirection, and dimensioning are all related to each other.
> > And we can visualise three dimensions easily enough, because we live
> > in a world with three dimensions of space. To visualise four dimensions,
> > you have to add time, which makes it a different sort of mental exercise.
> >
> > So three is the magic number.
> I don't think it works. Computer source code is usually 2-dimensional,
> tends to be limited horizontally, but has no particular limits vertically.
>
> The code unit is the 'function', which are not usually that tall, as
> they become unmanageable, and are not that wide either as people don't
> like scrolling sideways. That's why text like this wraps onto the next
> line, but that doesn't work for code which is line- not paragraph-oriented.
>
> When talking about function nesting, my own magic number is 1, and
> standard C doesn't allow more anyway. So people are welcome to limit
> those to three, as I don't care!
>
> But imagine applying the 'rule of three' to:
>
> - The number of lines in a function
>
> - The number of functions in a module
>
> - The number of modules in a program
>
> - The number of fields in a struct
>
> It doesn't work, does it? Or is this more about nesting?
>
> Was there also something about the number of nested parentheses in an
> expression? You don't really need a rule, as it will be obvious when
> there are far too many.
>
If C allowed for nested functions then it would start to become hard for
programmers to understand when the nesting level exceeded three.

But the rule of three doesn't apply to metrics which don't bear a relationship
to dimensions, like the number of lines in a function, or the number of
fields in a struct. Here there may be other psychological limits, but they
arise from different underlying causes.

The rule of three does apply to parentheses. Here you can easily verify
it. Simply write some expressions and note when the nesting starts to
make understanding the expression harder rather than easier.

Nesting has hierarchy whilst dimensions don't. And nesting doesn't have to
be balanced, but nesting which represents a multi-dimensional array
does have to be balanced. So it's related but not exactly the same thing (I
really shouldn't have to make this simple point, however I do). You can't
visualise a four-dimensional structure in your mind, and you can't take
in more than three levels of nesting without consciously matching either.

David Brown <david.brown@hesbynett.no> writes:

> On 27/09/2023 14:32, Bart wrote:
>> On 27/09/2023 10:37, David Brown wrote:
>>
>>> I will even write something like this on occasion :
>>>
>>>      if (<complicated condition>) {
>>>          // Everything is fine, nothing to do
>>>      } else {
>>>          do_something();
>>>      }
>>>
>>> rather than
>>>
>>>      if (!(<complicated condition>)) {
>>>          do_something();
>>>      }
>>>
>>> It is all about what is clearest to read.
>> I have a version of 'if' called 'unless', which sometimes reads better,
>> but not always.
>> In particular, although 'unless' can have an 'else' branch, it doesn't
>> have 'else-unless'; I couldn't work out what it meant!
>
> There are a few different varieties of conditionals that have been tried in
> different programming languages. That includes syntaxes roughly like "x =
> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
> remembered the details correctly. I don't think it really helps to have
> too many ways of doing the same thing - there has to be very clear gains to
> make it worth the effort.

The biggest departure are multi-way ifs like

if C1 -> S1
C2 -> S2
...
fi

I've even come across a language where the while loop had the same
structure with do ... od in place of if .. fi. For example

do a > b -> a :=: b
b > c -> b :=: c
od

where :=: is a swap operator ensures that the values in a, b and c are
in non-decreasing order.

One variation (I think it was used in S-Algol) is to have a case
statement where the arms can have arbitrary expressions. A multi-way
if then looks like this:

case true of
x > 0: return +1
x == 0: return 0
x < 0: return -1
esac

--
Ben.

On 28/09/2023 01:12, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote:
>> On 27/09/2023 18:46, Malcolm McLean wrote:
>>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>>>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>>>
>>>>>>> (Nesting, indirection, and dimensioning are all related to each other).
>>>>>> No, they are not.
>>>>>>
>>>>> You haven't thought this through, have you?
>>>> Yes, I have.
>>>>
>>>> I mean, obviously if you want to have an n-dimensional array and loop
>>>> through it all, you'll have n levels of nesting, and your array access
>>>> is technically through pointers with n levels of indirection.
>>>>
>>> Exactly. Not exactly a controversial idea, is it?
>>> Nesting, indirection, and dimensioning are all related to each other.
>>> And we can visualise three dimensions easily enough, because we live
>>> in a world with three dimensions of space. To visualise four dimensions,
>>> you have to add time, which makes it a different sort of mental exercise.
>>>
>>> So three is the magic number.
>> I don't think it works. Computer source code is usually 2-dimensional,
>> tends to be limited horizontally, but has no particular limits vertically.
>>
>> The code unit is the 'function', which are not usually that tall, as
>> they become unmanageable, and are not that wide either as people don't
>> like scrolling sideways. That's why text like this wraps onto the next
>> line, but that doesn't work for code which is line- not paragraph-oriented.
>>
>> When talking about function nesting, my own magic number is 1, and
>> standard C doesn't allow more anyway. So people are welcome to limit
>> those to three, as I don't care!
>>
>> But imagine applying the 'rule of three' to:
>>
>> - The number of lines in a function
>>
>> - The number of functions in a module
>>
>> - The number of modules in a program
>>
>> - The number of fields in a struct
>>
>> It doesn't work, does it? Or is this more about nesting?
>>
>> Was there also something about the number of nested parentheses in an
>> expression? You don't really need a rule, as it will be obvious when
>> there are far too many.
>>
> If C allowed for nested functions then it would start to become hard for
> programmers to understand when the nesting level exceeded three.
>
> But the rule of three doesn't apply to metrics which don't bear a relationship
> to dimensions, like the number of lines in a function, or the number of
> fields in a struct. Here there may be other psychological limits, but they
> arise from different underlying causes.
>
> The rule of three does apply to parentheses. Here you can easily verify
> it. Simply write some expressions and note when the nesting starts to
> make understanding the expression harder rather than easier.
>
> Nesting has hierarchy whilst dimensions don't. And nesting doesn't have to
> be balanced, but nesting which represents a multi-dimensional array
> does have to be balanced. So it's related but not exactly the same thing (I
> really shouldn't have to make this simple point, however I do). You can't
> visualise a four-dimensional structure in your mind, and you can't take
> in more than three levels of nesting without consciously matching either.

No, 4 spatial dimensions is entirely different because we are only
familiar with 3. (Although could probably cope with projections of 4
into 3.)

But nesting levels are like Russian dolls; we can easily visualise half
dozen.

I've done a quick survey of my own codebase; maximum nesting, not
including functions and modules or any encapsulating type, is 6,
although that's unusual.

It's not a problem, because you don't need to 'get' the whole thing. If
you already have 4 levels, then the code at that 4th level needs:

if a then b else c

that is perfectly clear in that local context. It doesn't need relating
to all the outer levels. And within that new 5th level, you may have an
expression with parentheses; should those be added in too, or considered
separate? If the latter, than that's what happens with statement levels.

(BTW here is that 6-level chunk of a function:

https://github.com/sal55/langs/blob/master/nesting.m)

On 9/27/2023 5:49 PM, Bart wrote:
> On 28/09/2023 01:12, Malcolm McLean wrote:
>> On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote:
>>> On 27/09/2023 18:46, Malcolm McLean wrote:
>>>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote:
>>>>> On 27/09/2023 17:35, Malcolm McLean wrote:
>>>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
>>>>>>> On 27/09/2023 12:37, Malcolm McLean wrote:
>>>>>>>
>>>>>>>> (Nesting, indirection, and dimensioning are all related to each
>>>>>>>> other).
>>>>>>> No, they are not.
>>>>>>>
>>>>>> You haven't thought this through, have you?
>>>>> Yes, I have.
>>>>>
>>>>> I mean, obviously if you want to have an n-dimensional array and loop
>>>>> through it all, you'll have n levels of nesting, and your array access
>>>>> is technically through pointers with n levels of indirection.
>>>>>
>>>> Exactly. Not exactly a controversial idea, is it?
>>>> Nesting, indirection, and dimensioning are all related to each other.
>>>> And we can visualise three dimensions easily enough, because we live
>>>> in a world with three dimensions of space. To visualise four
>>>> dimensions,
>>>> you have to add time, which makes it a different sort of mental
>>>> exercise.
>>>>
>>>> So three is the magic number.
>>> I don't think it works. Computer source code is usually 2-dimensional,
>>> tends to be limited horizontally, but has no particular limits
>>> vertically.
>>>
>>> The code unit is the 'function', which are not usually that tall, as
>>> they become unmanageable, and are not that wide either as people don't
>>> like scrolling sideways. That's why text like this wraps onto the next
>>> line, but that doesn't work for code which is line- not
>>> paragraph-oriented.
>>>
>>> When talking about function nesting, my own magic number is 1, and
>>> standard C doesn't allow more anyway. So people are welcome to limit
>>> those to three, as I don't care!
>>>
>>> But imagine applying the 'rule of three' to:
>>>
>>> - The number of lines in a function
>>>
>>> - The number of functions in a module
>>>
>>> - The number of modules in a program
>>>
>>> - The number of fields in a struct
>>>
>>> It doesn't work, does it? Or is this more about nesting?
>>>
>>> Was there also something about the number of nested parentheses in an
>>> expression? You don't really need a rule, as it will be obvious when
>>> there are far too many.
>>>
>> If C allowed for nested functions then it would start to become hard for
>> programmers to understand when the nesting level exceeded three.
>>
>> But the rule of three doesn't apply to metrics which don't bear a
>> relationship
>> to dimensions, like the number of lines in a function, or the number of
>> fields in a struct. Here there may be other psychological limits, but
>> they
>> arise from different underlying causes.
>>
>> The rule of three does apply to parentheses. Here you can easily verify
>> it. Simply write some expressions and note when the nesting starts to
>> make understanding the expression harder rather than easier.
>>
>> Nesting has hierarchy whilst dimensions don't. And nesting doesn't
>> have to
>> be balanced, but nesting which represents a multi-dimensional array
>> does have to be balanced. So it's related but not exactly the same
>> thing (I
>> really shouldn't have to make this simple point, however I do).  You
>> can't
>> visualise a four-dimensional structure in your mind, and you can't take
>> in more than three levels of nesting without consciously matching either.
>
> No, 4 spatial dimensions is entirely different because we are only
> familiar with 3. (Although could probably cope with projections of 4
> into 3.)
>
> But nesting levels are like Russian dolls; we can easily visualise half
> dozen.[...]
Think of using a 4'th component to be able to see through things. An
alpha channel for a color, for instance.

On 28/09/2023 02:34, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/09/2023 14:32, Bart wrote:
>>> On 27/09/2023 10:37, David Brown wrote:
>>>
>>>> I will even write something like this on occasion :
>>>>
>>>>      if (<complicated condition>) {
>>>>          // Everything is fine, nothing to do
>>>>      } else {
>>>>          do_something();
>>>>      }
>>>>
>>>> rather than
>>>>
>>>>      if (!(<complicated condition>)) {
>>>>          do_something();
>>>>      }
>>>>
>>>> It is all about what is clearest to read.
>>> I have a version of 'if' called 'unless', which sometimes reads better,
>>> but not always.
>>> In particular, although 'unless' can have an 'else' branch, it doesn't
>>> have 'else-unless'; I couldn't work out what it meant!
>>
>> There are a few different varieties of conditionals that have been tried in
>> different programming languages. That includes syntaxes roughly like "x =
>> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
>> remembered the details correctly. I don't think it really helps to have
>> too many ways of doing the same thing - there has to be very clear gains to
>> make it worth the effort.
>
> The biggest departure are multi-way ifs like
>
> if C1 -> S1
> C2 -> S2
> ...
> fi

Yes, especially if the choice is non-deterministic (that is, if the C2
and C3 are both true, then one of S2 or S3 will happen, but you don't
control which). That would probably surprise many programmers of
traditional languages, but I can see it having clear benefits. For
example, an "abs" function could be :

if x >= 0 -> return x;
x <= 0 -> return -x;
fi

Then it's up to the compiler to figure out the most efficient way to
make the code, using either return path in the case x == 0.

I can't think off-hand of a language that supports such overlapping
cases in that way. (Of course compilers can always do things like that
when following the "as if" rule.)

>
> I've even come across a language where the while loop had the same
> structure with do ... od in place of if .. fi. For example
>
> do a > b -> a :=: b
> b > c -> b :=: c
> od
>
> where :=: is a swap operator ensures that the values in a, b and c are
> in non-decreasing order.
>
> One variation (I think it was used in S-Algol) is to have a case
> statement where the arms can have arbitrary expressions. A multi-way
> if then looks like this:
>
> case true of
> x > 0: return +1
> x == 0: return 0
> x < 0: return -1
> esac
>

Is that really much different from :

if (x > 0) return -1;
if (x == 0) return 0;
if (x < 0) return -1;

?

On 28/09/2023 09:08, David Brown wrote:
> On 28/09/2023 02:34, Ben Bacarisse wrote:

>> One variation (I think it was used in S-Algol) is to have a case
>> statement where the arms can have arbitrary expressions.  A multi-way
>> if then looks like this:
>>
>>    case true of
>>      x  > 0: return +1
>>      x == 0: return  0
>>      x  < 0: return -1
>>    esac
>>
>
> Is that really much different from :
>
>     if (x > 0) return -1;
>     if (x == 0) return 0;
>     if (x < 0) return -1;
>
> ?

Yes, it's all encapsulated within one construct. With the separate ifs,
you add arbitrary statements between then, which is likely not possible
with the case.

Also, if you were to have something other then a return for 'x==0', the
case probably wouldn't fall through to the x<0 test, but it will do for
the ifs.

Further (I don't know if that is the case for that language, but it is
for mine), you might be able to write the case version like this:

return case true of
x > 0: +1
x == 0: 0
x < 0: -1
esac

or even leave out the 'return' completely if this is last statement in a
function. With the ifs, only the third 'if' is the last statement.

In short, the case is properly structured. The 'if' version is more like
early Fortran.

On 28/09/2023 01:49, Bart wrote:
> On 28/09/2023 01:12, Malcolm McLean wrote:

>> Nesting has hierarchy whilst dimensions don't. And nesting doesn't
>> have to
>> be balanced, but nesting which represents a multi-dimensional array
>> does have to be balanced. So it's related but not exactly the same
>> thing (I
>> really shouldn't have to make this simple point, however I do).  You
>> can't
>> visualise a four-dimensional structure in your mind, and you can't take
>> in more than three levels of nesting without consciously matching either.

> I've done a quick survey of my own codebase; maximum nesting, not
> including functions and modules or any encapsulating type, is 6,
> although that's unusual.

> (BTW here is that 6-level chunk of a function:
>
> https://github.com/sal55/langs/blob/master/nesting.m)

Looking at line 20 of this extract, there is 'else' followed by 'case'
(and the only statement in that branch) which is a candidate for my
'elsecase' feature. That would reduce nesting and indents by one level
(and removes one block-terminating keyword).

Actually, the C idiom to emulate if-elseif: 'if else if else ...' would
normally involve N nesting levels, except that people ignore that and
use fixed indentation.

But the point is, it's not an extra cognitive load, because the
structure is perceived as flat, not nested.

On 28/09/2023 11:37, Bart wrote:
> On 28/09/2023 09:08, David Brown wrote:
>> On 28/09/2023 02:34, Ben Bacarisse wrote:
>
>>> One variation (I think it was used in S-Algol) is to have a case
>>> statement where the arms can have arbitrary expressions.  A multi-way
>>> if then looks like this:
>>>
>>>    case true of
>>>      x  > 0: return +1
>>>      x == 0: return  0
>>>      x  < 0: return -1
>>>    esac
>>>
>>
>> Is that really much different from :
>>
>>      if (x > 0) return -1;
>>      if (x == 0) return 0;
>>      if (x < 0) return -1;
>>
>> ?
>
> Yes, it's all encapsulated within one construct. With the separate ifs,
> you add arbitrary statements between then, which is likely not possible
> with the case.

That's true. But is there a semantic difference, when there are no
arbitrary statements between them? (I'm a fan of constructs that have
limits on what they allow, so I can see a point in such as "case"
statement even if the meanings are the same.)

>
> Also, if you were to have something other then a return for 'x==0', the
> case probably wouldn't fall through to the x<0 test, but it will do for
> the ifs.

Yes, but that makes no difference in this situation. (It would make a
difference if there were overlaps in the conditionals, or if the
conditionals had side-effects.)

>
> Further (I don't know if that is the case for that language, but it is
> for mine), you might be able to write the case version like this:
>
>     return case true of
>            x  > 0: +1
>            x == 0:  0
>            x  < 0: -1
>            esac
>
> or even leave out the 'return' completely if this is last statement in a
> function. With the ifs, only the third 'if' is the last statement.
>
> In short, the case is properly structured. The 'if' version is more like
> early Fortran.
>