Also got email error for my last message, so I'm reposting it below with some
more information. From a technical point of view changes to Alex and Happy are
simple and already implemented on my branch:
https://github.com/jstolarek/alex/commit/32d4244894ae2702d965415483d0479d91570049
OK, that's fine. Thanks!
Simon
From: Nicolas Frisby [mailto:nicolas.fri...@gmail.com]
Sent: 10 September 2013 19:18
To: Simon Peyton-Jones
Cc: Luite Stegeman; Edsko de Vries; Thomas Schilling; ghc-devs
Subject: Re: extending GHC plugins with Hooks
My patch was extremely simple, so I'm asking
Hello GHC devs,
...as the topic came up in #ghc, what's the current rationale for keeping
HUGS-specific code sprinkled throughout GHC boot libraries?
I quick tally in GHC's source tree via
find -type f -iname '*.*hs' | xargs grep '#if.*HUGS' | cut -f1-3 -d/ | uniq -c
results in
1
Somebody claiming to be Herbert Valerio Riedel wrote:
Does anyone actually still use/test those packages in HUGS?
I know lots of people still using HUGS.
(When) can that code be removed?
When enough features become standard that it becomes unnecessary ;)
--
Stephen Paul Weber, @singpolyma
Hi all,
So I managed to remove 3 out of 4 of the -boot files. The one that
remains, ironically, is the DsMonad.hs-boot. DsMonad has a
(transitive) dependency on Hooks in at least two ways: once through
Finder, which imports Packages, which imports Hooks; but that's easily
solved, because Finder
I'm ok with that, thanks.
Can you put your comments below into DsMonad.hs-boot so that we don't lose the
reasoning? It's devilish hard to work out *why* a hs-boot file must exist,
sometimes.
Maybe also update
http://ghc.haskell.org/trac/ghc/wiki/Commentary/ModuleStructure
which tries to
On Wed, 2013-09-11 at 17:28 +0100, Duncan Coutts wrote:
Further, if only ghc-pkg and the ghc build system depend on Cabal, then
it is easier for Cabal to add more dependencies, since they do not have
to be installed with ghc (due to the ghc lib depending on them). In
particular the Cabal
On Wed, Sep 11, 2013 at 12:19 PM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
Actually, this is not quite right. Since ghc would still ship Cabal (but
not depend on it), it would also ship its dependencies including parsec,
mtl and transformers. So they would need to be up to date and
Hi Herbert,
On 09/08/2013 04:43 AM, Herbert Valerio Riedel wrote:
Hello Nicolas,
On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
I just merged in my -fdicts-strict work, so I was deleting the old
branch…
but it's rejected for some reason.
$ git push origin --delete dicts-strict
wasn't there an effort to have a mini private variant of attoparsec for the
parser combinator deps?
On Wed, Sep 11, 2013 at 4:03 PM, Johan Tibell johan.tib...@gmail.comwrote:
On Wed, Sep 11, 2013 at 12:19 PM, Duncan Coutts
duncan.cou...@googlemail.com wrote:
Actually, this is not quite
hey all,
first let me preface by saying I am in favor of breaking and
updating/modernizing the GHC ABI.
I just think that for a number of reasons, it doesn't make sense to do it
for the 7.8 release, but rather start work on it in another month or so, so
we can systematically have a better set of
Can you provide an example of the kind of ABI change you might want for
7.10? Is it mainly using more registers to pass arguments? We're already
using 6 *mm* registers to pass arguments on x86_64. I don't know for
sure, but I would be very surprised if there is code out there that
would benefit
On Wed, Sep 11, 2013 at 3:59 PM, Geoffrey Mainland mainl...@apeiron.netwrote:
I don't see why we should limit ourselves by insisting that the gap
between what the LLVM back-end and the native back-end not grow further.
If we want SIMD, the gap is already quite large. Yes it would be nice to
On 09/11/2013 07:33 PM, Johan Tibell wrote:
On Wed, Sep 11, 2013 at 3:59 PM, Geoffrey Mainland mainl...@apeiron.net
wrote:
I don't see why we should limit ourselves by insisting that the gap
between what the LLVM back-end and the native back-end not grow
further.
If we want
On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland mainl...@apeiron.netwrote:
Do you mean we need a reasonable emulation of the SIMD primops for the
native codegen?
Yes. Reasonable in the sense that it computes the right result. I can see
that some code might still want to #ifdef (if the
We support compiling some code with -fllvm and some not in the same
executable. Otherwise how could users of the Haskell Platform link their
-fllvm-compiled code with native-codegen-compiled libraries like base, etc.?
In other words, the LLVM and native back ends use the same calling
convention.
Hi devs,
I'm in the process of reimplementing role annotations (#8185). I need to add a
new pseudo-keyword 'role' to the lexer, and I'm initially tempted to guard the
lexing of this keyword with an extension bit (like, say, tyFamBit in Lexer.x).
But, there are already bits 0 to 31 taken, and
17 matches
Mail list logo
