(let x init
    (when (f x)
      ...body...))
  ==>
  (checklet x f init
    ...body...)

  (def fn-checklet (test x body)
    (test&body x))
  (mac checklet (var test x . body)
    `(fn-checklet ,test ,x (fn (,var) ,@body)))

How would ssyntax work, then?

Whatever gets passed to 'ssyntax or 'ssexpand oughta be able to contain symbols with ssyntax characters in them, or else they'll be trivial to implement. :-p

On Google: The 14th hit (2nd page) is arclanguage.org/. The 17th hit is paulgraham.com/arc.html. I don't see any more results in the next few pages. This being a Google search, the results are tailor-made according to my personal search history. (Ironically, this means there is some value in asking someone else to Google it for you. :-p )

On DuckDuckGo: The 26th hit (2nd page) is www.paulgraham.com/arc.html. I don't see any more results in the next few pages. DuckDuckGo gives everyone the same search results.

---

Searching for other things...

Searching for [emacs arc] on Google and DuckDuckGo doesn't give me arclanguagewiki on the first ten pages, regardless of whether I use Google or DuckDuckGo. (In fact, DuckDuckGo runs out of results, or at least stops listing them, after about ten page breaks. Each page seems to have more and more results on it as well, so the scrollbar of sisyphus makes it hard to count.)

Searching for [arc lisp], [learning arc], or [install arc] on DuckDuckGo doesn't seem to turn up arclanguagewiki at all. These searches work just fine for me on Google, turning up arclanguagewiki on the first page as you say.

When they first launched it, the tabs to use or not use social search results were right there on the top right section of the search page. They've since been moving it around and it shows only if you click "More search tools" on the bottom left, where one option is "All search results" and another is "Social". And it isn't immediately obvious how much weightage the first gives to social results, if any at all.

Personally, I think this is all moot, but I'd go with "checkify" or "to-check".

  testify
    Pro: Only 7 characters long.
    Pro: Bunches with related words containing "ify."
    Con: Bunches with unrelated words containing "test."
    Con: Is a neologism if used in English.
    Con: Has non-sequitur homonyms in English (one meaning "claim").
    Con: The vocal majority here at Arc Forum seems to dislike it. :-p
  
  predicate
    Pro: Bunches with related words containing "icate."
    Con: Debatable pronunciation.
      "predikayte"
        Con: Is a neologism if used in English, I think. It
          reinterprets the verb as a verbalization of the "predikit"
          version, when "predikit" is actually something of a
          nominalized form of "predikayte" in the first
          place[Wiktionary]. Is it already used this way?
        Con: Has non-sequitur homonyms in English (one meaning
          "assume").
      "predikit"
        Pro: Same as a related term used in English discussion.
      "predikahtay"
        Con: Has a non-sequitur homonym in Italian (meaning
          "preach")[Wiktionary].
    Con: Since it has the same spelling as a noun, it may conflict with
      other noun-based names (e.g. accessors, local variables).
    Con: In English discussion, needs special formatting to look like a
      variable name.
  
  checkify
    Pro: Bunches with related words containing "check."
      Pro: "Check" is a related term that can be dropped casually into
        English discussion.
      Con: "Check" has many non-sequitur homonyms in English (one
        meaning "restrict").
    Pro: Bunches with related words contianing "ify."
    Con: Is a neologism if used in English.
  
  to-check
    Pro: Bunches with related words containing "check."
      Pro: "Check" is a related term that can be dropped casually into
        English discussion.
      Con: "Check" has many non-sequitur homonyms in English (one
        meaning "restrict").
    Pro: Bunches with related utilities containing "to-".
    Con: Is a downright technical term if used in English.
    Con: "To check" could be seen as an infinitive form.

Personally, I consider something to be my kind of Arc once it's easy for me to adapt Lathe (my library of frameworks) to its quirks, even if Lathe doesn't work out of the box--and even if not all features of Lathe are available. That is to say, whatever set of assumptions I implicitly rely on in Lathe forms a common subset of several Arc-like languages, and I might as well call that common subset "Arc." I admit it's vague (what features of Lathe are optional and what aren't?) and that it isn't necessarily the same as what someone else would call Arc. Nevertheless, Lathe has a few unit tests to make this goal more discrete, in the examples/ directory.

https://github.com/conanite/rainbow/tree/master/src/arc/lib/...

It's safe to use these as a specification.If you fire up an arc3 repl within the rainbow src directory you can run the same tests to verify you get the same behaviour.

Well, I've tried to run the tests that do work fine with 3.1 and Anarki under Arcueid and find a lot of issues. For starters, I had no idea that Arc treats symbols with |'s specially. Looks like more accidental behavior inherited from MzScheme/Racket. Scheme48 says that '|abc| contains illegal characters. Guile creates a symbol |abc|. I don't see anything in R^6RS that mandates any of this behavior. Heh, looks like I've got a lot of work to do!

Older versions of Nu had lots of unit tests, yeah, but I haven't ported them over to the latest version of Nu yet and probably won't do so anytime soon, as I've unfortunately lost the motivation to work on anything Arc related.

---

"Nu's benchmarks are meant to be runnable on multiple Arc implementations for comparison purposes, so they could be a good start."

Yeah, but for now all the Arc implementations need to be built on top of Racket, so it works for ar, Arc 3.1, Nu, etc. but not, say, Rainbow. Getting it to work with non-Racket processes is probably doable - albeit difficult - and it would come at the cost of accuracy in the tests.

Can you implement vau like this?

  ; (vau (a b c) env ...body...)
  ; ==>
  ; (fn '(a b c) (let env caller-scope ...body...))
  ;
  (def vau '(parms env body)
    (eval (list fn (list quote parms)
            (list* let env 'caller-scope
              body))
          caller-scope))

What is 'caller-scope bound to at the top level?

---

"It seems all its drawbacks wrt vau involve hygiene, which I want to explore ignoring."

What drawbacks are those?

---

"Phew, that was a two-week-long tangent that involved me ripping wart down to its foundations before building it up again, and revisiting all my assumptions about how things work."

Or perhaps you're talking specifically about functions mutating their environment... well you can do that in Kernel too:

  (wrap ($vau ... env ...))

  ($vau ... env1
    ($vau ... env2
      ...))

  (fn '...
    (let env1 caller-scope
      (fn '...
        (let env2 caller-scope
          ...)))

I think so, yes!

I got to properly understand vau, to realize that its environment arg is never explicitly passed in.

  wart> caller-scope
  007scope.cc:122 No binding for caller-scope

If I just saw 'caller-scope in pseudocode somewhere, I'd implement it as an anaphoric variable of 'fn (and I'd implement a non-anaphoric variant of 'fn to base it on, so we'd basically be at vau again :-p ). So at the global scope, my implementation would just treat 'current-scope as a global variable.

  (env= caller-scope foo 5)

  (let global caller-scope
    ...
    (env= global foo 5)
    ...
    (eval ... global))

  ($let ((global (get-current-environment)))
    ...
    ($set! global foo 5)
    ...
    (eval ... global))

On the other hand, it's quite easy to define wart's magical fn in terms of vau... with no leaky abstractions! The only catch is that caller-scope will always refer to the global scope inside vau forms... that could be changed too, by extending/overwriting vau, but I didn't do that:

  (= get-current-environment (wrap (vau () e e)))

  ;; don't define this if you don't want caller-scope at the global level
  (= caller-scope (get-current-environment))
  
  ;; simple fn, without magical quoted args or caller-scope
  (= fn (vau (parms . body) env
          (wrap (eval `(,vau ,parms nil ,@body)))))

  ;; omitting other stuff like afn, no, caris, list, etc.
  ;; but they can all be defined in terms of simple fn
  ... 
          
  ;; makes these variables hygienic
  (with (with  with
         eval  eval
         let   let)
         
    ;; this recreates the part of wart that is currently handled in C++
    (= parse-fn (fn (parms env)
                  (if (caris x 'quote)
                      (list (cdr parms) nil)
                      ((afn (x vars parms)
                         (if (no x)
                               (list (rev parms)
                                     (rev vars))
                             (caris (car x) 'quote)
                               (self (cdr x)
                                     vars
                                     (cons (cdar x) parms))
                             (let c (car x)
                               (self (cdr x)
                                     `((,eval ,c ,env) ,c ,@vars)
                                     (cons c parms)))))
                       parms nil nil))))
    
    ;; overwrite with the complex fn which has quoted args and caller-scope
    (= fn (vau (parms . body) env
            (w/uniq new-env
              (let (parms vars) (parse-fn parms new-env)
                (eval `(,vau ,parms ,new-env
                         (,with ,vars
                           (,let caller-scope ,new-env
                             ,@body)))
                      env))))))

  (fn (a 'b . c)
    ...)

  (vau (a b . c) g1
    (with (a (eval a g1)
           c (eval c g1))
      (let caller-scope g1
        ...)))

One more caveat: I'm not sure how you implemented caller-scope. If it's hardcoded into every function such that functions can't have an argument called "caller-scope" then the above will work the same way. But if it's a global implicit parameter like in Nu and ar, then you'll need to search the arg list for an argument called "caller-scope", which is doable but would require some more code, especially for handling argument destructuring.

---

Anyways, I'm not saying you should necessarily do it this way in wart, but... I think it's cleaner, conceptually, for functions to be defined in terms of vau, rather than vau being defined in terms of functions.

Hmm... yeah, it's a pretty leaky abstraction. It's one of these features with ambient authority:

  (if designed like a global variable assigned at the beginning of each
  call)
  
  Right now, get the most recently started call's caller's environment.
  
  
  (if designed like a continuation mark)
  
  Right now, get the deepest-on-the-stack call's caller's environment.
  
  
  (if designed like a local variable bound by each (fn ...))
  
  Given a non-global lexical environment, its local variables must have
  been initially bound by some call, so get the lexical environment
  that was used to evaluate that call.

...Actually, the first two of these designs are broken! Say I define a simple fexpr like this one:

  (def idfn '(result)
    (eval result caller-scope))

  ((fn (a) ((fn () (idfn caller-scope)))) 1)  ; eval'd in global scope
  ((fn () (idfn caller-scope)))  ; eval'd in local scope of (fn (a) ...)
  (idfn caller-scope)            ; eval'd in local scope of (fn () ...)
  (eval result caller-scope)     ; eval'd in local scope of idfn
  caller-scope                   ; eval'd in local scope of (fn () ...)

Does Wart have this awkward behavior, akkartik?

---/change of topic---

To get back to the point, the local-variable-style version of the feature (the only version that works?) doesn't strike me as completely undesirable. It lets the programmer evaluate expressions in arbitrary ancestor stack frames, and that isn't a shocking feature to put in a debugger.

Wart returns the scope with a set to 1. Is that the one you mean? It's different from the value of:

  ((fn (a) caller-scope) 1)

http://github.com/akkartik/wart/blob/98685057cd/008eval.cc#L...

But I don't think it will become Kernel. Kernel seems really elegant as long as you give up quote and quasiquote. I suspect if you bolt them onto Kernel it'll have slid from its sweet-spot peak of elegance. A language that encourages quoting and macros will diverge significantly from Kernel.

http://github.com/akkartik/wart/blob/98685057cd/008eval.cc#L...

It tries to bind caller-scope after the params, so this fails:

  wart> def foo(caller-scope) 34
  wart> foo 3
  007scope.cc:77 Can't rebind within a lexical scope
  dying

In wart scopes are just tables. It's not a good idea to modify them, but nobody will stop ya :)

"Kernel's "get-current-environment" is not the same as the environment argument passed to fexprs."

Can you elaborate? In

  ($vau foo env
    ..)

  ($let ((env1 (get-current-environment)))
    ...
    ($vau foo env2
      ...
      ($let ((env3 (get-current-environment)))
        ...))

env2 is the dynamic scope where the $vau is called, it does not include bindings for foo, env1, env2, or env3.

env3 is the environment of the $vau itself. This environment inherits from env1, and thus is lexical just as env1 is. And so, it contains all the bindings of env1, in addition to bindings for foo, env1, and env2, but not env3.

So, by using this combination of lexical and dynamic scope, you can express a huge variety of different things in Kernel.

---

Let me explain via a more elaborate example:

  ($let ((global (get-current-environment)))
    (display (eval 'x global))
    
    ($set! global $foo
      ($vau (x) env
        (display (eval 'x env))
        (display (eval 'env env))
        
        ($let ((inner (get-current-environment)))
          (display (eval 'x inner))
          (display (eval 'env inner))
          (display (eval 'global inner))))))
          
  ($let ((x 10))
    ($foo 20))

Then, we create a $vau form and assign it to the variable $foo in the global environment. This is the same as saying ($define! foo ...) at the top level, but is necessary when inside a $let.

Now, at the bottom, we use $let to bind the variable 'x to 10 and then call $foo with the single argument 20. First, $foo tries to evaluate the variable 'x in the dynamic environment "env". This should display 10, because it's using the binding in the $let where $foo is called.

We then evaluate the variable 'env in the $vau's dynamic environment. But the variable 'env does not exist in the dynamic environment, so it throws an error.

Then, we use a $let inside the $vau to grab a hold of the $vau's inner environment and bind it to the variable 'inner. We then evaluate the variable 'x in the $vau's inner environment. This should display 20, because it's using the binding inside the $vau, which is bound to the $vau's argument 'x which was 20 when calling the $vau.

We then evaluate the variable 'env in the $vau's inner environment, which evaluates to the dynamic environment, because inside the $vau, the variable 'env is bound to the dynamic environment.

Lastly, we evaluate the variable 'global in the $vau's inner environment. This evaluates to the global environment because the $vau's inner environment inherits from the top-level $let where the variable 'global is bound.

--

Here is a picture showing the environments in the above code:

http://img42.imageshack.us/img42/1870/vauenvironments.png

The global environment is pink, the first blue environment is the $let's environment that inherits from the global environment, plus a binding for the variable 'global. The green is the $vau's environment which inherits from the $let's environment, plus a binding for the variables 'x and 'env. And the yellow is the $let's environment that inherits from the $vau's environment.

In Kernel, the dynamic environment is exactly analogous to dynamic scope. The difference is that lexical scope is the default, and you have to explicitly ask to evaluate things with dynamic scope, rather than earlier Lisps which used dynamic scope by default and didn't even have lexical scope.

Special variables in Common Lisp are similar to dynamic scope, except you're flagging only certain variables to be dynamic, whereas the dynamic environment in Kernel lets you evaluate any variable with dynamic scope.

---

"If we only create bindings using let and combiner parameters, the dynamic environment is just the caller's static environment, is that right?"

Yes. In fact, in Kernel, $let is defined just like it is in Arc, using $lambda. And $lambda uses $vau, and $vau is the only way to create new environments in Kernel, as far as I know. So, environments are all about $vau.

---

  ($define! $foo
    ($vau (x) env
      (list x env)))
      
  ($define! $bar
    ($vau (x) env
      ($foo x)))
      
  ($bar 10)

  ($define! $bar
    ($vau (x) env
      ($foo x env)))

  ($let ((x 10))
    ($bar x))

  ((wrap ($vau (x) env
           ($bar x env)))
   10)

---

"I thought about whether I could build lazy eval directly using $vau"

Ah! I considered this approach when I was building dynamic variables in wart, but it seemed less confusing to attach the scope to the binding. Wart is unlike common lisp in this respect. SBCL:

  * (defvar foo 34)
  * (defun bar() (foo))
  * (bar)
  34
  * (let ((foo 33)) (bar))
  33 ; foo is still dynamic. WEIRD.

  wart> = foo 34
  wart> def bar() foo.
  wart> bar.
  34
  wart> let foo 33 bar.
  34 
  wart> making foo 33 bar.
  33 ; dynamic scope

  ($vau () env
    (eval 'x env))

---

If you're talking about something similar to Racket's parameterize, you should be able to build that using dynamic-wind. Then something like this...

  ($parameterize ((foo 10))
    ...)

  ($let ((env   (get-current-environment))
         (orig  foo))
    (dynamic-wind ($lambda ()
                    ($set! env foo 10))
                  ($lambda ()
                    ...)
                  ($lambda ()
                    ($set! env foo orig))))

In fact, I'm gonna write a $parameterize form right now:

  ($define! $parameterize-redirect
    ($vau (target tree . body) env
      ($let ((inner (get-current-environment))
             (env   (eval target env)))
        (dynamic-wind
          ($lambda ()
            ($set! inner orig
              (map ($lambda ((var expr))
                     (list var (eval var env)))
                   tree))
            (for-each ($lambda ((var expr))
                        (eval (list $define! var expr) env))
                      tree))
          ($lambda ()
            (eval (cons $sequence body) env))
          ($lambda ()
            (for-each ($lambda ((var expr))
                        (eval (list $define! var expr) env))
                      orig))))))
                      
  ($define! $parameterize
    ($vau (tree . body) env
      (eval (list* $parameterize-redirect env tree body) env)))

  ($let ((x 5))
    ... x is 5 ...

    ($parameterize ((x 10))
      ... x is 10 in here ...
      )

    ... x is 5 again ...
    )

What about this?

  (def get-current-environment ()
    caller-scope)

  get-current-environment.
  thunk.caller-scope.

  (get-current-environment)
  ((fn () caller-scope))     ; Wart
  (($vau () e e))            ; Kernel

http://rocketnia.github.com/rainbow-js/test/#libs

If your browser supports gzip (and whose doesn't?) it'll probably be about 80KB of data, nothing to worry about, lol. If it doesn't, it'll be about 295KB. If it doesn't and there isn't any caching going on, it'll be about 375KB (because currently, (load ...) makes two duplicate AJAX requests).

You can still go here to get a REPL with no libraries:

  (fn nil (with (eof (uniq) f (infile "arc.arc") l
  *** redefining no
  *** redefining map1
  *** redefining pr
  *** redefining list
  nil 
  repl in 110995ms
  arc> (list 1 2 3)
  (1 2 3)
  arc> (java-invoke window 'eval (list "navigator.
  "Mozilla/5.0 (Linux; U; Android 2.2.2; en-us; MB
  arc>

  (java-invoke window 'eval (list "navigator.userAgent"))

That first line is kind of an implementation detail for now. The code that initializes the REPL is here: https://github.com/rocketnia/rainbow-js/commit/10a171557ef65...

It uses an "e" option in its call to Console.mainAsync(). This corresponds to Java Rainbow's -e command line parameter, and it takes an Array of strings, each string containing a single Arc command to evaluate. The results are printed as part of the initial output, the part before the first prompt shown.

The first Arc command passed into "e" is (assign load-from-web (fn ...)), which results in the big (fn ...) at the beginning of the output.

"A continuation can be invoked from the thread (see Threads) other than the one where it was captured."

Okay, that's not very helpful on its own.... The rest of the Racket docs don't seem to help either.

---

Based on nothing but intuition, what I expect to happen in your example is for the REPL thread to print "alive", sleep for the specified amount of time, print "dead", and terminate.

Now that I mention it, that could be what you're seeing. XD I don't know why "dead" didn't print in the full transcript you posted, but maybe the thread terminated before it got a chance to flush? How long did it take for the Racket REPL to appear?

By the way, you say "Trying to do the same thing in Arc 3.1," but what was the first attempt in? I'm guessing Anarki, but maybe it was some member of the Nu family. :)

What follows is an autobiography by counterexample. That is, it's my anecdotal evidence for the original order being out of whack.

For a high-level view (or for the sake of tl;dr), my progression is 1-8-M-4-5-7-2-10-7-9-9-3-9-M-6-5-9, and I consider my progress to be incomplete in levels 2, 8, 10, and M.

---

Level 1, The Read-and-Type

Level 8, Meta Man (In the sense that I approached every problem by designing a new language, not in the sense that I actually implemented easy-to-use languages and tools! I'm still working on that, lol.)

Mystery Level, Computer Scientist (in the sense that I hoped my pseudocode languages were advancing the state of the art, though they really weren't)

Level 4, Object-Dot-Method Guy

Level 5, Multiple Paradigm Man (in the sense that I knew that I could get certain things easily from one language that were more difficult or impossible in another)

Level 7, Architect Astronaut (not because I confused complexity with value, but because I was finally able to shoehorn abstract concepts into existing languages rather than keeping them in pseudocode)

Level 2, The Script Kiddie (in the sense that I started using filesystem calls sometimes but not on a whim)

Level 10, Language Oriented Designer (in the sense that I decided it would always be true that with certain shoehorned pseudocode, it makes life easier to admit it's a language of its own)

Level 7, Architect Astronaut (in the sense that my languages would have had kitchen sinks at this point in my life)

Level 9, Functional Nirvana (but only in the sense that I knew I'd learn a lot about custom syntax from a lisp)

Level 9, Functional Nirvana (in the sense that as I approached lisp--by way of Groovy--I discovered the sweetness of using first-class procedures for list comprehension, custom control flow, event handlers, etc.)

Level 3, The Librarian

Level 9, Functional Nirvana (in the sense that I actually started using a lisp, Arc)

Mystery Level, Computer Scientist (in the sense that I realized the language-oriented technique I wanted to pursue was not available in any language, and I expected to need to advance the state of the art)

Level 6, Architect Apprentice (Thanks to my frustration at the places Arc's modularity, customizability, and extensibility falls short (especially its modularity), and the fact that there was no other language I liked better, I've focused on Arc library design in particular and learned what approaches I liked and what approaches I could expect even if I didn't like 'em.)

Level 5, Multiple Paradigm Man (in the sense that every way to improve on Arc's code reusability seemed to require a compromise)

Level 9, Functional Nirvana (in the sense that I've realized that expressing certain kinds of modularity takes a reactive model and/or a static type system, and that an understanding of pure FP does me wonders for elucidating the semantics of both of these things)

---

For humility's sake, here's a list (a checklist?) of the levels I know I haven't fully explored:

---

Level 2, The Script Kiddie (in the sense of not being shy to write a program to automate a mundane task)

Level 8, Meta Man (in the sense of implementing easy-to-use languages and tools)

Level 10, Language Oriented Designer (in the sense of implementing easy-to-use tools for myself and others to make languages with)