On 11/08/2010 17:03, Johan Tibell wrote:
Inspired by the generic maps example at
http://www.haskell.org/haskellwiki/GHC/Indexed_types
I tried to use associated data types to create a generic finite map that
unpacks both the key and value into the leaf data constructor.
What you're trying to
On 12 August 2010 02:20, Greg Fitzgerald gari...@gmail.com wrote:
Is there a way for a package.conf file to contain paths that are relative to
the directory containing the .conf file? GHC 6.12.1 chokes on relative
paths. I see the problem is solved for GHC's core libraries with the
$topdir
On 11/08/2010 22:31, Greg Fitzgerald wrote:
Is there any documentation or examples available that shows what needs
to be linked to get a haskell executable to print hello world?
Instead of using GHC to link, I'm interested in using gcc, ar, or link
directly. For starters, what implements the
On Thu, Aug 12, 2010 at 11:28 AM, Simon Marlow marlo...@gmail.com wrote:
On 11/08/2010 17:03, Johan Tibell wrote:
Inspired by the generic maps example at
http://www.haskell.org/haskellwiki/GHC/Indexed_types
I tried to use associated data types to create a generic finite map that
unpacks
On 12/08/2010 11:13, Johan Tibell wrote:
There needs to be some amount of code generation, but much of the
implementation can still be shared. I previously tried to defined the
type class as
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
module Ex2 where
import Prelude
On Thu, Aug 12, 2010 at 12:25 PM, Simon Marlow marlo...@gmail.com wrote:
I'm not sure I want lookup (and other operations) to be inlined at every
call site though.
That's a good point. If inlining isn't a the right option in every case we
would have to duplicate the implementation.
I had a
On 12/08/2010 12:28, Johan Tibell wrote:
This doesn't quite work though as two MapIntDouble defined in two
different libraries are incompatible. This is essentially the same
problem as with instance collisions.
But you get to choose the module name, so you can
On Thu, Aug 12, 2010 at 1:47 PM, Max Bolingbroke batterseapo...@hotmail.com
wrote:
None of the mechanism for making this stuff happen is available at the
moment. It's an engineering problem that just needs time to be thrown
at it.
If we could figure out which mechanisms are needed we would
Hi,
On 12.08.2010, at 12:25, Simon Marlow wrote:
On 12/08/2010 11:13, Johan Tibell wrote:
There needs to be some amount of code generation, but much of the
implementation can still be shared. I previously tried to defined the
type class as
{-# LANGUAGE MultiParamTypeClasses,
On Thu, Aug 12, 2010 at 11:28 AM, Simon Marlow marlo...@gmail.com wrote:
Rather than try to solve this problem in one go, I would go for a low-tech
approach for now: write a TH library to generate the code, and ask the user
to declare the versions they need. To make a particular version, the
You don't want to go overboard here.
1. You *want* a distinct blob of lookup code for each different key type,
because you really do want a different lookup structure for each
2. For the most part you *dont want* a different blob of lookup code for
each value type, because almost
On Thu, Aug 12, 2010 at 6:07 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
1. You **want** a distinct blob of lookup code for each different
key type, because you really do want a different lookup structure for each
There are two reasons to want different blobs of code for the
C++ template instantiations are exported as weak linker symbols. It's just that
the linker elides all of the implementations.
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: Johan Tibell johan.tib...@gmail.com
Sender: glasgow-haskell-users-boun...@haskell.org
Date: Thu,
On Thu, Aug 12, 2010 at 9:27 PM, scooter@gmail.com wrote:
C++ template instantiations are exported as weak linker symbols. It's just
that the linker elides all of the implementations.
Yes and dead code elimination should also be able to get rid of much of the
code duplication even before
re ...
As I understand it the generated code is not exported from the
translation unit so there are no collisions at link time. We could do
the same if we could force the generated type class instance to not be
exported from the module.
I have encountered several occasions when I wished
On 12 August 2010 20:31, Johan Tibell johan.tib...@gmail.com wrote:
Yes and dead code elimination should also be able to get rid of much of the
code duplication even before it reaches the linker.
I don't think dead code elimination will help, because presumably you
want to generate
16 matches
Mail list logo
