On 06/01/2024 13:53, Bart wrote:
> On 06/01/2024 09:09, David Brown wrote:
>> On 05/01/2024 23:19, Bart wrote:
>>> On 05/01/2024 14:05, David Brown wrote:
>>>> On 05/01/2024 02:53, Bart wrote:
>>>
>>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>>
>>>>
>>>> One option for a useful array length operator/function/macro is a
>>>> simple and limited feature that works for arrays of known size and
>>>> gives a hard (compile-time) error when the size is not known.  The
>>>> one you have in your own language covers most of that, except for
>>>> the insanity of evaluating to 0 when given a pointer/reference to an
>>>> "unbounded" array.
>>>
>>> It gives zero because that is actually the compile-time type of the
>>> array. But it is low priority because it is never used that way.
>>>
>>
>> That's the kind of potentially confusing short-cut you can make when
>> only you ever use the language.
>
> I spent 10 mins trying to fix this today. So that '.len' on bounds
> specified as `[]` rather than `[0]`, and not later set by init data,
> would be an error.
>
> Then I got stuck on examples like '[]int a = ()' and realised it's
> tricky. And then I thought, why the hell am I doing this? A language
> I've already used for a million lines of code.
>

I have no idea why you are doing this. I have no idea why you thought
it was a good idea to make your own personal language and write a
million lines that no one can ever use again, or work with, change,
re-use, maintain or update. I have no idea why you hate C, why you
obsess about a language you hate and why you rave about your language
that no one else uses and no one else cares about in a newsgroup for C.
I have no idea why you continue to think that your language is God's
gift to programming and that everyone else, the world over, is crazy to
imagine there are any reasons to do something differently from the way
you do things in your language.

Yes, "why?" is a good question.

On 1/6/24 9:28 AM, David Brown wrote:
>
> I have no idea why you are doing this.  I have no idea why you thought
> it was a good idea to make your own personal language and write a
> million lines that no one can ever use again, or work with, change,
> re-use, maintain or update.  I have no idea why you hate C, why you
> obsess about a language you hate and why you rave about your language
> that no one else uses and no one else cares about in a newsgroup for C.
> I have no idea why you continue to think that your language is God's
> gift to programming and that everyone else, the world over, is crazy to
> imagine there are any reasons to do something differently from the way
> you do things in your language.
>
> Yes, "why?" is a good question.
>

I think the big reason for his "Why?" is that he KNOWS that his language
isn't sufficient, but will need to interface to things that others have
done, and those will invariably be written in C.

His complaint is that while C has become the common-tounge for
inter-language linkage, it really isn't designed for that.

The "shims" to perform this tend to need some part of it to be written in C.

On 06/01/2024 14:28, David Brown wrote:
> On 06/01/2024 13:53, Bart wrote:
>> On 06/01/2024 09:09, David Brown wrote:
>>> On 05/01/2024 23:19, Bart wrote:
>>>> On 05/01/2024 14:05, David Brown wrote:
>>>>> On 05/01/2024 02:53, Bart wrote:
>>>>
>>>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>>>
>>>>>
>>>>> One option for a useful array length operator/function/macro is a
>>>>> simple and limited feature that works for arrays of known size and
>>>>> gives a hard (compile-time) error when the size is not known.  The
>>>>> one you have in your own language covers most of that, except for
>>>>> the insanity of evaluating to 0 when given a pointer/reference to
>>>>> an "unbounded" array.
>>>>
>>>> It gives zero because that is actually the compile-time type of the
>>>> array. But it is low priority because it is never used that way.
>>>>
>>>
>>> That's the kind of potentially confusing short-cut you can make when
>>> only you ever use the language.
>>
>> I spent 10 mins trying to fix this today. So that '.len' on bounds
>> specified as `[]` rather than `[0]`, and not later set by init data,
>> would be an error.
>>
>> Then I got stuck on examples like '[]int a = ()' and realised it's
>> tricky. And then I thought, why the hell am I doing this? A language
>> I've already used for a million lines of code.
>>
>
> I have no idea why you are doing this.  I have no idea why you thought
> it was a good idea to make your own personal language and write a
> million lines that no one can ever use again, or work with, change,
> re-use, maintain or update.

It started as an in-house language. It was used for real work, real
programs. The products I made with it generated some $1m a year of
business and created work for quite a few people. 1000s of customers
benefited from those products for their own endeavours. And I managed to
retire at age 42.

Those are some reasons.

>  I have no idea why you hate C, why you
> obsess about a language you hate and why you rave about your language
> that no one else uses and no one else cares about in a newsgroup for C.
> I have no idea why you continue to think that your language is God's
> gift to programming and that everyone else, the world over, is crazy to
> imagine there are any reasons to do something differently from the way
> you do things in your language.
>
> Yes, "why?" is a good question.

Why? You pick on some relatively minor issue in my language, of which C
has in spades.

I list some aspects of working with arrays which I do better than C, to
put into perspective why I considered that low priority.

And you choose to go on the attack.

That no one uses my language is irrelevant. The ideas would stand by
themselves, even if never implemented. But being used in a real, proven
product should lend more credence. Be funny if you took vapourware more
seriously.

Where are the systems languages from 70s/80s that did it properly? There
aren't any; Unix put paid to that by inflicting its shitty language on
everybody and everything.

I picked on the sizeof thing for arrays as a simple example of C's
macros used to paper over deficiences in the core language. You and
others say it's no big deal.

Well, dozens of other languages do do it properly, eg. using len(A), not
just mine. Mine just demonstrates its use in a language of similar level
and scale.

I think you're just cross that my table wipes the floor with C and so
want to piss all over my own efforts.

--------
BTW here is my original comment about sizeof/sizeof:

BC to DB:

You missed my point. Take a tiny feature like being able to easily get
the size of a fixed-length array. You commonly see macro like this:

#define LENGTH(a) (sizeof(a)/size(a[0]))

What incentive is there to properly add a built-in way to do that, when
it can be done, badly, and in 1000 different ways by each user, in a
one-line macro?

Another example is GETBIT(a, n).

--------

It's a good job I went with LENGTH and not GETBIT. I use as A.[n] for
both GETBIT and SETBIT, and you would have gotten even angrier. How dare
somebody not only come up with some decent ideas for a systems language,
but who actually has the gall to go and implement them.

You are welcome to 'A.[i]'; I think it would have been a far more
interesting addition to new C that whatever it was that did go in. And
easy to implement to boot; with I believe no clashes with current syntax.

On 06/01/2024 14:56, Richard Damon wrote:
> On 1/6/24 9:28 AM, David Brown wrote:
>>
>> I have no idea why you are doing this.  I have no idea why you thought
>> it was a good idea to make your own personal language and write a
>> million lines that no one can ever use again, or work with, change,
>> re-use, maintain or update.  I have no idea why you hate C, why you
>> obsess about a language you hate and why you rave about your language
>> that no one else uses and no one else cares about in a newsgroup for
>> C. I have no idea why you continue to think that your language is
>> God's gift to programming and that everyone else, the world over, is
>> crazy to imagine there are any reasons to do something differently
>> from the way you do things in your language.
>>
>> Yes, "why?" is a good question.
>>
>
> I think the big reason for his "Why?" is that he KNOWS that his language
> isn't sufficient, but will need to interface to things that others have
> done,

I used it for at least 10 years without needing to interface to
anything. After that I needed to use OS and other libraries.

and those will invariably be written in C.
>
> His complaint is that while C has become the common-tounge for
> inter-language linkage, it really isn't designed for that.

The inter-language ABI is based on sets of MACHINE types such: u8-u64,
i8-i64, f32-f64, plus pointers and aggregate types. Those are common to
many languages, not just C, which tend to have far more sensible and
stable ways to denote such types.

That is what my FFIs use too. At this point C doesn't enter into it.

But it is true that many APIs (not ABIs) are defined in C terms or as C
headers. And in the latter, yes C's types could be better. And often,
some other aspects of C such as macros, which can include arbitrary C
code, can be exposed.

Bart <bc@freeuk.cm> writes:
[...]
> The concept is not that easy to get your head around either, the idea
> that the variable aspects of a VLA are associated with its type, not
> its value or instance.

Oh? I don't find it difficult at all. It's the kind of thing you learn
once, and then you know it. Now you know it, but you're still
complaining for some reason.

There are some complications regarding applying sizeof to a VLA type or
expression. I've cited a proposal to clean that up in a future
standard. The complications rarely affect non-contrived code.

> In my example, there were no instances of any actual arrays, not even
> if I declared an instance of one of the pointers involved, yet space
> had to be allocated for its size. And I kept the type simple.

Sure, space is allocated for the type's size. That space is implicit,
and is logically associated with the type. That seems straightforward
to me. (In fact the standard doesn't say how the size is stored, but
creating and initializing an implicit object associated with the type is
the obvious approach.)

> I remember also trying out VLAs within a struct, and there I got a
> wider variance of results.

The language does not allow VLAs within a struct; see N1570 6.7.2.1p9.
Some compilers support them as an extension. As usual, you do your
testing with a variety of *non-conforming* compilers and reach
conclusions about how inconsistent the language itself appears to be.

Most C compilers have options to tell them to attempt to conform to a
specified edition of the standard (e.g., `gcc -std=c17 -pedantic` or
`gcc -std=c17 -pedantic-errors`). I strongly suggest using those
options if you're trying to learn something about the language itself.
It will save you (and us) a lot of time.

And please don't pretend that I've said that it's a good thing that most
C compilers are non-conforming by default, and that it's (slightly)
difficult to get them to attempt to conform. I'm describing how they
work, not expressing an opinion.

> You can keep saying that VLAs are trivial to understand and implement;
> I won't believe you.

I don't recall anyone saying they're trivial. Apparently you have
trouble understanding them. Feel free to ask questions. They're not as
difficult as you want to believe them to be.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 6 Jan 2024 09:56:05 -0500, Richard Damon wrote:

> His complaint is that while C has become the common-tounge for
> inter-language linkage, it really isn't designed for that.
>
> The "shims" to perform this tend to need some part of it to be written
> in C.

There is a thing called libffi, which is commonly used by many high-level
languages to interface to C code (or to code that assumes that it is being
called from C code). This is the basis of the ctypes module in the
standard Python library, for example.

I have successfully used ctypes to produce “Pythonic” wrappers for several
useful facilities (e.g. Cairo graphics, D-Bus, inotify). By “Pythonic” I
mean that they try to look as though the underlying facility was designed
to be used from Python.

On Sat, 6 Jan 2024 15:57:00 +0000, Bart wrote:

> But it is true that many APIs (not ABIs) are defined in C terms or as C
> headers.

I wish they would be more consistent about that. It has been about a
quarter century since C99 introduced stdbool, yet you still see rigmarole
like (from /usr/include/SDL2/SDL_egl.h):

typedef enum {
KHRONOS_FALSE = 0,
KHRONOS_TRUE = 1,
KHRONOS_BOOLEAN_ENUM_FORCE_SIZE = KHRONOS_MAX_ENUM
} khronos_boolean_enum_t;

On 06/01/2024 21:40, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
> [...]
>> The concept is not that easy to get your head around either, the idea
>> that the variable aspects of a VLA are associated with its type, not
>> its value or instance.
>
> Oh? I don't find it difficult at all. It's the kind of thing you learn
> once, and then you know it. Now you know it, but you're still
> complaining for some reason.

Maybe you've never had to implement it. It is certainly not intuitive:

int n=rand();

typedef int T[n]; // here the size is stored with the type

int A[n]; // here you'd expect it with each variable
int B[n];
T C[n]; // and here in both

You might also expect the data of those variables to go on the stack.
But here:

T** P;

it presumably goes on the heap, when you get around to allocating it.

Despite all the complexity associated with VLAs (for example managing 17
active VLA allocations on the stack, and assorted VLA typedefs that are
now executable code) as you goto in and out of nested block scopes),
when you pass a VLA 'A' for example to a function, you still have to
supply the size or length separately.

With the far simpler slice mechanism that I mentioned several posts
back, that includes the length.

The reason I brought up VLAs at all was because the language skipped a
simple-to-implement and potentially more useful feature, for a much
harder one.

If I was to independently add a VLA-like feature to C, I would base it
on slices. And I would allow them only at the top level of data
structures, not nested, nor within conventional arrays, nor as a pointer
target (if the memory management is to be automatic).

They would also use heap storage not stack. And there would no dynamic
elements within typedefs; the actual size is an attribute of the
variable instance. Typedefs stay a purely compile-time artefact.

That would cover 99% of the ways that VLAs are typically used, of which
I believe a big chunk are inadvertent.

On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:

> typedef int T[n]; // here the size is stored with the type
>
> int A[n]; // here you'd expect it with each variable int
> B[n];
> T C[n]; // and here in both

The array size is in the wrong place. Java at least puts it in a more
natural place:

int[n] A;
... etc ...

though unfortunately it forgets to include typedefs.

Type specifications in C are all backwards, anyway. They should have
adopted the Pascal syntax for that.

On 06/01/2024 23:45, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 09:56:05 -0500, Richard Damon wrote:
>
>> His complaint is that while C has become the common-tounge for
>> inter-language linkage, it really isn't designed for that.
>>
>> The "shims" to perform this tend to need some part of it to be written
>> in C.
>
> There is a thing called libffi, which is commonly used by many high-level
> languages to interface to C code (or to code that assumes that it is being
> called from C code). This is the basis of the ctypes module in the
> standard Python library, for example.
>
> I have successfully used ctypes to produce “Pythonic” wrappers for several
> useful facilities (e.g. Cairo graphics, D-Bus, inotify). By “Pythonic” I
> mean that they try to look as though the underlying facility was designed
> to be used from Python.

LIBFFI solves a different problem, which is that of synthesising
function calls at runtime, given a function name as a string, and a
sequence of N arguments as assorted types.

Typically used in interpreted code.

Native code calling native code across languages generally doesn't need
that. It needs that information about the 1000s of different functions,
types, and enums that are used in an API, in a set of bindings suitable
for use in the calling language.

LIBFFI doesn't help here; you still need that info whether making a
statically compiled call or a dynamically synthesised one.

(When you do need something like LIBFFI, then it is another of those
hard-to-build C libraries.

I generally don't bother with it. I use a 60-line solution of my own
which cheats by using inline assembly. A lot less hassle, but it is
specific to each target.)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
>
>> typedef int T[n]; // here the size is stored with the type
>>
>> int A[n]; // here you'd expect it with each variable int
>> B[n];
>> T C[n]; // and here in both
>
> The array size is in the wrong place. Java at least puts it in a more
> natural place:
>
> int[n] A;
> ... etc ...
>
> though unfortunately it forgets to include typedefs.
>
> Type specifications in C are all backwards, anyway. They should have
> adopted the Pascal syntax for that.

C uses a "declaration follows usage" rule (though not with 100%
consistency).

For example, a declaration like:

int *foo[42];

ultimately means "declare foo as array 42 of int" (that's what the
"cdecl" program tells you), but you can think of it as declaration that
the expression `*foo[42]` is of type int. It follows from that that
`foo[42]` is of type int*, and that `foo` is of type int *[42], or
pointer to array 42 of int.

Recall that I mentioned that it's not 100% consistent. foo[42] doesn't
exist (valid indices are 0 to 41), but the point is that it would have
type int* if it existed.

See question 1.21 of the comp.lang.c FAQ, <https://www.c-faq.com/>.

I personally agree with you that C would have been easier with a
different declaration syntax, closer to the way you'd describe it in
English, but it will never be changed in any language named "C", so
there's not much point in worrying about it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sun, 7 Jan 2024 00:21:00 +0000, Bart wrote:

> (When you do need something like LIBFFI, then it is another of those
> hard-to-build C libraries.

sudo apt-get install libffi-dev

does it for me.

If you want to learn how to build things from source, maybe look at how a
source-based distro like Gentoo does it? They provide scripts to do
automatically what you struggle to manage with your human brain. Maybe too
much exposure to Microsoft Windows?

On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:

> C uses a "declaration follows usage" rule (though not with 100%
> consistency).

And putting the function result before the argument types turns out to
cause trouble when carried over to C++, when you try to express
dependencies between them. So they had to add a Pascal-style alternative
syntax, with the function result declared after the arguments.

Even pointer dereferencing should have been done with a postfix, not a
prefix operator. Consider why you need “->”: it’s purely syntactic sugar
to make things like

(*a).b

less awkward as

a->b

Whereas in Pascal, for example, there is no need for any alternative
syntax to

a^.b

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Bart <bc@freeuk.cm> writes:
>> On 05/01/2024 22:50, Keith Thompson wrote:
>>> Bart <bc@freeuk.cm> writes:
>>>> On 05/01/2024 18:44, Scott Lurndal wrote:
>>> [...]
>>>>> There are thousands of ways programmers can introduce
>>>>> bugs far more easily which are significantly harder
>>>>> to find and fix; and yes, I expect programmers to
>>>>> fully understand the code they're writing and test
>>>>> their code to find bugs which they then will subsequently
>>>>> fix.
>>>>> Do lookup the word 'strawman' as it relates to discourse.
>>>>
>>>> And yet, despite it having no problems according to you, people still
>>>> feel the need to create macros like ARRAY_SIZE.
>>> Yes. That's how they use the idiom.
>>>
>>>> So I'm puzzled. Why do they do that? What imaginary problem (according
>>>> to you) do they solve?
>>> I don't know what you're puzzled about.
>>
>> I'm puzzled because people like Scott are suggesting those macros are
>> a waste of time, and yet you find them in big, important software.
>
>Oh, so *that's* what you're complaining about.
>
>I just took a look at Scott's article to which you replied, and its
>parent, and so on all the way to the first article in this thread.
>Nowhere did Scott suggest that those macros are a waste of time.
>
>He did write some things that suggest that he considers the
>`sizeof arr / sizeof arr[0]` idiom clear enough to be written directly
>as part of an expression rather than as a macro (and I agree), but I
>didn't see him objecting to the idea of using a macro.

Correct.

>
>I can't speak for him, but I think he was objecting to your insistence
>that using the idiom directly is unacceptable, and you interpreted that
>as him insisting that wrapping the idiom in a macro is useless. He
>didn't say that.

Correct.

>
>I'm making an assumption here, that you find code that uses the idiom
>directly more objectionable than code that wraps it in a macro.
>
>Personally, I'd be likely to define a macro if I'm going to be using it
>multiple times. In an example I mentioned recently, where I modified
>some existing code to use `sizeof array / sizeof array[0]`, I was only
>doing it once, so just wrote the expression directly. Either method is
>fine with me, and I suspect Scott would agree.

Indeed. I do believe that absent standardization, using a macro
adds a level of indirection that may adversely affect the code
readability (whether it is ARRAY_SIZE, ARRAY_LENGTH, LENGTH, NUM_ELEMENTS,
or whatever, I would need to refer to the macro definition to
determine the intent of the programmer).

If syntax was added to the language standard that provided
similar functionality, I'd certainly use it.

On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
>
>> typedef int T[n]; // here the size is stored with the type
>>
>> int A[n]; // here you'd expect it with each variable int
>> B[n];
>> T C[n]; // and here in both
>
> The array size is in the wrong place.

You mean that the poster has a misconception about the declaration
mapping to the actual formal semantics? (That might at least explain
why he's confused by the C way.)

> Java at least puts it in a more natural place:
>
> int[n] A;
> ... etc ...

Or Algol(68) that I upthread mentioned for its formal sophistication

[n] int A;

>
> though unfortunately it forgets to include typedefs.

where Algol has 'mode' declarations for types

mode intarr = [n] int A;

>
> Type specifications in C are all backwards, anyway. They should have
> adopted the Pascal syntax for that.

Or any other [more] coherent language already existing at that time.

Janis

Bart <bc@freeuk.cm> writes:
> On 06/01/2024 21:40, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>> [...]
>>> The concept is not that easy to get your head around either, the idea
>>> that the variable aspects of a VLA are associated with its type, not
>>> its value or instance.
>> Oh? I don't find it difficult at all. It's the kind of thing you
>> learn
>> once, and then you know it. Now you know it, but you're still
>> complaining for some reason.
>
> Maybe you've never had to implement it. It is certainly not intuitive:

No, I haven't. I worked on compilers in the distant past (for Ada,
which doesn't distinguish on the language level between array with
constant and non-constant bounds), but I haven't implemented VLAs for C.

We were talking about the fact that, as you say, "variable aspects of a
VLA are associated with its type, not its value or instance". Are you
saying that makes implementing it unreasonably difficult?

> int n=rand();
>
> typedef int T[n]; // here the size is stored with the type

Yes, of course it is. And keep in mind that typedef doesn't create a
new type. A compiler will create, at compile time, some internal node
(or whatever data structure it uses) representing the anonymous type
`int[n]`, and will associate an implicitly created automatic object with
it to hold its length or size. It will then create a node representing
the typedef T, referring to the anonymous array type.

> int A[n]; // here you'd expect it with each variable

Why would you expect that?

I'd expect a compiler to create an internal node representing an
anonymous type int[n], and another representing an object A of that
type. The size information is associated with the type.

Since there's just one object of that type, *maybe* a compiler could
associate the size information with the variable, but I don't see the
point of doing so.

> int B[n];

Same thing again. The int[n] for A and the int[n] for B are distinct
but compatible types. (If the value of n changed between the two
declarations, the types would be distinct and incompatible.)

> T C[n]; // and here in both

n is evaluated again and stored somewhere.

> You might also expect the data of those variables to go on the
> stack.

Of course. Everything so far is defined at block scope (VLAs at file
scope are not allowed) and so has automatic static duration.
Informally, its allocated on the stack.

> But here:
>
> T** P;
>
> it presumably goes on the heap, when you get around to allocating it.

If you allocate using malloc(), of course it goes on the heap. There's
no implicit heap allocation. P itself is on the stack. Whatever P
points to is allocated where *you* choose to allocate it.

Is any of this surprising?

> Despite all the complexity associated with VLAs (for example managing
> 17 active VLA allocations on the stack, and assorted VLA typedefs that
> are now executable code) as you goto in and out of nested block
> scopes), when you pass a VLA 'A' for example to a function, you still
> have to supply the size or length separately.

Sure.

> With the far simpler slice mechanism that I mentioned several posts
> back, that includes the length.

Good for you. C doesn't have slices. Should it have them? Maybe, I
don't know. As I've discussed here recently, adding features to C is
genuinely difficult.

And if you have std::vector you don't need VLAs or slices. If you use a
language other than C, you can avoid C's limitations.

But remind me, this is comp.lang.what?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 07/01/2024 00:55, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 00:21:00 +0000, Bart wrote:
>
>> (When you do need something like LIBFFI, then it is another of those
>> hard-to-build C libraries.
>
> sudo apt-get install libffi-dev
>
> does it for me.

And then what? LIBFFI is still hard to use.

Bear in mind I would need to call LIBFFI itself across an FFI. Even if
it worked beautifully, it's a horrible dependency with the usual ghastly
build methods that require either Linux or MSVC, from what I can see.

Why, for a specific platform, can I not just get one .c and/or
one .s file to do the job?

Unlike the algorithms behind GMP, this is a task I do understand!

Below is the 60-line solution I mentioned. The function has already been
located so that a reference to it is passed.

(There is also a HLL-only version, including one in C, but it has many
restrictions.)

> If you want to learn how to build things from source, maybe look at how a
> source-based distro like Gentoo does it?

> They provide scripts to do
> automatically what you struggle to manage with your human brain. Maybe too
> much exposure to Microsoft Windows?

I can build ALL my projects using an invocation like:

mm prog

Most build in 1/10th of a second. I'm struggling to see how it can get
any simpler or faster!

This is what I do. I tried to do it with my C compiler, but the language
puts some difficulties there, so that might be more like:

mcc @prog

Still only a compiler and the source files plus this auxiliary file.

--------------------------------------
--------------------------------------
Core of 'libffi' solution for x64/Win64ABI
Not in C code.
--------------------------------------

export func os_calldllfunction(
ref proc fnaddr,
int retcode, nargs,
ref[]i64 args,
ref[]byte argcodes)u64 =

u64 a
r64 x
int nextra, pushedbytes

nextra:=0

!The stack is 16-byte aligned at this point

if nargs<4 then
nextra:=4-nargs !need at least 4 slots for shadow space
elsif nargs.odd then !need one more for a 16-byte-aligned stack
nextra:=1
fi

pushedbytes:=(nextra+nargs)*8

to nextra do
asm push 0
od

for i:=nargs downto 1 do
a:=args[i] !get generic 64-bit value to push
asm push u64 [a]
od

!blindly load first 4 args (incl unused) to both int/float regs
!(both must be loaded when calling variadic functions)

assem
mov D10,[Dstack]
movq XMM0,[Dstack]
mov D11,[Dstack+8]
movq XMM1,[Dstack+8]
mov D12,[Dstack+16]
movq XMM2,[Dstack+16]
mov D13,[Dstack+24]
movq XMM3,[Dstack+24]
end

if retcode='I' then
a:=((ref func:i64(fnaddr))^())
asm add Dstack, [pushedbytes]
return a

else
x:=((ref func:r64(fnaddr))^())
asm add Dstack, [pushedbytes]
return u64@(x) ! (type-punning cast)

fi
end

On 07/01/2024 01:12, Janis Papanagnou wrote:
> On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
>> On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
>>
>>> typedef int T[n]; // here the size is stored with the type
>>>
>>> int A[n]; // here you'd expect it with each variable int
>>> B[n];
>>> T C[n]; // and here in both
>>
>> The array size is in the wrong place.
>
> You mean that the poster has a misconception about the declaration
> mapping to the actual formal semantics? (That might at least explain
> why he's confused by the C way.)

There was nothing wrong with the C code. (The quote has garbled the
'int' belong to B.)

LD'O is saying the C syntax puts it in the wrong place.

>> Java at least puts it in a more natural place:
>>
>> int[n] A;
>> ... etc ...
>
> Or Algol(68) that I upthread mentioned for its formal sophistication
>
> [n] int A;
>
>>
>> though unfortunately it forgets to include typedefs.
>
> where Algol has 'mode' declarations for types
>
> mode intarr = [n] int A;

Interesting. My syntax uses:

[n]int A
type intarr = [n]int A

But then it came from Algol 68 in the first place. However, that
language also got some things wrong. Eg. your example might be written
as '[n]INT a;' due to 'stropping'.

Notice my version uses a single case, and there are no semicolons. The
Algol68 rules for semicolons, which separate statements not terminate,
are a complete PITA.

You spend half your time special-casing the last statement in a block,
as that's the one without the semicolon - until you insert, delete,
move, comment or uncomment lines, then you have to fix it.

On 07/01/2024 01:45, Bart wrote:
> On 07/01/2024 01:12, Janis Papanagnou wrote:
>> On 07.01.2024 01:16, Lawrence D'Oliveiro wrote:
>>> On Sun, 7 Jan 2024 00:09:11 +0000, Bart wrote:
>>>
>>>>       typedef int T[n];   // here the size is stored with the type
>>>>
>>>>       int A[n];           // here you'd expect it with each variable
>>>> int
>>>>       B[n];
>>>>       T C[n];             // and here in both
>>>
>>> The array size is in the wrong place.
>>
>> You mean that the poster has a misconception about the declaration
>> mapping to the actual formal semantics? (That might at least explain
>> why he's confused by the C way.)
>
> There was nothing wrong with the C code. (The quote has garbled the
> 'int' belong to B.)
>
> LD'O is saying the C syntax puts it in the wrong place.
>
>>> Java at least puts it in a more natural place:
>>>
>>>      int[n] A;
>>>      ... etc ...
>>
>> Or Algol(68) that I upthread mentioned for its formal sophistication
>>
>>      [n] int A;
>>
>>>
>>> though unfortunately it forgets to include typedefs.
>>
>> where Algol has 'mode' declarations for types
>>
>>      mode intarr = [n] int A;
>
> Interesting. My syntax uses:
>
>    [n]int A
>    type intarr = [n]int A

I was blindly copying your example. There is no 'A' in the type
definition, it is just:

type intarr = [n]int

On Sun, 7 Jan 2024 01:26:29 +0000, Bart wrote:

> And then what? LIBFFI is still hard to use.

Using Python’s ctypes module, which is basically built on top of libffi, I
have not found to be that hard at all.

Looking at the sizes of those particular Python wrappers I mentioned:

Cairo graphics <https://gitlab.com/ldo/qahirah> -- 8500 lines
D-bus <https://gitlab.com/ldo/dbussy/> -- 11,000 lines
inotify <https://gitlab.com/ldo/inotipy> -- under 600 lines

On Sun, 7 Jan 2024 02:12:03 +0100, Janis Papanagnou wrote:

> Or Algol(68) that I upthread mentioned for its formal sophistication
>
> [n] int A;

And for added fun, the distinction between

[m, n] INT

and

[m][n] INT

(using capitalization to indicate bold)

On 07/01/2024 01:15, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> On 06/01/2024 21:40, Keith Thompson wrote:
>>> Bart <bc@freeuk.cm> writes:
>>> [...]
>>>> The concept is not that easy to get your head around either, the idea
>>>> that the variable aspects of a VLA are associated with its type, not
>>>> its value or instance.
>>> Oh? I don't find it difficult at all. It's the kind of thing you
>>> learn
>>> once, and then you know it. Now you know it, but you're still
>>> complaining for some reason.
>>
>> Maybe you've never had to implement it. It is certainly not intuitive:
>
> No, I haven't. I worked on compilers in the distant past (for Ada,
> which doesn't distinguish on the language level between array with
> constant and non-constant bounds), but I haven't implemented VLAs for C.
>
> We were talking about the fact that, as you say, "variable aspects of a
> VLA are associated with its type, not its value or instance". Are you
> saying that makes implementing it unreasonably difficult?

It makes it bizarre. It would make a typedef involving a VLA type
something to be executed at runtime; it is executable code.

>
>> int n=rand();
>>
>> typedef int T[n]; // here the size is stored with the type
>
> Yes, of course it is. And keep in mind that typedef doesn't create a
> new type. A compiler will create, at compile time, some internal node
> (or whatever data structure it uses) representing the anonymous type
> `int[n]`, and will associate an implicitly created automatic object with
> it to hold its length or size. It will then create a node representing
> the typedef T, referring to the anonymous array type.
>
>> int A[n]; // here you'd expect it with each variable
>
> Why would you expect that?

Why would expect it to be part of some anonymous, associated type?

If you had a counted string type, would you expect its length to be part
of the data belonging to the object, and or part of a separate type object?

You might call it metadata, but being a type doesn't come to mind. What
would be the point of that; what could you do with that type?

Suppose you had a counted string variable S, currently set to "ABC" so
that its length (which you say is naturally part its type) is 3.

Assume you could somehow do this:

typeof(S) T

would you expect T to also have a length 3? What would the string contain?

It doesn't make sense. But you say that's how VLAs work:

int A[rand()];

typeof(A) B;

B has the same length as A, whatever that is.

> And if you have std::vector you don't need VLAs or slices. If you use a
> language other than C, you can avoid C's limitations.

Can a std::vector also be a view? If not then you still need slices.

However when I looked at std::vector, it was basically a pointer,
length, and capacity. My slices were pointer and length. Capacity was
something I'd thought about.

Automatic memory management however would complicate matters greatly.
This language (whether C or my own) is lower level and generally explicit.

Bart <bc@freeuk.cm> writes:
> On 07/01/2024 01:15, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 06/01/2024 21:40, Keith Thompson wrote:
>>>> Bart <bc@freeuk.cm> writes:
>>>> [...]
>>>>> The concept is not that easy to get your head around either, the idea
>>>>> that the variable aspects of a VLA are associated with its type, not
>>>>> its value or instance.
>>>> Oh? I don't find it difficult at all. It's the kind of thing you
>>>> learn
>>>> once, and then you know it. Now you know it, but you're still
>>>> complaining for some reason.
>>>
>>> Maybe you've never had to implement it. It is certainly not intuitive:
>> No, I haven't. I worked on compilers in the distant past (for Ada,
>> which doesn't distinguish on the language level between array with
>> constant and non-constant bounds), but I haven't implemented VLAs for C.
>> We were talking about the fact that, as you say, "variable aspects
>> of a
>> VLA are associated with its type, not its value or instance". Are you
>> saying that makes implementing it unreasonably difficult?
>
> It makes it bizarre. It would make a typedef involving a VLA type
> something to be executed at runtime; it is executable code.

Sure. A VLA type specifier like `int[n]` or `int[rand()%10+1]` involves
evaluating the (non-constant) expression that specifies the length. Of
course that requires executable code, whether it's part of a typedef or
part of an object definition. I don't understand why you find that
bizarre.

>>> int n=rand();
>>>
>>> typedef int T[n]; // here the size is stored with the type
>> Yes, of course it is. And keep in mind that typedef doesn't create
>> a
>> new type. A compiler will create, at compile time, some internal node
>> (or whatever data structure it uses) representing the anonymous type
>> `int[n]`, and will associate an implicitly created automatic object with
>> it to hold its length or size. It will then create a node representing
>> the typedef T, referring to the anonymous array type.
>>
>>> int A[n]; // here you'd expect it with each variable
>> Why would you expect that?
>
> Why would expect it to be part of some anonymous, associated type?
>
> If you had a counted string type, would you expect its length to be
> part of the data belonging to the object, and or part of a separate
> type object?

If a language considers "array of 10 ints" and "array of 20 ints" to be
the same type, I suppose I'd expect the length information to be
associated with an object. The type would just be "array of int".

If they're different types, as they are in C, I'd expect that
information to be associated with the type. If I have 123 objects of
type "array of 10 ints", there's no reason for the compiler to store the
value 10 123 times in its internal symbol table.

And if I have:

int n = 10;
typedef int vla[10];
vla twod_array[123];

then there's no need to store the value 10 separately for each of the
123 elements of `twod_array`.

> You might call it metadata, but being a type doesn't come to
> mind. What would be the point of that; what could you do with that
> type?

You could define objects of the type, you could apply sizeof to it, you
could define a type that points to it, or that's an array of it. You
know, all the stuff you can normally do with a type.

> Suppose you had a counted string variable S, currently set to "ABC" so
> that its length (which you say is naturally part its type) is 3.

What exactly do you mean by a "counted string variable"? If you mean
you have a variable whose current value is "ABC", and you can update it
so its value becomes "ABCDEF", then of course the count has to be
associated with the object. But a VLA object's size is fixed at run
time when it's created.

> Assume you could somehow do this:
>
> typeof(S) T
>
> would you expect T to also have a length 3? What would the string contain?

Without knowing what the type is *in C terms*, I can't answer that.

> It doesn't make sense. But you say that's how VLAs work:
>
> int A[rand()];
>
> typeof(A) B;
>
> B has the same length as A, whatever that is.

Well, C doesn't have typeof, but you can certainly do something similar.
(I'm changing the length expression because rand() can return 0, which
would cause undefined behavior.)

typedef int rvla[rand() % 10 + 1];
rvla A;
rvla B;

A and B are of the same type and therefore have the same length. The
obvious way to implement that would be to store the length in an
anonymous object associated with the type. You're saying you'd expect
the size be associated with A and with B, not with the type.

Given:

int row_count = 1000;
int col_count = 2000;
int vla_2d[row_count][col_count];

you have 1000 rows of 2000 elements each. Would you expect to create
1000 implicit objects, one for each row, each holding the value 2000?

Since the standard specifies the behavior of VLAs, not how they're
implemented, a conforming compiler could do that, but why would you
expect it?

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-01-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 06 Jan 2024 16:40:03 -0800, Keith Thompson wrote:
>
>> C uses a "declaration follows usage" rule (though not with 100%
>> consistency).
>
> And putting the function result before the argument types turns out to
> cause trouble when carried over to C++, when you try to express
> dependencies between them. So they had to add a Pascal-style alternative
> syntax, with the function result declared after the arguments.

In this millennium, you can have dependencies that flow opposite
to the lexical order of tokens.

C++ itself has no problem having inline function in a class declaration
mutually call each other, without any forward declarations.

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

On 2024-01-06, Bart <bc@freeuk.cm> wrote:
> Then I got stuck on examples like '[]int a = ()' and realised it's
> tricky. And then I thought, why the hell am I doing this? A language
> I've already used for a million lines of code.

That exact reasoning can be used to reject new features from C,
like an operator for the number of elements in an array.

People have written billions of lines of C without it!

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