Arc Forumnew | comments | leaders | submitlogin
Failed to modify strings in latest mzscheme
5 points by dram 3959 days ago | 14 comments
When go through tutorial, I encountered following error:

  arc> (= s "foo")
  "foo"
  arc> (= (s 0) #\m)
  Error: "string-set!: contract violation\n  expected: (and/c string? (not/c immutable?))\n  given: \"foo\"\n  argument position: 1st\n  other arguments...:\n   0\n   #\\m"
This problem exists both in vanilla arc3.1 and anarki. Version of mzscheme is:

  $ mzscheme -v                                                                  
  Welcome to Racket v5.3.4.
Any ideas?


2 points by zck 3959 days ago | link

This is also a bug in Racket 5.2.1, although with a different error message:

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

-----

2 points by akkartik 3959 days ago | link

Racket has ways to create mutable strings: http://docs.racket-lang.org/reference/strings.html#%28def._%...

But it's not immediately clear to me how to use them in arc.

-----

3 points by dram 3959 days ago | link

Find this thread in plt-scheme mailing list that pg posted several years ago.

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

It seems that this problem had once been solved, but occurred again.

-----

5 points by akkartik 3959 days ago | link

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

-----

4 points by dram 3959 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.

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

-----

3 points by Pauan 3958 days ago | link

Fixed in Arc/Nu:

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

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

-----

3 points by dram 3958 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 3957 days ago | link

Ah yes, excellent catch:

https://github.com/Pauan/ar/commit/95f13f757a52a5d07f5467603...

-----

1 point by akkartik 3959 days ago | link

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

-----

2 points by dram 3959 days ago | link

OK.

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"

-----

2 points by akkartik 3958 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 (http://github.com/akkartik/arc). All those seem ok..

---

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

---

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 3958 days ago | link

Great!

I'll make a pull request later.

-----

2 points by akkartik 3958 days ago | link

Thanks for the commit! I've merged https://github.com/arclanguage/anarki/commit/1bc954f598 and given you commit rights to anarki.

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

---

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 3958 days ago | link

Thanks, well done.

-----