[plt-scheme] Jane Street Summer Project 2009

At Mon, 2 Feb 2009 17:27:38 +0000, Noel Welsh wrote:
> On Mon, Feb 2, 2009 at 4:59 PM, Shriram Krishnamurthi <sk at cs.brown.edu> wrote:
> >> Along similar lines, I'm uncomfortable with the idea that a programmer
> >> should click a button to create a tree of files and start editing. ... I
> >> hope we can find ways to remove directory hierarchies and other
> >> boilerplate, instead of ways to generate boilerplate automatically.
> >
> > Hear, hear.
> >
> > Scheme macros are one of the very best ways of writing boilerplate.
> > Given that, problems that require boilerplate should be turned into
> > problems on macros+modules, not into boilerplate generators.
> 
> Consider info.ss. It needs to specify certain information. I've
> written a lot of PLT Scheme packages but I can never remember what
> that information is, so I always copy an old info.ss and edit that. It
> would be useful to have a tool that generates an info.ss for me.
> Perhaps you think that info.ss is the wrong thing ("things like
> documentation or reader extension require files with the right name
> (e.g., "info.ss")") but that information has be given somehow.  Maybe
> the package installation tools search for a module written in the
> infotab language. The exact mechanism isn't particularly important.
> The point is there are a bunch of things I don't do often enough to
> remember how to do them, so it would be nice if I had a tool that did
> them for me.

I agree that a GUI facade on "info.ss" would be useful. An extension to
DrScheme might detect when an "info.ss" file is being opened (based on
the "#lang" line, perhaps) and select the GUI info editing mode.

I note that I have no objection to extensions of a programming
environment, such as DrScheme, that provide nicer editors. My only
objection is when the environment becomes the only reasonable way to
act on the code because only the environment understands "projects".

> There are other things, like coding conventions, that could be
> replaced with code. For example, Untyped code always has a file called
> base.ss that defines the exception type used by that package when the
> built-in exceptions aren't appropriate.  (See e.g.
> http://svn.untyped.com/snooze/trunk/src/base.ss or
> http://svn.untyped.com/dispatch/trunk/src/base.ss) Making a
> sufficiently configurable #project language (or whatever) to replace
> all this stuff (there are a number of conventions we use) would be a
> good project, I think.

In other words, a GUI editor for something like "#lang project" that's
analogous to a GUI editor for "#lang setup/infotab" --- agreed!


Matthew