Arc Forumnew | comments | leaders | submitlogin

Hi Maluta,

Not doing much work on the news app in Arc but have done and currently working on a news clone in Prolog.

> - Search functionalities

A while back I added a simple search bar. There's no indexing but it should work fine for smaller instances. Have you tried it?

> - Add new buttons features that exchange data with other services

I implemented data export in JSON similar to the HN API[0] in a fork a while back. That wasn't complicated, and I could probably add it to the Anarki repo if it's something you could use.

By 'exchange', do you mean sending to or receiving from? What services were you thinking of? The news app also has RSS feeds which could fit this.

> - Login with Google Account

For a starting point, it might be good to look at Racket's OAuth package[1].

> - Best practices on backups (since people are adding links) and protocols to avoid data loss and restore if I need to re-install.

All the data is just in the `www` folder (or `anarki/apps/news/www` as it is currently). A backup can be as simple as taking a copy of that folder. Restore is just copying a backed up `www` folder back into `anarki/apps/news/www`. Best practice would probably involve having automated backups and also doing off-site backups once in a while.



I'm still working on it, but it's just in my spare time. Better API functionality is definitely on the todo list.

I added a project page to the github[0] to loosely collect and organize forum issues and development. Anyone is welcome to contribute.


You might want to chat with @kennethrapp on the GitHub repo. I think that's the only one actively working on the news app. Feel free to open issues and PRs as much as you like. I sadly no longer develop on Arc, but I'm happy to answer any questions if you set about trying to build any of these features.

Regarding backups, all data is stored in a single directory on the disk, so just copying a tarball or zip file of it to some other server or S3 should suffice. The only protocol I'd recommend is being wary of switching back and forth between branches. The master (Anarki) branch has diverged in the file format in some subtle ways, and using the stable or official branch or any other forks may cause data loss. At least make a backup first before you try it.

Incredible! Minimalism in language design taken to a maximalist extreme! ^_~ This is what it's all about. And the documentation/tutorial material looks like the cornerstone of the success here.

Also notably, the input is different for each user, as is each answer.

So the code should be the same, but you can't use my input to get an answer you can check on their website.

The input is on the problem page. Scroll to the bottom of to 'get your puzzle input'. You should be able to get the output by running the commands I gave. It's just a numeric answer so not super interesting.

Also, where do we find

Would love to see some output. Thanks, Akkartik!

My solution using Clojure:

As with your Python solution, set operations were nice. `(set/intersection w1positions w2positions)` helped.

2 points by rocketnia 109 days ago | link | parent | on: Pg just released a new Lisp: Bel

That one was Believe, written in C11. Here's the link again:

Looks like there's another project now, BelJS, written in JavaScript:

3 points by rocketnia 130 days ago | link | parent | on: Pg just released a new Lisp: Bel

From the perspective of my time on Arc Forum, it's great to see Bel. For most purposes Bel is pretty similar to Arc, but the Bel guide goes into pretty extensive detail about how Bel is intended to work, and that's information that was pretty sparse for Arc implementers and maintainers.

The fact that Bel contains a full description of reading, printing, and even arithmetic and thread arbitrarion means when someone tries to implement Bel in a non-Racket language, they'll have a good idea of how much work they're getting themselves into. They won't get lost in Racket documentation trying to understand how Bel works, and they won't find themselves questioning whether they need to implement every single obscure Racket feature just because a Bel program might use it.

I think some of the specific design choices in Bel are a bit wacky, like using mutable lists to represent numbers, functions, and continuations. Frankly I hope people won't invest their time trying to implement it all with perfect precision. Still, the goalposts are far clearer than trying to implement Arc.


I'm seeing a few pairs of design choices in Bel that seem to be in opposition, which might be a sign that one of the two is a bug. I suppose I don't know how many of these will turn out to be actual bugs, how many will turn out to be by design, and how many will turn out to be spurious products of my own misunderstanding.

1. Why do missing arguments to prims like `join` and `car` default to nil? In contrast, why do almost none of the functions defined in bel.bel have arguments that default to nil? It seems like the explanation for one of these would apply just as easily to the other, so I'm curious where the difference comes from.

2. Dynamic binding in Bel is a little surprising: "Dynamic bindings take precendence over lexical bindings, which take precedence over global ones." Does that mean we can set up dynamic bindings that interfere with the local lexical bindings of a function we call, like this?

  > inc.10
  > (dyn n 4 inc.10)
If Bel's functions expose their local bindings this way, then why do its macros go to the trouble to use gensyms (uvars) to avoid exposing theirs?

3. Exploring another consequence of dynamic binding: Considering the way Bel's macro calls are expanded at run time, can we can interfere with the local variables of macros' macroexpansion logic as well, like this?

  > (repeat 5 prn!hello)
  > (dyn init 'prn!4 (repeat 5 prn!hello))
If indeed we can do this, then why can't we do the same thing with Bel's special forms? Special forms' implementations are invoked at run time as well, but they're invoked using a plain function call in the interpreter rather than using `applyf`, so it looks like they have access to the dynamic scope of the interpreter host rather than that of the interpreted guest.

4. In the the printer, special care is taken for strings: "strings are lists and can thus share structure with other things we're printing." Shouldn't the printer pay the same kind of attention to numbers, since those are also lists?

4 points by rocketnia 130 days ago | link | parent | on: Pg just released a new Lisp: Bel

There's at least one implementation attempt starting up here:

Other name ideas:

- (isa bel)

- Rebel -- similar in theme to "Anarki," although there's already an unrelated Racket library called "Rebellion"

- Bombelli -- analogous to the spelling of "Anarki," and it can refer to a mathematician credited for putting complex numbers on solid ground

- Pachelbel -- would be a good name for an implementation written in D :-p

3 points by krapp 133 days ago | link | parent | on: Pg just released a new Lisp: Bel

I assume someone is already working on a Racket implementation.... wish I knew how, it looks like it would be fun.

Might I suggest calling it "Babel?"

2 points by breck 133 days ago | link | parent | on: Pg just released a new Lisp: Bel

Woohoo! 3 text files. So simple. Looking forward to playing with it.

It's also just very cool that he is still doing great science.

4 points by zck 133 days ago | link | parent | on: Pg just released a new Lisp: Bel

And he posted a "Show HN":

I was a bit shocked when I saw this and wondered how they’d handled tail call optimization since there’s no nice way to do a computed jump in web assembly. It turns out it relies on the new tailcall extension to web assembly that isn’t enabled yet in most browsers.

Still this is pretty cool! A lot of languages have web assembly compilers but few seem to make self hosting a priority.

2 points by jsgrahamus 164 days ago | link | parent | on: Fleetdb

Project seems to have been inactive for 5 years.

Best link I found is

2 points by breck 176 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 177 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 177 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 196 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 202 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!