Re: What's lacking: a good intermediate form

"Max Hailperin" <max@gustavus.edu> wrote in message
> "Tony" <tony@my.net>:
> [context: he asked for a good IR, I suggested LLVM]
>> I just realized that this is comp.compilers. (Maybe I should post in
>> comp.lang.misc, something similar to my OP). I, for anyone who hasn't
>> yet noticed, am interested in NOT writing a compiler but rather
>> developing my language concepts. (That of course is the major goal,
>> but I DO actually want to write the frontend of the compiler for my
>> language).
>
> It isn't immediately obvious why your goal includes wring a front end;


I said that would help keep an eye on the implementation complexity of
the language as it evolves (maybe I said that in another post/thread).


> if it is just so that you wind up with a working implementation of
> your language design, so that you can try things out, then I would
> suggest you might build an interpreter instead of a compiler. (See,
> for example, Essentials of Programming Languages.) But, if you really
> do want to wind up with a compiler for your language, having written
> only the front end yourself, then that is precisely the point of
> leveraging the LLVM project: they provide the back end for you. I am
> very puzzled by your emphatically stated conjunction of two facts:
>
> (1) You want to stay out of the back end.


Because the knowledge required to do that is all about various hardware
architectures. While not wanting to be oblivious to it, I certainly don't to
have to be an expert in that genre.


> (2) You reject someone else's back end that is usable on a canned,
> black-box basis.


I didn't reject LLVM. I was recently at the project website and got
the impression that their goals will not be achieved for many
years. Vaporware? Also, it would be nice to have a backend that isn't
as complex because it won't have to be for my language because it is
no where as complex as C++. LLVM would be "wasted man years", though
it would probably work. Just because I personally don't want to do the
backend doesn't mean that I wouldn't want someone to do that
specifically for my language rather than in general for all languages
or C++ (the latter of which is "a lofty goal").


> I would have thought that a ready-to-roll back end was exactly what
> you needed to avoid learning about how back ends work. (Again,
> assuming you really want to wind up with a compiler at the end, rather
> than an interpreter.)


Yes, I don't want an interpreter.


> I don't know where you got the idea that compiler design typically
> precedes language design in course structures. The immediate
> context of your post was a reply to mine, in which I had refered to
> my compiler design course. That course has a course on principles
> of programming languages as a prerequisite. And this is hardly
> unusual in at least US colleges and universities.


OK. I never noticed the language design courses, probably because I
wasn't focused on that then. I'd be interested to see a syllabus of a
few of the prerequisite courses. I like the content of the book
"Programming Language Pragmatics" by Michal Scott for a course like
that.


>
>> The LLVM project seems to be hampered by the lofty goal of being able
>> to compile every beastly-to-implement language out there (or at least
>> the most beastly one: C++). Yes? Perhaps they are the ones who like
>> doing the compiler implementation thing and couldn't care less about
>> language design whereas I am more of the opposite.
>>
>> Tony
>
> This is the third place in one posting where you've got me thoroughly
> confused. To the extent you are correct that the LLVM project tries
> to make their backend flexible enough to accommodate any language, I
> would have thought that this is precisely what a language designer
> like you would want -- because it means they are prepared to deal with
> whatever you throw at them.


At the design and development stages perhaps. But moreso than me,
other language designers who are pushing the envelope of language
design (read, academic and maybe even industry *researchers*) need
something like that. I, OTOH, am not doing anything that extreme and
would like to build something more practical and realizable in a
shorter time frame. Indeed, as I have said, most of what I need is
already in C++. The "C++ without baggage" concept has and will lead to
other departures but kept in check by knowing what the implementation
complexity cost is.


> If instead they had designed their backend to work only for their
> favorite language, then to the extent your language wasn't simliar,
> you would be forced to either not use LLVM or get to know its
> internals well enough in order to expand its scope to accommodate
> your needs, eliminating the ability to use it as a black box and
> keep out of back end issues. Or were you thinking that they would
> keep it simple by making it support only one kind of language --
> yours?


No, not *them*. In the end, I don't care how the IR gets into machine
code. But the obvious thing one may want to build with a new language
is the compiler, front and back end, for it in that new language. I
can and do go through evaluation of potential features I'd want to
implement and can dismiss many rather quickly. Mostly, I have gripes
about C++ which naturally, over the years, has led to doing more and
more "highly stylized C++" and macros to "beat C++ into submission". I
may be able to live with preprocessed C++ and probably will step on
that stone before doing a compiler. One can only do so much with a
preprocessor though. Anyway, is where I am coming from/came from more
apparent now?


> That seems a bit unrealistic, and in any case, if you really want to
> engage in language design, your current design is probably not your
> last one.


Oh surely it is. I am calling it Universal Programming Language (UPL)
just because I am so sure it will be the last programming language I
or anyone will ever have to write and it will do all things including
curing cancer, eliminating hunger and establishing world peace. :)


> If LLVM is flexible, that means it can accommodate not only your
> current design, but also the future ones you are going to try out
> (some of which may turn out to be dead ends, quickly scrapped once
> tried).


Again though, because LLVM project goals are so lofty, it may not be
available in my lifetime.


Tony

Return to the comp.compilers page.
Search the comp.compilers archives again.