Re: Another GHC 6.4 Release Candidate Binary for Mac OS X

[Stefan Holdermans]

Wolfgang,
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Works great for me.  The double-clickable icons for GHCi are great, too
I second that.
How much effort did take to construct the installer? Is it a process 
that could easily be automated? Would it, for instance, be possible to 
schedule the overnight generation of an installer for the HEAD branch?

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

Re: Another GHC 6.4 Release Candidate Binary for Mac OS X

[Andre Pang]

On 09/03/2005, at 8:15 PM, Wolfgang Thaller wrote:
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Works great for me.  The double-clickable icons for GHCi are great, too 
(I'm sure it'll help out many Mac users who have to use GHC In their 
first year at university ;).

Thanks Wolfgang, GHC's Mac OS X support has gone from non-existent to 
superior in the past two-three years largely because of you!

--
% Andre Pang : trust.in.love.to.save  
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: infix type operators

[Conal Elliott]

Agreed.  I was surprised by the language inconsistency when I discovered
that symbols were ruled out for type variables.  It just seemed natural
to me when programming with arrows, and I'm surprised it hasn't shown
itself useful before.  - Conal

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, March 09, 2005 4:58 PM
To: Remi Turk
Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones
Subject: Re: infix type operators

On Wed, Mar 09, 2005 at 11:59:40PM +0100, Remi Turk wrote:
> - It's one thing more to learn. The difference between types and
>   typevariables (upper/lowercase) is better visible than the
>   difference between operator(variables) and infix-types ("Does
>   it start with a colon?") Which, I have to admit, is more of a
>   vague feeling than anything like a fact.

On the contrary: it's one less exception to remember.  With this change,
the lexical syntax of type variables and type constructors is exactly
the same as that for data variables and data constructors respectively,
except that there are some special type constructors (->), (), (,,),
etc,
just as there are some special data constructors like 1.7, (), (,,) etc.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

Re: infix type operators

[ross]

On Wed, Mar 09, 2005 at 11:59:40PM +0100, Remi Turk wrote:
> - It's one thing more to learn. The difference between types and
>   typevariables (upper/lowercase) is better visible than the
>   difference between operator(variables) and infix-types ("Does
>   it start with a colon?") Which, I have to admit, is more of a
>   vague feeling than anything like a fact.

On the contrary: it's one less exception to remember.  With this change,
the lexical syntax of type variables and type constructors is exactly
the same as that for data variables and data constructors respectively,
except that there are some special type constructors (->), (), (,,), etc,
just as there are some special data constructors like 1.7, (), (,,) etc.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: infix type operators

[Remi Turk]

[warning: Very Vague message & possible bug-report follow]

Though I cannot claim any real-world experience with arrows, I'm
not sure I like this, and I hope they'll at least remain
experimental (may be removed next release kind of thing) for a
while.

- I doubt whether the difference between "Arrow a => a b c" and
  "Arrow (~>) => b ~> c" is all that great. Or even, whether the
  perhaps slightly improved readability of "b ~> c" makes up for
  the IMO slightly decreased readability of "Arrow (~>)".
- When one really needs to do it infix, one can always write
  "Arrow a => b `a` c".
- It's one thing more to learn. The difference between types and
  typevariables (upper/lowercase) is better visible than the
  difference between operator(variables) and infix-types ("Does
  it start with a colon?") Which, I have to admit, is more of a
  vague feeling than anything like a fact.
- We already have the special case of -> as a _type_, not
  a typevariable, and having -> as a type, :-> as a type and ->:
  as a typevariable doesn't sound too great. Of course, as -> is
  special in expression context too, that may not be convincing
  either :(

So I guess I'll have to end this mail with "there is at least one
person not feeling entirely comfortable about it" :)

Would it at least be possible to make it a seperate flag from
-fglasgow-exts? (I'm slightly worried about people needing one
extension and then using the rest too just because they're
already enabled, so actually this doesn't apply only to this
particular feature.)

Groetjes,
Remi


On Wed, Mar 09, 2005 at 05:06:03PM -, Simon Peyton-Jones wrote:
> OK, it's done for 6.4
> 
> SImon
> 
> | -Original Message-
> | From: [EMAIL PROTECTED]
> [mailto:glasgow-haskell-users-
> | [EMAIL PROTECTED] On Behalf Of Ross Paterson
> | Sent: 08 March 2005 16:29
> | To: glasgow-haskell-users@haskell.org
> | Subject: infix type operators
> | 
> | The User's Guide says:
> | 
> | The only thing that differs between operators in types and
> | operators in expressions is that ordinary non-constructor
> | operators, such as + and * are not allowed in types.  Reason:
> | the uniform thing to do would be to make them type variables,
> | but that's not very useful.  A less uniform but more useful
> thing
> | would be to allow them to be type constructors.  But that gives
> | trouble in export lists.  So for now we just exclude them.
> | 
> | Conal has pointed out that the uniform thing would be useful for
> | general arrow combinators:
> | 
> | liftA2 :: Arrow (~>) =>
> | (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c)

-- 
Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: environment variables for ghc

[Frederik Eaton]

> We'll definitely take the environment variable patch if it comes with a
> ghcbug script :-)

OK, well I'll be busy for the next few weeks so if someone else wants
to step up and do it, don't wait for me. But otherwise I'll put in on
my todo list.

Cheers,

Frederik

-- 
http://ofb.net/~frederik/

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

Re: environment variables for ghc

[Frederik Eaton]

OK, well I'll be busy for the next few weeks so if someone else wants
to step up and do it, don't wait for me. But otherwise I'll put in on
my todo list.

Cheers,

Frederik

On Wed, Mar 09, 2005 at 10:40:03PM -, Simon Marlow wrote:
> On 09 March 2005 21:13, Frederik Eaton wrote:
> 
> >>> I agree that the case you're presenting is indeed more difficult,
> >>> but I don't think you're doing the estimations right for the one at
> >>> hand. The cost and annoyance of perhaps tens of thousands of people
> >>> adding and remembering to maintain wrappers named 'ghc' somewhere
> >>> in their path to accomplish this simple task (after scrounging in
> >>> the documentation to find that ghc for some reason fails to be like
> >>> many other compilers, a nontrivial cost in itself since the lack of
> >>> environment variables isn't specifically documented) - or simply not
> >>> doing so, and typing in -package-conf hundreds of times as I have
> >>> done, because they may not have write access to the main
> >>> package.conf - I think outweighs the cost of one person, once,
> >>> adding central support for environment variables, a bit of
> >>> documentation in the man page, perhaps a ghcbug program if we want
> >>> super-detailed bug reports...
> >> 
> >> Are you volunteering to be that person? ;-)
> > 
> > Are you saying that a patch would be accepted?
> > 
> > Frederik
> 
> We'll definitely take the environment variable patch if it comes with a
> ghcbug script :-)
> 
> Cheers,
>   Simon
> 

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

RE: environment variables for ghc

[Simon Marlow]

On 09 March 2005 19:55, Frederik Eaton wrote:

> I agree that the case you're presenting is indeed more difficult, but
> I don't think you're doing the estimations right for the one at hand.
> The cost and annoyance of perhaps tens of thousands of people adding
> and remembering to maintain wrappers named 'ghc' somewhere in their
> path to accomplish this simple task (after scrounging in the
> documentation to find that ghc for some reason fails to be like many
> other compilers, a nontrivial cost in itself since the lack of
> environment variables isn't specifically documented) - or simply not
> doing so, and typing in -package-conf hundreds of times as I have
> done, because they may not have write access to the main package.conf
> - I think outweighs the cost of one person, once, adding central
> support for environment variables, a bit of documentation in the man
> page, perhaps a ghcbug program if we want super-detailed bug
> reports...

By the way, GHC 6.4 keeps a local package.conf in your home directory,
and you can install packages into it with ghc-pkg --user, or ./setup
--user for Cabal packages.

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

RE: environment variables for ghc

[Simon Marlow]

On 09 March 2005 21:13, Frederik Eaton wrote:

>>> I agree that the case you're presenting is indeed more difficult,
>>> but I don't think you're doing the estimations right for the one at
>>> hand. The cost and annoyance of perhaps tens of thousands of people
>>> adding and remembering to maintain wrappers named 'ghc' somewhere
>>> in their path to accomplish this simple task (after scrounging in
>>> the documentation to find that ghc for some reason fails to be like
>>> many other compilers, a nontrivial cost in itself since the lack of
>>> environment variables isn't specifically documented) - or simply not
>>> doing so, and typing in -package-conf hundreds of times as I have
>>> done, because they may not have write access to the main
>>> package.conf - I think outweighs the cost of one person, once,
>>> adding central support for environment variables, a bit of
>>> documentation in the man page, perhaps a ghcbug program if we want
>>> super-detailed bug reports...
>> 
>> Are you volunteering to be that person? ;-)
> 
> Are you saying that a patch would be accepted?
> 
> Frederik

We'll definitely take the environment variable patch if it comes with a
ghcbug script :-)

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

Re: environment variables for ghc

[John Meacham]

On Wed, Mar 09, 2005 at 01:12:49PM -0800, Frederik Eaton wrote:
> > > I agree that the case you're presenting is indeed more difficult, but
> > > I don't think you're doing the estimations right for the one at hand.
> > > The cost and annoyance of perhaps tens of thousands of people adding
> > > and remembering to maintain wrappers named 'ghc' somewhere in their
> > > path to accomplish this simple task (after scrounging in the
> > > documentation to find that ghc for some reason fails to be like many
> > > other compilers, a nontrivial cost in itself since the lack of
> > > environment variables isn't specifically documented) - or simply not
> > > doing so, and typing in -package-conf hundreds of times as I have
> > > done, because they may not have write access to the main package.conf
> > > - I think outweighs the cost of one person, once, adding central
> > > support for environment variables, a bit of documentation in the man
> > > page, perhaps a ghcbug program if we want super-detailed bug
> > > reports...
> > 
> > Are you volunteering to be that person? ;-)
> 
> Are you saying that a patch would be accepted?

A ghcbug script would be great IMHO. 
John

-- 
John Meacham - ârepetae.netâjohnâ 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: environment variables for ghc

[Tomasz Zielonka]

On Wed, Mar 09, 2005 at 01:12:49PM -0800, Frederik Eaton wrote:
> > Are you volunteering to be that person? ;-)
> 
> Are you saying that a patch would be accepted?

I am not the one to decide.

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

Re: environment variables for ghc

[Frederik Eaton]

> > I agree that the case you're presenting is indeed more difficult, but
> > I don't think you're doing the estimations right for the one at hand.
> > The cost and annoyance of perhaps tens of thousands of people adding
> > and remembering to maintain wrappers named 'ghc' somewhere in their
> > path to accomplish this simple task (after scrounging in the
> > documentation to find that ghc for some reason fails to be like many
> > other compilers, a nontrivial cost in itself since the lack of
> > environment variables isn't specifically documented) - or simply not
> > doing so, and typing in -package-conf hundreds of times as I have
> > done, because they may not have write access to the main package.conf
> > - I think outweighs the cost of one person, once, adding central
> > support for environment variables, a bit of documentation in the man
> > page, perhaps a ghcbug program if we want super-detailed bug
> > reports...
> 
> Are you volunteering to be that person? ;-)

Are you saying that a patch would be accepted?

Frederik

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

Re: environment variables for ghc

[Tomasz Zielonka]

On Wed, Mar 09, 2005 at 11:55:11AM -0800, Frederik Eaton wrote:
> > I am still not convinced that it is a good idea to add such
> > functionality to GHC. Do you want to persuade developers of
> > every program you use to add similar feature?
> 
> Is the perceived difficulty of that task an argument against improving
> ghc?

No, it's about avoiding unneccesary complexity.

> I agree that the case you're presenting is indeed more difficult, but
> I don't think you're doing the estimations right for the one at hand.
> The cost and annoyance of perhaps tens of thousands of people adding
> and remembering to maintain wrappers named 'ghc' somewhere in their
> path to accomplish this simple task (after scrounging in the
> documentation to find that ghc for some reason fails to be like many
> other compilers, a nontrivial cost in itself since the lack of
> environment variables isn't specifically documented) - or simply not
> doing so, and typing in -package-conf hundreds of times as I have
> done, because they may not have write access to the main package.conf
> - I think outweighs the cost of one person, once, adding central
> support for environment variables, a bit of documentation in the man
> page, perhaps a ghcbug program if we want super-detailed bug
> reports...

Are you volunteering to be that person? ;-)

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

Re: environment variables for ghc

[Frederik Eaton]

On Wed, Mar 09, 2005 at 08:14:24PM +0100, Tomasz Zielonka wrote:
> On Wed, Mar 09, 2005 at 10:27:28AM -0800, Frederik Eaton wrote:
> > On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote:
> > > 
> > > I was complaing (only to myself) that rsync doesn't allow to put some
> > > common options in ~/.rsyncrc or an environment variable. Then I simply
> > > added an alias in my .bash_profile:
> > > 
> > > alias rsync='rsync -v --progress'
> > > 
> > > Unfortunately, this is still something that developers would like to
> > > know when facing a bug report :)
> > 
> > Right. Well, to get it to work from makefiles etc., I'd need to create
> > a script in my path, something like
> > 
> > #!/bin/sh
> > ghc -i$HSPATH -package-conf $HSPKGCONF "$@"
> > 
> > And I'd call it ghc. The thing is, I'm arguing that enough people
> > would do this that we should standardize on the environment variable
> > names. Plus, yeah, as you point out, I could just as well forget to
> > mention in a bug report that 'ghc' is my own special script.
> 
> Why not simply do:
> 
> #!/bin/bash
> /usr/.../ghc $GHCOPTS "$@"
> 
> ?

OK, that's better, but the things I said still apply.

> I am still not convinced that it is a good idea to add such
> functionality to GHC. Do you want to persuade developers of
> every program you use to add similar feature?

Is the perceived difficulty of that task an argument against improving
ghc?

> For the simple case of providing the same options everytime
> shell script wrappers and aliases are the way to go.
> 
> There are more complicated case which justify extending a program in
> such way. For example, it is common that VCS's (like CVS, subversion
> and darcs) have a single executable with many sub-commands. You them in
> this way:
> 
> $ cvs get ...
> $ cvs update ...
> $ cvs status ...
> 
> You may want to provide different default options for different
> sub-commands. Possible to do with a shell script, but much, much more
> difficult. That's why at least darcs has a mechanism for setting default
> options for different sub-commands (~/.darcs/defaults or
> _darcs/prefs/defaults in a repo).

I agree that the case you're presenting is indeed more difficult, but
I don't think you're doing the estimations right for the one at hand.
The cost and annoyance of perhaps tens of thousands of people adding
and remembering to maintain wrappers named 'ghc' somewhere in their
path to accomplish this simple task (after scrounging in the
documentation to find that ghc for some reason fails to be like many
other compilers, a nontrivial cost in itself since the lack of
environment variables isn't specifically documented) - or simply not
doing so, and typing in -package-conf hundreds of times as I have
done, because they may not have write access to the main package.conf
- I think outweighs the cost of one person, once, adding central
support for environment variables, a bit of documentation in the man
page, perhaps a ghcbug program if we want super-detailed bug
reports...

Frederik

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

Re: environment variables for ghc

[Tomasz Zielonka]

On Wed, Mar 09, 2005 at 10:27:28AM -0800, Frederik Eaton wrote:
> On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote:
> > 
> > I was complaing (only to myself) that rsync doesn't allow to put some
> > common options in ~/.rsyncrc or an environment variable. Then I simply
> > added an alias in my .bash_profile:
> > 
> > alias rsync='rsync -v --progress'
> > 
> > Unfortunately, this is still something that developers would like to
> > know when facing a bug report :)
> 
> Right. Well, to get it to work from makefiles etc., I'd need to create
> a script in my path, something like
> 
> #!/bin/sh
> ghc -i$HSPATH -package-conf $HSPKGCONF "$@"
> 
> And I'd call it ghc. The thing is, I'm arguing that enough people
> would do this that we should standardize on the environment variable
> names. Plus, yeah, as you point out, I could just as well forget to
> mention in a bug report that 'ghc' is my own special script.

Why not simply do:

#!/bin/bash
/usr/.../ghc $GHCOPTS "$@"

?

I am still not convinced that it is a good idea to add such
functionality to GHC. Do you want to persuade developers of
every program you use to add similar feature?

For the simple case of providing the same options everytime
shell script wrappers and aliases are the way to go.

There are more complicated case which justify extending a program in
such way. For example, it is common that VCS's (like CVS, subversion
and darcs) have a single executable with many sub-commands. You them in
this way:

$ cvs get ...
$ cvs update ...
$ cvs status ...

You may want to provide different default options for different
sub-commands. Possible to do with a shell script, but much, much more
difficult. That's why at least darcs has a mechanism for setting default
options for different sub-commands (~/.darcs/defaults or
_darcs/prefs/defaults in a repo).

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

Re: environment variables for ghc

[Frederik Eaton]

On Wed, Mar 09, 2005 at 07:03:38PM +0100, Tomasz Zielonka wrote:
> On Wed, Mar 09, 2005 at 10:01:40AM -0800, Frederik Eaton wrote:
> > On Wed, Mar 09, 2005 at 05:19:18PM -, Simon Marlow wrote:
> > > On 09 March 2005 08:29, Frederik Eaton wrote:
> > > 
> > Oh, is that the only reason? That's a terrible reason to not have a
> > feature. :) You could just write a 'ghcbug' script which includes all
> > information automatically. See the output of 'perlbug -d' for example.
> > 
> > I guess I could write a wrapper to add the options myself ... but is
> > everybody supposed to do this who has a package.conf in their home
> > directory, or some common set of utility modules somewhere? It seems
> > like a fairly common use case that should be well-supported in a
> > standard way out of the box.
> 
> I was complaing (only to myself) that rsync doesn't allow to put some
> common options in ~/.rsyncrc or an environment variable. Then I simply
> added an alias in my .bash_profile:
> 
> alias rsync='rsync -v --progress'
> 
> Unfortunately, this is still something that developers would like to
> know when facing a bug report :)

Right. Well, to get it to work from makefiles etc., I'd need to create
a script in my path, something like

#!/bin/sh
ghc -i$HSPATH -package-conf $HSPKGCONF "$@"

And I'd call it ghc. The thing is, I'm arguing that enough people
would do this that we should standardize on the environment variable
names. Plus, yeah, as you point out, I could just as well forget to
mention in a bug report that 'ghc' is my own special script.

Frederik

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

Re: environment variables for ghc

[Tomasz Zielonka]

On Wed, Mar 09, 2005 at 10:01:40AM -0800, Frederik Eaton wrote:
> On Wed, Mar 09, 2005 at 05:19:18PM -, Simon Marlow wrote:
> > On 09 March 2005 08:29, Frederik Eaton wrote:
> > 
> Oh, is that the only reason? That's a terrible reason to not have a
> feature. :) You could just write a 'ghcbug' script which includes all
> information automatically. See the output of 'perlbug -d' for example.
> 
> I guess I could write a wrapper to add the options myself ... but is
> everybody supposed to do this who has a package.conf in their home
> directory, or some common set of utility modules somewhere? It seems
> like a fairly common use case that should be well-supported in a
> standard way out of the box.

I was complaing (only to myself) that rsync doesn't allow to put some
common options in ~/.rsyncrc or an environment variable. Then I simply
added an alias in my .bash_profile:

alias rsync='rsync -v --progress'

Unfortunately, this is still something that developers would like to
know when facing a bug report :)

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

Re: environment variables for ghc

[Frederik Eaton]

On Wed, Mar 09, 2005 at 05:19:18PM -, Simon Marlow wrote:
> On 09 March 2005 08:29, Frederik Eaton wrote:
> 
> > Is it possible to set environment variables which ghc will look at,
> > corresponding to command line options such as '-i' or '-package-conf'?
> > I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's
> > PERL5LIB or even PERL5OPT (which is the most flexible). These would be
> > really convenient since I have a package.conf file in my home
> > directory for locally installed packages, and some modules in another
> > directory that I often link to.
> 
> There's the GHCRTS environment variable that you can use for setting
> heap sizes and so on, and the ~/.ghci file, but nothing for setting ghc
> command-line arguments.  We're a bit wary of adding more things that we
> have to ask for in a bug report...

Oh, is that the only reason? That's a terrible reason to not have a
feature. :) You could just write a 'ghcbug' script which includes all
information automatically. See the output of 'perlbug -d' for example.

I guess I could write a wrapper to add the options myself ... but is
everybody supposed to do this who has a package.conf in their home
directory, or some common set of utility modules somewhere? It seems
like a fairly common use case that should be well-supported in a
standard way out of the box.

Frederik

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

RE: Registerised x86_64 port: test version available

[Simon Marlow]

On 09 March 2005 10:14, Ralf Hinze wrote:

> this is just to let you know that I successfully compiled the lastest
> snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks!
> 
> Cheers, Ralf
> 
> PS: Just curious: is the gcc route easier than the NCG? To me it seems
> much more fragile.

It's initially easier to get going, but yes it's more fragile.
Currently we can't go it alone with the NCG because the NCG isn't quite
capable of compiling the hand-written .cmm files in the runtime.  At
some point we'll fix this.

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

RE: environment variables for ghc

[Simon Marlow]

On 09 March 2005 08:29, Frederik Eaton wrote:

> Is it possible to set environment variables which ghc will look at,
> corresponding to command line options such as '-i' or '-package-conf'?
> I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's
> PERL5LIB or even PERL5OPT (which is the most flexible). These would be
> really convenient since I have a package.conf file in my home
> directory for locally installed packages, and some modules in another
> directory that I often link to.

There's the GHCRTS environment variable that you can use for setting
heap sizes and so on, and the ~/.ghci file, but nothing for setting ghc
command-line arguments.  We're a bit wary of adding more things that we
have to ask for in a bug report...

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

Re: Registerised x86_64 port: test version available

[Ralf Hinze]

Hi Simon,

this is just to let you know that I successfully compiled the lastest
snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks!

Cheers, Ralf

PS: Just curious: is the gcc route easier than the NCG? To me it seems
much more fragile.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

environment variables for ghc

[Frederik Eaton]

Is it possible to set environment variables which ghc will look at,
corresponding to command line options such as '-i' or '-package-conf'?
I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's
PERL5LIB or even PERL5OPT (which is the most flexible). These would be
really convenient since I have a package.conf file in my home
directory for locally installed packages, and some modules in another
directory that I often link to.

Frederik

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

RE: infix type operators

[Simon Peyton-Jones]

OK, it's done for 6.4

SImon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Ross Paterson
| Sent: 08 March 2005 16:29
| To: glasgow-haskell-users@haskell.org
| Subject: infix type operators
| 
| The User's Guide says:
| 
|   The only thing that differs between operators in types and
|   operators in expressions is that ordinary non-constructor
|   operators, such as + and * are not allowed in types.  Reason:
|   the uniform thing to do would be to make them type variables,
|   but that's not very useful.  A less uniform but more useful
thing
|   would be to allow them to be type constructors.  But that gives
|   trouble in export lists.  So for now we just exclude them.
| 
| Conal has pointed out that the uniform thing would be useful for
| general arrow combinators:
| 
|   liftA2 :: Arrow (~>) =>
|   (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c)
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Another GHC 6.4 Release Candidate Binary for Mac OS X

[Wolfgang Thaller]

Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Features:
*) all the normal GHC 6.4 features
*) dynamic linking
*) nice icons you can double-click to open a terminal window with ghci
(one for H98 and one for -fglasgow-exts)
*) You can even drag your favourite .hs files onto those icons!
*) a simple uninstaller
*) html documentation now included
Mac users, please start testing and send lots of feedback to me and to 
the list.

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

RE: infix type operators

[Simon Peyton-Jones]

Yes, that makes sense.  I think I will do that.  Whether it'll make it
into 6.4 is doubtful

S

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Ross Paterson
| Sent: 08 March 2005 16:29
| To: glasgow-haskell-users@haskell.org
| Subject: infix type operators
| 
| The User's Guide says:
| 
|   The only thing that differs between operators in types and
|   operators in expressions is that ordinary non-constructor
|   operators, such as + and * are not allowed in types.  Reason:
|   the uniform thing to do would be to make them type variables,
|   but that's not very useful.  A less uniform but more useful
thing
|   would be to allow them to be type constructors.  But that gives
|   trouble in export lists.  So for now we just exclude them.
| 
| Conal has pointed out that the uniform thing would be useful for
| general arrow combinators:
| 
|   liftA2 :: Arrow (~>) =>
|   (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c)
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

environment variables for ghc

[Frederik Eaton]

Is it possible to set environment variables which ghc will look at,
corresponding to command line options such as '-i' or '-package-conf'?
I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's
PERL5LIB or even PERL5OPT (which is the most flexible). These would be
really convenient since I have a package.conf file in my home
directory for locally installed packages, and some modules in another
directory that I often link to.

Frederik

-- 
http://ofb.net/~frederik/

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