boy sounds somewhat like Turkic bala/bola ("a boy").

Well it may have effect on ergonomics. Some people claim they cannot use 60Hz monitor after trying 144hz.

Well, that is usually refering to some form of "simulated fluid motion", not new characters appearing and disappearing. The only case where that kinda fluid motion would matter is when you have text scrolling by at semi-fast speeds.

I count myself among the people that would consider >60hz necessary.

For me, it's animations, especially if I'm dragging a window or just the mouse. On 60hz it's nauseating if I'm paying too much attention to the window I'm moving. It's goes completely away around 90-100 Hz (at least for me)

I've had the privilege of using a merely 90Hz display and the difference is still incredible. It gives me input feedback much faster so my brain does not have to do as much buffering/prediction, everything feels a lot more direct. One would think a measly 5 milliseconds wouldn't amount to much, but for input feedback it absolutely does.

I do not suffer from nausea or motion sickness of any kind arising from computers or visuals in general, but I can still easily tell the difference between a 60Hz and 90Hz display. A few months ago I had the privilege of checking out the 120Hz displays on the new MacBooks and they're amazing.

I'd still say that draggin a window would count as a "simulated fluid motion". Maybe not something you'd immediatly think of, but its still trying to convey the sense of motion. Just text appearing and dissappearing isn't something I personally could categorize ass the same type of animation.

And I also count myself as someone who considers 120 at least necessary (on the primary monitor)

Every time I hear Rust, I recall True Detective (Rustin Cohle).

Well, you know what he said about time ...

Yeah, he said it is a flatulence circle.

I have personally obtained unmesurable amount of relevant info from twitter; lots of true experts in every area in real time. Blogs were more like reading a published magazine article - for something not time sensitive.

1. It was USSR, not Russia. For many who were USSR citizen till 1991, but neither ethnically or geographically Russians, this rubs very wrong way.

2. Aviation in the USSR was developing completely independent, and you can accuse USSR in stealing technology in many areas but certainly not in aviation.

The problem that is extremely verbose though. OCaml is much more concise.

Both languages encourage a concise, functional programming style but with different flavors and toolsets. They are comparable, in terms of verbosity.

I think these are correct implementations of the tower of Hanoi.

OCaml

    let rec hanoi n source target auxiliary =
      if n > 0 then begin
        hanoi (n - 1) source auxiliary target;
        Printf.printf "Move disk from %s to %s\n" source target;
        hanoi (n - 1) auxiliary target source
      end

SML

    fun hanoi n source target auxiliary =
      if n > 0 then (
        hanoi (n - 1) source auxiliary target;
        print ("Move disk from " ^ source ^ " to " ^ target ^ "\n");
        hanoi (n - 1) auxiliary target source
      )

function definition, if expressions, recursion are more concise in SML, string interpolation is nicer in OCaml

You SML code is incorrect, shows that you actually never coded anything in SML. SML requires that "if" always contains "else" clause (which is the norm for many functional languages). And this kind of stuff which makes SML unnecessarily verbose (OCaml has for operators, single line let definitions that do not require you to make use val and fun for different type definitions etc.).

I did Programming Languages, Part A, (to learn FP semantics) many years ago. It doesn't show I never coded anything in SML, it shows I made a mistake :/ .I no longer have Standard ML on my machine.

I thought having the `let` keyword encompass `fun` and `val.` was needlessly confusing. It's not concise. if `let` can mean so many things why not just do what Haskell did.

Again.. it not "so much more verbose." which was the initial point.

but I concede, my SML code is in fact incorrect.

No SML is more verbose, is pretty obvious. A simple "for" in ocaml could save lots boilerplate doing trivial recurison.

Functional programmers tend to use recursion instead of explicit loops with implicit state, and it's wise to regard for loops with suspicion since it can't return anything.

Standard ML as the language of instruction is a vehicle for teaching FP semantics, not imperative ones.

Also, Tower of Hanoi is a classic problem that's well suited for recursion.

You do not need to school me about why "for" is not pure functional - as soon as you understand that it is syntactic sugar, you are fine; IO is also impure, so if you insisting in purity then the only option is Haskell.

If you want to be pedantic, in functional programming there is no such a thing as "return value", as there is no such a thing as statement, only expressions. And expressions always _have_ values, they do not _return_ them.

I agree that SML is better for teaching than OCaml no doubt about it.

I mean, it is pointless to continue this conversation; you did not use SML for a long time - I did use it last time last year, and I can attest, it is extremely impractical compared to any other FP language today.

What kind of UB the author is talikng about?

If x is n bits long, it's undefined behavior to evaluate x >> n. You can only shift by amounts smaller than the register width. IMO this is one of the more annoying instances of UB. Precisely because of situations like this, where you shift by "number of leading zeroes" which can end up being the width of the register.

This is one of the classic examples where C++ should clearly have picked Unspecified Behaviour rather than Undefined Behaviour but too late now. Nobody wants UB here, and the set of things CPUs actually might provide is enumerable.

Maybe I should suggest avoiding the same fate for Rust's unchecked_shl and unchecked_shr. (These aren't stabilized yet unlike the safe options and the rotates)

"C++ should clearly have picked Unspecified Behaviour rather than Undefined Behaviour but too late now"

It's never too late to replace Undefined Behaviour with Unspecified Behaviour.

> C++ should clearly have picked Unspecified Behaviour rather than Undefined Behaviour but too late now.

Why is it too late? Changing it in a later version of the standard wouldn't be a further constraint on any written code; any code which is currently correct will remain correct, and some code which could have done literally anything will now only be able to have one of a few possible behaviours.

The shift instruction is defined differently depending on the ISA. For example, on some CPUs "x >> 32 == 0" and on others "x >> 32 == x". Both shift designs are reasonable and C has to accommodate both. Defining this case would require putting a branch instruction in front of the shift instruction on many architectures. Obviously this would be a large performance regression.

Consider how long it took C++ to deprecate support for integers that are not two's complement, when every piece of silicon for many decades has been a two's complement design. In the case of shift instructions, it is defined differently across ISAs used today.

That is not a good pro argument.

When this operation is undefined, you must always put a branch instruction in front of it, on any architecture, regardless if it happens to do what you want.

Even when you know precisely the type of CPU on which the program will be run, you would need to use inline assembly to be sure of the behavior of the program.

When you can guarantee that the operand will never have the undesired value, then no branch instruction would be used on any architecture, regardless how the C standard would define the operation.

It is always better when the programming language standard defines completely all operations.

In the worst case, when two possible operation definitions are widespread in hardware implementations, two distinct operations should be defined in the language, allowing the programmer to choose the one that is more efficient on the intended target, but knowing that the program will remain correct regardless for which target it is compiled.

Why would having the standard set the behaviour as "unspecified" (or "implementation-defined") require a branch?

Surely under those circumstances, the compiler can document doing whatever the target ISA does as its behaviour, and just output the shift as-is?

I suppose it would break any currently compliant C++ compiler for which the target platform's CPU will throw an exception (or even less likely, return a random number) when shifting by a full word.

But I'd also suppose there aren't many such CPUs. Does anyone know of any?

> I suppose it would break any currently compliant C++ compiler

Maybe not?

I'm pretty sure that "trap" is an allowed behaviour for NaNs in some parts of the standard already, if properly documented. I don't see why unspecified/implementation-defined behaviour for shifts couldn't be allowed to do the same, on appropriate targets?

But also, the new behaviour should only be required of compilers in the to-be-written `--std=c++3X` (or whatever) mode. Any compilers conforming to an earlier version of the standard can already do whatever they're currently doing.

Still using my Sansa.

Love the Cobblestoned Walts.

Focus on Eyesafe monitors, esp. with Innolux panels. (such as all 28 inch 4k monitros).

Do you have any recommendations or links? I don't see anything on the innolux site about regular old computer monitors. I guess they manufacture the panels?