fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

the triad:
want to write an operating system
don't want to write C
don't know any systems language with full dynamic linking support except C

@alilly Does FreePascal support what you need?

@wizzwizz4 I don't really know Pascal, so I don't know if it compares favorably to C… but I worry it will share many of the same footguns.

wizzwizz4

@alilly To my knowledge, FreePascal has all the same footguns as GCC C, except viral Undefined Behaviour. (The optimisation philosophy is quite different: it doesn't seem to transform code into "equivalent code" in the same way, but often produces smaller binaries despite that.)

You could write your own language, and use that to write your operating system.

@alilly Existing languages aren't suitable. You know it, I know it. If we want to do OS dev (which I do), we need something better.

(Happy to collaborate if you don't want to make a new language on your own.)

@wizzwizz4 @alilly If we're talking about a new language, & new OS... Tempts me to ask...

(I think you 2 know me!)

@alcinnz @wizzwizz4 what would a modern Lisp OS look like…

I am too tempted

@alilly @wizzwizz4 And how readily could you implement HTML in it? That's where my curiosity lies!

Though a new OS on its own is interesting!

@alcinnz @wizzwizz4 I always focus in OS stuff on making something that would actually be somewhat practical to like, use, not just a research proof of concept.

@alcinnz @wizzwizz4 This bites me because I hit a problem like the dynamic linking issue with Rust and stop dead.

@alcinnz @wizzwizz4 anyway, microkernel-ish Lisp database-oriented OS, dangerous concept

@alilly @alcinnz Personally, I'm interested in a programming language that lets me experiment with various operating system designs in an "every prototype is usable" way.

Where lvalues are first-class objects, so e.g. I can say:

rax = Rax(7);
if f() then *rax = 14;
syscall(rax, &something);

and rax remains unclobbered while the lvalue is in scope.

I would usually use this language to bootstrap up to something higher-level, although it'd be nice to be able to write applications in it, too.

@wizzwizz4 @alcinnz I've definitely wanted to bootstrap a Lisp, I wonder what's the smallest Lisp you can get away with for writing a better Lisp in is.

@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…

@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).

@wizzwizz4 @alcinnz I've never done a compiler, so we're outside my realm of comprehension unfortunately.

@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...

@alcinnz @wizzwizz4 designing new hardware is /far/ beyond my comfort zone, but it's been fun to watch you go at it

@alilly @wizzwizz4 Thanks!
I love writing them, that's why I continue!

@alcinnz @alilly I'd be interested to see your take on Prolog. There have been several hardware implementations of it, over the years, but I suspect you'll come up with something new.

I'd also appreciate your take on miniKanren, the other language family in aphyr.com/posts/354-unifying-t.

aphyr.comUnifying the Technical Interview

@wizzwizz4 I'm looking into miniKanren: Is it basically an embedded (in Lisp or another language) version of Prolog?

minikanren.org/

minikanren.orgminiKanren.org

@wizzwizz4 O.K., the site (quite verbosely) explains that there's a certain logical purity to miniKanren that Prolog (by necessity of its time) lacks. I suppose that came across in the docs.

Which suggests that it'd be the more interesting one to design hypothetical hardware for!

@wizzwizz4 @alilly @alcinnz If you haven't seen this yet, you might be interested in one of Wirth's earliest attempts to write a programming language, PL/360. It's platform specific, being a smidge above raw assembly; but it seems very close to what's desired. I reckon it could be adapted with some effort to your platform of choice.

en.m.wikipedia.orgPL360 - Wikipedia

@loke @alcinnz @wizzwizz4 I haven't yet finished it but I do have some thoughts. The high-level design goals are similar to what I think mine would be (single-level store, objects instead of files, no processes), though I am considerably put off by the proposed strategy for crash resistance, which seems to be "don't have bugs."

@loke @alcinnz @wizzwizz4 Hm. :/ It has one of those middle-of-the-road "what if both capabilities /and/ ACLs!" access control systems. Plus it casually assumes all the object store metadata will fit in main memory and that it will be acceptably performant to test every entry against a user-provided filter function, /mentioning/ indexes without explaining how this approach would be able to use them. The two alternate checkpointing mechanisms discussed are both very wasteful of both space and time.

And then there's this sentence:

Experiments show that we will be able to run the thread-local garbage collector in a few milliseconds, which is good enough for most applications.

I don't think the author of this paper was thinking very carefully about the parts that didn't directly interest them.

It does appear to independently reinvent promises though (calling them "tickets").