Arc Forumnew | comments | leaders | submitlogin
2 points by jsgrahamus 5 days ago | link | parent | on: Fleetdb

Project seems to have been inactive for 5 years.

Best link I found is

2 points by breck 17 days ago | link | parent | on: Visible Lisp Computer

Very neat. It would be cool if there were a live emulator you can see on the web to play with it in action virtually.
1 point by akkartik 18 days ago | link | parent | on: HTTP Request in ARC

Indeed. Here's an example:

    arc> (load "lib/client.arc")

    arc> (mkreq "")
    '(("HTTP/1.0 200 OK"
       "Cache-Control: max-age=604800"
2 points by tug 18 days ago | link | parent | on: HTTP Request in ARC

this seems to be part of it

Great! Yeah, I'd love to hear how you fare following the examples in the Readme.

The examples involving gen_iso take a while to run, which may be even greater atop VirtualBox. I'd recommend skipping those for now, particularly the very first one at the top of the Readme.

Thanks for this. I maintain Linux Virtual Boxes.

I built an Arc-inspired toy Lisp interpreter like, oh, 5 years ago: (Source code:

But the experience frustrated me. It was hard for me to understand all the software under me as I provided abstractions above me.

So I spent the last 5 years gradually eliminating all the layers of abstraction that add complexity to my Lisp interpreter. The path passed through one other language for teaching programming: The sources for it are archived at (there was an earlier prototype in Arc at

At this point I have a very simple syntax for programming pretty much directly in machine code: It can be translated to an ELF binary for Linux using about 250KB of static x86 instructions (80% of which are unit tests, and much else of which is duplicated because I built the translator in multiple passes that run in a shell pipeline:

    $ cat examples/ex1.subx |./tests |./dquotes |./assort |./pack |./survey |./hex > a.elf

The nice thing about the resulting ELF binaries is that they can be run directly on a Linux kernel with no other dependencies. Not even libc.

There's a script in the repo called `gen_iso` that can take a list of .subx files, translate them into an ELF binary and package up the ELF binary with just a Linux kernel into a bootable disk image. You can then boot this image either in Qemu or on a cloud service like Linode (

This is what I have so far.

By contrast, the screenshot is quite fake. It's just a program that reads a line of text from the keyboard and prints it out to the screen. You can see it running on an emulated computer in Qemu that has nothing but a Linux kernel.

But I'm going to build up from that core into a high-level language. Maybe an Arc-inspired Lisp. Not a toy this time around.

Just give me 5 more years :D

To reiterate the main project link: Should hopefully be pretty easy to get running on Mac or Linux. (Though you're mostly on Windows, right jsgrahamus? I'm really sorry I still don't know Windows well enough to support it :( )

What is this exactly?
3 points by akkartik 37 days ago | link | parent | on: Mu no longer requires C

As of last night, Mu can package up a codebase (Assembly files in my special syntax) with a Linux kernel into a bootable disk image and deploy it to Linode. I've updated the top of with details.
1 point by akkartik 43 days ago | link | parent | on: MakerLisp Embedded Lisp Machine

My MakerLisp machine is up and running!

>The big drawback: you have to give up '-' in symbol names.

I wouldn't have a problem with that, but I'm probably of a minority opinion, since that seems to be a Lisp thing. When I started with Arc it took me a while to realize that symbols with asterisks in the name weren't something special like pointers, and using angle brackets just seems wrong after years of writing HTML.

Although if it were possible to do something along these lines, one could have the best of both worlds:

    (defgrammar infix ...)
    (w/grammar 'infix (do


Have you seen my proposal for infix syntax for Arc? I think it's pretty nice: The big drawback: you have to give up '-' in symbol names.

We already have syntax in the form of bracketed functions (or whatever they're supposed to be called) and {} for tables.

I'm speaking out of my depth here, but I think it would be nice if scoped syntax extension were a "first class" feature of Arc. It would be nice to be able to load, say, native support for XML syntax as a library or something, or to easily extend the language through grammar definitions.

Also, infix notation in a Lisp? If I had a monocle I would drop it into my coffee with shock forthwith!

In the "State of Racket" presentation, Matthew Flatt talked about how it was a ripe time to start seriously pursuing "Racket 2" and thinking about radical changes that could be made to the language. Then he surprised many people by showing a slide with some infix syntax ideas.

We've had many discussions about s-expressions with syntax here at Arc Forum, and it looks like the Racket community is going to dive into that topic now. It could be the best time ever for us to get involved with the platform we've relied on.

3 points by akkartik 69 days ago | link | parent | on: Readable Lisp S-expressions Project

My critique:

The final straw for me was when I tried to actually _use_ sweet expressions for something. I described it here: (Warning: lots of bad ideas in this thread)

2 points by jsgrahamus 81 days ago | link | parent | on: Arc and Scheme in Emacs Lisp

Very nice. Thanks, Shawn!
1 point by akkartik 85 days ago | link | parent | on: MakerLisp Embedded Lisp Machine

I'm considering buying this machine in a month or so. (The author says the full system will be available in a month: .)

Hair loss would be due to trying to think in a Klongish manner. Have only gotten a ways into the Klong book.

Nils is a prolific author and has even written non-CS titles to include Yoga and Zen (in German).

Very cool! The codebase ( or the book (

I’ve spent uncounted hours enjoying and pulling out my few remaining hairs with Holm’s Klong. Look forward to reading this.

Thanks for the heads up, akkartik!

2 points by i4cu 125 days ago | link | parent | on: Beunto an experimental app builder

Hmm, haven't seen that one. I've done a search on my entire code base tree and 'randid' is nowhere in my code (of course that may not matter when it's a compiled jar file that's running).

Can you tell me your OS? I've only been using OSX so it's possible it's chrome on Windows? Versions would be great too, if you can :)

And is that a js error or a server error? I'm hazarding a guess it's a js error given I'm not seeing any errors on the server.


2 points by mpr 125 days ago | link | parent | on: Beunto an experimental app builder

Hey -- I tried to go to the link but nothing loaded. This shows up in the Chrome console:

"Uncaught Error: No matching clause: :randid"

2 points by i4cu 126 days ago | link | parent | on: Beunto an experimental app builder

Hey thought I'd post this over here (even though it's not really arc related!).

note this is in the very experimental stages. I wouldn't try it on mobile or IE yet.

Posted it on HN too,

but I think maybe it's a little too Alpha for a general audience.

3 points by kinnard 127 days ago | link | parent | on: Lisp in Forth: a small lisp in Forth

What do you build in forth?
2 points by jsgrahamus 127 days ago | link | parent | on: Lisp in Forth: a small lisp in Forth

Thanks for this. 2 of my favorite languages.
3 points by shader 129 days ago | link | parent | on: EdgeDB

Two points that make this relevant:

1. The EdgeQL language seems like a significant improvement over SQL, and is interesting from a language design perspective

2. The EdgeDB itself also seems like it should be pretty easy to use from an arc application, since they provide http and graphql query interfaces out of the box.

The 'Datafy' and 'Nav' protocol interfaces look really interesting.

From what I gather using those along with Clojure 'Spec' allow you to create ad hoc, generalized interfaces as an abstraction layer accessing an infinitely large lazy tree of 'things' (provided these 'things' are data or can hold meta data).

Unfortunately I have yet to see anyone really use it in the way I imagine it can be. I'd like to see a web 'req' var with the ability to drill down through the server-code<->js-code barrier (via the session and connection protocol) all the way down into the dom and the js application state. That would be really, really cool.

Also, I've been building a general purpose app builder (for web apps). This app building process is currently working, but in the future I'll need build a more advanced inspector and a designer. Since my stack is Clojure from server to js I'm wondering if it makes sense to build the inspector on top of that trio of technologies then attach the designer to it.

Someday I'll get to do that! ... I just know it. :)

Edit: for those who wonder what this has to do with REBL... these are the core technologies that REBL is built upon.

2 points by akkartik 141 days ago | link | parent | on: Ask Arc: Arc forum RSS

I like which slices through the ambiguous terms 'worse' and 'better' and focuses on the crucial ideological divide: do you think evolution is something to combat or something to go with the grain of? That fits with a lot of your comment as well.

But you should elaborate on your last 2 paragraphs. I'm not sure I buy either that Arc adoption can pick up or that the mainstream tech stack will ever cut out layers.

My synthesis of "Worse is better" for myself (with Mu[1] and SubX[2]):

a) I don't think of evolution as "bad". Building something incompatible is indeed maladaptive. I'm clear-eyed about that.

b) Mu doesn't try to come up with the perfect architecture that doesn't need to evolve. Instead it tries to identify and eliminate every source of friction for future rewrites.

c) My goal isn't to go mainstream. I'd be happy to just have some minor Arc-level adoption. I think it's better to have a small number of people who actually understand the goal (an implementation that's friendly to outsiders) than to have a lot of adoption that causes Mu to forget its roots. My real goal is to build something that outlasts the mainstream stack (the way mammals outlasted the dinosaurs). That doesn't feel as difficult. It's clear the mainstream has a lot of baggage bogging it down. It'll eventually run out of steam. But probably not in my lifetime.

Anyways, I hope in a year or so to give Mu an Arc-like high-level language. It won't improve Arc's adoption, but hopefully it will help promulgate the spirit of this forum: to keep the implementation transparent, and to be friendly to newcomers without burning ourselves out.



4 points by shader 142 days ago | link | parent | on: Ask Arc: Arc forum RSS

Sounds good.

I guess these improvements will only affect people using the Anarki implementation of the forum? It would be nice if we could get some upgrades to the original instance.

Specifically turning off the feature that disables replies on old threads, and probably switching to a most-recently-updated ordering scheme.