Arc Forumnew | comments | leaders | submitlogin
6 points by drcode 6035 days ago | link | parent

I would frame the question differently.

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

Once a string is parsed into an sexp, the sexp would contain only symbols and numbers. The symbols would be standard lower-case and contain no weird characters. All strings would need to be translated into such an sexp using the 'fmt description. There would be no string or character data types. (Clearly there would seem to be lots of apparent limitations if you completely excised strings from a language like this, but I wonder if they could be addressed if the right approach is taken)



0 points by bitcirkel 6011 days ago | link

I strongly agree. After all, there are no particular accommodations for sounds, images, and what have you. Why would there be one for verbal data?

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.

And strings bring their own set of problems (not very useful for a 100-year language) like translation, ascii vs latest unicode version, coupling (the web is finally beginning to get this right by separating behaviour from content and presentation).

-----

1 point by absz 6011 days ago | link

In fact, many languages (or at least their large libraries) do have accommodations for sounds, images, etc. This is because most languages have some sort of "class" mechanism, and create classes for those things (in their standard library or in a very common one). And sometimes, what you are working on is a string parsing/manipulating/generating program, where strings do belong.

-----