[erlang-questions] Erlang Syntax and "Patterns" (Again)
Richard A. O'Keefe
Mon Mar 21 00:50:43 CET 2016
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.
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
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
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
(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*.
More information about the erlang-questions