As an example, much of the code assumes that the path separator character is "/", but I gather from mzscheme documentation that Mac OS uses ":". Also, bits and pieces of the Arc system use /dev/urandom.

So mostly I suspect the problems you encounter(ed) are from Arc's assumption of Unix-likeness which might not be available on OS X (not sure however; I don't have access to a real Mac)

niels@suse:~> echo $PATH /home/niels/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:.:/home/niels/myscripts:/myscripts

osx:~ niels$ echo $PATH /Users/niels/Desktop/LearningPython/arc2:/Users/niels/Desktop/LearningPython/MzSchemeV352/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/sw/bin:/sw/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/X11R6/bin

Windows internally implicitly supports / as an alias of \.

               ,(or default-method
                  `(err "no matching method found for multimethod:" ',name)))

Currently the (using ...) scheme in Arc-F assumes a package is a file is a library (and if the library is too large to fit in a single file, to have various "support packages" which are related to the main library package: i.e. lib.arc source contains '(using <lib/part1>v1), and there's a file in lib/part1.arc which contains the parts of the library.). I'm interested in your take on multi-file libraries.

Mmmm... I've been thinking about this. There seems to be some overlapping between your system and mine. I think pack.arc is better suited to extend a pure namespace system with a packaging/dependency system, whereas arc-f namespace system is meant to manage also dependencies.

Hmm. Project management? The Arc-F namespace system doesn't handle thinking in terms of "projects". And how about versioning? The "version" that is used in the Arc-F namespaces is more about the interface version, not necessarily the version of the actual library.

I will probably add it to pack.arc in the future. For the moment it wouldn't be very useful, since there are so few libraries and the ones that do exist are in early development stage. I'll put in pack.arc what I need now to help me develop and distribute libraries. Suggestions are always welcome of course.

The main overlapping between the two system seems to be the fact that 'using tries to load a file before importing its interface. I don't think this will create any conflict with pack.arc. I should also change its name: the term "package" is used both for "collection of files" (pack.arc) and "namespace" (arc-f).

Personally I prefer a variety of smaller libraries whose components would then be composed by other libraries (which would end up being small too, because the functionality exists in other libraries).

My main design goal in Arc-F is to make the use of libraries - and in particular, the use of different libraries from different people with different design philosophies - as smooth as possible. Many of the additions in Arc-F (the ones that aren't packages) are actually subtly biased towards that main goal.

> (2x slower than python is my personal limit).

I don't quite understand that. With pack.arc development is project-based. Maybe we have different opinions of what a "project" is. To me, it is a directory with a file proj.arc describing the structure of the project (a 'defproject declaration).

> write an interpreter from scratch

Really difficult but really needed. The mzscheme dependency is quite big compared to how small as a language Arc is. The main efficency problem, as you said, is function dispatch, because we have to check if it is a function, a list, etc. One thing I don't like very much about SNAP is the dependency on the boost libraries: it is a huge dependency. Is it really needed?

Ah, right. Of course, that's why there's 'defproject, right?

> because we have to check if it is a function, a list, etc

As an idea: generally writes to global variables are much rarer than reads from global variables; in fact, practically speaking nearly every global variable is going to be a constant. We could move the cost of checking if a call is a function, a fake arc-f function, or a data structure to the writing of global variables rather than the read.

Basically calls where the expression in function position is a reference to a global variable are transformed to callsites which monitor that global. The callsite initially determines the type of the value in the global (or creates an error-throwing lambda if the global is still unbound) and determines the proper function to perform for that call (normal function call, or a list lookup, or a table lookup, etc). The callsite also registers its presence to the global.

If the global is written, the global also notifies all living callsites (we thus need weak references for this), which will then update themselves with the new value.

This is actually "for-free" in SNAP, because there's an overhead in reading globals (copying from the global memory-space to the process memory-space), and SNAP thus needs to monitor writes to globals so it can cache reads.

> One thing I don't like very much about SNAP is the dependency on the boost libraries: it is a huge dependency. Is it really needed?

The bits of boost I've used so far are mostly the really, really good smart pointers; while I've built toy smart pointer classes I'm not sure I'd want those toys in a serious project. Also, I intend to use boost for portable mutexes. Now if only boost had decent portable asynchronous I/O...

Alternatively we could wait a bit for C++0x, which will have decent smart pointers which I believe are based on boost.

> Boehm-Weiser GC: it is easy to integrate in any interpreter (I don't know if it works with SNAP's process' model, though)

Well, one advantage of the process-local model is that process-local memory allocations won't get any additional overhead when the interpreter is multithreaded; AFAIK any malloc() drop-in replacement either needs to be protected by locks in a multithreaded environment, or will do some sort of internal synchronization anyway. In effect we have one memory pool per process, allocating large amounts of memory from the system and splitting it up according to then needs of the process.

Since processes aren't supposed to refer to other process's memory, the Boehm-Weiser GC won't have anything to actually trace across allocated memory areas anyway.

And I probably should start using tagged pointers instead of ordinary pointers ^^. They're even implementable as a C++ class wrapping a union.

The most important is that the dispatcher function is a limiting factor. To be specific, the dispatcher function means that extending the function is limited to what the dispatcher expects.

If the dispatcher function expects exactly one argument, you cannot create a method with an optional argument. For instance, consider a shape rectangular-prism

  (= shape
     (obj shape 'rectangular-prism
          height 2
          width 3
          depth 4))

  (method area 'rectangular-prism (p (o face 'front))
    (case face
      front  (* p!width p!height)
      back   (* p!width p!height)
      left   (* p!height p!depth)
      right  (* p!height p!depth)
      top    (* p!width p!depth)
      bottom (* p!width p!depth)))

It's not just the number of arguments. One advantage of CLOS-style multimethods is this:

  (def bam (a b)
    (err "collision type unknown!"))
  (defm bam ((t a ship) b)
    (destroy ship)
    (destroy b))
  (defm bam ((t a ship) (t b missile))
    (destroy ship)
    (destroy missile)
    (add-points missile!source))

Like I said: already implemented clojure-style multimethods. And tried it. So yes: I'll continue bashing my head implementing CLOS-style multimethods, because while clojure-style multimethods are cute, they're not good enough for all cases. Arguably neither are CLOS-style multimethods, but at least we have an alternative choice.

Edit:

Also, there's a good reason for implementing this in the scheme-side: efficiency. Your implementation of clojure-multimethods allocates a cons cell for each argument to the multimethod. The scheme-side implementation does not, because on the scheme-side I have access to the ar-funcall* functions.

Efficiency of course is not a concern, except when it is.

For me, cute means something really really nice, not necessarily useless. Like cute mature women, for example. Or better: cute girls, with guns. LOL.

Method chaining may require us to rethink PG's type system, at least if we want to handle a drop-down to a more generic type (which arguably is the more interesting bit about chaining). It's reasonably easy to drop from the "argument 2 matched type T" to "argument 2 matched no types", but how about when we want to drop from "argument 2 matched derived type D" to "argument 2 matched base type B"?

Waa.

Specifically, arc.sh sets the environment variable "arc_dir" to the installation directory.

I would suggest making a batch file which sets the environment variable arc_dir properly before launching mzscheme -af as.scm ^^

  C:\User\Programming\Arc\arc3f\arc-f>set arc_dir=C:\User\Programming\Arc\arc3f\arc-f

  C:\User\Programming\Arc\arc3f\arc-f>mzscheme -mf as.scm
  Compiling arc.arc...
  Use (quit) to quit, (tl) to return here after an interrupt.
  <User>tl:

Also of note, arc.sh doesn't work in Cygwin:

  $ sh arc.sh
  > default-load-handler: cannot open input file: "c:/cygdrive/c/User/Programming/Arc/arc3f/arc-f/as.scm" (The system cannot find the path specified.; errno=3)

   @echo off
   set arc_dir=C:\Program Files\ARCF
   mzscheme -mf "%arc_dir%\as.scm"

  Use (quit) to quit, (tl) to return here after an interrupt.
  <User>tl: (load "arc-life.arc")
  Error: "reference to undefined identifier: __<arc>car_"

  (prn "foo")

  Use (quit) to quit, (tl) to return here after an interrupt.
  <User>tl: (load "test.arc")
  foo
  nil
  <User>tl:

  E:\>"C:\User\Programming\Arc\arc3f\arc-f\arc.bat"
  Use (quit) to quit, (tl) to return here after an interrupt.
  <User>tl:

  E:\> copy con tmp.arc
  (prn "hello world!")
  ^Z                       <---- that's a control-Z
  E:\> "C:\User\Programming\Arc\arc3f\arc-f\arc.bat"
  Use (quit) to quit, (tl) to return here after an interrupt.
  <User>tl: (using <files>v1)
  t
  <User>tl: (ls)
  ("tmp.arc")       <--- you should get a list of files and stuff in the current directory, including tmp.arc
  <User>tl: (load "tmp.arc")
  hello world!
  nil
  <User>tl:

  (map [* _1 _2] '(1 2 3) '(4 5 6))

The auto-gensyms thing looks cute. It might be possible to hack something like that, although it would require modifying the axiomatic quasiquote operator.

Basically:

  `(let foo# ,foo
     (do-some foo# foo#))

  (quasiquote (let (unquote-uniq foo) (unquote foo)
                (do-some (unquote-uniq foo) (unquote-uniq foo))))

  (let ((gensym012032 (gensym)))
    (quasiquote (let (unquote gensym012032) (unquote foo)
                  (do-some (unquote gensym012032) (unquote gensym012032)))))

See in srv.arc:

    (def header ((o type textmime*) (o code 200))
      (string "HTTP/1.0 " code " " (statuscodes* code) "
    " serverheader* "
    Content-Type: " type "
    Connection: close"))

A second problem lies in 'readline:

    (def readline ((o str (stdin)))
      " Reads a string terminated by a newline from the stream `str'. "
      (awhen (readc str)
        (tostring
          (writec it)
          (whiler c (readc str) #\newline
            (writec c)))))