On Mon, 6 Nov 2006 21:32:39 -0600
"Quan Ta" <[EMAIL PROTECTED]> wrote:
> how about searching code that's outside of the standard library? Hoogle
> doesn't seem to know about HaXml, or haskelldb for example (maybe I am
> missing something obvious)
You want to distinguish between capabilities, and
how about searching code that's outside of the standard library? Hoogle doesn't seem to know about HaXml, or haskelldb for example (maybe I am missing something obvious)Quan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://
Hi Fredrick,
I have a perl script which I call 'hsman', which indexes
Haddock-generated HTML files, and allows users to search for functions
and also GHC manual topics.
Have you seen hoogle? http://haskell.org/hoogle - what features does
your program offer over hoogle, and would you be interes
I would definitely like something like this.
like
{-# PREPROCESS drift-ghc #-}
to specify the file should be preprocced by drift-ghc.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@hask
Hello,
I have a perl script which I call 'hsman', which indexes
Haddock-generated HTML files, and allows users to search for functions
and also GHC manual topics. For instance, I can run:
$ hsman foldl
to open the documentation on 'foldl'. There is also tab-completion in
zsh.
If people think th
Hi
Just for completeness, I came up with a proposal that would solve all
this, but in a very non-cabal style way.
Taking an example of happy, every generated file (File.hs) would have
as its first line:
{-# ORIGIN happy sourcefile.y -options -to -happy #-}
Then you just modify all haskell gene
I think this kind of build system feature ought to go into Cabal so it
can be used more widely and without people needing Makefiles.
I admit that we're not there yet with how easy it is to generate source
files.
Duncan
On Mon, 2006-11-06 at 21:12 +, Frederik Eaton wrote:
> Hello,
>
> I have
Hello,
I have a proposal for ghc. I think that it should take a new option,
say "--make-command". This will specify a command to be run whenever a
source file is read in by ghc. The command will be passed an argument,
which is the name of the source file. The idea is that the command can
be used t
Dear GHC Hackers,
I'm using the GHC API for a project of mine. I have a question about the way
GHC 'desugars' the following overloaded function:
incL :: (Num a) => [a] -> [a]
incL [] = []
incL (x : xs) = (1 + x) : (incL xs)
After calling 'Desugar.deSugar' on this function I get the follow
On Mon, Nov 06, 2006 at 06:25:48PM +, Malcolm Wallace wrote:
> When I use `seq`, it is sometimes in a construction like
>
> unsafePerformIO (emit "squawk!) `seq` x
>
> where I am trying to force the impure side-effect to happen, exactly and
> immediately before x is evaluated. Whilst thi
Ross Paterson <[EMAIL PROTECTED]> wrote:
> When I've used seq, it's to ensure that a function is strict in that
> argument, and therefore has been evaluated before the function is
> called. (If the language had unlifted types, I might have used those
> instead). Beyond that, I don't care exactly w
On Mon, November 6, 2006 9:21 am, Ross Paterson wrote:
> On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote:
>> So the doubly bizarre thing is that, actually, `seq` does not control
>> the evaluation order (which is the only valid reason for wanting to use
>> it in the first place), b
On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote:
> So the doubly bizarre thing is that, actually, `seq` does not control
> the evaluation order (which is the only valid reason for wanting to use
> it in the first place), but nevertheless it undesirably changes the
> semantics of pro
Malcolm Wallace wrote:
Indeed, `seq` is widely viewed as a wart on the language _because_ it
specifies the evaluation order, which is something otherwise avoided in
the Report.
I don't agree with that statement - the main problem with (polymorphic) seq is
that its existence implies that the f
Simon Marlow <[EMAIL PROTECTED]> wrote:
> The report is in general very careful to say absolutely *nothing*
> about evaluation order, leaving the implementation free to choose,
Yes, this is a highly desirable goal.
> However, having said all that, arguably an exception should be made in
> this
Malcolm Wallace wrote:
Simon Marlow <[EMAIL PROTECTED]> wrote:
The difference is subtle. The semantics of seq and pseq are
identical; however, GHC can see that seq is strict in both its
arguments and hence could choose to evaluate them in either order,
whereas pseq is only strict in its fir
Matthew
Thanks for submitting the Trac bug. I don't know what the answer to
your qn below is, but maybe someone else on ghc-users does. Meanwhile,
I added the qn to the bug report.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| On Behalf Of SevenThun
17 matches
Mail list logo
