import foo(42, FULL_OF_EELS) as foo
-:1:8: E0012: Initializer of module "foo" has 3 arguments, 2 were provided.Shouldn't be like how parent proposed imports work. Would lead to too much pain.
(Don’t confuse this with me thinking this project is worthless, I think it’s art.)
Sometimes I wonder if I'm exceptionally (haha) talented as I personally find the impact of exceptions on flow control pretty easy to grasp. But based on my understanding of other advanced computer language concepts, which is pretty lacking in some regards, I come to the conclusion that it can't be too hard, and people make a lot of fuss about it for no particular reason.
- you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of potentially error-raising calls is infinite but unknowable
- you’re working in a language that has checked exceptions, and you hate that it makes you do work, so you catch-rethrow runtime errors that recreate the first scenario
- you’re working in a language that has checked exceptions, but someone else did the second scenario so you’re in the first scenario anyway
As for myself, I've lived through the hell the are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.
At the highest level of your application (and at a few critical places, executors, retrying strategies etc) handle all the exceptions you know of, and implement a sane default for everything you don't know.
Done.
import "foo/bar" should make foo.* OR bar.* available, not bazz.*. I'm looking at you, Go.
Can you give an example of what you mean?
```go
import (
"net/http"
"os"
"github.com/anacrolix/torrent"
tstor "github.com/anacrolix/torrent/storage"
)
would import as: http, os, torrent and tstor. That guy is mixed up.
For example you can have github.com/user/go-module as module name, and "module" as package name, so "import github.com/user/go-module" will be imported as "module.*".
There’s a linter that automatically aliases this kind of imports with their actual module name so that it’s non ambiguous when reading the import list.
package main
// imports 'bar', you couldn't possibly know from reading this line
import "github.com/remram44/foo20240527"
func main() {
// ??? where does this function come from ???
bar.SomeFunc()
}I posted a criticism of Go, I don't know what you mean by "this is how it normally works".
I’m so confused by this. Unless you use a dot import, isn’t this just bar.*?
Useful when writing the code but not much use when reading the code.
For that very reason in Elixir `import` is discouraged in favor of `alias`
Instead there is this pattern of naming modules based on the file path they are located in, which is not enforced.
But for example gleam [1] is another language on the BEAM (compiles to Erlang), that has a much nicer approach: All imports must be declared explicitly, and the import path in your local project is based on the file structure so you always know where something is imported from [2].
I forked Ruby to have require that didn't clobber the symbol table but then lost interest in Ruby itself because the ecosystem seems unhinged on shared global mutable state.
Critiquing a joke design is of dubious usefulness, at best :)
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.
"one,two".std/strutils/split(',')
"one,two".split(',')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.