Porting Arc to mzscheme 4.0 may be tricky. One big change is cons pairs are immutable, which will break lots of things in Arc. You can create mutable cons pairs with "mcons", so ac.scm will need to use that all over.
Also, "interaction-environment" needs to be replaced with "current-namespace", I think.
I haven't figured out how ac.scm will need to change to use the new module system. The mzscheme command line options also change in various ways.
Simple DirectMedia Layer. Cross-platform multimedia library that has audio, input and 2D graphics. SDL_ttf is a standard extension to it that provides TrueType font support. If Arc can load C libraries, it can should be able to load SDL.
What support do you need for image processing beyond (system "ImageMagick ...")?
But seriously, if you're planning to implement an image processing library, take a look at the Common Lisp bindings to ImageMagick: http://common-lisp.net/project/cl-magick/
Writing libraries is a Good Thing, but trying to create a large collection of libraries for Arc strikes me as a bit of a hopeless cause. After all, Lisp hasn't been able to reach a "critical mass" of libraries and it has many, many more people involved.
I think Arc would be much better off with a way to leverage existing libraries. Easiest would be to use MzScheme's libraries, but that set of libraries is somewhat limited. (I'm currently experimenting with using MzScheme's OpenGL library from Arc; the object-oriented stuff is a big pain since it doesn't play well with Arc.)
Alternatively, if Arc had a way to access the libraries from, say, Python, .Net, or Java, it would gain access to a huge library base. A couple big problems are how to map the language datatypes between the languages, and how to get the runtimes working together.
Maybe make an arc2jvm? Perhaps even arc2java, I'm sure a subset of Java can be made sufficiently C-like to compile down to (and we even get GC for free).
> A couple big problems are how to map the language datatypes between the languages
I'm miles out of my league here, but in the interest of science I grabbed the spec, JSR-223. Here's the juice:
Introduction:
The original goal of JSR-223 was to define a standard, portable way to
allow programs written in scripting languages to generate web content. In
order to do this, it is necessary to have a common set of programming
interfaces that can be used to execute scripts in scripting engines and
bind application objects into the namespaces of the scripts. Therefore, in
addition to a framework for web scripting, the specification includes a
standardized Scripting API similar to the Bean Scripting Framework. It uses
the Scripting API to define the elements of the Web Scripting Framework.
[...]
There are several areas which are intentionally omitted from the
specification:
- The specification does not define how scripting languages should enable
the use of Java objects in scripts, although it is assumed that the
scripting languages implementing the specification have this
functionality.
- The specification does not distinguish between scripting implementations
that compile script sources to Java bytecode and those that do not.
Script engines that do can be used to implement the specification, but it
is not required.
- The specification makes no requirements of scripting languages or the
syntax uses to invoke the methods of Java objects in the languages.
Overview:
In this specification, a scripting engine is a software component that
executes programs written in some scripting language. The execution is
generally performed by an interpreter. Conceptually an interpreter consists
of two parts: a front-end which parses the source code and produces an
internal representation of the program known as intermediate code, and a
back-end which uses the intermediate code to execute the program.
The back-end of the interpreter, also known as the executor, uses symbol
tables to store the values of variables in the scripts.
[...]
Scripting engines which implement the fundamental scripting interface
defined in this specification are known as Java Script l20 Engines.
Conceptually, a Java Script Engine can be thought of as an interpreter, but
this may not actually be the case. For instance scripts executed by a
single Java Script Engine may be executed internally by different
interpreters.
Technologies:
- Java Language Bindings – Mechanisms that allow scripts to load Java
classes, create instances of them and call methods of the resulting
objects.
- General Scripting API – Interfaces and classes that allow script engines
to be used as components in Java applications.
The specification does not deal with issues of scripting language design or
interpreter implementation.
So, it looks like the way you interpret, compile and execute the code is your own business, but if your own ScriptEngine implementation matches the specified API, it will work with existing Java tools and frameworks, particularly for the web. It's modeled after Rhino, so some parts of the Rhino back-end might be directly reusable.
Making this part of "load" seems a bit special-case. I think it would be more general to make "infile" support this, and then you get "load" for free.
Obviously there are plenty of security issues. "load" from the file system has security issues to start with, but when you're loading over the network, you have little guarantee that what you're loading is what you think you're loading. (DNS poisoning, packet insertion, etc.) Using https instead of http would help.
If you go down the distributed computing path, just make sure you don't reinvent Jini :-)
"(/ 0 0.0) = 0" is a feature. "0" is exact 0, and "0." is "inexact 0". And something that's exactly zero divided by something that's not exactly zero is 0. There's also "-0." which is inexact negative 0. You've also got inexact infinities and inexact NaN's. If you divide a positive number by inexact negative 0, you get inexact negative infinity, and the other sign combinations work as you'd expect.
wow- I never would have expected that... It seems that anyone who has a computer program dividing by zero would want an exception raised or at least have an NaN generated. Generating "0" makes no sense- In my scenario, for instance, the function limit was towards 1, so generating a zero is mathematically seemingly completely nonsensical.... Thanks for straightening me out, kens :-)
In floating point arithmetic 0.0 isn't zero: it represent a range of numbers around zero, so it makes a little sense for 0/0.0 to return 0.0. I still think that raising an exception would be preferable.
I think it would be hilariously ironic to make non-ASCII Unicode characters part of Arc's syntax and functions.
A few proposals for giving functions new names: ☢ for atomic, ✄ for cut, ✔ for check, ⌚ for time, ⌛ for sleep, ☠ for kill-thread, ☇ for zap, ♭for flat.
As far as I can tell, there's no way to scrape a web page from Arc, as it doesn't let you open outgoing sockets. This is "almost perversely inconvenient" (http://www.paulgraham.com/arcll1.html).
Thanks for the encouragement. Sometimes I feel that I'm writing for the four or five remaining Arc users. It seems a bit quiet in this forum lately and the regulars seem to be disappearing, e.g. kennytilton hasn't been commenting for 40 days, pg for 22 days, byronsalty for 24 days, CatDancer for 50 days, nostrademons for 65 days. Are people losing interest, just lurking, or has the party moved somewhere else?
I see two main reasons for this. The first is obviously pg apparent disinterest in his own creature (in the sense that he seems to don't follow the forum anymore), because this makes people think "If its creator doesn't care about it, why should I?". Maybe pg is a bit too busy in this days, but I think Arc is still too young to survive if he doesn't come back soon, beacuse there are a lot of other interesting lisp projects out there that don't give the same sense of 'pause' that Arc gives (clojure is one of them). The second reason is the immature implementation that makes it difficult to write projects of moderate size in Arc, as an example think about Arc's error messages: they usually say something like 'You've got an error' and you simply don't get any hint about where it is. This is especially true about reader errors: I've read messages saying 'error at line 5234' in a file with just a few hundreds lines!
The good news is that these problems are, IMHO, fixable. Think about arc2c and how it is trying to fix the second problem to see the direction where the Arc community should go, but these solutions require time, and new users usually don't want to wait when there are other solutions already usable out there.
"The first is obviously pg apparent disinterest in his own creature..."
I think you hit the nail on the head there. I know pg has said that he does read the posts even when he doesn't reply, but let's face it, it doesn't take too long to post a comment occasionally. If he even took the time to communicate a vision to the "community", that would be helpful. I think people would be more patient if they had a clue about where this was heading.
Although it's certainly fun to pick up a new language, it also takes time and effort, and I'd like to see more evidence that Arc will continue to progress before I invest much time into it (especially since it lacks a couple "must haves" for me currently).
So, regarding the other comment about needing more publicity in terms of someone's pet project - I think there's a catch-22 there - who's going to put together a substantial application if they're unsure if the language will survive?
"who's going to put together a substantial application if they're unsure if the language will survive?"
This is true if you're writing your application for commercial use, but if you're doing it just for fun you can even use a language written by yourself that no one else know. The biggest problem is the lack of development and debugging tools. I few weeks ago I started a project to learn a bit more about compilers, and I ended up using Common Lisp because the task was very difficult by itself and I needed a good way to debug the program. Using Arc would have meant to make a difficult project even more difficult.
I think you just proved my point. I presume your project to "learn a bit more about compilers" was not commercial in nature, and yet you chose Common Lisp. Whether a project is for fun or for profit, I'd prefer to not waste my time, and it appears you feel the same.
I think the survivability (not popularity) of a programming language is closely correlated with its usefulness to programmers.
Of course, the best way to rebut my implicit assertion is to actually "put together a substantial application" with Arc instead of talking about it, right?
However, seriously, clojure looks really interesting, being a cool language on the JVM and being purely functional. But does anybody know if it is possible in this language to make (easily) funny structures like circular lists, graphs, etc. ? AFAIK, that's the problem when you don't want to use set-car & set-cdr in Scheme (that's a problem in NewLisp too, for example) : you loose them. Did clojure manage to overcome this problem ?
i'd say just take it easy. no need to hurry or anything
here's something from my experiences: a few times i have released things, and not responded to questions/comments about them for some time. not because i didn't care, but actually because i cared too much. to the people, those things were interesting curiousities, but to me they were things that my reputation was attached to. and so i felt that my statements, responses, and actions had to be well-calculated. and i had to consider the things themselves, which even by their lonesome were no walks in the park. it was somewhat daunting, which led to procrastination
I wouldn't be so discouraged. For my part, I'm simply in a mode where I'm working on stuff, and maybe (hopefully?) this is the case for other people as well.
FWIW, I'm trying to get a more robust version of the IntelliJ Arc plugin out the door, and I'm also working a very primitive project management tool in Arc.
Kenny has definitely left the building :) I think he just wanted to put in his due diligence in checking out the language, but I don't think he ever bought in to Lisp-1 and is sticking with CL.
He hasn't posted on his own blog, either, so he may be doing something entirely different, like travelling: he gave a talk recently at the European Common Lisp Meeting (ECLM) in Amsterdam.
I'm just messin' with ya. It's definitely better to not use multiple user names IMO. And as far as the tie - that 40+ point jump looks awfully fishy to me. Two can play that game though, so knock it off :)
Yeah, it's definitely been getting a bit quiet in the arc world... I'm planning on using arc long term, so I hope the community survives...
And I second the motion that your docs are extremely useful, kens. I have a bookmark link for them on my main toolbar, along with only a handful of other essential tools on the web. No question though, your audience is unfortunately is pretty small these days...
Still here, but dividing my time in finishing my phd, learning to use arc to code for a pet project of mine.
Can't imagine pg just abandoning arc, but a bit more excitement from the regulars would be a good thing. Perhaps we can do something like start writing the great computer language shootout progs in arc (although not for speed, we'd be able to go for brevity and clarity)?
As for shootout , that would be a good idea, but the current implementations (arc2, arc2c or even others) aren't mature enough to compete.
I mean, arc2 takes 3 sec. to startup (and it cannot even take command line arguments) and arc2c is not meta-circular yet (and lacks a lot of things, including command-line args, but that is easy to add), so a real benchmarks would need both arcs (one to compile, the other to run the compiler). I don't know the precise status of other implementations, but I guess they aren't mature enough either.
And, that's a chicken-and-egg problem, but I don't think the shootout admins would accept to add an Arc implementation until the language is a little more popular (or there would have thousands of languages referenced).
