Hmm. Seen flat and tried it. in Arc2 flat works recursively, turning (list (list 1 2) (list (1 2)) into (1 2 1 2), which doesn't produce the desired (2 4) when combined with map +
The apply function takes a function, any number of arguments, and a list, to wit (apply f x0 x1 x2 ... xN args). This is the same as (f x0 x1 x2 ... xN args.0 args.1 args.2 ... args.M). This allows you to construct argument lists at runtime, which can come in very handy.
I agree whole heartedly with this. I have begun abbreviating too.
I think arc like macros should go in Anarki. What does everyone else think? I like seeing everything arc in one place - even if it is CL or Scheme macros.
That being said it sucks that the arc community uses Anarki while pg doesn't. Or at least he doesn't contribute regularly. I think there is plenty of room for a more cohesive community.
> That being said it sucks that the arc community uses Anarki while pg doesn't. Or at least he doesn't contribute regularly. I think there is plenty of room for a more cohesive community.
Cohesion is the real big problem of the Lisp community in general, and it should be addressed by Arc. In this respect I think that Anarki is what the official version of Arc should look like: one place were everyone can contribute.
If arc could seamlessly access PLT scheme's libraries that would be a good start. I know from first hand experience that there are a number of ways to access PLT scheme from arkani and arc. But, there are two big issues. First there are type differences between fundamental types (lists gah). This means there can be a lot of work to convert between PLT scheme and arc, not impossible but time consuming. Secondly, there is no nice way to pull in a PLT library and just use it in arc. Of course this could be implemented - it's just not there yet.
There are two choices I see going forward immediately. Arc and the arc community starts implementing their own libraries or we find a way to use PLT scheme's libraries (ok maybe sbcl if you are using arkani).
I know there is additional information somewhere in the forum on type differences when coercing data between scheme and arc - specifically '() nil (list) aren't equivalent. Worse come to worse - see the source.
I think macros in smalltalk are plausible. I have nothing to back that up. I am definitely not a smalltalk hacker. I think that smalltalk can solve the same problems that macros solve just through a different approach.
Considering that arc doesn't even have slime support - it's accurate. Now when using slime supported lisps, the environments are at least comparable. Debugging in Smalltalk is awesome and straightforward after you are up to speed. It still takes more dedication to learn slime well enough to debug a gnarly bug.
Both smalltalk and lisp will allow you to create DSLs (domain specific languages) easily for your application. Both see code as data and allow customization of internals. They do this through different approaches. Each approach has different strengths and weaknesses. Also some people are just more comfortable with one approach over another.
I think it speaks volumes about Smalltalk that Avi Bryant could just add continuations (saved closures) to the language for seaside. This sort of ability to add powerful new forms to a language is key and helps set it apart from other languages and put it in the same category as Lisp.
If you are interested there are interesting "History of" papers on Smalltalk and Lisp from the HOPL ACM conferences. They help explain the different philosophies in detail and do a great job of explaining why each language is the way that it is.
I was talking to a fellow lisper recently and he said "If I weren't writing lisp or scheme, I'd be writing smalltalk". I entirely agree with that. In fact I may still end up writing some projects in smalltalk.
Unfortunately I don't have any huge insights. I've been using it on and off since 2005. It was recommended by a friend who lives in emacs. It makes lisp approachable and it makes me way way more efficient when writing and debugging lisp. No swank backend (and thus no slime) makes arc a hard sell. For those wondering what's so great about it - slime supports every major debugging feature I've seen in Eclipse or Visual Studio.
This is what I would recommend for someone learning slime:
If you are a complete slime n00b watch the screencast over at the slime homepage. I just watched it recently and it is well done.
I think the best way to learn from there is through using it to implement a non-trivial yet small project. Make sure the project isn't too challenging, so you have a chance to learn the new environment. Anytime you think there must be an easier/better way to do this - spend time learning slime. Keep coding and you'll continue to put yourself into situations where you can use slime in new ways.
If you have specific questions or problems it is worth asking the community or searching blogs / mailing lists. The questions are either answered already or someone will give you an answer. This is much like all the lisp and smalltalk communities.
I will see if I can get an expert slime user to post some more specific information. Maybe someone else can chime in. I know I have some useful information on specific parts of slime but it wouldn't help someone that is a new user.
Interesting! I just had this conversation with a fellow lisp hacker yesterday. What are the alternatives to arc? Or more precisely why not choose one of these other continuations based web frameworks over arc's web framework?
On top of this consider that if you use something like sbcl you'll then be able to use slime and all that it adds when debugging. Also you'll get a number of relatively stable libraries without having to port them to arc.
You also get some nice persistence libraries such as elephant in CL. These could make life easier if you had complex objects or structures that needed more than just hashs.
I think the number one thing plaguing SBCL is multiple threads causing problems. A friend mentioned that hashes should be threadsafe now. That is a move in the right direction. I know I've had problems with threading in SBCL in the past, but that was years ago.
I have thought about what my back up is if I run into too many problems in arc or lisp. Especially if I needed to hire people or contract work. I have my own ideas for how to address such problems, but I think it should be kept in mind when making a decision as to what framework and language to use.
There are public lispy web apps out there. I just don't have a list of them right now. Notably reddit was written in common lisp. I believe sbcl was used, but not sure. Later on it was rewritten in python. The reason is undisclosed but if I had to guess I would say issues with threads.
On the Arc level, it works perfectly well for me (no error, no segfault). But, when I try to (manually, with vi) open the db file (the "test" file), it's empty. Existing, but empty. I don't know why yet.
There's one thing that seems strange to me in the above declaration : char errmsg should not be declared as a cstring : it is a pointer to a string. I guess it should be declared as a cptr. I'll investigate more deeply later, when I'll find enough time...
xs will have a type of 'cons in this situation. Which means it sees it as (element . list). So for your example it'll see it as 3 (3 4 5 66 67). It just happens that pr deals with cons types well.
