> Hi,
>
> since you both only mention hasktags as an alternative, I
> wonder how ghctags relates to :ctags/:etags in ghci?
>
> http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
Doco suggests that this code is just calling hasktags.
How would I know for sure?
> Norman
> Hello nr,
>
> Saturday, October 14, 2006, 12:30:54 AM, you wrote:
> > The ultimate goal is to replace hasktags with
> > a tags generator based on GHC-as-a-library.
>
> is this working at this time? how i can download/use it?
It works, but there are two serious problems:
1. Incor
> [redirecting to ghc users]
>
> It looks like a splendid error to me.
I'm not sure if you meant the error or the message was splendid :-)
I yelled for help because my usual strategy failed. That strategy is
1. Remove the type annotation.
2. Get ghci to tell me what the 'right type' is.
sible fix', and indeed instead suggesting 'possible fix: remove
the type signature from f'?
>
> Simon
>
> | -Original Message- From:
> | [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
> | [EMAIL PROTECTED] On Behalf Of Norman Ramsey Sent: 06 December 2006
>
I've just discovered the {-# INLINE #-} pragma, but it's not
doing as much for me as I had hoped.
My example is complicated, so let me present a simpler analogy.
Suppose I defined
compose :: (b -> c) -> (a -> b) -> (a -> c)
compose f g = \x -> f (g x)
I can easily persuade GHC to inline 'compose
> On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote:
> > Hi,
> >
> > our developers that have a debian system (i.e Ubuntu) and want to
> > compile our sources with ghc complain that they have to install many
> > extra library packages one after another.
> >
> > Compiling fa
As a very part-time, temporarily inactive GHC developer I will offer
some opinions which should carry no weight:
* When I saw the announcement, I cheered! Last fall, I lost 2 weeks
of a 9-week visit to darcs hell. While the alleged features may
be alluring, the software simply doesn't
> On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote:
> >
> > * Our long-term goal should be to get the *entire* Haskell
> > development community to agree on a version-control system---one
> > that is not darcs. We should expect t
> > I see an increasing problem in that every community comes up with
> > their own package system, instead of reusing existing frameworks.
>
> That's because there are no usable existing frameworks.
I couldn't agree more. I have been working on this problem off and on
since 1993, and the
> Simon PJ and I had a talk about the build system earlier today, I thought
> I'd float the idea we discussed...
> I propose we do this:
>
> - Extract the code from Cabal that generates Makefiles, and treat it as
> part of the GHC build system. Rather than generating a Makefile
>
> ... exhaustive pattern checking might well help out a lot of
> people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the altar of
exhaustiveness checking.
> Anyone know why it isn't the default?
I have been bleating to GHC Central about the generally
> > > ... exhaustive pattern checking might well help out a lot of
> > > people coming from untyped backgrounds...
> >
> > Or even people from typed backgrounds. I worship at the altar of
> > exhaustiveness checking.
>
> Do you really want exhaustiveness, or is what you actually want saf
I'm trying to log into the trac wiki, and I'm logging in OK, but it says
my privileges are restricted until I verify my email address.
However, the promised opportunity to verify never arrives.
I've checked the spam folder and various other places---not finding it.
I could be doing something stupid
> It's time to consider again whether we should migrate GHC development
> from darcs to (probably) git.
I'd be thrilled to see GHC migrate to git, and I'd be much more likely
to make new contributions to the back end.
The rest of this email contains observations about my own experience
with so
14 matches
Mail list logo
