Newest at the top
| 2024-05-02 18:08:52 +0200 | <tomsmeding> | question is whether it would be worth the effort and the potential loss of some performance (to be measured) |
| 2024-05-02 18:08:37 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-05-02 18:08:36 +0200 | <EvanR> | IANAGH |
| 2024-05-02 18:08:31 +0200 | <tomsmeding> | but compiling a standardised wrapper function would theoretically be possible always |
| 2024-05-02 18:08:22 +0200 | <hseg> | fair enough |
| 2024-05-02 18:08:07 +0200 | <tomsmeding> | there may well me more reasons for ABI instability that I'm not aware of -- I'm not a ghc hacker |
| 2024-05-02 18:07:54 +0200 | <tomsmeding> | worker-wrapper is one thing I know of where this plays a role |
| 2024-05-02 18:07:45 +0200 | <tomsmeding> | indeed |
| 2024-05-02 18:07:40 +0200 | <hseg> | right, because now the workers will be opaque |
| 2024-05-02 18:07:25 +0200 | <tomsmeding> | yes |
| 2024-05-02 18:07:23 +0200 | <hseg> | but wouldn't that lose optimization opportunities? |
| 2024-05-02 18:07:17 +0200 | <tomsmeding> | conceptually this isn't very difficult, but it would be a lot of engineering |
| 2024-05-02 18:07:03 +0200 | <tomsmeding> | then you'd have to convince GHC to use those wrappers instead of the workers directly |
| 2024-05-02 18:06:49 +0200 | <tomsmeding> | you'd have to define some standard calling convention, and use that to define additional wrapper functions that _are_ materialised in the object files, and just unused whenever GHC can see the interface file |
| 2024-05-02 18:06:20 +0200 | <tomsmeding> | I mean, it wouldn't be that hard |
| 2024-05-02 18:06:11 +0200 | <tomsmeding> | :) |
| 2024-05-02 18:06:06 +0200 | <hseg> | and it's fundamental enough I can't even picture what an ABI-stable GHC is anymore |
| 2024-05-02 18:05:40 +0200 | <hseg> | ah yeah that would definitely be a problem |
| 2024-05-02 18:05:24 +0200 | <tomsmeding> | yes |
| 2024-05-02 18:05:21 +0200 | <hseg> | ohhh and so everyone will be calling the worker, whose type can change between recompilations? |
| 2024-05-02 18:05:15 +0200 | <tomsmeding> | the type of foo$w is dependent on the implementation of foo, unlike the type of foo itself which is independent on foo's implementation |
| 2024-05-02 18:04:55 +0200 | <tomsmeding> | the outer foo doesn't have any code generated because it is intended to be inlined everywhere |
| 2024-05-02 18:04:44 +0200 | <tomsmeding> | where the outer foo just does wrapping in data constructors and the inner foo$w works on unboxed values |
| 2024-05-02 18:04:38 +0200 | <hseg> | right, and that transformation can change intermediate types even if the worker's type doesn't |
| 2024-05-02 18:04:28 +0200 | <tomsmeding> | (if you write `foo :: Int -> Int`, that converts into `foo :: Int -> Int ; foo (I# i) = I# (foo$w i) where foo$w :: Int# -> Int#`) |
| 2024-05-02 18:03:55 +0200 | <tomsmeding> | e.g. specialisation, but also worker-wrapper transformation |
| 2024-05-02 18:03:45 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-02 18:03:39 +0200 | <tomsmeding> | the haskell interface file (.hi) produced by GHC as a side effect of compilation describes where the code is and what it looks like in the object file |
| 2024-05-02 18:03:25 +0200 | <hseg> | oh, because of specialization? |
| 2024-05-02 18:03:14 +0200 | <tomsmeding> | names too |
| 2024-05-02 18:03:12 +0200 | <tomsmeding> | more that the types of the arguments might change on the assembly level |
| 2024-05-02 18:02:52 +0200 | califax | (~califax@user/califx) |
| 2024-05-02 18:02:52 +0200 | <hseg> | eg you'd get a function dropped since it gets inlined everywhere? |
| 2024-05-02 18:02:39 +0200 | <tomsmeding> | yep |
| 2024-05-02 18:02:38 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-02 18:02:27 +0200 | <hseg> | ah -- because a haskell-compatible library edit might expose new optimizations, which might change the effective ABI? |
| 2024-05-02 18:02:01 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-05-02 18:01:54 +0200 | <tomsmeding> | so indirectly it's because of optimisations, but the direct cause is lack of ABI stability |
| 2024-05-02 18:01:19 +0200 | <tomsmeding> | the reason for which is, indeed, cross-module optimisations |
| 2024-05-02 18:01:07 +0200 | <tomsmeding> | just that there's no effort at stability |
| 2024-05-02 18:00:56 +0200 | <hseg> | hrm. What causes that instability? |
| 2024-05-02 18:00:35 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-05-02 18:00:26 +0200 | <tomsmeding> | (this is different from the C world, where C-level compatibility implies ABI-level compatibility if you have the same compiler) |
| 2024-05-02 18:00:05 +0200 | <tomsmeding> | so you have to rebuild dependent libraries and executables anyway |
| 2024-05-02 17:59:56 +0200 | <tomsmeding> | GHC makes no guarantees there |
| 2024-05-02 17:59:49 +0200 | <tomsmeding> | but if you recompile a new version of a library, even if the haskell-level interface is compatible, the binary interface is probably not |
| 2024-05-02 17:59:28 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-02 17:59:12 +0200 | <tomsmeding> | yeah also |
| 2024-05-02 17:59:05 +0200 | <tomsmeding> | e.g. libc, zlib, gmp, etc |
| 2024-05-02 17:58:59 +0200 | <tomsmeding> | note that system libs are still linked dynamically |