On 2/21/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> | Working on the documentation and external tools (with help from Andrew
> | Tolmach) is my priority right now, as I need it for my own work. Thus
> | *generating* External Core (and parsing it back in with an external
> | tool) should
| Working on the documentation and external tools (with help from Andrew
| Tolmach) is my priority right now, as I need it for my own work. Thus
| *generating* External Core (and parsing it back in with an external
| tool) should be possible for mere mortals again soon.
OK that's excellent. Thank
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Sorry, I should have been more precise. The language definition does not
> say anything about the pragmas and GHC ignores them by default. However,
> GHC has a flag which tells it to assign a meaning to certain pragmas.
> With this flag
Tim Chevalier wrote:
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
If it can't or doesn't want to maintain it, it throws it away. The info
is optional: if it's there, it has to be correct but it doesn't have to
be there.
[snip]
Just like in Haskell, they don't have a semantics -
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
>
> If it can't or doesn't want to maintain it, it throws it away. The info
> is optional: if it's there, it has to be correct but it doesn't have to
> be there.
[snip]
>
> Just like in Haskell, they don't have a semantics - they are essen
Tim Chevalier wrote:
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
Tim Chevalier wrote:
>
> 2) Perhaps even more seriously, GHC keeps a great deal of analysis
> information attached to variables, and it doesn't really make sense to
> export much of it into External Core files --
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Tim Chevalier wrote:
> >
> > 2) Perhaps even more seriously, GHC keeps a great deal of analysis
> > information attached to variables, and it doesn't really make sense to
> > export much of it into External Core files -- external tools
Tim Chevalier wrote:
2) Perhaps even more seriously, GHC keeps a great deal of analysis
information attached to variables, and it doesn't really make sense to
export much of it into External Core files -- external tools
presumably mostly can't or don't want to make usage of strictness
informatio
On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Tim Chevalier wrote:
> >
> > Working on the documentation and external tools (with help from Andrew
> > Tolmach) is my priority right now, as I need it for my own work. Thus
> > *generating* External Core (and parsing it back in with a
Tim Chevalier wrote:
Working on the documentation and external tools (with help from Andrew
Tolmach) is my priority right now, as I need it for my own work. Thus
*generating* External Core (and parsing it back in with an external
tool) should be possible for mere mortals again soon.
That's gre
On 2/19/08, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> The ext-core stuff is more complicated, and the support libraries that
> were meant to exist around it have all bit-rotted in nasty ways. As it
> currently stands, Tim's work is about the easiest route to getting
> Core out of GHC, but is fairl
On 2/19/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
>
>
>
> It relates to strictness info etc. I strongly suggest you do not try to
> parse this stuff -- it was never intended for that. Why do you think
> ext-core is harder? It's designed to be easier!
>
While I agree that there doesn't
On 2/18/08, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> I started my project implementing a stg compiler to .NET, as described in
> "Implementing Lazy Functional Languages on Stock Hardware: The Spineless
> Tagless G-Machine" [Jones, Peyton]. After that, I resolved to integrate it
> to GHC, so I
Hi Simon,
> It relates to strictness info etc. I strongly suggest you do not try to
> parse this stuff -- it was never intended for that. Why do you think
> ext-core is harder? It's designed to be easier!
The ext-core stuff is more complicated, and the support libraries that
were meant to exist
2008 11:08
To: Cvs-ghc@haskell.org
Subject: Re: STG code
Hi, I´m trying to use the Core representation by -ddump-simpl, because the code
generated is simpler than -fext-core.
But I don´t understand the meaning of some informations.
I compile the code:
mapp::(t->u)->[t]->[u]
mapp _
Sorry, I put the wrong code. The generated code is:
Rec {
Teste.mapp :: forall t_a5D u_a5E. (t_a5D -> u_a5E) -> [t_a5D] -> [u_a5E]
[GlobalId]
[Arity 2
NoCafRefs
Str: DmdType LS]
Teste.mapp =
\ (@ t_aap) (@ u_aaq) (ds_dat :: t_aap -> u_aaq) (ds1_dau :: [t_aap]) ->
case ds1_dau of wild_B1 {
Hi, I´m trying to use the Core representation by -ddump-simpl, because the
code generated is simpler than -fext-core.
But I don´t understand the meaning of some informations.
I compile the code:
mapp::(t->u)->[t]->[u]
mapp _ [] = []
mapp f (x:xs) = (f x):(mapp f xs)
is generated:
Teste.t :: G
On 2/18/08, Guilherme Avelino <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I know that Stg don´t have type informations, but I saw some research using
> a changed version of GHC
>
> Some researches, like Compiling Haskell to Java [Tullsen, Mark] and
> Multi-Paradigm Just-In-Time Compilation [Stewart, Don]
18 matches
Mail list logo
