Spring cleaning

[qwertie]

Sometime soon I'd like to have a good old fashioned round of breaking changes.

• Eliminate NodeStyle in Loyc trees? #80 Eliminate NodeStyle
• ✓ LES3: Implicit underscore in numeric custom literals? #76 Use underscore for numeric literals? Use underscore for suffix operators?
• ✓ Proposal: change trivia marker to a single character. #61 Use % as trivia marker
• LES3: keywords? #82 LESv3 Add keywords? (edit: I probably won't)
• ✓ LESv2 (and LESv3) prelude: use A: B for variable declarations instead of named arguments. I'm introducing a ✓ new operator for named arguments, tentatively named ::=. <: also seems like a reasonable choice.
• ✓ I think it's time to drop support for .NET 3.5 and .NET 4
• Switch the default language service to LESv3
• Perhaps split LESv2 into its own assembly
• ✓ EC#: rename #usingCast to 'using (for casts checked at compile time: X using Y)
• Replace Pair<A,B> with ValueTuple<A,B>
• ✓ MacroProcessor.AddMacros may as well return the number of macros added (rather than bool)
• ✓ Switch precedence of .. again to match C# (Let's finalize the LES3 precedence table #87) in v28.0

Then there's the new .NET Span<T> and Memory<T> features. The latter is basically ArraySlice<T> and StringSlice rolled into one. Upgrading for interoperability with Span<T> and Memory<T> might end up being a breaking change.

There are also some changes that are nonbreaking, or at least not obviously so:

• ✓ Support .NET Core or .NET Standard
• ✓ LES3: Faithful storage of acyclic graphs? #75 LESv3 acyclic graphs
• LES3: can named prefix operators or unparenthesized calls be practical? #74 LESv3 $ pseudo-operator
• ✓ LES3 lexer fails to set NodeStyle on literals #46 LESv3 numeric styles
• ✓ LESv3: finish up custom literal support
• ✓ LESv3: reconsider keyword parsing; sometimes .foo is seen as a keyword when it should be a dot operator.
• LESv3: resolve any other undecided issues
• LESv3: write a specification, switch over the main LES page to focus on LESv3
• I want to finally figure out how to write printers efficiently, then make printers for a couple of languages - perhaps TypeScript/JS and C++.
• ✓ vs 2019 extension #77 Oh geez, do I have to support another VS version? I guess so.

It's a lot of work but I have some time on my hands. I'm inclined to focus on nonbreaking changes first but I'd like to gather up a list of breaking changes here. CC @jonathanvdc

[jonathanvdc]

Hi @qwertie!

I don't really have any strong opinions either way regarding most of the (breaking) changes you're proposing here. They all seem fair and reasonable.

With regard to the enhancements: .NET Standard support would be neat. If Loyc were to support that then I could upgrade my Flame rewrite to support .NET Standard as well. That being said, I'm not in a rush to use .NET Standard for Flame. My current setup works well for me and my Flame rewrite isn't feature-complete yet.

Writing a LESv3 spec of some kind also seems like a great idea: maybe it'll help people decide if LES is a good fit for their use case. Speaking of which, what kinds of use cases do you have in mind for LES? Personally, I think LES is great for building DSLs. So it might make sense to "market" LES as JSON for DSLs: LES' syntax is really flexible and it allows people to flesh out a DSL in no time because they don't have to write a parser anymore. That's a pretty good selling point in my opinion. What do you think?

[qwertie]

Okay, I just released a .NET Standard version. And I agree, LES is great for DSLs and that would be better marketing than "an interchange format for syntax trees". I often see niche languages and custom DSLs, and I habitually imagine a series of small tweaks that would turn their custom language into LES! Hmm, but can I count on DSL-makers to know what a DSL is, or should I say something like "JSON for programming languages"?

[jonathanvdc]

Okay, I just released a .NET Standard version.

Awesome! I'll update Flame to support .NET Standard as well when I get the chance.

Hmm, but can I count on DSL-makers to know what a DSL is, or should I say something like "JSON for programming languages"?

No idea. Maybe you can do both? You could first say that LES is super useful for building a DSL and then describe what a DSL is. That ought to get the point across both to people who know what DSLs are and to people who don't.

[qwertie]

New spring cleaning item: #84 - I might do this right away, or I might wait a year, haven't decided.

[qwertie]

New spring cleaning item: consider eliminating StringSlice, replacing all uses with UString.

Update: done!

[qwertie]

Renaming #namedArg to '::=, with '<: as an alternate name. (I would've chosen ::: as it looks cleaner, but its precedence in LES just doesn't work for this purpose; the new precedence of <~ is also too high.) A macro changes '<: to '::=.

[qwertie]

Hmm, this isn't going in the planned order. I just added tuple-type support in the EC# parser and made sure other C# 7.0 features will at least parse. I think the next thing to do is rejigger the assemblies (#101) and LNode lists (#100) and then release semantic version 27.0 (2.7.0.2) without most of the spring-cleaning items. Notably, getting rid of NodeStyle isn't that simple and despite making LNode more complicated, I actually like having a teeny-weeny bit of mutable state in there.