3 ms·

>, but I think all that will lead to is a lot of gratuitous casting of strings But if programmers are not directly doing memcpy() of bytes directly to the stac

by jasode 11y ago

>, but I think all that will lead to is a lot of gratuitous casting of strings But if programmers are not directly doing memcpy() of bytes directly to the stack frame, they are already doing a roundabout version of "casting". If a programmer has to "yank" from a string to put it into a more organized data type, the "yank" has to be done within the framework of semantics. If one "yanks" or "slices", or "substr", etc characters 3 to 15, the exact behavior depends on whether contiguous bytes is ASCII, UTF8, UTF16, or binary blob (which means NUL(0) is valid byte in the middle of the block of bytes). That "meaning overlayed onto those bytes to manipulate it correctly" has to decided somewhere. It is either implicit or explicit. Likewise, if one pulls 4 bytes from disk or network, the programmer has to assign meaning to it and say it is the 4-bytes of an IEEE floating point (float) or 4-bytes of a integer (int). The programmer may later want to do a bitshift (<<) which is not applicable to a float.

mannykannot 11y ago
I think the first part of your argument works equally well for strings generally as for typed strings, and so I don't think it shows the latter are better than the former. >That "meaning overlayed onto those bytes to manipulate it correctly" has to decided somewhere. Sure, but I don't think it has to be done twice. A string type serves the purpose of abstracting the stringiness of a byte sequence, and an URL type serves the purpose of abstracting the URL-iness of strings, and to my mind, adding something to abstract the URL-iness of a byte sequence is a gratuitous redundancy that conflicts with the principle of separating concerns.
- jasode 11y ago
  >I think the first part of your argument works equally well for strings generally as for typed strings, But NameAscii.CharacterIndex(3) is a different meaning than NameUtf16.CharacterIndex(3). The byte index could be 3 or 6+n depending on semantics. >Sure, but I don't think it has to be done twice. [...]abstracting the URL-iness of strings, There's no redundancy. If I have a config file that has user-specified URLs in it. It is more likely that the programmer will know if that file on disk is ASCII or Utf16. The programmer can know that before the compiler or runtime can know it and assign a formal type to the incoming string. This is independent knowledge from a URL data type. A URL data type isn't going to have member functions to pull data directly off of the disk. That's a separate concern as you say. >, adding something to abstract the URL-iness of a byte sequence is a gratuitous redundancy that conflicts with the principle of separating concerns. We are envisioning different things. I thought of it as: - bytes -> typed string -> URL I think you're thinking of: - -- typed string - bytes / - \-- URL ... and yes that would be redundant for a URL data type to understand all kinds of raw bytes.
  - deleted 11y ago
    [deleted]
  - mannykannot 11y ago
    What I am actually thinking of is this: bytes -> string -> URL -> SQL ... Once you type strings, you get multiplicities. Completing your diagram, we get bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... or bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... There's the redundancy. What are the typed strings doing for us? Edit: I don't think these diagrams are formally correct - I don't think of URL as a subtype of string, even though it has a string representation and URL objects can be constructed from strings - but I think they make my point clear.
    - jasode 11y ago
      (LATE EDIT: I now see that your responses were influenced by cballard's original examples of NSURL and NSString but I wasn't talking about those.) I was thinking of ASCII/Unicode string types and not the URLString vs SQLString types. Yes, a URLString would be redundant. In C#, the URI data type contains a Utf16 string as a data member but it is not another type of string. We were talking about different things. The ASCII/Unicode string data types would be somewhat analogous to int32/int64/float32/float64/Money data types. The way C# does it is that everything is Utf16 and there is no separate ASCIIString data type for pure ASCII strings. They also don't have pure Utf8 strings. Instead, the UTF16 classes has member "get()/encode()" functions that interpret as ASCII or UTF8. The ASCII/Utf8 data state is transitory. This architectural choice is fine for most apps but if you have 1 gigabyte of ASCII data, it's very memory inefficient to double the memory footprint to 2 GB for Utf16 just to slice & dice strings. If you use byte[] arrays to keep everything as raw ASCII to conserve memory, you don't get any convenient string-like slice & dice functions. The "string type" is lost in a opaque byte[] array.
      - mannykannot 11y ago
        > We were talking about different things. You started by disagreeing with kazinator's objection to typed strings, and for several posts after that you explicitly defended the concept of typed strings. Now you are trying to rewrite the discussion as if it were about the internal representation of strings, which it has never been.
kazinator 11y ago
> That "meaning overlayed onto those bytes to manipulate it correctly" has to decided somewhere. The correct place is at the earliest possible point: the input into the system. Parse the textual cruft into a data structure as early in the data processing pipeline as possible. (And treat any deviation from this cautiously, for the sake of optimization.)
- jasode 11y ago
  >Parse the textual cruft into a data structure as early in the data processing pipeline as possible. Totally agree. But whether we "parse" or "yank", that processing requires semantics. Data types can help with correct semantics to interpret the textual cruft the way the programmer intended. The other issue of strings acting as adhoc compound data formats is orthogonal.

by jasode 11y ago

mannykannot 11y ago

I think the first part of your argument works equally well for strings generally as for typed strings, and so I don't think it shows the latter are better than the former. >That "meaning overlayed onto those bytes to manipulate it correctly" has to decided somewhere. Sure, but I don't think it has to be done twice. A string type serves the purpose of abstracting the stringiness of a byte sequence, and an URL type serves the purpose of abstracting the URL-iness of strings, and to my mind, adding something to abstract the URL-iness of a byte sequence is a gratuitous redundancy that conflicts with the principle of separating concerns.

jasode 11y ago
>I think the first part of your argument works equally well for strings generally as for typed strings, But NameAscii.CharacterIndex(3) is a different meaning than NameUtf16.CharacterIndex(3). The byte index could be 3 or 6+n depending on semantics. >Sure, but I don't think it has to be done twice. [...]abstracting the URL-iness of strings, There's no redundancy. If I have a config file that has user-specified URLs in it. It is more likely that the programmer will know if that file on disk is ASCII or Utf16. The programmer can know that before the compiler or runtime can know it and assign a formal type to the incoming string. This is independent knowledge from a URL data type. A URL data type isn't going to have member functions to pull data directly off of the disk. That's a separate concern as you say. >, adding something to abstract the URL-iness of a byte sequence is a gratuitous redundancy that conflicts with the principle of separating concerns. We are envisioning different things. I thought of it as: - bytes -> typed string -> URL I think you're thinking of: - -- typed string - bytes / - \-- URL ... and yes that would be redundant for a URL data type to understand all kinds of raw bytes.
- deleted 11y ago
  [deleted]
- mannykannot 11y ago
  What I am actually thinking of is this: bytes -> string -> URL -> SQL ... Once you type strings, you get multiplicities. Completing your diagram, we get bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... or bytes -> string -> URL-string -> URL -> SQL-string -> SQL ... There's the redundancy. What are the typed strings doing for us? Edit: I don't think these diagrams are formally correct - I don't think of URL as a subtype of string, even though it has a string representation and URL objects can be constructed from strings - but I think they make my point clear.
  - jasode 11y ago
    (LATE EDIT: I now see that your responses were influenced by cballard's original examples of NSURL and NSString but I wasn't talking about those.) I was thinking of ASCII/Unicode string types and not the URLString vs SQLString types. Yes, a URLString would be redundant. In C#, the URI data type contains a Utf16 string as a data member but it is not another type of string. We were talking about different things. The ASCII/Unicode string data types would be somewhat analogous to int32/int64/float32/float64/Money data types. The way C# does it is that everything is Utf16 and there is no separate ASCIIString data type for pure ASCII strings. They also don't have pure Utf8 strings. Instead, the UTF16 classes has member "get()/encode()" functions that interpret as ASCII or UTF8. The ASCII/Utf8 data state is transitory. This architectural choice is fine for most apps but if you have 1 gigabyte of ASCII data, it's very memory inefficient to double the memory footprint to 2 GB for Utf16 just to slice & dice strings. If you use byte[] arrays to keep everything as raw ASCII to conserve memory, you don't get any convenient string-like slice & dice functions. The "string type" is lost in a opaque byte[] array.
    - mannykannot 11y ago
      > We were talking about different things. You started by disagreeing with kazinator's objection to typed strings, and for several posts after that you explicitly defended the concept of typed strings. Now you are trying to rewrite the discussion as if it were about the internal representation of strings, which it has never been.

kazinator 11y ago

> That "meaning overlayed onto those bytes to manipulate it correctly" has to decided somewhere. The correct place is at the earliest possible point: the input into the system. Parse the textual cruft into a data structure as early in the data processing pipeline as possible. (And treat any deviation from this cautiously, for the sake of optimization.)

jasode 11y ago
>Parse the textual cruft into a data structure as early in the data processing pipeline as possible. Totally agree. But whether we "parse" or "yank", that processing requires semantics. Data types can help with correct semantics to interpret the textual cruft the way the programmer intended. The other issue of strings acting as adhoc compound data formats is orthogonal.