November 2002 - Glasgow-haskell-users

RE: (no subject)
by Simon Marlow 04 Nov '02

04 Nov '02

> > I'd argue that -package is a global option and should stay that way. > > The only reason you might want to disable -package for certain > > modules and not others is if you want to do some tricks with module > > shadowing - and this definitely isn't supported in GHC. You should > > pass the same -package to every compilation. > > Funny, I wasn't actually thinking of hiding -package (effectively > giving it a scope) when I wrote that. AFAIC, it would be fine for > GHC to collect all the -package options from the source files it > wants to compile and then use the same superset of package options > for all of them (*). Ok, I see what you mean now. The real problem is one of modularity: you use a library which requires package P, and that requires you to add -package P to the command line for your program. You're saying it would be nicer if the library itself had some way to say that it requires package P. This isn't so good either: package P gets added to the command line behind your back, and it might cause strange problems by polluting the module namespace. Our current solution is to put the library into a package itself, and then you can express package dependencies in the package meta-data. (note that this still suffers from the module namespace pollution problem). What we plan to do, however, is for packages with hierarchical libraries to be "automatic" in the sense that you don't have to say -package P on the command line to get access to P's modules. It'll be automatically included on the import path and linked into the resulting binary if it is actually used. Hierarchical modules don't suffer from the module namespace pollution problem. > (*) I didn't want to have global supersets of options for language > extension flags, but those seem to be dynamic anyway, and often, > their effects spill over to anything wanting to use the modules that > use language extensions. language extension flags have a real effect on the source code: they essentially specify what language the source code is written in (H98, H98+FFI, H98+FFI+TH, etc.) so IMHO they really belong in the source code. Language extensions only spill over into other modules in well-defined ways: eg. you can define a MPTC in one module, and use its methods in another module, but you can't write class assertions for that class in the second module unless you turn on the appropriate extension flag. The language extension flags are really about syntax only. Cheers, Simon

1 0

RE: IOError vs. Exception vs. IOException
by Simon Peyton-Jones 04 Nov '02

04 Nov '02

| FWIW, I agree with you, and I don't have any objections to changing it | (but Simon P.J. might). I doubt I'd have an objection. Want to make a concrete proposal to the libraries list? I didn't get exactly what it was from your messages. Simon

1 0

RE: IOError vs. Exception vs. IOException
by Simon Marlow 01 Nov '02

01 Nov '02

> > Personally I'm not completely happy with the design, the > > IOError==Exception thing is a bit strange. But most of the > complication > > arises if you try to mix the two interfaces to exceptions (IO and > > Exception) - if you stick to the Exception interface then > the design is > > quite consistent. > > Well that's true in the sense that Exception and IOException come from > the Control.Exception interface and IOError comes from the Haskell 98 > Prelude+IO interface, and it's only when you use them > together that you > ask what IOError is identified with. But even without the H98 stuff, > > ioErrors :: Exception -> Maybe IOError > > should really be > > ioErrors :: Exception -> Maybe IOException Agreed. > and it's wierd that the function to throw general exceptions in the IO > monad is called ioError. When you bring in the H98 stuff, > the abuse of > the types is clear. In the Prelude, we have > > ioError :: IOError -> IO a > userError :: String -> IOError > catch :: IO a -> (IOError -> IO a) -> IO a > > but userError produces only IOExceptions, and Prelude.catch > catches only IOExceptions. userError isn't really useful when you have the full Exception interface: it's just like error but in the IO monad (ie. evaluate.error). > (Having the same type as Control.Exception.catch is a bug, > not a feature.) The only gain from identifying IOError = Exception is > that you can generalize ioError to all exceptions, despite its name. > With IOError = IOException, you would have to add to Control.Exception > > throwIO :: Exception -> IO a > > as suggested by Alastair a while ago. FWIW, I agree with you, and I don't have any objections to changing it (but Simon P.J. might). > In IO (and System.IO.Error) we have > > isAlreadyExistsError :: IOError -> Bool > ... > > ioeGetErrorString :: IOError -> String > ... > > With IOError = Exception, these functions give runtime errors > on anything > that isn't actually an IOException. There is also (in IO and > System.IO) > > try :: IO a -> IO (Either IOError a) > bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c > bracket_ :: IO a -> (a -> IO b) -> IO c -> IO c > > which again handle only IOExceptions, so there are new > versions of these > three in Control.Exception. It seems that the old bracket functions > should now never be used, unless you know the whole program > will be H98. For bracket and bracket_, I agree. For try, we've found that Exception.try is very rarely what you actually want: in general it's wrong to catch *all* exceptions unless you plan to re-throw the ones that you don't care about. So IO.try is still useful, but as you say it's equivalent to tryJust ioErrors (and the latter is more readable). > I would advocate moving them to haskell98/IO.hs, so users of the new > libraries don't have to hide them. I think that's a good idea, regardless of what we do about the rest of the interface. Cheers, Simon

1 0

RE: IOError vs. Exception vs. IOException
by Simon Marlow 01 Nov '02

01 Nov '02

> Ross Paterson <ross(a)soi.city.ac.uk> cryptically writes: > > Shouldn't IOError be identified with IOException rather > than Exception? > > I had to grovel through the code to understand what this question > means. Well, you could have grovelled through the documentation instead :-) http://www.haskell.org/ghc/docs/latest/html/base/Control.Exception.html > It seems that GHC.IOBase contains these definitions: > > type IOError = Exception > > data Exception > = ArithException ArithException > | ... > | IOException IOException > | ... > > data IOException > = IOError { > ioe_handle :: Maybe Handle, -- the handle used by > the action flagging > -- the error. > ioe_type :: IOErrorType, -- what it was. > ioe_location :: String, -- location. > ioe_descr :: String, -- error type specific > information. > ioe_filename :: Maybe FilePath -- filename the error > is related to. > } > > I think the idea is that we want code protected using catch clauses to > be safe against not just IOErrors but also all the exceptions > (division by zero, etc) that can happen. Since the type of 'catch' is > fixed by the report, we have to make IOError include all those types. It didn't always used to be this way: before GHC 5.00, IOError was what is now called IOException. We changed it so that IOError == Exception because it seems simpler this way: IO.ioError can be used to throw exceptions, and Exception.catch and IO.catch have the same type. I think there were more good reasons, but I can't remember now (the change came about when Simon P.J. was trying to describe this stuff for his "awkward squad" paper). Personally I'm not completely happy with the design, the IOError==Exception thing is a bit strange. But most of the complication arises if you try to mix the two interfaces to exceptions (IO and Exception) - if you stick to the Exception interface then the design is quite consistent. > The report deliberately specifies IOError in such a way that > additional kinds of IOError can be easily added. > > This only leaves the question of whether division by 0 is an IO error > or is a pure error. The argument is that the only thing which causes > evaluation to happen is IO - if your program doesn't interact with the > outside world, it might as well not do anything. So, in that sense, > all errors are errors triggered by performing IO. [You can disagree > with this argument if you like - the fact will remain that we'd like > Prelude.catch to catch as many exceptions as possible even if the > names of the types seem a little screwy when we do that.] You can't have Prelude.catch catch division by zero and pattern match failures (for example), because that wouldn't be Haskell 98. That's why we have Exception.catch which does catch these errors. Cheers, Simon

2 1