From conal at conal.net  Thu Nov 17 16:39:43 2016
From: conal at conal.net (Conal Elliott)
Date: Thu, 17 Nov 2016 08:39:43 -0800
Subject: GHC rewrite rules for class operations & laws
Message-ID: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>

Is it possible to apply GHC rewrite rules to class methods? From what I’ve
read and seen, class methods get eliminated early by
automatically-generated rules. Is there really no way to postpone such
inlining until a later simplifier stage? The GHC Users Guide docs say no
<https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#how-rules-interact-with-class-methods>,
and suggests instead giving a duplicate vocabulary with somewhat awkward
names for class methods. I’ve not seen this practice in libraries. I gather
that we cannot therefore use class laws as optimizations in the form of
rewrite rules, which seems a terrible loss.

In Control.Category and Control.Arrow, I see rules for class laws but also
header comments saying “The RULES for the methods of class Arrow may never
fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any
strategies for using class laws in optimization.

Thanks, -- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161117/c678c587/attachment.html>

From david.feuer at gmail.com  Thu Nov 17 16:46:35 2016
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 17 Nov 2016 11:46:35 -0500
Subject: GHC rewrite rules for class operations & laws
In-Reply-To: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>
References: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>
Message-ID: <CAMgWh9tkGQMUUdhuJ=ZTtZKOdSFn_kvTyqO3njq5eRVy1YZc8g@mail.gmail.com>

The containers package uses the awkward double name approach. See, for
example, the way that Data.Map and Data.Sequence fuse (indexed) maps and
indexed) traversals. I know that Edward Kmett is very much opposed to
class-based rules as found in Control.Arrow because non-law-abiding
instances will behave differently when optimized.

On Nov 17, 2016 11:40 AM, "Conal Elliott" <conal at conal.net> wrote:

> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#how-rules-interact-with-class-methods>,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161117/bb3c7219/attachment.html>

From simonpj at microsoft.com  Tue Nov 22 12:06:08 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 22 Nov 2016 12:06:08 +0000
Subject: GHC rewrite rules for class operations & laws
In-Reply-To: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>
References: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>
Message-ID: <DM2PR21MB002800451DC99EE1E5C7BDE0ADB40@DM2PR21MB0028.namprd21.prod.outlook.com>

Conal

Is it possible to apply GHC rewrite rules to class methods?

Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples.  https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more background.

It’d be great if someone wanted to think through all this.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 17 November 2016 16:40
To: glasgow-haskell-users at haskell.org
Subject: GHC rewrite rules for class operations & laws


Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23how-rules-interact-with-class-methods&data=02%7C01%7Csimonpj%40microsoft.com%7C8678611c4c57499f97be08d40f08662a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636149976146128136&sdata=GjkFhlWdNkT6eo85FvcLKkJYoir7Dui9xJ9kMTYKVmU%3D&reserved=0>, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss.

In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”.

I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization.

Thanks, -- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161122/72a83650/attachment.html>

From conal at conal.net  Fri Nov 25 04:53:31 2016
From: conal at conal.net (Conal Elliott)
Date: Thu, 24 Nov 2016 20:53:31 -0800
Subject: GHC rewrite rules for class operations & laws
In-Reply-To: <DM2PR21MB002800451DC99EE1E5C7BDE0ADB40@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CAD6SzRJ7qvfENqjHQkos3UVPVyiPpAzQNCDqy5m8Yv0CRsBntA@mail.gmail.com>
 <DM2PR21MB002800451DC99EE1E5C7BDE0ADB40@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAD6SzRJTc3bO_LwT66XUrQ03632bNJnYizV80ax7vdxg0eg5SA@mail.gmail.com>

Thanks, Simon. For now, I've added a module with aliases for all of my
class methods and law-based rewrite rules in terms of those aliases.

- Conal

On Tue, Nov 22, 2016 at 4:06 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Conal
>
>
>
> Is it possible to apply GHC rewrite rules to class methods?
>
>
>
> Not currently.  See https://ghc.haskell.org/trac/ghc/ticket/11688, esp
> comment:7 which gives links to similar examples.
> https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13  gives more
> background.
>
>
>
> It’d be great if someone wanted to think through all this.
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
> bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 17 November 2016 16:40
> *To:* glasgow-haskell-users at haskell.org
> *Subject:* GHC rewrite rules for class operations & laws
>
>
>
> Is it possible to apply GHC rewrite rules to class methods? From what I’ve
> read and seen, class methods get eliminated early by
> automatically-generated rules. Is there really no way to postpone such
> inlining until a later simplifier stage? The GHC Users Guide docs say no
> <https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23how-rules-interact-with-class-methods&data=02%7C01%7Csimonpj%40microsoft.com%7C8678611c4c57499f97be08d40f08662a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636149976146128136&sdata=GjkFhlWdNkT6eo85FvcLKkJYoir7Dui9xJ9kMTYKVmU%3D&reserved=0>,
> and suggests instead giving a duplicate vocabulary with somewhat awkward
> names for class methods. I’ve not seen this practice in libraries. I gather
> that we cannot therefore use class laws as optimizations in the form of
> rewrite rules, which seems a terrible loss.
>
> In Control.Category and Control.Arrow, I see rules for class laws but
> also header comments saying “The RULES for the methods of class Arrow may
> never fire e.g. compose/arr; see Trac #10528”.
>
> I’d appreciate a reality check about my conclusions as well as any
> strategies for using class laws in optimization.
>
> Thanks, -- Conal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161124/347ca7af/attachment.html>

From ben at well-typed.com  Fri Nov 25 22:38:17 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 25 Nov 2016 17:38:17 -0500
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
Message-ID: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

The GHC team is happy to (finally!) announce the first candiate of the
8.0.2 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    http://downloads.haskell.org/~ghc/8.0.2-rc1/

This is the first of what will hopefully be only two release candidates
leading up the final 8.0.2 release. This release will fix a number bugs
found in 8.0.1 including,

  * Interface file build determinism (#4012).

  * Compatibility with macOS Sierra and GCC compilers which compile 
    position-independent executables by default

  * Runtime linker fixes on Windows (see #12797)

  * A compiler bug which resulted in undefined reference errors while
    compiling some packages (see #12076)

  * Compatability with systems which use the gold linker

  * A number of memory consistency bugs in the runtime system

  * A number of efficiency issues in the threaded runtime which manifest
    on larger core counts and large numbers of bound threads.

  * A typechecker bug which caused some programs using
    -XDefaultSignatures to be incorrectly accepted.

  * More than two-hundred other bugs. See Trac [1] for a complete
    listing.

Unfortunately there is one known bug (#12757) which can result in
runtime crashes which is still lurking in -rc1. This will be fixed in
-rc2, which will be released in about a week.

As always, let us know if you encounter trouble. Thanks to everyone who
has contributed so far!

Happy testing,

- Ben


[1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161125/990e68c7/attachment.sig>

From george.colpitts at gmail.com  Sat Nov 26 00:15:25 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 26 Nov 2016 00:15:25 +0000
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A4kcsz6M0Js4ZXqXkGK5aN7qHxAm4aQw0WKVQRnP=3eBQ@mail.gmail.com>

Thanks Ben, this is great!

Installing the binary on the Mac results in the following minor problem:

/usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
"/usr/local/share/man/man1"
install: /usr/local/share/man/man1/ghc.1: No such file or directory
make[1]: *** [install_man] Error 71
make: *** [install] Error 2

The error message is a bit confusing as the file does exist.
It is easily resolved by

 rm /usr/local/share/man/man1/ghc.1


I believe I encountered the same problem on ghc 8.0.1 rc1

Thanks
George




On Fri, Nov 25, 2016 at 6:39 PM Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC team is happy to (finally!) announce the first candiate of the
> 8.0.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
>     http://downloads.haskell.org/~ghc/8.0.2-rc1/
>
> This is the first of what will hopefully be only two release candidates
> leading up the final 8.0.2 release. This release will fix a number bugs
> found in 8.0.1 including,
>
>   * Interface file build determinism (#4012).
>
>   * Compatibility with macOS Sierra and GCC compilers which compile
>     position-independent executables by default
>
>   * Runtime linker fixes on Windows (see #12797)
>
>   * A compiler bug which resulted in undefined reference errors while
>     compiling some packages (see #12076)
>
>   * Compatability with systems which use the gold linker
>
>   * A number of memory consistency bugs in the runtime system
>
>   * A number of efficiency issues in the threaded runtime which manifest
>     on larger core counts and large numbers of bound threads.
>
>   * A typechecker bug which caused some programs using
>     -XDefaultSignatures to be incorrectly accepted.
>
>   * More than two-hundred other bugs. See Trac [1] for a complete
>     listing.
>
> Unfortunately there is one known bug (#12757) which can result in
> runtime crashes which is still lurking in -rc1. This will be fixed in
> -rc2, which will be released in about a week.
>
> As always, let us know if you encounter trouble. Thanks to everyone who
> has contributed so far!
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161126/134f1139/attachment.html>

From ben at well-typed.com  Sat Nov 26 13:46:36 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 26 Nov 2016 08:46:36 -0500
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
In-Reply-To: <CAB-d4A4kcsz6M0Js4ZXqXkGK5aN7qHxAm4aQw0WKVQRnP=3eBQ@mail.gmail.com>
References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A4kcsz6M0Js4ZXqXkGK5aN7qHxAm4aQw0WKVQRnP=3eBQ@mail.gmail.com>
Message-ID: <87zikmtkub.fsf@ben-laptop.smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Thanks Ben, this is great!
>
> Installing the binary on the Mac results in the following minor problem:
>
> /usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
> "/usr/local/share/man/man1"
> install: /usr/local/share/man/man1/ghc.1: No such file or directory
> make[1]: *** [install_man] Error 71
> make: *** [install] Error 2
>
Thanks for the report, George! That is quite odd indeed. It sounds like
/usr/local/share/man/man1/ghc.1 may have been a symlink to a directory
which does not exist (possibly?). What does `ls -l
/usr/local/share/man/man1/ghc.1` say now?

Cheers,

- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161126/50958012/attachment.sig>

From george.colpitts at gmail.com  Sat Nov 26 16:46:36 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 26 Nov 2016 16:46:36 +0000
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
In-Reply-To: <87zikmtkub.fsf@ben-laptop.smart-cactus.org>
References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A4kcsz6M0Js4ZXqXkGK5aN7qHxAm4aQw0WKVQRnP=3eBQ@mail.gmail.com>
 <87zikmtkub.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A7BSbB93JYcHsRZLd+v=azBjd2TcA_rmQS8MpPP+QWhkg@mail.gmail.com>

I think I am very atypical as I had the Haskell Platform installed and did
an uninstall-hs before installing this release candidate. This is on the
latest Mac OS and Xcode.

At the time I got the error the file was a symbolic link, I believe to an
existing file:

install: /usr/local/share/man/man1/ghc.1: No such file or directory
make[1]: *** [install_man] Error 71
make: *** [install] Error 2
bash-3.2$  ls -l /usr/local/share/man/man1/ghc.1
lrwxr-xr-x  1 gcolpitts  admin  80 Jun 23 19:44
/usr/local/share/man/man1/ghc.1 ->
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
bash-3.2$  rm /usr/local/share/man/man1/ghc.1

Now after a successful install of the binary and a successful compile from
source I have:

ls -l /usr/local/share/man/man1/ghc.1
-rw-r--r--  1 root  admin  58932 Nov 26 09:16
/usr/local/share/man/man1/ghc.1
bash-3.2$ ls -l
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
ls -l
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1
-rw-r--r--  1 root  wheel  58214 May 21  2016
/Library/Frameworks/GHC.framework/Versions/8.0.1-x86_64/usr/share/man/man1/ghc.1

After the binary install I did a cabal install of threadscope, hlint and
criterion and some minimal runtime testing. Everything looks fine.

Thanks
George

On Sat, Nov 26, 2016 at 9:47 AM Ben Gamari <ben at well-typed.com> wrote:

> George Colpitts <george.colpitts at gmail.com> writes:
>
> > Thanks Ben, this is great!
> >
> > Installing the binary on the Mac results in the following minor problem:
> >
> > /usr/bin/install -c -m 644  docs/users_guide/build-man/ghc.1
> > "/usr/local/share/man/man1"
> > install: /usr/local/share/man/man1/ghc.1: No such file or directory
> > make[1]: *** [install_man] Error 71
> > make: *** [install] Error 2
> >
> Thanks for the report, George! That is quite odd indeed. It sounds like
> /usr/local/share/man/man1/ghc.1 may have been a symlink to a directory
> which does not exist (possibly?). What does `ls -l
> /usr/local/share/man/man1/ghc.1` say now?
>
> Cheers,
>
> - Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161126/8e7f0038/attachment.html>

From juhpetersen at gmail.com  Mon Nov 28 07:55:57 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 28 Nov 2016 16:55:57 +0900
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
In-Reply-To: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAEDGBqJ0STDQiRet0byYKix_77ciSHD-AUrnvWD=RZ7KabXieQ@mail.gmail.com>

On 26 November 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:

>     http://downloads.haskell.org/~ghc/8.0.2-rc1/
>

Thank you, I built it for Fedora 25 (just released last week) and Rawhide:

https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2

Hopefully there will be a build for F24 soon too.

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161128/7a2e5a53/attachment.html>

From qdunkan at gmail.com  Tue Nov 29 01:54:55 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 28 Nov 2016 17:54:55 -0800
Subject: GHC API: memory usage of loaded modules
Message-ID: <CACbaDy6feykbU79by6gvPbo8ykf_xgRaALXG5S1r=1Qy3JNMDg@mail.gmail.com>

I have a program that uses the GHC API to provide a REPL.  It winds up
taking up 200mb in RAM, as measured by GHC.Stats.currentBytesUsed, but
without the GHC API it's 5mb.  If I turn on verbose, I can see that
GHC is loading 255 modules, all loaded binary ("skipping M ( M.hs,
M.hs.o )") except the toplevel, and the memory use is zooming up as it
loads them.

I expect some memory usage from loading modules, but 195mb seems like
a lot.  If I do a 'du' on the entire obj directory (which has 401
*.hs.o files... the REPL doesn't expose everything), it's only 76mb on
disk.  How do loaded modules wind up consuming space, and is there any
way to use less space?

The thing is, all those loaded modules are part of the application
itself, so presumably they've already been linked into the binary and
loaded into memory.  The ideal would be that I could somehow reuse
that.  I imagine that I could by writing my own haskell interpreter
and making a big symbol table of all the callable functions, but I'd
rather not write my own interpreter if I can use an existing one!

From rwbarton at gmail.com  Tue Nov 29 17:35:27 2016
From: rwbarton at gmail.com (Reid Barton)
Date: Tue, 29 Nov 2016 12:35:27 -0500
Subject: GHC API: memory usage of loaded modules
In-Reply-To: <CACbaDy6feykbU79by6gvPbo8ykf_xgRaALXG5S1r=1Qy3JNMDg@mail.gmail.com>
References: <CACbaDy6feykbU79by6gvPbo8ykf_xgRaALXG5S1r=1Qy3JNMDg@mail.gmail.com>
Message-ID: <CADmwj452K6TPzi-_rHiHrCATh85zGsxcNkoPia5v8-KVYkgEjQ@mail.gmail.com>

On Mon, Nov 28, 2016 at 8:54 PM, Evan Laforge <qdunkan at gmail.com> wrote:
> I have a program that uses the GHC API to provide a REPL.  It winds up
> taking up 200mb in RAM, as measured by GHC.Stats.currentBytesUsed, but
> without the GHC API it's 5mb.  If I turn on verbose, I can see that
> GHC is loading 255 modules, all loaded binary ("skipping M ( M.hs,
> M.hs.o )") except the toplevel, and the memory use is zooming up as it
> loads them.
>
> I expect some memory usage from loading modules, but 195mb seems like
> a lot.  If I do a 'du' on the entire obj directory (which has 401
> *.hs.o files... the REPL doesn't expose everything), it's only 76mb on
> disk.  How do loaded modules wind up consuming space, and is there any
> way to use less space?
>
> The thing is, all those loaded modules are part of the application
> itself, so presumably they've already been linked into the binary and
> loaded into memory.  The ideal would be that I could somehow reuse
> that.  I imagine that I could by writing my own haskell interpreter
> and making a big symbol table of all the callable functions, but I'd
> rather not write my own interpreter if I can use an existing one!

You'd probably find that you also want to, for example, type check the
expressions that you are interpreting. The information needed to do so
is not contained in your executable at all; it's in the .hi files that
were built alongside your program and its dependencies, and the ones
that came with the libraries bundled into GHC. I assume the in-memory
representation of these interface files is not very efficient, and
they probably account for a lot of the space usage of your program.

I'm not sure offhand, but perhaps using -fignore-interface-pragmas
when you invoke the GHC API would reduce the amount of space used
while loading interface files, and if you're using the bytecode
interpreter then you probably don't care about any of the information
it will discard (which mostly has to do with optimizations).

If you build your executable dynamically then the GHC API should also
reuse the same shared libraries and executable image rather than
loading a second copy of the object code. If that doesn't work then it
would be helpful if you could produce a minimal reproducer of it not
working. (The potential disadvantage is that you have to load the
entirety of each of your dependencies, rather than just the parts you
actually use.)

Regards,
Reid Barton

From ben at well-typed.com  Tue Nov 29 18:01:52 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 29 Nov 2016 13:01:52 -0500
Subject: [ANNOUNCE] GHC 8.0.2 release candidate 1
In-Reply-To: <CAEDGBqJ0STDQiRet0byYKix_77ciSHD-AUrnvWD=RZ7KabXieQ@mail.gmail.com>
References: <8737ifuqw6.fsf@ben-laptop.smart-cactus.org>
 <CAEDGBqJ0STDQiRet0byYKix_77ciSHD-AUrnvWD=RZ7KabXieQ@mail.gmail.com>
Message-ID: <87eg1utban.fsf@ben-laptop.smart-cactus.org>

Jens Petersen <juhpetersen at gmail.com> writes:

> On 26 November 2016 at 07:38, Ben Gamari <ben at well-typed.com> wrote:
>
>>     http://downloads.haskell.org/~ghc/8.0.2-rc1/
>>
>
> Thank you, I built it for Fedora 25 (just released last week) and Rawhide:
>
> https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.2
>
> Hopefully there will be a build for F24 soon too.
>
Thanks Jens!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20161129/54323df2/attachment.sig>