From: cr88192@gmail.com
On 10/9/2025 10:59 PM, Keith Thompson wrote:
> bart writes:
>> On 09/10/2025 04:49, BGB wrote:
> [...]
>
>> Nobody cares about C syntax.
>
> That is so manifestly untrue that I can't imagine what you actually
> meant.
>
> Many of us, myself included, don't particularly like some aspects of C
> syntax, but that's not the same as not caring about it.
>
Yes.
>> Learning all its ins and outs seems be a
>> rite of passage.
>
> Perhaps. It's also necessary if you want to work with the language.
>
>> The trouble is that C-style is so dominant, few people would know what
>> a decent syntax looks like. Or, more, likely, they associate a clean,
>> well-designed syntax with toy or scripting languages, and can't take
>> it seriously.
>>
>> But if it looks as hairy as C++ then it must be the business!
>
> C syntax has survived and been propagated to other languages because
> it's well known, not, I think, because anybody really likes it.
>
I would gladly pick C style syntax over PASCAL, FORTRAN, or COBOL.
> [...]
>
>>> One merit is if code can be copy-pasted, but if one has to change
>>> all instances of:
>>> char *s0, *s1;
>>> To:
>>> char* s0, s1;
>>> Well, this is likely to get old, unless it still uses, or allows C
>>> style declaration syntax in this case.
>>
>> That one's been fixed (50 years late): you instead write:
>>
>> typeof(char*) s0, s1;
>>
>> But you will need an extension if it's not part of C23.
>
> Yes, that will work in C23, but it would never occur to me to
> write that. I'd just write `char *s0, *s1;` or, far more likely,
> define s0 and s1 on separate lines. Using typeof that way triggers
> my WTF filter.
>
Agreed.
I think it can be contrast with C# style syntax (with "unsafe") where
one would write:
char* s0, s1;
Though, imagining a world where probably char is an unsigned byte, so
that UTF-8 makes sense.
So, say, if we had types (for a hypothetical language) like:
sbyte, ubyte: 8-bits, signed/unsigned
byte: 8-bits, probably unsigned
char: 8-bits, probably unsigned (UTF-8)
wchar: 16-bits, unsigned (UTF-16)
short: 16-bits, signed
ushort: 16-bits, unsigned
int: 32-bits, signed
uint: 32-bits, unsigned
long: 64-bits, signed
ulong: 64-bits, unsigned
Maybe some more, but with explicit bit sizes.
int8/int16/int32/int64/int128
uint8/uint16/uint32/uint64/uint128
But, no separate "unsigned".
Core type name is always a single identifier, unlike C.
And, special types:
string: String, UTF-8
wstring: String, UTF-16
...
While a string is (effectively) a pointer to the first character, the
type can be seen as distinct from that of 'char*'. Nominal
representation would be as a series of codepoints terminated with a NUL
byte.
Default string type can be UTF-8 because, most of the time, UTF-16 would
be a waste of memory (but, can be kept for "those that have that
preference").
And, floating point:
float: Binary32
double: Binary64
half: Binary16
Maybe explicit sized names:
float16/float32/float64/float128
Maybe vectors (optional):
vec2f 2x float
vec4f 4x float
vec4h 4x half
vec2d 2x double
quatf quaternion (float)
quath quaternion (half)
Untyped bit-blobs:
m8, m16, m32, m64, m128
Say:
ulong li;
double f;
li=(m64)f; //cast double->ulong as bit pattern
f=(m64)li; //cast ulong->double as bit pattern
With basic decl syntax like:
int i; //normal variable
int[16] ia; //fixed array (inline)
int* pi; //pointer
int[] ia2; //flexible array (reference, hosted only)
int*[16] pia; //fixed array of pointers
This would apply to primitive types and structs.
Object types having different suffixes (hosted only):
Foo obj1; //basic object
Foo! obj2; //automatic
Foo^ obj3; //refcount
Foo(Z) obj4; //zone
Foo[] aobj1; //flexible array of Foo
Foo[16] aobj2; //fixed array of Foo
...
Where, struct and class implicitly declare type, so:
struct Str1 {
int x, y;
}
class Foo:Bar { //class Foo, extends Bar
...
}
interface IBaz { //interface
...
}
Where, likely flexible arrays, classes, and interfaces, only exist:
If the implementation is hosted;
If a non-hosted implementation provides a full memory manager.
Would eliminate some more obscure patterns from C syntax, like:
int (*arr[16])[16]; //like, WUT?...
Just sorta say, stuff like this doesn't exist.
Might consider doing function pointers like:
delegate void FuncT();
...
FuncT fun;
Well, in contrast to some of my own languages which had used
typedef void FuncT();
For this, and 'delegate' as a scope modifier (where identifier lookups
may look into the variable). But, nothing stops using delegate for both
purposes (based on whether it is followed by a prototype or object
variable declaration).
Scoping could look like:
global top-level (behaves like C top-level);
namespaces.
Probably, things like function overloading are only allows inside
classes or namespaces. At the global toplevel, no overloading is allowed
(so, it is like C++ 'extern "C"' by default).
So, say:
namespace foo {
using c.stdio;
//why not?...
int func(int x, int y)
{
printf("yeah...\n"); //via stdio
return x+y;
}
}
Where, say, we don't need a bunch of wrapper classes for file IO and
printing, because C's "stdio.h" already does this.
Here, there can be some magic behind the scenes, where the compiler can
use namespaces and metadata rather than bulk textual inclusion.
One option is that when the compiler compiles stuff, like the runtime
library, it also generates "manifests" that the compiler can use to find
declarations. Likely, the manifest files could exist like a sort of
hierarchical database partly mapped onto a virtual filesystem, with
search paths and similar (sorta like the class path in the JVM). Just,
this metadata will only exist for compiling stuff.
Why not textual inclusion?: Because it wastes a lot of CPU time and RAM
to generate and parse a mountain of random stuff for every translation
unit (the amount of text pulled in from headers is typically several
orders of magnitude larger than the actual code for the translation unit
itself). Also precompiled headers are a poor solution to this.
May or may not do varargs differently.
One possible interpretation could be, say:
void vafunc(char* s, va...)
{
char* s1;
long x, y;
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
