Boo language roadmap

[masonwheeler]

The question of a roadmap recently came up in another issue. Since we don't have one, I thought I'd write one up.

This is tentative and subject to change, based on community feedback, but here are the things I feel are the highest priority right now:

• Boo v1.0. According to @bamboo, this will be achieved when the entire language is written in Boo. So far, several auxiliary libraries are in Boo, but the core three (Boo.Lang, Boo.Lang.Compiler, Boo.Lang.Parser) remain C#.
  • Migrating Boo.Lang.Parser will be difficult because a lot of it is generated code from ANTLR, which doesn't have a Boo code generator.
  • Boo.Lang.Compiler makes use of switch/case statements in several places, which Boo has no support for yet.
  • Boo.Lang.Compiler contains DepthFirstGuide, which can't be translated to Boo yet because of name resolution issues. This should either be resolved in the compiler, or DepthFirstGuide should be thrown out. (According to @drslump it doesn't appear to be used anywhere, so that's an available option.)
• Add missing language features
  • LINQ syntax and expression trees -- we have this, but without tests it's not ready to integrate.
  • Allow overloading for macros with parameters.
  • ref struct types, a very useful feature which is gaining traction in C#
    • Support for Span<T> and Memory<T>, related to ref structs.
  • switch/case statement: Boo has a magic __switch__ function that maps directly to the switch IL opcode, but it's not very user-friendly. Having a macro wrapping it that provides the same semantics as C#'s switch would be great. It might also be useful to integrate it with pattern matching. And speaking of which:
• Move pattern matching to Boo.Lang.Extensions. Having it in its own separate library might have been a good idea when it was new, but now that it's part of the language core, (it's used for macros with parameters,) it should be in Boo.Lang.Extensions so there are less things to keep track of for people deploying the language as a service. (Scripting, etc.)
• Visual Studio support. Having a working Boo language plugin for the Visual Studio IDE is very important. I've been working on updating @popcatlin81 's Boo plugin, but it still needs work.
• .NET Standard support. Boo is currently .NET Framework only, while most of the work being done these days is on Core, with persistent rumors that Framework is reaching the end of its lifecycle. The compiler has to be updated to support Core and .NET Standard. There will be a handful of headaches here, the major one being that .NET Core doesn't have a working Reflection.Emit implementation.

These are the things that I see as being the most important right now, in no particular order. Comments are welcome; PRs even more so.

[Guevara-chan]

Well, just finished my latest commercial mini-project in Boo and got some thoughts about it's future:

1. Using completely incompatible non-generic List and Hash custom implementations on a language level was a bad idea in 2005. For 2018+ it's simply confirmed madness.
2. Boo.Lang.Dll is a cool way to remind everyone which lang you used for your project. Especially since I personally never needed a single thing from it.
3. C# made really extensive usage of default parameters in third-party libraries nowadays.
   Like. Really. Extensive. Usage.
4. Did I said already that dedicated external runtimes aren't cool in 2018 ? I sure did.

[masonwheeler]

@Guevara-chan

1. Agreed, having those around is just annoying. They kind of have to stick around for compatibility reasons, though.
2. Did you use generators anywhere? Or type coercion? If so, you need stuff from Boo.Lang.dll. If you didn't use any of the features it provides, though, you should be able to get away with not shipping it with the finished product. (If you're not sure, use ILDASM to check your manifest and see if it's a dependency.)
3. Yeah, this is a feature that does need to go in.
4. What would you suggest as a solution, then?

[Guevara-chan]

1. 👌🏻
2. List comprehensions is too limited for my taste to use over Select and needs additional work to be made into comprehensible datatype. Yield is already provided in C# without need for additional .Dlls. Type coercion is cool, yet could be just a macro for Сonvert.
3. 👌🏻
4. Inlining all required stuff (and ONLY required stuff) in .exe, of course. Required stuff gonna be like... 2-3Kb overhead for most projects.