My first thought is a package system based on melpa / use-package from emacs. Please point out if something like this has already been done and I have just forgotten it.
Basically, just a simple index and package fetching system that pulls libraries directly from github or other vcs sources. Then we only need one file in the standard library "package.arc", that provides functions for querying the index and fetching packages from github into a ~/.arc directory, supported by a macro like use-package from emacs (https://github.com/jwiegley/use-package) or 'ns from clojure.
An important point here is that a package fetching utility can be independent of any module system. Which is good, because we don't really have that yet. The emacs community doesn't seem to think one is necessary; everything is just imported into the global namespace, and prefixed with the package name if necessary to keep it separate. Maybe we could make some macros to simplify the prefix process, but that could quickly get complicated.
We could also experiment with some avant garde packaging ideas, such as akkartik's thoughts on avoiding version pinning, searching the vcs sources directly for the package, or building the community CI tools that automatically find downstream dependencies and run their tests against your lib changes.
> My first thought is a package system based on melpa / use-package from emacs.
That would be great! Use-package is amazing, and that (combined with similar loading things from package.el) could make loading dependencies way easier. I know that when I'm writing arc code, I'm reluctant to use libraries -- even libraries included with arc -- because they're (afaik) impossible to automatically load.
> We could also experiment with some avant garde packaging ideas, such as akkartik's thoughts on avoiding version pinning...
Amusingly, the Emacs ecosystem can be thought of as a package manager that avoids version pinning; the standard package repositories (GNU Elpa, Melpa) only keep the latest version of a package around; you can't install older versions.
Of course, I know of no package foo.el that introduced _foo2.el_ when breaking backwards compatibility. So we can maybe do better that way.
That would be nice I suppose, but we can't actually modify the arclanguage forum, so it would be of limited benefit. I guess a lot of people come to arc because they want to run an HN clone though, so it might be worth pursuing.
> File upload
Yeah, I think enhancing some of the fundamental web-service functionality in arc would be good. Beyond file upload, better support for OAuth, ssl, etc. would be good too.
Good idea. Not sure how to make that better myself, but demystifying and enabling easy ecommerce would be cool.
I think that also has the same motivation for the previous category; we need better support for web application development, because that's what most people want to do.
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?
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:
* hide item
* past front pages
* show all stories from same site by clicking on domain name