Arc Forumnew | comments | leaders | submit | etal's commentslogin
1 point by etal 5849 days ago | link | parent | on: Programming in a vacuum

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.


1 point by etal 5849 days ago | link | parent | on: Programming in a vacuum

Looks like this is the official way to put another language on top of Java:

(Note their subtle language that any higher-level language running on the JVM is a "scripting" language.)

I haven't worked with it, but if it handles the mapping of Javascript's type system onto the JVM, then maybe it will do the same for Arc.


1 point by almkglor 5849 days ago | link

Does it allow "script" code to be compiled down to java or jvm bytecode, or is it strictly an interpreter for the scripting language?


1 point by etal 5848 days ago | link

I'm miles out of my league here, but in the interest of science I grabbed the spec, JSR-223. Here's the juice:


  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

  - 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

  - 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.


  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


  - Java Language Bindings – Mechanisms that allow scripts to load Java
    classes, create instances of them and call methods of the resulting

  - 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.


1 point by cpfr 5953 days ago | link

You could just set aside a handful of symbols. Every possible combination of them is a possible infix operator.


4 points by etal 5954 days ago | link | parent | on: a defense of arc

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."


2 points by etal 5956 days ago | link | parent | on: Arc as a better "common" Lisp?

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...)


3 points by cje 5955 days ago | link

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.


1 point by etal 5956 days ago | link | parent | on: Welcome

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__.