Arc Forumnew | comments | leaders | submitlogin

There's really not much happening in CL that can't be achieved in Clojure (or vice versa for that matter). Just grab a library and write your macros to obtain your desired level of brevity/utility. The first thing I did when moving from Arc to Clojure was port over the web service routing along with the html/json generators & parsers. Since then my server code has morphed into a custom unique hybrid, and now when I look at all of these other examples I think ugh, I'll pass thanks.
4 points by akkartik 23 days ago | link | parent | on: List comprehensions in Arc

musk_fan, your initial attempt inspired me to build on it :) Now that we can enumerate from a start number to an end, I hanker after something more comprehensive. Also, after reading malisper's description of iterate at, I thought I'd try to mimic its syntax, in hopes that it'll fit better with a Lisp and be extensible.

Here's what I ended up with: Is the description clear?

2 points by akkartik 23 days ago | link | parent | on: List comprehensions in Arc

Great! A few comments:

1. Is there a reason you start with `(1) and then pop? Why not just initialize lis to nil?

2. Here's a slightly more idiomatic implementation (also more efficient, because it avoids deconstructing and reconstructing lis on every iteration):

    (def l (start end)
      (accum acc
        (for i start (<= i end) ++.i
Read more about accum and for:

    arc> (help accum)
    arc> (help for)
(I'm assuming Anarki in the above example. The Arc version is slightly different.)
3 points by musk_fan 23 days ago | link | parent | on: List comprehensions in Arc

I wrote a simple version that only works like so (l 0 9) == '(0 1 2 3 4 5 6 7 8 9):

     (def l (start end)
       (let lis `(1)
         (pop lis)
         (while (<= start end)
           (= lis `(,@lis ,start))
           (++ start))
The (collect ...) structure is really cool; I'd forgotten about that; it's been awhile since I touched CLisp
4 points by akkartik 27 days ago | link | parent | on: List comprehensions in Arc

Yes, Arc doesn't come with list comprehensions. But it sounds like a fun exercise to build say a collect macro:

    (collect x for x in xs if odd.x)
I think it may be similar to the loop macro in Common Lisp. There's a Common Lisp implementation of loop at (via by malisper)
5 points by i4cu 27 days ago | link | parent | on: List comprehensions in Arc

I don't know python per say, but I don't believe arc supports them. I do know the iterator functions are there for you:

Before he concentrated his coding efforts on APL, I believe that he mostly used Chez Scheme.

He as in the original author.

He's made a point in the past about the utility of being able to see all of your code on a single page, or perhaps just a few pages.

Another interesting page is:

Good to see that your minds have been moving along the same tracks.

Wow, perhaps I should become an APL programmer. (My links below are probably familiar to everyone here, so forgive the shameless replugs. I'm mostly just working through commonalities for my own self.)

"[There is] a sharp contrast between Subordination of Detail and Abstraction as the term is commonly used in Computer Science. Iverson’s notion of subordination is the elimination of notational obligations through the use of generalization, systematic extension, and implicit guarantees. The usual notion of abstraction is the means by which 'API' barriers may be introduced to implement conceptual frameworks that suppress underlying implementation considerations in order to allow a black box reasoning at a different, non-native abstraction level."

I'm very partial to this point, but confusingly I've been calling Iverson's notion of subordination of detail "abstraction", and Iverson's notion of abstraction "service" [1] or "division of labor" [2]. Though lately I try to avoid the term "abstraction" entirely. That seems on the right track.

Regardless of terminology, this is a critical distinction.

[1] [2]


"Common practice encourages decomposing a problem into very small components, and most programming languages emphasize a clear picture of a small piece of code in isolation. APL emphasizes finding ways of expressing solutions around the macro-view of the problem."



Quoting Knuth: *"I also must confess to a strong bias against the fashion for reusable code. To me, re-editable code is much, much better than an untouchable black box or toolkit."

Compare me: "Watch out for the warm fuzzies triggered by the word 'reuse'. A world of reuse is a world of promiscuity, with pieces of code connecting up wantonly with each other. Division of labor is a relationship not to be gotten into lightly. It requires knowing what guarantees you need, and what guarantees the counterparty provides. And you can't know what guarantees you need from a subsystem you don't understand."


OMG, he's talking about "big picture" and "optimizing for the rewrite" I call the latter rewrite-friendliness at And "big picture" is in the navbar on the right of my side.


Ok, that's enough replugging. The most tantalizing idea for me here is to try to get structure to do some of the heavy lifting that names do in more conventional languages.

As a final note, this link somebody showed me today seems really relevant:

As I remember, brevity was one of PG's goals in creating Arc. That thought came to mind as I was reading this article.

I haven't engaged in APL programming but I have done some in other array languages (Klong, J and Q'Nial) and the practice has been enjoyable, not only in getting the answer but also in learning a new way to think/twist one's mind.

4 points by akkartik 60 days ago | link | parent | on: Quitting the arc server

Not at all. I meant that if your server doesn't serve much traffic it'll spend much of its time inside serve-socket blocked on a new connection. It's only after serving a connection that it'll loop around to check quitsrv.

I just ran an experiment, and indeed the server stops after one more request:

    $ ./run-news
    initializing arc..
    ready to serve port 8080
    arc> (= quitsrv* t)
    ; now browse to localhost:8080; page served
    quit server ; printed by *serve*
    ; hit reload on localhost:8080; no response
4 points by noobie 60 days ago | link | parent | on: Quitting the arc server

Thank you for your help!! Could you help me understand what you'd like me to do?

I'm not sure what you think I should try.

After looking up the definition of the 'until' macro, the line of code referenced seems to tell me: if quitsrv* is not nil, then continue to serve-socket, which looks to me, at a noobie's glance, as returning the function "accept-request-with-deadline", opening up threads to serve the request?

i.e., quitsrv* now returns t. According to this definition, doesn't that mean that serve-socket should stop?

And incidentally, when I run more defop macro calls, it returns the 'procedure' but (asv) doesn't work; none of the new page on localhost show up (instead it is "Unknown"). I'll look more into it but not really sure how to proceed after glancing at (def asv).

I've copied down the definitions for while and whilet from arc.arc but they don't seem helpful at first glance. Will look further into them if you think it would be useful.

Thank you!!

4 points by akkartik 61 days ago | link | parent | on: Quitting the arc server

Not a dumb question at all; there may well be something broken here.

It'll be a few hours before I can try running it, but one possibility: perhaps it will quit after serving one further request? Looking at the code ( I think it's waiting on serve-socket before it gets around to checking quitsrv again. Can you try that if you haven't already?

And thank you :) I'm glad you got something out of it, because the project's certainly better for it.

I tinkered with Anarki a whole bunch and finally got this working smoothly. There was a missing step, because it turns out we need to load certain Racket-side bindings into a namespace in order to be able to evaluate Arc code there. It seems more obvious in hindsight. :)

I approached this with the secondary goal of letting a Racket program (or a determined Arc program) instantiate multiple independent intances of Anarki. The ac.rkt module was the only place we were performing side effects when a Racket module was visited, and Racket's caching of modules makes it hard to repeat those side effects on demand, so I moved most of them into a procedure called `anarki-init`.

By adding one line to the example I gave...

  (= my-definition
    (let my-ns (nsobj)
      ; Load the Arc builtins into the namespace so we can evaluate
      ; code.
      (w/current-ns my-ns ($.anarki-init))

      ...)) becomes possible to evaluate Arc code in that namespace, and the example works.

I used issue #95 on GitHub to track this task, and I talk about it a little more there:

Before I started on that, I did a bunch of cleanup to get the Anarki unit tests and entrypoints running smoothly on all our CI platforms. To get started on this cleanup, I had a few questions hjek and akkartik were able to discuss with me on issue #94:

A lot of the problems I'm fixing here are ones I created, so it's a little embarrassing. :) It's nice to finally put in some of this missing work, though. I want to say thanks to shader and hjek for talking about modules and packages, provoking me to work on this stuff!

4 points by shader 67 days ago | link | parent | on: Yet another post regarding Arc & Heroku

I should mention that if what you want from Heroku is their deployment process, you can actually replicate some of it pretty easily with Caddy (though I have not done so yet myself; I plan to soon...)

Specifically, they have support for automatically fetching code from git and running a command in the repo, either periodically or triggered by a webhook:

That doesn't get you the app ecosystem that heroku offers, but you can get a lot of that pretty easily via docker and docker-compose now.

5 points by shader 67 days ago | link | parent | on: Yet another post regarding Arc & Heroku

I've recently discovered the Caddy server (, which makes SSL and application proxy deployments super easy. Like, 2 lines of config:               #uses the domain to automatically set up SSL with Let's Encrypt
  proxy / localhost:8080   #redirect everything to Arc on 8080
I will say that Arc runs a bit resource intensive, and the slightly slow boot times mean you don't want it to have to re-launch because of infrequent requests. I don't know how well it would work on Heroku.

Also, some VPS services like offer $5/mo nodes that have more resources than what you get from Heroku at $7/mo anyway.

Cool, thanks for the reply :) I've seen it discussed elsewhere that the way to have SSL (at least with the News example in the repository) is to run through Nginx.

Did that complicate your setup by much?

I don't really know Heroku, sorry, but to answer your final question: It was a while ago, but I used to host an Arc webapp on a VPS behind Apache/Nginx.

It looks like I might've subtly broken ns.arc with my own changes to make Anarki installable as a Racket package. Here's an example that should be working, but currently isn't:

  ; my-file.arc
  (= n 2)
  (= my-definition (* n n))
    (= my-definition
      (let my-ns (nsobj)
        ; Populate the namespace with the current namespace's bindings.
        (each k (ns-keys current-ns)
          ; Racket has a variable called _ that raises an error when
          ; used as an expression, and it looks like an Arc variable, so
          ; we skip it. This is a hack. Maybe it's time to change how
          ; the Arc namespace works. On the other hand, copying
          ; namespaces in this naive way is prone to this kind of
          ; problem, so perhaps it's this technique that should be
          ; changed.
          (unless (is k '||)
            (= my-ns.k current-ns.k)))
        ; Load the file.
        (w/current-ns my-ns (load "my-file.arc"))
        ; Get the specific things you want out of the namespace.
  arc> n
  _n: undefined;
   cannot reference an identifier before its definition
    in module: "/home/nia/mine/drive/repo/mine/prog/repo/not-mine/anarki/ac.rkt"
The idea is, you create an empty Arc namespace with (nsobj), you use `w/current-ns` to load a file into it, and you use `a!b` or `a.b` syntax to manipulate individual entries.

An "Arc namespace" is just a convenience wrapper over a Racket namespace that automatically converts between Arc variables `foo` and their corresponding Racket variables `_foo`.

For some overall background...

I wrote ns.arc when I didn't have much idea what Racket namespaces or modules could do, but I was at least sure that changing the compiled Arc code to more seamlessly interact with Racket's `current-namespace` would open up ways to load Arc libraries without them clobbering each other. It wouldn't be perfect because of things like unhygienic macros, but it seemed like a step in the right direction.

I went a little overboard with the idea that Racket namespaces and Racket modules could be manipulated like Arc tables. However, that was the only clear vision I had when I embarked on writing the ns.arc library, so I approximated it as well as I could anyway. In fact, I don't think the utilities for generating first-class modules (like `simple-mod` and `make-modecule`) are all that useful, because as I understand a little better now, Racket modules are as complicated as they are mainly to support separate compilation, so generating them at run time doesn't make much sense.

I'm still finding out new things about what these can do, though. Something I didn't piece together until just now was that Racket has a Racket has a `current-module-name-resolver` parameter which can let you run arbitrary code in response to a top-level (require ...) form. I presume this would let you keep track of all the modules required this way so you can `namespace-attach-module` them to another namespace later. Using this, the kind of hackish partial-namespace-copying technique I illustrate above can probably be made into something pretty robust after all, as long as Anarki sets `current-module-name-resolver` to something specific and no other code ever changes it. :-p

> Were you thinking a mobile friendly web app, or trying to run it natively on a phone?

The java/js ecosystem has the largest reach making it the easy choice. One could work on a js compiler and target pouchDB as a starting point. That said choosing js also makes Arc go further down the path Clojure has already gone putting the two closer together, and with Clojure being so far ahead in that arena then maybe it's doomed to fail. The other way to go is to do what Clojure is not great at. iOS development? maybe integration with swift? At any rate I'm not a language development guy. I can only tell you what would appeal to me. I mostly use Clojure and a really easy to use arc->iOS app development ecosystem would be really cool.

I agree.

Some newbie friendly documentation to ns.arc would be great, or perhaps some very simple examples. Have you tried using ns.arc?

> Forks that restrict where they get good ideas from will be outcompeted by forks that don't.

That is so true. LibreOffice and Gitea come to mind, but also what happened with io.js/nodejs.

> Without the ability to share code easily, it's a lot harder to build on and benefit from community effort.

I've just been dumping my Arc experiments into the Anarki repository. Akkartik manages it by the policy that pretty much anyone can commit anything, so I haven't had any issues sharing my code. I've recently put a Puredata compiler in Arc in there,

That said, there is an Arc package manager, Hackinator by awwx.

Perhaps that is worth a look?

The interactive help in Anarki is great, although there are some undocumented functions. A great improvement, which would be very easy to implement, would be to add the documentation from the various Arc sites to the Anarki interactive help.

3 points by hjek 76 days ago | link | parent | on: Next steps

It's true that unvote wouldn't make it to Arc Forum as it's never updated, but the same is true for any new feature, sadly.

Regarding SSL, I've been working on an example Nginx + LetsEncrypt secure reverse proxy configuration for Arc,

It's just insane that Arc Forum doesn't encrypt HTTP but, well, as you write, we can't change Arc Forum. Maybe they'll update it some day, or someone will set up an unofficial one that's more up to date?

Regarding web application development, there's already an interesting web based app development interface,

It looks quite humble but it has both a repl and an interface for saving/running various web apps.

I've set it to be enabled by default in Anarki. And it's only available for admins, because it can run system commands. I wonder if it would be possible to allow any user to develop apps securely, e.g. by disabling unsafe commands or sandboxing it somehow? Perhaps there is a simple way of doing that? It could open Arc web app development up to any user of an Anarki driven page.

I think those features mentioned above still need better documentation, too.

Other HN features that Anarki News is lacking:

* favourites

* hide item

* past front pages

* show all stories from same site by clicking on domain name

Maybe we should emphasize the flexibility of our language designs by making the language itself more modular. It would be challenging from a compatibility/dependency standpoint, but those are problems we might have to solve anyway. It would help to have better isolation of components.


I was confused for a second or two, because the current top post on that site is almost identical to the one you commented on a year ago.

(What are you working on this week? by caius)

> I don't have a short-term answer for how to solve Arc's users-vs-libraries chicken-and-egg problem ^_^

Be the change you want to see in the world... I'm not really sure how to motivate the community, but I am rather attached to it, even if I have been a very infrequent lurker over the past years. We have had a relatively high amount of discussion over the past few days though...

I don't think we can just expect to flip a switch and suddenly get a community; we have to /be/ a community, and then people might be willing to join us.