Google Summer of Code — Tracking for Typechecker’s Type Inference

@hborla Hi! Interested in participating in the typechecker project mentioned in the GSOC post. Some questions I have:

  • is the command line tool mentioned supposed to be implemented in Swift or C++ (or can one choose)?
  • is the output file mentioned in the second bullet supposed to be human-readable or will only be directly used by the compiler/command line tool?
  • how does the tool get its input? from the file mentioned above or via XPC from the compiler/SourceKit or both?
  • any other major knowledge/skill requirements from the compiler world (and maybe some book recommendation on that)?

Thanx in advance! :upside_down_face:

2 Likes

@GSoc-admins I also have some questions on how several parts of GSoC are implemented within Swift, particularly that I'm going to start with an already present project idea:

  • The student guide mentions that a proposal should include a section about "related work", which to me could seem a little contrived in this particular case since an official project idea is kind of by default relevant and is related to current goals (e.g. those outlined here) — so how should one write this section of the proposal? On that note, is it possible to get acquainted with the application format before the application start date?
  • What could be some examples of biography bullet points, past projects and/or achievements that would be regarded as sufficient? The knowledge of C++ and Swift is obvious, but apart from that, the aforementioned project description only mentions "familiarity with the concept" of static type checking. Should it manifest itself in that I already have implemented a type checker or a similar compiler (sub-)system in the past?
  • How does the bonding period work in particular here? I somewhat struggle to understand its purpose, since if one applies to participate in GSoC (and then get accepted with their proposal), they probably have been around in the community of interest for a certain time..?

Thank you for your attention!

Hi @wtedst, thank you for your interest in participating in GSoC with the Swift project!

is the command line tool mentioned supposed to be implemented in Swift or C++ (or can one choose)?

Up to you - I would recommend Swift :slight_smile:

is the output file mentioned in the second bullet supposed to be human-readable or will only be directly used by the compiler/command line tool?

This file doesn't need to be human readable. The purpose of this file is to capture detailed information about the solutions produced by the constraint system, and it will be consumed by the separate command line tool.

how does the tool get its input? from the file mentioned above or via XPC from the compiler/SourceKit or both?

Great question! I was imagining that the command line tool takes the type inference output file as input via stdin, but we can definitely workshop this idea. I think adding a new SourceKit request for type inference information at a particular location in a source file is a great idea, and it's something we would need anyway if we ever wanted to provide this information to an editor. If you choose the SourceKit route, you might not need the output file mentioned above.

any other major knowledge/skill requirements from the compiler world (and maybe some book recommendation on that)?

From your second set of questions it looks like you are already pretty familiar with type checking! I would recommend getting to know Swift's type inference algorithm, which is described in detail here, and the new diagnostic architecture, which you can learn about on the Swift Blog.

Additionally, if this is your first time diving into the Swift project, I highly recommend setting up/building the project and trying to step through the constraint solver. For example, try setting a breakpoint in ConstraintSystem::simplifyConstraint (in CSSimplify.cpp), compile a Swift file that contains a simple expression, and then step through the execution of the type inference algorithm. This is the best way to learn the details about the constraint solving algorithm!

Please let me know if you have any further questions!

1 Like

Hey @wtedst,

I think you can skip "related work". The most important thing to focus on your application is "Deliverables". We need to see you have a solid understanding of what needs to be done and a detailed plan to accomplish it.

Mentioning your prior experience in type checkers/compilers is definitely useful. Even if is unrelated to this specific project idea, it is useful to see what is your experience and past projects.

The "Bonding Period" is not so strictly defined but I would suggest to use that time to familiarize with the development environment for the Swift project (make sure you can build, run tests, debug, without issues), with the coding style and the guidelines for contributors. That way you would be ready to go once the coding period starts.

2 Likes

Thanks for such a detailed response! I've gone through the docs, and it definitely helped a lot that you pointed me at the simplifyConstraint method :nerd_face: — navigating such a codebase is definitely a little overwhelming at first.

I would then get myself acquainted with the system and accumulate some questions over the week and let you know the next Monday, if you don't mind? I'd also ask you if you find it appropriate that we switch to a private conversation (how would you prefer it?) due to both the somewhat competitive nature of GSoC and simply so that I don't clutter the feed with my questions? Perhaps I'll even be able to present you a proposal draft next week.

Feel free to start a private message thread with me here on the Swift Forums. I look forward to hearing your ideas!

1 Like

@akyrtzi What level of familiarity with the internals of Sema and SourceKit of the people evaluating a proposal should I assume? While there is some documentation providing a conceptual overview, it does not cover the actual architecture, so I need to know how much supporting information — and to what level of detail — I need to provide in my text.

Hi @wtedst, I would propose to keep the scope smaller and make this about a compiler tool and not using XPC/SourceKit (XPC/SourceKit will complicate the implementation without a clear idea how it would be useful beyond this specific tool). If you want to have some kind of "interactive" workflow you could create a command-line tool with a REPL interface, like the one the compiler is using.

Generally, the proposal should give us confidence that you understand the scope of the work involved, so detailing what parts of the compiler you'd modify or base your implementation on, would be goodness.

Terms of Service

Privacy Policy

Cookie Policy