From another thread:

On 07/12/2021 09:57, David Brown wrote:
DB> On 07/12/2021 10:22, Bart wrote:

B>> That might be the case on Unix where where the OS and C are so
B>> intertwined that that you don't know where one ends and the other
B>> begins.

DB> No, /you/ don't know where one ends and the other begins

I suspect that's true of many of us. It /is/ confusing when:

1. the C standards documents include the standard library, not just C
2. Clib and OS calls are invoked in the same way (flat namespace)
3. compiler and linker are expected to /search/ for referenced files
4. the 'OS calls' aren't really OS calls but wrappers
5. C headers are separate from the modules they describe
6. one C header can bundle declarations for multiple modules and one
module may need the inclusion of multiple headers (AIUI)

IMO that's a bit of a mess. All of those, even if I understand them
correctly (which is far from certain), blur the boundaries between the
language, the language's library/ies, and the operating system.

In a new language all of those six problems can be fixed - and should
be, IMO.

--
James Harris

On 13/12/2021 19:03, James Harris wrote:
> From another thread:
>
> On 07/12/2021 09:57, David Brown wrote:
> DB> On 07/12/2021 10:22, Bart wrote:
>
> B>> That might be the case on Unix where where the OS and C are so
> B>> intertwined that that you don't know where one ends and the other
> B>> begins.
>
> DB> No, /you/ don't know where one ends and the other begins
>
> I suspect that's true of many of us. It /is/ confusing when:
>
> 1. the C standards documents include the standard library, not just C
> 2. Clib and OS calls are invoked in the same way (flat namespace)
> 3. compiler and linker are expected to /search/ for referenced files
> 4. the 'OS calls' aren't really OS calls but wrappers
> 5. C headers are separate from the modules they describe
> 6. one C header can bundle declarations for multiple modules and one
> module may need the inclusion of multiple headers (AIUI)
>
> IMO that's a bit of a mess. All of those, even if I understand them
> correctly (which is far from certain), blur the boundaries between the
> language, the language's library/ies, and the operating system.
>
> In a new language all of those six problems can be fixed - and should
> be, IMO.
>
>

I am not sure how much of a "problem" this all is - we've had C for
decades, and it seems unlikely that you, me, or anyone else in this
group is smarter than the last 40-odd years worth of programmers,
language designers and systems architects put together.

Without going into details of your points, since that might just start
another long and unproductive thread, I would certainly agree that the
single flat namespace of C is a limitation of the language. Any new
language that aspires to be used for more than small and simple tasks
needs hierarchical namespace handling of some sort - modules,
namespaces, units, interfaces, whatever you want to call it and however
you want to divide it up. And it is definitely important to think
through the balance between flexibility and structure here - there are
significant pros and cons associated with tying interface files and
implementation files together tightly or loosely.