[plt-scheme] Choosing language in PLT Scheme

As another relative newcomer I'd like to tie this into the recent conversation about teachpacks, since I was and probably still am somewhat confused about the relations between the DrScheme language choice, the #lang line, teachpacks, and require. For what it's worth, where I've ended up is:

1. Always tell DrScheme to use (and tell my students to tell DrScheme to use) the module language.
2. Always use #lang scheme. (almost -- see * below)
3. Add libraries with require.
4. If someone says to use teachpack X then figure out instead how to translate that into an appropriate require form.
5. If someone says to use a different #lang line then figure out instead how to translate that into an appropriate require form.

I understand that there are reasons for other setups, but my students and I are writing code in Scheme (not some other language), we don't want to be limited to a subset of the language, we want the code to run on different machines without relying on application configuration, and we might want to use multiple libraries which, as far as I know (although I'm not sure), can't always be combined into a single #lang line (and you can't have more than one). I would imagine that some others looking for a Scheme environment and finding PLT will have a similar set of requirements.

If I'm wrong about any of the above then I'd love to be corrected. * Actually I think I can't actually always use #lang scheme because I've had to use #lang scheme/load for some projects and I don't think there's a way to get around that with a require form... Is that true? And I'm guessing that there are other #lang lines that can't be turned into a require form, but for some (like gui) that seem just to be alternative ways to include a library (am I right about this?) I think one can use a require form instead.

Anyway, I think it might be nice for the docs to present this approach or at least this set of issues explicitly in one place where newcomers will see it, since the multiple options for including libraries can be confusing. I do know that some of this is already in some places in the docs, but it took me a while to find the pieces that I've found. It would also be nice if any places in the docs that refer to teachpacks or library-related #lang lines provided the equivalent require forms explicitly.

Please take this a constructive (I hope) suggestion -- I'm enjoying PLT very much and getting a lot out of it (as are my students).

 -Lee



On Jan 19, 2010, at 3:49 PM, Synx wrote:

> 
> John Clements wrote:
>> (require scheme/web-server
>>         (planet foozle/mysql))
> 
> Also you'll want (planet user/package:major-version) at least. So like
> (require (planet foozle/mysql:3)). If you don't do that, then it means
> your program could break when this "foozle" character makes a new
> version of their mysql package.
> 
> In planet, major versions are allowed to change the interface and not be
> backwards compatible, but minor versions are required (by the honor
> system so caveat emptor) to have a backwards compatible interface, so
> saying (planet user/package:major-version:minor-version) is considered
> by some to be overkill, since an update will (in theory) mean you just
> have the burden of incrementing that minor-version number yourself,
> without changing any of your code. If you use a package whose maintainer
> you know is kind of flaky on that whole "backwards compatibility" thing,
> you should specify the minor version. You should also specify it if you
> go around the package's explicit interface in your own code (which is
> probably a sign you're doing it wrong).
> 
> If you specify the version number, then you can keep your programs
> working (with the old version) and incrementally change them to be
> compatible with the new version, file by file. Only danger about that is
> you might end up with a complex program using like 3 versions of the
> same package in 3 places, but at least then you know where to work on,
> and it's certainly better than having your program unpredictably crash
> or corrupt data because it made assumptions that are no longer true for
> the latest package version.
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/