4 ms·

If you customize your runtime behavior based on any metadata about the value on which you operate, you have multiple types. Attempting to change the syntax will

by duaneb 12y ago

If you customize your runtime behavior based on any metadata about the value on which you operate, you have multiple types. Attempting to change the syntax will not change the fact that you need to differentiate behavior for numbers and strings.

klibertp 12y ago
> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics are like that.
- jerf 12y ago
  "Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string looks like this: number: 0x000000000000002a string: 0x7ffb000000007264 result: 0x7ffb00000000728e The string is, of course, a pointer, and the result, of course, is gibberish. This is why "no" languages to speak of implement this form of "untyped language"; it isn't what anybody actually wants. (Assembler, of course, has it, but that's an exception for obvious reasons.) A term that describes essentially 100% of languages is not a useful one, so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime".
  - TazeTSchnitzel 12y ago
    B and early C are untyped like this
    - exprL 12y ago
      Early C? The parent described accurately how pointer addition in C works for all char pointers. (Well, other than the “nobody wants that” part, because that's how you skip n bytes of a string.)
      - TazeTSchnitzel 12y ago
        C has pointer arithmetic
  - iopq 12y ago
    you can easily add a number to a char in C and get a jibberish character, which is why C is a weakly typed language
    - exprL 12y ago
      Not true (technically). When you add an integer to a char, you get an integer. (If you add a floating point number, the result is such as well.) You can, of course, use the integer you got like a char (after all, C's char is a small integer type) to get your gibberish. You can also use a floating point number as a char, because C has lax implicit conversions.
      - iopq 12y ago
        If you add '!' to '#' you get 'D', which is non-sense in any high level language.
        jerf 12y ago
        Not true; you added the byte that happens to be identified in ASCII by !, 33, to the byte that happens to be identified in ASCII by #, 35, and get 68, which is D. This is all perfectly sensible and type safe, two 8-bit numbers being added to produce another 8-bit number; you are only confused by the surface syntax. There's plenty of high-level languages that will let you do this; there's all sorts of reasons to make numbers and the ASCII chars they represent easily usable for each other in source code.
        iopq 12y ago
        No, I didn't. I actually added the character '!' to '#'. The C language doesn't DISTINGUISH characters from their numerical representations. That's where I say it's weakly typed. It does not have an actual character type, it only has 8 bit numbers. Of course in C it is perfectly logical. I am pointing out that it is not as strongly typed as other type systems that have richer types.
  - klibertp 12y ago
    > The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number We're not discussing a concept of "type safety" here at all, but rather a concept of "untypedness". I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped". They are not: untyped language is one which has no type errors both on compile time and runtime (unless I'm very . An obvious example is Assembler, but Forth or TCL qualify too. And quite a few others do too. See here: http://en.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages http://en.wikipedia.org/wiki/Programming_language#Typed_vers... > so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime" Again, it was never suggested that Tulip has "static types". It doesn't of course. What I said is that it has types. I don't want to discuss how much better "static typing" is than "dynamic typing" or vice versa, this makes for a very boring discussion similar to Emacs vs. Vim and I'm not interested in it at all. I just object to the notion that "static types" are the only kind of types we can ever have in a language. The problem is with "static typing fanatics", really. They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types. This is both dishonest and unnecessary. No serious static typing advocate would do this (I hope) - static typing is a great idea able to defend on its own, there's no need to lie about "the other side" of the argument. Well, all fanatics are like that. Way too much Kool-Aid, way too little critical thinking.
    - jerf 12y ago
      "I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped"." You completely missed my point, as evidenced by the fact you appear to believe I just claimed that when I in fact claimed the exact opposite, which is that since darned near nothing is "untyped", that's not a useful concept to use in discussing whether something is "typed" or not. Assembler is truly untyped. Forth is untyped. Tcl is not untyped... it simply has a built-in coercian rule that it'll turn everything into strings if it doesn't like what you do to it. It's as close as you can get, but it isn't untyped. A concept that describes only two languages is not all tha useful. "They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types." Again, the fact that you appear to have completely missed my point is evidenced by the fact that I drew a distinction whereby languages may be "dynamically" or "statically" typed but darned near nothing is "untyped". With all due respect, you're not in a position to be claiming that other people are "fanatics"... you don't have the information to come to that conclusion because you appear to be incapable of reading what people say, because you've already decided in advance what they're going to say. Yes, that makes the world look like... well... anything you want, really, but it's not a true description. You are not in a position to be complaining about other people's "critical thinking" skills when you yourself aren't even accurately gathering information with which to critically think.

by duaneb 12y ago

klibertp 12y ago

> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics are like that.

jerf 12y ago
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string looks like this: number: 0x000000000000002a string: 0x7ffb000000007264 result: 0x7ffb00000000728e The string is, of course, a pointer, and the result, of course, is gibberish. This is why "no" languages to speak of implement this form of "untyped language"; it isn't what anybody actually wants. (Assembler, of course, has it, but that's an exception for obvious reasons.) A term that describes essentially 100% of languages is not a useful one, so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime".
- TazeTSchnitzel 12y ago
  B and early C are untyped like this
  - exprL 12y ago
    Early C? The parent described accurately how pointer addition in C works for all char pointers. (Well, other than the “nobody wants that” part, because that's how you skip n bytes of a string.)
    - TazeTSchnitzel 12y ago
      C has pointer arithmetic
- iopq 12y ago
  you can easily add a number to a char in C and get a jibberish character, which is why C is a weakly typed language
  - exprL 12y ago
    Not true (technically). When you add an integer to a char, you get an integer. (If you add a floating point number, the result is such as well.) You can, of course, use the integer you got like a char (after all, C's char is a small integer type) to get your gibberish. You can also use a floating point number as a char, because C has lax implicit conversions.
    - iopq 12y ago
      If you add '!' to '#' you get 'D', which is non-sense in any high level language.
      - jerf 12y ago
        Not true; you added the byte that happens to be identified in ASCII by !, 33, to the byte that happens to be identified in ASCII by #, 35, and get 68, which is D. This is all perfectly sensible and type safe, two 8-bit numbers being added to produce another 8-bit number; you are only confused by the surface syntax. There's plenty of high-level languages that will let you do this; there's all sorts of reasons to make numbers and the ASCII chars they represent easily usable for each other in source code.
        iopq 12y ago
        No, I didn't. I actually added the character '!' to '#'. The C language doesn't DISTINGUISH characters from their numerical representations. That's where I say it's weakly typed. It does not have an actual character type, it only has 8 bit numbers. Of course in C it is perfectly logical. I am pointing out that it is not as strongly typed as other type systems that have richer types.
- klibertp 12y ago
  > The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number We're not discussing a concept of "type safety" here at all, but rather a concept of "untypedness". I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped". They are not: untyped language is one which has no type errors both on compile time and runtime (unless I'm very . An obvious example is Assembler, but Forth or TCL qualify too. And quite a few others do too. See here: http://en.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages http://en.wikipedia.org/wiki/Programming_language#Typed_vers... > so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime" Again, it was never suggested that Tulip has "static types". It doesn't of course. What I said is that it has types. I don't want to discuss how much better "static typing" is than "dynamic typing" or vice versa, this makes for a very boring discussion similar to Emacs vs. Vim and I'm not interested in it at all. I just object to the notion that "static types" are the only kind of types we can ever have in a language. The problem is with "static typing fanatics", really. They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types. This is both dishonest and unnecessary. No serious static typing advocate would do this (I hope) - static typing is a great idea able to defend on its own, there's no need to lie about "the other side" of the argument. Well, all fanatics are like that. Way too much Kool-Aid, way too little critical thinking.
  - jerf 12y ago
    "I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped"." You completely missed my point, as evidenced by the fact you appear to believe I just claimed that when I in fact claimed the exact opposite, which is that since darned near nothing is "untyped", that's not a useful concept to use in discussing whether something is "typed" or not. Assembler is truly untyped. Forth is untyped. Tcl is not untyped... it simply has a built-in coercian rule that it'll turn everything into strings if it doesn't like what you do to it. It's as close as you can get, but it isn't untyped. A concept that describes only two languages is not all tha useful. "They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types." Again, the fact that you appear to have completely missed my point is evidenced by the fact that I drew a distinction whereby languages may be "dynamically" or "statically" typed but darned near nothing is "untyped". With all due respect, you're not in a position to be claiming that other people are "fanatics"... you don't have the information to come to that conclusion because you appear to be incapable of reading what people say, because you've already decided in advance what they're going to say. Yes, that makes the world look like... well... anything you want, really, but it's not a true description. You are not in a position to be complaining about other people's "critical thinking" skills when you yourself aren't even accurately gathering information with which to critically think.