(fn(_) (do "foo"))

  (fn(_) ("foo"))

[ ... ] expands to (fn(_) (...))

Because you can already write aform submission code that looks like:

  (defop said req
    (aform [ (pr "You entered " (arg _ "foo"))]
      (input "foo") 
     (submit)))

  (fn (_) ((pr "You entered.")))

So [ "foo" ] expands to (fn(_) ("foo")), which fails because you're trying to call a string like a function.

*or use a hidden field on a form submit.

I would like this second link to be what shows up on the top of the browser as the new url. -- but I would also like that page to be initialized with parameters I could express so far only with a closure.

I don't want to pass those parameters to the second link, because then they'll be visible.

So now I need to first save these initialization parameters somewhere (much like saving a closure) and modify the second link to check if there are any scheduled parameters to initialize itself with for a particular user. Some sort of defop-init.

(Am I missing something?)

Down the drain go closures when combined with redirection.

  (defop arf rq (arform [ "foo" ] (prn "Click:") (submit)))

The following works:

  (defop arf rq (arform (fn (req) "foo") (prn "Click:") (submit)))

  ;; aformh doesn't do it
  (defop prove-it1 req
    (aformh [ (pr "peekaboo") ]
            (pr "do something1 ")
            (submit)
            "/some-fancy-url"))

  ;; Neither does arformh
  (defop prove-it2 req
    (arformh [ (pr "peekaboo") ]
            (pr "do something2 ")
            (submit)
            "/some-fancy-url"))

  (defop some-fancy-url req (pr "Yeii!"))

https://github.com/Pauan/ar

  $ racket -f as.scm

In general, the instructions we've been steering newcomers toward are at https://sites.google.com/site/arclanguagewiki/getting-starte..., which we try to keep up-to-date. If that helps in this case.

If we syntax-highlight (withs ...) this way, since it expands into several (fn ...) forms it'll give a different color to each of its variables. But that's assuming we're able to perform some amount of macroexpansion frequently enough to be useful as the programmer edits, and it also assumes we can relate the original syntax to the transformed version returned by the macro.

Whoa, how do you mean?

One idea I've been thinking about a lot is to attach metadata to code. We can do a lot to code (pretty-print, optimize, ...) besides just eval it, and metadata might help with those without affecting eval.

My favorite use for this idea is to give functions levels:

  def (foo x y) :(level 3)
    34

This can be used in a variety of ways by different tools. You could flag as errors any calls from a lower to a higher level, so that level 3 functions could only call functions in levels 1-3. You could tell tracers to trace everything until level x, not below. You could tell debuggers to automatically step past calls below level x and step _into_ calls above that level. In gdb I often accidentally hit 'next' when I meant 'step', and now I have to restart and laboriously try again from scratch.

You could syntax-highlight calls within a level to be more salient to calls to lower levels. We've all seen open source projects with this structure.

  void main() {into 
    ...  // lots of option parsing crap
    if (doSomething()) { // the actual app code
       ... // more crap
    }
    ... // more crap
    return -1;
  }

In general, syntax highlighting sucks[1] because we simply highlight the things it's easiest to infer. Metadata might help reduce the inference burden and open up new uses for color.

  (mac parameter (x y)
    (w/uniq (var body)
      `(do (var ,x ,y)
           (mac ,(sym:string "w/" x) (,var . ,body)
             `(w/ ,',x ,,var ,@,body))
           ,x)))