On 28/09/2023 23:38, Anton Shepelev wrote:
> David Brown:
>
>> Wirth's languages tended to have strong separation of data
>> and code. But remember, the focus of his languages were
>> on two things - being good for teaching and learning, and
>> being simple to implement (when optimisation is not
>> important). C does not fit into either category. Nor do
>> other major languages used for "real" programming.
>
> Even so, I think Wirth considered these noble goals as
> /conductive/ to the production use of his languages, rather
> than contrary to it, as do his critics.
>

To be clear - easy to learn and easy to implement are both advantages in
a language. But you can't focus on /everything/. Different languages
have different focuses and tradeoffs, and can be good for different
purposes. So Wirth's languages have been used for some production use,
especially in significantly extended forms (such as Borland's massively
extended Pascal variants). Pascal variants did have significant
popularity for a while, before being replaced by other languages with
tradeoffs more suited to most production environments.

>> (Of course there are "real" programs written in Pascal -
>> but for the most part, you'll see Wirth's languages in
>> academic institutions, not in the software industry).
>
> Free market evaluates things not according to their
> intrinsic value, but always through the ultimate criterium
> of profit, where sponsorship, adverisment, and lobbism play
> an important role -- factors sufficiently suppressed in the
> academia.

There are many factors involved, the "programming language market" is
not remotely a "free market" (few things are), and "profit" is not the
only guiding factor. None of that is particularly relevant, however -
the reality is that Wirth's philosophy and languages played an important
part in the history and development of the software world we know, but
are mostly resigned to that history. The world moved on.

>
>> Also remember that Wirth wrote that (and languages like
>> Pascal) some 40-50 years ago. We've learned a lot since
>> then, and developed better coding techniques over time.
>
> Yes, but very often at the expense of a rapid growth of the
> complexity in the later programming languages, think C++!

Some languages are complex, others are much simpler. Some have big
libraries, some have smaller libraries. Languages and libraries suited
for large tasks are typically big and complex.

>
>> Wirth's most modern language, Oberon, is object oriented -
>> data and code are much more integrated and mixed in such
>> code.
>
> They are, but not so tightly as in typical OOP of our day.
> Instead of complete class inheritance, Wirth introduced two
> simple facilities: extension of record types and the IS
> operator. His methods are still pointers to normal
> procedures and functions exsiting outside record types and
> executed in their natural context, that is without an
> implied `this' or `self' parameter.

The term "object oriented programming" means many different things in
different languages. There are sometimes vast differences between the
object models for languages like Oberon, Smalltalk, Simula, C++, Object
Pascal, Python, Objective-C, and any other language you'd care to think
of. The single uniting concept is that code and data are bound together
in a structured and modular fashion.

>
>> I can see that putting the variables at the start of the
>> function lets you make a list like that. I cannot,
>> however, see any advantage of having such a list.
>
> One reason is that finding the type and annotaition to a
> variable is simplified.

No, it is not - it means you have to look in two places. That is not
simplified. It is unnecessarily split, and unnecessarily complicated.

Anyway, it is the /use/ of a variable or object that is most important,
not its type. The type is primarily important only in the way the
object can and cannot be used. In many cases in C programming, people
can (and do) happily use "int" without any further thought. And in many
languages, including C23, you use type inference to define variables
using whatever type is appropriate for the given initialisation. Some
languages don't have any way to declare a type at all - type inference
is always used.

> With interleaved combined
> declarations and initialisations, one has to scan through
> the entire wall of text backwards, and that the typical
> intialisaion does not /start/ with the variable name only
> aggravates the situation: examining the start of every line
> is not enough.
>
>> Local variables are temporary - they are just there to
>> hold intermediary results and give convenient names to
>> things so that it's easier to see what is going on.
>
> /Just/ is understatement. Their role is very important.

Of course they are important. That does not change what I wrote.

>
>> A list of variables does not aid understanding of a
>> function - rather, it detracts from it because you are
>> splitting the information (how the variable is declared,
>> and how it is used) into two separate parts.
>
> You can see it that way, but the contrary extreme of mixing
> everything into one homogenious mess does not help either.

No one suggested writing a "mess". All I suggest is not having an
artificial split of concepts that naturally hang together.

Splitting up data and code can make sense from an implementation
viewpoint. But when you write code in a high level language (including
C), you are not writing for the ease of the language implementation -
you are writing the best source code you can.

x = (a * b) + (c * d);

and

x1 = (a * b);
x2 = (c * d);
x = x1 + x2;

are two ways of writing the same thing. Assuming "x1" and "x2" are
local variables of appropriate type, used only here, and assuming there
are no side effects in the expressions, then both bits of code have
exactly the same semantics. Why should the second one involve dividing
up declarations into separate parts? Do you really think it "aids
understanding" to write :

int x1;
int x2;
.... more local variables ...

... lots of code ...
x1 = (a * b);
x2 = (c * d);
x = x1 + x2;

rather than:

const int x1 = (a * b);
const int x2 = (c * d);
x = x1 + x2;

?

> Separate declarations introduce some order and make the
> operational code more regular, by having all the assignments
> start with the name of the variable.

Such an order is good when it is helpful. Otherwise it is artificial,
and counter-productive.

Defining local variables only when you need them and have initial values
introduces a /better/ order - things happen when they should happen, not
scattered about.

>
>>> Upon encountering a new variable, the reader can glance
>>> at the top of function to find its type and desctiption,
>>> whereas intermixed style is requires scanning the entire
>>> text, unless, of course, you count IDE helper tools,
>>> which I do not. Code should read smooth off a printed
>>> page.
>>
>> With your style, the reader encountering a new variable
>> has to deal with two wildly separate parts of the text -
>> the definition at the start of the function, and the use
>> of the variable in the code. It is particular bad for
>> large functions or when you have a small screen or window
>> (this can be the case when you are debugging, for
>> example), and you have to scroll around.
>
> I partially disagree. My approach is indeed particularly
> bad for large functions on a small screen, but at the same
> time I find it particulartly good for small functions, and
> quite good for medium ones.

While we can agree that your approach is bad for big functions (and also
that big functions are only rarely a good idea in the first place), it
is /still/ bad for small functions. My approach works fine for big
functions /and/ small functions.

We can agree that hitting yourself on the thumb with a hammer is
particularly bad with a big hammer - that does not mean it's nice to do
it with a small hammer.

>
>> With my style, everything is there clearly in one spot.
>
> Yes -- because of better spacial cohesion. "Everything" is
> an exagerration, however. Variables having different
> lifespans, some may be used from way up above.

Variables most certainly /do/ have different lifespans - and different
scopes, and different "real" lifetimes. When you put them all at the
start of a function, you are maximising their scopes and lifespans, and
giving the biggest possible discrepancy between their language-defined
lifespan (the entire run-time of the function) and their actual
practical lifetime (from their first assignment to their last usage in
the function).

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 29 September 2023 at 02:31:51 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Thursday, 28 September 2023 at 20:47:37 UTC+1, David Brown wrote:
>> >> On 28/09/2023 17:38, Anton Shepelev wrote:
>> >> > Malcolm McLean:
>> >> >
>> >> >> Another psychological rule is that you can take in seven
>> >> >> objects without counting them.
>> >
>> > You can do further experiments to derive more sophisticated rules
>> > than the rule of seven. But it's not "all nonsense".
>> >
>> > Also, remember that I was introducing subitising (the technical term)
>> > newly into a discussion about something else. I wasn't posting about
>> > subitising itself. So a brief summary is adequate.
>> The subitising limit is usually given as four or sometimes five. What
>> is the rule of seven? And do you now have a citation for the "rule of
>> three" in programming? (I say now because you didn't the last time I
>> asked.)
>>
> I haven't published anything on the rule of three.

Of course not. I just asked for a citation.

> Setting up rigorous
> psychological experiments and collecting the results in a way that is
> publishable is quite involved. It's not that case that something has to
> appear in academic literature to be true.

If there are no published studies, just say so.

> If Linus Torvalds and myself independently come to almost the same
> conclusion, then that's good enough to say that we've an idea which
> is worth taking further. (Not it is necessarily correct and no-one may
> disagree, but no one has actually put up any substantive counter-arguments).
>
> The maximum for subitising is generally reckoned to be seven. It does
> depend on circumstances. But under not too contrived circumstances
> people can tell that there are seven objects without actually counting
> them. The limit of four or five is the limit at which it can always be done,
> under any (non-contrived, such as camouflage) circumstances, such
> as objects of diffeent types and sizes, widely scattered, no patterning
> at all and so on.
>
> Wiki claims that people can be trained to subitise up to fifteen.

So the "rule of seven" covers anything from four to fifteen? (Or are
you disputing the papers that claim four of five as the limit?)

I note that you acknowledge that circumstances and training have an
effect. I wonder if the circumstances that pertain to programming
(indentation, layout, operator precedence, common patterns...) as well as
the training to be a programmer (mathematics, syntax, parsing...) might
have an effect on the currently un-evidenced "rule of three".

But really all that's happening here is that you like "rules" and I
don't. To that limited extent, there is an element of postmodernism at
play here.

--
Ben.

David Brown <david.brown@hesbynett.no> writes:
[...]
> (C23 is not out yet, but you can use "#define nullptr (void*) 0" in
> anticipation.)

I think you mean:
#define nullptr ((void*)0)
or even:
#if __STDC_VERSION__ < 202311L
#define nullptr ((void*)0)
#endif

--
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 Friday, 29 September 2023 at 16:52:48 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > Setting up rigorous
> > psychological experiments and collecting the results in a way that is
> > publishable is quite involved. It's not that case that something has to
> > appear in academic literature to be true.
> If there are no published studies, just say so.
>
I just don't know. I'm not a psychologist. I don't really know what to look
for, or whether it's something that someone will definitely have looked
at or something that it's unlikely a psychologist would be very interested in
(unless asked by a person wanting to design a coding standard, if course).
>
> > Wiki claims that people can be trained to subitise up to fifteen.
> So the "rule of seven" covers anything from four to fifteen? (Or are
> you disputing the papers that claim four of five as the limit?)
>
Four or five is the limit when you impose the rule that the person devising
the test can use any non-contrived spatial distribution and selection of
elements to subitise. So you could show a cat and a dog and a mouse and
ask "how many animals?" and the subject would immediately answer "three".
However you couldn't place the mouse halfway in the cat's mouth as though
it were eating it. (I think, I haven't actually done that experiment).

Seven is the limit when you impose the rule that the person devising the test
can't contrive to make the exercise especially easy. As David Brown pointed out,
you can subitise up to twelve if the objects are dots on two dice. That would
be an example of such contrivance. However placing twelve identical dots in
a straight line well within the subject's visual field would not be, but you are
of course trying to make the exercise a bit easier.
>
> I note that you acknowledge that circumstances and training have an
> effect. I wonder if the circumstances that pertain to programming
> (indentation, layout, operator precedence, common patterns...) as well as
> the training to be a programmer (mathematics, syntax, parsing...) might
> have an effect on the currently un-evidenced "rule of three".
>
Yes. That's why I don't impose Torvald's rule of three. I do always lay out my
C curly braces so that they are vertically aligned. Which you wouldnt have to do
if matching were perceptutally easy. The rule of three is for doing what is the
equivalent of subitising for nesting rather than counting. But you don't actually
have to take in a function as a whole to understand it. In a procedural language
like C at least.
>
> But really all that's happening here is that you like "rules" and I
> don't. To that limited extent, there is an element of postmodernism at
> play here.
>
Well I maybe have broader interests than you. My view is that if you wish to
understand the world around you, attempting to devise rules which describe
it is helpful.

Malcolm McLean:

> Seven is the limit when you impose the rule that the
> person devising the test can't contrive to make the
> exercise especially easy. As David Brown pointed out, you
> can subitise up to twelve if the objects are dots on two
> dice. As David Brown pointed out, you can subitise up to
> twelve if the objects are dots on two dice.

I for one certainly do not subitise the dots on dice -- I
add two small numbers, which is very fast.

> However placing twelve identical dots in a straight line
> well within the subject's visual field would not be

Because then you'd really need to subitise to count them
quickly, or be forced to add up twelve unities, or four
three's...

Then again, Miller's "rule of seven" is not about
subitising.

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

On 30/09/2023 03:19, Malcolm McLean wrote:
> On Friday, 29 September 2023 at 16:52:48 UTC+1, Ben Bacarisse wrote:

>> But really all that's happening here is that you like "rules" and I
>> don't. To that limited extent, there is an element of postmodernism at
>> play here.
>>
> Well I maybe have broader interests than you. My view is that if you wish to
> understand the world around you, attempting to devise rules which describe
> it is helpful.

I think perhaps you misunderstand the differences between terms like
"rules", "guidelines", "patterns", "habits", "laws", "indications", and
"preferences".

There is no "rule of three", or "rule of seven". Linus Torvalds does
not have a "rule of three" regarding nesting, braces, indentations, or
anything else. There is no "rule of seven" regarding counting, memory,
subitizing, or anything else.

It's fine to have a /preference/ for no more than three levels of
parenthesis, or a /guideline/ of no more than three levels of
indentation (the Linux coding standard doesn't even go that far).

It's fine to say experiments show that most people can subitize around
4 or 5 objects placed randomly. It is not a law, or a rule, or a
scientific fact - it's a rough value appropriate in some circumstances.
Such results can be helpful to know, but they are not rules.

It is human nature to look for patterns and rules in the world around
us. They help us understanding things, appreciate things, and predict
things. A vital part of this - and the part that you seem to be missing
- is knowing when such patterns apply, and to what extent. "Bricks fall
when you drop them" is a rule, or a law - a scientific fact. "Many
people will have to think hard about code with more than three levels of
nesting" is a pattern or guideline - not a rule, not a law - because it
is very rough and approximate, and varies so much by circumstance.

It is also important to be rational about the patterns you see, and
understand that they are often coincidence. This applies particularly
with small numbers, which turn up a /lot/. Two patterns involving the
same small number does not imply any kind of relation between them.

Try to be more scientific here, and less dogmatic - consider how
accurate a pattern is, how the error distribution looks, what confidence
you can have in the pattern, what circumstances are needed for the
pattern to work or fail. Then we have something that can be useful as a
guideline or recommendation. Don't try to condense it into a religious
pontification of absolutes unless it really is an absolute law.

On 29/09/2023 19:07, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> (C23 is not out yet, but you can use "#define nullptr (void*) 0" in
>> anticipation.)
>
> I think you mean:
> #define nullptr ((void*)0)

Yes, the extra parentheses are a good idea. (I don't think there are
many good uses of "nullptr" where the extra parenthesis would make a
difference, but it could be useful in turning some mistakes into
compile-time errors rather than silent errors.)

> or even:
> #if __STDC_VERSION__ < 202311L
> #define nullptr ((void*)0)
> #endif
>

Sure.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

[.. combining 'else' with 'for' or 'while', etc ..]

> [from some code written in 2011]
>
> 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. [...]

This code is truly horrific.

Ironically, combining 'do' directly with 'else' may be
responsible for a bug in the code.

Anton Shepelev <anton.txt@gmail.moc> writes:

> Kaz Kylheku:
>
>> 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 took this as an exercise in linearising nested if's:
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (!list) {
> if( !*escape ) return nil; /* Ant: no need of else after return */
> /* Ant: henceforth, *escape */
> list = pop( escape );
> continue;
> }
> /* Ant: henceforth, list != NULL */
> val a = car(list);
> /* Ant: henceforth, we have a */
>
> if(nilp(a)) {
> list = cdr(list);
> continue;
> }
> /* Ant: henceforth, !nilp(a) */
>
> if (atom(a)) return list; /* Ant: no need of else after return */
> /* Ant: henceforth, !atom(a) */
>
> do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> }
> }
>
> I deal with conditions step by step, adding invariants as
> execution moves down. I start with the shorter branches, to
> minimise amount of highly indented code, until at the end I
> can write the `do' loop (the most complex branch) without
> any encircling conditionals.

Do you think the revised code does the same thing
as the original?

On 2023-09-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [.. combining 'else' with 'for' or 'while', etc ..]
>
>
>> [from some code written in 2011]
>>
>> 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. [...]
>
> This code is truly horrific.
>
> Ironically, combining 'do' directly with 'else' may be
> responsible for a bug in the code.

Seeing you say there is a problem in that area, I reproduced a
problem on first try. That loop drills into left nesting at the front of
the list: (((...)) ...)

Cases like ((())) do not flatten correctly; the empty list is treated as an
atom, resulting in (nil) which is identical to (()). The correct
result is ().

The do loop takes matters into its own hands, so to speak, and isn't
checking for the case when a is nil.

The following change fixes it:

--- a/lib.c
+++ b/lib.c
@@ -3671,7 +3671,6 @@ static val lazy_flatten_scan(val list, val *escape)
list = a;
a = car(list);
} while (consp(a));
- return list;
} else if (*escape) {
list = pop(escape);
} else {

but that just shows that the loop is not only insufficient (since we have to
rely on the main loop to handle a case after it is done), but unnecessary.

In that else block we can just descend one level the left nesting, push one
level into the escape stack, and continue with the main loop:

--- a/lib.c
+++ b/lib.c
@@ -3666,12 +3666,11 @@ static val lazy_flatten_scan(val list, val *escape)
list = cdr(list);
} else if (atom(a)) {
return list;
- } else do {
+ } else {
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 {

I might also remove the surrounding for (;;) and rely on tail calls.

The root cause of the problem is lack of test coverage, which has to be
addressed first. I wouldn't write anything like this without a ton of tests
today, but some old functions in the project are uncovered.

Thanks for the review; unless you object, I will credit you in
the commit message.

--
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.

Tim Rentsch:

> Anton Shepelev <anton.txt@gmail.moc> writes:
>
> > Kaz Kylheku:
> >
> >> 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 took this as an exercise in linearising nested if's:
> >
> > static val lazy_flatten_scan(val list, val *escape)
> > {
> > for (;;) {
> > if (!list) {
> > if( !*escape ) return nil; /* Ant: no need of else after return */
> > /* Ant: henceforth, *escape */
> > list = pop( escape );
> > continue;
> > }
> > /* Ant: henceforth, list != NULL */
> > val a = car(list);
> > /* Ant: henceforth, we have a */
> >
> > if(nilp(a)) {
> > list = cdr(list);
> > continue;
> > }
> > /* Ant: henceforth, !nilp(a) */
> >
> > if (atom(a)) return list; /* Ant: no need of else after return */
> > /* Ant: henceforth, !atom(a) */
> >
> > do {
> > push(cdr(list), escape); /* safe mutation: *escape is a local var */
> > list = a;
> > a = car(list);
> > } while (consp(a));
> > return list;
> > }
> > }
> >
> > I deal with conditions step by step, adding invariants as
> > execution moves down. I start with the shorter branches, to
> > minimise amount of highly indented code, until at the end I
> > can write the `do' loop (the most complex branch) without
> > any encircling conditionals.
>
> Do you think the revised code does the same thing
> as the original?

I intended it to be, but since the purpose was to show an
approach, I did not actually test my code as that would
require some work of setting up the test environment.

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

On 2023-09-30, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Tim Rentsch:
>> Do you think the revised code does the same thing
>> as the original?
>
> I intended it to be, but since the purpose was to show an
> approach, I did not actually test my code as that would
> require some work of setting up the test environment.

If I plug it into the program and try a few test cases interactively,
I'm not seeing any difference. It doesn't appear that there
are differences in the function that are relevant to its caller.

Under appears to be "bug for bug compatible".

(The original is buggy; I fixed it already and covered it with
test cases, which can't be used for this exercise.)

Buggy original:

1> (flatten* '(a b c))
(a b c)
2> (flatten* '(a (b c)))
(a b c)
3> (flatten* '((a) (b c)))
(a b c)
4> (flatten* '((()) (b c)))
(nil b c)
5> (flatten* '((()) (b ())))
(nil b)
6> (flatten* '((()) (b (()))))
(nil b nil)
7> (flatten* '(a (b (c (d)))))
(a b c d)
8> (flatten* '((((a)))))
(a)

With Anton's lazy_flatten_scan:

1> (flatten* '(a b c))
(a b c)
2> (flatten* '(a (b c)))
(a b c)
3> (flatten* '((a) (b c)))
(a b c)
4> (flatten* '((()) (b c)))
(nil b c)
5> (flatten* '((()) (b ())))
(nil b)
6> (flatten* '((()) (b (()))))
(nil b nil)
7> (flatten* '(a (b (c (d)))))
(a b c d)
8> (flatten* '((((a)))))
(a)

The function is lazy, so it can flatten an infinite list.
E.g. this works in both; regular flatten will hang:

1> (take 2 (flatten* (repeat '(a (b c)))))
(a b)

Naturally, I'm not motivated to thorougly test something I'm not planning to
integrate.

--
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.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> Thanks for the review; unless you object, I will credit you in
> the commit message.

I'd prefer not to have any attribution. I'm glad
my comments helped you track down the problem.

Kaz Kylheku:

> Naturally, I'm not motivated to thorougly test something
> I'm not planning to integrate.

Of course, I only wanted to share it to demonstrate my
approach of flattening deep nesting.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 29 September 2023 at 16:52:48 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > Setting up rigorous
>> > psychological experiments and collecting the results in a way that is
>> > publishable is quite involved. It's not that case that something has to
>> > appear in academic literature to be true.
>> If there are no published studies, just say so.
>>
> I just don't know. I'm not a psychologist.

OK. Without supporting evidence it's just something you (and maybe
other people) like to claim.

>> > Wiki claims that people can be trained to subitise up to fifteen.
>> So the "rule of seven" covers anything from four to fifteen? (Or are
>> you disputing the papers that claim four of five as the limit?)
>>
> Four or five is the limit when you impose the rule that the person
> devising the test can use any non-contrived spatial distribution and
> selection of elements to subitise. So you could show a cat and a dog
> and a mouse and ask "how many animals?" and the subject would
> immediately answer "three". However you couldn't place the mouse
> halfway in the cat's mouth as though it were eating it. (I think, I
> haven't actually done that experiment).
>
> Seven is the limit when you impose the rule that the person devising
> the test can't contrive to make the exercise especially easy. As David
> Brown pointed out, you can subitise up to twelve if the objects are
> dots on two dice. That would be an example of such
> contrivance. However placing twelve identical dots in a straight line
> well within the subject's visual field would not be, but you are of
> course trying to make the exercise a bit easier.

More un-cited supposed facts that just add to my point that there is no
reasonable meaning for the "rule of seven".

>> I note that you acknowledge that circumstances and training have an
>> effect. I wonder if the circumstances that pertain to programming
>> (indentation, layout, operator precedence, common patterns...) as well as
>> the training to be a programmer (mathematics, syntax, parsing...) might
>> have an effect on the currently un-evidenced "rule of three".
>>
> Yes. That's why I don't impose Torvald's rule of three.

Ah, so maybe you could cite that? At least there might be some
explanation from him. I can't find anything, but you must have seen it
somewhere.

> I do always lay out my C curly braces so that they are vertically
> aligned. Which you wouldnt have to do if matching were perceptutally
> easy. The rule of three is for doing what is the equivalent of
> subitising for nesting rather than counting. But you don't actually
> have to take in a function as a whole to understand it. In a
> procedural language like C at least.

So you claim without any evidence. But anyway even you don't follow it.
And there are only limited situations it applies to. Everyone should
note that this is what you mean be a "rule".

>> But really all that's happening here is that you like "rules" and I
>> don't. To that limited extent, there is an element of postmodernism at
>> play here.
>>
> Well I maybe have broader interests than you. My view is that if you wish to
> understand the world around you, attempting to devise rules which describe
> it is helpful.

I admit I can't work them all out for myself so I read books and
published papers by experts who know more than I do. That's why I ask
for citations and references. There is no rule of seven (in perception)
or three (in programming) that helps to describe the world. Most
aspects of the world (people and their actions, in particular) are far
more varied than such banal rules could possibly describe.

--
Ben.

Anton Shepelev <anton.txt@gmail.moc> writes:

[..concerning "the magic number seven plus or minus two" and
other philosophical/psychological musings..]

I encourage you to stay out of these long running, meandering
threads that have wandered far away from the subject of the C
language or programming in C. Besides being untopical, they
aren't going to help you get better at writing programs,
either in C or in any other language. I know it can be fun
to engage in such discussions, but ultimately its a disservice
both to yourself and to the group.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 29 September 2023 at 05:48:22 UTC+1, Tim Rentsch wrote:
>
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> [discussion regarding the so-called "rule of three"]
>>
>>> I haven't published anything on the rule of three. [...]
>>
>> Whatever the merits of your views might be, your comments
>> have essentially zero overlap with the C language. Please
>> take any further discussion of your psychological theories
>> to a forum where they are topical. Thank you.
>
> Most C code is required to be read by humans. So these questions
> like "how many parentheses can I nest?" are highly relevant.
>
> People should maybe spend less time querying the underlying
> pyschology, which is pretty obvious and self-evident, and more
> time on the implications, I agree there.

My objection is not that there was an extended discussion of an
unsupported crackpot psychological theory. My objection is that
these discussions have essentially nothing to do with the C
language or writing C code, except in the most incidental ways.