Thirty Four Thirty Four

This is the illustration of the different ways dynamic languages could potentially interpret this statement: 

  writeln("34" + 34);
The purpose is to demonstrate all the potential different ways it could in theory be done, yet be an otherwise "normal" looking language.

Language #1

The language (interpreter) looks at the type tag of the right to determine the "assumed type" of the entire expression. In this case the tag is "Number" (or similar) because the expression has no quotes. It thus sees if the left side can be interpreted as a number (via parsing, not tag analysis), converts it to 34 internally and does arithmetic addition to get 68.

Language #2

The language looks at the type tag of the left to determine the "assumed type" of the entire expression. In this case the tag on the left expression is "string" because the expression has quotes. It thus assumes string concatenation, converts the right-side number to the string "34", and the result is "3434".

Language #3

A language looks at the type tag of the first operand, and sees "String" (since it is enclosed in quotes). It then looks at the 2nd operand's type tag, and sees "Number" (because it has no quotes). In this particular language, the tags must be of same type (same tag), or an error is thrown. Since "String" is not "Number", an error is thrown.

Language #4

A language looks at the type tag of both operands. The first is "String" and the second is "Number" (per above). This particular language has a rule-table like this: 

  Oper A | Oper B | Assumed Type
  ---------------------------
  String | String | String
  String | Number | String
  Number | String | String
  Number | Number | Number
Since it matches the 2nd rule row, String is assumed, and thus concatenation is assumed and the result is "3434".

Language #5

A language parses both operands. If both can be interpreted as a number (irregardless of tags or quotes), then addition is assumed. If either side fails to parse as a legitimate number, then string concatenation is assumed. In this case both sides "pass" and the result is 68.

Language #6

A language sees if the first (left) operand is parsable as a number (irregardless of tags or quotes). If it passes "numberness", then addition is assumed, else concatenation. However, if the second operator cannot be converted to a number (including via parsing), then an error is raised. In this case it's already a number such that the result is 68. (Note that "34" + "34" would also return 68 because parsing would be done if the second operand was not a "native" number.)

Language #7

The language performs the operation on the operands interpreting "+" as addition being that it has operators for concatenation. In the example case, the result would be 68. Languages in this category take the view that if anything is passed to a process it is appropriate to the requirements of that process - i.e. there is no error. If there is in fact erroneous data then the process should fail gracefully. Concatenation is a different operation and would be something like

writeln(concat("34", 34));

which would produce "3434"

TopMind believes that any variable or constant with a tag (primary type) of "string" is parsed to see if it's a number. If it cannot be converted into a number, then an error is raised. In the example case, the result would be 68. If the first operand was "3A" instead of "34", then parsing to a number would fail and an error would be raised. And well that may be true for some language unknown to me, but I reckon the process just fails when it tries to add a string to a number.

Note: Since some do not like my usage of "tag", for this example when I say "tag", you can interpret it to mean the "type" that the quotes indicate. Thus, if a value (constant) has quotes, its tag is "string", but "number" if it does not have quotes. In the tag model, most dynamic languages will set the "tag" based on existence or absence of quotes. (Other syntactical elements may also play a part, depending on the language, but we'll put these aside for this example and just consider "number" and "string".)

Language #8

This language doesn't do any type conversion (such as parsing to "interpret as") for this operator (unlike #7), and "+" means addition and it has a different operator for concatenation (no overloading). The code as given would trigger an error because the tag of the first operand is not a numeric type, per tag.

{Tags? Both languages 7 and 8 describe a type-handling style which, to me, describes dynamic languages in the context of conventionally typed languages. In dynamic languages, ("true" dynamic languages?), the type of each variable or literal is implicit, not in the definition of the variable, but in the context in which the variable is used. If a function is used, it expects the caller to have passed it valid data. If the data is not valid, the function used would either trigger an exception, or happily use the erroneous data. There are times when this can cause difficult to find errors - for example, say a process had an error which allowed non-numeric data to be passed, say, say to an addition process. I would expect an exception to be raised. However if this data were, coincidentally, a representation of a floating point number, like a product code of "123E05", the addition process would not fail and you could have a subtle (difficult to see) problem within your system.}

I am reminded of this talk, which makes fun of types in JavaScript and Ruby:

http://www.destroyallsoftware.com/talks/wat

Epic.

(I cannot play the vid. Tried 2 browser brands.)

Odd, that. It works on everything I've got, including some mobile devices. Firewall issue, maybe?

The above is speculation. 

   int plus(string p1, int p2) {
      int v1 = tryToConvertToIntegerAndThrowExceptionIfFailed(p1)
      int v2 = p2
      return v1 + v2;
   }

           BEFORE:
           <var name="a" tag="number" value="123"/>
           ..............^^^^^^^^^^^^..............
           AFTER:
           <var name="a" float, boolean, integer, string etc. value="123"/>
           ..............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^..............

I removed some of the text from #7 above. It didn't make sense to me; anthropomorphizing interpreters in a confusing way. Here's the original snippet:

"The language performs the operation on the operands interpreting "+" as addition being that it has operators for concatenation. In the example case, the result would be 68. Languages in this category take the view that if anything is passed to a process it is appropriate to the requirements of that process - i.e. there is no error. If there is in fact erroneous data then the process should fail gracefully. Concatenation is a different operation and would be something like..."

[under construction] 

 Processing type determined by: T:(__) getType(), I:(__) is_numeric(), O: (__) other operand


 Error handling: 
   E:(__) Error raised if not expected type or conversion to number fails, 
   N:(__) A special character or "mode", such as Not-a-Number is generated if 
          not the expected type or a conversion fails.
   S:(__) String is assumed if conversion to number fails


 Ex#|Opn|Det|Err
 ---|---|---|--------
 01 | A | ? | ?
 01 | B | ? | ?
 ---|---|---|--------
 02 | A | ? | ?
 02 | B | ? | ?
 ---|---|---|--------
 03 | A | ? | ?
 03 | B | ? | ?
 ---|---|---|--------
 04 | A | ? | ?
 04 | B | ? | ?
 ---|---|---|--------
 05 | A | ? | ?
 05 | B | ? | ?
 ---|---|---|--------
 06 | A | ? | ?
 06 | B | ? | ?
 ---|---|---|--------
 07 | A | ? | ?
 07 | B | ? | ?
 ---|---|---|--------
 08 | A | ? | ?
 08 | B | ? | ?
This is to eventually somewhat resemble the grids as found in TypeHandlingGrid.

See TypeSystemCategoriesInImperativeLanguages, TypeTagDifferenceDiscussion

SeptemberThirteen

EditText of this page (last edited November 5, 2014) or FindPage with title or text search