I've used both mzc (from racket) and raco.exe, same error message. (I've tried to run create-embedding-executable from repl without success because I've not figured out how to call that correctly.)

Racket/Arc think the symbol is not bound - the symbol being the first symbol in arc.arc coming from scheme (xref disp). It's yet-another error due to namespace+eval I think.

As the blog post says, HN still is Arc, but not software used to run YC.

The only problem I've had running on MzScheme 372 is that it can be awkward to track down documentation for that version. Newer versions sometimes have more features available.

https://github.com/arclanguage/anarki/commits/stable

I actually thought there were more crucial bug fixes on this branch, like akkartik said, but it seems that the rest of the commits are various improvements to Arc's usability from editors and from the command line.

Here's a holistic summary of the changes, so you don't have to trudge through the commits one by one:

- Adds a CHANGES/ directory which is supposed to host a summary of changes like this one. Anarki's master branch makes use of this directory, but so far it's been neglected on the stable branch. (I should probably add this list to it!)

- Adds an extras/ directory containing Vim and Emacs extensions.

- Adds arc.sh, a nicer way to run Arc from the command line. (Many of the other changes were made to support this.)

- Doesn't display the REPL when stdin is not interactive. (https://github.com/arclanguage/anarki/commit/eb55979588bb01d...)

- Outputs error messages to stderr rather than stdout. (https://github.com/arclanguage/anarki/commit/e518e3b323a63bc...)

- Makes it possible to execute Arc at the command line from directories other than the Arc directory. (https://github.com/arclanguage/anarki/commit/4df89245bb49ae2...)

- Interprets command line arguments as filenames of Arc scripts to load. (https://github.com/arclanguage/anarki/commit/5ac5d567bce0800...)

>Does Arc 3.1 run properly though on MzScheme 372 or does it need to run on Racket?

The instructions at /install are actually more than six years out of date. As of August 2009 (http://arclanguage.org/item?id=10254), Arc officially stopped depending on MzScheme 372. Shortly after that, the official releases of the language ran dry, and the Arc website (this website) entered a more preservational mode of maintenance. It even preserves those obsolete instructions!

Arc 3.1 actually doesn't require an old version of mzscheme -- you can just use racket, and start it with `racket -f as.scm`. And no, the instructions on this site don't say anything about that.

Nope, that won't help.

> so it's better to have a separate setup of Nginx/Apache (with PHP or whichever) handling file the uploads

That's the easiest approach. Not that you'd need PHP, just pop in a module to handle file uploads for you.

> Or is it more like doing anything with big files in Arc is a no-go

To be able to handle image uploads directly in Arc, you'd want an HTTP server implementation which supported binary buffers.

http://arclanguage.org/item?id=244

http://arclanguage.org/item?id=2887

It's not much, but they have an sexp. based parser, so it should be at least as easy to build a lisp on top of it as vanilla js.

I think so. I'm primarily familiar with Haskell, but I hope those examples at least work in SML too.

A lot of the syntactic similarity starts to break down once the examples include lambdas, pattern matching, and top-level declarations, but I think that's similar to how the similarity between Lisp dialects breaks down when we look closely enough.

---

"It conflates calling a function (by surrounding it in parentheses) with converting an infix function to prefix."

I was making it look similar to Lisp syntax for the sake of argument, but parentheses aren't actually used like Lisp function calls there. In that example, parentheses are just used for two purposes:

- Grouping.

- Referring to infix variables (+) without applying them, which would otherwise be impossible to do.

The syntax for function application is juxtaposition with left associativity, so "gcd a b" is grouped as "(gcd a) b".

Agda[1] and some notes on Epigram 2[2] track "spines" of elimination contexts for the purposes of type inference and implicit argument elaboration. I think Haskell might use spines to resolve type class instances as well. In that case, the meaning of gcd in ((gcd a) b) can depend on the types known for a and b. With this kind of trick, Haskell's instance resolution can supposedly be used to write what are effectively varargs functions[3].

[1] http://www2.tcs.ifi.lmu.de/~abel/talkIHP14.pdf

[2] http://mazzo.li/epilogue/index.html%3Fp=1079.html

> In this example, the + and - look like punctuation separating the phrases "gdc a", "b c", and "(square d)", and it takes me a moment to realize "b c" isn't a meaningful expression.

Agreed. This is possibly my main complaint with mixing infix syntax with prefix syntax.

> gcd (a + b) (c - square d) (* ML ) (gcd ((+) a b) ((-) c (square d))) ( ML again *)

This is the same in Haskell^1. But I really dislike how this is done. It conflates calling a function (by surrounding it in parentheses) with converting an infix function to prefix. And if the function is unfamiliar, you don't know which it is. I assume this is taken care of by the parser, so it's into the arbitrariness of syntax, not the clear standard of function application^2.

[1] I assume Haskell got it from ML.

The big benefit that parentheses have is that they make the correct parsing of the text obvious, especially when combined with decent automatic indentation^1. If I never have to read something like `[x * 2 if x % 2 == 0 else x for x in a_list]` or `[x * (2 - x % 2) for x in a_list]` again^2, I'll be thrilled.

So my question is: unless you can make the correct parsing obvious, why skip the parens?

[1] Hello, Emacs!

  //StackArray.h

  #ifndef STACKARRAY_H
  #define STACKARRAY_H

  #define MAX 10

  typedef struct _stackarray{
	int array[MAX];
	int size;
  } StackArray;

  StackArray * newStackArray();
  int pushStackArray(StackArray *, int );
  int popStackArray(StackArray *);
  int fullStackArray(StackArray *);
  int emptyStackArray(StackArray *);
  void displayStackArray(StackArray *);
  void delete(StackArray *);
 
 #endif

  //StackArray.c

  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include "StackArray.h"

  StackArray * newStackArray(){
	StackArray * stack = malloc(sizeof(StackArray));
	int i;
	for(i = 0; i < MAX; i++){
		stack->array[i] = 0;
	}
	stack->size = 0;
	return stack;
  }

  int pushStackArray(StackArray * stack, int item){
	if(stack->size < MAX){
		stack->array[stack->size] =  item;
		stack->size++;
		return item;
	} else {
		printf("The stack is full\n");
		return 0;
	}
  }

  int popStackArray(StackArray * stack){
	if(stack->size > 0){
		int top = stack->array[stack->size-1];
		stack->size--;
		return top;
	} else {
		return 0;
	}
  }

  int fullStackArray(StackArray * stack){
	return stack->size == MAX ? 1 : 0;
 }
  int emptyStackArray(StackArray * stack){
	return stack->size == 0 ? 1 : 0;
  }

  void displayStackArray(StackArray * stack){
	if(stack->size > 0){
		int i;
		for(i = 0; i < stack->size; i++){
			printf("%d ", stack->array[i]);
		}
		printf("\n");
	} else if (stack->size == 0) {
		printf("The stack is empty\n");
	}
  }

  void delete(StackArray * stack){
	free(stack);
  }

  Compile and create the Shared Library (Linux):
  gcc -c -fPIC StackArray.c
  gcc -g -Wall -shared -o libStackArray.so StackArray.o

  In Anarki type in:
  
  ($:require ffi/unsafe
    ffi/unsafe/define
    ffi/unsafe/alloc)

  ;Define the library
  ($:define-ffi-definer define-StackArray (ffi-lib "/home/conan/Documents/Arcprojects/ffi/stack/libStackArray"))

  ;Define the functions input and ouput

  ($:define-StackArray newStackArray (_fun -> _pointer ))
  ($:define-StackArray delete (_fun _pointer -> _void ))
  ($:define-StackArray pushStackArray (_fun _pointer _int -> _void))
  ($:define-StackArray popStackArray  (_fun _pointer  -> _int))
  ($:define-StackArray fullStackArray  (_fun _pointer -> _int))
  ($:define-StackArray emptyStackArray  (_fun _pointer  -> _int))
  ($:define-StackArray displayStackArray  (_fun _pointer -> _void))

  ;assign the functions a symbol to use in Anarki
  (= newSA $.newStackArray)
  (= deleteSA $.delete)
  (= pushSA $.pushStackArray)
  (= popSA $.popStackArray)
  (= fullSA? $.fullStackArray)
  (= emptySA? $.emptyStackArray)
  (= displaySA $.displayStackArray)
  
  ;To use the functions
  (= stack (newSA))
  (emptySA? stack) 
  (pushSA stack 1)
  (displaySA stack)
  (fullSA? stack)
  (emptySA? stack)
  (popSA stack)
  (deleteSA stack)

 ;A lispy solution using closures with very little effort... a macro can be used to clean up the middle.
  (def Stack ()
    (with (items nil acc 0)
      (fn msg
        (let it (car (cdr msg))	
          (case (car msg)
             set
              (=  acc (len it) items it )
            empty?
              (is items nil)
            push 
              (do (= acc (inc acc)) (= items (join items (list it))) )
            pop 
              (if (> acc 0) (do (= acc (inc acc -1)) (= items (butlast items))))
            peek
              items
            size	
               acc)))))
 
  (= stack (Stack))
  (stack 'empty?)
  (stack 'push 1)
  (stack 'peek)
  (stack 'pop)
  (stack 'set '(1 2 3 4 5 6 7 8 9 10))