The Elm project has a lot in common with Flapjax, another FRP language. However, Flapjax automatically lifts expressions like "a + b" to return signals if the arguments are signals, whereas Elm just acts as a Haskell-like FRP library plus a Haskell-like language to use it in. In Elm, there's an explicit family of lift, lift2, lift3, ... operators for mapping an n-arg function over n Signals.

                                   Elm                   Flapjax
                          ---------------------   ---------------------
  Maintained in:           Haskell and some JS     Haskell and some JS
  Compiler runs in:              Haskell                   JS
  Application runs in:             JS                      JS
  Syntax approximates:           Haskell                   JS
  Expressions represent:         Values             Signals or Values

'Paul and Robert' don't come here anymore; we hang out here, but we can't make improvements. We could setup a new site, but the issues so far seem too minor to push us to that.

I've also added/plagiarized rainbow's tests to the repo: https://github.com/arclanguage/anarki/commit/68be3c0f4d. Joys of the perl artistic license.

There's still a couple of syntax tests that are failing, likely because of test harness issues. And I'd like to unify all the different tests into a single framework. For future work..

---

BTW, I think `(unescape-ats s)` also needs to be treated as the same.

https://github.com/Pauan/ar/commit/a2c1939936846b665eccf06d0...

I've added a few piecemeal tests over the years (all the .t files in the repo), and there's also some tests in my curated repo (http://github.com/akkartik/arc). All those seem ok..

---

Looks like dfn is a rainbow innovation: http://arclanguage.org/item?id=10539

---

I'd like to run some tests to make sure it does not cause much problem.

I found this one:

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

But it failed with following error when using arc3.1.

  arc> (load "unit-test.arc")
  nil
  arc> (rat)
  Error: "_dfn: undefined;\n cannot reference undefined identifier"

Here is a quick and dirty patch for arc3.1, it postpones string-copy and let it run by eval.

Not sure if it will cause some other problem.

  50,51c50,51
  <           (unescape-ats s))
  <       (string-copy s)))          ; avoid immutable strings
  ---
  >           `(string-copy ,(unescape-ats s)))
  >       `(string-copy ,s)))          ; avoid immutable strings

In ac.scm, in the arc compiler ac, arc strings are translated using ac-string. I've tried instrumenting the output of ac-string, and it seems mutable when it's encountered. And yet it's immutable by the time I return to the prompt:

  arc> ($.immutable? "abc")
  #f  # printed inside *ac-string*
  #t  # return value

---

I tried bisecting the git history, and the stable branch, which still requires mzscheme, has mutable strings. But sometime in 2011 when the master branch switched to using racket and stopped working with mzscheme, strings went immutable again. Still investigating..

---

Back in Feb 2011, waterhouse provided a bugfix for arc's mutable pairs. http://arclanguage.org/item?id=13616. https://github.com/arclanguage/anarki/commit/cea8a4c5e9. This change requires a racket-only lib, and so arc stopped working with the old mzscheme versions. Prior to it, modifying strings worked in mzscheme but not in racket. So it seems to be something about the move from mzscheme 372 to racket.

---

Update 34 minutes later: It seems eval in racket emits immutable strings even when given mutable strings. Since everything passes through racket's eval it doesn't matter how much arc twists and turns to avoid immutability.

  $ racket
  > (immutable? "abc")
  #t
  > (immutable? (string-copy "abc"))
  #f
  > (immutable? (eval (string-copy "abc")))
  #t

http://comments.gmane.org/gmane.lisp.scheme.plt/14787

  arc> (= (s 0) #\m)
  Error: "string-set!: expects type <mutable string> as 1st argument, given: \"foo\"; other arguments were: 0 #\\m"

Arc/Nu used to have keyword arguments, but they were a pain in the butt to implement, and only a single function actually used them, so I took them out.

If you want to go with base Arc, you can pass a dictionary in, something like this:

  (def greet ((o arg-dict (obj)))
       (prn "Hello there, "
            (or arg-dict!person "friend")
            "! Would you like "
            (or arg-dict!thing-to-offer "some ice cream")
            "?"))
  
  arc> (greet)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> (greet (obj person "Darth Vader" thing-to-offer "a lightsaber"))
  Hello there, Darth Vader! Would you like a lightsaber?
  "Hello there, "
  arc> (greet (obj thing-to-offer "two lightsabers"))
  Hello there, friend! Would you like two lightsabers?
  "Hello there, "
  arc> 

  (def greet2 arg-list
       (let args (pair arg-list)
            (prn "Hello there, "
                 (or (alref args 'person) "friend")
                 "! Would you like "
                 (or (alref args 'thing-to-offer) "some ice cream")
                 "?")))
  
  arc> (greet2)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> (greet2 'person "Darth Vader" 'thing-to-offer "a lightsaber")
  Hello there, Darth Vader! Would you like a lightsaber?
  "Hello there, "
  arc> (greet2 'thing-to-offer "two lightsabers")
  Hello there, friend! Would you like two lightsabers?
  "Hello there, "
  arc> 

  arc> (greet2 'person)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> 

  (def greet3 (emotion . arg-list)
       (let args (pair arg-list)
            (prn "Hello there, "
                 (or (alref args 'person) "friend")
                 "! I'm " 
                 emotion
                 " to see you. Would you like "
                 (or (alref args 'thing-to-offer) "some ice cream")
                 "?")))
  arc> (greet3 'happy)
  Hello there, friend! I'm happy to see you. Would you like some ice cream?
  "Hello there, "
  arc> (greet3 'enraged 'thing-to-offer "to be murdered")
  Hello there, friend! I'm enraged to see you. Would you like to be murdered?
  "Hello there, "
  arc> 

Downsides include not having a good way to set defaults -- you have to supply the default each time in the code you use it. Alternately, you can put the body in a function that requires each argument, then in the "regular" function, supply the default as an argument to the helper:

  (def greet4 (emotion . arg-list)
       (let args (pair arg-list)
            (greet4-helper emotion
                           (or (alref args 'person)
                               "friend")
                           (or (alref args 'thing-to-offer)
                               "some ice cream"))))
  
  (def greet4-helper (emotion person thing-to-offer)
       (prn "Hello there, "
            person
            "! I'm " 
            emotion
            " to see you. Would you like "
            thing-to-offer
            "?"))
  
  arc> (greet4 'bored)
  Hello there, friend! I'm bored to see you. Would you like some ice cream?
  "Hello there, "
  arc> (greet4 'bored 'thing-to-offer "to go away")
  Hello there, friend! I'm bored to see you. Would you like to go away?
  "Hello there, "
  arc> 

  arc> (greet4 'bored 'thing-to-offer nil)
  Hello there, friend! I'm bored to see you. Would you like some ice cream?
  "Hello there, "
  arc>

		Source/Medium - Visits
 	
	1.	(direct) / (none) - 1,240
	2.	google / organic - 1,130
	3.	en.wikipedia.org / referral - 695
	4.	nicholasblee.com / referral - 167
	5.	arclanguage.org / referral - 129
	6.	tryarc.org / referral - 114
	7.	arcueid-arc.org / referral - 61
	8.	reddit.com / referral - 49
	9.	news.ycombinator.com / referral - 45
	10.	lambda-the-ultimate.org / referral - 37

		Landing Page - Visits
 	
	1.	/site/arclanguagewiki/ - 1,811
	2.	/site/arclanguagewiki/getting-started/install-arc - 617
	3.	/site/arclanguagewiki/more/avl-trees - 487
	4.	/site/arclanguagewiki/getting-started/tutorial - 310
	5.	/site/arclanguagewiki/home - 160
	6.	/site/arclanguagewiki/arc-3_1/known-bugs-and-gotchas - 155
	7.	/site/arclanguagewiki/more/list-of-languages-with-s-expression-sugar - 80
	8.	/site/arclanguagewiki/getting-started/installing-emacs - 64
	9.	/site/arclanguagewiki/more/keyword-arguments - 31
	10.	/site/arclanguagewiki/arc-3_1/optimizations - 27

   arclanguage.org / referral - 129

So here is my appeal, pg, if you are listening:

Which of these interpretations do you mean?

  (list 1 2 (splice 3 4) 5)
  -->
  (list 1 2 3 4 5)
  
  
  (list 1 2 (splice (reverse (list 4 3))) 5)
  -->
  (list 1 2 3 4 5)

---

"Namely, making the lists that form the code/ast have reverse links, so you can mutate above the macro call level, instead of just insert arbitrary code in place."

I'll make an observation so you can see if it agrees with what you're thinking of: The expression "above the macro call level" will always be a function call or a special form, never a macro call. If it were a macro call, we'd be expanding that call instead of this one.

---

For these purposes, it would be fun to have a cons-cell-like data structure with three accessors: (car x), (cdr x), and (parent x). The parent of x is the most recent cons-with-parent to have been constructed or mutated to have x as its car. If this construction or mutation has never happened, the parent is nil.

Then we can have macros take cons-with-parent values as their argument lists, and your macro would look like this:

  (mac splice list
    (= (cdr list) (cdr (parent list)))
    (= (cdr (parent list)) list))

---

Suppose we have a more comprehensive alternative that lets us manipulate the entire surrounding expression. I'll formulate it without the need to use conses-with-parents or mutation:

  ; We're defining a macro called "splice".
  ; The original code we're replacing is expr.
  ; We affect 1 level of code, and our macro call is at location (i).
  (mac-deep splice expr (i)
    (let (before ((_ . args) . after)) (cut expr i)
      (join before args after)))

  (mac-deep subquote expr (i)
    `(quote ,expr))
  
  
  (list (subquote))
  -->
  (quote (list (subquote)))
  
  
  (do (subquote))
  -->
  ((fn () (subquote)))
  -->
  ((quote (fn () (subquote))))
  
  
  (fn (subquote) (+ subquote subquote))
  -->
  (fn (subquote) (+ subquote subquote))

Namely, making the lists that form the code/ast have reverse links, so you can mutate above the macro call level, instead of just insert arbitrary code in place. This wouldn't be feasible for general lists, as it is possible for a sub-list to be referenced in more than one place, but for code, each piece is generally considered unique even if it looks the same.

Anyway, this would allow for affects ranging from splicing to arithmetic and other much more evil and nefarious but possibly useful effects. I haven't thought through all of the implications, and I bet most of them are negative, but it would still be interesting to consider.

An implementation of intermediate splicing would be something like:

  (mac (list)
    (= (cdr list) (cdr (parent)))
    (= (cdr (parent)) list))

I think he's talking about run-time environments a la Kernel, Emacs Lisp, etc.

Nulan and Arc/Nu use a compile-time environment to replace symbols with boxes at compile-time. But that feels quite a bit different in practice from run-time environments (it's faster too).

---

"Are you suggesting a third thing we could insert here?"

Once again, I think he's referring to run-time environments. Basically, what he's saying is that you would use boxes at compile-time (like Nulan), but you would also have first-class environments with vau. The benefit of this system is that it's faster than a naive Kernel implementation ('cause of boxes), but you still have the full dynamicism of first-class run-time environments. I suspect there'll be all kinds of strange interactions and corner cases though.

---

Slightly off-topic, but... I would like to point out that if the run-time environments are immutable hash tables of boxes, you effectively create hyper-static scope, even if everything runs at run-time (no compile-time).