Conversation

Notices

1. Embed this notice
   wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Monday, 13-Jan-2025 10:14:08 JST wizzwizz4

   • alcinnz
   • Alexandra-Lilith

   @alilly @alcinnz I don't think it's possible to start with a small language, not unless you're willing to drop down to "and my high-level language spits out machine code". That's cheating, to me: it significantly reduces the approachability.

   A big selling point of C is that it's "portable assembly" – except it doesn't achieve that. I'd like to have something that's as powerful as assembly, without all the footguns. Where you can have sum types, and define how those map to machine semantics…

   • alcinnz repeated this.
   • Embed this notice
     wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Monday, 13-Jan-2025 10:18:15 JST wizzwizz4

     in reply to

     • alcinnz
     • Alexandra-Lilith

     @alilly @alcinnz That said, if you're willing to go really eccentric, the minimum you need is a LISP model of the CPU (including the instructions you want to support), a proof system, and a basic constructive compiler. Then, if you want more optimised machine code for something high-level, you can prove the equivalence of the two algorithms (up to the extent your LISP is supposed to preserve lower-level semantics).

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Monday, 13-Jan-2025 10:23:34 JST alcinnz

     in reply to

     • Alexandra-Lilith

     @wizzwizz4 @alilly Or there's my approach: Know the language & the tasks I want, then design hardware for that language!

     I haven't actually built any of these yet...
     Easier to use the hardware we have now...