The sections under 'Web Serving' contain all the information about using Arc to serve web pages. You can also look at the source of news.arc in the Arc distribution to see an example of a completed web app. The Arc tutorial also contains some useful information.
I totally agree that these things should be non-global. In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).
But it's worth pointing out that there are work-arounds to a global read table. In CL, for example:
Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package? The base language could just be a very primitive one, and then everything else could go in a package. It would mean there is no real distinction between 'the language' and 'a package that defines its own syntax'. That feels quite Lispy to me.
> Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package?
Uh, yes. That's how it's already done. That's why arc.arc is itself a package. In fact, when you say '(in-package foo), the only thing that the contexter will add to the newly-defined package foo are the Arc axioms: '<axiom>fn, '<axiom>if, '<axiom>quote etc. That's why you have to declare '(using <arc>v3) for each package - because otherwise the language doesn't actually import arc.arc
Edit: Ultimately (and this is another disagreement with PG) arc.arc is a library, not part of the language. It's like the libc in this respect. Because you see, we already had the 150-year language 50 years ago.
Edit2: as an aside, the package system even lets you export a binding for 'quote, 'quasiquote, etc. In fact, once we have defined a formal method to add ssyntaxes, it would be possible to add support for `(let foo# ,foo (something foo#)) in a library, not in the language. How? By defining an export for 'quasiquote, say (interface v1 <auto-uniq>quasiquote), where <auto-uniq>quasiquote is a macro that expands to <axiom>quasiquote
> In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).
Hehe. It's in the arc-f/ directory more for historical reasons than because it's not a library, and also because it's treated specially (it gets precompiled to Scheme bytecode, for example).
As an aside, arc-f currently handles loading by wrapping a sizeable bit of 'load in 'atomic, but this is unnecessary, I think, if I use a thread-local for current-load-file* and friends.
I agree that frameworks should make things easy, but 'convention over configuration' doesn't do that. It just calls configuration by another name. If being hard to configure is a virtue, then I can show you lots of frameworks that do that ;)
The point is that there is a default config mate. So there is a "way" of the framework, so the majority of people who don't want to configure nothing, won't have to. That does make it harder to the minority, but those are probably already experienced enough to don't mind the pain.
I think all of those questions were pretty thoroughly answered in the original rationale essays for Arc. My only reservation is with question 4, because most of Arc could have been implemented as macros on another Lisp. That might change as it gets fleshed out.
Although current Lisp frameworks leave a lot to be desired, I'm not sure copying the other frameworks is a good idea either. They all seem to have serious flaws, and despite trying to make things easy, they are all seriously overcomplicated.
As for 'convention over configuration', I think this is a bit of a fraud. Rails simply turns the file system into a configuration file and provides scripts for modifying it (e.g. scripts to create a new project, add a model, add a controller etc.) How is this any different to creating a configuration file to hold the information and then providing scripts to write it for you? The real question should be: why do we need all this complication in the first place? With Arc you can create a simple web app in a few lines of code. You can even use features from the app server with almost zero configuration or convention. That, I think, is the way forward.
I could not agree more. Arc's web development model is the best I ever found. You can really make apps as fast as what Rails or Django offer, without being limited to CRUD applications or being stuck in an official way of thinking : in Rails, if your table is called pets, then your class MUST be called Pet (don't even think about not using classes), that's convention. If you have other conventions or if, in your mother tongue, the plural of "cheval" is "chevaux", well, too bad for you. Oh, or you can reconfigure the whole thing, of course...
Well, maybe a few functions providing a "preconfigured" framework for CRUD applications would be interesting. We would have all the benefits.
You can really make apps as fast as what Rails or Django offer
I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.
The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking.
* scalability of not requiring session affinity
* database libraries
* regular expressions
* Rails *huge* library
It's trivial (takes one line) to have a class with a name different than the table:
class MyPet < ActiveRecord::Base
set_table_name 'pets'
...
end
You can turn off pluralization in one line.
I hardly consider those minor changes to be reconfiguring the whole thing. You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc.
> "I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.
> The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking."
Oh, you are totally right about that. That's why I reimplemented the Arc web server in Lua. Now, I have libraries too (even if Lua isn't the richest language in this regard, at least communicating with the outside world is damn easy -- that's the language's goal). I think I'll try to write a small CRUD framework to see what can be done.
> "It's trivial (takes one line) to have a class with a name different than the table [...] You can turn off pluralization in one line.
> I hardly consider those minor changes to be reconfiguring the whole thing."
Ok, that was a little exageration. But to me it feels like bad design : why didn't they default to "the table has the same name as the class" ? That's simpler, easier to implement (no exceptions to take care of) and foreign-language friendly.
> "You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc."
I did it. It's especially when the application starts to be non-trivial that I hate having to fight with Rails designers' points of view to make my stuff work. On the opposite, with Arc/Luarc, the more my application grow, the better its design feels, because I have to make explicit things I considered implicit / subject to change in the previous versions.
That is probably only my own vision, but with the Arc model, I can see my applications becoming more mature and stable, while with the Rails model, I see them getting more and more patched, with more and more bureaucracy to make everything work.
Of course, it is still better than with, say, PHP, where it is bureaucracy and patches all the way down (that could be a motto : "PHP : patches all the way down").
Arc already does some things better than Rails. Consider the difference in effort between creating the Arc "hello world" application and the Rails one.
Personally, I think the only thing that went wrong in the history of Arc is that pg didn't correct people's misunderstandings about what it was, and what it was trying to achieve. A 100-year language is not going to be usable tomorrow, and a language designed by the optimal number of people (one) is not going to accept many patches!
If people want a practical language to use now (and there's nothing wrong with that!) then they should go ahead and build one. I'm happy to join any project that anyone may have for developing an Arc-like language. I might even start one myself (why not? It'll be fun!) if I have the time.
A language doesn't survive in its implementations, but in its ideas. Modern languages (especially Python/Ruby, but even C# and Java) are becoming Lisp. Dynamic typing, late binding, functional programming, closures, generic functions, MOP... the 'popular press' laughed at them, but now these are the hot topics in language design. Those ad hoc, informally-specified, bug-ridden, slow implementations of half of Common Lisp are getting better every year. Common Lisp and Scheme will die, but in 10 years everyone will be using Lisp, and they won't even know it.
The same goes for Arc. Clojure already uses some ideas from Arc (e.g. fewer parens in conditionals). If the ideas are good (and I think they are) then they'll spread. If people want to build new languages (e.g. Arc3F) that use them, then that spreads them further, That, I think, is the true future of Arc, as a source of eternal ideas.
I have to admit that Clojure looks very interesting. Functional programming, concurrency with software transactional memory, access to a huge Java library, conciseness, etc. It's also a Lisp-1 like Arc w/ Common Lisp style macros, but it has namespaces. It doesn't have TCO due to JVM limitations and I don't think it has continuations, so an Arc-like web server might be more challenging.
The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.
The Clojure version of Norvig's spelling corrector appears to be one line shorter than Norvig's Python version:
I would really like to see an Arc version of that. I translated Norvig's Python version to Ruby easily, so I expect that someone fluent in Arc could do it easily.
The other Lisp versions I've seen (Scheme/Common Lisp) were quite a bit longer and less elegant IMO.
I'm not super excited about Clojure's dependence on the JVM, but on the other hand, that gives it a huge head start with libraries and state of the art VM/JIT technology.
Rich Hickey doesn't seem to have the star power of pg, but he is very involved in the language and community. He seems like more of a Matz or Guido which doesn't seem that bad - he seems quite sharp in his web cast presentations.
I could be way off, but it seems like it would be easier to add Arc innovations to Clojure than to add Clojure-like concurrency support to Arc.
> continuations, so an Arc-like web server might be more challenging.
Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)
> The concurrency story is particularly interesting given the proliferation of cores and slowing of GHz.
This is true and I think the "extra-cycles-to-waste" property expected by PG isn't going to put out in a hundred years.
> state of the art VM/JIT technology
Forget the libraries. This is what's scary about any JVM language.
"Arc's server doesn't actually use continuations - it uses functions that serve as continuatinos. There's no call to 'ccc or any of the wrapping forms in srv.arc (at least none that I remember)"
That's right, no 'ccc. That's why I could implement it so easily in Lua (no real continuation in Lua either). As for TCO, I'm not sure it's a real problem in this case. Sure, a lot of simple functions are written in a recursive style, but they can be trivially rewritten in an iterative style.
This is only half-true. Clojure cannot automagically convert a self-call in the tail position in to iteration, but it does have the recur form to provide essentially the same semantics. I've also found it useful that recur throws an exception if used outside of the tail position, making it obvious which recursive forms consume stack space and which do not.
I personally feel that a language core should be the work of a single person. Period.
The core set of axioms that form a language are almost fundamental as the laws of nature to that language. Just imagine theory of relativity being developed by several scientists together... almost impossible.
Even 2 persons should not work together on a language core. The quantity of communication required if 2 persons work on a single language is so large, that hinders and messes up the development process.
If there's one place where the saying "Too many cooks, spoil the soup" applies; its core language design.
If you're using Anarki, you'll find that the files used by news.arc have been moved to arc/arc/news_public_html. If you put your gif in there it should work fine.
