Installers

There are quite a few Haskell compilers/interpreters, and on Windows they all want to be the default handler for .hs and .lhs files. Some Haskell tools might provide several handlers for Haskell source files, many Haskellers might want to use several Haskell tools side by side. Oh, and then there is the question of editing source files - to each their own.. This document aims to be the basis for a consensus, which all installers of Haskell tools on Windows should try to adhere to, so that all Haskell users and tools may work in harmony (amen;-).

The compilers which are committed to implementing this standard (note that this document is still in the discussion phase) are: Yhc, Hugs

User configuration

This document is concerned with two configurable aspects of installation: associating file name extensions with file types and associating file types with the handlers provided by the Haskell tools being installed. During install the user will be asked whether they want to register .hs/.lhs files to open with the tool being installed. Yes will be the default, meaning that the installer will ensure that the common file types for .lhs/.hs files will be known, and that the Haskell tool's handlers ("Open in Tool", "Edit with Tool", ..) will be available via the right-click menu for files of these types. If the user picks no, then no changes will be made to the .lhs/.hs association settings.

Installers may also offer to register one of their handlers as a default handler for these file types, but is important to realise that there are two kinds of users: first-time Haskellers just want to say yes to everything the installer offers and have it do "the right thing", whereas more experienced Haskellers will have widely different opinions about what "the right thing" is. So when you write your installer, you will have to curb your enthusiasm and, instead of just putting your own tool first, think of it as adding functionality to a whole box of Haskell tools. You may only change the default action with explicit permission from the user (i.e. a checkbox which is unchecked by default).

File types

The Haskell file types are given as .hs and .lhs. The icon used shall be the top line of this image. These icons are available in the Hugs CVS repository in Windows .ico format (where?).

The file type description for each file shall be "Haskell Source" for .hs and "Literate Haskell Source" for .lhs. It is important that installers agree on these file types. We can't help it that old installers will replace whatever is there with their own idea of a file type, effectively replacing all handlers associated with the existing file types; but it would be nice if new installers would try to copy existing handlers before replacing any existing file type association for .hs/.lhs, so that using a new installer after an older one is safe. Again, users need to have the option of avoiding any changes to the file type associations.

On a related note, MIME types for Haskell files have also been discussed in the past (see this 2002 thread and the 1999 thread it points to).

comment: while the above sounds like the right thing in principle, it seems that in practice all Haskell tools and editors check directly for file extensions or content, so there seems to be no real need for having two separate file types, and we could default to "Haskell Source"?

Actions available

The actions available for each compiler shall be:

• Open in <interpreter>

Where interpreter is an interactive environment, in the style of Hugs/GHCi/Yhe.

question: should version numbers be included (probably yes)?

If the interpreter can offer a sensible Edit action (i.e. WinHugs, but not GHCi) then there will be an additional command:

• Edit using <interpreter>

It is probably not useful to flood the right-click menu with Edit actions where each interactive Haskell system just calls out to an editor, but some Haskell tools (e.g., WinHugs) have invested some effort in finding sensible default Edit actions, so users can save time by letting the Haskell tool open the Haskell file with the editors configured (and configurable) there. Also, IDEs (e.g., Visual Haskell or Eclipse FP) might offer combined interaction and editing functionality.

• Edit with <editor>

Though not usually provided by Haskell tool installers, it is good to keep in mind that there are various programmers' editors out there, so installers should never lose existing actions associated with Haskell files, just add their own handlers.

Default action

If there is a preexisting default handler, then that must not be changed without the users consent (a checkbox during install). It doesn't matter whether that default is an older version of the tool you are installing or another tool you consider inferior to the one you provide: the user is always right!

It does make sense to offer making one of your tool's handlers the default during install, it does make sense to suggest uninstalling that old version before proceeding with the new install (after copying the user preferences), and you might be forgiven for pointing out that one of your tool's handlers would make a much more sensible default for Haskell files than the existing ones. But users need a chance to say no, and if they do, that's it.

If the user does agree to make one of your tool's handlers the default, you still need to take care that the old default handler remains available in the right-click menu (i.e. you add your tool's handlers, then switch defaults - never mess up what is already there!).

New document creation

An entry should be added to the Explorer's New menu, giving Haskell Source as an option, which will create a .hs file.

Technical implementation

Not much point in doing this section until everyone agrees on the end user behaviour!