I like paragraphs[-3:-1] in particular; I've had a vague sense of that idea for awhile.
In choosing how to write an app for someone else's machine, you're right, I do start with a list of what's already available to work with. Can I tweak the environment? Use shell scripts? Rely on an interpreter? Use long processes? Windows is particularly limiting, since it's hard (for me) to track down how to talk to the system outside of the standard Visual Studio portal. Everything else (e.g. py2exe) feels a bit hackish or uncertain.
However, for web and Unix applications, you don't use just one language -- your program is the whole system. An FFI is nice, but I'm happy enough to run a few background processes, call a few scripts as needed, in order to do platform-specific tasks, crunch some text, and generally solve the problems that have already been solved. (Maybe this says more about the projects I work on than programming in general.)
For the libraries that we do need -- looking at how I use Python, for instance, I see a core set of libraries that should be in the standard library for any exploratory programming -- everything in C (all operating system features), some way to get at the runtime's internals, string processing, low-level talking to databases, some concurrency support, development tools like profiling and debugging, parsers & serializers for common file formats (XML, JSON, etc.) ... and finally, a way to talk to code in other languages. Re-implement the complete Java or .NET (Mono?) libraries sounds like quite a rabbit-hole, and quite a high barrier to entry for new languages, when the core system libs and an FFI can get you most of the way there with a lot less effort.
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.
Sounds good to me. But we'd have to keep a complete list of which characters can be used that way, or else the parser wouldn't know where to slice the tokens, right? Or can you think of a general way to do it?
This topic really makes me wish I knew a function-level programming language like K. It's all about composing a certain set of basic functions, and it's amazingly concise, so I feel like someone with that background would be able to suggest a Right Way of handling functions at this level.
Exactly. These days Java can be used for high-performance computing, but in the '90s -- coincidentally, the peak of its hype -- it was enough of a CPU and memory hog to make C++ programmers spit. I saw a paper from around 2000 discussing it, and it unfavorably compared the JVM to Python's relatively lightweight runtime. These days Java actually gets pretty close to C++ in speed, but we still think of it as "not terribly slow."
This release has 3450 lines of Arc and 1157 lines of Scheme, so it looks like it's mostly On Arc already. About a C implementation -- looking at benchmarks, I'd be happy if it was just ported to Ikarus Scheme. (Maybe once Ikarus is done...)
Actually, quite a few features Arc uses are taken from the underlying scheme -- like garbage collection, numbers, closures, basic I/O, strings, and so on. In that case, you'll need to count most of PLT Scheme, which dwarfs Arc's 3450 lines. So Arc isn't nearly self hosting yet. But it will be.
I know a couple:
4. That's the "compose" operator. In math notation, the symbol looks like a small mid-line circle.
6. From the intro: "it uses overlays on hash tables instead of conventional objects". Python kind of does the same, where you can get an object's attributes as obj.__dict__.
