Using mzscheme as some sort of high-level virtual machine isn't a bad idea as it may seem. In fact, I think that it could be quite practical even in the lon period. Speed is not blazingly fast, but it is quite good, and you get stability and a good portability without effort.
> Do you really think you're going to be calling a C++ function through an FFI in 100 years?
I think I will be dead in 100 years.
> I'm not sure if there is any good way to solve this dilemma
The only solution is to write libraries. Take some problem you think is generic enough for a library and write code to solve it. I've already written in Arc a library to download files through HTTP and a simple XML parser. They're not complete, but they're something. Talking about libraries' shortage won't solve the problem. We have to write code.
I agree. Of course, there are still some ASCII-based little helper functions, but I recall seeing PG post something in Icelandic characters in this forum after the UTF-8 thing was addressed.
Actually, especially since Arc lacks a debugger, I find it very convenient to be able to just place a pr: or pr. in front of some symbol to get an expression printed out without the behavior changing.
It could return the list (1 2), but this would mean to cons up a new list every time we use 'pr just to throw it away. Multiple return values would solve the problem. Why not add them to the language?
> How much more expensive is cons compared to multiple return values?
It depends on the GC used and on the implementation. mrvs are usually pushed on the stack, so there is no GC overhead. When I develop applications with Lisp, I notice that most of the time reducing the amount of garbage speeds up the program noticeably. It's not only a problem of consing, it's also a problem of collecting the garbage. More garabage, more collection cycles.
I keep saying in this forum that we need to concentrate on language design and on writing libraries. I keep saying to myself that I should work on applications or at least on some useful library. I keep writing half-working implementations. Here's my second attempt. Arc on parrot.
What do you think would be helpful for taking Arc away from a culture of reimplementation, and closer to a culture that supports writing libraries?
I'm thinking a clean (to the point of using syntaxy bits that are currently in use for other things) and simple-as-possible namespacing and packaging system would help a little. But maybe I'm wrong.
Namspaces are essential. I think that a real, actively developed implementation, not just a prototype as Arc2.tar, would stop the reimplementation culture. That culture is quite spread in the lisp world in general, and it's not totally bad because it let you compare and try different approches. We shouldn't stop doing something just because it has already been done, because sometimes innovation comes from re-inveting the wheel in a different manner. That said, a standard implementations where the majority of the efforts goes is essential. Summing up, I think we need:
1) Module system.
2) Real (not a prototype), actively developed implementation.
3) Work hard.
4) Have the time to work hard. This is what open source projects usually miss, for obvious reasons.
Since we miss the time to work on an implementation from scratch, we should leverage existing platforms, like clojure did with the java platform. rainbow already does this using java, and I'm trying to do it for the Parrot platform.
After I posted the question above a little voice in the back of my head started saying "wait... aren't we in the language design phase? Doesn't Arc ultimately just have a messaging problem, in that I am still thinking more in Being Popular terms than Hundred Year Language terms, despite knowing that it isn't really appropriate?"
So I guess what I'm saying is I agree with you? ... Yeah! (I especially think the focus on building on VMs is a great one right now. One language that could sit on the JVM, Parrot, and/or the CLR or DLR would be a pretty strong win (see also fandev.org).)
I can imagine as a language founder you'd hate remarks like the one above, where other people tell you that in order for your language to remain popular, you have to address these and these and these points.
What would excite me most (but I'm somewhere at the bottom of the food chain when it comes to language design) is that different new and old ideas for implementation of certain language features can be tried in arc.. so.. if we want to be able to load modules, what kind of options do we have to design a loading system.. and what about arc gives us new / better options to design a module system that other languages did not have, and thus could not consider as an option.
These would require a standard FFI system. Or else we would end up writing Anarki specific code. Such a fork would be a real Arc killer (in the bad sense of the term).
sacado built an FFI on Anarki.... well forks are generally bad but with PG asleep until october or so .... (maybe he's getting ready for oktoberfest or something ^^)
Another point to consider is that if your a-list is very small (<= 5 elements) it could be faster than hash tables. The sharing behavior could be achieved with some sort of concatenated hash-tables, a list of tables to consider in turn to find the desired element. This seems very slow though. BTW, removing a-lists would be useless: they're so simple to implement that a lot of developers (me included) would re-invent them to use in their applications.
That's true. Programming languages take years to evolve, not months. Moreover, Arc is in the language design phase. As of today, the syntax and the semantics of the language are more important than libraries. For example, I'd like to see something like Kenny Tilton's cells (http://github.com/stefano/cells-doc/) nicely integrated within the core language.
Is it in the language design phase? Does anyone know if this is in fact true, and if so, what is currently being designed? The impression I have is that it just sort of stopped.
I would suppose that since a) this language is not used in anything "important" yet, and b) it's open source; yes, it can be in the design phase. I should think that the design phase persists until, for some reason, the language becomes "formalized", or until it is impossible to change anything major without ruining things for a lot of people. At that point you can still "design" the language, but since it has a generally understood "style" and so forth, it won't be able to change too much unless you make a whole new language.
What do you want to be designed? One of the major problems about "designing" a new lisp is that, since anyone can "do it" in their spare time, they don't see the point. Maybe they're right. ^^
Sorry for all of the quotes; it looks kind of funny, I'm sure.
