I think this is awesome. One of the only pain points I have with Scala is collection literals.
I’d like to see something like this proposal. I’d been following that pre-SIP but was rather dismayed by so many negative comments.
I respect those who urge caution to be sure that it’s not too hard to implement in the tooling - smooth-running metals etc. is very important. But it’s a pity to see all those remarks like “we shouldn’t put data in code”.
I’m a scientist, I make an interactive climate / socio-scenarios system model. It now works in scala.js (even wasm), but was derived from a java applet, evolving over 25 years.
This is real world stuff, there are many small sets of ‘constants’ (not user data) with irregular structures, setting up gases and aerosols, regions, socioeconomic sectors, sources of energy, land use biomes, pledge (NDC) definitions, parameter sets tuned from other models and scenarios, etc. etc. Of course the model loads big historical datasets separately, but small sets of numbers should be in the code where it’s easy to see and adjust them (real world and science changes…), that’s an essential part of the transparency. And don’t tell me to put these within multi-line strings, then the compiler doesn’t check the structure, so we’d get runtime errors instead (scala is great - because when once it compiles, it just works).
As noted in the discussion, there are various workarounds with aliases, which I use, but it could be neater.
A related topic that was on scala-contributors which I’d like to see reopened is multi-level (nested) enums, for similar reasons. To get around the limitations of enums, I recently started to write my own macros, which works but … (another story…).The “we shouldn’t put data in code stuff” is silly. Why do we have Scala worksheets, then? The reason I like and teach Scala is that it’s so flexible and meets you where you are.
@benjhm @smoredahl “Scala does not have enough ways to do the same thing”, a sentence probably never spoken.
Ha, I won’t pretend this is not a challenge in Scala. But then I would ask, why be precious about this one thing?
@smoredahl Because it’s always the same “I agree in principal that we shouldn’t add more things, but my pet syntax addition should be exempt”.
And then people who do *not* want to get new language additions get overridden by the 5% that want *this* feature and the cabal of people that do not care about this one, but have their own pet extension they want to add.
Language design is leaving things out.
@smoredahl Not to mention that the people who want to add things don’t even want to deal with the fallout, for instance figuring out what gets cut from presentations, workshops, tutorials.
It’s just sad that nobody cares about learners/beginners when adding yet-another-thing.
I understand your perspective, but I argue that there is a difference between adding a new feature that is unique to your language (I think we would both agree that Scala does not need any more of these), and adding a feature that makes the language more consistent with the syntax that most people coming from other languages expect to be there.
I teach Scala at a university level, so I very much do care about learners and beginners. In my opinion, having a syntax for collection literals would make the language a little more approachable, as my students are coming from languages that do provide this syntax (e.g., Python).
@smoredahl That’s an absolute dog shit reason to be completely honest.
No matter how familiar it makes the language, it increases the inconsistency within the language itself, not to mention the complexity that comes with it.
I have a whole presentation about how stupid increasing familiarity at the expense of simplicity and consistency is.
One of the core reason why we can’t have nice things in computing.I see what you’re saying, but isn’t familiarity worth something? After all, Brainfuck is incredibly simple and consistent :)
