On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
>
> So what exactly is a C compiler? What does it do? Don't bother answering.
>
A compiler takes a program written in one language and translates it into
another language. As the author of many languages yourself, you should know
that basic defintion.
>
> Next I fully expect you will say that C isn't really a language. From
> what I've gleaned here, it isn't. It's a collection of suggestions and
> recommendations as to how an input file might be processed.
>
The problem is that if we extend C in a small way, for example to speed things
up a bit by making 32 bit pointers "near" pointers and 64-bit pointers "far"
pointers, the we've got what is technically a different language. Pointer
declarations which would be syntax errors in original C are now legal, whilst
a handful of legal C programs which use "far" or "near" as identifiers will
break.
But it isn't really a different language. It's just a slightly incompatible extension.

Because gcc is written by volunteers, it's far more fun to implement new features
than to write a compiler for a language where someone else has taken all the
decisions. So gcc has a lot of extensions.
>
> There's so much gaslighting going on here that I'm almost starting to
> question my own ideas.
>
> /My/ idea of a compiler is a simple box, with a single Go button. You
> feed in a tape at one side representing source code and it writes a tape
> on the other with a runnable program. When it's finished a green light
> flashes. The output tape I can subsequently feed into a computer to execute.
>
> If there's a problem with the input, a red light flashes, and no output
> tape is produced.
>
> It's almost like a consumer product that anyone can use.
>
> Now, what would gcc look like when expressed like that? How many
> thousands of buttons and lights would it have? What actual language
> would be accepted? How many colours of errors lights would there be? I
> know there is no green light.
>
> How big would it be? Would it be one huge box, or would be contain other
> boxes? How many different languages could it deal with?
>
> One more thing about this box: if you don't set the dials for the title
> of the output take, it will overwrite the same tape it producted a
> minute ago! And of course the buttons, switches and dials all reset
> themselves each time.
>
A C compiler translates C into another language, almost always directly
executable machine code. So the specification for a C compiler is
"take a C source file and produce the executable that has the same behaviour".
But of course we want more than that. We want "produce the best executable
with the same behaviour".
That's the rub. It's not so much that there are minor and usually unimportant
trade-offs to be had between code size, memory usage, and execution speed.
It's that a compiler can't actually produce the "best" executable, because
optimisation isn't a computable problem (there's no Turing machine which reads
a C source as input and outputs the fastest equivalent machine code as output
it's mathematically impossible).
So you have to ask the user. The most basic option a compiler usually has is
release vs debug. But it's only necessary because of techncial limitations.
Then you've got other options like "signed chars" which are necessary because
of poor design decisions taken early in C's history. Then you've got options like
"warning level" or "treat warnings as errors" which are cop-outs by the compiler
designers and in a good compiler wouldn't be provided at all. (The concept
of a warning which is only sometimes worth issuing is a strange one).

The options do represent failures. But some of those failures are inherent
problems in what you are asking the compiler to do. gcc of course has a
ridiculous number of options and many of them could and should be culled,
but you'd still be left with a substantial number which carry their weight.

On 04/09/2023 11:07, Malcolm McLean wrote:
> On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
>>
>> So what exactly is a C compiler? What does it do? Don't bother answering.
>>
> A compiler takes a program written in one language and translates it into
> another language. As the author of many languages yourself, you should know
> that basic defintion.

Yes, but what is a /C/ compiler? Because apparently:

BB:
> For example, nether the gcc nor clang command (run just like that) is
a C compiler.

Those (run just like that) will take an input and translate it into an
about. But that is not compiling C according to BB.

Here's a novel idea, how about taking those products (run just like
that) and making them C compilers. Trustworthy ones.

On Monday, 4 September 2023 at 11:43:49 UTC+1, Bart wrote:
> On 04/09/2023 11:07, Malcolm McLean wrote:
> > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
> >>
> >> So what exactly is a C compiler? What does it do? Don't bother answering.
> >>
> > A compiler takes a program written in one language and translates it into
> > another language. As the author of many languages yourself, you should know
> > that basic defintion.
> Yes, but what is a /C/ compiler? Because apparently:
>
> BB:
> > For example, nether the gcc nor clang command (run just like that) is
> a C compiler.
> Those (run just like that) will take an input and translate it into an
> about. But that is not compiling C according to BB.
>
Yes, because in BB's world, a grammar either defines C, or a subset of C,
or a superset of C, or a different language to C.

On 04/09/2023 12:07, Malcolm McLean wrote:
> On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
>>
>> So what exactly is a C compiler? What does it do? Don't bother answering.
>>
> A compiler takes a program written in one language and translates it into
> another language. As the author of many languages yourself, you should know
> that basic defintion.

That's not what he is asking.

You can't say what a "C compiler" is until you understand what "C" is.
It is the language defined by the C standards. Technically, only the
current standard (C17) defines C, as it replaces previous standards -
but in practice it is reasonable to talk about a "C99 compiler", a "C17
compiler", etc., with a "C compiler" commonly regarded as meaning at
least a C99 compiler, since the changes to the language after C99 were
relatively small. (The upcoming C23 has big changes again.)

So a "C compiler" is a compiler which will accept the language as
defined by the standards, and issue diagnostics as required for syntax
or constraint errors. It can issue other diagnostics, but should not
fail to compile source that is valid according to the C standards.
Other things useful for compiling C code, including a standard library,
headers, OS/System headers, an assembler, a linker, utilities such as
"make", editors, IDEs, debuggers, profilers, linters - these are not
part of a C compiler, but may be packaged alongside for user convenience.

It is usually fine to have a much looser meaning of "C compiler", as a
tool for compiling a language roughly like C - perhaps with extra
restrictions, perhaps with extra extensions, perhaps stricter or perhaps
more lenient. But in this discussion, since Bart wants to know exactly
what is allowed or not allowed in C and how a C compiler should behave,
we have to use a strict definition of the language.

There is nothing to suggest that a "C compiler" must be a single
program, nor that it should be run using a simple command-line
interface. I have used several dozen C compilers through the years - I
don't know of any that were even reasonably strict and compliant C
compilers without an appropriate selection of flags or options.

>>
>> Next I fully expect you will say that C isn't really a language. From
>> what I've gleaned here, it isn't. It's a collection of suggestions and
>> recommendations as to how an input file might be processed.
>>
> The problem is that if we extend C in a small way, for example to speed things
> up a bit by making 32 bit pointers "near" pointers and 64-bit pointers "far"
> pointers, the we've got what is technically a different language. Pointer
> declarations which would be syntax errors in original C are now legal, whilst
> a handful of legal C programs which use "far" or "near" as identifiers will
> break.
> But it isn't really a different language. It's just a slightly incompatible extension.

If a compiler silently accepts "int * far p;", or "far int * p;", or
whatever syntax you are suggesting, then it is not a C compiler in the
context of this discussion, because a C compiler will at least issue a
diagnostic here. Your hypothetical extended C compiler might be a more
useful tool, and it would often be referred to as a "C compiler", but in
this discussion branch, it is not.

>
> Because gcc is written by volunteers, it's far more fun to implement new features
> than to write a compiler for a language where someone else has taken all the
> decisions. So gcc has a lot of extensions.

For the past two decades, the great majority of work on gcc has been
done by professionals who have been paid for that work, by companies
such as Intel, ARM, Red Hat, IBM, Google, and others. What you describe
was more accurate in the 1980's and 1990's - and many of gcc's
extensions have since been standardised. Since those days, the solid
majority of gcc extensions have been within the reserved namespaces,
such as __builtin* functions and __attribute__'s. There is, however, a
tendency to allow new features of later C standards to be accepted by
default even if those newer C standards are not picked.

Since its early days, gcc has by default accepted a language that only
approximately conforms to any of the C standards. If you want it to act
as a C compiler, you need to give it the appropriate flags (specify the
standard you want with "-std=c11", "-std=c17", etc., and either
"-Wpedantic" or "-pedantic-errors").

>>
>> There's so much gaslighting going on here that I'm almost starting to
>> question my own ideas.

When everyone else is saying something different than you, you /should/
be questioning your own ideas.

>>
>> /My/ idea of a compiler is a simple box, with a single Go button. You
>> feed in a tape at one side representing source code and it writes a tape
>> on the other with a runnable program. When it's finished a green light
>> flashes. The output tape I can subsequently feed into a computer to execute.

That's not how real-world compilers work - at least, not when the
language must cover such a huge variety of usages as C. It's okay for a
small or limited language with simple tools and a very restricted set of
usages. And it might be acceptable for a byte-compiler that targets a
single virtual machine.

So yes, question your ideas.

Bart <bc@freeuk.com> writes:

> On 04/09/2023 09:54, David Brown wrote:
>> On 03/09/2023 19:11, Bart wrote:
>
>>> What's wrong with that?
>> If you can live inside a bubble, and be happy with that, then I suppose
>> that's fine.  However, you don't have the experience or understanding to
>> criticise those outside the bubble.  You can live in your blissful
>> ignorance if that's what suits you - but please understand that others do
>> not want to be in your bubble.  It does not appeal at all to me. Your
>> bubble tools and languages are of little use or interest to all but a
>> very few other people.
>
> That may be so. But you can still learn things from them.

I think I've asked before, but is there a language reference manual?

> And yet, I can't get this program to compile when expressed in my langage:
>
> char* fred(void) {
> (long long int)rand()*3.14159;
> }
>
> int main(void) {
> printf("%s\n", fred());
> }

C (as currently defined) has nothing to say about the behaviour of this
program. That makes it trivial to implement an "equivalent" in almost
any language. If your view of equivalent is the inclusive one, then any
program at all will match the behaviour permitted for this one. And if
your view of equivalent is quite narrow, then any text that has no
defined meaning in the other language will do instead.

I post this only to explain how I interpret the notion of "expressing" a
program in another language. I am sure your view of the term is quite
different.

--
Ben.

Bart <bc@freeuk.com> writes:
>On 04/09/2023 09:54, David Brown wrote:
>> On 03/09/2023 19:11, Bart wrote:
>
>>> What's wrong with that?
>>
>> If you can live inside a bubble, and be happy with that, then I suppose
>> that's fine.  However, you don't have the experience or understanding to
>> criticise those outside the bubble.  You can live in your blissful
>> ignorance if that's what suits you - but please understand that others
>> do not want to be in your bubble.  It does not appeal at all to me. Your
>> bubble tools and languages are of little use or interest to all but a
>> very few other people.
>
>That may be so. But you can still learn things from them. A good idea is
>a good idea.

Not really. Define 'good' in this context.

On 04/09/2023 12:06, Bart wrote:
> On 04/09/2023 09:54, David Brown wrote:
>> On 03/09/2023 19:11, Bart wrote:
>
>>> What's wrong with that?
>>
>> If you can live inside a bubble, and be happy with that, then I
>> suppose that's fine.  However, you don't have the experience or
>> understanding to criticise those outside the bubble.  You can live in
>> your blissful ignorance if that's what suits you - but please
>> understand that others do not want to be in your bubble.  It does not
>> appeal at all to me. Your bubble tools and languages are of little use
>> or interest to all but a very few other people.
>
> That may be so. But you can still learn things from them. A good idea is
> a good idea.

I agree entirely that you can learn from them, and some good ideas are
widely applicable.

But a good idea for one language is not necessarily a good idea for a
different language.

>
>>
>>
>
>> We focus on C here, because it is a C discussion group.
>
> The thread has been largely about how compilers work. That surely can be
> compared with how compilers for like languages work. Or even how my
> compiler for C works.

Your own languages are basically irrelevant here. Languages related to
C are sometimes interesting for comparison, but should at least be
languages familiar to people here. (Thus C++ can sometimes come up.)
How your C compilers act on C code /is/ relevant.

>
>> Do not imagine for a moment that you are special because you have
>> another language to compare to C.
>
> Why not? How many here:
>
> * Have used a viable alternative to C for most of their careers?
>   (I don't mean C++!)

Why don't you mean C++? It is a viable alternative to C for a great
many uses. Other languages that can be used in places where C might
also be a reasonable choice include Rust, Go, D, Fortran, Ada, Pascal,
Java, Objective-C, Ocaml, Zig, Forth, and probably several others.

Your language is not viable as a choice for programming. I would not
consider a personal one-man language as acceptable for professional
work. (Your opinion, naturally, will differ here - I can only speak for
myself.) I've seen what happens when rare or obscure languages are
picked for development projects, and it is not pretty. Even when the
tool involved is a perfect for the task, and even when it is an
established tool (at least big enough to have its own Wikipedia page),
you have a maintenance disaster. The customer is left with software
that has cost them a great deal of time and money, and as soon as it
hits a limit or a new feature is required, it is worthless because they
can't get someone to build on it.

No, at least for the customers I have had over the decades, your tools
would not be considered viable at all.

(And of course they are completely useless on the main targets for most
of my code.)

And regardless, your point is irrelevant to being able to compare C with
other languages.

>
> * How many have /designed and implemented/ that alternative?

That is completely irrelevant to understanding other languages.

>
> * How many here have written compilers? That includes a 'full stack'
>   implementation

Again, irrelevant.

>
> * How many here have tried implementing a C compiler?
>

Again, irrelevant.

> You don't think that can give someone a rather special perspective?

Not for this point, no.

Don't get me wrong - you've done some impressive stuff over the years,
and creating your own languages and tools is no minor achievement.
Implementing a C compiler does (or should) give you some useful
insights. (Though you are not alone in this group in having implemented
a compiler.)

But does any of that mean you have unique insights or are able to offer
comparisons or views on C that others cannot? No, it does not. For
every time you bring up your own language in comparison to C, I could
compare it to half a dozen other languages (and there are other regulars
here would could do far more) - all equally irrelevant. I don't need to
have had a career programming in Ada or D to be able to compare them to
C - I just need to know enough about the languages. And these have the
overwhelming benefit that everyone here can look up the details if they
want to know more, try them online at godbolt.org (or other similar
sites), and test them out on their own machines.

So yes, you certainly have done something few others have over the
decades. Call yourself "special" if you want - it would not be
unreasonable. But don't mistake that for thinking you have special
knowledge of C or unique abilities to compare it to other languages.

>
> You can tell any other upstart, This is what a C compiler is and how it
> is supposed to work. But not when that upstart says, No, a C compiler
> can also look and behave like /this/, because I've done it.

Well, no, you haven't.

You've made a compiler for a sort-of C language, of unknown standard,
with unknown details, that rejects code that is by definition valid C,
works in limited use-cases, and is missing features that other people
want when developing in C.

That doesn't mean it is a bad tool - being small, fast and easy to use
is a good thing. (And it certainly does not mean it is not an
impressive achievement.) And when your tool is good enough, it is good
enough.

I would be much happier to see you take credit and stand for what you
have achieved, than making absurd comparisons that lead to ridicule.
Say you have made a sort-of C compiler that handles a useful subset of
the language and has defaults and error handling that you personally
find more useful than other tools and the standard C language - that's
honest opinion, and perfectly valid. Telling people that the defaults
they find useful in massively popular software are objectively wrong, or
that C compilers should work contrary to the requirements of the
language, is entirely different - it makes you look arrogant and
ignorant. (This is especially the case since you have proved that your
knowledge of C is barely enough to write code in the language, and
certainly not accurate enough to write a conforming C compiler.)

>
>>> I acknowledge that it is easy for me to try new things, but that
>>> itself allows me to say whether they are better than how C does it,
>>> or worse. (Usually the former! The others don't last long.)
>>
>> No, it does not allow you to say anything of the sort - except within
>> the very limited and niche confines of your little bubble.  You have
>> no concept of how your ideas might work or fail to work in the real
>> world - you've demonstrated that repeatedly here.
>
> The real world consisting of half a century's accumulation of cruft in
> the C language, compilers, options, libraries, makefiles and assorted
> other tools?
>
> I fully agree.

You can't "agree" with something completely unrelated to what I wrote.

>
> Of course, you can /change/ that in the real world if somebody put their
> mind to it. But nobody will. Most people's contribution in that area is
> to add to the cruft: 51 year's accummulatation instead of 50!
>

And what, exactly, do you think /you/ are doing? Whining, moaning and
complaining to people who have no influence whatsoever on the language
or tools in question? You've written a sort-of-C compiler that is, if I
understand correctly, not even that useful for your own work - and the
only other person interested in it makes flat-earthers look rational.

What do you think we should all be doing - even if anyone here agreed
with you on more than a few small points?

>>   You have no inkling about what other people want or need, or how
>> they could apply to other people's projects.  This is because you
>> directly avoid anything outside your bubble, refuse to listen to
>> anything people tell you, and you will not make any attempt to learn
>> or understand.  Nothing gets through your walls of smugness,
>> self-satisfaction, and irrational hatred.
>>
>> That does not mean you don't have good ideas, or that your programming
>> languages don't have their good points - far from it, there are some
>> nice things there.  They are not as unique or innovative as you
>> believe, and certainly not as universally good, but can be good things
>> for at least some people and some uses.
>
> And yet, I can't get this program to compile when expressed in my langage:

Why should anyone care about your language?

>
>   char* fred(void) {
>       (long long int)rand()*3.14159;
>   }
>
>   int main(void) {
>       printf("%s\n", fred());
>   }
>
> I can very easily do so in C, /and/ I can run it.

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

> On Monday, 4 September 2023 at 11:43:49 UTC+1, Bart wrote:
>> On 04/09/2023 11:07, Malcolm McLean wrote:
>> > On Monday, 4 September 2023 at 10:34:39 UTC+1, Bart wrote:
>> >>
>> >> So what exactly is a C compiler? What does it do? Don't bother answering.
>> >>
>> > A compiler takes a program written in one language and translates it into
>> > another language. As the author of many languages yourself, you should know
>> > that basic defintion.
>> Yes, but what is a /C/ compiler? Because apparently:
>>
>> BB:

Bart, you asked me not to reply to that question so I didn't. Given
that you don't want me to reply, I would appreciate it if you left me
out of the discussion.

>> > For example, nether the gcc nor clang command (run just like that) is
>> a C compiler.
>> Those (run just like that) will take an input and translate it into an
>> about. But that is not compiling C according to BB.
>>
> Yes, because in BB's world, a grammar either defines C, or a subset of C,
> or a superset of C, or a different language to C.

It's more than just the grammar, the defined semantics matter as well,
but that's the gist of it. I'd hope that you also define a programming
language as a grammar plus semantics. That's why names like C99 and GNU
C are used -- they name different languages.

Do you know that gcc (with no other flags or options) will report no
syntax errors for this source code:

PROGRAM HELLO
WRITE (*,*) 'Hello world'
END

? Is it only in "my world" that the plain gcc command is not a C
compiler?

--
Ben.

Bart <bc@freeuk.com> writes:

> On 04/09/2023 03:17, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 03/09/2023 15:31, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> Take this program:
>>>>>
>>>>> void fred(void){}; void bill(void)
>>>> This program has two syntax errors.
>>>
>>> Sorry, I found that when I tested the above but forgot to update the post.
>>>
>>>> The one you are talking about and
>>>> the missing ; or missing compound statement as the end of the line.
>>>>
>>>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>>>> a syntax error.
>>>>>
>>>>> Should a compiler fail it or not?
>>>> The standard says that it should be reported.
>>>
>>> And yet the first four compilers I tried don't do that.
>> Most programs that claim to be C compilers are not C compilers. For
>> example, nether the gcc nor clang command (run just like that) is a C
>> compiler.
>
> Ha ha ha!
>
> And here /you/ go around the same loop!
>
> Oh, you know the product that we've been hailing as the flagship C compiler
> for that few thousand posts, well it isn't really a C compiler anyway!
>
> So what exactly is a C compiler? What does it do? Don't bother
> answering.

OK.

--
Ben.

On 2023-09-04, Bart <bc@freeuk.com> wrote:
> On 04/09/2023 03:17, Ben Bacarisse wrote:
>> Most programs that claim to be C compilers are not C compilers. For
>> example, nether the gcc nor clang command (run just like that) is a C
>> compiler.
>
> Ha ha ha!
>
> And here /you/ go around the same loop!

gcc, when invoked on a .c file with no arguments, is a C compiler,
for some version of GNU C. It is not an ISO C compiler.

"C" does not mean "ISO C", unless the debate has been explicitly
restricted that way.

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

On 04/09/2023 17:16, Ben Bacarisse wrote:

> Do you know that gcc (with no other flags or options) will report no
> syntax errors for this source code:
>
> PROGRAM HELLO
> WRITE (*,*) 'Hello world'
> END
>
> ? Is it only in "my world" that the plain gcc command is not a C
> compiler?

Your comments are misleading:

--------------------------------------
c:\c>type c.c
PROGRAM HELLO
WRITE (*,*) 'Hello world'
END

c:\c>gcc c.c
c.c:1:7: error: unknown type name 'PROGRAM'
1 | PROGRAM HELLO
| ^~~~~~~
c.c:2:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'WRITE'
2 | WRITE (*,*) 'Hello world'
| ^~~~~
c.c:2:19: warning: character constant too long for its type
2 | WRITE (*,*) 'Hello world'
| ^~~~~~~~~~~~~

c:\c>ren c.c c.ext

c:\c>gcc c.ext
C:\tdm\bin\ld.exe:c.ext: file format not recognized; treating as linker
script
C:\tdm\bin\ld.exe:c.ext:1: syntax error
collect2.exe: error: ld returned 1 exit status

c:\c>ren c.ext c.ftn

c:\c>gcc c.ftn
gcc: error: c.ftn: Fortran compiler not installed on this system

--------------------------------------

I didn't use the -x option as you said it would work without options.
But apparently it needs some input to tell it the language. That appears
to be the file extension.

That's clever, but so what? I can do that too:

c:\c>bcc c.ftn
Error: Fortran compiler not available
Stopping

I don't however want a Swiss army knife type of compiler that marshalls
each type of file into the appropriate tool. Isn't that more the OS's job?

Since people are always talking about wrappers around gcc to more
precisely pinpoint the task, why can't they write their own wrappers to
to this kind of dispatch too?

Of course, when /you/ have to, it's not so much fun is it?

I quite like the idea that I can do this:

mm prog compile .m
aa prog assemble .asm
bcc prog compile .c
mc prog transpile .m to C
ms prog Run .m

rather than:

gcc prog.m
gcc prog.asm
gcc prog.c
gcc prog.m -transpile
gcc prog.m -run

Because why not go further:

gcc prog.mp3
gcc prog.html
gcc makefile.mk
etc

You see my point? 'gcc' is too general.

My stuff is controlled by the names of the executables. You want to have
a minimal number of executables controlled by file extension (the famous
file extensions that in Linux are supposed to be optional!)

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

> On 2023-09-04, Bart <bc@freeuk.com> wrote:
>> On 04/09/2023 03:17, Ben Bacarisse wrote:
>>> Most programs that claim to be C compilers are not C compilers. For
>>> example, nether the gcc nor clang command (run just like that) is a C
>>> compiler.
>>
>> Ha ha ha!
>>
>> And here /you/ go around the same loop!
>
> gcc, when invoked on a .c file with no arguments, is a C compiler,
> for some version of GNU C. It is not an ISO C compiler.
>
> "C" does not mean "ISO C", unless the debate has been explicitly
> restricted that way.

Note, though, that this is exactly what has happened in this thread.
Bart's complaints about gcc's defaults are largely based on what "C"
permits, says or requires and gcc's failure to allow, honour or insist
on.

For a long while I went along with the idea that "C" can mean many
things, but that's not how Bart uses the term. In fact, that's one of
his big whinging topics -- C is what you care to make it. So I changed
my usage and posted the remark above. He found it worthy of mockery,
but did not want me to respond. Go figure.

--
Ben.

On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> For a long while I went along with the idea that "C" can mean many
> things, but that's not how Bart uses the term. In fact, that's one of
> his big whinging topics -- C is what you care to make it. So I changed
> my usage and posted the remark above. He found it worthy of mockery,
> but did not want me to respond. Go figure.

C is a language family, like Lisp. Some people mean "Clojure"
when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".

Bart will just have to be patiently educated in the differences among:

- language family
- language dialect
- language standard
- language implementation
- language reference manual

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

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

> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> For a long while I went along with the idea that "C" can mean many
>> things, but that's not how Bart uses the term. In fact, that's one of
>> his big whinging topics -- C is what you care to make it. So I changed
>> my usage and posted the remark above. He found it worthy of mockery,
>> but did not want me to respond. Go figure.
>
> C is a language family, like Lisp. Some people mean "Clojure"
> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".

Yes.

> Bart will just have to be patiently educated in the differences among:
>
> - language family
> - language dialect
> - language standard
> - language implementation
> - language reference manual

How's that going?

--
Ben.

On 04/09/2023 20:17, Kaz Kylheku wrote:
> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> For a long while I went along with the idea that "C" can mean many
>> things, but that's not how Bart uses the term. In fact, that's one of
>> his big whinging topics -- C is what you care to make it. So I changed
>> my usage and posted the remark above. He found it worthy of mockery,
>> but did not want me to respond. Go figure.
>
> C is a language family, like Lisp. Some people mean "Clojure"
> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".

But there is still one current C standard, and one current set of
standard headers?

>
> Bart will just have to be patiently educated in the differences among:
>
> - language family
> - language dialect
> - language standard
> - language implementation
> - language reference manual

Sure, how much more complicated do you want to make it?

But while you're here, perhaps you can tell me which of those myriad Cs
is being compiled in each case here:

gcc prog.c
clang prog.c
tcc lang.c
msvc lang.c
zig cc lang.c
lcc lang.c
pellesc lang.c (I forget the actual compiler name)

None of those likes to be verbose so it's rather a mystery what exactly
they are doing.

All I know is that the family/dialect/standard in each case doesn't care
amount making a missing 'return <value>' a hard error. So else are they
being being lax over?

Do I have to to specify -Werror=xxx 173 times for all the possible
things that ought to sensibly be hard errors?

BTW apparently 'gcc' is not a C compiler. That's both an interesting and
useless bit of information. What is means is that 'gcc.exe' invokes
programs like 'cc.exe', 'as.exe' and 'ld.exe', when presented with a -xc
option or a .c file extension, but people, in a C context, colloquially
refer to 'gcc' as a C compiler.

I think you guys just want to keep things a mystery!

Despite all the smoke and mirrors you want to apply, I seem to remember
a few weeks ago taking a project called libjpeg, and successfully
compiling the C modules it comprised with both 'gcc' and 'bcc' programs,
without any specific dialect options (I might have needed to dumb down
bcc with -old).

So, what language is libjpeg written in? If I look at the Wikipedia
entry for it, it says:

Written in: C

Same with Gzip. Same with CPython.

But, but, there IS no single language called C, right? In the case of
libjpeg, it used also a generic jconfig.h file.

So what's going on? Just trying to bamboozle people? Cut them down to
size? Carry on doing that, and I'll carry on trying to cut all the bullshit.

On 9/4/2023 1:06 PM, Bart wrote:
> On 04/09/2023 20:17, Kaz Kylheku wrote:
>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> For a long while I went along with the idea that "C" can mean many
>>> things, but that's not how Bart uses the term.  In fact, that's one of
>>> his big whinging topics -- C is what you care to make it.  So I changed
>>> my usage and posted the remark above.  He found it worthy of mockery,
>>> but did not want me to respond.  Go figure.
>>
>> C is a language family, like Lisp. Some people mean "Clojure"
>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
>
> But there is still one current C standard, and one current set of
> standard headers?
>
>>
>> Bart will just have to be patiently educated in the differences among:
>>
>> - language family
>> - language dialect
>> - language standard
>> - language implementation
>> - language reference manual
>
>
> Sure, how much more complicated do you want to make it?
>
> But while you're here, perhaps you can tell me which of those myriad Cs
> is being compiled in each case here:
>
>   gcc prog.c
>   clang prog.c
>   tcc lang.c
>   msvc lang.c
>   zig cc lang.c
>   lcc lang.c
>   pellesc lang.c       (I forget the actual compiler name)

Fwiw, its nice to be able to have one code base that compiles in all of
those compilers. I cannot remember trying zig. But I do remember you
helping me port one of my programs to most of those compilers. :^) Fwiw,
here is a crude version of it online:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=a3e49ce5df3d492b288b19cc079741fb777535e907b116efa4d06849a4d5d27889712b21995097e47304946224a5d66dbd3cd337e28e3ce1927aedb177eca3aaa468d80e3e9e2883dfe0e60d1a13f2957514ab2c5c

Using the "default secret key" so everybody can read it. :^)

[...]

On 04/09/2023 20:48, Ben Bacarisse wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> For a long while I went along with the idea that "C" can mean many
>>> things, but that's not how Bart uses the term. In fact, that's one of
>>> his big whinging topics -- C is what you care to make it. So I changed
>>> my usage and posted the remark above. He found it worthy of mockery,
>>> but did not want me to respond. Go figure.
>>
>> C is a language family, like Lisp. Some people mean "Clojure"
>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
>
> Yes.

Examples of versions of the C family which have their own identities?

I think it's clear we're not talking about distinct languages like
Objective-C or C++.

If you're going to include those, then you're clutching at straws.

On 04/09/2023 14:54, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 04/09/2023 09:54, David Brown wrote:
>>> On 03/09/2023 19:11, Bart wrote:
>>
>>>> What's wrong with that?
>>> If you can live inside a bubble, and be happy with that, then I suppose
>>> that's fine.  However, you don't have the experience or understanding to
>>> criticise those outside the bubble.  You can live in your blissful
>>> ignorance if that's what suits you - but please understand that others do
>>> not want to be in your bubble.  It does not appeal at all to me. Your
>>> bubble tools and languages are of little use or interest to all but a
>>> very few other people.
>>
>> That may be so. But you can still learn things from them.
>
> I think I've asked before, but is there a language reference manual?

No.

In my case it's not worth doing. There was something a few years ago,
but it's out of date, is too long and needs a rewrite. Since the
expected audience is zero, it is not a priority.

The language is also volatile; it adapts to new hardware, and contains
many experimental features. If it was going to be used by others, it
would need to be more stable first.

However, the language has been self-hosted through various versions and
implementations in a continuous chain going back to the mid-eighties.
The first compiler of the chain would have been written in assembly.

So again, no; I'm keeping my languages private as support, even just
docs, is not viable. But people are welcome to benefit from any features
that come up in forums like these.

>> And yet, I can't get this program to compile when expressed in my langage:
>>
>> char* fred(void) {
>> (long long int)rand()*3.14159;
>> }
>>
>> int main(void) {
>> printf("%s\n", fred());
>> }
>
> C (as currently defined) has nothing to say about the behaviour of this
> program. That makes it trivial to implement an "equivalent" in almost
> any language. If your view of equivalent is the inclusive one, then any
> program at all will match the behaviour permitted for this one. And if
> your view of equivalent is quite narrow, then any text that has no
> defined meaning in the other language will do instead.

The equivalent program in my language is this:

func fred:ref char =
int(rand()*pi)
end

proc main=
println fred()
end

The language uses the value of the last statement or expression as the
return value in a function.

The error here is not a missing return (it is implicit), it is that the
value has the wrong type: int rather than 'ref char'.

This version:

func fred:ref char =
do end # (endless loop)
end

Shows the error "Void expression or return value missing". (A loop
statement has a 'void' type.)

To emulate the behaviour of the C, this used to do the trick, but the
current code generator has an issue with it that I need to fix:

func fred:ref char =
int(rand()*pi)
asm nop
end

(Inline assembly blocks are assumed to have set up a suitable value of
the right type.) However I'd only use assembly as a last resort,
preferably in an isolated module.

> I post this only to explain how I interpret the notion of "expressing" a
> program in another language. I am sure your view of the term is quite
> different.

Do you have your own examples in other languages which do the same:
return whatever garbage is in a register, since the language allows you
to omit an explicit value?

On 2023-09-04, Bart <bc@freeuk.com> wrote:
> On 04/09/2023 20:48, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> For a long while I went along with the idea that "C" can mean many
>>>> things, but that's not how Bart uses the term. In fact, that's one of
>>>> his big whinging topics -- C is what you care to make it. So I changed
>>>> my usage and posted the remark above. He found it worthy of mockery,
>>>> but did not want me to respond. Go figure.
>>>
>>> C is a language family, like Lisp. Some people mean "Clojure"
>>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
>>
>> Yes.
>
> Examples of versions of the C family which have their own identities?
>
> I think it's clear we're not talking about distinct languages like
> Objective-C or C++.

Mostly dialects.

> If you're going to include those, then you're clutching at straws.

There is no reason to exclude those. You can meaningfully write C
that also compiles as C++ or Objective C.

My TXR project is ostensibly written in C, but you can ./configure
cc=g++ and it works. I mostly don't work that way, but at least I check
it for regressions before releases. From time to time it catches
something.

Objective C is highly compatible with C due to introducing extensions
with @. GNU Awk does that (it has @include); it's still considered Awk.

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

David Brown <david.brown@hesbynett.no> writes:
> On 04/09/2023 12:06, Bart wrote:
[...]
>>   char* fred(void) {
>>       (long long int)rand()*3.14159;
>>   }
>>   int main(void) {
>>       printf("%s\n", fred());
>>   }
[...]
> As you know, it is not valid C code. As you know, proper C compilers
> will - at least - warn you about it when asked to treat the input
> according to the C standards. As you know, there isn't a compiler in
> the world for any language which will stop programmers from writing
> incorrect code.

Given the context of the discussion, pedantry seems appropriate.

It's invalid C code because it doesn't declare rand() and printf(),
correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
(It also contains NO-BREAK SPACE characters, but that's that's just a
Usenet formatting issue.)

Other than that, a conforming C compiler is not required to diagnose
the above code. It does have undefined behavior, and a C compiler is
likely to warn about it with appropriate warnings, but it does not
violate any syntax rule or constraint.

[...]

--
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 */

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> "C" does not mean "ISO C", unless the debate has been explicitly
> restricted that way.

I understand and respect your point of view, but I do not share it.

For me, "C" means "ISO C" unless otherwise specified, especially in the
context of this newsgroup.

"C" can also *informally* have a wider meaning. (English am confusing
sometimes.)

It doesn't hurt to say "ISO C" rather than "C" when the distinction is
important.

--
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 */

Bart <bc@freeuk.com> writes:
[...]
> All I know is that the family/dialect/standard in each case doesn't
> care amount making a missing 'return <value>' a hard error. So else
> are they being being lax over?

I have what I think is a very simple question for you. Will you
acknowledge that the ISO C standard does not require a diagnostic
for a missing return statement in a non-void function?

I'm asking you for nothing more than a "yes" or "no" answer. You can
of course follow that with anything you like, but a "yes" or "no"
would be helpful -- or a brief explanation of why you think neither
"yes" nor "no" is a meaningful answer.

[...]

> I think you guys just want to keep things a mystery!

If I had wanted to keep things a mystery, I wouldn't have spent
a great deal of time explaning things, even after it became clear
that my explanations were falling on deaf ears.

[...]

--
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 05/09/2023 00:04, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> All I know is that the family/dialect/standard in each case doesn't
>> care amount making a missing 'return <value>' a hard error. So else
>> are they being being lax over?
>
> I have what I think is a very simple question for you. Will you
> acknowledge that the ISO C standard does not require a diagnostic
> for a missing return statement in a non-void function?
>
> I'm asking you for nothing more than a "yes" or "no" answer. You can
> of course follow that with anything you like, but a "yes" or "no"
> would be helpful -- or a brief explanation of why you think neither
> "yes" nor "no" is a meaningful answer.
>
> [...]
>
>> I think you guys just want to keep things a mystery!
>
> If I had wanted to keep things a mystery, I wouldn't have spent
> a great deal of time explaning things, even after it became clear
> that my explanations were falling on deaf ears.

You may be right.

I think I've become over-saturated with talk of C versions and C
compilers (and non-compilers) and people's obsession with trying to
muddy things in order to trip me up.

You can imagine that recent discussions and newly discovered attitudes
have not done much for my appreciation of ... whatever the hell 'C'
actually is (right now I have no idea), and its whole ecosystem of
maybe-compilers and other tools.

I have had enough (I guess you all have too).

However there two tools I need to maintain for the time being:

* The revised backend of my C-subset compiler, which I'm doing largely
for my own satisfaction since I have my own standards to meet

* The transpiler necessary to turn that C-subset compiler, written in a
large subset of my language, into the same C-subset. If nothing else,
it will be able to at least self-host, sort of.

Then I can be free of all this nonsense! Back to sanity.

Bart <bc@freeuk.com> writes:
> On 05/09/2023 00:04, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> All I know is that the family/dialect/standard in each case doesn't
>>> care amount making a missing 'return <value>' a hard error. So else
>>> are they being being lax over?
>> I have what I think is a very simple question for you. Will you
>> acknowledge that the ISO C standard does not require a diagnostic
>> for a missing return statement in a non-void function?
>> I'm asking you for nothing more than a "yes" or "no" answer. You
>> can
>> of course follow that with anything you like, but a "yes" or "no"
>> would be helpful -- or a brief explanation of why you think neither
>> "yes" nor "no" is a meaningful answer.
>> [...]

I note your refusal to answer this simple question. I asked it
because I believe that any discussion of the merits or demerits of
either C or the ISO C standard should begin with an understanding
of what the standard says.

If you change your mind and decide to post a "yes" or "no" answer
(or an explanation of why neither answer would be meaningful),
I might be willing to continue the discussion.

If not, I am done with you, and barring unforeseen circumstances
this will be my last reply to anything you write here, except that
I *might* reply to misstatements of fact that I think are likely to
mislead others. (In the unlikely event that you wish to contact me,
the email address on this post is valid and will reach me.)

Others will do as they see fit. I'm sure many people here will be
relieved if I stop engaging with you.

[...]

> I think I've become over-saturated with talk of C versions and C
> compilers (and non-compilers) and people's obsession with trying to
> muddy things in order to trip me up.

Nobody has done that.

> You can imagine that recent discussions and newly discovered attitudes
> have not done much for my appreciation of ... whatever the hell 'C'
> actually is (right now I have no idea), and its whole ecosystem of
> maybe-compilers and other tools.

One person has expressed the opinion that "C" doesn't mean "ISO C".
You've probably seen my reply, so I won't repeat it here. If one
person expressing an opinion causes you such confusion, I can't
help you.

[...]

--
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 */

Bart <bc@freeuk.com> writes:

> On 04/09/2023 14:54, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 04/09/2023 09:54, David Brown wrote:
>>>> On 03/09/2023 19:11, Bart wrote:
>>>
>>>>> What's wrong with that?
>>>> If you can live inside a bubble, and be happy with that, then I suppose
>>>> that's fine.  However, you don't have the experience or understanding to
>>>> criticise those outside the bubble.  You can live in your blissful
>>>> ignorance if that's what suits you - but please understand that others do
>>>> not want to be in your bubble.  It does not appeal at all to me. Your
>>>> bubble tools and languages are of little use or interest to all but a
>>>> very few other people.
>>>
>>> That may be so. But you can still learn things from them.
>> I think I've asked before, but is there a language reference manual?
>
> No.

Then no significant learning can happen.

>>> And yet, I can't get this program to compile when expressed in my langage:
>>>
>>> char* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>>
>>> int main(void) {
>>> printf("%s\n", fred());
>>> }
>> C (as currently defined) has nothing to say about the behaviour of this
>> program. That makes it trivial to implement an "equivalent" in almost
>> any language. If your view of equivalent is the inclusive one, then any
>> program at all will match the behaviour permitted for this one. And if
>> your view of equivalent is quite narrow, then any text that has no
>> defined meaning in the other language will do instead.
>
> The equivalent program in my language is this:

As I said. It's trivial since the C program has no defined meaning.

>> I post this only to explain how I interpret the notion of "expressing" a
>> program in another language. I am sure your view of the term is quite
>> different.
>
> Do you have your own examples in other languages which do the same: return
> whatever garbage is in a register, since the language allows you to omit an
> explicit value?

If "the language" is C, then it does not allow any such thing. And the
program you posted does not "do" anything. It is as meaningless and any
and all other undefined C programs.

--
Ben.