https://kotlinlang.org logo
Join SlackCommunities
Powered by
when i paste this into intellij i see
# language-proposals
j
when i paste this into intellij i see
..i see this...
usecase: kotlin can follow intellij's lead and assign start and end operators for lists, maps, and arrays....
r
You can for lists in annotations. There a longstanding open request for collection literals in Kotlin. I don't know what the status is, but you can probably find more information in YouTrack.
k
Are you talking about collection literals? https://github.com/Kotlin/KEEP/pull/112
j
clearly that looks like a debate deep in analysis paralysis.
i didnt read the PR code, but is there a chance to bring that along via the arrow-kt compiler extension examples?
k
It's basically dead in the water until Kotlin allows functions to be differentiated by their return type. I don't know anything about #arrow-kt, so I can't speak to that.
j
my interpretation of inline classes was like this: you want the old class, but you want a new return type. now you have both.
k
@jimn I don't follow
j
I would write the proposal to introduce new literals with new inline classes for old collections, for use in Experimental annotation
then the ludites won't have to worry about an influx of js newbs using collections with literals polluting thier pristine namespace
k
I think you should read the proposal I linked. It uses operator functions instead of classes, and doesn't require any new types whatsoever.
✔️ 1
j
can you describe any showstoppers that aren't purely bikeshedding arguments?
k
The only way to determine, based on a given collection literal in the file, which type it should be interpreted as, would be to allow the most appropriate 
operator fun sequenceLiteral
or 
operator fun dictionaryLitertal
to be chosen. To determine which is most appropriate, they have to be distinguished by their return types as well as their parameter types. Today, Kotlin only distinguishes identically-named functions by their parameter types. A separate Kotlin compiler change needs to be made to allow distinguishing by return types. Aside from activating this currently-unused JVM capability, this might also introduce strange and unexpected errors in existing code if it were compiled with that new compiler, and in the behavior of existing compiled bytecode if it were linked against that new Kotlin runtime/stdlib. These are problems I'm willing to work through, but nobody from JetBrains has stepped up to be a shepherd to this feature. More on KEEP shepherds: https://github.com/Kotlin/KEEP#keep-shepherds
j
apparently there is someone at jetbrains who couldn't live without their annotation addiction and implemented literals into annotations. this was a feature of such importance that it became an incorrectly implemented intellij type recognition trigger. which brings us full circle to my proposal.
strange and unexpected errors in existing code if it were compiled with that new compiler, and in the behavior of existing compiled bytecode if it were linked against that new Kotlin runtime/stdlib.
this didn't stop inline classes from pushing ahead and completely obfuscating legal kotlin from java legalities. and so it should follow that precedent, seperate but implemented language features can move into realization as features that don't provoke the wrath of legacy compatibility trolls using inline classes as one approach of potentially many to avoid legacy conflicts
➕ 1
i believe we could arrive at a productive benefit from having collection literals even if we did something silly and proclaimed it must be for simple JSON types-- the community would still win, in fact, we would have a new implementation every week testing json parsers as kotlin transparency strategies.
k
Hmm how would you solve the empty-set problem?
j
i would leave that to the implementor to solve free of bikeshed
"if i were building the bikeshed, i would pass the buck to wikipedia"....
"Passing the buck to wikipedia" makes me aware that while there are numerous mathametical notations, these are very rarely confined to the ascii character set, and apparently no particular collections concepts character set convention exists outside of the general centroid of "Set Notation". Wikipedia itself tends to draw in unicode characters almost instantaneously with every definition that hints at either an explanation or a notation. This is actually troubling, because I'd rather not pick a side, unless that side is to liberally enable unicode operators to minimize the distance between my code and some paper I'm drawing implementation details from. (and I do exactly this, with the limitations imposed by kotlin that it is impossible for colelctions)
k
That's kind of pedantic, 
{}
is just fine and look similar enough. This bigger problem is that an empty map (usually 
{a:b, c:d}
) and an empty set look identical.
j
are you going to build the bikeshed?
the blocker here is there are no shepherds, and the discussion is based on a multitude of informed opinions adding their particular concerns. this is not the same as coroutines, coroutines are vastly complex and dangerous concepts, the shepherds addded annotations and lifecycle process to support concepts like coroutines, but noone will touch curly braces.
something REALLY important happened inside the annotations implementation that bypassed all the bikeshedding, and went straight into intellij interpretation.
"In the context of programming language design, one encounters "Wadler's law", named for computer scientist Philip Wadler.[6] This principle asserts that the bulk of discussion on programming language design centers on syntax (which, for purposes of the argument, is considered a solved problem), as opposed to semantics." https://en.wikipedia.org/wiki/Law_of_triviality
k
There's no real semantics to discuss, the entire proposal is literally new syntax for something that already exists. You're talking about whether to use 
{}
or 
Ø
or 
∅
youself, but whenever anyone else does you condescendingly call it bikeshedding or trivial.
j
"BenLeggiero commented on May 14, 2018" -- no sheperd yet. long discussion. The python founder said he has an issue with empty-set, but no [other] regrets. you ask me my personal opinion on empty-set, and i give you my opinoin and my rationale. the problem is clearly much larger, but more importantly, there is an overwhelming amount of horsepower here in a deadlock since May 2018.
meanwhile, your kotlin editor +- primary language vendor implemented optimistic parser for this syntax as annotations.

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

hell yes, there is some serious bikeshedding but not on the intellij team. just in the language spec
k
Of course, what kind of error intelij gives doesn't matter that much so you can just make a quick decision, meanwhile the language spec is there forever.
j
overstated. coroutines are the example to follow, nothing permanent about them today
k
Well they were experimental at first but now they're pretty permanent, no? (I know they're a separate library but I assume they'll guarantee backward compatibility there too)
j
coroutines now? not permanent. still evolving. not going away, but but cautiously proceeding with some additions and removals
my proposal here is to promote whatever logic intellij uses to recognize java Character arrays in kotlin annotations as a programming option in kotlin sooner than later. certainly wouldn't want to wait another 18 months for @Ky Leggiero similar KEEP#112. There are several things that have become available since April 2018: • Experimental Lifecycle Annotations • Inline Classes • Arrow Meta compiler extensions Any one of these let alone all three could be an effective vehicle to demonstrate plausibility of a starting point to @elizarov and the rest. The most conspicuous inconsistency is that Annottions are operating on a black budget with syntax freedoms not carried over to the languge evolution "forever" thing.
k
They're implemented in annotations because it's very easy: there are no collections to worry about, no user defined stuff, no type inference problems, no resolutions necessary. It's literally only primitive and strings arrays.
j
and for collections, those are usecases where kotlin has a sledgehammer to kill a fly
you are arguing against a simple string array? simple list of ints? so we are stuck with literally 0 macros for simple usecases?
kotlin extensions and operator overloading are completely awesome features, until you look at the list of allowable operator literals, like all 5 of them. This proposal is a side-effect of kotlin being in the wrong quadrant of this box. KEEP#112 is like a completely parrallel casualty, anything in the area of operator overloading seems to end in FUD

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

the language could easily accomodate operator definition and in so doing, eliminate a lot of specification discussion about bike shed complexity
k
I'm not arguing against a simple string array, I'm trying to explain why the problem is not as simple as "just paste intelijs array parser into the actual compiler, it'll be fine".
➕ 3
Allowing custom operators to be defined is also just a can of worms, and still won't allow array literals unless you just allow arbitrary language constructs to be defined.
j
not as simple as "just paste intelijs
this and KEEP#112 are simply fighting for crumbs in the bigger picture of expressive options. the compiler can be extended, so it's possible to iterate this way on models (in a vaccuum) but the following things seem to hold true: pairs of literals have language elements: (incompletel list) • entity/function scope {...} • Index [...] • expression scopes (...) things in keep#112 Collection literals same arity as joinToString(sep,prefix,suffix()) and then there's things in the definable operators quadrant of operator overloading languages which kotlin is not a part of, and presumably Kotlin could move to join those and solve keep#112 by defining perhaps anything it allows in backticks as a symbolic operator for the sake of fidelity with domain specifications that are not already kotlin source code. These might be structured like corouinescopes in terms of the mechanics that can be applied with definable operator interplay, I wouldn't want to pigeonhole definable operators "forever" with a simplistic expectation of arity 1,2,3 operator what we could gain by the upper right quadrant of the overload languages box is truly thin dsel parser and functional decomposition options that we don't have with anything but sed and awk right now, on thier terms via regex.
or when a bigger gun is needed, antlr.
2 Views
Open in Slack
PreviousNext
Powered by