I know of 2 examples of Lisp being used to develop an OS (there may be more): one by Symbolics (called Genera) and the other by Lisp Machine Inc (aka LMI). Apparently both of these descended from code developed at MIT's AI Lab. Googling, it sounds like some of the source code for one of the versions was released as open source.
Of course, Lisp Machine Lisp (or Zeta Lisp, et al.) are not the same as Arc, but I expect that what you can do in one, you can do in the other. Small matter of programming :-)
The interesting question is not the implementation language, but what you intend to build.
Arc is a pretty small codebase built on Racket, so I think if there's an answer to "Can Racket be used to write an OS?" then the Arc answer follows close behind.
I can imagine two distinct ways you might be interested in OS development, so I'll answer twice. :)
Personally, when I think about writing an OS, I'm motivated mainly by the prospect to design new ways that "applications" can be obtained, upgraded, and integrated with each other.
I would not want to develop low-level memory management code and device drivers. That would open up a can of worms in terms of security issues, not to mention the expense of keeping up to date on the latest hardware and the latest machine-code-based security topics. So my "OS" would ideally sit on top of another OS kernel.
For that kind of application, Racket could be great. Racket has tools for running computations in sandboxes with limited memory, so it should be practical to run a new kind of "application" this way as well. Looks like there's a way to run any X Window System client program as a kiosk (https://raspberrypi.stackexchange.com/questions/11866/how-ca...), which can probably be used to run a Racket GUI application. So it seems like all the tools exist to make a Racket program take the place of an OS desktop and manage its own applications.
Since Racket has these sandboxing and GUI features, technically Arc can invoke them too, since Arc can run Racket code. However, I don't think I've seen anyone use these features in Arc code yet, so it might be easiest to learn them in the context of writing a program in Racket itself.
On the other hand, if your goal is to do things that involve machine code, kernel privileges, and device drivers, you'll pretty much want a language where the run time semantics is very similar to machine code, with the ability to refer to specific memory addresses and the ability to initialize and manipulate its own call stacks. In many cases where you're using functionality specific to an architecture, such as booting up and initializing a first call stack, you'll need to write assembly code so that you know precisely what machine code is being generated.
There are many "C replacement" languages out there, but the one that I consider most approachable right now is Rust. It's easy to find a number of tutorials and examples of OS programming in Rust, and Rust is sort of a codification and streamlining of many techniques that have caught on in C, so the skills may be somewhat transferable between those languages.
In short: Racket (and hence Arc) has a lot of the high-level tools for making OS-like systems, but it's probably not good for the parts of an OS that require meticulous attention to machine code. I recommend something like Rust for those.
What OS skills or projects are you thinking of pursuing anyway? :)
I don't know if I'd ever want to use this 2D syntax directly, but I'll probably "use" it as a thought experiment for non-hierarchical syntaxes, along with cellular automata and spreadsheets. :)
Can you imagine an 'unquote-splicing operation for this tabuleau syntax? Between lists, 'unquote-splicing can insert any list into any other, but the cells of these tables have externally imposed sizes and shapes, so for an 'unquote-splicing in a table (if we wanted one at all), we'd probably want to enforce that the sizes and shapes match up in a way that makes sense. What might make more sense is to do 'unquote-splicing in a full row or column at once, because at least we get one dimension of freedom that way. If the splice takes up a full row, then it can splice in any number of rows (of any height) to that location.
I'm probably a little obsessed with quasiquotation lately. I've been trying to write an implementation of a macro system where the meanings of notations like 'unquote, 'unquote-splicing, and parentheses themselves can be treated as user-defined macros, and where syntax-bound concepts like source locations and syntax highlighting are mostly managed automatically in the macroexpander rather than something every macro must deal with (except for the macros that do something unusual with them).
Welcome back, conanite! I was coincidentally just thinking about you yesterday when I ran across your bug report at http://arclanguage.org/item?id=10485. Too bad that bug is still open in both Arc 3.1 and Anarki. I think I will try to fix it now that I've spotted it.
I guess the quote idea came from me thinking that the strings were being evaluated. My untrained mind thought "strings evaluate to themselves", but apparently not. So I used the single quote to prevent evaluation.
Since I was delving into the Arc codebase and my Lathe codebase anyway, I made a bunch of fixes to Anarki, Anarki's stable branch, arc/nu's arc/3.1 language, and Rainbow.js today. It's enough to run a simple check of Lathe's module system on Windows, which meant I fixed a bunch of Windows bugs in particular! My Lathe sanity checks also worked fine on Rainbow, Jarc, ar, and the official Arc 3.1.
I understand, I think. I think it adds regularity, which is a benefit and drawback, like it is with Lisp's parentheses. But I got used to Arc's (a:b c) at a time when I didn't need a strong reason; the fact that someone put it in a language was enough to convince me it was worth a try, and by "try" I mean using it everywhere I could. :)
This Parendown syntax tackles the a lot of the same needs as quotation sugars, right-associative infix operators, multi-branch conditionals, and imperative blocks. Those individualized pleasantries no longer need to exist as much, but some of what was pleasant about them might slip through the cracks and be neglected entirely by the more regulated approach. Lisp's parentheses didn't solve the things this does, and this doesn't solve some things that other syntaxes do (such as left-associative infix operators, perhaps).
Programming this way in Cene for a while, one thing I keep wanting to reintroduce is quotation sugar. But that's probably unrelated; Cene has a more elaborate syntax for quotation to help with programs that involve several nested quotes, and since I only actually use it in shallow cases, it's a bit hard to explain why I've made it so elaborate. :-p A sugar would brush some of that complexity under the rug until it's useful.
I developed Parendown over the last couple of days as my first foray into Racket #lang extension.
This is a syntactic feature I've had in the Era languages for a long time, and it has such a drastic effect on the language's appearance that I always feel like I need to go out of my way to explain it. It's just a simple s-expression sugar inspired by Arc's a:b ssyntax, but it's so handy.