5 ms·

Note that it definitely has types, they just aren't required explicitly. It seems to use dynamic type matching.

• jneen 12y ago
  Yep! It focuses more on dynamic type-checks than on static typing though, so I put it in the category of "untyped functional" - more like clojure and erlang than haskell or ml.
  • duaneb 12y ago
    Well, dynamic types are still types. :) It also seems strongly typed through a lack of implicit conversions between types. I would say this is more like go than anything, though it seems to lack methods (and interfaces) and includes a functional syntax. You're going to run into issues when attempting to extend polymorphism for built-in functions to user-defined types—imagine trying to figure out how to sort an 'unknown' type without a way to compare them without modifying the method to be explicitly aware of the new type.
    • asQuirreL 12y ago
      There does seem to be a method/interface system (Under the "Methods, Protocols, Implementations" header). And it seems to have some sort of dispatch system for tagged structures that can be later modified by the user.
      • jneen 12y ago
        Exactly! This is what the @method / @impl system is for - it's about equivalent to clojure's defprotocol. Future plans include named protocols consisting of multiple methods, and protocol-based matching.
• namanbharadwaj 12y ago
  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