Hey, I know I haven't been there for a while, and now I'm here to show you some Lua code.
Well, I'm still playing with Arc, and particularly still love its webapp's model, but I'm really fed up with the lack of libraries especially when I want to do real work, so I actually wanted to see if its web server could be easily implemented in another (good) language. Well, it can, even if it's not as elegant as Arc's code.
What I've learnt :
First, macros are really great, I miss them ; Lua has extensions if you want to play with macros, but I didn't use them here
I already wrote about that, now I'm sure : Arc has too many basic datatypes. It has string, symbols and characters, Lua only has strings, and that's clearly enough ; a lot of code in Arc is converting strings, symbols and characters into each other.
Arc has lists and hash tables (and unofficially vectors), Lua only has tables ; again, a lot of code in Arc tries to convert lists as hash tables.
Agreed re: libraries. I expect that libraries might start showing up once/if folks feel that pg hasn't simply left entirely as it appears currently. Typical catch-22 - who wants to write libraries for a language that might stagnate or die?
The boring stuff, like building nice parameterized SQL queries and getting back the data from SQL. Launching a system process in parallel and keeping track of its status (and potentially aborting it if e.g. it takes too long)
If we do all of the boring stuff in a clean, concise way, that makes everything easy, with the option of adding macros on top to boot, the boring stuff might well become fun, or at the very least, painless.
Some times ago I started a GTK+ binding, now "paused". It's more boring than I thought initially. If you wish look at it for a starting point (file gtk.arc in Anarki). I now think a binding towards tcl/tk would look nicer and easier to use, though.
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 ^^)
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.
On the basic datatypes of arc: you cannot remove symbols or lists from arc. Then it would no longer be a lisp. I suppose you could just have strings be symbols or vice-versa, but then you either put overhead on usage of strings for variable lookup or overhead on usage of symbols for string manipulation.
Yes, but, for example, association lists could be implemented as hash tables while beeing seen and manipulated as regular lists. That's tricky, but that should be feasible. And Clojure removed cons cells and thus "traditional" lists, but it's still a Lisp...
As for strings and symbols, I don't really know how they are actually implemented, but as far as I know, the idea is that 'foo and 'foo are the same memory location, while "foo" and "foo" are not necessarily the same object(thus allowing string mutation). Or maybe I'm wrong ?
Lua's strings are implemented the same way : "foo" is always the same location as any other "foo" and string manipulation really doesn't seem to be a problem at all...
I really think "foo" could be just an alternate syntax for 'foo (just as |foo| is) so that we still have a Lisp... Add string manipulation facilities to symbols, and you're done. In any case, characters just seem useless...
Probably means we want to have some sort of "source" slot too, so that we can display shadowed values. Hmm. The association sublists e.g. '(key1 . val1) can probably be directly shared, but lists also imply an ordered set, so we need to store that info too. Hmm.
>As for strings and symbols, I don't really know how they are actually implemented, but as far as I know, the idea is that 'foo and 'foo are the same memory location, while "foo" and "foo" are not necessarily the same object(thus allowing string mutation)
This is correct. And when you really look at it, changing strings as if they were arrays of characters is hardly ever done in Arc; usually what's done is we just read them off as an array of characters and build a new string.
> In any case, characters just seem useless...
Another lisplike, Skill, uses 1-char length symbols for characters (i.e. no separate character type). Also, many of its string manip functions also accept symbols (although they still all return strings).
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.
My two cents on strings/symbols, there are semantic reasons they should always be separate. It's not about string mutation, ignore the implementation, it isn't relevant.
Two symbols 'foo can always be considered to mean the same thing, two strings "foo" can't, they may be only the same by coincidence. This matters if automated refactoring tools become available because you can safely rename all occurrences of a symbol, the same cannot be said of strings.
Mixing strings and symbols is a bad idea, they are different things and should remain that way.
Well, we could at least have a very lightweight bridge between both worlds, by allowing (and automatically converting) symbols into string where strings are needed and vice versa.
Code crashing because, for instance, you tried to concatenate a string and a symbol is rather annoying, but these bugs keep happening and the developer's intention is rather obvious there.
Oh I don't disagree, I'm actually a Smalltalker and I'm accustomed to Symbol being a subclass of String and a String being a list of Characters. I actually have refactoring tools so I just wanted to point out that they are different for more than just implementation reasons and there's a logical reason to have symbols beyond mere optimization.
I just hang out here because I like to see how a new Lisp is born and how you guys think, even though I don't actually use Arc.
