Update the documentation in MAKEHELP to make it clear that "make html"
isn't supposed to work from the top level.
---
MAKEHELP |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAKEHELP b/MAKEHELP
index 85497e9..fb8c688 100644
--- a/MAKEHELP
+++ b/MAKEHELP
@@ -25,9 +25,
Simon Peyton-Jones writes:
> My goal is to use your travels through GHC to make the journey for the
> next person easier.
> ...
> "How could I write some notes (probably in the code) so that
> I'd have understood it a lot quicker?"
Excerpts from Adam Megacz's message of Sun Apr 24 18:14:16 -040
The (new) commentary describes a mechanism for creating "links" from
inline/interleaved comments to detached comments:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#Commentsandcommitmessages
Is Haddock aware of this mechanism on some level? If not, does it have
a similar me
Understanding GHC.Prim.Any is all about understanding the need for
explicit type applications in CoreSyn; the previous example had one
explicit type application but was missing the other, which this patch
adds. It also expands the explanation, based on SPJ's post here:
http://article.gmane.org/
Update the documentation in MAKEHELP to make it clear that "make html"
isn't supposed to work from the top level.
---
MAKEHELP |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAKEHELP b/MAKEHELP
index 85497e9..fb8c688 100644
--- a/MAKEHELP
+++ b/MAKEHELP
@@ -25,9 +25,
Simon Peyton-Jones writes:
> No. The primary use for Any is to fix otherwise-unconstrained type variables.
> ...
> length Any ([] Any)
Ah, I get it! Thanks.
- a
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/l
Simon Peyton-Jones writes:
> Do you mean that GHC itself is seg-faulting, or that a program it
> compiles is seg-faulting?
It's coming from GHC itself, after I have added in some extra code.
That extra code is what's using unsafeCoerce in a [purportedly]
disciplined way.
> Could you binary-chop
Simon Peyton-Jones writes:
> Here's the story for Any [below]. A favour: could you
> ...
> My goal is to use your travels through GHC to make the journey for the next
> person easier.
> ...
> it would be very very helpful. I'm too close to the code to do that -- you
> are ideally placed!
Ye
Simon Marlow writes:
> cd ghc; make 1
>
> More details on this in the wiki:
>
> http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges
Thank you!
- a
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www
Adam Megacz writes:
> The really strange part is this: if I modify the extraction machinery
> and wrap every subexpression "e" as "(trace e)" where trace is:
>
> trace x = System.IO.Unsafe.unsafePerformIO $ Prelude.return x
>
> Everything works perfectly
Typing
make inplace/bin/ghc-stage1
will build ghc-stage1 (as desired). Then it also runs the configure
scripts for all of the libraries, which takes a really long time.
Is there some invocation of make that will just recompile
inplace/bin/ghc-stage1 and won't re-run all of the configure stuf
Hello, could anybody explain:
1. How GHC.Prim.Any maps on to SystemFC; I'm guessing it isn't "just
another 0-ary tycon" -- it seems to get special treatment.
2. If using -XNoMonoPatBinds ensures that GHC.Prim.Any won't appear in
post-desugarer CoreSyn's (this is the case for my tes
"Edward Z. Yang" writes:
> Can you minimize the test-case into a minimal program that still segfaults?
Sadly, no; the extracted Haskell is difficult to read and very fragile
in the face of manual modifications. It would be like editing STG code
by hand...
> Maybe you can reduce the Coq itself
So, I have a situation where my modified GHC is segfaulting. All
compilation is done with -O0. I'm sort of hoping for suggestions on how
to continue figuring this out.
I've tried all of the suggestions on these pages, short of using gdb:
http://hackage.haskell.org/trac/ghc/wiki/Debugging
h
This fixes Trac bug 5141.
---
compiler/types/TypeRep.lhs | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/compiler/types/TypeRep.lhs b/compiler/types/TypeRep.lhs
index aa1f941..e687719 100644
--- a/compiler/types/TypeRep.lhs
+++ b/compiler/types/TypeRep.lhs
@@ -
Adam Megacz writes:
> people who download the paper from the authoritative source at ACM
> won't even know the appendix exists.
... which is here:
http://dx.doi.org/10.1145/1190315.1190324
___
Cvs-ghc mailing list
Cvs-ghc@haske
Ian Lynagh writes:
> On Mon, Jan 17, 2011 at 12:38:57AM +, meg...@cs.berkeley.edu wrote:
>> Sun Jan 16 03:20:12 UTC 2011 meg...@cs.berkeley.edu
>> * Add warning that GHC.CoreSyn.Expr is based on Appendix C of TLDI'07
>> paper, not the body of the paper.
>
> Thanks for the patch! However,
Ian Lynagh writes:
> Unfortunately, plans have changed once more. We'll be doing the
> migration a little later instead - probably in around 2 weeks, but we
> haven't worked out a precise date yet.
Is there any chance that the mirror of the base library will be brought
up to date before 1400 UTC
Adam Megacz writes:
> you've convinced me that there's no reason to have -XRebindableSyntax
> active on depth=0 terms. So I'm going to try to find a way to have
> -XModalTypes desugar depth>0 terms as if -XRebindableSyntax were
> enabled -- that way the flag won
Max Bolingbroke writes:
> It does work on HelloWorld.hs, but that program is not very
> interesting for me as it doesn't make use of any heterogeneous
> metaprogramming.
Then please try tutorial.hs using **no flags** on the command line (the
comment at the top will turn on -XModalTypes). That f
Adam Megacz writes:
> Also, you appear to be using -dcoqpass (right?) which you're not
> supposed to use with the tutorial. That flag builds proof-trees as
> LaTeX code and unless you've recompiled it with expanded limits, LaTeX
> will surely choke on anything as large
al.hs:
http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/45482
> I'm not sure what you mean by HelloWorld - it doesn't seem to be
> mentioned on that page.
Search for "HelloWorld" in: http://www.cs.berkeley.edu/~megacz/coq-in-ghc/
> instance GArrow (->) (
It seems that the git mirror of the base package is a few months out of
date:
http://darcs.haskell.org/ghc-git/packages/base.git/
Sadly this means I can't build the compiler: the representation of some
of the low-level threading stuff has changed recently.
Could somebody please refresh the gi
Max Bolingbroke writes:
> I would suppose that there is some trivial way to run
> sufficiently-polymorphic modally-typed stuff as simple Haskell by
> taking g = (->), which would be good to show. (Speaking of which,
> wouldn't it make sense to have that GArrow instance in
> GHC.HetMet.GArrow?)
O
> HaskWeak ELet: t and GHC.Types.Bool
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Did HelloWorld work? See the commands here:
http://www.cs.berkeley.edu/~megacz/garrows/
Also, you appear to be using -dcoqpass (right?) which you're not
supposed to use with t
Max Bolingbroke writes:
> It is possible that it just takes an extremely long time to build -
That is certainly the case. You need to let it run for at least four or
five minutes on a fast machine. Also, don't try to use anything above
-O0. Here's why:
> My initial diagnosis was wrong (I wa
Max Bolingbroke writes:
> My installed GHC is looping when building your TcRnDriver, oddly.
Yikes, that is bad news. You mean that your pre-installed GHC, without
any of my modifications, is going into a loop? Not good.
Even though I suspect this isn't my fault, I need to look into it. What
Hi Max, I have access to email right now but not to a machine with the
code on it, so I can answer questions but can't fix bugs (yet):
Max Bolingbroke writes:
> 1. What is the %%a syntax in the dotproduct' function?
It's cross-stage persistence, but I need to remove that. I included CSP
out o
On Mar 8, 2011, at 12:25 AM, Max Bolingbroke wrote:
> Your tutorial is a 404 for me.
Yikes! So sorry. Should be fixed now. When compiled, you should get the
output shown below (if not, make sure you have the latest copy of the git repo
and base package).
I'll have only intermittent access t
understand it is to start
with a program that exercises that feature and fiddle with it until the
typechecker complains. To facilitate that, there's now a tutorial program
linked off the project page:
http://www.cs.berkeley.edu/~megacz/garrows/
There's also a new branch with the
Type constructor applications need not be saturated. Therefore, both of
these are legitimate values of type Type:
AppTy (TyConApp []) X
TyConApp [X]
However, it seems like none of GHC's type-comparison functions
(tcEqType, coreEqType, various permutations of
coreView/expandTypeSynonyms et
Simon Peyton-Jones writes:
> | I assume this is only the
> | value variables, and that the type/coercion variables come from
> | DataCon.{dataConExTyVars,dcEqSpec}, right?
>
> Not so at all. Why did you assume that?
You're right, that was a silly assumption. However, without it, I
1. SystemFC1 distinguishes between data type constructors (T) and type
functions (S_n). It seems that in CoreSyn these both become
TyCon.TyCon -- do I have this right? Is there a way to ask which
kind of thing a TyCon stands for?
2. Type function applications in SystemFC1 are always fu
1. In SystemFC a case branch binds three sorts of variables: type variables
(for the existential types of the relevant DataCon), coercion variables
(similar), and value variables (for the fields of the DataCon).
CoreSyn.AltCon includes a list of Var's -- I assume this is only the
valu
On Mar 3, 2011, at 9:24 PM, Simon Peyton-Jones wrote:
> Wow. My brain exploded when I read about what you've done.
"Monads may make your head hurt, but generalized
arrows make SPJ's head *explode*"
Gotta make some t-shirts or something ;)
- a___
GArrow terms is here:
http://www.cs.berkeley.edu/~megacz/garrows/
Information on how I use Coq to write GHC passes can be found here:
http://www.cs.berkeley.edu/~megacz/coq-in-ghc/
More details will arrive over the course of the next week, but
feedback/advice is most welcome (either here or
Could somebody help me understand why Case binds its scrutinee in
CoreSyn?
Unless I'm misreading it (quite possible), the "case" expression does
not bind a variable for its scrutinee in System FC1: the contexts in
which the branches get checked seem to have new expresion variables only
for the fi
Here are the leftover questions I had that weren't very urgent (I
kludged my way around most of them and am now going back to clean stuff
up)
- Can I count on the desugarer and core-to-core passes preserving the
syntactic order of the branches in a (Let (Rec branches) e)?
- It isn't
The function at the end of this email walks over a Type, basically
(recursivey) replacing it with its coreView. The resulting tree has no
PredTy's except for (PredTy (EqPred _ _)).
How problematic is it for a core-to-core translation to replace all the
Type's in an Expr with their coreView-ifica
Roman Leshchinskiy writes:
> Two Vars are Eq-equal iff they could shadow each other.
Simon Peyton-Jones writes:
> Two Vars are considered equal if their Names are the same.
Max Bolingbroke writes:
> If you weren't using Uniques, presumably your variables would be
> compared just by their OccN
Roman Leshchinskiy writes:
> However, coreView from types/Type.lhs expands one level of a type to
> the representation.
Ah, that worked perfectly. Thank you!
> But note that equality predicates as also PredTys and they aren't
> removed by coreView.
I see. Could you help me correlate EqPred
Max Bolingbroke writes:
>> Hrm, isn't it bad for two Var's with different fields to have the same
>> uniq? Because if they have the same uniq, they will be Eq-equal.
>
> Just because two vars are eq-equal does not mean that they refer to
> the "same thing".
Hrm, okay, thanks for clearing this u
In the next few weeks I will be posting two substantial modifications to
GHC in order to start getting feedback from a larger group of people.
Neither modification is appropriate for inclusion in the compiler at
this time (one is written in Coq rather than Haskell and the other
breaks separate com
GHC's PredTy construct doesn't seem to correspond neatly to any specific
part of System FC. However, there is a comment in the source code near
it indicating that "It can be expanded into its representation".
Is there a particular point in the compiler pipeline after which one can
be certain tha
> Or did you mean that OccName-shadowing is allowed, but Var-shadowing
> is not?
By Var-shadowing, I guess I meant that there's no way to replace
{-FIXME-} in the code below to make it represent the expression
(\x::Int -> \x::Char -> e):
Lam v (Lam v e)
where
v::V
Thank you (and Dimitrios) once again for so patiently answering my
System FC (and CoreSyn) questions!
http://www.cs.berkeley.edu/~megacz/garrows/ghc.-ddump-proofs.pdf
Hopefully this will soon lead to something more useful than gigantic,
illegible proof-tree printouts. :)
One last
Hello! I'm currently attempting to reconstruct natural deduction proofs
(with explicit contraction/exchange/weakening) in System FC from
CoreSyn.Expr's in order to carry out a transformation which is defined
by induction on proofs (rather than terms). I have it working for
simple examples, and n
Hello! I'm currently attempting to reconstruct natural deduction proofs
(with explicit contraction/exchange/weakening) in System FC from
CoreSyn.Expr's in order to carry out a transformation which is defined
by induction on proofs (rather than terms). I have it working for
simple examples, and n
Hello! I'm currently attempting to reconstruct natural deduction proofs
(with explicit contraction/exchange/weakening) in System FC from
CoreSyn.Expr's in order to carry out a transformation which is defined
by induction on proofs (rather than terms). I have it working for
simple examples, and n
Sun Jan 16 03:20:12 UTC 2011 meg...@cs.berkeley.edu
* Add warning that GHC.CoreSyn.Expr is based on Appendix C of TLDI'07 paper,
not the body of the paper.
New patches:
[Add warning that GHC.CoreSyn.Expr is based on Appendix C of TLDI'07 paper, not the body of the paper.
meg...@cs.berkeley.ed
50 matches
Mail list logo
