I'm anxious about it being too big a change too.
I'd be up for it if we had several customers all saying yes, this is
precisely what we need to make our usage of the GHC API far far easier. With
enough detail so we can understand their use-case.
Otherwise I worry that we might go to a lot of
I tend to agree that this change is much too intrusive for what it attempts
to do.
I think the concept of a node key could be workable, and ties in to the
approach I am taking in ghc-exactprint [1], which uses a SrcSpan together
with node type as the annotation key.
[1]
Hello,
What semantics are you using for recursive modules? As far as I see, if
you take a least fixed point semantics (e.g. as described in A Formal
Specification for the Haskell 98 Module System,
http://yav.github.io/publications/modules98.pdf ) this program is incorrect
as the module does not
If there is to be such a language feature, I strongly feel it should be via
something like
module Long.Name.M( f, g, h ) as K where ...
I do not want to try to piggy-back on the possible meaning of a self-import;
it’s just asking for trouble, as Iavor points out.
Using “as M” in
On further reflection of the goals for the annotation, I would like to put
forward the following proposal for comment
Instead of physically placing a node-key in each AST Node, a virtual
node key can be generated from any `GenLocated SrcSpan e' comprising a
combination of the `SrcSpan` value and
Yes, that is the semantics I use for recursive module imports in jhc. And
you are right in that it does not accept those examples due to being unable
to bootstrap the least fixed point.
How would the 'as M' proposal interact? Would it actually be new entries in
the name table or rewritten as a
Hi *,
Here's the latest weekly news post:
https://ghc.haskell.org/trac/ghc/blog/weekly20140930
Included verbatim for those too lazy to open new tabs:
Hi *,
Here's some news for y'all! Apologizes about the unavailability last
week; the internet wasn't exactly a very fun place
Hello developers, users, friends,
I'd like you all to weigh in on something - a GHC bug report, that has
happened as a result of making Applicative a superclass of Monad:
https://ghc.haskell.org/trac/ghc/ticket/9590
The very condensed version is this: because haskell2010/haskell98
packages try
I hate #1. Let's avoid if unless it's really crucial to some of our users.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin
| Seipp
| Sent: 30 September 2014 21:21
| To: ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org
|
Hi,
the attached graph shows a noticable increase in build time caused by
Update Cabal submodule ghc-pkg to use new module re-export types
author Edward Z. Yang ezy...@cs.stanford.edu
https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae
and only halfway mitigated by
Hello Joachim,
This was halfway known, but it sounds like we haven't solved
it completely.
The beginning of the sordid tale was when Cabal HEAD switched
to using derived binary instances:
https://ghc.haskell.org/trac/ghc/ticket/9583
SPJ fixed the infinite loop bug in the simplifier, but
How about doing the honest thing, and withdrawing both packages in ghc-7.10?
Haskell'98 is now 15 years old, and the 2010 standard was never really popular
anyway.
Regards,
Malcolm
On 30 Sep 2014, at 21:21, Austin Seipp aus...@well-typed.com wrote:
Hello developers, users, friends,
I'd
Gintautas, and other folk building GHC on Windows,
There has been some activity on the “GHC on Windows” front, which is great.
Some time ago I wrote:
I would love it if you guys formed a GHC-on-Windows Task Force, who tried to
make sure that the Windows experience was always good. At the
Hi Edward,
This is possibly unrelated, but the setup seems almost identical to a very
similar problem we had in some code, i.e. very long compile times (6+
minutes for 1 module) and excessive memory usage when compiling generic
serialization instances for some data structures.
In our case, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm working with my qnx-nto-arm cross-compiler again. I still have the
issue where I get link errors about __aeabi_memcpy and similar. I am able
to solve this problem by always adding -lcaps to ghc invocations. I'm still
not sure if that
Hi all,
I'm trying to implement https://ghc.haskell.org/trac/ghc/ticket/5364 ,
I did the coding part but I'm having trouble compiling it/adding it as
a part of GHC libraries.
My library is just one hsc file with a line `#include Rts.h` in it.
Any ideas what should I do to make it compiled with
16 matches
Mail list logo
