February 2006 - Haskell-prime

Array interface refactoring
by Alson Kemp 23 Feb '06

23 Feb '06

We had a short discussion on the IRC channel the other day about Arrays. I advocated that we do some refactoring work and didn't meet with overwhelming disagreement, so I wanted to propose that the Arrays interfaces be refactored in Haskell'. As a Haskell new-ish-bie, the various Array interfaces seem a bit inconsistent and make learning/using arrays complicated. I *do* understand how to use arrays in Haskell, but I think that the interface could be cleaned up. Examples of current confusions: IArray and Array are dupes (obvious); listArray for IArray, but newListArray for MArrays; "!" for IArray, but readArray for MArrays. Proposal: I would propose the following for Haskell': "Array" is the interface for arrays; drop IArray; "MArray" is the interface for arrays in monads (IO, ST, etc); As much as possible, functions that operate on arrays will be the same for both Array and MArray (e.g. "!" for element access in both Array and MArray); In cases in which confusion would result from identical functions or in which it is beneficial to differentiate, functions will be minimally changed to identify the intended function type (e.g. listToArray for Array; listToMArray for MArray). Descriptive names ("toArray"; "toMArray") instead of termsOfArt ("freeze", "thaw"). --- Perhaps this e-mail could be read more generally as a request to consistencify/update the (Data) libraries in general (e.g. only use "unsafe*" if referential transparency is broken; group refs into Data.Ref.IO, Data.Ref.ST rather than Data.STRef, Data.IORef; create ListInterface Class to propogate consistently "toList" & "fromList" functions; append "_s" to functions that are stricified, "foldl_s" instead of "foldl'"; "//" performs very different functions in List and IArray). Is this possible for Haskell'? Or is this too much of a break? If it's possible, I'm happy to build a wiki page for discussion (I noticed that a short page has been started.) - Alson (A presumptuous new-ish-bie? Why yes, how did you guess?)

6 8

RE: Array interface refactoring
by Simon Peyton-Jones 22 Feb '06

22 Feb '06

| Perhaps this e-mail could be read more generally as a | request to consistencify/update the (Data) libraries | in general ... | | Is this possible for Haskell'? Or is this too much | of a break? If it's possible, I'm happy to build a | wiki page for discussion (I noticed that a short page | has been started.) Library design is certainly part of the Haskell' process, as I understand it. And the refactoring you describe sounds sensible and desirable. What it needs is someone willing to take up the cudgels and do it. Library design takes real work. Simon

3 2

The worst piece of syntax in Haskell
by Josef Svenningsson 22 Feb '06

22 Feb '06

Hi all, Quickly! How fast can you tell me which classes are defined an instantiated in the code below? > class Monad m => MonadPlus m where ... > > class Ord a => Ix a where ... > > instance Integral a => Eq (Ratio a) where ... How fast did you do it? And no, the correct answer is not Monad, Ord and Integral. It is MonadPlus, Ix and Eq. Ok, I guess you can see my point. My point is that the placement of class constraints in class definitions, instance declarations and type signatures is bad. Class constraints should *not* come first. It's hard on the eye. It makes your eyes going back and forth looking for the most important thing while trying to avoid the class constraints. Class constraints should come *after* the thing they constrain. This hit me pretty badly some time ago when I was writing a largish library full of class declarations. After a while it became unwieldy to browse through the code. It became overly difficult to find the right class definition. This is one of the things that the Clean people got right. In Clean, my examples from above would look like: > class MonadPlus m | Monad m where ... > > class Ix a | Ord a where .. > > instance Eq (Ratio a) | Integral a where ... Much better! I'm not proposing we change this though. I realise that Haskell will have to live with this bad syntax for its entire lifetime. It simply brakes too many programs to change it. And having two alternative syntaxes with the goal of eventually switching to the other would be awfully confusing. But even though I don't propose to change this I had to let it off my chest. I feel much better now. All the best, /Josef

8 13

Module System
by Georg Martius 22 Feb '06

22 Feb '06

Hello, I have some proposals for changes of the hierarchical module system as it is at the moment. Goals: - easy refactoring at Module/Package level - easier import/export of trees of modules (useful for any larger library) - relative imports/exports - deep import or export lists Notation: I use "X --> Y" to mean X is an example how it is now and Y is my proposed version. 1) Instead of writing the full name of the module in the head line it should be allowed to just use its last part e.g. module System.Posix --> module Posix The hierarchical name can be derived from the place in the filesystem. Pros: - allow much easier refactoring at package level. - reduce redundancy between file location and file content Cons: - loose location information in file itself 2) relative imports/exports: imports/exports of submodules can be specified as a relative path: module System.Posix ( module System.Posix.Env ) where import System.Posix.Env --> module Posix ( module .Env ) where import .Env or whatever syntax you prefere. Pros: - Again, easier refactoring at package level Cons: - the "." might be overseen (I expect long syntax discussions :-) ) 3) Import subtrees: import (qualified) System.Posix.* as P would to the same as import (qualified) System.Posix.Directory as P.Directory import (qualified) System.Posix.Env as P.Env import (qualified) System.Posix.DynamicLinker as P.DynamicLinker import (qualified) System.Posix.DynamicLinker.Module as P.DynamicLinker.Module .... Pros: - Much less imports - easy use of large libraries like Graphics.UI.Gtk Cons: - More modules are imported than necessary 4) Export subtrees: This proposal seems to do the same thing as 3) but on the side of the library not on the calling side. ----------------- module System ( module P.* ) where import qualified Posix.* as P ------------------ module Test where import System -- Posix.Env is in scope now The details about the qualification must be sorted out carefully, but I see no serious problem there at the moment. Pros: - Easy writing of meta-modules - avoids name clashing within submodules (e.g. Data.Map, Data.Set,... which have all insert, lookup,...) Cons: - importing side does not see, that there is a whole tree imported. Comments? Cheers, Georg

6 9

RE: Pragmas for FFI imports
by Simon Marlow 22 Feb '06

22 Feb '06

On 21 February 2006 18:14, Einar Karttunen wrote: > On 21.02 16:50, Simon Marlow wrote: >> I lost the argument for include files, but this is why libraries >> cannot currently be specified inside source files. Back in the FFI >> discussion, we didn't have Cabal, but now that we do, Cabal is the >> natural place to specify these things. > > Cabal is a good place, but does not handle very well optional > dependencies that most programs linking against the library > don't need. > >> I don't understand this - surely if you just put those two modules in >> separate packages, then everything works? Or is it that you don't >> want to do that? > > Think about a database library supporting e.g. mysql, postgresql, > sqlite and odbc. Now it needs six packages to do this: > 1) foo-common for common code that does not import any of the > implementations 2) foo-mysql (depends on 1) > 3) foo-pgsql (depends on 1) > 4) foo-sqlit (depends on 1) > 5) foo-odbc (depends on 1) > 6) foo (this has a connect function which uses any of the above, thus > depends on 1, 2, 3, 4, 5) > > I don't consider this very good design and in practise this is quite > tedious for the library writer. This is exactly what you need to do. The rationale is this: for simplicity, packages are the unit in several concepts: distribution, dependency, versioning, licensing, dynamic linking, include file dependencies, external library dependencies, and more. If we start confusing the issue by having smaller units for some of these concepts, things get even more complicated. I don't think that requiring a package distinction in order to have a distinction between external library dependencies is too onerous. Packages are supposed to be lightweight things - if it is too difficult to divide a package, then we should address that in the tools and infrastructure. (I think it is more difficult than it needs to be right now, but we have been thinking about how groups of packages should look to the Cabal user recently - see discussions on the libraries list). Cheers, Simon

2 1

RE: Array interface refactoring
by Simon Marlow 22 Feb '06

22 Feb '06

On 22 February 2006 09:48, Donald Bruce Stewart wrote: > It's not a terribly serious suggestion ;) > > I just found that using unsafeRead/Write is very important for > shootout entries (we used it a lot -- it's the only way to beat C), > but a lot uglier on the page than (the equally dangerous) peek/poke, > which get nice short names for some reason. The obvious conclusion if you follow this line of reasoning is that we should rename Foreign.* to Unsafe.Foreign.* :-) More seriously, I think the rationale here is that if we added "unsafe" to every part of the FFI that could possibly be used to shoot yourself in the foot, that would be an awful lot of "unsafe"s. Cheers, Simon

1 0

RE: Pragmas for FFI imports
by Simon Marlow 22 Feb '06

22 Feb '06

On 22 February 2006 01:33, John Meacham wrote: > On Tue, Feb 21, 2006 at 04:50:20PM -0000, Simon Marlow wrote: >> First of all, my position on this has always been (since we argued >> about this during the design of the FFI) that include files and >> libraries should be kept out of the source file and specified >> separately, since they are a part of the build infrastructure, and >> vary across platforms. >> >> I lost the argument for include files, but this is why libraries >> cannot currently be specified inside source files. Back in the FFI >> discussion, we didn't have Cabal, but now that we do, Cabal is the >> natural place to specify these things. > > the problem is that package granularity is way to big for specifying > dependencies, jhc wants all dependencies attached to each FFI import. > the reason being that it collects only the dependencies for things > that are actually used so for instance the following works: > > foreign import ccall "fcntl.h open" c_unix_open ... > foreign import ccall "win32.h OpenFile" c_win_open ... > foreign import lvm "lvmOpen" c_lvm_open ... > > > openFile = case os of > "unix" -> ... c_unix_open ... > "lvm" -> .... c_lvm_open ... > "win32" ->.. c_win_open ... > > and all the intermediate code remains platform independent. You could still break this into packages - I guess I'm not convinced by the argument that packages have too large granularity. It seems nice, even, to put the OS-specific code into separate packages in this example. Cheers, Simon

1 0

RE: proposal: standardize interface to Haskell' implementations
by Simon Marlow 22 Feb '06

22 Feb '06

On 12 February 2006 22:43, Claus Reinke wrote: > [an innocent question on ghc-users just reminded me of another > missed opportunity in previous Haskell definitions: by chosing to > ignore the very idea of implementations, they have left tool > implementors in a limbo.] > > these days, there is some momentum for providing Haskell with > various tools for refactoring, documentation, profiling, tracing, > instance generators, analyzers, pre-processors for extensions, > editor modes, interactive interfaces (textual, graphical, visual), > .. and even first ides, but all that is hampered by the lack of a > standardized interface to functionality that exists in every single > Haskell implementation: parsing, type checking, AST, (pretty > printing,) semantic information, (evaluation). > > that functionality is common to most tools, hard (and > unneccessary) work to reimplement, and almost impossible to > keep up to date, diverting precious man-power from small teams > trying to provide much needed tools. > > all we have at the moment is the haskell-src part of the libraries > Language.Haskell.{Parser,Pretty,Syntax), and some Hugs- or > GHC-specific APIs (Hugs Server API, package GHC), or other > frontends like Programatica, etc.. > > compare that with Lisp, Smalltalk, SML/NJ and the like, where > reflection support means that tool builders get a fantastic head > start by being able to reuse available implementation functionality. You don't say what you don't like about the existing Language.Haskell.* libraries - on the face of it, don't they at least fulfill the requirements for a re-usable Haskell AST, parser, and pretty-printer? That's what they were intended to be, because we recognised the importance of having this a long time ago. I'll start to answer my own question: no they don't fulfill the requirements. Not many projects *use* Language.Haskell.*. Why is that? One very good reason is that the AST isn't at all extensible, and everyone wants to extend Haskell. Even in Haddock, I couldn't use Language.Haskell.Syntax because I wanted to add annotations to the AST. Later on I wanted to add GHC extensions too. So the programmatica project started with Language.Haskell.Syntax and made it extensible (that's my understanding - please correct me if I got the history wrong). Also, we now have haskell-src-exts which is haskell-src + (some fixed set of extensions). So if you standardise the AST, I'm pretty sure it has to be extensible to be useful. It seems hard to do a good job of this: Haskell doesn't do open-ended extensible types very well, the programatica solution is neat but a little unweildy if you ask me. I'm not entirely sure why you're using the term "reflection" here - I suppose there's some overlap in that you might want to obtain the AST of the data declaration for a particular type at runtime, but mostly I think runtime reflection is separate from a reusable front-end. The Data.Generics library does a pretty good job of reflection. Standing back a little, I think this is an ideal candidate for a standardisation process independent of Haskell' - it's too big a task to squeeze into the Haskell' timeframe, and there are no dependencies that prevent it from being separately defined. It's just a library, after all. Cheers, Simon

2 1

RE: Pragmas for FFI imports
by Simon Marlow 22 Feb '06

22 Feb '06

First of all, my position on this has always been (since we argued about this during the design of the FFI) that include files and libraries should be kept out of the source file and specified separately, since they are a part of the build infrastructure, and vary across platforms. I lost the argument for include files, but this is why libraries cannot currently be specified inside source files. Back in the FFI discussion, we didn't have Cabal, but now that we do, Cabal is the natural place to specify these things. On 21 February 2006 14:13, Einar Karttunen wrote: > But it is not possible to have e.g. > Foo.Bar.MySQL (depends on -lmysql) > Foo.Bar.PgSQL (depends on -lpq) > > and with suitable optional compiler support create an executable > that depends only on those libraries that it actually uses. This > is not possible if library dependencies are per-package. Of course > compilers can still default to actually handling dependencies > on a per package level if they want without breaking anything. I don't understand this - surely if you just put those two modules in separate packages, then everything works? Or is it that you don't want to do that? Cheers, Simon

4 3

Pragmas for FFI imports
by Einar Karttunen 21 Feb '06

21 Feb '06

Hello I would like to propose two pragmas to be included in Haskell' for use with FFI. One for specifying the include file defining the foreign import (INCLUDE in ghc) and an another for defining a library that the foreign import depends on, called FFI_LIB (not implemented at the moment). These changes would not break any existing code. - Einar Karttunen

4 4