On 7/15/2014 6:03 PM, Mike wrote:
OT: Isn't inp/outp and Intel-only thing, though?
Of course. But it's still used on embedded systems.
DIP62 addressed why peek/poke are not the right tool for the job in the "why a type qualifier" section. In summary, one would never want to access volatile memory with non-volatile semantics, and a type qualifier is the only proposal I've seen that enforces that: peek/poke intrinsics do not.
See my reply to Steve Sobel.
From what I've read in this thread, I suspect you favor peek/poke due to the complexity it introduces into the implementation. If a 'volatile' type qualifier was a trivial implementation, and did not introduce complexity into implementation, would your position be different?
Unfortunately, it isn't trivial, so your point is moot. Even if it were, "trivial" is not a good reason to put a feature in a language. The language must not become a kitchen sink grab-bag of trivia. Go has demonstrated there is considerable value in having a small set of orthogonal features instead.
I remember watching a talk you gave where you compared code with an airplane, and how when you get it right, it just looks like it wants to fly. I don't know how many people got that, but I sure did.
You're the only one that likes my airplane metaphors :-)
A type qualifier is an elegant tool for modeling one's hardware because at every usage, it already knows how, and wants to fly.
Type qualifiers are not elegant. Type qualifiers are fairly burdensome to the user.
