[TUHS] About Unix header files

[George Michaelson]

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 at gmail.com> wrote:
>
> On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry at piermont.com> wrote:
>>
>> On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck at texoma.net>
>> wrote:
>> > Early C-compilers didn't care much about prototypes. The default
>> > return type of a function would be an int. It was up to the code's
>> > author to pass the right (amount, order, type). The linker didn't
>> > care about signatures as long as the symbol resolved.
>>
>> To my knowledge, object file formats still don't have information
>> about type signatures, and linkers still don't care about types. This
>> is actually a problem. It would probably prevent a lot of errors if
>> those things changed.
>
>
> One can embed type information in existing object file formats (e.g. ELF) by placing it in dedicated sections. This is what Go does, for example. The Go linker does some type analysis for reflection, though if symbols line up it does not detect or prevent e.g. signature mismatches.
>
>         - Dan C.
>