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.
Hear hear! Let there be libraries! The school year's almost over, and I'll contribute more then. And I second the idea of a list of necessary libraries that stefano proposed.
Also, has anyone else found themselves accumulating a file of utility functions? I have one with a little fewer than 30 functions which I find generally useful. There's probably some duplication of standard stuff, but there are also things that aren't. If other people have these, we might put the common functions on Anarki.
I mean scanning Arc files or, better, the help* table and gather information in text files formatted in a wiki-friendly format in order to easily put them on the Anarki wiki.
Edit: have a look at the file lib/help-to-wiki in Anarki (just pushed it).
