ecsharp
ecsharp copied to clipboard
qwertie
Spring cleaning
Sometime soon I'd like to have a good old fashioned round of breaking changes.
- #80 Eliminate NodeStyle
- ✓ #76 Use underscore for numeric literals? Use underscore for suffix operators?
- ✓ #61 Use
%as trivia marker - #82 LESv3 Add keywords? (edit: I probably won't)
- ✓ LESv2 (and LESv3) prelude: use
A: Bfor 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
#usingCastto'using(for casts checked at compile time:X using Y) - Replace
Pair<A,B>withValueTuple<A,B> - ✓
MacroProcessor.AddMacrosmay as well return the number of macros added (rather thanbool) - ✓ Switch precedence of
..again to match C# (#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
- ✓ #75 LESv3 acyclic graphs
- #74 LESv3
$pseudo-operator - ✓ #46 LESv3 numeric styles
- ✓ LESv3: finish up custom literal support
- ✓ LESv3: reconsider keyword parsing; sometimes
.foois 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++.
- ✓ #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
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?
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"?
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.
New spring cleaning item: #84 - I might do this right away, or I might wait a year, haven't decided.
New spring cleaning item: consider eliminating StringSlice, replacing all uses with UString.
Update: done!
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 '::=.
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.