GHC and dynamic linking
I foggily remember previous versions of GHC being unable to create programs that use dynamic links to libraries. Is this the case and, if so, is it still an issue? Static linking is not an option due to licensing issues. I'm interested in GHC 6.6.1 and 6.8.1 on Windows, Mac (PowerPC and x86), and Linux (x86). Thanks in advance, Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
I've entered a feature request for this on Trac http://hackage.haskell.org/trac/ghc/ticket/1866 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
I think this would be a BIG mistake. Whatever system GHC settles on
is almost certain to become part of the Haskell standard, and this
particular system has some deep limitations which could not be got
round without ripping it all out and starting again.
The problem with this (and other Flex-like) systems is that they
take record extension as the basic operation of record building,
rather than record merging. This means that you can only ever add or
update statically determined fields of a given record.
An important application which is made impossible by this approach is
functions with optional arguments. For example, if you look at the
definition of R (the statistics system) every function has a small
number of mandatory positional arguments, and a very large number of
optional named arguments, which take sensible default values. I want
to be able to write:
f opts x = let vals = {Opt1 =: default1, ... } |: opts in
... vals ... x ...
where '{Opt1 =: default1, ... }' is some fixed record of default
values, and '|:' is record overwrite. The type of f should be
f :: (a `Subrecord` {Opt1 :=: t1, ...}) = a - b - c
where '{Opt1 :=: t1, ...}' is the (fixed) type of '{Opt1 =:
default1, ... }' (and x::b, and c is the type of the result).
The condition 'a `Subrecord` {Opt1 :=: t1, ...}' in the context of
this type means that every field of 'opts :: a' must be a field of
'{Opt1 :=: t1, ...}', but opts can have as few fields as you like.
This is exactly what you want for optional arguments.
This could never be defined in any Flex-like system, because these
systems depend on the fact that their record types can be reduced to
a type variable extended by a fixed set of labels. This is a major
restriction to what you can do with them: you can never define
operations like '|:' or '+:' where the second argument does not have
a constant set of fields.
This restriction does not hold for more flexible systems like that
defined by Oleg co using functional dependencies, or the one I
proposed on this list using type families. Although these systems are
much more flexible than the scoped labels system, they would take
LESS work to add to GHC because they have less built-in syntax, and
are almost entirely defined in a library.
I second the call for a records system, but please don't limit us to
something like scoped labels!
Barney.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.1
On Sat, 2007-11-10 at 21:45 +, Ian Lynagh wrote: Hi Philip, On Mon, Nov 05, 2007 at 09:58:40AM +0100, Philip K.F. Hölzenspies wrote: Booting libraries/base Booting libraries/directory /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal I still don't understand why this would happen. That's not a problem in GHC's configure.ac or other .ac files. It's just that autoreconf scans all the /usr/share/aclocal/*.m4 files that you happen to have installed on your system. If any of those are from before autoconf started getting really picky about quoting then you'll get that warning. It's nothing to worry about, especially as in this case it's in a .m4 file that we do not get any definitions from. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Extensible Records
Hello Barney, Sunday, November 11, 2007, 2:34:14 PM, you wrote: An important application which is made impossible by this approach is i propose to start Records project by composing list of requirements/applications to fulfill; we can keep it on Wiki page. this will create base for language theorists to investigate various solutions. i think they will be more motivated seeing our large interest in this extension -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.1
On Sun, Nov 11, 2007 at 11:59:43AM +, Duncan Coutts wrote: On Sat, 2007-11-10 at 21:45 +, Ian Lynagh wrote: Hi Philip, On Mon, Nov 05, 2007 at 09:58:40AM +0100, Philip K.F. Hölzenspies wrote: Booting libraries/base Booting libraries/directory /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal I still don't understand why this would happen. That's not a problem in GHC's configure.ac or other .ac files. It's just that autoreconf scans all the /usr/share/aclocal/*.m4 files that you happen to have installed on your system. If any of those are from before autoconf started getting really picky about quoting then you'll get that warning. It's nothing to worry about, especially as in this case it's in a .m4 file that we do not get any definitions from. So why doesn't booting base cause it? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
missing Control.Monad.State
Hi all -- Something weird just happened and I feel bad asking on the list for help (because it's a dumb question), but I've racked my brains and can't figure it out. I've been happily using ghc for some time now. My current machine died, and the computer folks gave me a new one. Both my old and new were running ubuntu. The new machine came in and I apt-get installed ghc6 ghc6-prof ghc6-docs haskell-mode ghc6-libsrc. But when I try to run ghc on a module that uses Control.Monad.State, I get: ~ ghc --make -fglasgow-exts Main.hs -o hbc Core.hs:24:7: Could not find module `Control.Monad.State': Use -v to see a list of the files searched for. If I say -v, I get: Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main.hs Core.hs:24:7: Could not find module `Control.Monad.State': locations searched: Control/Monad/State.hs Control/Monad/State.lhs *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: Looking in /usr/lib/ghc-6.6/package.conf, I don't find any mention of Control.Monad.State (or anything with State) for that matter. A find in /usr/lib/ghc-6.6 doesn't turn up anything called State, either. I presume that I'm doing something incredibly stupid, but I'd appreciate a bit of help! Thanks! - Hal -- Hal Daume III --- me AT hal3 DOT name | http://hal3.name Arrest this man, he talks in maths. | http://nlpers.blogspot.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Binary for Vista 64-bit
Just wondering if a binary for Vista 64-bit will be released? Regards Chris Saunders ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
On Tue, Nov 06, 2007 at 05:29:05PM +1100, Manuel M T Chakravarty wrote: A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is available Thanks Manuel! I've put it on the download page. Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.4 (Tiger)
On Thu, Nov 08, 2007 at 12:25:12PM +0100, Christian Maeder wrote: binary distributions of GHC 6.8.1 for Mac OS X 10.4 (Tiger) Thanks Christian! I've put them on the download page. Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.8.1 under Solaris
On Fri, Nov 09, 2007 at 12:46:14PM +0100, Christian Maeder wrote: Dear Solaris Users, binary distributions for Solaris 10 ultrasparc and i383 Thanks Christian! I've put them on the download page. Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: missing Control.Monad.State
It seems you haven't the mtl package installed. You can either get a custom package for your OS distribution or grab it from hackage. On Nov 11, 2007 2:29 PM, Hal Daume III [EMAIL PROTECTED] wrote: Hi all -- Something weird just happened and I feel bad asking on the list for help (because it's a dumb question), but I've racked my brains and can't figure it out. I've been happily using ghc for some time now. My current machine died, and the computer folks gave me a new one. Both my old and new were running ubuntu. The new machine came in and I apt-get installed ghc6 ghc6-prof ghc6-docs haskell-mode ghc6-libsrc. But when I try to run ghc on a module that uses Control.Monad.State, I get: ~ ghc --make -fglasgow-exts Main.hs -o hbc Core.hs:24:7: Could not find module `Control.Monad.State': Use -v to see a list of the files searched for. If I say -v, I get: Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main.hs Core.hs:24:7: Could not find module `Control.Monad.State': locations searched: Control/Monad/State.hs Control/Monad/State.lhs *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: Looking in /usr/lib/ghc-6.6/package.conf, I don't find any mention of Control.Monad.State (or anything with State) for that matter. A find in /usr/lib/ghc-6.6 doesn't turn up anything called State, either. I presume that I'm doing something incredibly stupid, but I'd appreciate a bit of help! Thanks! - Hal -- Hal Daume III --- me AT hal3 DOT name | http://hal3.name Arrest this man, he talks in maths. | http://nlpers.blogspot.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and dynamic linking
On Sun, Nov 11, 2007 at 02:01:30AM -0700, Richard Giraud wrote: I foggily remember previous versions of GHC being unable to create programs that use dynamic links to libraries. Dynamic linking to C libraries works fine. Support is patchy for Haskell libraries in GHC 6.8.1; the plan is for GHC 6.10 to support them properly. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: missing Control.Monad.State
On Sun, Nov 11, 2007 at 06:29:36AM -0700, Hal Daume III wrote: running ubuntu. The new machine came in and I apt-get installed ghc6 ghc6-prof ghc6-docs haskell-mode ghc6-libsrc. You probably need libghc6-mtl-dev. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5
On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote: Anytime I see the linker crash I get nervous. Any clues on where to start debugging? Is it deterministic? A hardware fault, e.g. bad RAM, seems likely to me. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
On Sat, Nov 10, 2007 at 11:24:24PM +, Voldermort wrote: I assume that porting an existing implementation would be much easier than starting from scratch. I doubt this is true, but even if it is I would prefer to see features chosen based on their merits. (I'm not familiar with the various proposals, so I can't say anything about this one) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5
Ian Lynagh wrote: On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote: Anytime I see the linker crash I get nervous. Any clues on where to start debugging? Is it deterministic? A hardware fault, e.g. bad RAM, seems likely to me. Thanks Ian I got the same Bus Error in compiling Parsec (as part of extralibs) with OS X 10.5 / XCode 3.0 on a single G4 ppc computer (powerbook). I fear the new Apply toolchain is choking on something, possible split-objs? -- Chris Kuklewicz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
On Sun, Nov 11, 2007 at 03:02:56PM +0300, Bulat Ziganshin wrote: Hello Barney, Sunday, November 11, 2007, 2:34:14 PM, you wrote: An important application which is made impossible by this approach is i propose to start Records project by composing list of requirements/applications to fulfill; we can keep it on Wiki page. this will create base for language theorists to investigate various solutions. i think they will be more motivated seeing our large interest in this extension +1 Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
Whatever system GHC settles on
is almost certain to become part of the Haskell standard, and this
particular system has some deep limitations which could not be got
round without ripping it all out and starting again.
i'd like to have extensible records, but i'd rather like to decompose
this complex language feature into its components, and then have
better support for each of those components, which will be simpler,
could be combined to support different record system variants, and
are likely to have other applications.
in light of this, what library-based record proposals have to offer
are light-weight case studies of useability and feature composition.
once we know which kind of record system we want, we can then
think about which parts of it need better language and implementation
support. even before we converge on any specific system, there
might be features that are shared by all contending proposals.
some time ago (was that really 2 years? trac claims it was), i
suggested that any record system with first-class labels needs
language support for type sharing: if i import modules A and B,
each of which introduces a record-label X, i need some way of
telling the type system that A.X ~ B.X (Trex solved that problem
by not requiring label declarations at all, but Trex labels weren't
first-class objects, either).
i made a haskell prime ticket for it (which was duly classified
as maybe and then ignored;-), to which i also attached an
implementation of records that, in contrast to other record
libraries, does not depend on label ordering, as an illustration:
http://hackage.haskell.org/trac/haskell-prime/ticket/92
http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/92/Data.Record.hs
the code was inspired by Daan's system, i think, because not
removing label overlap made the type class hacking a lot easier,
but went slightly beyond in supporting record concatenation
(i've been waiting for type functions to support overlap
resolution, so that i can port the code; the fact that this is
still future work supports the argument that haskell'2006
should have appeared with a functional dependencies
addendum instead of waiting for better things to happen?-):
poor man's records using nested tuples and declared labels:
apart from record extension (,), we've got field selection (#?),
field removal (#-), field update (#!), field renaming (#@),
symmetric record concatenation (##), .. anything missing?
see main at the bottom for examples of use.
submitted to support proposal for first class labels in Haskell'.
Claus Reinke, February 2006
i just downloaded the old Data.Record code and it still loads
and runs in a recent ghc head, giving examples of all operations
(these days, one might want to clean up the syntax with some
infix constructors, but at the time i was still hoping to get it to
work in hugs as well..):
*Data.Record main
records
r1 : ((A,True),((B,'a'),((C,1),(
r2 : ((A,False),((B,'b'),((C,2),((A,True),((B,'a'),((C,1),()))
r3 : ((D,hi there),((B,[who's calling]),()))
symmetric record concatenation
r4a = r1 ## r3:
((A,True),((B,'a'),((C,1),((D,hi there),((B,[who's
calling]),())
r4b = r3 ## r1:
((D,hi there),((B,[who's
calling]),((A,True),((B,'a'),((C,1),())
record selection
x1 r = (r #? B, r #? C, r #? A)
x1 r1: ('a',1,True)
x1 r2: ('b',2,False)
x1 r4a: ('a',1,True)
x1 r4b: ([who's calling],1,True)
x2 r = (r #? B, r #? D)
x2 r4a: ('a',hi there)
x2 r4b: ([who's calling],hi there)
record field removal
x3 r = r #- D #- B
x3 r1: ((A,True),((C,1),()))
x3 r2: ((A,False),((C,2),((A,True),((B,'a'),((C,1),())
x3 r3: ()
x3 r4a: ((A,True),((C,1),((B,[who's calling]),(
x3 r4b: ((A,True),((B,'a'),((C,1),(
record field update
(r2 #! B) dingbats:
((B,dingbats),((A,False),((C,2),((A,True),((B,'a'),((C,1),()))
record field renaming
(r2 #@ D) C:
((D,2),((A,False),((B,'b'),((A,True),((B,'a'),((C,1),()))
f opts x = let vals = {Opt1 =: default1, ... } |: opts in
... vals ... x ...
where '{Opt1 =: default1, ... }' is some fixed record of default
values, and '|:' is record overwrite. The type of f should be
f :: (a `Subrecord` {Opt1 :=: t1, ...}) = a - b - c
in Hugs' Trex that would be:
Hugs.Trex :t let f opts x = (opt1=default|opts) in f
let {...} in f :: a\opt1 = Rec a - b - Rec (opt1 :: [Char] | a)
but that still doesn't give you things like record concatenation.
in principle, the record-concatenation-for-free trick works with
Trex, but it falls apart if you need to define type classes involving
record types. because then you need to be specific about the
types, making those labels explicit. (btw, what is Flex-like?)
claus
___
Glasgow-haskell-users mailing list
Re: Extensible Records
Hugs.Trex :t let f opts x = (opt1=default|opts) in f
let {...} in f :: a\opt1 = Rec a - b - Rec (opt1 :: [Char] | a)
This completely loses the aim of optional arguments: with this type,
the argument 'opts' cannot have a field 'opt1' (as shown by the
context 'a\opt1'). The type we want should say that 'opts' cannot
have any fields except 'opt1' (though that is optional). Flex cannot
express this type.
(btw, what is Flex-like?)
What I meant by Flex-like systems is that they can only extend
record types by fixed fields. As well as the usual extraction and
deletion of fields, I want first-class operators:
(+:) :: r `Disjoint` s = r - s - r :+: s
x +: y is the concatenation of two records x and y, under the
condition that they have no fields in common
r :+: s is the type of x +: y, assuming x::r and y::s
(|:) :: r `Subrecord` s = s - r - s
x |: y is the update of x by y, under the condition that every field
of y is a field of x of the same type
the type of x |: y is the same as the type of x
The conditions on the types of these operators are important, as they
catch common errors. For example, if a function 'f' has optional
arguments 'opt1::x1, ... optn::xn' you want 'f {optt1 = val}' to give
a type error because you've misspelled 'opt1', not simply to ignore
it. In other words, you need a condition that the fields of the
record argument of f are a subset of {opt1, .., optn}.
These operators can be defined using type families: download the code
from
http://homepage.ntlworld.com/b.hilken/files/Records.hs
This code would only need minimal extensions to GHC to make it
completely useable.
some time ago (was that really 2 years? trac claims it was), i
suggested that any record system with first-class labels needs
language support for type sharing: if i import modules A and B,
each of which introduces a record-label X, i need some way of
telling the type system that A.X ~ B.X (Trex solved that problem
by not requiring label declarations at all, but Trex labels weren't
first-class objects, either).
I believe this issue is completely independent of records. Exactly
the same problem would arise if the same datatype with the same
constructors was defined in two different modules. To solve this we
need a mechanism whereby identically defined types in different
modules can be identified.
i propose to start Records project by composing list of
requirements/applications to fulfill; we can keep it on Wiki page.
this will create base for language theorists to investigate various
solutions. i think they will be more motivated seeing our large
interest in this extension
I am happy to contribute to this, but I am strongly biased in favour
of my own records system!
Barney.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Binary for Vista 64-bit
Hello Chris, Sunday, November 11, 2007, 4:57:39 PM, you wrote: Just wondering if a binary for Vista 64-bit will be released? i've asked here June 19. Simon Marlow asked: The main thing standing in the way of this is the lack of a 64-bit port of mingw. The latest status update I could find is here: http://sourceforge.net/mailarchive/message.php?msg_id=460D8FC1.64E689DB%40dessent.net you can see whole thread for details -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
Hugs.Trex :t let f opts x = (opt1=default|opts) in f
let {...} in f :: a\opt1 = Rec a - b - Rec (opt1 :: [Char] | a)
This completely loses the aim of optional arguments: with this type,
the argument 'opts' cannot have a field 'opt1' (as shown by the
context 'a\opt1'). The type we want should say that 'opts' cannot
have any fields except 'opt1' (though that is optional). Flex cannot
express this type.
ok, then i misunderstood what you wanted to demonstrate with
that example. but then this part doesn't seem to need any extensible
records at all, in fact 'cannot have any fields except' requires non-
extensibility. the standard type for optional things is Maybe thing,
and if you want a record of optional things, a record with default
value Nothing in each field, updated only on the fields you want
to pass a value in, will do fine.
What I meant by Flex-like systems is that they can only extend
record types by fixed fields.
thanks, i find the explanation more helpful than the name.
there are already too many variations around, so unless there
is a concrete implementation/specification, as in the case of
Trex, Daan's system (i think he actually had several, so i should
say 'Daan's scoped labels'), or Oleg's, your's and my libraries,
it might be better to specify the features.
As well as the usual extraction and
deletion of fields, I want first-class operators:
(+:) :: r `Disjoint` s = r - s - r :+: s
x +: y is the concatenation of two records x and y, under the
condition that they have no fields in common
r :+: s is the type of x +: y, assuming x::r and y::s
this is a fairly complex operation, part of which includes a
generalisation of the 'lacks' predicate in Trex to sets of labels,
to catch common errors at the price of additional complexity.
until i saw Daan's system, i would have agreed that this kind
of disjointness/lacks guarantee was necessary for a useable
record type system, but i'm no longer convinced that the
additional complexity (not just in implementation, but in types)
is worth it. but that is just one example of why we might
need several design alternatives - no single system to please
everyone all the time!-)
(|:) :: r `Subrecord` s = s - r - s
x |: y is the update of x by y, under the condition that every field
of y is a field of x of the same type
the type of x |: y is the same as the type of x
i agree that something like this is useful (i should add it to
my own code some time).
The conditions on the types of these operators are important, as they
catch common errors. For example, if a function 'f' has optional
arguments 'opt1::x1, ... optn::xn' you want 'f {optt1 = val}' to give
a type error because you've misspelled 'opt1', not simply to ignore
it. In other words, you need a condition that the fields of the
record argument of f are a subset of {opt1, .., optn}.
again, that is achievable even with haskell's labelled fields, as it
specifically rules out record extension as a programmer error.
for a full record system, there are two parts of the problem:
- opening closed record types to extension
- closing extensible record types to prevent extension
you argue that the second step is necessary, and suggest a
generalisation of systems like Trex, Daan argued that a
surprisingly large subset of practical problems can be
addressed with the first step alone.
since the second step isn't entirely for free (those 'lacks'
and 'Disjoint' predicates keep piling up), there is something
to be said for offering both the step 1 and the step 1+2
systems.
there are several other features in which both kinds of
system go beyond haskell's labelled fields, but many of
those we might be able to agree on?-)
These operators can be defined using type families: download the code
from
http://homepage.ntlworld.com/b.hilken/files/Records.hs
This code would only need minimal extensions to GHC to make it
completely useable.
i still have your original announcement in my inbox!-) i just
haven't got around to it yet, because i wanted to translate
my own system to type functions first, and other things keep
getting in the way..
.. (type sharing)..
I believe this issue is completely independent of records. Exactly
the same problem would arise if the same datatype with the same
constructors was defined in two different modules. To solve this we
need a mechanism whereby identically defined types in different
modules can be identified.
indeed. record labels just raise the urgency of the issue as
a real problem in programming practice.
but I am strongly biased in favour of my own records system!
who isn't?-) that is exactly why none of the systems have made
it into haskell so far. and why we should allow for multiple options
if we want to go any further than the numerous previous attempts.
claus
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Re: Extensible Records
Bulat Ziganshin wrote: i propose to start Records project by composing list of requirements/applications to fulfill; we can keep it on Wiki page. Wiki page duly created http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.1
Dear Ian, Duncan, all, Thank you for looking into the build failure. I actually expected that the autoconf warning didn't really matter, since I couldn't imagine any ReiserFS dependency being critical. The other error is actually quite a lot more weird and critical, for it stops the build. Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5
Split objects does seem to be the source of the crash. With it disabled the compile of Parsec succeeds but linking of System fails due to unknown scattered relocation type 4. I decided to compile the ld tool with debugging to see if I can get more information when ld crashes. Here's what I've found out so far: The ld executable used is actually from the ld64 project and not the cctools project. The cctools' ld is installed as ld_classic on OS X. In theory this should be the same linker as on Tiger and could be used instead of the ld from ld64. That might be a good workaround till ld is fixed: Update ghc's SysTools to use ld_classic instead of ld. 1. Once ld from ld64 is compiled for debug swap out the production ld with the version with debug symbols. 2. ulimit -c unlimited 3. Run ghc's make once again. 4. Load the core dump in GCC This gives the interesting back trace: #0 0x000222ac in ObjectFile::Section::getBaseAddress (this=0x0) at ObjectFile.h:182 #1 0x000224a0 in ObjectFile::Atom::getAddress (this=0x6decb0) at ObjectFile.h:269 #2 0x000c3a30 in mach_o::executable::Writerppc::addObjectRelocs_powerpc (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at MachOWriterExecutable.hpp :2742 #3 0x0001309c in mach_o::executable::Writerppc::addObjectRelocs (this=0x6f65a0, atom=0x6dea30, ref=0x6f34a0) at MachOWriterExecutable.hpp :2678 #4 0x001ab3e4 in mach_o::executable::Writerppc::buildObjectFileFixups (this=0x6f65a0) at MachOWriterExecutable.hpp:3065 #5 0x001be094 in mach_o::executable::Writerppc::buildFixups (this=0x6f65a0) at MachOWriterExecutable.hpp:2398 #6 0x001be108 in mach_o::executable::Writerppc::buildLinkEdit (this=0x6f65a0) at MachOWriterExecutable.hpp:1834 #7 0x001be238 in mach_o::executable::Writerppc::write (this=0x6f65a0, [EMAIL PROTECTED], [EMAIL PROTECTED], entryPointAtom=0x0, dyldHelperAtom=0x0, createUUID=false, canScatter=false, cpuConstraint=ObjectFile::Reader::kCpuAny, biggerThanTwoGigs=false) at MachOWriterExecutable.hpp:1814 #8 0xfec4 in Linker::writeOutput (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:2700 #9 0x0001f5b0 in Linker::link (this=0xbffef608) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:585 #10 0x0002113c in main (argc=465, argv=0xbffefb88) at /Users/coconnor/Development/External_projects/Darwin/ld64-77/src/ld.cpp:3568 Looks like a NULL pointer dereference. Why the pointer is NULL I don't know but that's what I have so far. -Corey On Nov 11, 2007 7:33 AM, Chris Kuklewicz [EMAIL PROTECTED] wrote: Ian Lynagh wrote: On Fri, Nov 09, 2007 at 08:21:09PM -0800, Corey O'Connor wrote: Anytime I see the linker crash I get nervous. Any clues on where to start debugging? Is it deterministic? A hardware fault, e.g. bad RAM, seems likely to me. Thanks Ian I got the same Bus Error in compiling Parsec (as part of extralibs) with OS X 10.5 / XCode 3.0 on a single G4 ppc computer (powerbook). I fear the new Apply toolchain is choking on something, possible split-objs? -- Chris Kuklewicz -- -Corey O'Connor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
IArray (IOToDiffArray IOUArray) Bool : Why it doesn't exist ?
IOUArray Bool exists, and is even a bits array in reality (which makes it really efficient), is there any reason that DiffUArray Bool can't exist ? -- Jedaï ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
