winhugs window disappears

Hello

I have used hugs98 with the winhugs gui for a couple of weeks with no problem.
Suddenly, every time i try to run it, the window flashes briefly and disappears.
Running hugs.exe from a command line still works.
I tried uninstalling/rebooting/reinstalling, to no avail.
My system is windows xp.
Any ideas?

Thanks

Moti

Prof. Moti Ben-Ari
Department of Science Teaching, Weizmann Institute of Science
   and 
Department of Computer Science
University of Joensuu
PO Box 111, FIN-80101 Joensuu, Finland
Tel: +358-13-251-7951, Fax: -7955
mailto:moti.ben-ari <at> cs.joensuu.fi
http://cs.joensuu.fi/~moti

REMINDER - HC&A Report (November edition)

As you may have noticed, the deadline for the next edition
of our report passed last Thursday. Yet I still don't have
received an update for the Hugs section. 

Given your ongoing efforts, and the recent activity around
preparing a new release, I consider this as a serious bug! 
Unless fixed urgently, it would leave a disappointing gap
in the report..

I'm currently in the process of editing the parts of the
report together, so if one of our Hugs Heros (tm) could send
me an update as soon as possible, it could still go in.

Thanks,
Claus

Does SOE run on Unix?

Several of the programs in Paul Hudak's Haskell text will run under 
Windows, but fail with Solaris or Linux because Win32Misc isn't 
available.  It looks like only timeGetTime is imported from Win32Mics.  
Is this an oversight with a simple fix?  Has anybody done the fix?  Or 
is this just the tip of the iceberg with a hopeless mess just out of 
sight?

Thanks for any help,

Warren

ambiguous occurrences (in RC1)

Hugs accepts the following:

	module A
	where x = 1

	module B where
	import A
	x = 'a'
	y = x

but the reference to x in B is ambiguous.

Re: Does SOE run on Unix?

> Several of the programs in Paul Hudak's Haskell text will run under
> Windows, but fail with Solaris or Linux because Win32Misc isn't
> available.  It looks like only timeGetTime is imported from
> Win32Mics.  Is this an oversight with a simple fix?  Has anybody
> done the fix?  Or is this just the tip of the iceberg with a
> hopeless mess just out of sight?

All the examples in SOE run on Unix.

When I ported HGL/SOE to Unix, I ran into exactly this problem and
provided the following shim to get round it:

  module Win32Misc( timeGetTime ) where
  import GraphicsCore( getTime )
  import Word( Word32 )

  timeGetTime :: IO Word32
  timeGetTime = do
    t <- getTime
    return $ fromInteger (t `mod` 1000000000)

The story is that if you want to write clean-looking code, you'll use 

  GraphicsCore.getTime :: IO Integer

but if you're working your way through the SOE book, you can use Win32Misc
which is available as part of the HGL distribution.

--

"Could not unambiguously deduce"..

I'm not actually sure whether this is a bug, but if it isn't, 
could someone please enlighten me about what is going on?-)

[the following is a simplified version of a problem with instances
 generated by Drift, for Strafunksi, where T would be the Drift
 target, C would be Term, and expl(ode) would return TermRep] 

------------

{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances #-}

module Main where

data T a = D [a]

class C t where
   expl :: t -> String
   expl x = "default"

instance        C String where expl s = "String"
instance C a => C [a]    where expl l = "[a]"

instance (C a {- ,C [a] -} ) => C (T a) where
    expl (D xs) = expl xs

main = putStrLn $ expl "hi"

------------

RE: "Could not unambiguously deduce"..

| What I don't understand, however, is why adding that extra
| constraint helps in any way? Shouldn't the addition of new
| things in the context only make more options available? Why
| does it make some of the existing, amgibuous options go away?

With the extra constraint, the instance decl can build a C (T a)
dictionary from
a (C a, C [a]) dictionary, by choosing the expl method from the C [a]
dictionary it is passed (ignoring the C a one).  That defers the choice
of which of the overlapping instance decls we are going to use.  Perhaps
it'll be postponed to a point at which 'a' is known, in which case the
choice is easy.  The point is that we don't want to have to choose
between the C String and C [a] instance decls until we know enough about
'a' to choose the right one.

Simon

| data T a = D [a]
| 
| class C t where
|    expl :: t -> String
|    expl x = "default"
| 
| instance        C String where expl s = "String"
| instance C a => C [a]    where expl l = "[a]"
| 
| instance (C a {- ,C [a] -} ) => C (T a) where
|     expl (D xs) = expl xs
| 
| main = putStrLn $ expl "hi"

Re: "Could not unambiguously deduce"..

> | What I don't understand, however, is why adding that extra
> | constraint helps in any way? Shouldn't the addition of new
> | things in the context only make more options available? Why
> | does it make some of the existing, amgibuous options go away?
> 
> With the extra constraint, the instance decl can build a C (T a)
> dictionary from a (C a, C [a]) dictionary, by choosing the expl
> method from the C [a] dictionary it is passed (ignoring the C a
> one).  That defers the choice of which of the overlapping instance
> decls we are going to use.  Perhaps it'll be postponed to a point
> at which 'a' is known, in which case the choice is easy.  The
> point is that we don't want to have to choose between the C String
> and C [a] instance decls until we know enough about 'a' to choose
> the right one.

Yes, but isn't that an implementation problem surfacing at the
language level? All the dictionaries needed to delay the decision to
the point of use could also be made available when compiling the
original program, no? After all, that's the reason why there's an
ambiguity in the first place. 

Not to mention that in the case for which there is an overlap, the
String instance will always be chosen as the more specific one..

Claus

> | data T a ý [a]
> | 
> | class C t where
> |    expl :: t -> String

RE: "Could not unambiguously deduce"..

| Yes, but isn't that an implementation problem surfacing at the
| language level? All the dictionaries needed to delay the decision to
| the point of use could also be made available when compiling the
| original program, no? After all, that's the reason why there's an
| ambiguity in the first place.

No, it's not.   It's tricky to understand and tricky to explain.  I'll have one more go.

Consider just this:

| > | class C t where
| > |    expl :: t -> String
| > |    expl x "default"
| > |
| > | instance           C String where expl s = "String"
| > | instance C a => C [a]    where expl l = "[a]"

Now try this:

	f :: C a => [a] -> String
	f xs = expl xs ++ "\n"

	foo1 = f "wig"
	foo2 = expl "wig" ++ "\n"

	baz1 = f [True]
	baz2 = expl [True] ++ "\n"

I think we'll agree that foo2 should return "String\n" and baz2 should return "[a]\n".]
But what about foo1 and baz1?  Both execute the code for 'f'.  What does f do?  It needs a dictionary for C[a] to

Help me!!!!