Let's stop parser Hell

[David Piepgrass]

>> Yeah, with a tree-transforming parser, I imagine the same 
>> thing, except
>> my current [fantasy] is to convert a certain subset of D to 
>> multiple other
>> languages automatically. Then I could write libraries that can 
>> easily be
>> used by an astonishingly large audience. I certainly would 
>> like to see D
>> targetting Android, but that's best done directly from D to 
>> ARM.
>>
> That does sound very cool.  Possibly difficult though, due to 
> having to cater to the lowest-common-denominator in all of your 
> API designs.  No templated functions or ranges in your API, 
> that's for sure.  I'm sure there are some things where this is 
> very doable though; it probably depends on what kind of 
> libraries you are writing.

Well, for templates, in general, it would be necessary to 
instantiate a particular set of templates and explicitly give 
them names in the target language. So for instance, I could 
define a Point!T struct in D, sure, but then I'd have to tell the 
language converter to create target-language specializations: in 
C#, PointD=Point!double, PointI=Point!int, etc. If the target 
were C++, the template could be translated to a C++ template, 
Point<T>, as long as there aren't any "static ifs" or other 
things that can't be translated. Notably, if a template P!T 
depends on another template Q!T, then P!T cannot be translated to 
a C++/C# P<T> unless Q!T was also translated as Q<T>.

Adapting standard libraries could no doubt be a gigantic problem. 
I don't know how to begin to think about doing that.

But for ranges in particular, I think the concept is too 
important to leave out of public interfaces. So I'd port the 
major range data structures to the target languages, most likely 
by hand, so that they could be used by converted code.

> As for D targeting Android, my intent is really to target X 
> where X is any CPU/OS combo you can think of.  I want to be 
> able to get D, the language, not necessarily phobos or other 
> niceties, to work on any platform, and to do so without much 
> work.  Cross-compiling to a new platform that has never been 
> cross-compiled before should require zero coding.

I understand. Conversion to C is an effective last resort. And, 
well, I hear a lot of compilers have even used it as a standard 
practice. I guess you'd be stuck with refcounting, though.

> I think that the D-directly-to-ARM is the current approach for 
> cross-compiling.  I critique it for its underwhelming lack of 
> results.

Yeah. I assume it involves weird object-file formats, calling 
conventions and ABIs. I guess very few want to get involved with 
that stuff, and very few have the slightest clue where to begin, 
myself included.

> (2) suffer from integration problems if you try to compile the 
> expressions in separate files before compiling the rest of the 
> front-end.

Absolutely, I love language-integrated metaprogramming. Without 
it you end up with complicated build environments, and I hate 
those, cuz there isn't a single standard build environment that 
everybody likes. I think people should be able to just load up 
their favorite IDE and add all source files to the project and It 
Just Works. Or on the command line, do dmd *.d or whatever. Oh, 
and the ability to run the same code at meta-compile-time, 
compile-time and run-time, also priceless.