egonSchiele
Use a macro preprocessor for speed
A while ago a suggestion came up to inline some of the code (e.g. method calls) to speed up Contracts, but to use an automated tool to do it so our code can remain nice. Perhaps other performance increases could be made in this way, e.g. unwinding loops.
I came across this new macro preprocessor that might do the job, or at least provide inspiration. Or simulating Crystal lang's macros with a preprocessor. https://github.com/alehander42/sith
Well, conceptually sith looks awesome, but it doesn't quite work (everything I tried to do got me a ruby parsing error :D). Before we can use it, we might want to send a couple of PRs to it.
Oh. From the simple work I did on yard-contracts I had to use Ripper which is what YARD uses for Ruby parsing, and it's a pile of junk. Ripper has practically no documentation and is full of bugs, things like missing off closing brackets. It's in STD lib but old and unfortunately not well maintained.
So when I saw sith that uses a new Ruby parser simply called parser I'd hoped that would be better. Of course the issue might be with sith not parser. I think using parser is still probably the way forwards as it's more likely to get bugfixes than Ripper. It also has the opposite unparser and rewriting support, that Ripper can't do anyway.
It's a shame that the MRI parser isn't exposed, then there wouldn't be any compat problems. I think Rubinius has an API to their parser but that doesn't help other Ruby implementations.
Well, sith doesn't have any problems with parser or unparser, it is just that sith itself is not tested well (it has 3 commits :)), and sometimes generates weird ruby, that ruby interpreter can't parse. So that is why I'm saying we will have to create a bunch of PRs for this gem :) I can create something like sith-playground repo with not-working examples.
Ah well good to hear the parser foundation is solid so far. It's an exciting idea, hopefully bringing some of the magic of Crystal's macros.