- Haskell-prime - Haskell.org

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 21 Feb '06

21 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 21 Feb '06

21 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

RE: proposal: standardize interface to Haskell' implementations
by Simon Peyton-Jones 20 Feb '06

20 Feb '06

| (*) a standard haskell' api providing the commands of ghci/hugs | style interactive systems would be a start, together with an | annotated AST, parser/typer/pretty printer. more detailed | specifications could be left for future revisions. Claus, A reasonable suggestion, but I'm unsure what you actually have in mind. I think that perhaps you mean that Haskell' should specify a (Haskell) library through which one can compile, load, and execute Haskell programs? Is that right? That is, you have in mind precisely the sort of thing that GHC-as-a-library tries to offer? I ask because that isn't exactly what Java reflection, for example, offers. If that is what you have in mind, then yes indeed, it would be great to have such an interface specified. But it's a big task. The data types involved are large, and there are lots of design choices. We've simplified the problem in GHC by exposing some of GHC's internal types (e.g. Type, Class, TyCon, Id etc) which have themselves evolved over time. And that's before you start asking about what interfaces are suitable for loading, renaming, typechecking, optimising etc. I, for one, would love it if you and others felt able to contribute to the Haskell-as-a-library interface (i.e. what it should look like to the client). Whether we'd be anywhere near done for Haskell' I'm less certain. There's a (GHC-specific) Wiki page for suggestions about GHC as a library, which might be good place to start. http://haskell.org/haskellwiki/GHC/As_a_library Simon

4 3

Strict Haskell debate
by Andy Gill 17 Feb '06

17 Feb '06

I'd like to see a way of enforcing return strictness, that is where you have confidence that what a function is returning is fully evaluated. Imagine a function hstrict; hstrict :: a -> a you can define hseq with this. hseq :: a -> b -> b hseq a b = hstrict a `seq` b and $!!. ($!!) :: (a -> b) -> a -> b a $!! b = a $! (hstrict b) With hstrict you can write functions in the style. fun f a b c = hstrict $ .... where ... ... and also fun f a b c = hstruct $ bla { abc = def , cfg = tts , ... } We know that strictness plays no part in the returned value after the function is finished evaluating, which is a Useful Property. What I'd like is a efficient hstrict, that does not re-evaluate anything that has already been hstrict-ified. In the same way as we evaluate an object, we could strictify an object using a similar (low-level) mechanism. So the cost of calling hstrict would be amortized away to almost nothing. How much work would this be to add hstrict GHC? A extra bit in the runtime representation? Could we use the speculation mechanism to do it? Andy Gill

2 2