Yes,but no. Once you get in the code of ac.scm, you see that the code is great (really easy to understand everything) but that it can really be optimized in trivial ways.
We already talked about arc<. The original code was : if all the elements are numbers, apply numeric + to the args. If all are strings, apply string-append. If all are lists, apply append. Else, apply numeric + (again). The optimization is obvious there, and I don't think it can be called premature.
There was another one that was fixed by pg in Arc2 (for those interested, it deals with ar-funcall).
I know I wasn't clear. I don't want Arc as fast as light right now. What really bugs be is the fact that I have to wait 3 seconds before I get the prompt. When arc.arc and libs.arc are loaded. That's what I would like to see optimized, as soon as possible.
This is potentially an issue if you open up intrasymbol syntax though. It'd be pathologically dumb, but what happens if I set up - to be an intrasymbol macro?
Solution: perhaps user defined intrasymbol macros should be surrounded by colons (:-:) by convention? Do intrasymbol macros support multiple characters?
Of course, that means that any designer has to be fluent in Arc's libraries as well.
Not to suggest that Arc's method is anything short of perfect for what Arc does, but a big benefit of MVC is how separation of logic and presentation reflects separation in personnel.
The seperation of logic and presentation doesn't belong between code and HTML, it belongs between HTML and CSS. HTML is best controlled and generated programatically. Arc does it right, Rails does it wrong.
I'm not sure what your professional experience making websites is, but mine has shown me time and time again that making good looking sites is an iterative process full of workarounds for real-world considerations.
The method you're suggesting would make it excruciating to converge on a good design with any real designer. Look at the markup any good looking and well-implemented web page (especially one with dynamic content), and you'll see a huge amount of extra tag work to accommodate the real world of cross-and-backwards-compatibility between browsers, CSS limitations, browser quirks, and other concerns that people making professional sites require.
If every one of these changes and workarounds required changes to the code, which would require my time instead of the designer's time?
The Rails way is just copying a method that nearly every web toolkit uses, and they use it for a reason. Arc's way may be cleaner, but without a templating language it will be at a disadvantage.
- If you get the layout, including both how it should look and how things should work, from an external source, or if there is substantial external input, use templates. It will save time and headache.
- If you are just about the only one responsible for the layout but support skins (for lack of a better word; the CSS part), use the HTML tag functions and macros embedded in Arc.
Since Arc is at this point targeted for exploratory programming, the former is an unlikely case.
What I would like to see, though, is a templating engine akin to HTML::Template [1] in Perl 5. It has the minimum of control structures and extra syntax on top of standard HTML, just enough to make it possible to use the template for dynamic content. All templating frameworks suffer from the same fault, though: they define a new but severely restricted embedded language that's mixed in an unpleasant way with the HTML source. The language embedded in Arc is a much cleaner way to do things.
Complex designed websites are pretty much impossible using Arc's current library. Well, unless you're a programmer/designer with a high pain threshold.
When Arc is no longer classified by whatever greek letter comes before alpha, it might be worth investing into a nice way to separate out some MVC/MTV/VH1/&c.
I know this has been pg's convention in the code, but in my code I've been keeping the indentation at the same level. Since code tends to shoot off toward the right, you get code that look like:
It's pretty easy to count off condition/result pairs like this, but if you indent the results it gets more difficult to pick them out from the conditions.
Somewhere earlier pg suggested that he'll probably want to have more than just optional parameters at some point in the future. The idea was that at least as of now (o ...) is more robust.
This would also allow things like a splice operator (mentioned here: http://arclanguage.org/item?id=540); if we had this (assuming that @x expands to (splice x)), you could write (let arglist '(4 5 6) (list 1 2 3 @arglist 7 8 9)) and get (1 2 3 4 5 6 7 8 9). This would actually be superior to apply in certain cases: (and x y @arglist) wouldn't have to evaluate y or the parts of arglist, whereas (apply and x y arglist) has the same effect in most cases, but does evaluate y, which can be problematic. I suppose one way to solve this would be to give values a "cer" (Current EnclosuRe) or some such; if lst were '(1 2 (a b) 3 4), then (cer x) = nil, (cer (car x)) = x, and (cer (car (list-ref 2))) = (list-ref 2). It's not clear what (cer (cdr x)) would be, but it would probably also be x.
Personally I'd still implement this as a macro form, such that we would have a (spliceable ...) form which would scan its contents for splice-macros. So the syntax would look approximately like:
(spliceable ...) would essentially be a generalization of the `() operator, except that ` will only scan for , while (spliceable ...) would scan for any splice-macros.
