5 ms·

I'm a bit confused. The documentation says it is static and strongly typed, but the example for functions is: def multiply(a, b): print("Multiplyin

I'm a bit confused. The documentation says it is static and strongly typed, but the example for functions is: def multiply(a, b): print("Multiplying", a, "with", b) return a*b How is this strong and static? If I don't need to specify what my function takes, isn't that duck typing? Maybe I'm missing something? It would be really nice to have strong, static types. It's the only thing keeping me from learning Elixir, so this could be a nice alternative.

deciduously 2y ago
It could be both if all types are inferred.
- leke 2y ago
  I think Kotlin is an example of both.
cbarrick 2y ago
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
munificent 2y ago
I was confused by that too. Under the "Types" page of the guide[1], they say: > Every value in Acton is of a certain data type, which tells Acton what kind of data is being specified so it knows how to work with the data. Acton is a statically typed language, which means the type of all values must be known when we compile the program. Unlike many traditional languges like Java or C++, where types must be explicitly stated everywhere, we can write most Acton programs without types. The Acton compiler features a powerful type inferencer which will infer the types used in the program. > Acton implements the Hindley-Milner (HM) type system, which is common in languages with static types, like Haskell and Rust. Acton extends further from HM to support additional features. The language also has inheritance (and thus presumably subtyping), protocols (interfaces, I think), and generics. Historically, those features have not played nice with HM inference, so I'm not sure what's going on there. [1]: https://acton.guide/types/intro.html https://acton.guide/types/intro.html
monooso 2y ago
In case you're not aware, Elixir is in the process of implementing gradual set-theoretic types. https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...

deciduously 2y ago

It could be both if all types are inferred.

leke 2y ago
I think Kotlin is an example of both.

cbarrick 2y ago

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

munificent 2y ago

I was confused by that too. Under the "Types" page of the guide[1], they say: > Every value in Acton is of a certain data type, which tells Acton what kind of data is being specified so it knows how to work with the data. Acton is a statically typed language, which means the type of all values must be known when we compile the program. Unlike many traditional languges like Java or C++, where types must be explicitly stated everywhere, we can write most Acton programs without types. The Acton compiler features a powerful type inferencer which will infer the types used in the program. > Acton implements the Hindley-Milner (HM) type system, which is common in languages with static types, like Haskell and Rust. Acton extends further from HM to support additional features. The language also has inheritance (and thus presumably subtyping), protocols (interfaces, I think), and generics. Historically, those features have not played nice with HM inference, so I'm not sure what's going on there. [1]: https://acton.guide/types/intro.html https://acton.guide/types/intro.html

monooso 2y ago

In case you're not aware, Elixir is in the process of implementing gradual set-theoretic types. https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...