Some of my complaints: I never know if something expects a string or a symbol, e.g. keys into the req structure. Symbols sometimes require quotes and sometimes not, interacting confusingly with macros. (To make a hash with key foo and value bar: (obj foo 'bar) - bar needs a quote and foo needs no quote.) Symbols have their own strange syntax, e.g. to define a home page, you use the mysterious (defop || ...) because || is the empty symbol. Using symbols as strings makes the code more confusing; is passwd being used as a variable or as a string-like token? I think it's nice that strings have a consistent syntax: if it's got quotes around it, you know it's a string.

The big advantage of symbols over strings in Lisp is they are interned, so you can compare two symbols for equality in constant time, unlike strings which take O(n) time. But it seems that you could use interned immutable strings.

I agree with you that Arc's marginally mutable strings aren't very useful; being able to only modify individual characters gives you the worst of both worlds.

While I'm complaining about strings, it would be very nice to have something like Python's triple-quote """ that can be used to define a string that contains single and double quotes. To generate my documentation, I'm constantly creating strings that contain double quotes, and it's a big pain to go through and make sure all the backslashes are correct.

"Strings" are used for communication with a human- Human readable text is an important tool that software uses for interacting with a user.

Inside the actual logic of a program it really has no useful role. It is unfortunate that a byte hold a text character reasonably efficiently, so almost all software uses strings as primary data structures, even though they don't belong in the body of a program.

In my view, strings should only be used in two places in any application: 1. Acquiring raw data from the user to parse into more meaningful internal data structures. 2. In the final step when rendering text for the human to read, generated from internal data structures.

I think it would be interesting (though perhaps not practical) if arc had only two commands with string support (string-to-sexp fmt str) and (sexp-to-string fmt sexp)... In this case, the 'fmt parameter would be some kind of definition of the string syntax, something like a BNF or RegEx description. The only other things you'd be able to do is somehow acquire it from the user and somehow display it to the user. Any internal manipulation of strings would be impossible and unnecessary.

Strings have no place in the core logic of a program. It is only because of inertia that we have this remnant from the early terminal days.

First, I have always taken symbols to be things that are conceptually different than strings, but just happened to be represented as strings. After all, symbols really appear because they are part of the interpreter/compiler data structures - they are a way of referencing an identifier, which you might use as, for instance, a variable name. Yes, they can be displayed, and they print as the string associated with their identifier, but I've always considered that a rather uninteresting side effect. Showing a symbol to a user would seem to break layers of abstraction.

Strings, on the other hand, always seemed like the right way to store user-readable text. They have these nice escape sequences, and you can isolate them and change them without affecting your entire program. They can also include spaces and nice stuff like that.

However, it is completely possible that my gut reaction is wrong. Having interned strings can be very useful. I would suggest, however, that we do it with a real interned string facility, and then make symbols a special case of that. This facility should include strings that would not make valid identifiers, including things with spaces and special characters in them.

To your second point, though, you're right - strings are pointless. After all, they're just a special case of a list (or an array, depending on how you like to think). If you have the general case, then having the specific too is pointless and feels bloated. You could argue that characters, too, are just a special case of numbers, since that's what they really are underneath. In fact, you could say that the current string type is just a vector of numbers, with cool special syntax.

To which I would say, yes, let's go for the more general stuff. Practically speaking, we should add that in before we take out the specific string case, which after all is used a lot. But in general, yeah, let's make it possible to do this with anything.

If you do allow this abstraction, you also get the interesting benefit that internationalization and unicode come for free. As PG says, they're just stupid bloat in the core of the language. In order not to have them there then, there should be some way for people to implement them, without sacrificing anything that a built-in implementation would have.

This means that there needs to be a way to make a new type which is a vector of uniform type (oddly enough, this might be easier in arc2c than in arcn or anarki). It also means that there should be a way to define nice readable syntax for things like strings in double quotes, and isolated single characters.

And it still doesn't address the issue of how you communicate with the development system, which after all does have one preferred string representation - the one that you're writing in.

Well, Arc lists are (e e . nil). Why do we have a different terminator for strings?

This is where things get hairy. In Scheme lists are (e e . ()), so I would say that having strings be (#\a #\b . "") would make sense there, but Arc specifically tries to pretend that () is nil. Why should "" be different from nil, when () is nil?

As for [isa _ 'string], I propose instead the following function:

  (def astring (e)
    ((afn (e e2)
       (if
         (no e)
           t
         ; check for circularity
         (is e e2)
           nil
         (and (acons e) (isa (car e) 'character))
           (self (cdr e) (cddr e2))
         ; else
           nil))
      e (cdr e)))

Hmm. I suppose someone will complain that you might want to differentiate between the empty string and nil. To which I respond: How is nil different from the empty list? Arc attempts to unify them; why do we want to not unify the empty string with nil? If someone says http://example.com/foobar?x= , how different is that from http://example.com/foobar ? x is still empty/nil in both cases.

That said, I did recently write an app which used symbols as de facto strings, and the text file format being used as a configuration/task description file by the user was just an s-expr format. The app wasn't written in Lisp or anything like it, which was why I settled for using symbols as strings (to make it easier on my readerfunction - I just didn't have a separate readable string type).

Given that experience, well, I really must insist that having separate strings and symbol types are better. In fact in the app I wrote it for, the config/taskdesc file was just a glorified association list (where the value is the 'cdr of the list, not the 'cadr)!

About lists of chars. Rather than analyzing lists every time to see if they are strings, what about tagging them? I've mentioned before that I think Arc needs better support for user defined types built from cons cells. Strings would be one such specialized, typed use of lists.

I don't know if interning strings would really kill performance. Lua does it if I remember well, and it is quite performant. Anyway, mutable strings are a real performance killer, since you must compare them with scheme's 'equal? instead of 'eq?.

Now, you are right too, they don't represent exactly the same thing, so simply removing one of them would quite feel bad, but sometimes you have to make both worlds communicate. That's a matter of syntax too. After all, "Hello, Arc world" could be a special syntax meaning : the quotation of the symbol |Hello,\ Arc\ world|. A triple-quote syntax could be added, too.

It can be said the other way around : every time you need a string and are provided with a symbol (or the opposite), an automatic coercion could be performed.