On 10/10/05, Ketil Malde wrote:

Tomasz Zielonka writes:

...

Because of this long syntax and comand-line completion I've even once lost the source code. I forgot to remove the .hs at the end of line: $ ghc --make Prog -o Prog.hs

If you want, I can tell you about this great version control system I'm using :-)

It was before I acquired the habit to put even the smallest programs in darcs. And even if I did use darcs - I usually at least try to compile the new code before recording it. Anyway, this is not the biggest reason for my request. What bothers me more is typing the redundant command over and over again. Best regards Tomasz

Why don't you use a small shell script for this?

These kinds of answers are all too abundant, no offense meant. :-) There are lots of things that *can* be done already, that doesn't mean that we can't improve them! Using a shell script is a possible work-around, but certainly not *the* solution. If there is no real reason for ghc to spit out a.out files, then surely choosing the exe name from the main input file would simplify a programmer's life. And for applications that desperately want a.out, well, there's still the -o flag, right? I second Tomasz suggestion. /Niklas

On 10/10/05, Wolfgang Jeltsch wrote:

Am Montag, 10. Oktober 2005 11:55 schrieb Niklas Broberg:

...

[...]

...

Using a shell script is a possible work-around, but certainly not *the* solution. If there is no real reason for ghc to spit out a.out files, then surely choosing the exe name from the main input file would simplify a programmer's life. And for applications that desperately want a.out, well, there's still the -o flag, right?

Maybe the makers of GHC wanted GHC to be "GCC compatible".

With --make it could be more "make compatible", ie $ ghc --make Prog woud be similar to $ make Prog Also, ghc --make Prog is not "GCC compatible". Try running 'gcc Prog' when the source is in Prog.c Perhaps the new behaviour should be enabled when using Prog without the .hs suffix. Best regards Tomasz

On Tuesday 11 October 2005 18:16, Lajos Nagy wrote:

While working on a toy compiler I realized that Data.Set.Set (Set) is not an instance of the Functor class. In other words: 'fmap' is not defined on it. I tried various ways of defining an instance but I failed. The reason is quite interesting: Set is a type constructor (* -> *) so it should qualify it for being a Functor. (In a sense it is very similar to a Map or a list.) However, most Set functions require the elements of the Set to be an instance of Ord. The problem is that this constraint cannot be deduced from the instance declaration for Functor:

[...]

On the other hand, it seems intuitively natural to make Set an instance of fmap. Any ideas on how to do it?

Hi, you are not the first one to observe this. AFAIK, there is no really satisfactory solution available. The general problem is discussed and a solution (a language extension) proposed in (http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps). Cheers, Ben

Ketil Malde wrote:

Indeed. While I generally like the overloaded, qualified names, I find it annoying when, like 'map', they clash with Prelude imports. Which means that, in a module using Data.Set, I must either use it all qualified, or import it twice (qualified and hiding map), or explicitly import Prelude hiding map. (Better solutions wanted!)

I think, you should import qualified Data.Set as Set only and use "Set.map" rather than the deprecated "mapSet" (most other names from Data.Set make more sense with the "Set." prefix) Christian

Ketil Malde wrote:

the advantage of Set.map instead of mapSet?

Well, you know that the unqualified name is "map", i.e. also for Data.Map it's not mapMap or mapFM but <YourChoice>.map.

(Oh, right, I can "import qualified List as Set" -- but then I still have to change "member" to "elem" etc etc.)

I think, that was discussed when including Data.Set and Data.Map (but only isEmpty became null). Replacing the import of Set by List does not work well, but Data.Set could be easily replaced by a different Set implementation with the same (or a similar enough) interface. Christian

On 10/10/05, Stephane Bortzmeyer wrote:

On Mon, Oct 10, 2005 at 11:40:21AM +0200, Wolfgang Jeltsch wrote a message of 28 lines which said:

...

Why don't you use a small shell script for this?

Or better, a rule in the Makefile, with suffixes:

%: %.hs ghc --make -o $@ $^

How about module dependencies? You would have to handle them in the Makefile (ghc -M?). I'm not saying it's difficult, but it's enough hassle that in case of small "scripts" I would still prefer to use ghc --make directly. Best regards Tomasz