> How do you suggest getting around copyright issues?
LIke Eric said - by posting pre-prints. I think this should be legal.
Note also these two clauses in the ACM Copyright Agreement:
1. "Copyright to the Work (...) is hereby transferred to the ACM (...)
effective as of the date
of this agreem
Thanks for the explanation, Simon. I think Eric is spot on. Looking at some
of the "ghc -v3" output, it appears GHC always runs the following passes
before any plugins are run:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
*** Desugar:
Just judging by the name, it could either be the f
I think a lot of conferences allow authors to host pre-prints elsewhere,
like arXiv. We could ask the authors of the relevant papers to make the
submission and then update the links on the Reading List. (Perhaps arXiv
even has some sort of collection feature?)
But you're right that we probably can
How do you suggest getting around copyright issues? I think that's a real
barrier to this (good) idea.
Richard
On Dec 7, 2015, at 2:23 PM, Jan Stolarek wrote:
> I know this is a bit old, but I just had a thought that perhaps we could
> archive GHC papers on
> arxiv.org? This should be perman
> Aren't those already guaranteed to be strict because of pattern matching? Try
> it again with irrefutable patterns.
But pattern matching only forces the evaluation up to the pattern that is
matched. We need another pattern matching(or seq etc.) on x, y, xs and ys here.
If you look at the generat
On Mon, Dec 7, 2015 at 8:40 PM, Ömer Sinan Ağacan
wrote:
> With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
> about
> the motivation behind this, I found this interesting. I always thought
> -XStrict
> gives me this guarantee: If I'm using an already-defined variable(bound
Let's say I have this code:
zip :: [a] -> [b] -> [(a, b)]
zip [] [] = []
zip (x : xs) (y : ys) = (x, y) : zip xs ys
With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering about
the motivation behind this, I found this interesting. I always thought -XStrict
gives me t
Fine with me!
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 07 December 2015 19:23
| To: ghc-devs@haskell.org
| Subject: Re: A GHC Library
|
| I know this is a bit old, but I just had a thought that perhaps we could
I'm on track for that. Did a bunch of performance-related debugging over the
weekend, and I can observe nice improvements. Just checking those fixes now. If
the results are acceptable, I have to double-check testsuite wibbles and then
I'll rebase, validate, and push.
Richard
On Dec 7, 2015, at
Andrés Sicard-Ramírez writes:
> On 2 December 2015 at 01:54, Jens Petersen wrote:
>> On 29 November 2015 at 23:54, Ben Gamari wrote:
>>> On that note, 7.10.3 is coming. At the moment I am blocked on getting a
>>> Cabal release tagged but hopefully this will happen Real Soon Now(TM).
>>
>> Cool
Oh I forgot to mention that I was testing on my local branch which fixes
precisely this kind of bug when the CallStack is used inside a let-binder,
which is what happens in rewriteEqEvidence.
So it looks like my patch takes care of this issue. Thanks for the report!
Sent from my iPhone
> On D
On Dec 7, 2015, at 2:23 PM, Eric Seidel wrote:
> After staring at your bug confusedly for a few minutes, wondering why I
> couldn't simplify it, I realized that the actual warning I was getting
> was in *mkTcTransCo*, not rewriteEqEvidence. mkTcTransCo does not in
> fact use a CallStack (by defa
I know this is a bit old, but I just had a thought that perhaps we could
archive GHC papers on
arxiv.org? This should be permanent and with a bit of effort we can get around
copyright issues
(I think). Surprisingly little Haskell research can be found on arXiv and
perhaps it is time we
change
> > As quite a separate point from above, I may have found a bug: I put a
> > (?callstack :: CallStack) constraint on TcEvidence.mkTcTransCo and then
> > put the same constraint on TcCanonical.rewriteEqEvidence. GHC complained
> > about a redundant constraint on rewriteEqEvidence, and indeed its ca
Simon's right, you need an explicit conversion, and unfortunately those
conversions don't currently exist. You would have to add them to the
MachOp type, and implement them in each of the native code generators.
The good news is that if you did this, we could implement cheap
conversions betwe
Note that int2Float# converts an Int# to the Float# with the same numeric
value (e.g. 72 -> 72.0), not the one with the same bit representation
(which doesn't really make sense anyways since Int# and Float# may be
different sizes). So I think it's not what you want.
At least on x86_64, it's rather
It would not be hard to stop the desugarer dropping dead bindings, if that was
helpful.
S
| -Original Message-
| From: Eric Seidel [mailto:e...@seidel.io]
| Sent: 07 December 2015 15:44
| To: Simon Peyton Jones
| Cc: Levent Erkok ; omeraga...@gmail.com;
| ezy...@mit.edu; ghc-devs@
Thanks Simon, primops worked fine, but not I'm getting assembler errors(even
though -dcore-lint, -dstg-lint and -dcmm-lint are all passing).
The error is caused by this STG expression:
case (#,#) [ds_gX8 ds_gX9] of _ {
(#,#) tag_gWR ubx_gWS ->
case tag_gWR of tag_gWR {
The problem, as I recall, is that GHC does an initial bit of dead-code
elimination in the desugarer, before the plugins have a chance to run.
(I believe this is part of simpleOptPgm, but may be mistaken)
I'm not sure why this is done in the desugarer, it seems to be out of
place there.
On Mon, D
On 2 December 2015 at 01:54, Jens Petersen wrote:
> On 29 November 2015 at 23:54, Ben Gamari wrote:
>> On that note, 7.10.3 is coming. At the moment I am blocked on getting a
>> Cabal release tagged but hopefully this will happen Real Soon Now(TM).
>
> Cool - Cabal-1.22.5.0 went into Stackage Nig
On Mon, Dec 7, 2015, at 06:15, Richard Eisenberg wrote:
> And sorry if my tone on those emails was a bit snarky. It was late...
> though snarkiness at any hour is unwelcome. :)
>
> I understand the concerns about the Show instance, though I have no
> opinion about the name of the pretty-printer.
Richard
What’s your ETA on the kind-equality stuff? We wondered in today’s call. We
want to make an RC next week.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
And sorry if my tone on those emails was a bit snarky. It was late... though
snarkiness at any hour is unwelcome. :)
I understand the concerns about the Show instance, though I have no opinion
about the name of the pretty-printer. My only request is that the pretty-print
function is easily disc
Simon Peyton Jones writes:
> Plugins get to edit the entire core-to-core pipeline! There is no magic. At
> least I don’t think so
>
> file:///Z:/tmp/users_guide/compiler-plugins.html
>
Or for those of us who aren't using Simon's desktop...
http://downloads.haskell.org/~ghc/master/users-guide/
tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release.
Hello everyone,
As you likely know, the GHC 8.0 release cycle is quickly drawing to a
close. One of the tasks that remains outstanding is porting the patches
on Haddock's `ghc-head` branch to `master`. This task is bound to
| OK, fine. Is there a way to make it an error, but keep checking the
| rest of the module? My goal is *get both messages if possible*, within
| a module. I'm not tied to any particular mechanism of doing so.
Yes it'd be possible. A bit fiddly, but certainly possible.
Of course, doing so can
Plugins get to edit the entire core-to-core pipeline! There is no magic. At
least I don’t think so
file:///Z:/tmp/users_guide/compiler-plugins.html
S
From: Levent Erkok [mailto:erk...@gmail.com]
Sent: 07 December 2015 13:11
To: Simon Peyton Jones
Cc: Eric Seidel ; omeraga...@gmail.com; ezy..
That's a good point; keeping all annotated bindings alive seems to be an
overkill..
Regarding implementing "pass at the start." I'm not sure if plugin authors have
any freedom as to decide when their plugin actually runs. It seems GHC
magically determines the order and runs them. Can you point
Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC
should keep it alive.
Really? It might be something like “don’t give warnings for this binding” or
“don’t inline me” or something. To say *any* annotation seems a bit brutal
doesn’t it?Mind you I don’t have a bette
Indeed. How about this: if there's an ANN on a binder (any ANN), then GHC
should keep it alive.
Is that something one of the core-developers can implement? Happy to open a
ticket if that helps.
> On Dec 7, 2015, at 4:14 AM, Simon Peyton Jones wrote:
>
> If it's "dead" in this sense, it's alr
On 07/12/15 11:59, Ben Gamari wrote:
>> If the name "showCallStack" suggests the compiler-derived output, we
>> could change it to something like "prettyCallStack" or
>> "formatCallStack", I don't have a strong opinion there.
>
> I have also struggled with these sorts of naming decisions. The
> ov
If memory serves, there are primops for converting between unboxed values of
different widths.
Certainly converting between a float and a non-float will require an
instruction on some architectures, since they use different register sets.
Re (2) I have no idea. You'll need to get more informat
If it's "dead" in this sense, it's already removed from ModGuts, no?
Yes, if it’s dead it’s gone. That’s not too surprising, is it?
So you need a way to keep it alive. Maybe we need a pragma for that. Or how
would you like to signal it in the source code?
Simon
From: Levent Erkok [mailto:e
Thanks Simon.. But I remain utterly confused. As a "plugin" author, how do I
get my hands on the Id associated with a top-level binder? If it's "dead" in
this sense, it's already removed from ModGuts, no?
That is, by the time GHC runs my plugin, the Id has already disappeared for me
to mark it
Richard Eisenberg writes:
> On Dec 5, 2015, at 9:01 AM, Ben Gamari wrote:
>
>> Richard Eisenberg writes:
>>
>>> I just tried to update D808, but the following happened. Any ideas?
>>>
>> I'm afraid I don't know what to say here. Austin, do you know what is
>> happening?
>>
>> Does Phabricato
Eric Seidel writes:
> Hi Richard,
>
> Sorry for all of the confusion, it seems the docs do indeed need some
> love!
>
> On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote:
>> That looks like exactly what I want. Thanks.
>>
>> There remain two mysteries:
>> - I thought that CallStacks were a
If you're debugging GHC, I've recently added pprSTrace :: (?location ::
CallStack) => SDoc -> a -> a in Outputable. It's been a great help for me
in understanding where the calls were coming from. You can just use it
without importing anything extra, and when you want more context you just
add (?l
In the mean time, I'm still looking for a solution that doesn't involve
exporting such identifiers from modules. As Eric pointed out, that seems to be
the only current work-around for the time being.
“Exported” in this context only means “keep alive”. It does not mean exported
in the Haskell so
38 matches
Mail list logo