I'm sort of around-ish. I don't really do anything with Arc anymore, but I occasionally browse the forums (e.g. now). I'll certainly reply to any direct questions.
For GitHub repos, you have to request public-push access specifically. If you're setting up a repo on your own, it's not an issue of configuration, but of how you serve it (git init --shared just affects the Unix permissions). "git daemon" comes with git and can be configured to allow public push by mucking with the configuration or starting it using "git daemon --enable=recieve-pack".
I don't like this because then you have inconsistent behavior between types. It feels like you're saying, "If you can find something useful to do on function call, do that... otherwise just run is." Why wouldn't
There will never be a language where everything can be done in a few lines. There are just some concepts that take more than a few lines to express even in the most concise languages (see APL and descendants).
Also, as I mentioned elsewhere (http://www.arclanguage.org/item?id=4864), a properly-designed type system can do amazing things for increasing the conciseness of a language. For example, take Ruby's Enumerable mixin. This relies on an implicit has-a relationship (that the mixed-in class will define an #each method) to automatically make practically every list operation you could ever want - map, fold, zip - work on any type that it would make sense for.
In short, a well-designed type system means that objects that can act in the same way - like lists and arrays, or strings and input ports - can be manipulated with the same code. This ends up significantly decreasing the code size overall, since each function that operates on multiple types only has to be written once, rather than once for each type it uses.
To be pedantic, it was proven that any program can be expressed in one line of APL (two if you need I/O).
In any case, I agree wholeheartedly: classes, if used properly, are an incredibly good way to streamline code. (Don't use them for everything, though. Then you get Java.) Ruby's mixins are actually very, very convenient, and seem to me to mesh well with Arc's approach: anything that can be cared and cdred can be mapped, too, and Arc doesn't care. But I feel like referring to this style as has-a is slightly weird, and it threw me off for quite a while. An object doesn't have-an Enumerable, it is-an Enumerable. On the other hand, an object does have-an #each method, so it does make some sort of sense.
Another advantage of combining mixins/has-a and Arc is that we get implicit mixins. In Ruby, you need to define #each and you need to include Enumerable to get all the Enumerable methods. But in Arc, since there are only functions, defining each would allow you to pass your object to all Enumerable functions (or their equivalent) without having to (include-mixin 'Enumerable 'MyType).
My main objection is the current state of arc.arc : Every iteration construct works with lists or strings, but it won't work well with something that has 'car and 'cdr (they check by using 'acons and 'alist, which use (is (type foo) 'cons) - meaning I had to hack into 'acons and 'alist. For that matter I had to hack into 'isa too)
Generally is-a means "object is this and only this", meaning single inheritance, which was really my meaning. But a scanner isn't a cons (it's a subset of cons; it will fail on scar and scdr). It does has-a 'car and has-a 'cdr.
I think the reason you keep saying has-a is that you're using conses as an example. A cons does has-a car and has-a cdr, but this is too restrictive. For example, say you wanted to make a type that acts like a list, that is, it supports map, each, reduce, all, rev, some, len, nthcdr, and so on.
arc> (= a (my-listtype 'foo nil t 'bar))
(foo nil t bar)
arc> (car a) ; has-a car
foo
arc> (cdr a) ; has-a cdr
(nil t bar)
arc> (map no a) ; has-a map (?!)
(nil t nil nil)
arc> (rev a) ; has-a rev (?!)
(bar t nil foo)
arc> (some no a) ; has-a some (?!)
t
arc> (all no a) ; has-a all (?!)
nil
See what I mean? (Note: I fully agree that it would be really cool if the above actually worked, I'm just arguing that the name has-a makes no sense here.)
has-a scanner interface just means that: it has-a car and has-a cdr. 'map et al. now require an object which has-a scanner interface, and will simply use basic 'car and 'cdr operations to work. This supports genericity: just write 'map et al once, then any new type you create just needs to give 'car and 'cdr, and say it has-a scanner interface, and the existing map will work.
Now suppose we have another type, which has-a 'collide function, which handles the events where it is collided with in the game space. A ship has-a collide function, and the basic collission detection code is something like this:
(thread
(while t
((afn (game-elements)
(iflet (first . rest) game-elements
(each e rest
(when (overlapping first e)
(collide first) (collide e))))
game-elements)))
The above now works on ships. Now suppose we add a new type of game element: a missile. We simply define its 'collide function, and declare it as having that function; now it magically works without changing the collision-detecting code.
I don't like this. I'd prefer to allow the question mark to be at the end of any predicate. It's pretty simple to define your own type predicates if you need them, but it's not possible to define other question-marked predicates if the syntax is already taken up.
Oh please no! Static typing and Lisp - especially a Lisp like Arc that puts even more emphasis on being as dynamic as possible - don't mix. If we want performance improvements like this, that's what type annotations are for. Those work fine in CL for gaining performance, and integrate well into dynamic languages.
If we add Haskell's type system, we'll just end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell. That's not what anyone wants.
Err. The idea is that these are the "type annotations" you are looking for. I never said anything about making this mandatory; it's merely the implementation layer for type annotations.
