I don't see how that issue would stop you from using Anarki. And it appears news.arc was modified to accommodate the change.

I have to say, I don't like that change in making templates into first class objects. It would have been better to add something like 'inst-with' to extend inst.

If that change is a show stopper for you, then I would just fork anarki and eliminate the template changes, or fork Arc 3.1 and add the file upload change.

  arc> (save-table (obj a 10 b 20) "tfile")
  nil

  arc> (load-tables "tfile")
  (#hash((b . 20) (a . 10)))

https://sites.google.com/site/arclanguagewiki/

I'm using Arc 3.1. I don't know if it has the mutable-pair bugfix. I wish there were updated instructions somewhere explaining what's recommended or stable.

I've never seen this. Did you consider just trying racket from the same package?

What arc are you using? Does it have the mutable-pair bugfix from anarki? http://arclanguage.org/item?id=13616

If these questions don't help, one last idea is to try Pauan's https://github.com/arclanguage/arc-nu, which seems to be a better-quality implementation of the arc core. I haven't played with it much, but reports of what's broken might get me to do so, knock it into shape.

Also, v0.1.3 crashes for me:

  $ /usr/local/arcueid/bin/arcueid --include=`pwd`
  Arcueid 0.1.3 REPL Copyright (c) 2013 Rafael R. Sevilla
  This is free software; see the source code for copying conditions.
  There is ABSOLUTELY NO WARRANTY; for details type (warranty)
  arc> (load "libs.arc")
  *** redefining arg
  nil
  arc> (load "mywebapp.arc")
  *** redefining nbsp
  *** redefining input
  *** redefining submit
  *** redefining menu
  Segmentation fault (core dumped)
  
  
  
  
  $ gdb /usr/local/arcueid/bin/arcueid GNU gdb (GDB) 7.5-ubuntu
  Copyright (C) 2012 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-linux-gnu".
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>...
  Reading symbols from /usr/local/arcueid/bin/arcueid...done.
  (gdb) run --include=/home/me/arc3.1
  Starting program: /usr/local/arcueid/bin/arcueid --include=/home/me/arc3.1
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
  Arcueid 0.1.3 REPL Copyright (c) 2013 Rafael R. Sevilla
  This is free software; see the source code for copying conditions.
  There is ABSOLUTELY NO WARRANTY; for details type (warranty)
  arc> (load "libs.arc")
  *** redefining arg
  nil
  arc> (load "mywebapp.arc")
  *** redefining nbsp
  *** redefining input
  *** redefining submit
  *** redefining menu
  
  Program received signal SIGSEGV, Segmentation fault.
  0xb7fa9918 in arc_append (c=0x804c120 <cc>, thr=177156352) at cons.c:327
  327	     AFCALL(arc_mkaff(c, arc_apply, CNIL),
  (gdb) bt
  #0  0xb7fa9918 in arc_append (c=0x804c120 <cc>, thr=177156352) at cons.c:327
  #1  0xb7f9de68 in __arc_resume_aff (c=c@entry=0x804c120 <cc>, thr=thr@entry=177156352)
      at ccode.c:263
  #2  0xb7fc9e76 in __arc_thr_trampoline (c=c@entry=0x804c120 <cc>, thr=thr@entry=177156352, 
      state=<optimized out>, state@entry=TR_RESUME) at vmengine.c:104
  #3  0xb7fc62d0 in arc_thread_dispatch (c=0x804c120 <cc>) at thread.c:405
  #4  0x08049526 in main (argc=1, argv=0xbffff704) at repl.c:590

---

"Perhaps it's impossible to do if commas don't expand to unquote ?"

From what you're saying, it sounds like you're using some custom data structures, but that you just haven't given yourself all the primitives you need to manipulate them.

  > foo <- (make-unquote 12)
  ,12
  
  > (unquote? foo)
  t
  
  > (unquote-get foo)
  12
  
  > foo <- (make-quasiquote 12)
  `12
  
  > (quasiquote? foo)
  t
  
  > (quasiquote-get foo)
  12

  (def foo (a) `(list ,a))

  arc> (foo 3)
  (list 3)

I use the term "Pure Dataflow Programming" in reference to the original idea put forth by Bert Sutherland's paper "The On-line Graphical Specification of Computer Procedures" and others. It is characterized by fine grain operations (small operations like add or subtract) and the assumption that dataflow concepts will be employed for all levels of an application.

Flow-Based Programming takes the Dataflow concepts but says that the nodes (aka components) should be programmed using our current, sequential, control-flow programming languages. The Dataflow graph is a layer above and it controls the execution of the nodes.

Reactive Programming is a newer term. I use it to mean Dataflow using the push model (nodes only execute when data is pushed to it). It is "reactive" to changing data.

There is a tower of babble in respect to Dataflow terminology because we haven't yet defined a common meaning for all the terms. These are my definitions for the terms but everyone seems to define things slightly different.

I will have a chapter in the book that explains all the terms and their common synonyms.

As Dataflow concepts are just now starting to come to the attention of the masses, we don't have any consensus on the best, or most common, Dataflow implementation architecture. So the book will cover all the tiny variations of Dataflow architectures and compare them to each other for their pros and cons.

I would sometimes do this:

  (def recstring (test s (o start 0))
       (let helper (afn (i)
                        (and (< i (len s))
                             (or (test i)
                                 (self (+ i 1)))))
            (helper start)))

http://canhekick.it/project/52464fcc8f64d1fd5512a6c7

In Arc, my immediate approach would be to define 'push as a macro, but also to give it a procedure version that's just a little more verbose. Then we can extend the procedure version and leave the macro version alone.

Here's some working Arc 3.1 code, which calls the macro "my-push", rather than overwriting Arc's own 'push:

  (mac place (p)
    (w/uniq new-val
     `(make-place (fn () ,p) (fn (,new-val) (= ,p ,new-val)))))
  
  (def make-place (getter setter)
    (annotate 'place (list getter setter)))
  
  (def place-get (place)
    (rep.place.0))
  
  (def place-set (place new-val)
    rep.place.1.new-val)
  
  (defset place-get (place)
    (w/uniq g-place
      `((,g-place ,place)
        (place-get ,g-place)
        [place-set ,g-place _])))
  
  
  (mac my-push (elem stack)
    `(fn-push ,elem (place ,stack)))
  
  (def fn-push (elem stack)
    (zap [cons elem _] place-get.stack))

  foo <- (fn (n) (eval `(+ ,n 1) caller_scope))

  foo <- (fn '(n) (eval ((fn () `(+ ,n 1))) caller_scope))

---

"I'm still not convinced I fully understand why eval and fn each add an indirection to caller_scope ."

(For the moment, I'm going to overlook eval here.)

That's just how you chose to build it, right? Isn't the whole point of caller_scope that it's specific to the current call?

I think the main issue you're encountering is that you always use the same name, "caller_scope", resulting in shadowing. Kernel uses an explicit parameter, as in ($vau () env ...), but Wart doesn't. This isn't necessarily a problem, because you can do something like this to work around the shadowing when necessary:

  (fn (x)
    (let my_scope caller_scope
      (fn (y)
        ...)))

I think this code will evaluate the ... as though it's just inside the (fn (x) ...), so that it can see the correct binding of caller_scope:

  (fn (x)
    (let fnx_scope ((fn () caller_scope))
      (fn (y)
        (eval '... fnx_scope))))

If you tweak the language a bit, you could make the implicit caller_scope parameter get shadowed by the explicit parameters. That is, if a function is of the form (fn (caller_scope) ...), you could let it ignore its implicit caller_scope binding altogether. (Currently Wart treats this just like any other duplicate argument name, and it throws an error.) In that case, you could use this technique:

  (fn (x)
    (let my_scope caller_scope
      (fn (y)
        (let caller_scope my_scope
          ...))))

---

"I'm still not convinced I fully understand why eval and fn each add an indirection to caller_scope ."

(Now to tackle eval.)

Are you sure 'eval adds a layer of indirection? I think the only indirection you're encountering is caused by 'fn. I just tried it out in Wart to make sure:

  ((fn () ((fn () (caller_scope = caller_scope)))))
  => ''1
  ((fn () ((fn () (caller_scope = (eval 'caller_scope caller_scope))))))
  => nil
  ((fn () ((fn () (caller_scope = ((fn () (eval 'caller_scope caller_scope))))))))
  => ''1

Within this second layer, we get a true value for (caller_scope = caller_scope). This is just a sanity check.

We false value for (caller_scope = (eval 'caller_scope caller_scope)), presumably because we're comparing the two different environments we've established.

Finally, it seems we can successfully use ((fn () (eval '<foo> caller_scope)))) in place of <foo>, because although it introduces a new environment, it evals in the old one.

Here's another way we can verify that eval doesn't introduce its own binding for caller_scope:

  ((fn () (eval 'caller_scope caller_scope)))
  020lookup.cc:28 no binding for caller_scope
  => nil
  ((fn () (eval '2 caller_scope)))
  => 2

---

"But I needed it to expand to this:"

  let $old push
    mac (push x s)
      `(if (isa stack ,s)
         (push ,x (rep ,s))
         (,$old ,x ,s))

  mac (push x s) :case `(isa stack ,s)
    `(push ,x (rep ,s))
  
  -->
  
  let $old push
    mac (push x s)
      `(if ,`(isa stack ,s)
         ,`(push ,x (rep ,s))
         (,$old ,x ,s))

In between the , and the ` you have "room to operate on the names before starting on the backquote":

  mac (foo n) :case (let a .. `(isa foo-type ,a))
    with (a ..
          b ..)
      `(bar ,a ,b)
  
  -->
  
  let $old foo
    mac (foo n)
      `(if ,(let a .. `(isa foo-type ,n))
         ,(with (a ..
                 b ..)
            `(bar ,a ,b))
         (,$old ,n))

---

"But even if there isn't, I'm starting to question if lisp is indeed the hundred-year programming model. I'm starting to feel at the end of my tether, at the limits of what macroexpansion can cleanly support."

Yeah, it's an interesting problem. One that I should probably understand better... I mean, I "get" it: the RAM machine model is simple. But I've not programmed enough C (or similar) to understand how far the semantics would permeate day-to-day programs.

There's the part of me that's like "oh, just have primitives to reference & dereference addresses; easy". I seem to recall Lisps that use something like (ref x) and (deref x), and the explicitness pleases me, coming from "modern" languages where you have to remember odd rules about whether/where things are passed as pointers. But then I read C code and see all these pointers-to-pointers all over the place---in spots of code where I normally wouldn't think of pointers at all. Then again, that might be endemic to C, where you're probably just being destructive by default.

  animals!dog!thaddeus!age

I thought the execution was fine! I only objected to the direction :p Only simplification I could see was to turn:

  (if args 
      `(,f ,@(join args (list x)))
      `(,f ,x)))

  `(,f ,@args ,x)