And just a note that Caipenghui is new to the list, he is from China and dmr is one of his heroes. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

On August 22, 2018 5:37:43 AM GMT+08:00, Cornelius Keck <ckeck(a)texoma.net> wrote: We miss DMR. DMR is dead, but we will not forget his contribution to humanity. We will learn a simple humorous spirit of DMR. Not only did he teach us to code, he seemed to convey a human spirit. DMR also conveys the spirit of Unix philosophy, such as kiss.do a thing, do it well, etc. Caipenghui

On 8/22/18, Perry E. Metzger <perry(a)piermont.com> wrote: For a linker to enforce (or warn about) type and call signature matching, it would have to know the type and call semantics of each particular language, and each particular compiler's switch options that allow the programmer to bend the language rules. Not impossible, but a difficult and cumbersome problem, particularly as language and compiler implementation semantics vary over time. C++ and other strongly-typed languages typically hack around the problem using name decoration. Not elegant, but effective. Has anyone experimented with building Unix using C++, to take advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. -Paul W.

On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski <paul.winalski(a)gmail.com> wrote: Not necessarily. One could produce a language-independent way of signaling what the type signatures are (perhaps with normalized language-dependent strings) and the linker could just check that they match. I've seen several languages (like OCaml) hack around the lack of this by providing an auxiliary file for a pre-link phase to check off of. It would be nicer if the linker could just handle that. And, as I noted, this would doubtless prevent a _lot_ of bugs. One could simply decorate the symbols with a (language, semi-opaque "type string") pair, and the linker could just verify that they matched without understanding semantics. As I noted, there are ways to get around that. Name mangling for C++ is needed for another reason, too, which is that a single "name" foo might be multiple different concrete functions depending on what type it is invoked on. C++ doesn't have strong typing in the modern sense. It also has some small incompatibilities with C's syntax and semantics, sufficient that you can't just (say) compile the Linux kernel with a C++ compiler and have it work. Perry -- Perry E. Metzger perry(a)piermont.com

On 8/22/18, Perry E. Metzger <perry(a)piermont.com> wrote: True. And the debugger people have already done the design work in this area. One could probably use DWARF to pass this info to a linker. I'm pretty sure that is how VMS Ada solved the problem, too. -Paul W.

That Go decision feels like something which could be built upon. I think this already moving off TUHS but none the less, looking forward, the increase in strongly typed languages in use points to a desire to preserve the type semantics so that inter-language linking can maintain the promises (so to speak) If Go has gone to marking the promises around types in a useful way, I would be entirely cool if somebody smart in llvm said "oh, if you layer your language compiler onto our STL and ISA model, our intermediate code representation then ... " (I believe GHC deliberately does this, and Frege targets the JVM similarly) Smart people in small groups do huge things which have big consequence. I am not a Go person, I tried and failed for purely personal reasons. If Go takes the underlying abstract ideas and does something other people can leverage, I would be very applauding. I like that kind of outcome. -G On Thu, Aug 23, 2018 at 2:05 AM Dan Cross <crossd(a)gmail.com> wrote: