arc> (prn "abc\"")
  abc"

http://docs.racket-lang.org/reference/reader.html?q=string%2...

'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.

You seem to be focussed on questions of the form, "Why can't an A be a B?" I ask: Why should it? Different things enrich the world and provide opportunities for future cross-fertilization.

I think what math people obsess about is always reality. The fact that they are obsessing about it at all is a real phenomenon, and we can think about tracing it back to its most immediate cause. That immediate cause is likely to be a very math-like problem in need of a solution. The not-so-math-like problem which inspired that math-like problem may be an awfully long way from where we started searching, but it's still connected.

Some mathematicians (the pure mathematicians) may pursue math-like curiosities without much regard for where they're going. Still, their own intuition and sense of elegance will constrain their discoveries to forms that can come in handy later on. In this case, mathematics acts as a bridge that starts from today's human intuition and elegance and connects to tomorrow's newfound human problems.

Clearly you're looking for an efficient connection, not just any connection. I suspect the only way to find that is to keep yourself in a state of perpetually looking, even as you continue with what you're doing. Be your own JIT compiler--and yet, don't let a JIT compiler be all that you are.

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

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

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

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

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

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"

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'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..

---

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))

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))