[plt-scheme] Jane Street Summer Project 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