[erlang-questions] Erlang Syntax and "Patterns" (Again)

[Richard A. O'Keefe]

On 19/03/16 5:30 am, Emil Holmstrom wrote:
> The confusion between strings and [integer()] would have been greatly 
> reduced if char() existed, $a wouldn't have to be syntactic sugar for 
> 97 but would actually be "character a". You would have to explicitly 
> convert char() -> integer() and wise versa. This is how strings are 
> implemented in ML and Haskell.
Actually no.
<quote>
    The STRING signature specifies the basic operations on a string type,
    which is a vector of the underlying character type char
    as defined in the structure.

    signature STRING = ...
    structure String :> STRING
        where type string = string
        where type string = CharVector.vector
        where type char  = Char.char
    structure WideString :> STRING
        where type string = WideCharacterVector.vector
        where type char  = WideChar.char
</quote>

 From the SML Basis Library book, page 360.

There are indeed Char.char and WideChar.char types which are just wrappers
for integer types such that chr and ord are implementation-level identities.
But characters as such are so far from being basic to strings in ML that the
very syntax, #"c", tells you that they were an afterthought.

For what it's worth, when I'm working on strings in SML, I suppose I 
*should*
make use of the StringCvt.reader type but it's usually easier to use
explode to convert (*change* the representation of) strings to lists and
implode to convert back.

As for Haskell, String does indeed exist, but the preferred representation
for strings in "efficient" programs is
http://hackage.haskell.org/package/text-1.2.2.1/docs/Data-Text.html

(It's interesting to note that a Text value in Haskell is NOT an arbitrary
sequence of suitably bounded integral values; a sequence of bounded
integral values yes, arbitrary no.)

I completely agree that encodings should be handled at the edges of a
system, *for data that the system will accept/generate*.