4 ms·

Static: the types could be inferred. I haven't looked too closely yet. Strong: Python is strongly typed with a similar syntax. Strong vs weak typing means "ho

Static: the types could be inferred. I haven't looked too closely yet. Strong: Python is strongly typed with a similar syntax. Strong vs weak typing means "how much information does the type system provide to me." Static vs weak typing means "when does the type system do its work." I see no reason why a language with syntax like this could not be strongly typed. The static part is hard to claim until the type inference rules are explained.

tail_exchange 2y ago
I think the word I'm looking for is explicit. It's not required to have explicit types in the functions, which I find disappointing.
- keithnz 2y ago
  why? type inference is generally quite nice. Makes for clean code. One of the things I've enjoyed from using things like F#. All the advantages of strong and static typing without the cruft.
  - tail_exchange 2y ago
    It depends how it's applied. I like type inference when I'm defining a variable, for example. In Go, I can just write this: message := "hello world" ...and the compiler knows it's a string, and I know it's a string because I can just hover it with my mouse and my IDE will tell me that. That's good enough for me. But when we are talking about functions..: # some fictional function I just came up with def install_requirements(dependencies, opts): run_setup(dependencies, opts) return assert_requirements_installed(dependencies) Now I'm confused. What is the data type of "dependencies" and "opts"? Is the IDE smart enough to tell me that? What if I'm building a function that assumes "dependencies" to be of type A, but the compiler thinks it can also be type "B"? I don't know enough about compilers and type inference to know whether this is actually a problem in Acton or not. I wish they explained more. My gripe against this kind of inference is that it's impossible for my IDE to tell me what is being passed around. In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition; can Acton do the same?
    - kll 2y ago
      It's about the same in Acton message = "hello world" message is a `str` since we know the literal "hello world" is a str. Some literals can be multiple types, like 123 can be `int` or `u64` or some other fixed int type. You can specify the type explicitly if you want to # some fictional function I just came up with def install_requirements(dependencies: set[str], opts: dict[str, str]): run_setup(dependencies, opts) return assert_requirements_installed(dependencies) which makes it easier to read the code which is a little bit more involved. It also helps guide the type inferrence & checking. Hindley-Milner type checking is notorious for doing a good job at type unification and a lousy job at error messages. Acton is no exception and is arguably worse than many other users of HM implementations since it is relatively young and all effort have gone into actual type checking and not much into errors. Broadly speaking, I think the modern solution to IDE insight into types is to implement an LSP that provides types and other information to the editor. Acton does not have an LSP but it will.
      - tail_exchange 2y ago
        Cool. Thanks for explaining!
    - mrkeen 2y ago
      > In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition Java doesn't track the types as well as HM does. Specifically, if I treat a Stream as a Mappable, I lose the static type info, and can only get it back via casting. In an HM language, e.g. Haskell, my object is statically a Stream type everywhere it's used, even if I'm doing Mappable stuff to it.

tail_exchange 2y ago

I think the word I'm looking for is explicit. It's not required to have explicit types in the functions, which I find disappointing.

keithnz 2y ago
why? type inference is generally quite nice. Makes for clean code. One of the things I've enjoyed from using things like F#. All the advantages of strong and static typing without the cruft.
- tail_exchange 2y ago
  It depends how it's applied. I like type inference when I'm defining a variable, for example. In Go, I can just write this: message := "hello world" ...and the compiler knows it's a string, and I know it's a string because I can just hover it with my mouse and my IDE will tell me that. That's good enough for me. But when we are talking about functions..: # some fictional function I just came up with def install_requirements(dependencies, opts): run_setup(dependencies, opts) return assert_requirements_installed(dependencies) Now I'm confused. What is the data type of "dependencies" and "opts"? Is the IDE smart enough to tell me that? What if I'm building a function that assumes "dependencies" to be of type A, but the compiler thinks it can also be type "B"? I don't know enough about compilers and type inference to know whether this is actually a problem in Acton or not. I wish they explained more. My gripe against this kind of inference is that it's impossible for my IDE to tell me what is being passed around. In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition; can Acton do the same?
  - kll 2y ago
    It's about the same in Acton message = "hello world" message is a `str` since we know the literal "hello world" is a str. Some literals can be multiple types, like 123 can be `int` or `u64` or some other fixed int type. You can specify the type explicitly if you want to # some fictional function I just came up with def install_requirements(dependencies: set[str], opts: dict[str, str]): run_setup(dependencies, opts) return assert_requirements_installed(dependencies) which makes it easier to read the code which is a little bit more involved. It also helps guide the type inferrence & checking. Hindley-Milner type checking is notorious for doing a good job at type unification and a lousy job at error messages. Acton is no exception and is arguably worse than many other users of HM implementations since it is relatively young and all effort have gone into actual type checking and not much into errors. Broadly speaking, I think the modern solution to IDE insight into types is to implement an LSP that provides types and other information to the editor. Acton does not have an LSP but it will.
    - tail_exchange 2y ago
      Cool. Thanks for explaining!
  - mrkeen 2y ago
    > In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition Java doesn't track the types as well as HM does. Specifically, if I treat a Stream as a Mappable, I lose the static type info, and can only get it back via casting. In an HM language, e.g. Haskell, my object is statically a Stream type everywhere it's used, even if I'm doing Mappable stuff to it.