Hacker News Reader

Comment by cbarrick | Hacker News Reader

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.

View on HN

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.

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.

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?

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.

Cool. Thanks for explaining!

> 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.

Reply on news.ycombinator.com