On Oct 31, 2011, at 7:31 AM, Simon Marlow wrote:
> On 28/10/2011 16:27, Knut Halvor Skrede wrote:
>> Hi,
>>
>> I have been trying to dump Core to an alternative format for a while now.
>>
>> I started trying to use the compileToCoreSimplifed function and
>> traversing the resulting CoreModule,
On Aug 28, 2008, at 12:39 PM, Thomas Schilling wrote:
On Thu, Aug 28, 2008 at 7:46 PM, Max Bolingbroke
<[EMAIL PROTECTED]> wrote:
2008/8/28 Ian Lynagh <[EMAIL PROTECTED]>:
The arguments for moving to hierarchical module names were:
* it makes finding modules much easier for people new to the
Actually, that file should be fine. I updated the External Core output
path to include all of the constructs in modern GHC core. It's the
input path I've been slow to finish (and, when I do finish it, the
output format will likely be totally different, too :) )
So, there's little formal doc
This patch fixes the preprocessor directives surrounding the Darwin/
i386 portion of freeHaskellFunctionPtr, which had used the wrong
symbol (x86_HOST_ARCH instead of i386_HOST_ARCH), causing occasional
FFI problems. This patch is against the 6.8 branch, but will probably
apply to HEAD, as w
I think I'm convinced. Trying to make the format stay consistent has
been the major thing that has slowed me down. The current syntax
doesn't include all of the information contained in the iface data
types, and inferring the missing bits is rather tricky. I had thought
that inference of th
On Jul 2, 2007, at 2:28 AM, Simon Peyton-Jones wrote:
=| 2) I have the following source file:
|
|%module main:GADTTest
| %data main:GADTTest.Term x =
|{K :: %forall x a (cozuwild::(x:=:a -> a)) .
| main:GADTTest.Term x};
|
| which is translated into (roughly):
|IfaceData {
On Jul 1, 2007, at 5:37 AM, Neil Mitchell wrote:
Hi,
Thanks to all the help I've now managed to get GHC Core converted to
Yhc Core (the source is at the end of this mail, if anyone wants a
look). I have three remaining issues:
1) Data types (i.e. data/newtype) are not represented in [CoreBind
I'm slowly but surely making more progress on External Core. I can
now typecheck many simple programs, but I'm blocked on a number of
questions about the right way to encode various types in iface format.
1) What's the right way to encode the coercion manipulation functions
such as left, ri
Hi,
You might already be aware of this, but .type seems to be a gas-
specific directive. At least, it's not supported by the OS X version
of as, so HEAD can't successfully compile things on that platform for
the moment. Feel free to ignore me if you're already planning to fix
this. :)
Th
We can definitely add those to the existing data types, but it
wouldn't be entirely trivial. I believe some of them already have
Read and Show instances which don't do quite what we want, and
changing them to automatically-derived instances might make other
bits of the compiler behave dif
We've been leaning away from having a specific data type for External
Core, and just using the existing data types in GHC (such as
IfaceExpr and CoreExpr). So it's unclear what data type we'd add
deriving(Show) to. One of the major difficulties in having a standard
external format is that G
11 matches
Mail list logo
