News for hackers. Stuff that matters.
Re:We need more keywords by gizmo686 on Wednesday January 09, 2019 @09:30PM (#18871038)
Another option is to enable language features on a per-file basis. That way you could have your "ideal" syntax, and only have to do the work of updating those files where you need to use it.

The only language I can think of that does this extensively is Haskell (and some flavors of regular expressions). The main downside I have noticed is that the ability to do this allows for the language to add a bunch of complexity that would otherwise be prevented by the need to preserve backwards compatibility [1]; but, if the language writers can remain disciplined, it seems like an effective way to grow a language without the growing pains the article is discussing.

For adding keywords, this approach doesn't even add that much maintenance cost, as all the additional complexity is confined to the lexer.

[1] Or, as has happened several times with Haskell, add features that too broken to even be considered adding but for the fact they are always behind a flag.

Re:We need more keywords by majewsky on Thursday January 10, 2019 @06:58AM (#18873232)
> The only language I can think of that does this extensively is Haskell

Rust is doing the same thing (although on the level of crates (packages) instead of individual files). When you want to use new keywords like async/await, you have to declare your crate as using the 2018 edition of Rust (as opposed to the original 2015 edition). Crates using different editions can be freely mixed, so when a new edition is released, everyone can migrate to the new edition at their own pace.

Re:We need more keywords by EvilTerran on Thursday January 10, 2019 @07:00AM (#18873249)
Python has the same idea, albeit on a smaller scale, with its "from __future__ import <feature>" statements:

https://www.python.org/dev/peps/pep-0236/

Re:We need more keywords by steinuil on Thursday January 10, 2019 @01:24AM (#18871941)
On a purely syntactical level, F# has a "light" indentation-based syntax mode which can be toggled on a per-file basis, and OCaml recently got a whole syntax revision with curly braces in the form of ReasonML, which the build system automatically recognizes based on its file extension.

Neither of these adds new keywords (ReasonML switches some around, e.g. match is now switch) but maybe one of these approaches might work for language features or breaking syntax changes or revisions.

Re:We need more keywords by willghatch on Thursday January 10, 2019 @05:08PM (#18878759)
One of my favorite features of Racket[1] is that each file declares its dialect on the top line with `#lang language-name`. Different dialects, such as custom embedded DSLs, can have slight syntax modifications or even their own custom lexer and parser. In the end Racket modules all boil down to a smaller core language and interoperate beautifully.

[1]: https://racket-lang.org

Re:We need more keywords by chrisseaton on Wednesday January 09, 2019 @09:38PM (#18871064)
> Another option is to enable language features on a per-file basis.

Will you need a new keyword to enable your option for new keywords?

Re:We need more keywords by gizmo686 on Wednesday January 09, 2019 @09:44PM (#18871101)
It works better if it is part of the language from the start.

Having said that, we can probably implement it using only existing keywords. Maybe: import java.lang.extensions.assert.

(I assume Java has some reserved part of the package namespace they can use for this purpose. Even if they don't, it shouldn't be difficult to find a package name that hasn't been used by anyone yet)