5 ms·

>, yank the data out of the string representation Well, the very act of "yanking" can be helped by more well-defined behavior policies of "typed strings". It

by jasode 11y ago

>, yank the data out of the string representation Well, the very act of "yanking" can be helped by more well-defined behavior policies of "typed strings". It is unavoidable that the programmer will have to confront a contiguous piece of memory (string) with no boundaries between characters whether it's a block of bytes on disk, network stream, or the clipboard buffer. It can be helpful to differentiate the various types of strings with a formal type system before the yanking takes place. The Alan Perlis epigram is wise but I don't think it applies here. I think's he's talking about abusing strings as an adhoc data format by stuffing them with multi-value data and then turning right around and parsing them. For example, concatenating name+":"+id+":"+amount into a string with colons like "John:389432:$5.99", passing the "complex" string around, and then later parsing out the colons with string.split(). Basically, the programmer is making an in-memory csv (comma separated values) data format instead of using "C struct {}" or passing 3 separate formal parameters.

mannykannot 11y ago
> ...before the yanking takes place. I take it that you are advocating for typed strings in addition to fully-formed types for things like URLs and SQL, but I think all that will lead to is a lot of gratuitous casting of strings just so they can be passed to the fully-formed types. Furthermore, few of these casts could be statically checked for validity.
- 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.

by jasode 11y ago

mannykannot 11y ago

> ...before the yanking takes place. I take it that you are advocating for typed strings in addition to fully-formed types for things like URLs and SQL, but I think all that will lead to is a lot of gratuitous casting of strings just so they can be passed to the fully-formed types. Furthermore, few of these casts could be statically checked for validity.

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.