23 Aug
2018
23 Aug
'18
8:23 a.m.
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:
On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger <perry(a)piermont.com> wrote:
On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck <ckeck(a)texoma.net>
wrote:
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.
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.