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 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?
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.
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.
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.
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?
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 ;-)
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 ;-)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 89:44:30 |
Calls: | 9,679 |
Files: | 13,722 |
Messages: | 6,173,895 |