You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
The main thing I wish someone would write is a profiler that (a) had sufficiently low overhead that it could run in production code and (b) could be installed without huge changes to ac.scm and/or the underlying MzScheme.
Oof. Tough. I and raymyers did some work back on a profiler when we were optimizing treeparse, but it didn't quite work well in my use-case.
Certainly it seems to involve deeper hackery skills than I seem to have right now ^^.
As an aside, it might be slightly easier to actually insert profiling code in arc2c. Each function has its own ID number in arc2c and all we need is some sort of index from ID number to original function name (given that a function in arc2c may be split by CPS conversion, so a function with a name may end up being split into several functions),
> You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
Please, lets not get into a "yes it is"/"no it isn't" argument here!
I am aware of some rather horrid languages that forced the use of meaningful indentation, but that doesn't make indentation evil in and of itself.
As for in Lisp, a number of people have tried to add it to Arc (including pg) without too much success. It seems that meaningful indentation lends itself much better to statement based languages than expression based ones.
classes/types? I thought arc is a language where every thing can be done in a few lines ... i cant see extra typing systems save all that much lines but just increase the complexity of the language.
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.
It also looks like its OO using Clos and it looks very un-arcish presenting the very hard problem with in CS - naming things - or in this case renaming things shorter.
i am learning how to write scheme compilers now it it looks like you just jump around your CCC's like GOTO labels - very fascinating and lower over head then functions calls (if you compile to machine level)
There is plenty of scheme to c compilers. I would think that one could compile arc to c and have option to go lower level and code c like constructs in arc.
I much prefer pypy rpython approach though it uses rtype (like ctype) to ffi to c most of the time but during complication of rpython to c the rtypes get replace completely. I think pyrex is a bit of a dead end.
