some background(syntax highlighting seems not working properly, sorry for that):
in Java, one can write Map<String,Collection<String>>xxx, and the compiler won’t get confused about the >> there because of a trick in the parser. in kotlin however one cannot write val set:Set<String>=... because the compiler will get confused about >= there.
so one might want to use import Set<String>as SetOfString;val set:SetOfString=..., but it won’t work. however typealias SetOfString=Set<String> works. this makes me wonder:
is there a chance that kotlin can enable the use of val set:Set<String>=... by using the same trick as Java?
the trick is to treat LTEQ(>=) as separate tokens LT(>) and EQ(=) in tokenizer and use LTEQ:=LT EQ in the parser. this also enables the use of 1 > = 0, and it can be disabled if we check for spaces explicitly.
“typealias”'es functionality is a superset of “import as”'es, namely, every import M as N can be written as typealias N=M, and typealias N=M<G> can’t be written as import M<G>as N.
will kotlin deprecate typealias by allowing import to appear in the middle of the file and support import M<G>as N, or we can deprecate “import as” in favor of “typealias”?
makes the code cleaner, I think this question is the same as:
why Java supports Map<String,Set<String>> where people can simply write Map<String,Set<String> >
I disagree. White space increases legibility in this case in my opinion. But that is just my preference, and I believe the preference of almost all developers. I can’t imagine that someone would want to write an assignment without spaces around =.
I feel that the complication of the parser is not worth the benefits that it gives a very small group of developers, but I may be wrong. You can always create an issue for it, and maybe it will get enough votes to be implemented.
We find variable declarations without spaces around = to be strictly less readable than the ones with spaces, and it’s hard to convince us to make changes to the compiler if the only benefit of these changes is making it possible to write less readable code.
A common use case for import as is renaming top-level and extension functions, and this cannot be accomplished with a typealias.
it seems to me that “import as” and “typealias” can both be used to rename references, why not supporting import M<G> as N? if so, could typealias be removed?
This would require allowing to place imports anywhere in the file, and not just in the beginning, leading to a significant increase of complexity in the compiler and the tooling.
it’s not obvious to me, why is that? when converting a typealias to import-as, if no such name is used before the original typealias, can we just move the resulting import-as to the top section of the file?
now it seems to me that import-as can rename imports, where typealias can only rename types, if I understand it correctly, we just have to extend import-as to support generics, and offer an option to convert typealiases automatically. I just couldn’t understand why we need two set of keywords for what I think is (ultimately) one feature.
Typealiases are more “visible” than imports. Import only affect the scope of the file, whereas typealiases can be internal or even public, so that they are visible in other files and modules.
Knowing nothing about the kotlin tokenizer but being reasonably familiar with compilers, solving this problem with an ANTLR generated parser would involve using what ANTLR’s own author calls “lexical black magic”, which he has a whole chapter on in his reference.
Needless to say, black magic is not appreciated in large-scale software projects.
I think the idea of a brain-dead tokenizer is not only acceptable but preferable. Enforcing some amount of white-spacing --especially as a mechanism to remove ambiguity for tokenzers-- seems entirely reasonable to me, and I believe leads to greater standardization and better comprehension among greenhorn devs.