<p><span class="h-card" translate="no"><a href="https://mastodon.social/@regehr" class="u-url mention">@<span>regehr</span></a></span> <span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> <span class="h-card" translate="no"><a href="https://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> that&#39;s actually why I&#39;m thinking of it now--the compiler is 4 days old (... and already runs on par with state-of-the-art on a subset of workloads, interestingly) and barely has unit tests, i feel like we can do better than that</p><p>there is undef, with similar but not identical semantics to LLVM&#39;s, and refinement under different versions of the semantics is something software in the field often gets very wrong</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> <span class="h-card" translate="no"><a href="https://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> my next piece of advice is to do formal verification from the start, don&#39;t put it off. it has a way of finding design flaws as well as implementation bugs, but once you&#39;ve heavily committed to a design it&#39;s hard to make big changes. </p><p>another thing is that if there&#39;s undefined behavior then you&#39;re checking refinement instead of equivalence, might as well deal with that right at the start!</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://types.pl/@lenary" class="u-url mention">@<span>lenary</span></a></span> <span class="h-card" translate="no"><a href="https://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> yeah, awesome. one way is to use Z3 as a library, another is to emit SMT-LIB, which is a bit of a pain but then you get process separation from the solver (giving reliable timeouts for ex) and also you can use another solver, such as CVC5</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> could work. reliability might be tricky but I bet there are botanists out there who know the best species for this sort of thing.</p>

<p><span class="h-card" translate="no"><a href="https://chaos.social/@gsuberland" class="u-url mention">@<span>gsuberland</span></a></span> <span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> use a plant&#39;s ability to rotate toward light?</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> I wonder if there are any photochemical reactions that could be exploited here. Phase change for applying work via pressure would probably be too thermally dependent, but perhaps there might exist an equilibrium reaction whereby the presence of light leads to (or inverts) a separation of two liquids of differing densities, allowing you to use a precisely bouyant float.</p>

<p>💭 (set-logic QF_ABDL)</p>

<p><span class="h-card" translate="no"><a href="https://mstdn.social/@plragde" class="u-url mention">@<span>plragde</span></a></span> The word &quot;so&quot; is critical. There&#39;s a claim of degree and consequence that don&#39;t apply to either of us.</p>

<p><span class="h-card" translate="no"><a href="https://mathstodon.xyz/@bremner" class="u-url mention">@<span>bremner</span></a></span> TBH, even better is Morgan Ames&#39;s &quot;Hackers, Computers, and Cooperation: A Critical History of Logo and Constructionist Learning&quot;:</p><p><a href="https://dl.acm.org/doi/10.1145/3274287" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="">dl.acm.org/doi/10.1145/3274287</span><span class="invisible"></span></a></p>