Comment by perlgeek
2 days ago
I like 99% of this, and the thing I don't like is in the very first line of the example:
> import abs, epsilon from math
IMHO it's wrong to put the imported symbols first, because the same symbol could come from two different libraries and mean different things. So the library name is pretty important, and putting it last (and burying it after a potentially long list of imported symbols) just feels wrong.
I get that it has a more natural-language vibe this way, but put there's a really good reason that most of the languages I know that put the package/module name first:
import packageName.member; // java
from package import symbol; # python
use Module 'symbol'; # perl
With Typescript being the notable exception:
import { pi as π } from "./maths.js";t
Also autocomplete.
Though I almost never manually type out imports manually anymore.
I really like the way Elm does it, from "wide" (package) to "narrow" (symbol). I suspect this also helps language server implementation.
See https://guide.elm-lang.org/webapps/modules (scroll down to "Using Modules") for examples
Do you think approaching the way typescript does it for Bolt is a reasonable compromise here? Bolt already supports full-module renames like
So supporting something along the lines of
Would be farily simple to accomplish.
The OP seems to be asking for the Python order of the import statement because it allows for simpler auto-completion when typing it:
In a format like this, your language service can open up `math` immediately after the `from math` and start auto-completing the various types inside math on the other side of the `import`.
Whereas the `import abs from math` often means you type `import` have no auto-complete for what comes next, maybe type ` from math` then cursor back to after the import to get auto-completion hints.
It's very similar to the arguments about how the SQL syntax is backwards for good auto-complete and a lot of people prefer things like PRQL or C# LINQ that take an approach like `from someTable where color = 'Red' select name` (rather than `select name from someTable where color = 'Red'`).
Or: `import math with abs as absolute, sqrt as square_root`
Oooh, bikeshedding! To me your `import math with x as y` reads like "import all of math, making all of its symbols visible, just renaming some of them". That's different from the intended "from math, import only x (maybe with a renaming)".
Why?
Put the category first so it makes it easy to skim and sort dependencies. You're never going to organise your dependencies based on what the individual functions, types or sub-packages are called, and sorting based on something that ends up in a more or less random place at the end of a line just seems obtuse.
According to the Programming Guide, it supports aliases for imports
"In case of conflict or convenience, you can give modules an alias as well."
This isn't about conflict, it's about how humans read it.
Let's say I have two modules, "telnet" and "ssh", and both have a "connect" function. When I read "import connect, (long list of other imports here)" I don't know which connect it is, and I might form the wrong mental connection, which I then have to revise when I start to read the module name.
can't the compiler process it in reverse?
The compiler doesn’t care either way, this is for the human reader’s benefit.