I've been looking at PicoLisp's documentation for some time now, and I think there are a lot of things that could be borrowed from it, starting from the interpreter to the html functions it has which I've found to be way more intuitive than Arc's for a lot of things.
Micro benchmarks can be misleading sometimes. Most of the time I get different timings for the same microbenchmark when I eval it a few times so it's really difficult to see if they really do their job when the timings are too close unless some full blown benchmark is performed on some real data.
I'm also interested in doing graphics with Arc, but since using ffi seemed to be an overkill when it comes to opengl, I'm doing some IPC stuff in plain X (not the fastest but the easiest and most flexible to get going).
I've thought of modding picolisp to work with arc natively, but I think it's not worth the effort right now, since any design decisions regarding unix integration and stuff are most likely to be trampled and disregarded silently by the vanilla branch (I already see many GOOD improvements in Anarki suffering this).
I think I'd wait for arc to be more mature before attempting to write a compiler or interpreter from scratch.
X you mean X.org?! I don't understand here, but it's because I'm not a graphic guy and I've never understand X.org (if you are effectively speaking about it).
Can you provide more explanations and/or some example code please? I'd be really glad to understand.
> I think it's not worth the effort right now, [...] most likely to be trampled and disregarded silently by the vanilla branch
+1, for the silently mainly. But don't get too frustrated, it will make you have heartburns and this is not good :-D, or yes get frustrated, but at least know you're not alone thinking this kind of thing
All the drawing is handled externally by... a drawing server which processes drawing requests from Arc. But it's not even in alpha state so I'm not releasing it yet. Also because I'm thinking in trashing it and start from scratch using opengl instead of xdraw and change the way it communicates with Arc.
But I'm too busy at the moment, it will have to be in my next holidays (roughly 4 or 5 months).
This is a major problem. I agree with you, and I don't see myself writing a lot of Arc scripts in the current situation.
Maybe a client/server would be a way to solve the problem. I may try something like that one of these days. I mean, launch Arc once as a daemon, then talk to it with a lightweight client, via FIFOs (named pipes) or something.
For the moment, you may want to comment the imported arc libraries you don't use (in libs.arc or as.scm), for instance all the HTTP/HTML stuff. Loading only arc.arc, my load time is reduced by 50%.
Yeah, maybe they are just an optimization but they are definitely going to be present in production implementations and I think they should be standarized beforehand, and since they are already available in the underlying mzscheme, I think it shouldn't be too problematic to get vectors in Arc.
Again, I suggest {...} for vectors, since they stand out (so to avoid confusing them with lists) and because they remind of array oriented languages.
I'm sure there will be heated debates about the trade-offs between the "hundred-year" aspect of arc and the need to deploy reasonably fast applications. Here are some quotes from http://www.paulgraham.com/hundred.html
"Having strings in a language seems to be a case of premature optimization."
"Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient."
So arc already deviates from the ideal minimal language; it might well deviate some more, I don't know. In a perfect world, the underlying VM should be able to figure out the most efficient implementation for each particular list you want to represent, and we would never need to bother ourselves with such details.
For comparison, "primitive types" in java are a performance compromise that (a) seriously mess up the language, and (b) are less and less relevant with each iteration of Moore's law.
Notwithstanding any of the above, I have shamelessly used
(mac fpush (thing place) ; a very primitive, naive, fast 'push
`(assign ,place (cons ,thing ,place)))
because the standard 'push uses 'atomic-invoke internally which slows some things down intolerably. Hence ... heated debates.
The only problem with using standard array notation for arc is that [] are already tied up for anonymous functions.
However, I think that too much syntactic sugar like this will end up damaging arc. Partly due to aesthetic reasons, but mostly due to the fact that each user has a different view on aesthetics, and adding too much will just exacerbate the "everyone has their own version" problem.
hmm, come to think of it, I've never used my table literal syntax {...} myself in a program. I wrote it so that I could write out and read back tables, which I use all the time, but that would work just as well with some long syntax like (literal-table k1 v1 k2 v2 ...) which doesn't use up precious syntax characters like { or #{.
Looking at the link, and your username, I can tell this is spam. Also the title is not very informative and I don't see how the site you linked relates to Arc in any way.
Just for your information, there is a "flag" button on the "X points by Y" line, which can be used to mark spam messages. (Or at least there is if you have over some amount of karma.)
That's way too funny. I saw this a while back and thought 'flag' was to bookmark the post as 'important'.... so naturally was 'flagging' some of pgs' posts. I'm glad it didn't end up marking his posts as spam!
I've been willing to give rainbow a try for a couple of days now, but I keep getting the same build error no matter what I tried.
└──> ant -lib "lib" jar
Buildfile: build.xml
compile-parser:
BUILD FAILED
/home/tc-rucho/Sources/Extern/Java/rainbow/build.xml:23: Problem: failed to create task or type javacc
Cause: the class org.apache.tools.ant.taskdefs.optional.javacc.JavaCC was not found.
This looks like one of Ant's optional components.
Action: Check that the appropriate optional JAR exists in
-/usr/share/ant-core/lib
-/home/tc-rucho/.ant/lib
-a directory added on the command line with the -lib argument
Do not panic, this is a common problem.
The commonest cause is a missing JAR.
This is not a bug; it is a configuration problem
Total time: 0 seconds
should fix the ant config issue. On a mac, I think ant-optional comes with the Developer Tools. I should add this to the readme, thanks for pointing it out.
what color theme are you using?
On the spiral app? "theme" is too dignified a term for my crude CSS :) ... I found white dots on a dark background were easier to look at, so I set up the rest of the page in a similar way - dark bg, bright text. Did I understand your question correctly?
Yay, I've solved the ant problem emerging some stuff related to the ant package, thanks for pointing that out :D
I'm excited about having java libs available in arc, although it would be nice to have an obvious way to disable tests on startup (now that I know it's fully functional I would like to speed the initialization up).
About the color theme: I meant the color theme used in the arc code. I bet you took those colors from an editor. Anyway, it doesn't matter at all..
Oh, the syntax highlighting, yes, welder (arc editor that comes with rainbow) can htmlify arc code so that it's easy to paste into a blog or other web page; then it's just a matter of a little CSS to decide what colour you want for different kinds of tokens.
You can just comment out the (run-all-tests) line in rainbow-libs.arc, but you're right, it should be optional somehow.
Let me know how you get on with accessing java libs, I've tried to make it as simple and concise as possible, so that your code still looks like arc code and not some outrageous contaminated half-blood hybrid monstrosity ...
