[plt-scheme] Jane Street Summer Project 2009

From: Sam TH (samth at ccs.neu.edu)
Date: Mon Feb 2 13:20:03 EST 2009

On Mon, Feb 2, 2009 at 11:29 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Mon, 2 Feb 2009 15:49:47 +0000, Noel Welsh wrote:
>> On Mon, Feb 2, 2009 at 12:31 AM, Grant Rettke <grettke at acm.org> wrote:
>> > A typical IDE set up might include the notion of a project, a file
>> > browser, a module browser, a class browser.
>> Of these I think the notion of a project is the most important. It
>> should include:
>>  - standard directory layout, prepopulated with standard stuff
>>  - one-click testing, building, build for planet, planet dev. link
> For my part, I've tried to avoid introducing the notion of a "project"
> into PLT Scheme tools.
> It isn't because I'm unused to the project concept. My first real
> programming experiences were using CodeWarrior on the Mac. I still
> (have to) use projects with VisualStudio. And I'm forced to use XCode
> sometimes.
> Personal taste aside, the technical problem with projects --- as
> usually implemented --- is that they are outside the programming
> language. If your project tools are missing some functionality, then
> you're either stuck doing things manually or you learn the project
> system's ad hoc extension API.
> I've instead pushed the idea that everything should be code organized
> into modules. If you want a new programming language, you don't tell
> the project manager that it should run some command-line tool on files
> that end in ".xqz". Instead, you import the "xqx" language into your
> module (perhaps via "#lang xqz"). I'm convinced that this approach is
> more systematically extensible and composable.
> That approach is potentially compatible with a notion of projects. I
> can imagine a project description that starts "#lang project" and that
> does great things. But if there are some "project description" files
> sitting around that aren't code, or if doing something with a project
> (other than editing it) requires looking at the source of the
> description (in some fixed syntax) instead of "running" the project
> description, then it will seem to me like the wrong approach.

When thinking about this, I think it's important to consider the
specific functionality that people might want from "projects".

One big use-case is project-wide refactoring.  For example, right now
the ability to rename via check-syntax arrows is limited to a single
file, because Check Syntax has no way of knowing about other potential
references to the identifier.  A "project" that knew the scope of the
identifier would be able to find the rest of the references.

A second use-case, mentioned by Noel, is project-wide testing.  This
requires the ability to find a different sort of references: the tests
for a particular bit of code (or for the whole system).  Similarly for
building, where finding the "main module" is the important bit.

So, I think the important thing to think about is how can we specify,
in our code, the scope that we intend our program to be a part of, and
where to find ancillary information like tests or build scripts or
main modules or source control repositories.

sam th
samth at ccs.neu.edu

Posted on the users mailing list.