https://kotlinlang.org logo
Join Slack
Powered by
on that note.. I hope I am not alone, but I would ...
# language-evolution
j
on that note.. I hope I am not alone, but I would really like a "use wingnut-mode" language extension that puts kotlin into the category of overloading any operator to move kotlin from the "designated symbols" quadrant of https://en.wikipedia.org/wiki/Operator_overloading#Catalog to the top-right flexible quadrant.

https://files.slack.com/files-pri/T09229ZC6-FP3NH4PCJ/image.png▾

there are great reasons to protect a certain class of platform majorities from anti-patterns. but when you get into scientific and idiomatic equation solving you really want options to make your compiled context as transparent as possible without additional linker steps to add your ecosystem libraries to your type-safe efficiently compiled source code. I see less of this discussion than i would like to. I work routinely with graph notations and equation solvers, and also I deal with python constantly, and I would be more than happy to have such operators as foo[:] and foo[1:] in my own codex of my own equation solvers, and not have to think about what compiler extension i have to write personally to use these
➖ 1
➕ 1
f
Not that I have anything specifically against this idea in particular
But this worries me
k
I personally don't work that much with scientific python but numpy and pandas sometimes confuses me with all the 
[ ]
syntax. Of course I never took the time to learn it properly so that is on me but can be tricky 🙂 On the other hand tho F# and Haskell has some really nice operators which can significantly reduce the overhead we have to write 🤔 and as my kowledge matures around Haskell I tend to use more and more operators.
f
Is everyone going to create a compiler plugin that brings what they want into the language and the language team disagrees with?
💯 3
Is each project going to use its own sublanguage of kotlin that outsiders can’t understand?
k
@Fudge doesn't matter because it is your codebase and you decide what to include
f
Yes and no
Technically, you can use scala and decide to not use implicits
But this doesn’t solve the problem of people using implicits and then having ununderstandable code
k
it is the same as libraries, we tend to include rxjava and dagger and room and other annotations, people don't neccesary know all of them 🤷‍♂️ It let us think out of a box and start the new ideas to flow
🚫 1
j
scala TL;DR that's 10 years of jvm history that was entirely uninteresting until all the fans jumped on kotlin.
😄 1
f
But libraries work within the confinements of the language. Anything a library does is within the toolset you know
k
+ codegeneration + bytecode manipulation + reflection
f
j
what i know is that i don't want DI, or maven codegen turds or a preprocessor that creates unreflectable objects if i can stay in one compilation context
I think the llvm strategy is going to pay off in the long run and kotlin has gratuitous amounts of flexibility to compete toe to toe with rust and c++ template mataprogramming, and all of its generous operator freedom with hand-optimized assembler performance. but kotlin has most narrow set of operators short of brainfuck language which has fewer. i don't want c++ templates to be the only thing relevant in the long run to do expressive and performant idiomatic expression
understandably there is going to be converts from simple environments who need special attention to prevent them from using powerful tools to cause expensive technical debt. php programmers, and javascript communities have a really good opportunity to merge with the kotlin agenda and not threaten the larger community with a flood of dangerous packages.
if that's the primary agenda of kotlin, I'm scoping the compiler extension options because this baseline nanny-state idealism will not move the needle in performant scientific and data engineering that needs the end-game languages to merge with the compilation IR as directly as possible
I can take this a lot further
e
In fact, simply allowing more symbols to be used without backquotes in function names might solve 99% issues that you have without any major change to the language. Relaxing restriction on what can appear as an identifier is so easily that you can have your own fork of Kotlin doing that in less than a day. If you play with it and it really helps, come back with some more specific and concrete proposals.
j
I think there's a little bit more to the limitations of operators than backtick requriements, which really take the language a long ways combined with infix.
things that noone complains about in python is having some intrinsic operators (as does java!) like 
foo=["a","b"]
sub=a[1:]
e
Taking a language like Kotlin “long ways” is hard. I’m interested in what can be done easily. I do not even know how to implement user-defined precedence, for example, in a language with Kotlin’s architecture.
j
@elizarov have you had any exposure to factor lang?
e
You can use 
..
in Kotlin. 
a[1..3]
looks as good as 
a[1:3]
to me if not better, actually. Open-range operators (
1..
and 
..3
) are not supported, but adding them would be far less-intrusive that a whole new operator just for slicing.
➕ 3
This is the first time I hear about factor language, but now I see that it is a concatenative language which is a whole different subclass of PLs where user-defined operators are a piece of cake to introduce.
We are talking about Kotlin which is not concatenative at all, not even close to being to.
j
factor is powerful for a small set of principal mechanisms. kotlin is closer than anything i have seen to being the right-to-left version of factor, except momentum, structure, and the stricter typing. the most powerful and useful operators in c++ are overloadable cast indirections and the ability to double up on a symbol to do an overload or conversion. the equivalent kotlin choices appear to be overriding the '!' and unary operators, and that's like 3 -- this already brings a lot of grumbling to the arrow community so much so as to banish the ! feature after it was introduced
i think having 
operator Nothing.get(vararg x:T)=listOf(*x)
would also be an easy and pleasant addition to operator overloading possibilities, i have seen this compaint a few times already
iiuc you are open to seeing a proposal for additional operator flexibility backed by a simple PR for review
in the long game, it would take a really deliberate effort to screw up the ability to optimize an llvm front-end, so even if correctness is the only interest at this time, llvm can be independantly engineered to accomodate the parts of kotlin IR that are currently awkward.
this means that by virtue of having llvm, the long game becomes relevant, discounting this point in time
h
@elizarov In regards to relaxing the restriction on legal characters for function names, do you see that as ever coming to the language, or only suggesting we make that change in our own fork? I find the idea of allowing more characters really intriguing. I hadn't considered how far that would go to filling my desire to have math operators like ⊗ × ∧ etc
e
That’s debatable, as with every language features, but if it is proven to be helpful, combining with the ease of implementation it does have chance. Moreover, even if it is even in your own fork or hidden flag, you loose nothing in interop.
The complex decision is to figure out which characters to allow and why.
j
i think that's an academic consideration to the notion that I want extremely expressive source code in the same compilation environment as everyone else's FP training wheels kotlin dialect.
h
What is the danger of allowing... any characters that aren't already reserved for operators? ... and even those, since it'll be clear whether or not you are calling an operator function. Well yeah, unicode can get reaally messy with stuff like arabic letters, but I still think the question of "why restrict" is more prominent than "why not restrict"
j
i think that having a mode, or a context signified is adequate to draw the line for nanny project managers and the other category (me)
kotlin is already a strange coding experience with suspend keyword changing almost all of the assumptions when it is invoked. you don't (yet) have to use suspend, but if you do, you have to learn more, and you get forkbomb powers from the jvm target at least
namely, the utility would be in building sleek parsers, mapping horn-clauses and predicate logic, and yes, absolutely pushing the envelope on executable ascii art 🙂
it bodes well with the design of equation solvers to relax the imperative grammar a lot, and to experiment with the available minimums of constraint.
i think that top level functions and extension based declaration are really advanced features, and the potential to do intellectual violence with just these two features alone on a project with kotlin is an inevitable outcome. with that in mind, the spiderman "with great power..." is going to play out killing a few uncle Ben's as T approaches infinity.
there are no slack discussions that don't get a comparison to Scala or haskell several times an hour, and as an impartial observer, the syntax limitations imposed on the Arrow-kt project are mildly sadistic (and cause a lot of references to scala and haskell).
i come from c++, and I have violated the readability of several programming languages over the years to effect certain transparent outcomes, i am only aware of the limitations of kotlin in this regard, certain options are incredibly well done, but in the area of erradicating ternaries and preventing ambiguous symbols, the war has been won, google blessed kotlin with the all powerful android future. the newbs+revenue are a guranteed fixture. i think the type system would be extremely powerful if it could rejoin its roots again with a dad-key that takes it out of valet mode.
3 Views
Open in Slack
PreviousNext
Powered by