On Fri, Aug 13, 2010 at 1:14 AM, Max Bolingbroke batterseapo...@hotmail.com
wrote:
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
On 13 August 2010 00:13, John Lask jvl...@hotmail.com wrote:
I have wondered and perhaps someone can explain: what are the issues in
explicit control of instance export and import? (apart from defining an
appropriate syntax)
IMHO main problem with this (and related feature requests like local
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 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
Subject: Re: Using associated data types to create unpacked data structures
On Thu, Aug 12, 2010 at 11:28 AM, Simon Marlow
marlo...@gmail.commailto: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
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
, 12 Aug 2010 13:28:25
To: Simon Marlowmarlo...@gmail.com
Cc: glasgow-haskell-usersglasgow-haskell-users@haskell.org
Subject: Re: Using associated data types to create unpacked data structures
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users
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
Hi all,
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.
This makes functions such as lookup faster as the key
On Wed, Aug 11, 2010 at 9:03 AM, Johan Tibell johan.tib...@gmail.comwrote:
However, if we try to apply this method to large programs we run into
problems: we need to defined instances for a large number of combinations of
keys/values. We could generate a large number of instances, hoping that
18 matches
Mail list logo
