gpderetta

> Accidentally stumbling on a mechanism that is simple enough to be recreated with every human birth might be possible, accidentally stumbling on a mechanism that took evolution billions of years to find and which it has hung onto by copying it and has never recreated it from scratch, could be much less likely, in a much bigger search space.

Maybe, but you could make the same argument about anything artificial.

While dreaming, the brain synthetizes sensory experience while cutting down (or greatly suppressing) most of external stimuli. Yet it is still conscious.

definitely point 1.

Also: 5. Async/await is a necessarily evil that allows for extremely high concurrency (10s of millions of concurrent tasks) where stackful coroutines and threads wouldn't practically scale.

See also Cilk/Cilk++

I know approximately zero about webgpu, but I assume it allows for pipelining.

Option 1 could be easily solved by having an atomic {} blocks that statically error if call any potentially async function in it. This is better as it document where an externally visible invariant is temporarily broken (i.e. reentrancy is required), instead of being implied by the code and potentially being broken a a future code change.

Implicit thread safety across async blocks of course break if you introduce actual shared multithreading in the language, while if you have atomic blocks at least you can build transactional memory on top.

With (unchecked) exceptions the custom validator can abort the whole stack non locally and transport the error to the original call stack, the validation library being none the wiser.

With stackful coroutines, the custom validator can transport the error to the original call site, handle it and resume back into the validation library if the error was recovered, or abandon the validation (as with exceptions) if unrecoverable.

With HKTs, the validation library can be agnostic on the specific return type of the custom validator.

Exceptions are a very good comparison because they also perform non-local control flow.

Checked exceptions are a form of coloring, while unchecked aren't. But Java (which has checked exceptions) has an escape into unchecked land in the form of RuntimeError, most async languages do not, short of spawning a background thread (for sync->async) or force blocking (async->sync).

Interestingly, Result<T,E> based error models are semantically (and even syntactically, mostly, except for the call-site annotation) equivalent to checked exceptions. Usually these languages have enough abstraction capabilities (HKT for example) to make coloring not an issue, or, again, an escape into unchecked land (for example panic in rust or Go, although the latter hardly counts as having Result-like error handling).

The problem with function color exists when you can't abstract over it[1]

Some statically typed languages (I believe both Haskell, ocaml) have powerful type system that allow abstracting over function types and function colors. Color is not an issue here.

Some other statically typed languages (C#, rust, and C++ (at least with the built-in stackless coroutines)) can abstract over types but not over colors. This is a problem.

Some statically typed languages (Go) do not encode async-ness statically, so it is not an issue[2].

Some dynamically typed languages (scheme, Lua, lisp) also do not encode async-ness statically. Everything is fine.

Finally there are some dynamically typed languages (python, js) that, eskew static types but for some reason still decide to encode async-ness statically. For me this is the most bizarre decision, especially as some of the justifications for static async-ness (performance, memory usage) are less relevant.

[1] for example, a litmus test is being able to implement an higher order function that inherits its color from one of its parameters. Essentially this is the problem of generically turning an internal iterator to an external one.

[2] fundamentally in these languages continuations are first class values that can be passed around, so the asyncness is naturally not bound to the function that created a continuation.

Edit: you can in principle abstract away color in any async language by simply assuming that any function call is async and await it. Then sync functions can trivially be made async. But at this point async annotations no longer convey any useful property: the language might as well implicitly await any function and require call-site annotations for diverging control flow or reentrancy requirements. More practically as languages with async evolve and grow asyncness becomes pervasive and pushes away any sync component.

amusingly, the last Toyota Prius looks quite nice.

Ferrari has been doing in-house design for a while. With spotty results.

I wouldn't say it is pretty, but to me it looks nicer on this picture than on the Ferrari website.

It is a very generic shape for sure!

Haven't Ferrari used buttons for turn signals for a while?

EU famously has one. Of course you might not consider it a country.

I loved the Warhammer 40k sets and the LotR sets. Didn't care about the others. Other people loved the FF or Avatar. Different people have different tastes (everybody hated Spiderman though).

The canonical MtG lore is not exactly deep and refined anyway.

what if at some point we will no longer be able to understand the answers?

a thread_local is just a global variable. Mutable global variables are of course bad, but in this case the threadindex is immutable once created, so it is perfectly fine.

SARIF is machine readable. An editor (or a shell filter if you prefer it that way) would allow hierarchically inspecting the output at the desired detail level. The article shows nested overload candidates that could be potentially be collapsed, for example.

concepts have been excellent for me for overload resolution in complex template code (good riddance SFINAE) and for documentation.

To improve error messages, not so much.

It is not obvious to me that the list of categories is not infinite (unless the final category is "everything else" of course)

The issue is that the list is infinite (anything not specified is UB), so actually removing any finite amount of UB from the list won't make it shorter.

(only slightly tongue-in-cheek, I do believe that removing silly things is worthwhile).

Consider:

   enum op_t{ add, mul };
   int exec(op_t op, int a, int b) {
       if(op == add) { return a+b; }
       if(op == mul) { return a\*b; }
   }

   c = exec(add, a,b);

Should be the compiler be prevented from inlining exec and constant-propagating op and removing the mul branch? What about if a and b are constants and the addition itself is optimized away?

> Unaligned access? Packed structs.

Packed structs are dangerous. You can do unaligned accesses through a packed type, but once you take the address of your misaligned int field, then you are back into UB territory. Very annoying in C++ when you try to pass the a misaligned field through what happens to be generic code that takes a const reference, as it will trigger a compiler warning. Unary operator+ is your friend.

Ex falso quodlibet.

Bounding UB would be a nice idea, or at least prohibiting time-traveling UB (and there is an effort in that direction). But properly specifing it is actually hard.

[We are very much in speculative territory here of course, it is not a given that duplication or upload is possible at all for a human mind]

I would say that both A and B would claim to be X and have the "continuous"[1] experience to be X while agreeing that they are distinct persons. I think that the question of whether A or B, both, or neither is the true X, is not a scientific question, and as a philosophical question, a fairly empty one.

Regarding the challenge, I would expect that the consciousness would be forked: there is a "me" that would awake inside the machine and would be very glad to be alive, while the "me" outside would experience dying. This seems to go against the exclusiveness of the experience of being themselves, but assuming the existence of the magically perfect duplication, both would be valid experiences and again neither could make a claim about being the real me. I don't find this to be a contradiction.

An interesting question would be whether consciousness can be reunited after being forked.

But all of these scenarios have been explored extensively. Are you familiar with the Egan's "Permutation City"?

edit: I was not familiar with the functionalist position, but for the little I read, it seems to me that it is just a variant of the monist position. You could say I'm a functionalist I guess. Also I believe that we are fundamentally in agreement and we might just disagree with definitions of words.

[1] what does "continuous" even mean? Do one have a "continuous" experience of being yourself after a night's sleep? After anesthesia? After a coma?

I checked how Simula calls its object methods, but it just uses the term procedure as for normal top level functions. At least it shows that the term method is not universal.

I think that C had members, so members that are functions just became that. But then again, members that are types are usually called nested types.

> A vector of variants still wouldn't be optimal

Transpose.

> the experiences of one do not get magically transmitted to the brain of the other. So those are two distinct selves, even if they are made with the exact same information.

How's that a problem? They would both be distinct selves with a common past.

If this actually happened, would the 'I' that replaced you be any wiser. How do you know this hasn't happened to you already? Maybe multiple times per second?

> It says "something" survived the utter complete destruction of the physical body and was "put back in it" once it was reassembled. If "it" survived the complete physical destruction of the body, it must be somewhere else, detached from the body.

The information of how to put your body and mind back must have survived somewhere, in the alien mind for example or the machine they used. But the information would still be in (a medium in) this universe and bound to this universe physical laws. I would say this is still a monist position.

A true dualist believes that consciousness survives outside of a medium in this universe.

I have only been doing this for the last 20 years, so maybe I don't know, but it seems to me that requirement gathering is trivially software engineering. How can you implement something if you do not know what you need to implement. Figuring out what it need to be built and how to build it are closely linked. A good project manager will help collecting any missing domain knowledge, but ultimately it is on the architect to make sure that all the right questions have been asked.

And it is given that not all requirements will have been discovered before a development start or that they may change during development.