I am new to arc (and lisp), I was wondering if any one here is actually using arc for real world applications (other than Hacker News! of course). I mean is there a way to compile into binaries or run the code without using the interactive console? I am reading http://ycombinator.com/arc/tut.txt and it is quite useful but it gives me the impression that arc although fascinating, still has a long way to go, at least it needs good documentation to begin with.
Compile into binaries: what's the end result you care about?
To run code without the interactive console, in pure arc3.1 one way to do it is to add calls to load your own code in libs.arc. Iirc some people have also made extensions that allow you to run Arc code from the command line, I don't have a reference in front of me but you might try searching the forums or looking in Anarki.
I mean 1) if I want to run a web app I don't want my server to depend on an interactive console, I want to run it (them) in the back and stop and start them and ... 2) if I want to run something on a host or a cluster (neither usually have the interactive console, so a binary could help there
In other words, can you give me some use cases that I can understand how you develop and deploy arc apps?
By the way the documentation link in arcfn.com is what I was missing, thanks.
I like using the "screen" program (available on most servers, try typing "man screen"), which lets me pop in and see any error messages.
For an automated startup, you might try something like this shell script (after modifying libs.arc to load your code):
#!/bin/sh
cd /location/of/arc/directory
nohup mzscheme -f as.scm >log 2>&1 &
a caveat here is that "nohup" redirects stdin to /dev/null which in turn will cause Arc to go into an infinite loop if it gets to its REPL, a trick is to have the last thing called in libs.arc be "(serve)" (or "(asv)" etc.), which doesn't return and thus Arc won't get to the REPL prompt.
Thanks, I use screen all the time, still I fill there is a lot fundamental differences between ways of arc and ways of "bulb" (python for me) that I need to learn. By the way the idea behind Anarki is that people come and fork and if they did something worthwhile it could be merged back, right?
Yes, the main purpose of Anarki is as a place for people to share the work they've done on/for arc. Since arc itself is easily modified, a lot of the code on Anarki actually changes the language. There is also a fair amount of library developed there as well, though since most important library functions can be lifted from Racket that's not so much of an issue.
However, beyond simple bug fixes pg hasn't ever discussed much about changing the language itself with the community. As far as I know, none of even the truly good, simplifying and useful features of Anarki are planned to be lifted to arc.
I had a pearson function of my own lying around, which I just pushed. I personally think mine is a little shorter and easier to see the connection between it and the original mathematical function on which it is based. I also have a matrix version and some nearest neighbors functions I wrote a while back.
Thanks a lot, for taking care of the anarchy I caused in the Anarki!
From now on I'll commit to my fork and if there was any thing of general interest you can pull it to master later.
I noticed you mentioned "it would be better if matrix was its own type" I agree with that. Is there any way to communicate this with pg (or anybody else who has a say on such basic matters) and see if matrix could be implemented as its own type?
As you know I am an absolute newbie in arc/lisp but I find it quite refreshing to solve (or re-solve) problems the arc/lisp way.
Actually, do you mind pushing to Anarki instead (unless you have some really risky code that could break a lot of stuff)? Totally up to you, but I'm of the opinion that if we're all hacking in the same repo, our community will be stronger.
A growing set of files in lib/ doesn't really hurt anyone, and if someone really hates your or my code, they're free to rewrite it, or just not load that library.
It's pretty obvious that people like aw, shader, and fallintothis (off the top of my head) are much better scheme hackers than I am, but I don't think I've stepped on their toes too much, and if I think I'm going to, I'll ask the forum about pushing something.
Regarding implementing matrix and vectors as their own types, if you can do it and have the time to do so, you don't need to wait for PG's permission. For my needs at least, Anarki is the more useful tool and PG, while he is the original creator, is just a periodic contributor like the rest of us (although he doesn't push to github - one of us ends up merging his stuff).
Oh, and your variable capitalization style (is duck typing the name? I can't remember) is a little out sync with the community style. Just a heads up :)
Since we're talking about vectors and matrices - one of the things I've been wanting to do is define + as a generic (see iso). There's been some discussion about the pros and cons of overloading + for strings (http://arclanguage.org/item?id=12347) but for mathematical entities it should be fine.
A more intense project is to come up with some nice way to extend coerce without needing to modify ac.scm each time. Was there ever a way to do this in anarki, does anyone know? Maybe in the arc2 branches?
For example, here is an extension to + to combine tables:
(extend + args (isa (car args) 'table)
(listtab (apply + (rev:map tablist args))))
arc> (+ (obj a 1) (obj b 2) (obj a 3 c 4))
#hash((b . 2) (c . 4) (a . 1))
I know you've been working a bit with generics, which I'm not familiar with. I really haven't looked into your code (except to note that you have something in arc.arc which throws me redefinition messages whenever I start up arc), do you have an easy way to create a vector and matrix type? Seems like aw's "extend" and a "vector" method which allowed me to create something that returned type 'vector would be sufficient to get the ball rolling.
rocketnia had a nice comparison of extend with defgeneric in the original thread: http://arclanguage.org/item?id=11779. aw chimed in as well: "If there's a facility that does what you need, use it, but if there isn't, use 'extend ^_^" :)
(Thanks for the pointer to coerce, rocketnia)
My experience since then has been that the efficiency of a hash-table lookup is irrelevant. But I really like the conciseness and readability of being able to say:
(defmethod foo(arg1 arg2) type-of-arg1
...)
---
"you have something in arc.arc which throws me redefinition messages whenever I start up arc"
If you're just concerned about having the type 'vector, you can use Arc's (annotate type representation) function to give a value a wrapper with a custom type, and you can use the (rep wrapper) function to unwrap it.
If you're actually talking about vectors in the Scheme sense (arrays), there'll be a few more hoops to jump through, but that's not really what you mean, right?
Since then, it's been redefined in terms of [coerce _ 'fn] and an extensible implementation of 'coerce. http://arclanguage.org/item?id=9828 (Here you go, akkartik!)
Rainbow also supports 'defcall, but in the more direct way rather than through extensible coercion.
Sorry guys, would somebody summarize this discussion on vectors and matrices? I mean after all is there any merit in defining a generic matrix type for everybody to use or people better define their own for their specific job. I am still trying to read the documentation, this is all new for me.
Looks like garply is putting together a library which deals with matrices and vectors and wants to be able to say (isa x 'vector). The 'annotate and 'rep functions make that happen. Anarki also defines 'defcall so that new types like these can be given special behavior when used as functions.
In one sense, garply's defining a matrix type for every Anarki user to use. In another sense, it's only a matrix type specific to the purposes of that library. But in any case, if this type doesn't look good to someone, they can just follow the same process to define their own type and forget this one exists at all. :-p
Realistically, I think efficiency is one of the things at the top of people's minds when they're trying to do computation with matrices, and with all due respect to garply, I doubt the project is going to get to the cutting edge of matrix efficiency anytime soon. >.> So I actually do expect someone to decide to define another matrix type later on. Nevertheless, garply's contributions could certainly help that person along. ^_^
You're absolutely correct. I would go so far as to say that Arc itself is too slow to do any serious matrix computations (maybe if you made this just an interface to some Racket matrix libs you could work around it). I'm really not going to bother thinking about efficiency much at all. What I have done before in Arc is prototyped some algorithms on very small test sets. Once I got those working and figured out what I actually wanted, I rewrote everything in C++ or C, with a very close eye to efficiency.
I used to use this strategy all the time with an R / C combination, but I greatly prefer writing in Arc. Lush is kind of the best of both worlds, except the last time I pulled the bleeding edge version there appeared to be some crippling, hard-to-find bugs. Plus it's nice to just be able to build quick prototypes when you're already in Arc.
