Arc needs to do some list marshaling in any case to deal with nil -- and as such it reimplements nearly all of the list operations, deferring to mzscheme functions only for a few things. Because of this, using `mcons' shouldn't be too problematic (not even for speed, since arc functions in general are not careful about cyclic lists, a plain implementation will be fast enough -- for example, mzscheme's `map' is now implemented in scheme). I have done some tests in the past to measure

Probably the only major problem is how to deal with a rest argument. One option is to make it illegal to mutate rest arguments. Another is to hook on the fact that rest arguments are not modified often -- so instead of copying them to a mutable list on every call, they can be converted only when needed, by the functions that change the contents of these lists. Given the above (need to implement list functionality anyway), this wouldn't be difficult -- basically some wrapper around a mzscheme list that can do the necessary work. As a side benefit it can be used to deal with nil too, which will make that run faster as well.

Currently, in arc.arc, list is defined as

  (def list args args)

Another is to hook on the fact that rest arguments are not modified often -- ... they can be converted only when needed

How could this possibly work??

  ((fn args
     (= (cadr args) 'X)
     args)
   'a 'b 'c)

As a side benefit it can be used to deal with nil too, which will make that run faster as well.

Can you explain? (I need smaller steps to be able to follow you :-)

(BTW, this will be much faster than using r6rs or r5rs modes.)

Yes, I was getting that impression browsing through the r6rs and r5rs code.

  (w/ffi #f
    (cdef cfork "fork" cint ()))

  (w/ffi (read "#f")
    (cdef cfork "fork" cint ()))

  (mac foo () 1)
  (def bar () (let x (foo) (fn () x)))
  (= x (list (bar)))
  (mac foo () 2)
  ((car x))
    --> 2

And BTW, this is not just some cooked up academic non-problem. It's a practical issue. Consider this example:

  (mac foo () ...)
  (def bar ()
    ...do something...
    ...change foo...
    ...continue doing stuff...)

* You cannot change the main server handler loop unless you make it call itself via its name, so the recursive call will use the new definition.

* Macro is a local source-code transformation that replaces macro call with the macro definition (with some hygienic magic, if you prefer).

* The language adopts applicative order.

If you want redefining foo to affect the value of the closed variable 'x', then either you have a non-trivial definition of macros (macro transformation requires transformation of code surrounding the macro call) or you are adopting different evaluation semantics (like x is bound by call-by-name).

  (define cc (make-parameter #f))

  (define (input name) `(input ((type "text") (name ,(format "~a" name)))))
  (define (submit) `(input ((type "submit"))))
  (define (form . body) `(form ((action ,(cc))) ,@body))
  (define (a ref . body) `(a ((href ,ref)) ,@body))
  (define-syntax page
    (syntax-rules ()
      [(page x ...) (send/suspend (lambda (k) (cc k) `(html (body ,x ...))))]))
  (define (get name req)
    (extract-binding/single name (request-bindings req)))

  (define (start initial-request)
    (define foo (get 'foo (page (form (input 'foo) (submit)))))
    (page (a (cc) "click here"))
    (page "you said: " foo))

What I mean is most of the other posts demo how to do it with some required (exotic) framework. This example is just using the basic web server APIs of the PLT continuation based web server.

In other words in this example, Eli BOTH writes the framework (in the first 9 lines), then uses the framework in the last 4 lines.

PLT's mzscheme is in effect, a very distant cousin to Scheme. If they weren't all eggheads and had at least one attentive marketing person, they would have labeled it some new fangled SuperLispIncarnateNextGeneration (SLING) moniker and received a bit of buzz.

I haven't looked at exactly how PG implemented Arc over MzScheme, but consider this. Much of what he did _could_ be done using no more then PLT mzscheme's out of the box, macro system, custom language module capability and custom reader capability, by anyone. Yes, even you.

In some sense most of Arc is just what anyone does who develops in PLTs Scheme/laguage system, i.e., create their own custom language/DSL. PG's may have done it a bit better, more extensively, with a general purpose intent.

So what is the secret weapon here Arc, or the underlying system that allows someone to create an Arc so easily?

You could, right now, be using PLT MzScheme to do your own Arc(s), your own, just for you and your friends custom language/DSL.

While Matthew and Robby are the "drivers" (with lots of co-pilots :-) I think that setting this tone early in the project has placed PLT Scheme naturally in a lonely niche: it is a real scripting language with capabilities that rival those of everything out there and it is also a serious academic infrastructure. Typed Scheme -- the first and only sound 'gradual typing' language so far -- is just an example of what I mean. We can publish about this in the flagship research conference on programming languages and at the same time, we are using it for its intended applications. Sam Tobin-Hochstadt is porting a part of DrScheme to Typed Scheme as I type. It is this kind of experiment -- porting a piece that your "life" depends on -- that puts us squarely on the applied side, too.

It's quite short and set out in a question and answers style. The thing is, it very gently and very subtlety bends your mind around to the Lisp way of thinking. After reading this, SICP seems so much more accessible.

1 - Paste the following code into a new document test.ss and save in servlet example folder (/usr/plt/collects/web-server/default-web-root/servlets/examples/test.ss) If document name test.ss changes, change the module name on first line.

(module test mzscheme (require (lib "servlet.ss" "web-server")) (provide (all-defined)) (define interface-version 'v1) (define timeout +inf.0)

  (define cc (make-parameter #f))

  (define (input name) `(input ((type "text") (name ,(format "~a" name)))))
  (define (submit) `(input ((type "submit"))))
  (define (form . body) `(form ((action ,(cc))) ,@body))
  (define (a ref . body) `(a ((href ,ref)) ,@body))
  (define-syntax page
    (syntax-rules ()
      [(page x ...) (send/suspend (lambda (k) (cc k) `(html (body ,x ...))))]))
  (define (get name req)
    (extract-binding/single name (request-bindings req)))

  (define (start initial-request)
    (define foo (get 'foo (page (form (input 'foo) (submit)))))
    (page (a (cc) "click here"))
    (page "you said: " foo))
  

2 - Start the PLT web server sudo /usr/plt/bin/plt-web-server

3 - Open a web browser and navigate to http://localhost/servlets/examples/test.ss

* The define-syntax...syntax-rules boilerplate is a very-easy-to-bypass thing.

* Small applications are not a good justification for unhygienic macros: they bite much more when there are several people involved, or when a project lives for a long time.

2. What I mean is that variable capture is even more useful in big projects (because the DSL approach tends to be more powerful). It is true that they could cause nastier bugs if used incorrectly. But if you use them correctly (by forcing an order of evaluation and protecting the variables you use) there should be no problems. That's certainly true for a LISP-2, I'm not sure about Arc.

  (define-syntax defmac
    (syntax-rules ()
      ((defmac (name x ...) body)
       (define-syntax name
         (syntax-rules () ((name x ...) body))))))

  (defmac (unless condition body ...)
    (when (not condition) body ...))

2. Yes, DSLs are even more useful in big projects; obviously, the only source of all problems is using something incorrectly, the problem is how easy it is to write something incorrect; evaluation order has nothing to do with macros; protecting variables you use doesn't cover all problems; lisp-2 is "statistically better" because people shadow function names less frequently (see also next item).

3. They will bite -- even if you always use gensyms. A simple example:

  (def twice (func) [func (func _)])
  (mac with-duplicate (func . body)
    `(let ,func (twice ,func) ,@body))

  (let twice [+ _ _] (with-duplicate cdr (cdr '(1 2 3 4))))

2. "the problem is how easy it is to write something incorrect". Very true.

"evaluation order has nothing to do with macros" I'm sorry but that's incorrect. An example will show you why:

  (mac sum (x y) `(+ ,y ,x)) ; This is a toy, but some macros suffer from the same problem without being so trivial/stupid
  (= x 1)
  (+ x (++ x))   ; -> 3, the expected result
  (= x 1)
  (sum x (++ x)) ; -> 4, wrong result

"lisp-2 is statistically better". Well, not if people know that shadowing function can cause problems. Now a question arises: does shadowing functions solve problems in a way not possible with other methods? Does shadowing function make programs shorter? Or, equivalently, is shadowing functions really that useful? (Please provide examples if you answer this). If not, using a lisp-2 and being careful is enough. But yes, it's easy to overlook a symbol and make a mistake that can be costly. On that, I agree.

3. You are right and that's why I said "I'm not sure about [a lisp-1 like] Arc".

One of the things that you can do with macros is specify evaluation order, that's correct. You should also know when and how to evaluate your arguments, as done with the once-only utility (which is really just a thin wrapper around the obvious solution of binders).