3 ms·
The question I would have is more: what is the value-added of your own compiler here? Could the same think be done with some C++ operator overloading, and a tem
by Joky 11y ago
The question I would have is more: what is the value-added of your own compiler here? Could the same think be done with some C++ operator overloading, and a template library, and the runtime?
- eslaught 11y agoRegent actually sits on top of a C++ runtime library called Legion[1] that supports very similar abstractions (tasks, regions, dynamic discover of dependencies, etc.). Unlike most runtime libraries, Legion was intended from the beginning as both a compilation target, and as something users could write to directly. So we do actually have experience building it both ways. The advantage that Regent has over a C++ library like Legion is that the language can embody the abstractions we want to provide. With C++, there is always an impedance mismatch between how we want people to think about programming, and what C++ forces us to do. C++ code is more verbose, and the C++ type system doesn't capture all the invariants that the programming model requires. Regent code is also a lot more amenable to static analysis. In Legion, if the system needs to know some property of the program, the user needs to supply that information. (And we're forced to trust whatever the user says---there's no reasonable way to statically analyze arbitrary C++ to validate what they've given us. At best, we can check those properties at runtime, but that isn't always feasible either.) In Regent, many of these sorts of things can be analyzed automatically, reducing the number of moving parts users have to think about. This is only possible because we've thought very carefully about what abstractions we need in the language---the type system is already on the edge of what is decidable, so adding anything more would make analysis intractable. To be sure, C++ has its advantages too. Some users will simply never accept a new language. So, that's why we're doing both. And for those who prefer to stick with C++, that's always going to be an option. [1]: http://legion.stanford.edu/ http://legion.stanford.edu/
- Joky 11y agoThanks for the answer. I'm familiar with the "Impedance mismatch" that EDSL have in C++. If done right, it can be very limited. For example, I like what they did with NT2 (for Matlab programmer): https://www.lri.fr/~falcou/nt2/tutorial/matlab/first_example.html https://www.lri.fr/~falcou/nt2/tutorial/matlab/first_example... . But it is not always possible, depending on the paradigm. I agree that static analyses and invariant enforcement/extraction is a good reason to have a new language (I think most of the time you have to "get around" with "convention" when using C++ EDSL).
- elcritch 11y agoIt's great to see a hybrid approach. Modern compilers seem to be much easier to build but still hard to get widely used. A cursory look at the language reminded me of JavaScript. How are you doing your static analysis from this syntax? I'm working on a visualization project and particularly interested in visualizing the data flow aspects of imperative languages, so it'd be interesting to hear how you're typing data flows in reagent. Especially since it sounds like you're targeting ports from imperative languages. Also, do you think the type system / syntax could be implemented in something like Julia by a combination of macros and types?