Thanks for the analysis!

You're absolutely right in that I've glossed over quite a few details, and clearly I've screwed up in some ways that were immediately obvious to you :P

I guess the first thing I'd have to introduce for the whole issue of basic operations destroying the entire system is to introduce something like:

    def _foo:+(_foo:n, _foo:m):
        ...

Then we have:

  hello = "hi, "
  world = "planet"

  hello_world = hello + world     # error, since join(hello, world) = top

  # and yet...

  hello_world = "hi, " + "planet" # not an error: join(bottom, bottom) = bottom

I don't know how it'd scale but I imagine that many users of such a theoretical system would find it really annoying to write in the beginning without good tooling (kind of like Java with all those getters and setters :P). I do believe though that this is also the case in Objective-C and that in ObjC this tradeoff is appreciated later when maintaining big code bases. Maybe my rather draconian idea is unfeasible because of this reason alone!

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"

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

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