Alastair Reid <[EMAIL PROTECTED]> writes:
> > I thought we established that generating valid C prototypes from the
> > Haskell FFI type signature wasn't possible due to the incompleteness
> > of the Haskell type (lack of 'const' modifiers for one thing - is
> > there anything else?).
>
> Compile
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> Ok, so in general a 'scope' can be constructed by combining:
>
>1. the full top-level scope from zero or more *interpreted* modules
>2. the exports of zero or more modules (interpreted or compiled)
>3. any temporary bindings made on the co
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> > I've seen unexpected compiles using ghc --make. I've got a system
> > with modules A, B, and C; A depends on B and B depends on C. I've
> > seen the following sequence of events:
> >
> > I change C
> > ghc --make A compiles C, B, and A
> > I chang
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> GHC actually has rather sophisticated recompilation checking which
> goes beyond just checking whether the interface changed - it keeps
> version information for each entity exported by a module and only
> recompiles if any of the entities actually use
Nicolas <[EMAIL PROTECTED]> writes:
> Hi there,
> Sorry for this stupid question:
> Is there a distrib of a HOpenGl package working with ghc 5.02. I tried
> the CVS but don't manage to make it work (ghc 5.03 panic).
> Can someone help me?
I got HOpenGL to work without trouble. On September 29,
Leon Smith <[EMAIL PROTECTED]> writes:
> However, in this situation, pointer comparison is simply an arbitrary total
> order on the set of all atoms, which is all we need to implement finite maps
> based on search trees. And of course, pointer comparisons are a much cheaper
> operation that a
"Sigbjorn Finne" <[EMAIL PROTECTED]> writes:
> "Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> writes:
> >
> > Hmm, we're looking at this. However, I don't really know what
> > C is or is not supposed to do here. Given
> >
> > char fooble ( ... )
> > {
> >return 'z';
> > }
> >
> > on a
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> You obtain the ordering properties by setting the handle to NoBuffering,
> otherwise you get buffered input/output. Wouldn't it be deviating from
> the report to do extra flushing in the buffered case? (this is
> something of a technicality, actually
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> I didn't say that this works for any kind of parser
> combinator, I merely said that it works Doitse's and mine.
> Both implement SLL(1) parsers for which - as I am sure, you
> know - there exists a decision procedure for testing
> ambiguit
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> I don't think, the point is the test for non-ambiguity. At
> least, Doitse's and my self-optimising parser combinator
> library will detect that a grammar is ambigious when you
> parse a sentence involving the ambiguous productions. So,
>
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> I am not a parsing expert, but given the recent discussion on macros, I
> have to ask: why use happy rather than monadic parsing? Monadic parsing
> allows you to avoid a whole additional language/compilation step and work
> in Hugs (where you
Simon Marlow <[EMAIL PROTECTED]> writes:
> > The merge sorting costs O( n*log(n) ), so it is good in any case.
> > Why not implement it?
>
> GHC's sort implementation is a well-optimised quicksort plundered originally
> from the hbc library I believe. In your example above you mention testing
12 matches
Mail list logo