Hi there,

I am self-studying compilers these days, and find it really interesting. I
would love to apply for a PhD's degree in PL, can anyone kindly give me
some suggestions for the preparation?

Best,
Tianbo

I think the best thing you can do to prepare is to search for a good
advisor. That's already a hard task in general, but in PL/compilers even
more so as there aren't that many out there.

PL is very broad, so I don't know exactly what you like, but I suggest you
start participating in an open-source project to learn how production code
is developed and to improve your own coding skills. At least the google
summer of code projects usually have mentors available to bootstrap
students.
Knowing really well how production code is developed is always a plus for
any PL researcher. Most students have no clue.

Good luck,
Nuno

-----Original Message-----
From: Tianbo Hao
Sent: Tuesday, October 18, 2022 7:53 AM
Subject: What should I prepare for a PL PhD program

I am self-studying compilers these days, and find it really interesting. I
would love to apply for a PhD's degree in PL, can anyone kindly give me some
suggestions for the preparation?

Best,
Tianbo

On Tuesday, October 18, 2022 at 8:58:41 PM UTC-7, Tianbo Hao wrote:

> I am self-studying compilers these days, and find it really interesting. I
> would love to apply for a PhD's degree in PL, can anyone kindly give me
> some suggestions for the preparation?

It seems the CMU usually has a compiler class, but not this year:

https://csd.cmu.edu/course-profiles/15-411_611-compiler-design

A compiler class used to be part of the normal CS coursework,
but it seems less common now.

PhD work is less obvious, but I suspect that CMU is one of the
more likely places to find one.

Tianbo Hao <tianboh@alumni.cmu.edu> writes:
>I am self-studying compilers these days, and find it really interesting. I
>would love to apply for a PhD's degree in PL, can anyone kindly give me
>some suggestions for the preparation?

I recommend reading proceedings of programming language and compiler
conferences, e.g., PLDI and OOPSLA. This gives you a knowledge of
current research topics, and who works on what.

And of course you should read "The researcher's bible":

https://www.research.ed.ac.uk/en/publications/the-researchers-bible

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

On 10/19/22 10:30 AM, Nuno Lopes wrote:

> PL is very broad, so I don't know exactly what you like, but I suggest you
> start participating in an open-source project to learn how production code
> is developed and to improve your own coding skills.

Open source projects often direct newbies to their to-do list. That's
the "hall of shame" with problems beyond the skills or knowledge of the
"core" developers.

DoDi

On Thu, 20 Oct 2022 11:30:40 +0200
Hans-Peter Diettrich <DrDiettrich1@netscape.net> wrote:
> On 10/19/22 10:30 AM, Nuno Lopes wrote:
>
> > PL is very broad, so I don't know exactly what you like, but I suggest you
> > start participating in an open-source project to learn how production code
> > is developed and to improve your own coding skills.
>
> Open source projects often direct newbies to their to-do list. That's
> the "hall of shame" with problems beyond the skills or knowledge of the
> "core" developers.

First , participating in an open source project doesn't mean that one waits
to be "directed". They can simply notice a bug and send a fix or add some new
functionality. Second , issues on the todo list may be stuff that core
developers don't know how to do or it may be stuff that they haven't got
around to doing. In my experience it is almost always the latter.

Spiros Bousbouras <spibou@gmail.com> schrieb:
> On Thu, 20 Oct 2022 11:30:40 +0200
> Hans-Peter Diettrich <DrDiettrich1@netscape.net> wrote:
>> On 10/19/22 10:30 AM, Nuno Lopes wrote:
>>
>> > PL is very broad, so I don't know exactly what you like, but I suggest you
>> > start participating in an open-source project to learn how production code
>> > is developed and to improve your own coding skills.
>>
>> Open source projects often direct newbies to their to-do list. That's
>> the "hall of shame" with problems beyond the skills or knowledge of the
>> "core" developers.
>
> First , participating in an open source project doesn't mean that one waits
> to be "directed". They can simply notice a bug and send a fix or add some new
> functionality. Second , issues on the todo list may be stuff that core
> developers don't know how to do or it may be stuff that they haven't got
> around to doing. In my experience it is almost always the latter.

A quote from the "Quickstart Guide to Hacking GFortran":

What kind of PR to start with

[...]

Traditionally, internal compiler errors on invalid code have been
considered relatively easy. But you may always find a hard one...

On Friday, October 21, 2022 at 4:46:28 PM UTC-7, Thomas Koenig wrote:

(snip)

> Traditionally, internal compiler errors on invalid code have been
> considered relatively easy. But you may always find a hard one...

Reminds me of the story (I never saw anyone do it) that in the early days
of compilers, they would feed cards from the card recycle bin to them.

That is, as you note, a test of (most likely) invalid code.

But now that we don't have card recycle bins, where do you get a good
selection of invalid code to test them with?
[I've seen reports where people fed strings of random bytes into various
kinds of programs to see what happened. Almost invariably they crashed.
On the other hand, I recall a story from the 1960s in which someone reported
that an IBM Fortran compiler failed on a source card that contained an
obscure hard to punch invalid special character which they happened to use
for an internal delimiter. The quite reasonable reply was "Don't do that."
-John]

gah4 <gah4@u.washington.edu> schrieb:
> On Friday, October 21, 2022 at 4:46:28 PM UTC-7, Thomas Koenig wrote:
>
> (snip)
>
>> Traditionally, internal compiler errors on invalid code have been
>> considered relatively easy. But you may always find a hard one...
>
> Reminds me of the story (I never saw anyone do it) that in the early days
> of compilers, they would feed cards from the card recycle bin to them.
>
> That is, as you note, a test of (most likely) invalid code.
>
> But now that we don't have card recycle bins, where do you get a good
> selection of invalid code to test them with?

There appears to be an art to it. At least one frequent submitter
of bug reports to gfortran has mastered, but I don't know how he
does it (and haven't asked).

An automated code generator which generates valid programs according
to the syntax and semantics rules of a langauge and then systematically
violates the rules (especially those prescribed outside the formal
grammar) one by one might be possible. Alternatively, it might
also be feasible to parse an existing code base and systematically
insert violations there.

I am not sure that research has been one on that, but it would
be interesting.
[I believe I have seen both random program generators and "fuzzers"
that make random changes to programs. This isn't just for compilers,
it's for anything that is supposed to interpret its input. -John]

On 10/22/22 10:49 AM, Thomas Koenig wrote:

> An automated code generator which generates valid programs according
> to the syntax and semantics rules of a langauge and then systematically
> violates the rules (especially those prescribed outside the formal
> grammar) one by one might be possible. Alternatively, it might
> also be feasible to parse an existing code base and systematically
> insert violations there.

Isn't it good practice to maintain a test suite at least for compilers,
that contains both selected valid and invalid code snippets?

For error reports on obviously weird input I'd prepare an equally weird
answer ;-)

DoDi

On Saturday, October 22, 2022 at 7:51:45 PM UTC-7, Hans-Peter Diettrich wrote:

(snip)

> Isn't it good practice to maintain a test suite at least for compilers,
> that contains both selected valid and invalid code snippets?

> For error reports on obviously weird input I'd prepare an equally weird
> answer ;-)

The only one I know that actually, really, did that was TeX.
There is a test program that is supposed to execute all code
except for fatal errors.

To do that, you need some type of flow analysis to figure out which
parts of the program are, and especially are not, being executed.
The figure out what to add to the input to execute those that aren't.

I don't think I am quite as good now, but in my early programming days,
I had a tendency to try out features just to try them out, and often enough
find bugs that no-one thought about before.

The only one I can remember now is using ++ in C on a double variable.
There is no rule against using it on floating point types, but it seems that
compiler writers aren't so good at testing it.
[There are certainly code coverage tools that are supposed to let you exercise
all of the code in a program. Again, not just compilers. -John]

Hans-Peter Diettrich <DrDiettrich1@netscape.net> schrieb:
> On 10/22/22 10:49 AM, Thomas Koenig wrote:
>
>> An automated code generator which generates valid programs according
>> to the syntax and semantics rules of a langauge and then systematically
>> violates the rules (especially those prescribed outside the formal
>> grammar) one by one might be possible. Alternatively, it might
>> also be feasible to parse an existing code base and systematically
>> insert violations there.
>
> Isn't it good practice to maintain a test suite at least for compilers,
> that contains both selected valid and invalid code snippets?

Very much so.

For example, gcc requires two things for a patch: There needs to
be a test case to make sure that the bug is fixed, or the added
feature keeps on working, and the submitter needs to run the
testsuite to make sure that all other tests continue to work.

This is a good approach, but it has the same basic limitations of
all testsuites: They are never complete, and they also contain
compiler-specific code and also some errors.

> For error reports on obviously weird input I'd prepare an equally weird
> answer ;-)

If you have seen enough strange bug reports, it might be equally
challenging to come up with something new as to actually fix the
bug :-)