Re: there isn't any difference, is there, with unboxed tuples?

[Stefan O'Rear]

On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote:
> --> unboxed types in function results are automatically "lifted"... or what 
> was the term meaning they could be _|_, failing to terminate, (because of 
> the function-ness)?
>
> --> unboxed tuples are specially restricted to be only allowed, among 
> useful places, in function results.
>
> Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are identical, 
> assuming both are kind-correct (identical in terms of optimization and 
> semantics, not type equality, of course).  Is that right?  If so, there's 
> never an excuse to use unboxed tuples except to contain unboxed values 
> (because then you don't have the choice of using boxed tuples, which can 
> only contain boxed values of kind *).

Semantically, you are absolutely correct.  However, there is a very
subtle difference in sharing.

Consider these two functions:

foo (a,b) = (a,b)
bar tuple = tuple

These two functions are denotationally identical, but at runtime one
performs more allocations.  If we use unboxed tuples, then the caller
must always allocate if a tuple is needed; thus effectively we always
get the allocation behavior of foo.  That is, return unboxing is not
always an optimization!  However, it *is* always safe if the tuple is
constructed in the function itself, for then it could not possibly be
shared with anything.  Having explicit unboxed tuples in the language
allows this complexity to be moved out of the code generator, which is a
Good Thing.  (Incidentally, this is what the CPR analysis is all about -
identifying places where a Constructed Product is Returned.)

Stefan


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

there isn't any difference, is there, with unboxed tuples?

[Isaac Dupree]

--> unboxed types in function results are automatically "lifted"... or 
what was the term meaning they could be _|_, failing to terminate, 
(because of the function-ness)?


--> unboxed tuples are specially restricted to be only allowed, among 
useful places, in function results.


Therefore (... -> ( a, b, c ) ) and (... -> (# a, b, c #)) are 
identical, assuming both are kind-correct (identical in terms of 
optimization and semantics, not type equality, of course).  Is that 
right?  If so, there's never an excuse to use unboxed tuples except to 
contain unboxed values (because then you don't have the choice of using 
boxed tuples, which can only contain boxed values of kind *).


~Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Module system, was Re: GHC source code improvement ideas

[Brian Hulley]

Brian Hulley wrote:

Ian Lynagh wrote:

On Fri, Jan 04, 2008 at 08:34:22AM +, Simon Peyton-Jones wrote:

|   4. A more radical change would be introducing hierarchical modules.



Sorry I quoted what Simon PJ replied to not what he wrote so I should 
have written:


> Ian Lynagh wrote:
>>
>>>  On Fri, Jan 04, 2008, Twan van Laarhoven wrote:
>>>4. A more radical change would be introducing hierarchical modules.

Though this is again not quite right since Ian did not write line 3...

Apologies to Simon PJ and Twan (and now also to Ian) for mis-quoting ;-)

Brian.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

wish for more-usable bindist

[Isaac Dupree]

the i386 linux ghc bindist still uses readline 4 
, which is hard to get:
readline 5.0 came out almost three and a half years ago 



And I don't want to pollute my Ubuntu system with "compatibility RPMs"; 
in fact I intend to install the bindist as my local user so I don't 
pollute it with extra GHCs either, except I can't.  Could there be a 
bindist with modern readline, or perhaps is it possible to statically 
link with readline?


~Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Module system, was Re: GHC source code improvement ideas

[Brian Hulley]

Ian Lynagh wrote:

On Fri, Jan 04, 2008 at 08:34:22AM +, Simon Peyton-Jones wrote:

|   4. A more radical change would be introducing hierarchical modules.



It's a pity that GHC.* is already used in base. I'm not sure what the
best thing to do is in the short term.



How about Language.Haskell.Compiler.GHC.*

In the long term, Haskell needs a better module system IMHO, since the 
problem at the moment is that having to write the full hierarchical name 
in each module means that you need to know in advance, before you've 
even started writing a program, where each module will fit into the 
global namespace, which makes it extraordinarily difficult to do 
exploratory programming or bottom-up development, and the need to write 
so many import directives in each module makes it extremely painful not 
to mention overly hard-wired.


A good direction IMHO is the way SML structures are grouped using 
CM.make (SML/NJ) or MLBasis (MLton and others), so that there are no 
import directives at all: a separate group definition determines what is 
in scope, and compilation proceeds by chasing these group definition 
files rather than chasing modules.


Translating this into Haskell, the module syntax could be simplified and 
other modules could be nested and aliased within a module, so that it is 
easy to create different hierarchical views of the modules which are in 
scope to suit the particular module being written or clients of that module:


-- Leaf.hs
module Leaf where
module String where
open Data.ByteString.Char8
type T = ByteString

module Map = Data.Map

module Util where
foo :: Int -> Int
foo i = i

--Other.hs
module Other where
bar :: Int -> Leaf.String.T
bar = Leaf.String.pack . show . Leaf.Util.foo

Note that here there is no need for any import directives, since the 
modules which are in scope when Leaf.hs is compiled would be determined 
by whatever group Leaf.hs is part of (with respect to that particular 
program), which would be defined in a separate file:


--MyBasis.hsg
local $Haskell/StdBase.hsg

Leaf.hs
Other.hs

Within the .hsg files, groups and modules are referenced by filename, 
and is just a simple list of components that are required and/or 
exported by the group. In the .hsg file above, MyBasis will export the 
contents of Leaf.hs and Other.hs, which are compiled in an environment 
augmented by StdBase (which is not itself exported by MyBasis).


(See CM.make and the MLBasis system for more details - in particular, 
for any given program a module may appear in only one group, but the 
same module may appear in different groups in different programs thus 
facilitating easy exploratory programming and re-organization without 
breaking previous programs.)


This can be taken further to get an even more powerful system by using 
parameterized traits and explicit instantiation for modules:


trait T a b where
foo :: a -> b

bar :: Int -> Int
bar i = i + 1

module M where
include T Int String
foo = show . bar

Here, the body of a module is always a trait, and the above is 
equivalent to:


trait T a b = tra
foo :: a -> b

bar :: Int -> Int
bar i = i + 1

module M = new tra
include T Int String
foo = show . bar

which makes it more explicit that conversion of the contents to actual 
code (ie linking, allocation/identity/initialization of CAFs and foreign 
objects, generativity of data types etc) happens only in the module decl.


The great thing about making instantiation explicit is that traits are 
pure functional values and so can easily be combined with no side 
effects, whereas modules may in general contain mutable state eg to 
interface with some external C library and thus are 
objects-with-identity. Thus the separation solves the whole problem of 
applicative vs generative functors in ML, as well as solving the problem 
of mutually recursive structures (functors become a redundant concept 
because you can always start with including a trait then overriding some 
decls with more instantiated (here used in a different sense) decls 
and/or traits).


Last but not least, a trait could also be used similarly to a signature, 
except that definitions in the trait can be considered to be default 
implementations. Therefore in this scenario the body of a class or 
instance decl is just a trait and so could be composed using other 
traits etc. (Each instance decl instantiates the trait given in the body 
merged with the trait given in the class leading to a possibly 
parameterized module.)


Anyway these are some of the directions I am currently working on for my 
n

Re: GHC 6.8.1 port on FreeBSD-amd64?

[Matthias Kilian]

[Note: already shortly discussed with Wilhelm]

On Fri, Nov 23, 2007 at 12:30:06PM +, Wilhelm B. Kloke wrote:
> > ../../compiler/stage1/ghc-inplace -package-name unix-2.2.0.0 
> > -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build 
> > -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build 
> > -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -package 
> > directory-1.0.0.0 -O -XCPP -XForeignFunctionInterface -idist/build  -H32m 
> > -O0 -fasm -Rghc-timing -keep-hc-files -O -c 
> > dist/build/System/Posix/Process.hs -o dist/build/System/Posix/Process.o  
> > -ohi dist/build/System/Posix/Process.hi
> > Prologue junk?: .type   s32x_ret, @function
> > s32x_ret:
> > pushl   %ebp
> > movl%esp, %ebp

I see nearly the same problem with ghc-6.8.2 on OpenBSD, using the
gcc-3.3.5 included in its base system.

Regardless of wether there's something wrong with the generated
code or wether it's just a bug in the mangler, it's possible to
build Process.c with -fviaC *and* -O0.[1]

For now, I'm able to build a HC file bundle with this settings in
build.mk and running "gmake stage1 hc-file-bundle":

SRC_HC_OPTS=-H64 -O -fvia-C -keep-hc-files
GhcLibHcOpts=   -O0 # Workaround the mangler problem
GhcLibWays=
GhcRTSWays=
SplitObjs=  NO

I'd appreciate any reports wether people see the same problem on
other systems (if so: what gcc version are you using?) and wether
GhcLibHcOpts=-O0 fixes it.

Ciao,
Kili

[1] BTW: what's the point of using -fasm with -keep-hc-files? IMHO,
it should be -fviaC -keep-hc-files. Someone let me know if I should
correct this in the wiki.


ps: yes, I'm slowly trying to bring HC bootstrap back to work. It's
a must-have for the OpenBSD port. Apart from the HC file bundle,
this will require some more hacking especially on library/Makefile
and the Cabal-generated GNUmakefiles (and/or Makefile.local).

pps: I guess, cvs-ghc would be the more correct list for sending
patches and discussing the bootstrapping stuff, right?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC source code improvement ideas

[Ian Lynagh]

On Fri, Jan 04, 2008 at 08:34:22AM +, Simon Peyton-Jones wrote:
> 
> |   4. A more radical change would be introducing hierarchical modules. This
> | could be just a matter of renaming the directories to start with an upper
> | case character and changing the import declarations. This gives module names
> | like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be
> | renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would
> | be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the
> | GHC api.
> 
> I don't think I'd object, but I'm not sure that much is gained here.  We 
> don't spend much time on mondule-name clashes.

One point is that GHC uses module names like Util and State, which is a
bit unfriendly to people using GHC-as-a-library.

Also, although "import Types.Generics" is a bit longer to type, it is
also a bit easier for someone less familiar with the code to follow the
imports (if their editor does not help them).

It's a pity that GHC.* is already used in base. I'm not sure what the
best thing to do is in the short term.


Thanks
Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: binary-dists for ghc-6.8.2

[Christian Maeder]

Christian Maeder wrote:
> 
> http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin.tar.bz2
> http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2

these dists are updated now, with a proper (though stripped) file
hsc2hs-bin that caused problems
http://hackage.haskell.org/trac/ghc/ticket/1395.

> The frameworks under
> http://www.haskell.org/ghc/dist/mac_frameworks/mac_e.htm
> should do.

> The Mac binaries have been built using
> gcc version 4.0.1 (Apple Computer, Inc. build 5367)
> and a patched Linker.lhs from
> http://hackage.haskell.org/trac/ghc/ticket/1798

Also the file compiler/main/DriverPipeline.hs is (still) patched
according to http://hackage.haskell.org/trac/ghc/ticket/1395

> The PPC binary still features:
> http://hackage.haskell.org/trac/ghc/ticket/1845

Both binaries have a fix for
http://hackage.haskell.org/trac/ghc/ticket/1980 now.
(Only the PPC dist has been rebuilt, the i386 one was only repacked)

Ian, could you replace the dists on the download page?

It's possible to overwrite an installation (and loose your later
installed packages!), but not necessary in most cases. Still use "make
install-strip" after "./configure".

Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Maps, was Re: GHC source code improvement ideas

[Christian Maeder]

Simon Marlow wrote:
> Regarding Data.Map, I'd be interested in trying out AVL trees instead,
> to see if they have better performance, but then we'd have to import the
> code of course.

Surely, we want the best maps possible for ghc and as public library
(and minimize maintenance).

The problem is to agree on a suitable interface. I would suggest to take
 (or only slightly change) Daan's interface (the current Data.Map) and
improve the underlying implementation possibly using (i.e. Adrian Hey's)
AVL trees.

Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: odd GHC 6.8.2 compile failure

[Simon Marlow]

Isaac Dupree wrote:

Simon Marlow wrote:
Note however that if you install this compiler, the packages in your 
home directory won't work any more, because they were compiled by 
another instance of 6.8.2


true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not 
counting packages?


Yes, the ABI is the same, but there's no guarantee that the interfaces to 
all the packages are the same.



against a different set of packages.


hmm.  different versions?  I think it might work out since I installed 
everything locally, if I just install the versions of the extra-libs 
that came with the 6.8.2 bindist...


Or do I have too great hopes in the reproducibility of ghc compilations?


It's too fragile to rely on getting the same results when you compile a 
package again, if -O is on.  In practice, if the conditions are exactly the 
same you can often get identical interfaces, but we've never put any effort 
into figuring out how to guarantee this and under what conditions.  Better 
not to rely on it.



Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: odd GHC 6.8.2 compile failure

[Isaac Dupree]

Simon Marlow wrote:
Note however that if you install this compiler, the packages in your 
home directory won't work any more, because they were compiled by 
another instance of 6.8.2


true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not 
counting packages?



against a different set of packages.


hmm.  different versions?  I think it might work out since I installed 
everything locally, if I just install the versions of the extra-libs 
that came with the 6.8.2 bindist...


Or do I have too great hopes in the reproducibility of ghc compilations?

(Not that I have any reason to try that.  I would probably just pull 
from the 6.8-darcs-branch to get your patch (and other post-6.8.2 fixes) 
and recompile everything anyway.)


~Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: odd GHC 6.8.2 compile failure

[Simon Marlow]

Isaac Dupree wrote:

Simon Marlow wrote:

Isaac Dupree wrote:

Simon Marlow wrote:

Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, 
with --prefix=$HOME .


It's odd because I previously had a 6.8.2 (official x86 Linux 
bin-dist) installed as root (it's gone now), and I still have a 
bunch of cabal/hackage packages installed in $HOME that were 
compiled by that 6.8.2 (in addition to a few things installed by 
`cabal install` in ~/.cabal/).  Do you think that could be 
confusing the build process, and if it is, is that a bug - and a 
bug in what?


It looks like at some point you've updated your sources and 
recompiled without cleaning in stage2, or something similar.  The 
build system doesn't currently notice when libraries have changed 
and stage2 needs to be completely recompiled.


It sure looks that way!  But I didn't do that personally; I think 
these are all of my steps:

[download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2]
cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe
aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2
# this `aunpack` is equivalent to tar -xjf in this case.
cd ghc-6.8.2
./configure --prefix=$HOME
# ($HOME is /Users/me/HOME , by the way).
make

Indeed I just reproduced it, newly unpacking that tarball in a new 
location, to make sure, and I got the same error.



What if GHC suddenly decided to link with the newer versions of the 
boot-libraries than come with 6.8.2, the ones that could be found in 
$HOME since I installed them there? (or with the _same_ versions that 
happened to be compiled with different flags, perhaps?)


And you get different results if you omit the --prefix=$HOME?  (if so, 
that's very strange, and I don't have a clue what's wrong, yet)


tested a couple more times:
- it still fails without --prefix=$HOME
- but it succeeds if I `su - east` and have 'east' compile it (without 
using --prefix here either) ('east' being another user on my machine 
other than the user 'me' which I usually use)


Ah, I see.  You have packages installed in your home directory for GHC 
6.8.2, and these are being picked up by the stage1 compiler.


We should be using -no-user-package-conf when running the compiler from the 
build tree.  I'll test this fix.


Note however that if you install this compiler, the packages in your home 
directory won't work any more, because they were compiled by another 
instance of 6.8.2 against a different set of packages.


Cheers,
Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC source code improvement ideas

[Neil Mitchell]

Hi

Yhc did a few of these things, and our experiences were:

>   1a. Use do notation where possible instead of `thenXX`.

If it is that simple, yes. Certainly Yhc uses "super-monads" which
made this a bit painful. You should probably step this by getting it
to the stage where thenXX = >>=, then only flipping to do notation
once the things are already monads.

>   1b. Even better, use Applicative where possible. For example
>
>  ds_type (HsFunTy ty1 ty2)
>= dsHsType ty1   `thenM` \ tau_ty1 ->
>  dsHsType ty2   `thenM` \ tau_ty2 ->
>  returnM (mkFunTy tau_ty1 tau_ty2)
>
>   Could be rewritten as
>
>  ds_type (HsFunTy ty1 ty2)
>= mkFunTy <$> dsHsType ty1 <*> dsHsType ty2

I still don't particularly like applicative, it is a bit confusing to
me. If you moved to using the Uniplate library, you could then write:

descendM dsHsType

Shoter, more concise, and probably works for more cases than just
HsFunTy - eliminating even more code. I suspect moving to Uniplate
would give GHC massive benefits.

>   4. A more radical change would be introducing hierarchical modules. This
> could be just a matter of renaming the directories to start with an upper
> case character and changing the import declarations. This gives module names
> like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be
> renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would
> be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the
> GHC api.

We did this in Yhc, and it was really useful just to group files into
the same directory.

Thanks

Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC source code improvement ideas

[Simon Marlow]

Twan van Laarhoven wrote:

Hello GHC people,

I was trying my hand at some GHC hacking, and I couldn't help but notice 
that much of the code looks (IMHO) horrible. There are some things that 
look as if they haven't been touched since the Haskell 1.3 days. The 
most striking is the use of `thenXX` instead of do notation.


I was thinking of cleaning up some of this. In particular:

 1a. Use do notation where possible instead of `thenXX`.


Yes.


 1b. Even better, use Applicative where possible. For example

ds_type (HsFunTy ty1 ty2)
  = dsHsType ty1`thenM` \ tau_ty1 ->
dsHsType ty2`thenM` \ tau_ty2 ->
returnM (mkFunTy tau_ty1 tau_ty2)

 Could be rewritten as

ds_type (HsFunTy ty1 ty2)
  = mkFunTy <$> dsHsType ty1 <*> dsHsType ty2


No, IMO.  This just adds another abstraction that a potential GHC 
contributor has to learn about.  Including me :-)  It doesn't hurt to write 
 out the code in full sometimes, and as the GHC coding style guidelines say:


  Remember: other people have to be able to quickly understand what you've
  done, and overuse of abstractions just serves to obscure the really
  tricky stuff, and there's no shortage of that in GHC.

http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle

(I think I might be quoting myself there, in which case it doesn't really 
add much credibility to my argument :).


Also bear in mind that we have to be able to compile GHC with older 
versions of itself (currently back to 6.2.2), which explains why we're 
often conservative with respect to using external libraries.


 2. Investigate the need for all these mappM functions. To quote the 
source: "Standard combinators, but specialised for this monad (for 
efficiency)". Wouldn't a SPECIALIZE pragma work just as well?


It does look like we could do away with some of those, yes.

 3. In general, use standard functions when they are available. 
Currently GHC has its own sort function and its own versions of 
FiniteMap/Data.Map and Text.PrettyPrint. Using standard functions/data 
structures will a) make GHC smaller and therefore easier to maintain, 
and b) will make the code easier to understand for someone who knows the 
standard library.


In general yes.  But bear in mind there's another principle at work here: 
we want to insulate GHC as much as possible from its environment, to reduce 
the chances of spurious failures or performance regressions.


I believe our version of Text.PrettyPrint has diverged from the library 
version - last time I looked it wasn't obvious that we could replace it.


Regarding Data.Map, I'd be interested in trying out AVL trees instead, to 
see if they have better performance, but then we'd have to import the code 
of course.


 4. A more radical change would be introducing hierarchical modules. 
This could be just a matter of renaming the directories to start with an 
upper case character and changing the import declarations. This gives 
module names like "Typecheck.TcGadt". The tc is redundant here, so 
perhaps it should be renamed to "Typecheck.Gadt" or "Typecheck.GADT". 
Perhaps even better would be "GHC.Typecheck.GADT", this way some modules 
can be exposed as part of the GHC api.


Yes, I've wondered about doing this in the past.  It does mean more typing, 
though: clearly 'import BasicTypes.Id' is more painful than just 'import 
Id' and doesn't add much, so IMO we'd need to put some thought into a 
structure that makes sense.


How do the GHC developers feel about this? Would such paches be gladly 
excepted? Or will they be directly forwarded to the bit bucket?


Within the constraints I've outlined above, cleanups are definitely welcome.

Another worthwhile gardening-type activity is to go around elimianting 
warnings.  Many modules have {-# OPTIONS -w #-} at the top, waiting for 
someone to go in and clean up all the warnings.  They do catch real bugs, 
so this is not a waste of time by any means.


In addition to this, things like

 - identifying and removing dead code
 - commoning up duplicate code fragments
 - improving test coverage
 - profiling and optimising hotspots

are all useful tasks.

Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Redefining built in syntax

[Simon Marlow]

Simon Peyton-Jones wrote:

| C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts
| -package-name base
| GHCi, version 6.8.1: http://www.haskell.org/ghc/  :? for help
|
| :1:22:
| Failed to load interface for `System.IO':
|   it is not a module in the current program, or in any known package.

I don't think we'd ever thought of doing this.  In particular, I don't think 
we'd every considered using GHCi in combination with -package-name.


I can't off the top of my head think of a reason why it should fail, unless 
you use a special -package-name like base, rts, haskell98 or template-haskell.



Furthermore, I'm not sure we've ever thought what should happen if you use 
-package-name foo, when compiling with a compiler that already has a package 
'foo' (with an identical name) installed.  Probably we should check for this 
case, because it looks likely to lead to confusion.


This certainly works, because it must be possible to recompile a package P 
even though P is installed - it happens when you go back in libraries/ and 
say 'make', for example.


Normally the already-installed P is hidden, because Cabal passes 
-hide-all-packages to GHC, so things work out fine.  Probably GHC ought to 
filter out P and anything that depends on it from the set of installed 
packages anyway, to prevent strange things from happening.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Rank-2 polymorphism and pattern matching

[Simon Peyton-Jones]

| > The following won't compile for me
| >
| > isnull :: (forall a . [a]) -> Bool
| > isnull ([] :: forall b . [b]) = True
| >
| >Couldn't match expected type `forall b. [b]'
| >against inferred type `[a]'
| > In the pattern: []

This is a pretty strange thing to do, to match a polymorphic argument against a 
data constructor.  I guess you'd expect this to work too, perhaps?

f :: forall a.  (forall b. Either a b) -> a
f (Left x) = x

I grant that arguably these should work, but I think it'd be quite tricky to 
make it do so, because it'd involve re-generalising in the pattern.  
Furthermore, I can't see any use for it.  Just remove the type signature from 
the pattern.

One could argue that it's a bad sign that the pattern typechecker should have 
difficulty with this.  But until it turns out to be important I'm not going to 
lose sleep over it!

Interesting example though.  Perhaps the error message should be better.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Is GHC.Base deliberately hidden?

[Simon Marlow]

Adrian Hey wrote:


Why is it that the haddock docs supplied with GHC omit this module and
its exports? Is it because we're not supposed to use them? I'm thinking
of the compareInt# function in particular, which I use quite a lot.


We don't intend GHC.Base to be a stable interface for external use, which 
is why we don't document it.  Use at your own risk!


If there's useful stuff in GHC.Base, then arguably we should have a 
published stable interface from which to get it, though.


Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC source code improvement ideas

[Isaac Dupree]

Simon Peyton-Jones wrote:

|   4. A more radical change would be introducing hierarchical modules. This
| could be just a matter of renaming the directories to start with an upper
| case character and changing the import declarations. This gives module names
| like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be
| renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would
| be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the
| GHC api.

I don't think I'd object, but I'm not sure that much is gained here.  We don't

> spend much time on mondule-name clashes.

I vote for this, as it makes it easier to progress to standard 
module-chasing such as Cabal or `ghc --make`, and everyone supports 
hierarchical modules nowadays. (I might do it myself, if appropriate)


warning: calling them "GHC.*" clashes with base's use of that namespace 
for implementation-specific functions in compiled programs, INCLUDING 
ghc (I mean, GHC code sometimes says "import GHC.Exts") ... so let's 
please find a different name-prefix if we decide we want one.



~Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Redefining built in syntax

[Simon Peyton-Jones]

| C:\Documents\Uni\packages\base>ghci Prelude.hs -i -cpp -fglasgow-exts
| -package-name base
| GHCi, version 6.8.1: http://www.haskell.org/ghc/  :? for help
|
| :1:22:
| Failed to load interface for `System.IO':
|   it is not a module in the current program, or in any known package.

I don't think we'd ever thought of doing this.  In particular, I don't think 
we'd every considered using GHCi in combination with -package-name.

Furthermore, I'm not sure we've ever thought what should happen if you use 
-package-name foo, when compiling with a compiler that already has a package 
'foo' (with an identical name) installed.  Probably we should check for this 
case, because it looks likely to lead to confusion.


The immediate problem is that GHCi looks for the value "System.IO.stdout" so 
that it can use it to print things, and it can't find module System.IO, I think 
because you've overridden the base-package binding.


Do you have to use GHCi for this stuff?  It's delicate, because GHCi prints 
things, but you want to compile the very functions it is using to do the 
printing...


Simon

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

[Christian Maeder]

(Let's discuss this openly on glasgow-haskell-users)

I'm not happy about this framework hick-hack either. I've only pushed
it, because we needed a readline solution on macs.

The alternative is to use static linking of gmp (as suggested by chak)
_and_ readline (version 5), so that user programs are also statically
linked with these libs. Nobody supplied a binary distribution so far,
though. I only supplied the binary distributions that I (naively) made
anyway.

Regarding this actual GNUreadline-framework.zip replacement, this is
harmless and seems to matter only for those who build ghc with
frameworks (as only the inclusion of header files changed)

In any case we should strive to fix the frameworks issues _and_ add
support for static linking of gmp, readline and possibly other libs
(plus license issues).

HTH Christian

Thorkil Naur wrote:
> Hello,
> 
> Thanks everybody. However, I believe that using a modified readline library 
> is 
> debatable, mainly because it adds the burden of keeping this library 
> up-to-date to the GHC maintenance process. Having a renamed library is one 
> thing and it does not seem that also modifying the contents of the library is 
> an improvement.  For me to consider this idea, it should be the very last 
> solution, every other stone having been turned. And I certainly believe that 
> stones remain to be turned in this case.
> 
> I would very much like to hear your comments to this.
> 
> In addition, if you must replace this framework with another with different 
> contents, I would suggest the use of some versioning scheme. Otherwise is 
> seems that a lot of confusion could result.
> 
> Thanks and best regards
> Thorkil
> 
> On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
>> Hi Christian,
>>
>> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
>>> Judah's framework (2342543 Bytes)
>>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
>>>
>>> should replace (my old one)
>>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
>> Done!
>>
>>
>> Thanks
>> Ian
>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Unrecognized -F flag

[Christian Maeder]

Thanks, for your report. It was my fault. I should not have modified
utils/hsc2hs/Main.hs as described in the following links.

http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583
http://hackage.haskell.org/trac/ghc/ticket/1395

A fix is to replace your file /lib/ghc-6.8.2/hsc2hs-bin with a
new one that you can download from:
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/hsc2hs-bin
(635468 Bytes)

a ppc version from:
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/versions/hsc2hs-bin
(800044 Bytes)

 above is /usr/local (or the one you've configured with)

Does someone have a cute command to easily update this file in a binary
distribution (without unpacking and repacking), so that Ian can replaced
my binary-dists (replacing hsc2hs-bin manually is a bit of a pain).

Christian


Adam Smyczek wrote:
> Hi Christian,
> 
> I'm using your OS X (Tiger) Intel ghc-6.8.2 distribution downloaded from
> haskell.org.
> So far everything worked great until I run into one problem compiling
> zlib 0.4.0.1.
> Running build command I get the following error:
> 
> Preprocessing library zlib-0.4.0.1...
> ghc-6.8.2: unrecognised flags: -F/Users/asmyczek/Library/Frameworks
> Usage: For basic information, try the `--help' option.
> compiling dist/build/Codec/Compression/Zlib/Stream_hsc_make.c failed
> command was: /opt/local/bin/ghc -c -package base-3.0.1.0 -package
> bytestring-0.9.0.1 -F/Users/asmyczek/Library/Frameworks
> dist/build/Codec/Compression/Zlib/Stream_hsc_make.c -o
> dist/build/Codec/Compression/Zlib/Stream_hsc_make.o
> 
> I'm newbie to Haskell, Cabal etc. and not sure what the root cause of
> this problem is.
> Google did not find any concrete solution as well.  Do you have an idea
> what the problem
> could be or maybe some hints where I can start to dig into?
> 
> Thanks,
> Adam
> 
> 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Fwd: Re: Problem building hdbc-sqlite3 with ghc 6.8.2]

[Christian Maeder]

Did a final "runhaskell Setup.lhs install" work for you, Emmanuel?

Thanks, Wolfgang

Cheers Christian

Wolfgang Thaller wrote:
> On 3-Jan-08, at 4:47 PM, Christian Maeder wrote:
> 
>> Hi,
>>
>> can someone explain the linking error below? (on Intel-Mac (Tiger?))
>>
>> Preprocessing library HDBC-sqlite3-1.1.3.0...
>> Building HDBC-sqlite3-1.1.3.0...
>> [1 of 7] Compiling Database.HDBC.Sqlite3.Consts ( dist/build/Database/
>> HDBC/Sqlite3/Consts.hs, dist/build/Database/HDBC/Sqlite3/Consts.o )
> [...]
>> ar: creating archive dist/build/libHSHDBC-sqlite3-1.1.3.0.a
>> ld: atom sorting error for
>> _HDBCzmsqlite3zm1zi1zi3zi0_DatabaseziHDBCziSqlite3ziTypes_CSqlite3_closure_tbl
>>
> [...]
> 
> To the best of my knowledge, this is harmless and can be ignored.
> Linking continues after this message is printed, and I haven't yet found
> any adverse side-effects.
> 
> The message is triggered (in Apple's recently-rewritten linker) when
> there are two or more labels pointing to the very end of a section in an
> object file. This sometimes happens when empty _closure_tbls are emitted
> by GHC; it's probably not too hard to prevent this from happening.
> 
> Cheers,
> 
> Wolfgang
> 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: GHC source code improvement ideas

[Simon Peyton-Jones]

Twan,

In general I'd be delighted for you to clean up GHC's code -- thank you!  There 
is a slight down-side which is that because you end up touching a lot of code, 
you get a big patch that means you can't selectively pick patches from before 
and after the change -- but I'm not too bothered about that, and its balanced 
by the clean-up.

Let's also see what Simon and Ian (or others) have to say.

Best to do one change per patch.

A very useful thing to do would be to improve the Commentary:
http://hackage.haskell.org/trac/ghc/wiki/Commentary
In fiddling with GHC's codebase you will surely learn stuff that you wish you'd 
known to start with, and that is the Ideal Moment to capture it in writing on 
the Wiki.  A real service to others.


|   1a. Use do notation where possible instead of `thenXX`.

Yes.

|   1b. Even better, use Applicative where possible. For example
|
|  ds_type (HsFunTy ty1 ty2)
|= dsHsType ty1   `thenM` \ tau_ty1 ->
|  dsHsType ty2   `thenM` \ tau_ty2 ->
|  returnM (mkFunTy tau_ty1 tau_ty2)
|
|   Could be rewritten as
|
|  ds_type (HsFunTy ty1 ty2)
|= mkFunTy <$> dsHsType ty1 <*> dsHsType ty2

This works great when you have the pattern above -- but often it's a bit more 
complicated and then it does not work so well.  So it's hard to employ the 
pattern consistently.  Then you have to ask whether a mixture of styles is good.

My gut feel is that it's better to use do-notation consistently.

|   2. Investigate the need for all these mappM functions. To quote the
| source: "Standard combinators, but specialised for this monad (for
| efficiency)". Wouldn't a SPECIALIZE pragma work just as well?

The trouble is that currently you can only specialise a function at its 
definition site -- and at the definition of mapM the relevant monad isn't in 
scope because mapM is in a library.

I have no clue whether this has any effect on performance.  You could try a 
small experiment, by defining mappM=mapM and seeing if there was any change.

|   3. In general, use standard functions when they are available. Currently
| GHC has its own sort function and its own versions of FiniteMap/Data.Map and
| Text.PrettyPrint. Using standard functions/data structures will a) make GHC
| smaller and therefore easier to maintain, and b) will make the code easier
| to understand for someone who knows the standard library.

In general yes.

But GHC is meant to be compilable with any GHC back to 6.2.  So if the 
interface to a library changes between (say) 6.2 and 6.4, you end up with 
ifdefs.  That can be a royal pain.  Having the library code in the compiler 
source eliminates that problem.

The other thing is that it's possible that GHC's version of the library has 
more functions.  Or uses some non-standard feature like unboxed types.

So proceed with caution here.  Prettyprinting would be a strong candidate.  
FiniteMap too. But be careful with UniqFM -- it's a very very heavily-used 
library.

|   4. A more radical change would be introducing hierarchical modules. This
| could be just a matter of renaming the directories to start with an upper
| case character and changing the import declarations. This gives module names
| like "Typecheck.TcGadt". The tc is redundant here, so perhaps it should be
| renamed to "Typecheck.Gadt" or "Typecheck.GADT". Perhaps even better would
| be "GHC.Typecheck.GADT", this way some modules can be exposed as part of the
| GHC api.

I don't think I'd object, but I'm not sure that much is gained here.  We don't 
spend much time on mondule-name clashes.

Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users