search

qwertie / ecsharp

Home of LoycCore, the LES language of Loyc trees, the Enhanced C# parser, the LeMP macro preprocessor, and the LLLPG parser generator.
http://ecsharp.net
Other
177 stars 25 forks source link

Spring cleaning #81

Open qwertie opened 5 years ago

qwertie commented 5 years ago

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

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

qwertie commented 5 years ago

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

Update: done!

qwertie commented 4 years ago

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 commented 4 years ago

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.