RE: select() failure
I have a program that is suffering a select() failure. It prints: 9 select: Bad file descriptor Fed: fatal error: select failed From looking at some RTS sources, the 9 apparently represents errno EBADF (bad file descriptor). Does that mean that my program is somehow closing one or more file descriptors between when the select() starts and when it finishes? This can arise if you do one of the operations threadWaitRead or threadWaitWrite on a file descriptor that is closed. Sigbjorn recently modified the select() code so that it wouldn't fail in such an ugly way; now it just wakes up all the threads that were doing select() in the hope that the one with a bad file descriptor in its hands will discover it some other way (the real problem is that select() doesn't tell us which file desriptors were bad/closed when it fails). Anyway, you should avoid this scenario if at all possible, since the current fall-back method of waking up all the threads could be quite expensive. Unfortunately, select() (and hence the GHC RTS) doesn't identify the bad descriptor(s). Here's where I suspect my program may be going awry. The main process creates a pipe. The process then forks. The parent closes the pipe's read descriptor immediately. The child soon goes to read from the pipe, using threadWaitRead followed by fdRead. The child process suffers the select failure shown above. So.. I take it the child shouldn't really be reading from a closed file descriptor? By the way, why shouldn't such a fatal error in the RTS raise an exception that I can catch in my program? I could then determine at least which thread in which process suffered the error. A 'fatal error' in the RTS usually means some kind of internal error which it isn't possible to recover from. Hence the term fatal :-) I've changed the wording in my copy to make it more clear that these errors are internal and normally indicate a bug. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: bug with rank n polymorphism in classes
Please say which version of GHC you are using. This program works fine with GHC 5.02.2 Simon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 22 August 2002 20:47 | To: [EMAIL PROTECTED] | Subject: bug with rank n polymorphism in classes | | | consider: | | module Foo where | | class Foo p where | foo :: p - (forall q . Foo q = q - a) - a | | instance Foo Int where | | | if you load this in to ghci, it complains: | | /home/hdaume/projects/NLP/Foo.hs:6: | Ambiguous type variable(s) `q' in the constraint `Foo q' | arising from a function with an overloaded argument type | at /home/hdaume/projects/NLP/Foo.hs:6 | Expected type: Int - (forall q1. (Foo q1) = q1 - a) - a | Inferred type: Int - (q - a) - a | In the application `GHC.Err.noMethodBindingError | /home/hdaume/projects/NLP/Foo.hs:6|Foo.foo#' | | which is a reasonable complaint, but is emiited in a rather | bizzare way. | | -- | Hal Daume III | | Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Posix.executeFile having problems with unevaluated argumnets
Sorry, I haven't got time to narrow this down to a test case, but here are what I hope are the key factors: (1) We start up applications in a child process (forked with Posix.forkProcess) by calling Posix.executeFile, wrapped in an Exception.catch handler (to detect errors). (2) Both the third (arguments) and fourth argument (environment) of Posix.executeFile are non-empty. The environment at least requires some computation, being obtained by prepending another setting to the result of Posix.getEnvironment. (3) The second argument of Posix.executeFile is True. (4) The executable of the whole compiled Haskell program is pretty big (13.6MB). This may be relevant because the problem I am about to describe developed quite suddenly yesterday afternoon, after I'd made some small changes to completely unrelated areas of the program, and the only explanation I can think of is that in some way the slightly increased size of the executable triggered the problem. What happens is that the arguments and environment are somehow garbled. This is surprising, but I have good evidence for it, obtained by putting a small proxy binary between Haskell and the environment. For example it does echo indefectible $* | mail ger [the real application] $* and although the argument should actually be -pipe, what I get mailed is my current PATH, or something of the sort. Yes I know it's hard to believe. Fortunately I have discovered a fix. If I insert the commands deepSeq (args parms) done deepSeq (env parms) done just before doing executeFile (actually they are also outside the exception handler) everything works swimmingly. deepSeq is just that helpful utility which forces full evaluation of its argument, and so this forces full evaluation of the arguments and parameters. As I have a fix, and not much spare time, I'm afraid I can't do much to fix this. But could someone eyeball the code for Posix.executeFile and see if there's something obviously wrong? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: select() failure
On Wed, 28 Aug 2002, Simon Marlow wrote: I have a program that is suffering a select() failure. It prints: 9 select: Bad file descriptor Fed: fatal error: select failed From looking at some RTS sources, the 9 apparently represents errno EBADF (bad file descriptor). Does that mean that my program is somehow closing one or more file descriptors between when the select() starts and when it finishes? This can arise if you do one of the operations threadWaitRead or threadWaitWrite on a file descriptor that is closed. Sigbjorn recently modified the select() code so that it wouldn't fail in such an ugly way; now it just wakes up all the threads that were doing select() in the hope that the one with a bad file descriptor in its hands will discover it some other way (the real problem is that select() doesn't tell us which file desriptors were bad/closed when it fails). Anyway, you should avoid this scenario if at all possible, since the current fall-back method of waking up all the threads could be quite expensive. I use `threadWaitRead` in one place and `threadWaitWrite` nowhere. I added a check before the use of `threadWaitRead` that I've not closed the file descriptor. The check never detects a closed file descriptor, yet I still get the select() failure. I'm assuming that the RTS's select() is done on the sets of file descriptors involved in current `threadWaitRead` and `threadWaitWrite` calls. Is that true? Are there other uses of select() in the RTS? Unfortunately, select() (and hence the GHC RTS) doesn't identify the bad descriptor(s). Here's where I suspect my program may be going awry. The main process creates a pipe. The process then forks. The parent closes the pipe's read descriptor immediately. The child soon goes to read from the pipe, using threadWaitRead followed by fdRead. The child process suffers the select failure shown above. So.. I take it the child shouldn't really be reading from a closed file descriptor? The file descriptor is the read end of a pipe used to send data from the parent to the child. The parent closes it because it will never use it, but only after the parent forks. So the child's copy of the file descriptor should still be open, n'est-ce pas? By the way, why shouldn't such a fatal error in the RTS raise an exception that I can catch in my program? I could then determine at least which thread in which process suffered the error. A 'fatal error' in the RTS usually means some kind of internal error which it isn't possible to recover from. Hence the term fatal :-) I've changed the wording in my copy to make it more clear that these errors are internal and normally indicate a bug. Is recovering from this error really not possible, as opposed to not likely to be useful? Dean ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GpH Mosix
Paul, The GdH implementation is currently used here, and is basically in beta-release form. If you would use it we could wrap up a and X86/Linux version for you. The GUM implementation of GpH and GdH uses very simple communication (mainly point to point, with a single barrier synchronisation, and the communication is restricted to just 3 C modules. As a result it can be readily ported to new communications libraries, e.g. MPI and CMMP (bespoke CM5 library) versions exist. Then what will Mosix provide when you can have a PVM cluster without Mosix running the same thing? Don't know a lot about Mosix, but if the PVM calls in the 3 GUM communications modules can be replaced with Mosix shared-memory routines that would give a low effort port of GUM to a Mosix cluster. I'd expect Mosix communication to be *much* faster than PVM: it's so generic that it absorbs a lot of time, e.g. probing for a message takes 2000 machine cycles. For small numers of processors a higher-performance implementation could be constructed by adapting the runtime system to effectively use the shared memory, but IIRC Simon Marlowe found there were problems with memory contention with more processors. Phil On Tue, 20 Aug 2002 21:17:28 +0800 [EMAIL PROTECTED] wrote: Speaking of GpH, I wonder how is GdH coming along? It seems that the installation instruction on http://www.cee.hw.ac.uk/~dsg/gdh/ is still incomplete... As far as I know, Mosix has nothing to do with PVM, so am I right to say that GpH still needs PVM even you use it on a Mosix cluster? Then what will Mosix provide when you can have a PVM cluster without Mosix running the same thing? Regards, .paul. On Tue, Aug 20, 2002 at 12:09:28PM +0100, Phil Trinder wrote: Murray, There are several parallel Haskell implementations: a survey of them has just appeared in Journal of Func. Prog Vols 45 (July Sept 2002). Implementations are available for o Eden http://www.mathematik.uni-marburg.de/inf/eden/ o GpH http://www.cee.hw.ac.uk/~dsg/gph/ My group works on Glasgow parallel Haskell (GpH) which extends Haskell 98 with a parallel composition combinator. As Simon said the main implemntation, GUM, buys portability using the relatively slow PVM communications library. This doesn't matter so much on distributed memory machines, and we've recently achieved some quite respectable results SunServer shared-memory machines. Simon Marlowe developed an alternative SMP implementation of GpH a couple of years ago that may be more suitable for a Mosix platform, but I'm not sure of the status of that implementation now. Phil On Mon, 19 Aug 2002 18:04:44 +0100 Simon Peyton-Jones [EMAIL PROTECTED] wrote: Hi Murray I'm catching up with my email backlog, but I didn't see a reply to your message, so I thought I'd reply. The parallel-Haskell crew are at http://www.cee.hw.ac.uk/~dsg/gph/ There's a mailing list that I'm ccing. GHC can be built to run on a shared-memory multiprocessor, but we have not built and tested that for some time. Untrue - both Eden and GpH are currently used on SunServer SMPs. GPH is aimed more at distributed-memory machines, and has quite a bit more code layered on top of GHC. Details on the GPH page above. Let me know if I can help. It'd be great to get some more parallel-Haskell stuff going. Simon | A group of us at Brooklyn College (City University of New | York) are in the latter stages of setting up a Mosix cluster | that we would like to use for research on, among other | things, parallel execution of Haskell code and run-time | optimization of both automatic and programmed parallelization. | | I would greatly appreciate hearing from anyone who can | provide advice on | an appropriate bibliography on the language implementation and past | work in this area (other than the code in the Haskell compilers and | libraries, of course), approaches, ongoing work, etc. | | Also, I would be most interested in hearing from anyone | interested in joining our effort (no problems with remote | access to the cluster by way of SSH), or making arrangements | for cooperation in research in this area, although, of | course, access to our equipment will be subject to approval | from higher authorities (however, note that I really don't | expect difficulty here, since our administration has already | shown considerable interest in supporting the project). | | Replies to the list will be read, but those who wish may mail | me directly at [EMAIL PROTECTED] | | Thanks in advance for any replies. | | Murray Gross | Adj. Lecturer, Brooklyn College, | City University of New York | | | | ___ | Haskell mailing list | [EMAIL PROTECTED]
Re: A: Evaluation order, ghc versus hugs, lazy vs. strict
Dear All, Hal's comments on the use of Evaluation Strategies for controlling strictness are substantially right, and they are used this way in Eden, a parallel Haskell. In Glasgow parallel Haskell(GpH) we use them to control parallel evaluation as well. The key reference is Algorithm + Strategy = Parallelism, Journal of Functional Programming, 8(1):23--60, January 1998. http://www.cee.hw.ac.uk/~dsg/gph/papers/ Highlights are as follows. There are three basic strategies: r0, rwhnf, rnf :: Strategy a r0 - does no evaluation, rwhnf - reduces it's argument to Weak Head Normal Form (WHNF). Hal defines this as stratWHNF), and rnf - reduces it's argument to normal form (i.e. containing no redexes). It's defined in a class similar to the Eval class Strategies can be composed, e.g. seqList applies a strategy to every element of a list: seqList :: Strategy a - Strategy [a] seqList s [] = () seqList s (x:xs) = s x 'seq' (seqList s xs) so seqList r0 :: Stratgy [a]- evaluates just the spine of a list seqList rwnf :: Strategy [a] - evaluates every element to WHNF seqList (seqList r0) :: Strategy [[a]] - evaluates just spines of every sublist in a list of lists Analogous parallel strategies, like parList, also exist. The Strategies.lhs module is distributed with GHC (since version 0.29), so simply 'import Strategies' if you want to play. HTH Phil On Fri, 23 Aug 2002 05:10:05 -0700 (PDT) Hal Daume III [EMAIL PROTECTED] wrote: I think there's more to strategies than this. They are not necessarily related to parallel programming and can be used for tuning (in the seq sense) sequential (perhaps non-parallel would be a better word) programs. The type of strategies is: type Strategy a = a - () for example, a strategy which reduces its argument to weak head normal form could be given by: stratWHNF x = x `seq` () We define a funciton 'using' which uses strategies to do a computation: v `using` s = s x `seq` x These are used in parallel programming something like: fib 0 = 1 fib 1 = 1 fib n = a + b `using` strategy where a = fib (n-1) b = fib (n-2) strategy result = a `par` b `par` result This clearly separates the computation a+b from the way it is evaluated a in parallel to b in parallel to the result (i.e., a+b). But this can of course be used for sequential programming, too, simply by using seq instead of par in the above example. This enables you to write clean code (your functions stay the same, except they are appended with `using` strategy), but you can control more precisely when things get reduced. - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On 23 Aug 2002, Ketil Z. Malde wrote: Jan Kybic [EMAIL PROTECTED] writes: What are GUM and Strategies? Could you provide any links? http://www.cee.hw.ac.uk/~dsg/gph/docs/Gentle-GPH/sec-gph.html GUM is an implementation of GPH (a parallel Haskell) that runs on top of PVM. Strategies are about making sure parallel threads actually do the work they're intended to before returning control to the main thread; in other words, ensuring sufficient strictness. Or something like that. Grain of salt as applicable, I'm not using any of this yet. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: [EMAIL PROTECTED] Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ambiguous type variables in existential classes
Hal I don't quite understand the intuitions behind your program, but the bug is easy enough: | instance (Eq e, Foo p) = Foo (Wrap p) where | foo (Bar p) e q = foo p e q This instance declaration is guaranteed to give problems if it is ever used, and GHC should probably bleat about it. Suppose you have the constraint Foo (Wrap T) where T is some type. Using the instance declaration we can simplify this to the constraints Eq e Foo T where e is a fresh type variable. But we are never going to learn any thing more about 'e', and so it is correctly reported as ambiguous. It's like writing reverse :: Eq x = [a] - [a] Any call to this 'reverse' will give a constraint (Eq x) that is ambiguous. Really, GHC should reject the instance declaration. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ugliness with state parameter in ST stuff
I don't know what you are trying to do, but I do know why your program is rejected. The *whole point* of a value of type (STArray s Int Int) is that it can only be read by a state thread with the same type parameter 's' as the array. Given your decls class Foo a where foo :: a - IO Int data Bar s = Bar (STArray s Int Int) instance Foo (Bar s) where ... it is absolutely right that you are going to fail. To implement the instance decl, you need to make foo :: forall s. Bar s - IO Int But you can read an STArray parameterised by an *arbitrary* state type s using the IO monad! Of course not! There is even a theorem in 'State in Haskell' that makes just this point: separate state threads really are separate, and you can't read a reference from one in another. No, no, no! Simon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 06 August 2002 19:20 | To: Haskell Mailing List | Subject: ugliness with state parameter in ST stuff | | | Sorry for the flood of emails this morning, but I've got | something which has really got me scratching my head. | | Suppose I have a class: | | class Foo a where | foo :: a - IO Int | | and a datatype with a single function: | | data Bar s = Bar (STArray s Int Int) | | getFirst :: Bar s - ST s Int | getFirst (Bar arr) = readArray arr 0 | | Now, I want to make (Bar s) and instance of Foo. But I can't | seem to do this. If I use: | | instance Foo (Bar s) where | foo = stToIO . getFirst | | GHC complains: | | Cannot unify the type-signature variable `s' | with the type `RealWorld' | Expected type: Bar s - IO Int | Inferred type: Bar RealWorld - IO Int | In the expression: stToIO . getFirst | In the definition of `foo': stToIO . getFirst | | and if I use: | | instance Foo (Bar s) where | foo = return . runST . getFirst | | GHC complains: | | Inferred type is less polymorphic than expected | Quantified type variable `s' escapes | Expected type: ST s a - c | Inferred type: (forall s1. ST s1 a) - a | In the first argument of `(.)', namely `runST' | In the second argument of `(.)', namely `runST . getFirst' | | Is there no way to do this? I can change the definition of Foo to: | | class Foo2 a where | foo2 :: (forall s . a s) - IO Int | | I can define: | | instance Foo2 Bar where | foo2 = stToIO . getFirst | | Which I suppose works, but the problem is that in real life, | Foo is Binary and I can't really change it. | | Suggestions? (Other than simply moving all my ST stuff over to the IO | monad?) | | - Hal | | -- | Hal Daume III | | Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume | | ___ | Haskell mailing list | [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: difference between (evaluate . runST) and stToIO
They aren't identical. runST guarantees to run a complete state thread that can't interact with any other. stToIO runs some imperative actions that might interact with other stToIO calls. You might find it helpful to read 'State in Haskell' if you havn't already done so. Simon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 06 August 2002 18:55 | To: Haskell Mailing List | Subject: difference between (evaluate . runST) and stToIO | | | I can't seem to figure out what the difference is between using | | evaluate (runST action) | | and | | stToIO action | | when in the IO monad and running something in ST...they seem | to behave identically...are they? | | If they are, why do they have different type signatures (one | is ST RealWorld a - IO a, while the other is (forall s. ST s | a) - IO a)? | | - Hal | | -- | Hal Daume III | | Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume | | ___ | Haskell mailing list | [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GHC bug,or Hugs feature?
There are two things going on.
1. Hugs deals with mutual recursion in a more sophisticated
way than GHC. Mark T is absolutely right, and the THIH paper explains.
2. Furthermore,GHC implements the H98 requirement that the context of
all functions in a mutually recursive groups must be the same. So
f :: Eq a = ...
g :: Ord a = ...
is illegal if f and g are mutually recursive.
Both these things arise from the way GHC translates mutually recursive
overloaded defns. Consider
f :: Ord a = a - a - a
f x y = ...(x==y)...(xy)...(f y x)...
GHC translates it thus:
f ord_dict = let gr = select_gr ord_dict
eq_dict = select_eq ord_dict
eq = select_eq eq_dict
fm x y = ...(eq x y)...(ord x y) ...(fm y x)...
in
fm
Note that all the dictionary selection (and sometimes construction)
is done outside the loop, implemented by 'fm'.
Matters get more complicated when there is mutual recursion; suffice it
it say
that in order to pull the dictionary manipuation outside the loop, all
the contexts
must be the same.
Arguably, H98 and GHC are wrong, and the restrictions should be lifted.
GHC usually errs on the side of lifting restrictions (with
-fglasgow-exts) but on
this occasion the benefit seemed slight, while it turns out that the
cost of
changing the way let/where is dealt with is not inconsiderable. So I've
let
sleeping dogs lie.
I think it's a corner case that seldom matters. Counter examples to
this
claim would be interesting. At least I hope this explains what's
happening.
Simon
| -Original Message-
| From: Mark Tullsen [mailto:[EMAIL PROTECTED]]
| Sent: 09 August 2002 20:31
| To: [EMAIL PROTECTED]
| Cc: Arthur Baars
| Subject: Re: GHC bug,or Hugs feature?
|
|
| I believe the incompatibilities are explained thus:
|
| In section 4.5.1 of the Haskell Report it only states that
|A dependency analysis transformation is first performed
| to increase
| polymorphism
|
| But hugs appears to be using a more refined version of the
| dependency
| analysis as explained in section 11.6.3 of Mark Jones' paper Typing
| Haskell in Haskell. Read that section.
|
| - Mark
|
|
| Arthur Baars wrote:
| In Mark Jones' paper Typing Haskell in Haskell, I found the
| following
| example(in the section on binding-groups):
|
| f :: Eq a = a - Bool
| f x = x==x || g True
| g y = y=y || f True
|
| According to the paper the inferred type of g should be:
| g::Ord a =
| a - Bool
|
| Hugs infers this type but GHC infers the following
| *ambiguous* type:
| *Main :i g
| -- g is a variable, defined at Test.hs:25
| g :: forall a. (Eq a) = Bool - Bool
|
| When adding an explicit type signature for g, Hugs happily
| accepts the
| code, but GHC gives the following error:
|
| f :: Eq a = a - Bool
| f x = x==x || g True
| g :: Ord a = a - Bool
| g y = y=y || f True
|
| Test.hs:24:
| Couldn't match `{Ord a}' against `{Eq a1}'
| When matching the contexts of the signatures for
|g :: forall a. (Ord a) = a - Bool
|f :: forall a. (Eq a) = a - Bool
| The signature contexts in a mutually recursive group
| should all be
| identical
| When generalising the type(s) for g, f
| Failed, modules loaded: none.
|
| I think the problems are caused by differences in the binding group
| analysis in Hugs and GHC.
|
| Malcolm, could you check what NHC says about the examples above?
|
| Cheers,
| Arthur
|
| ___
| Haskell mailing list
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
|
|
|
| ___
| Haskell mailing list
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
|
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: GpH Mosix
On Wed, Aug 28, 2002 at 10:46:34AM +0100, Phil Trinder wrote: Paul, The GdH implementation is currently used here, and is basically in beta-release form. If you would use it we could wrap up a and X86/Linux version for you. That will be very sweet! I'd love to play with this thing ;-) Please post the link when it is ready. ... Don't know a lot about Mosix, but if the PVM calls in the 3 GUM communications modules can be replaced with Mosix shared-memory routines that would give a low effort port of GUM to a Mosix cluster. I'd expect Mosix communication to be *much* faster than PVM: it's so generic that it absorbs a lot of time, e.g. probing for a message takes 2000 machine cycles. That would be indeed a very good research field to work on, I guess Murray's group will be interested to pick it up from here. Though we are also experimenting some GpH stuff in a our company, we do not have the required research force or skill (yet). Regards, .paul. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
SAS'02 Call for Participation -- Early Registration: * September 3 *
[ Please Distribute -- Apologies for Receiving Multiple Copies ] [ CALL FOR PARTICIPATION: Early Registration Extended: * September 3 * ] [ EU funded student grants available ] -- CALL FOR PARTICIPATION SAS'02 The 9th International Static Analysis Symposium Madrid, Spain 17 - 20 September 2002 -- On-line Registration and Hotel Reservations: http://clip.dia.fi.upm.es/SAS02/ Early registration date is ** September 3, 2002 ** -- SAS'02 is Organized by: Department of Computer Science, Technical University of Madrid -- The Ninth International Static Analysis Symposium (SAS'02) will be held at the Technical University of Madrid (UPM), co-located with Logic-based Program Development and Transformation (LOPSTR'02), the APPIA-GULP-PRODE Joint Conference on Declarative Programming (AGP'02), and a number of workshops. Static Analysis is increasingly recognized as a fundamental tool for high performance implementations and verification systems of high-level programming languages. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical, and application advances in the area. Invited Talks include: Static Program Analysis via 3-Valued Logic Thomas Reps, University of Wisconsin Open Modeling in Multi-stakeholder Distributed Systems: Research and Tool Challenges Robert J. Hall, ATT Labs Research An Algebraic Approach to the Static Analysis of Concurrent Software Javier Esparza, University of Edinburgh Secrets of Software Model Checking Thomas Ball, Microsoft Research Accepted papers: Static Analysis of the Numerical Stability of Loops Martel Matthieu Modular Control Flow Analysis for Libraries Christian Probst On termination of programs with real numbers computations Alexander Serebrenik and Danny De Schreye Polynomial Constants are Decidable Markus Müller-Olm and Helmut Seidl Normalizable Horn clauses, Strongly Recognizable Relations and Spi Flemming Nielson, Hanne Riis Nielson, and Helmut Seidl Detecting Optimal Termination Conditions of Logic Programs Fred Mesnard, Etienne Payet, and Ulrich Neumerkel Representing and approximating transfer functions in Abstract Interpretation of hetereogeneous datatypes Bertrand Jeannet Improving the Precision of Equality-Based Dataflow Analyses Erik Ruf From Secrecy to Authenticity in Security Protocols Bruno Blanchet Checking Safety Properties of Behavioral VHDL Descriptions by Abstract Interpretation Charles Hymans Refinement of LTL Formulas for Abstract Model Checking Maria del Mar Gallardo, Pedro Merino, and Ernesto Pimentel Making Abstract Model Checking Strongly Preserving Francesco Ranzato and Francesco Tapparo Static Confidentiality Enforcement for Distributed Programs Andrei Sabelfeld and Heiko Mantel More Precise Yet Efficient Type Inference for Logic Programs Claudio Vaucheret and Francisco Bueno A Few Graph-Based Relational Numerical Abstract Domains Antoine Mine' Pipeline Modeling for Timing Analysis Marc Langenbach, Stephan Thesing, and Reinhold Heckmann Compactly Representing First-Order Structures for Static Analysis R. Manevich, G.Ramalingam, J. Field, D. Goyal, and M. Sagiv Semantics for Abstract Interpretation-Based Static Analyzes of Temporal Properties Damien Masse States vs. Traces in Model Checking by Abstract Interpretation Roberto Giacobazzi and Francesco Ranzato Speeding Up Dataflow Analysis Using Flow-Insensitive Pointer Analysis Stephen Adams, Thomas Ball, Manuvir Das, Sorin Lerner, Sriram K. Rajamani, Mark Seigle, and Westley Weimer Analysing Approximate Confinement under Uniform Attacks Alessandra Di Pierro, Chris Hankin, and Herbert Wiklicky Reuse of results in termination analysis of typed logic programs Maurice Bruynooghe, Michael Codish, Samir Genaim, and Wim Vanhoof Backward Type Inference Generalises Type Checking Lunjin Lu and Andy King Security Typings by Abstract Interpretation Mirko Zanotti Possibly Not Closed Convex Polyhedra and the Parma Polyhedra Library R. Bagnara, E. Ricci, E. Zaffanella, and P. M. Hill Reliable Optimization for Imperative Languages: Proving Nullspace Properties of Compilers Todd L. Veldhuizen and Andrew Lumsdaine Representation Analysis for Coercion Placement Karl-Filip Faxen Ensuring Termination of Offline Partial Evaluation in Polynomial Time (A New Finiteness Analysis) Chin Soon Lee Automated Verification of
Welcome to Floralplanet.com- thanks for stopping By!
Floralplanet.com http://www.floralplanet.com Visit Earth's Largest Garden and see theInternets mostspectacular one-stop superstore for fresh flowers, silks, gift baskets,batiks, art, and other exciting gifts !!Visit Planet Bouquets !Now at a Galaxy near You !http://www.floralplanet.com/planetbouquets1.htm Visit Planet Gift Baskets !http://www.floralplanet.com/giftbaskets1.htm Visit the Planet Gallery !http://www.floralplanet.com/planetgallery.html Visit Planet Rainforest !http://www.floralplanet.com/planetrainforest.htm Visit Planet Reef !http://www.floralplanet.com/planetreef.htm A Planet Wish for You !http://www.floralplanet.com/planetwishes.htmSeptember 11th Tributehttp://www.floralplanet.com/usatributepage1.htm RegisterNoW! for ExclusiveMembership and automatically enter Planet Sweepstakes !http://www.floralplanet.com/registration1.htmThanks for stopping by our garden ! Bryan S. TartusCEOFloralplanet.comhttp://www.floralplanet.comTo Unsubscribe Please Click Reply and Type Unsubscribe in SubjectSorry if we have caused any inconvienence. Peace on Earth. Floralplanet.com - US Trademark 2002All Rights ReservedEarth's Largest Garden- US Trademark 2002All Rights Reserved
RE: Question aboutthe use of an inner forall
No, this is a bug, thank you. Will fix. Simon | -Original Message- | From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] | Sent: 19 August 2002 11:31 | To: Jay Cox; Haskell Cafe List | Subject: Re: Question aboutthe use of an inner forall | | | At 2002-08-18 20:19, Jay Cox wrote: | | #ST runST (newSTRef (3::Prelude.Int)) | # | #Ambiguous type variable(s) `a' in the constraint `PrelShow.Show a' | #arising from use of `PrelIO.print' at No locn #In a 'do' | expression | pattern binding: PrelIO.print it | | I don't understand this either, actually: | | $ ghci -fglasgow-exts -package lang | ___ ___ _ | / _ \ /\ /\/ __(_) |/ /_\// /_/ / / | | GHC Interactive, version 5.04, | for Haskell | 98. | / /_\\/ __ / /___| | http://www.haskell.org/ghc/ | \/\/ /_/\/|_| Type :? for help. | | Loading package base ... linking ... done. | Loading package haskell98 ... linking ... done. | Loading package lang ... linking ... done. | Prelude :module ST | Prelude ST :type runST | | Inferred type is less polymorphic than expected | Quantified type variable `s' escapes | Expected type: ST s a - t | Inferred type: (forall s1. ST s1 a) - a | Prelude ST | | What's up with that? Can't I even look at the type? Is this the | monomorphism restriction or something? | | -- | Ashley Yakeley, Seattle WA | | ___ | Haskell-Cafe mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell-cafe | ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
