7 ms·

It's unityped! It has one type with infinitely many variants/tags (.<string>). Match failure occurs at runtime as in any other safe typed language such as Haske

It's unityped! It has one type with infinitely many variants/tags (.<string>). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.

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.
wyager 12y ago
>Match failure occurs at runtime as in any other safe typed language such as Haskell or ML. That is incredibly disingenuous. The only way a Haskell or ML program could be as colossally unsafe as a unityped language program is if the programmer used only one giant sum type for the entire program, and most functions in the program were non-total with respect to that type. "Unityping" provides no static type safety. It is isomorphic to, and usually a euphemism for, the lack of any static type system.
- jneen 12y ago
  Yeah, it was a difficult decision to remove types - I'd gotten myself into a corner trying to tack on dependent types, and it just wasn't happening. My bet is that unlike most of the un{i,}typed languages out there (most of which I'd categorize as lisps and smalltalks), tulip provides tagging and destructuring that allows the programmer to maintain some level of control over the polymorphism. Tulip will panic at runtime for non-total functions, but ideally you'll have the tools necessary to keep the panic as close to the problem as possible.

It's unityped! It has one type with infinitely many variants/tags (.<string>). Match failure occurs at runtime as in any other safe typed language such as Haskell or ML.

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.

wyager 12y ago

>Match failure occurs at runtime as in any other safe typed language such as Haskell or ML. That is incredibly disingenuous. The only way a Haskell or ML program could be as colossally unsafe as a unityped language program is if the programmer used only one giant sum type for the entire program, and most functions in the program were non-total with respect to that type. "Unityping" provides no static type safety. It is isomorphic to, and usually a euphemism for, the lack of any static type system.

jneen 12y ago
Yeah, it was a difficult decision to remove types - I'd gotten myself into a corner trying to tack on dependent types, and it just wasn't happening. My bet is that unlike most of the un{i,}typed languages out there (most of which I'd categorize as lisps and smalltalks), tulip provides tagging and destructuring that allows the programmer to maintain some level of control over the polymorphism. Tulip will panic at runtime for non-total functions, but ideally you'll have the tools necessary to keep the panic as close to the problem as possible.