If not ':' then '..' is also possibility, like (a 5..9),
but to be honest i like your version, it's more Lispy. But maybe syntax '..' could improve readability? Compare:
(a b c)
(a b..c)
You write (about ar) "Much of Arc remains unimplemented", so is it better to use mzsheme version for now?
Nope, no can do. "." is used for ssyntax as well. To be specific, foo.bar is equivalent to (foo bar) Thus, setf would need to be a macro, or we'd need to give up on ssyntax. I like ssyntax, so I'd go the macro route, personally.
---
"You write (about ar) "Much of Arc remains unimplemented", so is it better to use mzsheme version for now?"
Oh, no! I've been using ar for quite some time now, it works beautifully. I think awwx is being silly when he says that "much of Arc" is unimplemented. It's mostly implemented, and the stuff that isn't implemented, I don't use, so I don't notice... I'm at the point where the idea of using Arc 3.1 is absurd: ar is definitely the way to go.
My libraries are designed specifically to work only with ar, though some may work on Arc 3.1 with some tweaks... My apologies for the incredible number of files in the ar branch, there's not much I can do about that...
---
By the way, you shouldn't use my old branch. It's there for historical reasons, and so that I can pull in changes piece-meal into current ar. Using the latest version of ar (I give the link above, in this post) is the way to go. Sorry for the confusion.
"Nope, no can do. "." is used for ssyntax as well."
Even though . is used for ssyntax, .. isn't, at least in Arc 3.1. While (ssyntax 'a..b) returns t, ssexpanding anything with .. in it throws an error.
You've talked about classifying ssyntax as prefix, postfix, and infix before, so I suspect you'd want a..b to expand through (a .b) to (a (get b)). As for me, I think it's nicer to treat multiple-character sequences like .. as their own operators.
Great that it's already there. Is there a way to do foo[5:]?
And about docs - you are right, the best is to read the source-code. But the problem (as you pointed out) is when you have something you want to solve, it's hard to search for it in source-code. If you want to append strings and you don't know that + does it, source code will not give you an answer (unless you read the whole thing carefully). In Racket, you can search using human language in Racket Reference or Racket Guide.
Anyway, is there a centralized page, where you can get most links to Arc resources?
It's not as short as the Python version, but it works well enough. Basically, you can pass nil to mean the "default value".
That means that (foo nil nil) is the same as foo[:] in Python (this creates a copy of the list). The defaults are (foo 0 (len foo) 1)
---
"If you want to append strings and you don't know that + does it, source code will not give you an answer (unless you read the whole thing carefully)."
Right. I was working on solving that as well, by grouping arc.arc into different "sections". So you'd have a section for "assignment", a section for "scripts", a section for "file system", etc. I believe this approach is actually better than English prose documentation. Unfortunately, I have not done this for the latest version of ar... it's only on my old branch[1], which is sorely outdated.
---
"Anyway, is there a centralized page, where you can get most links to Arc resources?"
If you're looking for libraries, you can try Anarki[2], or rocketnia's Lathe[3], or my lib branch[4].
My branch currently has a library that implements slicing (already shown), a lib that implements a very simple and lightweight object system, a lib that implements a hacky (but working!) namespace/module system that uses inheritance, and a compiler that can take an Arc expression and convert it into a JavaScript string, that can then be executed in your favorite JS engine.
I should warn you that my arc2js library is severely outdated. I've made many many changes and improvements, and plan to push them to my branch (eventually). In addition, the import.arc library is very very hacky (in particular, the way it deals with macros), so I personally wouldn't use it just yet. It's mostly a proof-of-concept at this point.
