Hacker News Reader

Comment by xigoi | Hacker News Reader

Requiring namespaces would break dot call syntax, which is one of Nim’s main features.

It could be preserved if specifying the namespace used a different syntax.

Right now, if I have the `foo` module and `bar` function, I can call `arg1.bar()`, or `foo.bar(arg1)`. But if the namespace didn't also use `.`, then it wouldn't be an issue.

For sake of argument, lets choose `/` like Clojure. Then we'd get: `arg1.foo/bar()` so we can specify the namespace and uniform function call syntax is preserved.

True. That said, would you find, say,

    "one,two".std/strutils/split(',')

more readable than this?

    "one,two".split(',')

Maybe. First, you need the module name primarily for disambiguation for compiler or possibly for readability. I wouldn't recommend requiring it for everything, eg one of the arguments against requiring naming all imported symbols explicitly is for procs that use `[ ]`.

But I think the std/strutils/split counter example isn't strong for two reasons:

1. When you disambiguate in Nim, you use just the module name, not it's full path. So it would still just be `strutils/split`.

2. If we were to introduce such a syntax, we could also introduce an `import foobarbazqux as foo` alias syntax, which is present in many languages (eg JavaScript, Clojure, etc). This would also be useful if we ever had module name collisions, which has never happened to me in Nim, but doesn't seem impossible.

Reply on news.ycombinator.com