waltpad

I don't know Forth, Perl, or even Rust enough to discuss them on that basis, but having other languages allowing it doesn't mean that C should be lenient about it either, or does it?

Now, don't get me wrong, I do not dislike C, I've practiced it a lot, and I come back to it from time to time when I need to. But I would rather use a language where many of these forms are forbidden for readability and maintainability.

Indeed, anyone can also write code over-abusing lambdas in a functional language, but lambdas are also quite useful in the majority of cases. On the other hand, can you point out a single situation where swapping int and typedef in a type definition brings anything good?

Likewise, in your example, I doubt that this could bring anything. Is there a practical obfuscation method based on that quirk in Rust, or a reason for keeping it in the syntax? I cannot tell, but maybe you can?

Overall, the problem that I have with this is not that it is silly, it is that it makes it harder to understand and maintain. In some cases, it requires active engineering to fix the issue, but the language should be designed so that most of these problems are taken care of by design.

Also, many people seem to enjoy the fact the C can be bent that way. I don't mean to remove that from them, I just think that for system programming, it should be less permissive. Perhaps a 'strict mode' could be devised, not at the syntax level like in javascript (which I suppose couldn't be avoided), but as compiler flag (like the c++ people did it).

That probably shows (once more) that the C language really needs an overhaul, with a stricter grammar disallowing that sort of tricks.

Or maybe not.

How is that supposed to work? I understand that it possible to pull the plug on packages which are not ready at time T, but it also means pulling the plug on all the packages that depend on it.

So if libreoffice depends on package P, and that one is not ready, is Debian going to simply drop libreoffice until next release?

> my arch installations tend to be quite lightweight.

That may explain why you don't get that many problems.

If you start pulling in many different components, the set of potential interactions grows exponentially. And if you add to that external software, it easily becomes nightmarish.

I've seen other comments saying that they've been running Debian or what have you for years without any upgrade hickups, and personally I've never had that. The easiest way was always to simply remove as much as possible, start the upgrade, and then pull back whatever I removed, so that the system setup would correctly fall back in to place. And even with that, I sometimes get problems.

The main issue is probably not that upgrades are issue-less. The problem is perhaps the lack of cooperation between distros so that everyone could benefit from the experience others built along the way. But How does one organize that sort of cooperation?

Or maybe there's too much friction between distros and upstream developers?

I thought Debian also moved to a fixed schedule release policy? Doesn't it make it harder to stick to a "release when ready"?

Personally, I don't think that Ubuntu is less perfect that Debian wrt. upgrade quality, it's just that (it seems to me that) the workforce is not as large, and that they also have other projects on their plate (not to say it should be that way or not, I'm merely trying to state the facts).

Debian unstable follows more or less that "CI/CD" approach you're describing, but it is called unstable for a reason: sometimes, a significant change is necessary, which may lead to significant breakage as well, but most of the time, you get small breaks here and there, which are usually easy to fix (and hopefully report, so that break can be handled by the package upgrade process directly).

I wonder how's Arch in that regard. You speak about breakage less common, but there has to be some significant breakage from time to time: for instance, for a shift as important as moving from traditional sys-v init scripts to systemd, it must be expected that a lot of OS configuration related packages would break, unless every package maintainer is made aware that this change would happen, and that he/she has to prepare its package (if necessary) to that shift, AND that the shift only happens when everyone's ready. But Debian (and I suspect Arch as well) do not follow such a rigid scheme, and so there has to be breakages and fixes to follow.

So clearly, if llvm is used as a backend for js, this feature will come in handy.

On a side note, apparently, it will also be useful for the rust folks, which has user implemented libraries to emulate C-like bitfields, and implement bigints,

So this work has promising outcomes.

First of all, I suppose that it will be possible to make them unsigned (just like for standard types). Is this correct?

Also, what's the relationship between standard types and the new _ExtInts? Are _ExtInt(16) equivalent to shorts, or are they considered distinct and require explicit cast?

> In order to be consistent with the C Language, expressions that include a standard type will still follow integral promotion and conversion rules. All types smaller than int will be promoted, and the operation will then happen at the largest type. This can be surprising in the case where you add a short and an _ExtInt(15), where the result will be int. However, this ends up being the most consistent with the C language specification.

For instance, what if I choose to replace short by _ExtInt(16) in the above? What would be the promotion rule then?

Note that it was already possible to implement arbitrary sized ints for a size <= 64, by using bitfields (although it's possible that you could fall into UB territory in some situations, I've never used that to do modular arithmetic).

Edit: Ah, there's this notion of underlying type: one may use the nearest upper type to implement a given size, but nothing prevents to use a larger type, for instance:

struct short3_s { short value:3; };

struct longlong3_s { long long value:3; };

I don't know what the C standard says about that, but clearly these two types are not identical (sizeof will probably gives different results). What's will it be for _ExtInt? How these types will be converted?

Another idea:

what about

struct extint13_3_s {

  _ExtInt(13) value:3;

};

Will the above be possible? In other words, will it be possible to combine bitfields with this new feature?

I guess it's a much more complicated problem that it appears to be at first.

I love Yann Lecun's eyeglass rim arching in one of the demos from the first-order-model code repo[1].

1: https://github.com/AliaksandrSiarohin/first-order-model

I totally agree; there's a world of difference between laws impossible to enforce and laws impossible to break.

Has any of these talks been published?

> That said, "meaning" is not statistical.

Are you sure of that? After all, we don't have all the same interpretation for every word in the dictionary. Ask a hundred person in the street - well perhaps not these days - the meaning of the word "meaning", how many different explanations will you get? And will you be able to reduce them all to the same "fundamental" meaning?

slight nitpick

It is not a grammatical error: such an error would mean that the sentence is not constructed according to the grammatical rules (of English), when clearly it is. What you probably meant is that it's a semantic error: the writer used a construction which doesn't not convey the intended meaning.

As an example, substitute the impossible fact of both wearing a mask and not wearing a mask by "both walking and not looking frontward" and you would obtain a sentence following the same construction, yet doesn't seem to carry an incorrect meaning.