Uninstall warning...
> I had GHC-4.08.1 installed in my computer (which runs under a Windows98 > platform), and then I decided to install GHC-5.00.2 (this was its latest > version at that time). It is said that GHC-5.00.2 can co-exist with other > versions of GHC under a Windows platform, because it does not use cygwin > anymore. That's true. > At this point, everything was ok. But when I uninstalled GHC-5.00.2 (in > order to install GHC-5.02), a lot of DLL files were removed from the "bin" > directory of GHC-4.08.1 (ex.: HSlang.dll). I don't have any idea why this > happened, but a lot of my programs that were compiled with GHC-4.08.1 became > impossible to run. I had to recover the DLLs from a backup... My guess is that this is because the two installations overlap and therefore confuse Add/Remove Programs, perhaps because they have the same name (which is perhaps used as a UID). > Is this a uninstall bug? > (ps: installing GHC-5.02 didn't bring my old DLLs back). Indeed, because 5.x versions of GHC don't come with DLLs. The fix is to reinstall 4.08.1 (there's a link to old versions on the GHC download page; actually, you'll get 4.08.2). ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Thread-Safety through FFI
> Is there a way of calling exported 'dynamic export' functions in a > thread-safe manner? I have this problem in JVM-Bridge... > > This is what the main thread does, from Haskell: > > 1. starts the Java VM, which starts a bunch of other threads, > including > the AWT thread; > 2. creates a pointer to a some IO function 'paint', using a 'dynamic > export' callback-maker; > 3. creates a new Java Frame (i.e. a GUI window) with the > function-pointer; > 4. repeatedly calls the Java Thread.yield function for 20 seconds. > (the program then ends) > > Now, once the Java Frame has been created, the AWT thread will > occasionally call the 'paint' method, which ends up calling the > function-pointer. However, it seems GHC 5.02 'dynamic export' > calls are > not thread-safe, and sooner or later it crashes, either with a seg > violation or a complaint about unknown closure types. If you're talking about OS threads (eg. POSIX threads), then GHC's RTS certainly isn't thread safe. It isn't safe to call foreign exported functions from more that one OS thread simultaneously. We have some partially working thread support, but it has been on the back burner for some time now. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Socket library
I just wanted to play a bit with the Socket library comming with Haskell. However, whatever I try to do, I get the following runtime error, eg in ghci: Socket> connectTo "pcsep" (PortNumber 80) *** Exception: does not exist Action: getProtocolByName Reason: no such protocol entry Seems that I am doing something wrong here? Sven Eric ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 5.02 MonadError Broke My Code
Sun, 21 Oct 2001 19:38:55 -0700, Ashley Yakeley <[EMAIL PROTECTED]> pisze:
> MonadError seems to have been redefined in 5.02 to have a fundep:
>
> 5.00.2:
>
> class (Monad m) => MonadError e m
>
> 5.02:
>
> class (Monad m) => MonadError e m | m -> e
>
> Why?
It allows some practical functions which would be awkward to write
without the fundep. For example:
data ParseError = ...
class HasParseError e where
inject :: ParseError -> e
parseInteger :: (MonadError m e, HasParseError e) => m Integer
-- This type is ambiguous without the fundep because the main part of
-- the type doesn't mention e.
You could argue that we should write this instead:
parseString :: MonadError m ParseError => String -> m ()
but this style isn't always feasible.
It would force to have a concrete error type in all places where the
error type is not directly visible in the type of the whole function.
I don't want to commit to a particular error type in generic parsing
library for example - the library only specifies properties of the
error type using classes and gives several choices for it; details
of the error type are specific to places where the library is used.
Also a constraint like 'MonadError m ParseError' which mentions
a concrete type can't be put in an instance context without
-fallow-undecidable-instances. I have an example where putting this
in an instance context is useful: there is a large set of constraints
(six) which is used in many functions, so they are packed in a subclass
with no methods which serves as a "class synonym".
> Anyway, because of GHC's naive instance overlapping checking, it broke my
> code:
>
> instance (JVMMonad m) => MonadError ThrowableRef m where
Sorry about that. A single MonadError class can't simultaneously
allow both ways of associating error types with monads.
I guess you can move 'MonadError ThrowableRef m' to superclasses of
JVMMonad and make MonadError instances for all types in this class
separately.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Socket library
> I just wanted to play a bit with the Socket library comming > with Haskell. However, whatever I try to do, I get the following > runtime error, eg in ghci: > > Socket> connectTo "pcsep" (PortNumber 80) > *** Exception: does not exist > Action: getProtocolByName > Reason: no such protocol entry > > > Seems that I am doing something wrong here? Which platform are you on? (there is a bug in 5.02's networking library which means that Socket.conncetTo might not work - but I haven't seen it produce the error that you quote above). Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Existential Typing (was Multi-parameter OOP)
On Friday 19 October 2001 11:02, George Russell wrote: > Recently I've been experimenting with a sort of OOP with GHC, [...] I find your discussion rather intriguing, but I'm not sure I fully understand what you are trying to do. Existential typing allows for what I would call "dynamic dispatch", which allows for the dynamic lookup of class members (i.e. methods). What you appear to be trying is something resembling dynamic typing. Dynamic typing can be "emulated" using dynamic dispatch. If GHC had true existential typing, as opposed to just existential datatypes, you could reasonably code what I think you want like this: class A a where basicA :: Bool nextA :: a -> (EX a'. A a' => a') basicA = True nextA = id data WrappedA = forall a. A a => WrappedA a instance A WrappedA where basicA = False nextA (WrappedA a) = a data A1 = A1 instance A A1 --... similarly for B ... class AB a b where toBool :: a -> b -> Bool instance (A a, B b) => AB a b where toBool a b | (basicA :: a) && (basicB :: b) = True | (basicA :: a) || (basicB :: b) = False | otherwise = toBool (nextA a) (nextB b) In this new setting, class AB seems a little silly. You could simply get rid of it. Of course, GHC doesn't work this way. Instead, you have to introduce a datatype "StupidA" to wrap your existential type in. For the benefit of this new stupid datatype, you'll also need to change the type of basicA from (:: Bool) to (:: a -> Bool). This datatype also introduces unnecessary overhead, as you end up having chains of StupidA constructors that do essentially nothing. You could look at my attached code if you really want to. It has been beaten throughly with an ugly stick. >From the purely denotational point of view of semantics, I love existential typing. I think this example really drives the point across that existential datatypes are not nearly as useful as existential typing. I can think of several similar situations in actual code of mine. However, using existential datatypes was overkill for the situation, and thus I opted for a different solution altogether. I don't understand all the implementation consequences of existential typing. Most importantly, how does existential typing effect the operational semantics? Mercury has existential typing, but then again, Mercury is newer and its design philosophy is far more ambitious. best, leon class A a where basicA :: a -> Bool nextA :: a -> StupidA basicA _ = True nextA a = StupidA a data StupidA = forall a . A a => StupidA a instance A StupidA where basicA (StupidA a) = basicA a nextA (StupidA a) = StupidA (nextA a) data WrappedA = forall a . A a => WrappedA a instance A WrappedA where basicA _ = False nextA (WrappedA a) = StupidA a data A1 = A1 instance A A1 class B b where basicB :: b -> Bool nextB :: b -> StupidB basicB _ = True nextB b = StupidB b data StupidB = forall b . B b => StupidB b instance B StupidB where basicB (StupidB b) = basicB b nextB (StupidB b) = StupidB (nextB b) data WrappedB = forall b . B b => WrappedB b instance B WrappedB where basicB _ = False nextB (WrappedB b) = StupidB b data B1 = B1 instance B B1 toBool :: (A a, B b) => a -> b -> Bool toBool a b | basicA a && basicB b = True | basicA a || basicB b = False | otherwise= toBool (nextA a) (nextB b) main = return ()
RE: Existential Typing (was Multi-parameter OOP)
| If GHC had true existential typing, as opposed to just | existential datatypes, | you could reasonably code what I think you want like this: | | class A a where | basicA :: Bool | nextA :: a -> (EX a'. A a' => a') | basicA = True | nextA = id Curiously enough, this thread intersects with the "higher-ranked types" thread on the Haskell list. If I do implement the Odersky/Laufer higher-ranked types inference mechanism, then I'll also allow existentials in arbitrary positions. The elimination of "stupid" existential wrapper constructors is discussed in a bit more detail in the paper Mark and I wrote recently: First class modules for Haskell http://research.microsoft.com/~simonpj/papers/first-class-modules/index. htm Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Thread-Safety through FFI
At 2001-10-24 02:52, Simon Marlow wrote: >If you're talking about OS threads (eg. POSIX threads), Yes >then GHC's RTS certainly isn't thread safe. Good. This means I know why it's crashing... >It isn't safe to call foreign exported >functions from more that one OS thread simultaneously. OK, can I call a foreign exported function from some other thread while the main thread is in 'foreign import' native code? I could have calls to the foreign exported function block until the main thread called a special foreign imported 'yield' function. The alternative is to have all Haskell in one thread, which means other threads would have to queue up calls to foreign exported functions, which would get executed by the main thread whenever it called 'yield'. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling in GHC-4.08.1
I was trying to compile a .hs file with the profiling option enabled (-prof -auto-all) but I got an error message: /usr/bin/ld: cannot find -lHSstd_p_imp collect2: ld returned 1 exit status Does anyone know what is this "-lHSstd_p_imp"? I am using GHC-4.08.1 (with Cygwin) under a Windows 98 platform. Thanks, -- Andre ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
