Arc Forumnew | comments | leaders | submitlogin
5 points by akkartik 2840 days ago | link | parent

Yeah, very strange.

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
Very strange.


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. 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")
  > (immutable? (string-copy "abc"))
  > (immutable? (eval (string-copy "abc")))

4 points by dram 2840 days ago | link

Yes, That is the problem!

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.

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


3 points by Pauan 2839 days ago | link

Fixed in Arc/Nu:

Thanks for finding the bug, and the great idea for fixing it.


3 points by dram 2839 days ago | link

Your fix is cleaner. :)

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

So that it will not fail when atstrings is set.


1 point by Pauan 2838 days ago | link

Ah yes, excellent catch:


1 point by akkartik 2840 days ago | link

Ingenious! Do you have a github account? You should be the one to fix this in anarki :)


2 points by dram 2840 days ago | link


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

I found this one:

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

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


2 points by akkartik 2839 days ago | link

That's a good idea. Did the tests pass without your changes?

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 ( All those seem ok..


Looks like dfn is a rainbow innovation:


Update 1 hour later: almost all rainbow tests pass! I had to disable the dfn tests, and the ssyntax tests at the bottom of core-evaluation-test were hanging. Other than that it's all good.


2 points by dram 2839 days ago | link


I'll make a pull request later.


2 points by akkartik 2839 days ago | link

Thanks for the commit! I've merged and given you commit rights to anarki.

I've also added/plagiarized rainbow's tests to the repo: 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..


Update 43 minutes later: it turns out rainbow's ssyntax precedence rules were different. Perhaps anarki changed at some point. Those tests are now fixed.


1 point by dram 2839 days ago | link

Thanks, well done.