35,475 karma · joined July 2, 2014
Want to talk to me? Drop me an e-mail:
125-888-0378@kylheku.com
This could change without notice; check the profile.
Git repositories: https://www.kylheku.com/cgit
Mastodon: @Kazinator@mstdn.ca
LinkedIn: https://www.linkedin.com/in/kaz-kylheku-8a8b94197/
meet.hn/city/49.2608724,-123.113952/Vancouver
Socials: - kazinator.at.hn
---
If we have a compiler for language X in language X, and don't use any tools such as a parser or lexer generator, then there is nothing but code in X in the project, and that makes the developer of language X feel like they have earned major brownie points ... err, I mean, ... that they have kept their project free of cumbersome dependencies.
If language X is a one-implementation invention, then the tooling won't exist which hits these checkboxes: (1) is written in X; (2) generates code for X. By the time language X is mature enough that its ecosystem has something like that, it is long past the point where it would make sense to introduce it into its one and only implementation. There would have to be interest in writing another implementation.
E.g. the first C compilers would never have used Yacc.
Among languages that have one implementation, and that use parser generators, we will almost always see that another language is used for bootstrapping and the generator is for that language.
For some designers, that is a bruise to the ego, or else an unappetizing dependency. Even if they are boostrapping with another language, they are thinking forward to a future release where they will ditch that: they will rewrite parts that are in the boostrapping language in the new language to make it self-hosting.
If you use tooling like parser generation, which is in the ecosystem of, and oriented toward, the to-be-jettisoned-one-day boostrapping language, that throws a barrier in the path toward self-hosting. So you tend not to do it.
Like if you are boostrapping with C, and have it in the back of your mind to get rid of it, do you want to be bringing in a complicated tool with its own input language, which generates C? You think twice and are more likely to go ahead if you've resigned yourself to sticking with the C dependency.
Most of the make replacement tools are promoted by propaganda which attacks a strawman version of make, whereby it is assumed to be at the center of a shitty recursive situation.
Of course, it's not the same as having the parse tree all done from a previous pass and just walking it to do semantics.
I.e. basically not at all.
Basically, standardization groups should be dissolved long before they devolve into stuff like this, where they are just creating churn for the sake of their own continuation.
But in terms of usability, if you can fog a mirror and move the needles on an EEG, you can probably upload documents to LMNotebook and punch in a question.
6 more are blue-leaning "purple": Arizona, Colorado, Georgia, Nevada, New Mexico and Wisconsin.
Only four are "blue": California (ban coming into effect 2027 as per article), Hawaii, Illinois, Maryland.
I don't understand why the ban cannot come into effect immediately. Like, wouldn't want to spoil someone's child marriage plans in the next year or so because it would be rude?
If you regard undefined behavior as having ordering requirements, it's game over for optimization (not to mention the current understanding of undefined behavior). Any time you have bona fide observable effects near calculation, you are hamstrung, because the potential for UB is in every nook and cranny, around every corner.
I think it's perfectly fine for the division by zero to occur before the output is produced and flushed, in that example. The UB of a bad division can time travel because a division is assumed not to have UB and can be reordered before a visible effect to which it is not related (the effect doesn't require the result of the division, nor does the division require an output tied to the production of the visible effect).
What these people are looking for is a safe calculation mode in which a bad division does something that is well-defined, like raise an exception that can be caught. That is then deemed visible, and must not be reordered w.r.t. other visible effects. And while it does hamper optimization, it is a translation mode that can be enabled or disabled around a block of code. If the programmer is certain there is no bad division, or else don't care about that being ordered w.r.t. a visible effect, then they declare a low safety level. (Which, this still being C, could be the default level).
As long as C standardization thinking remains obtuse or hostile w.r.t. this type of programmer-controlled safety level concept, they will be forever confounded by dilemmas caused by wanting intuitive outcomes that logically require undefined behavior to be partially defined.
To google (two syllables, only slightly glibber, due to no "b-s" plosive-fricative combo).
Maybe "web search" can be shortened to "bsearch" or "besearch", like "web log" got shortened to "blog".
"besearch" has grammatical precedence: bestow, bequeath, behead, bewitch, belabor, befriend, ...
A division calculation not a visible effect. Therefore the question doesn't even m ake sense: it's asking: can we see something that is not a visible effect (division) before or after a visible effect (modification of a volatile object).
Blaming Vim is like politicians blaming the previous administration.