On 28/08/2023 02:00, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/08/2023 01:44, Ben Bacarisse wrote:
>>> As it happens, I am not with David on this. There are many matters on
>>> which I think an appeal to authority carries significant weight. I
>>> don't know DMR's opinion of underscores (the code in K&R is indicative
>>> but not exactly conclusive), but I would take more time considering it
>>> than I would Kevin's or Barbara's. It's just one way to simplify life.
>>
>> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
>> fallacy - or at least, to Malcolm's use of it or my objection to his
>> use.
>
> I did not refer to any supposed fallacy.
>
>> It's fine to "appeal to authority" as supporting evidence for a claim, and
>> it is absolutely appropriate to view DMR's opinion on C style in higher
>> standing than Kevin's or Barbara's.
>
> That is all I was referring to and all I was commenting on in MM's post.
>
>> But it is fallacious to think of DMR's opinion as being proof that
>> Malcolm's theories are correct - at best, they could be supporting
>> evidence.
>
> Maybe you went further and were suggesting that he was constructing a
> logical argument based on the appeal to authority. If so, I missed
> that. I didn't think he was doing that.
>

I think he has been, in several cases, basing his argument on fallacious
appeals to authority (to paraphrase - "God didn't use inter-word
spacing, so clearly continuous text is always a good thing" and "DMR
never used underscores, so they make identifiers harder to read and
continuous text is more legible").

But you are right (I think) that he was not using it to further an
argument in the particular part of a post that you quoted.

Anyway, I wanted to make it clear that when you wrote "I am not with
David on this", you in fact /are/ with me - because I fully agree that
"There are many matters on which an appeal to authority carries
significant weight". I have only been objecting to Malcolm's appeals to
authority in which they do /not/ carry significant weight, or carry it
contrary to what he has been claiming.

On Monday, 28 August 2023 at 10:24:41 UTC+1, David Brown wrote:
> On 28/08/2023 02:00, Ben Bacarisse wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> On 27/08/2023 01:44, Ben Bacarisse wrote:
> >>> As it happens, I am not with David on this. There are many matters on
> >>> which I think an appeal to authority carries significant weight. I
> >>> don't know DMR's opinion of underscores (the code in K&R is indicative
> >>> but not exactly conclusive), but I would take more time considering it
> >>> than I would Kevin's or Barbara's. It's just one way to simplify life.
> >>
> >> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
> >> fallacy - or at least, to Malcolm's use of it or my objection to his
> >> use.
> >
> > I did not refer to any supposed fallacy.
> >
> >> It's fine to "appeal to authority" as supporting evidence for a claim, and
> >> it is absolutely appropriate to view DMR's opinion on C style in higher
> >> standing than Kevin's or Barbara's.
> >
> > That is all I was referring to and all I was commenting on in MM's post.
> >
> >> But it is fallacious to think of DMR's opinion as being proof that
> >> Malcolm's theories are correct - at best, they could be supporting
> >> evidence.
> >
> > Maybe you went further and were suggesting that he was constructing a
> > logical argument based on the appeal to authority. If so, I missed
> > that. I didn't think he was doing that.
> >
> I think he has been, in several cases, basing his argument on fallacious
> appeals to authority (to paraphrase - "God didn't use inter-word
> spacing, so clearly continuous text is always a good thing" and "DMR
> never used underscores, so they make identifiers harder to read and
> continuous text is more legible").
>
> But you are right (I think) that he was not using it to further an
> argument in the particular part of a post that you quoted.
>
The claim was that "The only thing /wrong/ - and pretty much everyone
thinks it is wrong - would be to call it "multiplymatrixwithvector".

So of course to refute this you have to provide a few counter-examples.
Now it's not committing the fallacy of arguing from authority to choose
counter-examples who are familiar, well-respected figures rather than
those who wouldn't be familiar to most readers.
>
> Anyway, I wanted to make it clear that when you wrote "I am not with
> David on this", you in fact /are/ with me - because I fully agree that
> "There are many matters on which an appeal to authority carries
> significant weight". I have only been objecting to Malcolm's appeals to
> authority in which they do /not/ carry significant weight, or carry it
> contrary to what he has been claiming.
>
Reality is that even sophisticated thinkers use appeals to authority all the
time. For instance I quite frequently point out to scientists that peer review
is an appeal to authority. Some of them get it. But a lot don't. These are highly
educated, highly intelligent people who work in universities alongside
professional philosophers, but they can't understand that they are making a
basic logical error.
There are two reasons. The first is that as a heuristic, authority is usually
right, people who are not recognised authorities and dissent from the accepted
consensus are usually wrong. The second reason is that when the fallacy is
explained, the person doing the explaining doesn't really understand it
himself, and does a a bad job. So he gives an example of where the authority
isn't really an authority, and is in the wrong. "Homeopathy must be right
because ing Charles believes in it".

Ritchie is a real authority, probably the world's most capable person, at
designing programming languages. But nothing he said is correct,
because Denis Ritchie said it. It's correct because the arguments he used
hold water.

On 28/08/2023 11:03, Malcolm McLean wrote:
> On Monday, 28 August 2023 at 09:40:00 UTC+1, David Brown wrote:
>> On 28/08/2023 09:42, Malcolm McLean wrote:
>>
>>> People work out complex
>>> and rather tendentious theories about why the ancients used Scriptio Continua
>>> and moderns use text separated by spaces.
>>>
>> Yes - people that are a lot smarter and more knowledgable than you, and
>> that don't have some bizarre agenda to try to "prove" that their unique
>> and illegible naming style is somehow better than what everyone else uses.
>>
>>> You need to understand the strength of the simple, obvious argument, before you
>>> try to snipe at it with sophisticated objections.
>>>
>>
> A simple, straightforwards, obvious and natural point takes priority.

Do you agree that word break indication makes text easier to read?

You agree therefore that continuous text is harder to read?

You understand that word breaks were used from very early times in some
texts?

You understand therefore that continuous text was used despite more
legible alternatives being available, and that in at least some cases,
it is reasonable to suppose the writer was familiar with alternatives
and could see that it was easier to read?

This means that in at least some cases, the use of continuous text was
motivated by factors that outweighed legibility - perhaps costs, perhaps
intentionally making the text harder to read.

I don't actually expect you to answer these questions - I expect more
strawmen, more fallacious appeals to authority, more rambling stories,
and no actual relevant points. But you might surprise me.

> Scriptio Continua
> was used for 2000 years (first texts about 700 BC or so, the last texts 13th century
> - I make that about 2000 years).

Older Greek was written with spaces, and a variety of dots was also
used. Scriptio Continua was fairly common (but very far from universal)
in Greek from perhaps about 400 BC, and Latin from around 100 BC to
maybe 700 AD. It existed outside that range, but was a minor style -
you don't get to write something now in Scriptio Continua and claim it
is still in use in the 21st century.

So around 1000 years is closer than 2000 years. If you want to say 1200
years, I'll not argue.

> So if it was difficut to read, would it have been
> used for so long? Obviously not.

It /was/ (and is) difficult to read - it was used despite that. People
do odd things all the time, and strange habits become popular for all
sorts of reasons - despite common sense.

> People would have used dots or vertical lines,
> both of which were used in very early Latin and Greek texts, and occasionally appear
> in later manuscripts, but weren't very popular.
>
> You have to learn how to draw conclusions from the information, not to trawl through
> material looking for reasons to object to the obvious, because you are naturally
> contentious in character.

I have looked at the information - including what experts (not me, not
you) have said on the matter. Two things are clear from the experts -
continuous script was far from the universal norm, and that nobody is
sure why it existed at all because everyone agrees it is significantly
more difficult to read than when there are word breaks.

It is a truly foolish viewpoint to think "people do/did this a lot,
therefore it must be a good idea".

I would suggest that /you/ have been drawing unwarranted conclusions
from your data - despite cherry-picking your examples and authorities in
an attempt to shore up your unique viewpoints.

The only thing you can conclude from people writing without word breaks
is that it was not /so/ hard to read that it could not be used, and that
other considerations then outweighed ease of reading.

>>
>>> M.B. Parkes was my teacher at Oxford by the way. He taught me this stuff.
>>
>> Appeal to authority again? Except this time you have picked an
>> "authority" that is meaningless to your audience, and who would probably
>> be horrified to hear what a jumbled mess you have made of his teachings,
>> and how you misuse your misunderstandings to justify bad coding (based
>> on the Wikipedia article and references).
>>
> Not really. When your old tutor's works come up, it's natural to mention that
> he was your tutor.

What you consider "natural" is often at odds with what other people
consider natural. But again, you are missing the point.

On 28/08/2023 12:29, Malcolm McLean wrote:
> On Monday, 28 August 2023 at 10:24:41 UTC+1, David Brown wrote:
>> On 28/08/2023 02:00, Ben Bacarisse wrote:
>>> David Brown <david...@hesbynett.no> writes:
>>>
>>>> On 27/08/2023 01:44, Ben Bacarisse wrote:
>>>>> As it happens, I am not with David on this. There are many matters on
>>>>> which I think an appeal to authority carries significant weight. I
>>>>> don't know DMR's opinion of underscores (the code in K&R is indicative
>>>>> but not exactly conclusive), but I would take more time considering it
>>>>> than I would Kevin's or Barbara's. It's just one way to simplify life.
>>>>
>>>> Ah, now it is /your/ turn to misunderstand the "appeal to authority"
>>>> fallacy - or at least, to Malcolm's use of it or my objection to his
>>>> use.
>>>
>>> I did not refer to any supposed fallacy.
>>>
>>>> It's fine to "appeal to authority" as supporting evidence for a claim, and
>>>> it is absolutely appropriate to view DMR's opinion on C style in higher
>>>> standing than Kevin's or Barbara's.
>>>
>>> That is all I was referring to and all I was commenting on in MM's post.
>>>
>>>> But it is fallacious to think of DMR's opinion as being proof that
>>>> Malcolm's theories are correct - at best, they could be supporting
>>>> evidence.
>>>
>>> Maybe you went further and were suggesting that he was constructing a
>>> logical argument based on the appeal to authority. If so, I missed
>>> that. I didn't think he was doing that.
>>>
>> I think he has been, in several cases, basing his argument on fallacious
>> appeals to authority (to paraphrase - "God didn't use inter-word
>> spacing, so clearly continuous text is always a good thing" and "DMR
>> never used underscores, so they make identifiers harder to read and
>> continuous text is more legible").
>>
>> But you are right (I think) that he was not using it to further an
>> argument in the particular part of a post that you quoted.
>>
> The claim was that "The only thing /wrong/ - and pretty much everyone
> thinks it is wrong - would be to call it "multiplymatrixwithvector".
>
> So of course to refute this you have to provide a few counter-examples.
> Now it's not committing the fallacy of arguing from authority to choose
> counter-examples who are familiar, well-respected figures rather than
> those who wouldn't be familiar to most readers.

If DMR had supported your viewpoint, it would have been reasonable to
show his opinion as a valid appeal to authority. But he did not support
it (as far as I know, and as far as has been shown so far) - thus
claiming he did is fallacious. Had you should code that he had written
using names such as "multiplymatrixwithvector", then you would have had
a point.

>>
>> Anyway, I wanted to make it clear that when you wrote "I am not with
>> David on this", you in fact /are/ with me - because I fully agree that
>> "There are many matters on which an appeal to authority carries
>> significant weight". I have only been objecting to Malcolm's appeals to
>> authority in which they do /not/ carry significant weight, or carry it
>> contrary to what he has been claiming.
>>
> Reality is that even sophisticated thinkers use appeals to authority all the
> time.

So now we can add "whataboutism" to your list. It's another popular
fallacy.

> For instance I quite frequently point out to scientists that peer review
> is an appeal to authority.

No, it is not - or at least, it is not /fallacious/ appeals to authority.

> Some of them get it. But a lot don't. These are highly
> educated, highly intelligent people who work in universities alongside
> professional philosophers, but they can't understand that they are making a
> basic logical error.

Peer review - done properly - is not a "basic logical error".

> There are two reasons. The first is that as a heuristic, authority is usually
> right, people who are not recognised authorities and dissent from the accepted
> consensus are usually wrong.

That is correct. (Getting expert opinion from qualified and
knowledgable authorities is not an "appeal to authority" fallacy.)

> The second reason is that when the fallacy is
> explained, the person doing the explaining doesn't really understand it
> himself, and does a a bad job. So he gives an example of where the authority
> isn't really an authority, and is in the wrong. "Homeopathy must be right
> because ing Charles believes in it".

That last example is a good example of an appeal to authority fallacy.
It is completely different from scientific peer review. So if a
scientist does not agree with you when you claim they are the same, then
that's good.

>
> Ritchie is a real authority, probably the world's most capable person, at
> designing programming languages.

He is a real authority on C. There's no doubt that he was capable of
good programming language design. But it is completely unjustified to
suggest he was "probably the world's most capable". There is no world
cup for programming language design. There are no rankings, or scoring
systems.

> But nothing he said is correct,
> because Denis Ritchie said it. It's correct because the arguments he used
> hold water.

Sure. But he did not say long identifiers are best without word breaks,
or that underscores are bad, or that "const" is a terrible idea, or that
"size_t" is horrible. He used underscores in long identifiers, he
supported "const" (with different wording in the C standard than the
original proposal), he created "size_t".

So if /I/ were to write "Dennis Ritchie is arguably one of the most
important original authorities on C, and he supports my points" it would
be a valid appeal to authority. When /you/ write that he supports
/your/ ideas, it is a fallacy because - regardless of whether Ritchie's
thoughts here were right or wrong - he did not support your position.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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

[named function arguments]

>> The only way this can be sanely introduced into C with backward
>> compatibility is if there is a separate way to introduce the
>> parameter names used for named calling, like this:
>>
>> char *strcpy(const char * : dest, char * : src);
>
> Why not just declare
> char *strcpy(const char *dest, char *src);
> and use those names in calls, with a few simple rules for when there's
> more than one visible declaration?

Amusing that both of thesse declarations get the qualifiers
wrong.

I favor a different approach to this problem:

static inline char *
copy_to_from( char *to, const char *from ){
return strcpy( to, from );
}

with no language changes needed. And people are still free to
use the more concise form if they so desire.

David Brown <david.brown@hesbynett.no> writes:
>On 27/08/2023 12:05, Malcolm McLean wrote:

<discussion regarding use of underscore characters in identifiers>
>
>But /I/ said something to that effect. And since there are undoubtedly
>three classes here (lots of people have put themselves in the "like"
>group, you and Bart are in the "horrible" group, while Scott has, I
>think, placed himself in the "don't care" group), then there is no doubt
>that your question was a false dichotomy.

Yes, "don't care" is an accurate summation of my position. It's a legal
character in identifiers - there is no intrinsic goodness or badness to it.

That said, I will use it in preference to CamelCase, which I dislike
primarily because of the impact on my typing speed.

David Brown <david.brown@hesbynett.no> writes:
>On 28/08/2023 09:32, Malcolm McLean wrote:
>> On Sunday, 27 August 2023 at 19:34:14 UTC+1, Kalevi Kolttonen wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>> No. Denis Ritchie didn't like const. But to say "const is a bad idea because
>>>> Denis Ritchie didn't support it" is fallacious, though obvioulsy Denis Ritchie
>>>> almost certainly knows what he is talking about, and obvioulsy the committee
>>>> has shown their inferiority inm many other ways. But you have to look at the
>>>> arguments Ritchie used, not just say "Ritchie says so, so it is".
>>> I am sorry, I am a bit lazy today and cannot be bothered to do web
>>> searches. What exactly are Ritchie's arguments against "const"?
>>>
>>> I cannot think of any, but I have heard some that lend support
>>> to having, and properly using, "const".
>>>
>> He write them in a leter tot he committee many years ago.
>> I believe there was also apost to this newsgroup.

"By way of introduction, the important thing about 'const' is that the
current wording says, in section 3.3.4, that a pointer to a const-qualified
object may be cast to a pointer to the plain object, but "If an attempt is
made to modify the pointed-to object by means of the converted pointer,
the behavior is undefined." Because function prototypes tend to convert
your pointers to const-qualified pointers, difficulties arise.In discussion
with various X3J11 members, I learned that this section is now regarded as an
inadvertant error, and no one thinks that it will last in its current form.

Nevertheless, it seemed wisest to keep my comments in their original strong
form. The intentions of the committee are irrelevant; only their document matters.

https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-analysis-in-the-c-programming-language-1988/

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 27/08/2023 07:54, Malcolm McLean wrote:
>> On Saturday, 26 August 2023 at 15:10:54 UTC+1, Scott Lurndal wrote:
>...
>>> The sources I found indicate that it wasn't intended to be read by anyone
>>> other than the person who wrote it.
>>>
>> Just goes to show that you can believe everything you read.
>> Do you think that is remotely plausible?
>
>The Wikipedia article on Scriptio Continua gives precisely that
>explanation. That explanation is bracketed by two citations - it's not
>clear which of the two is most relevant:
>
>
>Moore, F. C. T. (2001). "Scribes and Texts: A Test Case for Models of
>Cultural Transmission". The Monist. 84 (3): 421.
>doi:10.5840/monist200184325. JSTOR 27903738. Retrieved March 24, 2023.
>
>Parkes, M. B. "Antiquity: Aids for Inexperienced Readers and the
>Prehistory of Punctuation". Pause and Effect: An Introduction to the
>History of Punctuation in the West. Berkeley: U of California, 1993. 10–11.
>
>I would not recommend dismissing that thesis out of hand without first
>following up on those citations and learning what reasons they give for
>believing it to be true.

And the undercurrent of my post was the implication that if Malcolm
doesn't care about other people reading his code, he's free to use
'scriptio continua' as his guide for identifier naming.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>[...]
>> If required, positional parameters are going to be callable using named
>> arguments, the named arguments must be a mandatory part of the function
>> definition.
>
>Named arguments are already mandatory for function definitions (barring
>old-style definitions).

Nit, IIRC, you don't need the name if you don't use the parameter.

On 28/08/2023 15:15, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> [...]
>>> If required, positional parameters are going to be callable using named
>>> arguments, the named arguments must be a mandatory part of the function
>>> definition.
>>
>> Named arguments are already mandatory for function definitions (barring
>> old-style definitions).
>
> Nit, IIRC, you don't need the name if you don't use the parameter.
>

This program:

void F(int,int,int) {}

int main(void) {}

generally results in hard errors in I think 5 out of 6 compilers I
tried. Only gcc on Windows passed it with no comment.

On Monday, 28 August 2023 at 13:01:19 UTC+1, David Brown wrote:
>
> So if /I/ were to write "Dennis Ritchie is arguably one of the most
> important original authorities on C, and he supports my points" it would
> be a valid appeal to authority. When /you/ write that he supports
> /your/ ideas, it is a fallacy because - regardless of whether Ritchie's
> thoughts here were right or wrong - he did not support your position.
>
No. You just haven't got it.
The appeal to authority fallacy says "proposition X must be true,
_because_ such and such supports it".
It doesn't matter if such and such is Dennis Ritchie or David Brown.
Or if the person genuinely supports proposition X or not.
Or if the claim is highly controversial or something few people
would disagree with.
The appeal to authority fallacy is the fallacy that a statement is true
because of the identity of the person making it.

On 2023-08-28, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Scriptio Continua was used for about 2,000 years. So it's not difficult to read.

Say, what proportion of the populade was literate over that period?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-28, David Brown <david.brown@hesbynett.no> wrote:
> On 28/08/2023 11:03, Malcolm McLean wrote:
>> On Monday, 28 August 2023 at 09:40:00 UTC+1, David Brown wrote:
>>> On 28/08/2023 09:42, Malcolm McLean wrote:
>>>
>>>> People work out complex
>>>> and rather tendentious theories about why the ancients used Scriptio Continua
>>>> and moderns use text separated by spaces.
>>>>
>>> Yes - people that are a lot smarter and more knowledgable than you, and
>>> that don't have some bizarre agenda to try to "prove" that their unique
>>> and illegible naming style is somehow better than what everyone else uses.
>>>
>>>> You need to understand the strength of the simple, obvious argument, before you
>>>> try to snipe at it with sophisticated objections.
>>>>
>>>
>> A simple, straightforwards, obvious and natural point takes priority.
>
> Do you agree that word break indication makes text easier to read?

The Japanese do. Books for small children have word breaks.

In reading grownup Japanese, there are situations in which you have to
hypothesize one of two or possibly more word boundaries to see which way
it makes sense, based on your vocabulary. It doesn't help that Japanese
has a large number of homonyms and situations in which words are
fragments of unrelated words. Kanji helps in this regard; Japanese
written out in kana with no spaces is more brutal.

In the history of Fortran, the most idiotic thing was removing spaces
before tokenizing it, resulting in the "famous" fact that
DOI=1,10 must be parsed as the DO I = 1, 10 head of a loop.

> This means that in at least some cases, the use of continuous text was
> motivated by factors that outweighed legibility - perhaps costs, perhaps
> intentionally making the text harder to read.

Like, maybe, keeping the illiterate rabble illiterate, maintaining the
status quo that only a tiny elite can read and write?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 28/08/2023 16:53, Bart wrote:
> On 28/08/2023 15:15, Scott Lurndal wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> [...]
>>>> If required, positional parameters are going to be callable using named
>>>> arguments, the named arguments must be a mandatory part of the function
>>>> definition.
>>>
>>> Named arguments are already mandatory for function definitions (barring
>>> old-style definitions).
>>
>> Nit, IIRC, you don't need the name if you don't use the parameter.

That's true in C++, but not true in C until C2x comes out.

>>
>
> This program:
>
>    void F(int,int,int) {}
>
>    int main(void) {}
>
> generally results in hard errors in I think 5 out of 6 compilers I
> tried. Only gcc on Windows passed it with no comment.

As you know, gcc does not try to be accurately conforming to the
standards unless you give it appropriate command line flags. In
particular, it tends to be lax in accepting some syntax from later C
standards (and occasionally C++), as long as there is no conflict with
valid code of the specified (or default) standard. So gcc accepts this
because C2x will allow it, or because C++ allows it, and it is a simple
and obvious extension.

If you don't like that, you know what flags to give gcc to get the
standards-required diagnostic. (The standards do not require a "hard
error". For some kinds of mistakes in code, I would agree with you that
a hard error would be far better than a warning or silently accepting
the code by default - but in this case, a hard error is an overreaction
unless you want to enforce very strict checking.)

On 28/08/2023 17:41, David Brown wrote:
> On 28/08/2023 16:53, Bart wrote:
>> On 28/08/2023 15:15, Scott Lurndal wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>> [...]
>>>>> If required, positional parameters are going to be callable using
>>>>> named
>>>>> arguments, the named arguments must be a mandatory part of the
>>>>> function
>>>>> definition.
>>>>
>>>> Named arguments are already mandatory for function definitions (barring
>>>> old-style definitions).
>>>
>>> Nit, IIRC, you don't need the name if you don't use the parameter.
>
> That's true in C++, but not true in C until C2x comes out.

Why is the standard moving backwards?

>
>>>
>>
>> This program:
>>
>>     void F(int,int,int) {}
>>
>>     int main(void) {}
>>
>> generally results in hard errors in I think 5 out of 6 compilers I
>> tried. Only gcc on Windows passed it with no comment.
>
> As you know, gcc does not try to be accurately conforming to the
> standards unless you give it appropriate command line flags.

'gcc c.c' on Windows (13.2.0) passed it; 'gcc c.c' on WSL (9.4.0)
failed it.

I've given up trying to make sense of gcc's behaviour. WHATEVER it does
or doesn't do, even when it contradicts itself, people will always find
an excuse for it.

But this one is unusual: normally newer gcc tries to continue passing
legacy code that older versions passed. Now, it can be passing code that
older versions *failed*.

gcc appears to be doing a passing (no pun) imitation of Trump: no matter
what crazy stuff it does, people like it all the more!

It will please people when it does X instead of Y, and please those who
want it to do Y when it does Y instead of X, and it will please those
who like the 'flexibility' of it being able to either X or Y.

Any complaints about the behaviour, Oh, you can just add these
half-dozen obscure options to give the correct behaviour, which of
course you already knew about in advance, to join the other 200 weird
behaviours.

The fact that you're then dividing C into two languages: C which allows
parameter names to be omitted from definitions, and C which doesn't, is
of no consequences. So you end up define one of 2**N dialects where N is
the number of behaviour-altering options. What language are you
programming in, again?

> If you don't like that, you know what flags to give gcc to get the
> standards-required diagnostic.

As I said...

>  (The standards do not require a "hard
> error".  For some kinds of mistakes in code, I would agree with you that
> a hard error would be far better than a warning or silently accepting
> the code by default - but in this case, a hard error is an overreaction
> unless you want to enforce very strict checking.)

In this case, the rule can very simple: each parameter name in a
definiton MUST be named.

(Accidentally delete a parameter name 'abc', and it's possible that a
reference to that parameter in the function now matches a global 'abc'.)

On Monday, 28 August 2023 at 17:21:58 UTC+1, Kaz Kylheku wrote:
> On 2023-08-28, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > Scriptio Continua was used for about 2,000 years. So it's not difficult to read.
> Say, what proportion of the populade was literate over that period?
>
Very low. Which is probably part of the reason. Most people either couldn't read
and write at all, or were professionals whose job it was to work with books.

When in the late Middle Ages knights and merchants and similar people began
to become literate, but were occasional readers and writers rather than doing it
full time, then it would have been more important that text was easy to read.

But the point I was making was that whilst professional readers might have
tolerated a bit of extra difficulty, they wouldn't have tolerated text which was
very difficult to read, for a period of 2000 years.

On Monday, 28 August 2023 at 17:36:03 UTC+1, Kaz Kylheku wrote:
>
> > This means that in at least some cases, the use of continuous text was
> > motivated by factors that outweighed legibility - perhaps costs, perhaps
> > intentionally making the text harder to read.
> Like, maybe, keeping the illiterate rabble illiterate, maintaining the
> status quo that only a tiny elite can read and write?
>
Very implausible. It takes non-trivial education to teach people to.read and write,
even with modern printed texts with spacing. Illiteracy rates are a scandal.

The motive to raise the barrier even higher would have been very low. You
just don't provide schools for the rabble, if you wish to keep them illiterate.

On 28/08/2023 18:35, Kaz Kylheku wrote:
> On 2023-08-28, David Brown <david.brown@hesbynett.no> wrote:

>> This means that in at least some cases, the use of continuous text was
>> motivated by factors that outweighed legibility - perhaps costs, perhaps
>> intentionally making the text harder to read.
>
> Like, maybe, keeping the illiterate rabble illiterate, maintaining the
> status quo that only a tiny elite can read and write?
>

Yes. Writing without spaces isn't much harder than writing with spaces,
but reading it is a lot harder. As a member of the elite, you don't
want reading to be easier for others.

Even within the elite classes, your ability to read unspaced texts
quickly (or, more often, your ability to afford a scribe who could read
it) was a status symbol. It was like serving larks' tongues at dinner -
you don't do it because they are tasty or nutritious, you do it because
they are expensive.

I don't think anyone can say how much of an influence such reasons were,
but it is certainly one of several reasons given by historians.

On 28/08/2023 19:01, Bart wrote:
> On 28/08/2023 17:41, David Brown wrote:
>> On 28/08/2023 16:53, Bart wrote:
>>> On 28/08/2023 15:15, Scott Lurndal wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>> [...]
>>>>>> If required, positional parameters are going to be callable using
>>>>>> named
>>>>>> arguments, the named arguments must be a mandatory part of the
>>>>>> function
>>>>>> definition.
>>>>>
>>>>> Named arguments are already mandatory for function definitions
>>>>> (barring
>>>>> old-style definitions).
>>>>
>>>> Nit, IIRC, you don't need the name if you don't use the parameter.
>>
>> That's true in C++, but not true in C until C2x comes out.
>
> Why is the standard moving backwards?

What do you mean?

C2x allows you to omit names for parameters you don't use in a function
definition. How is that "moving backwards" ? You still need the proper
prototype, and you still need to include the arguments when calling the
function.

It is not uncommon to have compiler warnings on unused variables and
parameters - if a function takes a parameter, and the definition does
not use it somehow, then it's likely there's a mistake somewhere. But
that is not always the case, so such warnings have relatively high false
positive rates, and then you have to have explicit indication that the
parameter is intentionally unused. That's not a bad idea from the point
of view of documenting what the code is doing, but an alternative option
in C++, and now in C2x, is to simply omit a name for the parameter.
(Whether you like that or not is a matter of opinion, and you can use
the feature or ignore it.)

>
>
>>
>>>>
>>>
>>> This program:
>>>
>>>     void F(int,int,int) {}
>>>
>>>     int main(void) {}
>>>
>>> generally results in hard errors in I think 5 out of 6 compilers I
>>> tried. Only gcc on Windows passed it with no comment.
>>
>> As you know, gcc does not try to be accurately conforming to the
>> standards unless you give it appropriate command line flags.
>
>  'gcc c.c' on Windows (13.2.0) passed it; 'gcc c.c' on WSL (9.4.0)
> failed it.

That does not surprise me. Newer gcc has support for some parts of C2x,
older gcc does not.

>
> I've given up trying to make sense of gcc's behaviour. WHATEVER it does
> or doesn't do, even when it contradicts itself, people will always find
> an excuse for it.

OK. Maybe I should stop trying to explain it to you? (Note that
explaining why gcc does something is not the same thing as making an
excuse for it, or liking it. I personally would prefer if it followed
the standards more strictly by default.)

>
> But this one is unusual: normally newer gcc tries to continue passing
> legacy code that older versions passed. Now, it can be passing code that
> older versions *failed*.

And the problem with that is... what? Nothing, as far as I can see.

It can be a problem if old code used to work with older gcc and fails to
work with newer gcc. But it's not a problem if something works on newer
gcc and fails on older gcc - that's entirely natural with new versions
of tools.

>
>> If you don't like that, you know what flags to give gcc to get the
>> standards-required diagnostic.
>
> As I said...

You didn't say anything related to that.

>
>>   (The standards do not require a "hard error".  For some kinds of
>> mistakes in code, I would agree with you that a hard error would be
>> far better than a warning or silently accepting the code by default -
>> but in this case, a hard error is an overreaction unless you want to
>> enforce very strict checking.)
>
> In this case, the rule can very simple: each parameter name in a
> definiton MUST be named.

That's certainly a simple rule.

But is it a useful rule? I can't see it being particularly important.

If anything, I'd prefer a rule saying parameter names were necessary in
declarations - that's the bit seen by people using the function.
Parameter names for unused parameters in a function definition add very
little to the code.

>
> (Accidentally delete a parameter name 'abc', and it's possible that a
> reference to that parameter in the function now matches a global 'abc'.)
>

That's a conceivable reason, yes. But is it likely? You'd have to
accidentally delete a bit of your code - accidentally deleting bits of
your code can always have adverse effects, no matter what. That's why
we have keyboard shortcuts for saving files often, undo features for
when you've made such a mistake, and "commit often" policies for source
code control. And how often do your parameter names shadow global
identifiers? Rarely, I would say, in well-written code (though it
certainly /can/ happen). And of course the shadowed identifier would
have to be of an appropriate type.

Note that C++ has had this feature for decades - I've never heard anyone
complain about it. (And people complain about C++ a /lot/.)

I think there are many things that are more likely to be errors in code.

(And I am confident that there are other things in C2x that you will
dislike far more than this. C2x has so many new features that I think
you'll be hard pushed to find someone who likes them all.)

On 28/08/2023 19:01, David Brown wrote:
> On 28/08/2023 19:01, Bart wrote:

>> Why is the standard moving backwards?
>
> What do you mean?
>
> C2x allows you to omit names for parameters you don't use in a function
> definition.  How is that "moving backwards" ?

We want a stricter language moving forward and less of the crazy
flexibility of older versions.

What other missing bits of syntax can we assign some arbitrary meaning
to rather than being called out as obvious errors?

How about, leaving out a function name in a definition, when that
function is not called?

>> But this one is unusual: normally newer gcc tries to continue passing
>> legacy code that older versions passed. Now, it can be passing code
>> that older versions *failed*.
>
> And the problem with that is... what?  Nothing, as far as I can see.

It was an error before for a good reason. Now somebody decided you need
to take away some redundancy so that they can declare unused parameters
without the compiler moaning about it.

So that actual errors, like accidentally missing out a name, are harder
to detect.

There are also lots of reasons for a parameter name not to be used in
some compilations out of dozens or hundreds:

Maybe you've only got as far as writing a skeleton function and not all
params are yet use, or in the middle of writing it, or it's being
changed, or parts are temporarily commented out. It's a WIP!

Yet an overzealous compiler might warn about an unused parameter name.
There must be better ways of shutting it up than deleting the name
completely. So, what was it again, when you decide to use it?

What about declarations? It would be perverse for those to define a name
for a parameter which is not named nor used in the definition (what
would it be called?).

The whole thing has a very bad smell to me.

Using Godbolt, I can see that gcc up to 11.1 failed missing parameter
names. From 11.1 onward, such code passes.

On C, code fails on older versions, and gives warnings from 11.0.0 onwards.

In MSVC, code fails on all versions. So:

Older Newer/current

GCC Fail Pass
Clang Fail Warning
MSVC Fail Fail

bcc --- Fail
tcc --- Fail

Nice to see consistency in a language! All those languages in the final
column are still C. I think.

Of course, a really useful enhancement such as declaring multiple
parameter names under the same shared type doesn't get a look-in:

void F(int a, b, c) {}

> But is it a useful rule?  I can't see it being particularly important.
>
> If anything, I'd prefer a rule saying parameter names were necessary in
> declarations - that's the bit seen by people using the function.
> Parameter names for unused parameters in a function definition add very
> little to the code.

Which, of course, is totally backwards. Most things in this newsgroup are!

Parameter names in declarations are optional: you can take them all out,
and programs would still compile.

Not so with parameter names in definitions.

Actually, I've never across missing parameter names in definitions in
the million lines of code I've passed through my C compiler. Or maybe
everyone has been waiting for 50 years for just that feature.

Bart <bc@freeuk.com> writes:
>On 28/08/2023 19:01, David Brown wrote:
>> On 28/08/2023 19:01, Bart wrote:
>
>>> Why is the standard moving backwards?
>>
>> What do you mean?
>>
>> C2x allows you to omit names for parameters you don't use in a function
>> definition.  How is that "moving backwards" ?
>
>We want a stricter language moving forward

Are you using the royal "we" here? The plural definite article surely doesn't apply.

On Monday, 28 August 2023 at 18:40:26 UTC+1, David Brown wrote:
> On 28/08/2023 18:35, Kaz Kylheku wrote:
> > On 2023-08-28, David Brown <david...@hesbynett.no> wrote:
>
> >> This means that in at least some cases, the use of continuous text was
> >> motivated by factors that outweighed legibility - perhaps costs, perhaps
> >> intentionally making the text harder to read.
> >
> > Like, maybe, keeping the illiterate rabble illiterate, maintaining the
> > status quo that only a tiny elite can read and write?
> >
> Yes. Writing without spaces isn't much harder than writing with spaces,
> but reading it is a lot harder. As a member of the elite, you don't
> want reading to be easier for others.
>
> Even within the elite classes, your ability to read unspaced texts
> quickly (or, more often, your ability to afford a scribe who could read
> it) was a status symbol. It was like serving larks' tongues at dinner -
> you don't do it because they are tasty or nutritious, you do it because
> they are expensive.
>
> I don't think anyone can say how much of an influence such reasons were,
> but it is certainly one of several reasons given by historians.
>
And then in the next paragraph, the same people claim that spaces were
omitted to save expensive parchment.
You don't deliberately make things difficult for yourself. These suggestions
are all most implausible.
We don't really know why the Greeks used scriptio continua whilst the Jews
did not. We do know that they did.

On 28/08/2023 21:14, Bart wrote:
> On 28/08/2023 19:01, David Brown wrote:
>> On 28/08/2023 19:01, Bart wrote:
>
>>> Why is the standard moving backwards?
>>
>> What do you mean?
>>
>> C2x allows you to omit names for parameters you don't use in a
>> function definition.  How is that "moving backwards" ?
>
> We want a stricter language moving forward and less of the crazy
> flexibility of older versions.

I am certainly in favour of things that make it easier to find or
prevent errors. And there are certainly some flexibilities in C that
make it easier for some kinds of errors to slip by. (For my own
development, I use a lot of warnings in gcc as a way to limit the
language and reduce possibilities. Many people do this - it is also
popular to adhere to coding standards or style guides.)

However, I really do not see this particular case as a problem.

>
> What other missing bits of syntax can we assign some arbitrary meaning
> to rather than being called out as obvious errors?

Let's stick to the issue at hand.

>
> How about, leaving out a function name in a definition, when that
> function is not called?
>

And let's not go overboard.

We are letting unused parameters be anonymous. Letting unused things be
anonymous is often a good thing - it reduces clutter and saves having to
invent identifiers that are never actually needed. Thus we have
anonymous unions and anonymous structs.

>
>>> But this one is unusual: normally newer gcc tries to continue passing
>>> legacy code that older versions passed. Now, it can be passing code
>>> that older versions *failed*.
>>
>> And the problem with that is... what?  Nothing, as far as I can see.
>
> It was an error before for a good reason. Now somebody decided you need
> to take away some redundancy so that they can declare unused parameters
> without the compiler moaning about it.

Remember we are talking about /unused/ parameters. There was not really
a good reason to require them to have names, and in C2x they won't be
needed.

A typical use-case for this is for call-backs. Call-back function types
often have parameters such as a "void *" user data pointer, or perhaps
parameters for handles or instances (of whatever thing is doing the
call-back). These can be very useful for writing generic call-back
functions that handle many cases. But if you only need one case, you
don't really want parameters at all. Of course you must still declare
the right number and types of parameters in C - those must match.
Omitting the parameter names seems a nice convenience. (Some people
will prefer to have the names anyway, and that's also fine.)

>
> So that actual errors, like accidentally missing out a name, are harder
> to detect.

It is important to detect errors that are likely. It is a lot less
important to detect errors that are very unlikely to be made.

>
> There are also lots of reasons for a parameter name not to be used in
> some compilations out of dozens or hundreds:
>
> Maybe you've only got as far as writing a skeleton function and not all
> params are yet use, or in the middle of writing it, or it's being
> changed, or parts are temporarily commented out. It's a WIP!

Sure. And there is nothing stopping you from including the parameter
name - omission is optional.

>
> Yet an overzealous compiler might warn about an unused parameter name.
> There must be better ways of shutting it up than deleting the name
> completely. So, what was it again, when you decide to use it?

There /are/ other ways of doing it.

A common way, supported by most compilers, is a cast to void :

int foo(int x, int y) {
(void) y; // y is intentionally unused
return x + 1;
}

Compilers also often have their own methods, such as gcc's
"maybe_unused" attribute (others have pragmas, declspecs, or other methods).

If you think it is clearer to use "(void) y" in such a situation, rather
than omitting the parameter name, then write that. I probably will
continue to do so in my own code - it's not a feature I expect to have
much use of personally. But others could well find it neat.

>
>
> What about declarations? It would be perverse for those to define a name
> for a parameter which is not named nor used in the definition (what
> would it be called?).

You don't have to have parameter names in declarations in today's code.
You don't have to have consistency between the names in declarations and
definitions. (You can well say that this is a bad thing - and I'd agree
with you, even though I understand why enforcing consistency would not
be an easy fit with the rest of the language. But whatever your opinion
on this is, you must understand that this is how C is defined.)

Allowing function definitions to omit parameter names lets you be
consistent with declarations that omit parameter names. So it is a win
for consistency.

>
> The whole thing has a very bad smell to me.
>
> Using Godbolt, I can see that gcc up to 11.1 failed missing parameter
> names. From 11.1 onward, such code passes.

Yes, as I explained - this is not a surprise.

(Again, I would have preferred an error, or at least a warning, if the
C2x standard were not explicitly chosen. Don't mistake understanding
for liking.)

>
>> But is it a useful rule?  I can't see it being particularly important.
>>
>> If anything, I'd prefer a rule saying parameter names were necessary
>> in declarations - that's the bit seen by people using the function.
>> Parameter names for unused parameters in a function definition add
>> very little to the code.
>
> Which, of course, is totally backwards. Most things in this newsgroup are!
>
> Parameter names in declarations are optional: you can take them all out,
> and programs would still compile.
>
> Not so with parameter names in definitions.
>
> Actually, I've never across missing parameter names in definitions in
> the million lines of code I've passed through my C compiler. Or maybe
> everyone has been waiting for 50 years for just that feature.
>

Why would you expect to come across missing parameter names in
definitions? They are not legal in C as yet - C2x is not published.
And even after it comes out, you won't expect to see it in much code for
a long time - C programmers are conservative in using new standards.

You'd see it sometimes in C++ code, but obviously that's not something
you'd give to your compiler.

On 2023-08-28, Bart <bc@freeuk.com> wrote:
> On 28/08/2023 19:01, David Brown wrote:
>> On 28/08/2023 19:01, Bart wrote:
>
>>> Why is the standard moving backwards?
>>
>> What do you mean?
>>
>> C2x allows you to omit names for parameters you don't use in a function
>> definition.  How is that "moving backwards" ?
>
> We want a stricter language moving forward and less of the crazy
> flexibility of older versions.

What?

> What other missing bits of syntax can we assign some arbitrary meaning
> to rather than being called out as obvious errors?
>
> How about, leaving out a function name in a definition, when that
> function is not called?

Yes, that is possible with this same feature:

void foo_api_bar_impl(int arg, void (*)(char *))
{ // ...
}

This bar implementation of the foo API found that it didn't need to
store or call the function pointer parameter, so it didn't name it.

In C++ implementations, this feature suppresses warnings about unused
parameters. If it's not used, but not named, then there is nothing to
complain about.

C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
prototype declaration, parameter names can be omitted.

C++ just allowed that syntax in definitions, which looks like a
miniscule extension that has as a palpable impact on usability.

C programmers have wasted lines of code on things like

void foo_api_bar_impl(int arg, void (*fn)(char *))
{ UNUSED(fn); // this project's own unused macro
}

>>> But this one is unusual: normally newer gcc tries to continue passing
>>> legacy code that older versions passed. Now, it can be passing code
>>> that older versions *failed*.
>>
>> And the problem with that is... what?  Nothing, as far as I can see.
>
> It was an error before for a good reason. Now somebody decided you need
> to take away some redundancy so that they can declare unused parameters
> without the compiler moaning about it.

C++ has had this feature for decades. Adopting it into C improves the
range of compatibility between the languages.

The "void *" type came from C++; if ANSI C hadn't adopted it, that would
have been a major rift. It's not adopted in the same form though;
C is more loose in conversion from void *.

ANSI C invented the (void) parameter list; in C++ it was just ().
C++ doesn't support old-style unprototyped declarations, so it doesn't
need this. Yet, C++ implemented (void) for compatibility.

Compatibility matters. Less work when preparting a header file usable
in C and C++. Less work converting C code to C++.

> So that actual errors, like accidentally missing out a name, are harder
> to detect.

Accidentally missing a name makes itself loudly heard when you use
the name and it's not defined.

You could have a bug whereby it is defined, but in an outer scope;
that's too bad for you.

Since standard C doesn't have nested functions, that would have to be a
clash between a intended/forgotten local and global, which indicates
that you're using a local-like naming scheme for globals.

> There are also lots of reasons for a parameter name not to be used in
> some compilations out of dozens or hundreds:
>
> Maybe you've only got as far as writing a skeleton function and not all
> params are yet use, or in the middle of writing it, or it's being
> changed, or parts are temporarily commented out. It's a WIP!

If you think you will use the parameters, you will likely put in
their names and live with the unused diagnostics which remind you
to complete the work.

> Yet an overzealous compiler might warn about an unused parameter name.

This is not overzealous. Diagnosis of unused lexical variables uncovers
bugs. You want this in any language with lexical scopes, and to be on by
default.

I added it to TXR Lisp not long ago.

Only the compiler warns about it, not the interpreter.

Both warn about an unbound variable.

No peep out of interpreter:

1> (let (x))
nil

Intepreter warns about y before running code, then the error
happens:

2> (let (x) y)
** expr-2:1: warning: unbound variable y
** expr-2:1: unbound variable y

Compiler warns about unused x and undefined y, but generates code.

3> (compile-toplevel '(let (x) y))
** expr-3:1: warning: unbound variable y
** expr-3:1: warning: let: variable x unused
#<sys:vm-desc: 8b9e5c0>

Code bombs when run:

4> [*3]
** expr-2:1: variable y is not defined

Unused variables are code smell which can indicate an actual
bug like: (defun add (x y) (+ x x)).

Sometimes unused variables are just crumbs left after refactoring;
it's good to clean them out.

> There must be better ways of shutting it up than deleting the name
> completely. So, what was it again, when you decide to use it?

If the option is available in the syntax, there is nothing better.

All else being equal, subtracting a token to achieve a goal is
better than adding more tokens.

> What about declarations? It would be perverse for those to define a name
> for a parameter which is not named nor used in the definition (what
> would it be called?).

No it wouldn't.

The declaration might be like this:

void foo_api_register_bar_callback(void *context,
void (*callback_fn)(void *context,
void *buffer,
size_t size));

You're implementing the callback and find you don't need a context:

void my_bar_callback(void *, void *buffer, size_t size)
{
}

Just because you don't need that parameter in your implementation of the
callback doesn't mean that the master declaration for it should omit the
name, too. The naming (assuming it does not lie) tells us that the
context parameter that will be passed to the callback is that one that
is passed to the registration function.

Obviously, you lack experience in C and C++, due to working in other
things, but you have a lot of opinions.

> On C, code fails on older versions, and gives warnings from 11.0.0 onwards.
>
> In MSVC, code fails on all versions. So:
>
> Older Newer/current
>
> GCC Fail Pass
> Clang Fail Warning
> MSVC Fail Fail
>
> bcc --- Fail
> tcc --- Fail
>
> Nice to see consistency in a language! All those languages in the final
> column are still C. I think.

They are a newer dialect of C. Obviously, you can't use the feature
if your code has to work with older compilers (that are not C++).

C is fragmented into numerous dialects with each new revision of
the language.

So is anything you've written yourself.

Any change you make to a language, whether an ISO-standard definition,
or your own project, means that something works no that won't work
with yesterday's version.

Every real, functional change is testable by a test case which fails if
the change is absent and passes when the change is present.
(If you can't write such a test for a change, it must be some
refactoring or code cleanup.)

For a language, that test case is a piece of code that is not supported
by the version of the language before the change.

Every commit that you make like this splinters the dialect into
before that commit and after.

> Actually, I've never across missing parameter names in definitions in
> the million lines of code I've passed through my C compiler. Or maybe
> everyone has been waiting for 50 years for just that feature.

Yes; it's a bleeding-edge feature, so you wouldn't have encountered
that. If you'd supported a million lines of C++, you probably would
have.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 28/08/2023 21:31, Malcolm McLean wrote:
> On Monday, 28 August 2023 at 18:40:26 UTC+1, David Brown wrote:
>> On 28/08/2023 18:35, Kaz Kylheku wrote:
>>> On 2023-08-28, David Brown <david...@hesbynett.no> wrote:
>>
>>>> This means that in at least some cases, the use of continuous text was
>>>> motivated by factors that outweighed legibility - perhaps costs, perhaps
>>>> intentionally making the text harder to read.
>>>
>>> Like, maybe, keeping the illiterate rabble illiterate, maintaining the
>>> status quo that only a tiny elite can read and write?
>>>
>> Yes. Writing without spaces isn't much harder than writing with spaces,
>> but reading it is a lot harder. As a member of the elite, you don't
>> want reading to be easier for others.
>>
>> Even within the elite classes, your ability to read unspaced texts
>> quickly (or, more often, your ability to afford a scribe who could read
>> it) was a status symbol. It was like serving larks' tongues at dinner -
>> you don't do it because they are tasty or nutritious, you do it because
>> they are expensive.
>>
>> I don't think anyone can say how much of an influence such reasons were,
>> but it is certainly one of several reasons given by historians.
>>
> And then in the next paragraph, the same people claim that spaces were
> omitted to save expensive parchment.

Yes. Does it surprise you that there could be several reasons for
something? Or that different people might have different reasons? Or
that historians might have different theories?

> You don't deliberately make things difficult for yourself. These suggestions
> are all most implausible.

They are all far more plausible than thinking it was easy to read.

> We don't really know why the Greeks used scriptio continua whilst the Jews
> did not. We do know that they did.

Agreed. But we know some things that were not the reason for it. They
did not omit spaces to make the writing more legible. That's a starting
point at least.