Re: Records in Haskell
Barney Hilken b.hilken at ntlworld.com writes: Please remember SPJ's request on the Records wiki to stick to the namespace issue. We're trying to make something better that H98's name clash. We are not trying to build some ideal polymorphic record system. I must admit that this attitude really gets my hackles up. Barney. So Barney, the obligation on you is clear: - pick one of the many theoretically sound clean designs for records - (or make up your own) - write it up on the wiki - show what work it would need to get there from where we are - encourage discussion on this forum One thing I can be pretty sure of: proposals not written up won't get implemented. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
wren ng thornton wren at freegeek.org writes: I'm not sure that I like the current proposals for how to control the non/automatic-ness of polymorphism (for reasons I can spell out later, if desired). But we definitely want to have something that's a bit more cultured than simply making all record projectors polymorphic over records. Wren, I'm not sure if you've got it straight. (It's a subtle issue.) This is an area where SORF differs from DORF: - SORF can't hide the representation of a given field name (so a client program can 'guess' a field identifier) That's because SORF is driven by String Kind, which cannot be scope controlled. - DORF uses (Proxy) types for (roughly) the same purpose as the String Kinds. But because they're types, you can control the scope, and keep the abstraction. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding the -A and the -H flags
On 27/02/2012 17:34, Johan Tibell wrote: Hi Simon, On Mon, Feb 27, 2012 at 12:25 AM, Simon Marlowmarlo...@gmail.com wrote: Think of -Hsize as a variable -A option. It says: I want to use at least size bytes, so use whatever is left over to increase the -A value. Doesn't that describe exactly what it means? Maybe. Let me start with the mental model I approach this with: the allocation area (i.e. the nursery) should have a size in the order of megabytes, often around the size of the L2 cache. Ah, so I see where your confusion arises - this assumption is not true in general. Just discard the assumption, and I think everything will make more sense. Picking a size for -A around the L2 cache is often a good idea, but not always. GHC defaults to -A512K, but programs that benefit from much larger sizes are quite common. For more about the tradeoff, see my SO answer here: http://stackoverflow.com/questions/3171922/ghcs-rts-options-for-garbage-collection/3172704#3172704 Given this model, I read the above as: * if you set e.g. -H1G, you'll get an allocation area which is in the order of 1Gb large. That makes no sense to me. Right - see above. In fact there's no problem with a 1GB nursery. * The suggested size of the total heap (-H) has something to do with the size of the allocation area (-A). This makes no sense to me either. So either I do understand what -H does, but it makes no sense to me, or I don't understand what -H does, but what it does makes sense. Perhaps the confusion lies in the phrase left over. Left over from what? Left over after the memory required by the non-nursery parts of the heap has been deducted. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
wren ng thornton wren at freegeek.org writes: FWIW, this is the concern I alluded to earlier. Namely that we may want to have two (or more), er, 'classes' of records--- where a field is polymorphic over an individual class, but we don't want those classes to merge simply because they happened to choose the same name and type for the field. I agree 'classes' is a misleading word for that. Isn't what you want two (or more) namespaces for records -- that is, for their fields? This is the DORF approach. (Barney seems to be describing the SORF approach -- he's got DORF wrong.) One of the namespaces includes Product.name; another Person.name. (So I'm taking a namespace as equivalent to a module.) You can have multiple records with a `name` field in each module (Customer, Employee, Business Contact, etc) -- so this is already better than H98.) Providing you're coding in a module that imports only one of those namespaces, you can use `name` unqualified. If you're coding in a module that imports both, you must use `name` qualified. If you try to apply (Product.name customer) you'll get a type failure (no instance). I'm not sure it's a good proposal, but it seems like the only way to handle this issue is to (1) introduce a new kind for semantically-oriented field names, That's what SORF does: the String Kind and (2) make the Has class use that kind rather than a type-level string. No proposal is using a _type_-level string. Barney's confused you. DORF uses a type (regular importable/qualifiable/hidable) with a prefix to the field name: data Proxy_name Where you're in a module that imports both the `name`s per above, the desugarrer would generate Product.Proxy_name and Person.Proxy_name. (That's all rather awkward to get right, which is why I prefer the sugar.) By (1), what I mean is that rather than referring to the field as name, we would declare PersonalName and BrandName and then use those in lieu of the string. And if we do that, then (2) demands that we must somehow make explicit which one we mean, should we want the `name` field to be polymorphic for some given record declaration. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unpack primitive types by default in data
On 17/02/2012 18:34, Johan Tibell wrote: On Fri, Feb 17, 2012 at 3:13 AM, Roman Leshchinskiyr...@cse.unsw.edu.au wrote: True, I didn't phrase that right at all. AFAIK, in Java, there is a one-to-one correspondence between a primitive type and its boxed version. So you can say that boxed integers will be unboxed when necessary and it's clear what that means. But in Haskell, there is no such one-to-one correspondence. This is a very good thing but it makes specifying and understanding what will be unboxed when much harder. You're right that it's harder to specify exactly when unpacking happens but default is better, both if you know how it works and if you don't. - If you don't know how it works (e.g. you're a beginner/intermediate level Haskeller) the default is saner. - If you know how it works you don't have to write all these UNPACKs that sit on every single primitive field* in our core libraries. * I did a quick count of how many primitive fields are manually unpacked in text, bytestring, and containers. Here are the results (unpacked/total): text: 27/30 Not unpacked: Data/Text/Lazy/Builder/Int.hs:data T = T !Integer !Int Data/Text/Lazy/Read.hs:data T = T !Integer !Int Data/Text/Read.hs:data T = T !Integer !Int These three seem all to get their boxed removed anyway as they're just used as a return type and get turned into (# Integer, Int# #) anyway. An unpack here wouldn't have hurt. bytestring: 3/3 containers: 13/13 I would be interested to see if there's a case where primitive fields aren't unpacked and that's not a misstake. I think there are some in GHC - I've been surprised occasionally when adding an UNPACK makes things worse. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Barney Hilken b.hilken at ntlworld.com writes:
My objection is that I'm not sure if there is ever a case where you
really want things to be polymorphic over all records.
Well, I don't have a simple, really convincing example, but there are
certainly things I want to play with.
More importantly, DORF automatically attaches one class to each label, but
this is often not what you want.
Barney, you seem to be very confused. Added to that you're mixing up DORF with
SORF. Agreed both proposals are similar, but there are crucial differences and
you've completely befuddled them.
In DORF (and SORF) there is only one class -- namely `Has`, with methods `get`
and `set`.
SORF 'attaches' one Kind for each label. (I'm not sure 'attaches' is the right
word -- perhaps 'provides' is better? It's a String Kind same as the label
name.)
In DORF you must _declare_ a _type_ for the label. (Hence **Declared**
Overloaded Record Fields.) Since it's declared and it's a type, it has usual
namespace (module) control. You can declare as many as you want, providing you
respect the namespacing.
For example, if you have two fields firstname and lastname the
associated classes are less useful:
what you really want is
class (Has r firstname String, Has r lastname String) =
HasPersonalName r
That example is a SORF declaration: it uses String Kinds.
The DORF equivalent would be:
class (Has r Proxy_firstname String, Has r Proxy_lastname String) =
HasPersonalName r
Note: familiar Haskell proxy types, _not_ new/untried String Kinds.
That Proxy stuff is a mouthful, and easy to mistype. I prefer the sugar:
class (r{firstname, lastname :: String} ) = ...
so that you can define
fullname :: HasPersonalName r = r - String
fullname r = r.firstname ++ ++ r.lastname
You may also want to define subclasses to express more specific conditions.
In general, the compiler
cannot automatically deduce what is semantically important: you need to
define it yourself. The Has
class is the base on which you can build.
...
My approach achieves the same as
DORF (and more), but using existing language features instead of introducing
new ones.
Barney.
What you say there applies to SORF, not DORF. DORF deliberately uses existing
class features and familiar type instance resolution. (Because I didn't like
the 'experimental' Kinds in SORF, and you couldn't control their namespace.)
So what you call My approach is almost identical to DORF -- except that
you're confusing it with SORF syntax. What you're criticising is SORF, not
DORF.
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci 7.4.1 no longer loading .o files?
On 21/02/2012 04:57, Evan Laforge wrote: On Mon, Feb 20, 2012 at 8:33 PM, Evan Laforgeqdun...@gmail.com wrote: On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crossercros...@average.org wrote: On 02/20/2012 10:46 AM, Evan Laforge wrote: Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files instead of loading their .o files? E.g.: I don't *know* but could this have anything to do with this? http://hackage.haskell.org/trac/ghc/ticket/5878 Indeed it was, I initially thought it wasn't because I wasn't using flags for either, but then I remember ghci also picks up flags from ~/.ghci. Turns out I was using -fno-monomorphism-restriction because that's convenient for ghci, but not compiling with that. I guess in the case where an extension changes the meaning of existing code it should be included in the fingerprint and make the .o not load. But my impression is that most ExtensionFlags let compile code that wouldn't compile without the flag. So shouldn't it be safe to exclude them from the fingerprint? Either way, it's a bit confusing when .ghci is slipping in flags that are handy for testing, because there's nothing that tells you *why* ghci won't load a particular .o file. After some fiddling, I think that -osuf should probably be omitted from the fingerprint. I use ghc -c -o x/y/Z.hs.o. Since I set the output directly, I don't use -osuf. But since ghci needs to be able to find the .o files, I need to pass it -osuf. The result is that I need to pass ghc -osuf when compiling to get ghci to load the .o files, even though it doesn't make any difference to ghc -c, which is a somewhat confusing requirement. In fact, since -osuf as well as the -outputdir flags affect the location of the output files, I'd think they wouldn't need to be in the fingerprint either. They affect the location of the files, not the contents. If you found the files it means you already figured out what you needed to figure out, it shouldn't matter *how* you found the files. And doesn't the same go for -i? Isn't it valid to start ghci from a different directory and it should work as long as it's able to find the files to load? I agree - I'll omit all these flags from the recompilation check in 7.4.2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci 7.4.1 no longer loading .o files?
On 27/02/2012 05:08, Evan Laforge wrote: Indeed it was, I initially thought it wasn't because I wasn't using flags for either, but then I remember ghci also picks up flags from ~/.ghci. Turns out I was using -fno-monomorphism-restriction because that's convenient for ghci, but not compiling with that. I guess in the case where an extension changes the meaning of existing code it should be included in the fingerprint and make the .o not load. But my impression is that most ExtensionFlags let compile code that wouldn't compile without the flag. So shouldn't it be safe to exclude them from the fingerprint? Either way, it's a bit confusing when .ghci is slipping in flags that are handy for testing, because there's nothing that tells you *why* ghci won't load a particular .o file. After some fiddling, I think that -osuf should probably be omitted from the fingerprint. I use ghc -c -o x/y/Z.hs.o. Since I set the output directly, I don't use -osuf. But since ghci needs to be able to find the .o files, I need to pass it -osuf. The result is that I need to pass ghc -osuf when compiling to get ghci to load the .o files, even though it doesn't make any difference to ghc -c, which is a somewhat confusing requirement. In fact, since -osuf as well as the -outputdir flags affect the location of the output files, I'd think they wouldn't need to be in the fingerprint either. They affect the location of the files, not the contents. If you found the files it means you already figured out what you needed to figure out, it shouldn't matter *how* you found the files. And doesn't the same go for -i? Isn't it valid to start ghci from a different directory and it should work as long as it's able to find the files to load? Further updates: this has continued to cause problems for me, and now I'm wondering if the CPP flags such as -D shouldn't be omitted from the fingerprint too. Here's the rationale: I use CPP in a few places to enable or disable some expensive features. My build system knows which files depend on which defines and hence which files to rebuild. However, ghci now has no way of loading all the .o files, since the ones that don't depend on the -D flag were probably not compiled with it and those that do were. This also plays havoc with the 'hint' library, which is a wrapper around the GHC API. I can't get it to load any .o files and it's hard to debug because it doesn't tell you why it's not loading them. In addition, ghc --make used to figure out which files depended on the changed CPP flags and recompile only those. Now it unconditionally recompiles everything. I always assumed it was because GHC ran CPP on the files before the recompilation checker. If that's the case, do the CPP flags need to be included in the fingerprint at al? It seems like they're already taken into account by the time the fingerprints are calculated. I reviewed http://hackage.haskell.org/trac/ghc/ticket/437 and I noticed there was some question about which flags should be included. Including the language flags and -main-is since that was the original motivation (but only for the module it applies to, of course) makes sense, but I feel like the rest should be omitted. I don't see how we could avoid including -D, since it might really affect the source of the module that GHC eventually sees. We've never taken -D into account before, and that was incorrect. I can't explain the behaviour you say you saw with older GHC's. unless your CPP flags only affected the imports of the module. Well, one solution would be to take the hash of the source file after preprocessing. That would be accurate and would automatically take into account -D and -I in a robust way. It could also cause too much recompilation, if for example a preprocessor injected some funny comments or strings containing the date/time or detailed version numbers of components (like the gcc version). So for now I'm going to continue to take into account -D. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Isaac Dupree ml at isaac.cedarswampstudios.org writes: Darn, I misinterpreted DORF. There was too much text and too many options. Sorry! You might do better to stick to the implementor's page if you want a less 'option-laden' description. Also better to skip the speculative bits until you've got the basics clear. Tell me if I'm correct: A. Every declaration with record syntax creates Has instances for all fields [1]. Correct B. Has, get and set may not be written by users (guessing due to representation-hiding fail). Correct: I want the implementors to have design space for the mechanics behind the scenes. C. You create functions using fieldLabel name [...] Correct-ish: create both functions and a proxy types. It's really the type that drives inference, not the function. D. which have the magical effect of, when in scope unqualified, ... Nothing 'magical' going on: they're ordinary functions and types, with ordinary import/export/hiding. And you can use them qualified if you'd rather. ... causing data types defined with record syntax to be accessible through that particular fieldLabel function (and no other way). The fieldLabel function behaves very similar to the H98-generated function. The difference is with DORF it's overloaded, but H98 is monomorphic. You can still access the fields as per H98 through pattern match (using the data constructor), or positionally. [Yes I know that if we were designing a 'true' polymorphic record system we'd ban positional access.] E. (When two fieldLabels of the same name are in scope unqualified, declaring a record containing that name is an error.) Correct. Just like having any other clash of names in scope (for example all the competing declarations of `map`). And just like those, you can use module qualifiers to resolve the clash. F. So adding an import (for some other reason for your code) that happens to include a fieldLabel can make your records accidentally be more visible, rather than be compile-error or no-effect. Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to access a record with a field `name` declared in module B. You'll get a 'no instance' compile fail. Same familiar rules as for any instance resolution. This is the crucial difference compared to SORF: which can't control the scope of its String Kind. (Apologies that I added a speculative discussion of whether DORF could use String Kinds. I said that if doing so would open the 'back door' to the abstraction, then I'll stick with types.) I feel weird about record fields having an option that depends on whether something's in scope and cannot be controlled syntactically. Maybe we can fix that without making the syntax worse. Absolutely agree. I designed DORF to correct that deficiency in SORF (as I saw it). G. It is possible (but rather ugly) to use dot-notation when there are multiple fieldNames of the same name in scope. [2] Yep, agree with the ugly. Hmm. Maybe this is Haskelly as well as convenient enough. Did I get everything right? What do you think about my concern about F? Well done! Nearly everything. I hope I've allayed your concerns re F. AntC [1] http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields /ImplementorsView [2] http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields /DotPostfix#UsingDotnotationamongstqualifiednames ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Hi,
Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to
access a record with a field `name` declared in module B. You'll get a 'no
instance' compile fail. Same familiar rules as for any instance resolution.
This is the crucial difference compared to SORF: which can't control the scope
of its String Kind. (Apologies that I added a speculative discussion of
whether DORF could use String Kinds. I said that if doing so would open
the 'back door' to the abstraction, then I'll stick with types.)
Perhaps this situation could occur though?
Module A
fieldLabel name String
Module B
import A -- unknowingly picking up the name label
data Foo = Foo { name :: String } -- uses the name label by accident
So there'd have to be some syntax to make sure you intend to use a
label rather than accidentally use it?
(Not that this is a big issue, the situation is surely minor compared
to sharing unrelated labels all the time)
Oliver
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New STM?
On 17/02/2012 18:36, wren ng thornton wrote: Hello all, I had some patches committed to STM a while back[1], and for some reason I was expecting them in the new GHC release. Does STM only ship with the Platform? If not, then any idea when the next version of STM will be released? Thanks for the reminder, I just uploaded 2.3: http://hackage.haskell.org/package/stm Cheers, Simon [1] http://hackage.haskell.org/trac/ghc/ticket/5104 http://www.haskell.org/pipermail/cvs-libraries/2011-April/012914.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recent changes to hsc2hs break wrapping c++
On 18/02/2012 05:22, Evan Laforge wrote:
On Thu, Feb 16, 2012 at 4:27 AM, Simon Marlowmarlo...@gmail.com wrote:
I'm not sure why you're using the C++ compiler from hsc2hs, and I don't
think that is guaranteed to work. But maybe we can fix it if there's a
legitimate reason to want it.
Well, consider if you're writing c++ along with haskell. You can
communicate with c++ by passing structs, which are guaranteed to have
the layout as c, and call functions wrapped in extern C {...}. You
can't call class constructors from haskell or anything, but you can
create structs to pass in and use directly in c++, which is already
quite convenient.
But those C structs are going to be defined in C++ headers with other
C++ cruft in them that a C compiler is not going to understand. But
if you pass -c g++ to hsc2hs then it works just fine to emit the
struct offsets.
Otherwise, I'm not sure how you'd call C++ from the haskell FFI. Like
I said, I guess you'd have to split the C structs into separate
headers, or maybe wall off the C++ bits with ifdefs. Actually, I
guess the ifdef part wouldn't be *so* bad, at last as far as ifdeffery
goes, but it is intrusive on existing headers, which is not going to
be possible in all situations. Of course if the C++ API was written
without regard to the haskell FFI it is likely to require structs to
be constructed with constructors instead of direct pokes, which is
beyond the FFI's capabilities. But in the case where it is designed
to use plain structs in the haskell-facing bits, it's very convenient
how you can just pass -c g++ to earlier versions of hsc2hs and have it
just work.
Ok, I buy that it's useful to be able to do this. I suggest you make a
ticket and describe the problem. Is it possible you'd be able to make a
patch to fix it too?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Barney Hilken b.hilken at ntlworld.com writes: After more pondering, I finally think I understand what the DORFistas want. Barney, 1) please don't personalise. I designed DORF, built a proof of concept, got it running, asked for feedback (got some very useful thoughts from SPJ), built a prototype, posted the wiki pages. I'm not a DORFista; I'm somebody who wants to improve the Haskell records namespace issue. 2) whether or not you think you know what some people want, you don't understand DORF, and you've mixed it up with SORF. You've then caused a great long thread of confusion. In particular, at exactly where DORF is designed to avoid (what I see as) a weakness in SORF, you've alleged DORF has that weakness. Here is an example: ... (by the way, you've used SORF syntax in those examples) It doesn't make any sense to apply your functions to my records or vice- versa, Exactly! and that's what the DORF design avoids, whereas SORF suffers from it. but because we both chose the same label, SORF uses the same label in the sense of the same String Kind. the compiler allows it. Putting the code in separate modules makes no difference, since labels are global. DORF's labels are not global, they're proxy _types_ so that the scope is controlled in the usual way. So using separate modules makes all the difference. Here is a simple solution, using SORF: ... I think your solution would work just as well 'translated' into DORF. (But then it's a solution to something that isn't a problem in DORF.) ... than building the mechanism in to the language as DORF does, ... Barney. DORF is not building the mechanism in to the language, nor is it introducing any new language features, only sugar. The prototype runs in GHC v7.2.1. All I've done is hand-desugarred. (Look at it for yourself, it's attached to the implementor's page.) SORF, on the other hand, needs user-defined Kinds, which are only just being introduced in v7.4, and don't yet include String Kind. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Installing binary tarball fails on Linux
On 23/02/2012 21:24, Johan Tibell wrote:
Hi,
I tried to install the GHC 7.4.1 32-bit binary tarball today and ran
into the error below. Are 32-bit GHC's not supported on 64-bit
Linuxes?
The error:
Installing library in /usr/local/lib/ghc-7.4.1/ghc-prim-0.2.0.0
ghc-cabal: Bad interface file: dist-install/build/GHC/Classes.hi
magic number mismatch: old/corrupt interface file? (wanted 33214052, got
129742)
Is it possible you also had the 64-bit version installed? To install
the two side-by-side, you have to set the --prefix or --libdir so they
don't clash.
Also, the 32-bit version won't work out of the box on a 64-bit Linux
install without some -optc -m32 -opta -m32 -optl -m32.
Cheers,
Simon
Full log:
$ tar jxf ghc-7.4.1-i386-unknown-linux.tar.bz2
$ cd ghc-7.4.1/
tibell@tibell:ghc-7.4.1$ ./configure --prefix=/usr/local
checking for path to top of build tree... /tmp/ghc-7.4.1
Build platform inferred as: i386-unknown-linux
Host platform inferred as: i386-unknown-linux
Target platform inferred as: i386-unknown-linux
GHC build : i386-unknown-linux
GHC host : i386-unknown-linux
GHC target : i386-unknown-linux
checking for perl... /usr/bin/perl
checking if your perl works in shell scripts... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gsed... sed
checking for gcc... /usr/bin/gcc
checking for gcc... /usr/bin/gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/bin/gcc accepts -g... yes
checking for /usr/bin/gcc option to accept ISO C89... none needed
checking version of gcc... 4.4.3
checking how to run the C preprocessor... /usr/bin/gcc -E
checking whether ld understands --hash-size=31...
checking whether ld understands --reduce-memory-overheads...
checking for extra options to pass gcc when compiling via C... -fwrapv
checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done
checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0,
CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done
checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1,
CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done
checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2,
CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done
checking for .subsections_via_symbols... no
checking for GNU non-executable stack support... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking size of void *... 8
checking for ar... /usr/bin/ar
checking whether /usr/bin/ar is GNU ar... yes
checking for ar arguments... q
checking whether ranlib is needed... no
configure: creating ./config.status
config.status: creating settings
config.status: creating mk/config.mk
config.status: creating mk/install.mk
Configuration done, ready to 'make install'
(see README and INSTALL files for more info.)
$ sudo make install
make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES
/usr/bin/install -c -m 755 -d /usr/local/share/man
/usr/bin/install -c -m 755 -d /usr/local/share/man/man1
/usr/bin/install -c -m 644 docs/man/ghc.1 /usr/local/share/man/man1
rm -f driver/split/dist/ghc-split
echo '#!/usr/bin/perl'
driver/split/dist/ghc-split
echo '$TARGETPLATFORM = i386-unknown-linux;' driver/split/dist/ghc-split
echo '$TABLES_NEXT_TO_CODE = YES;' driver/split/dist/ghc-split
cat driver/split/dist/ghc-split.prl
driver/split/dist/ghc-split
/usr/bin/install -c -m 755 -d /usr/local/lib/ghc-7.4.1
/usr/bin/install -c -m 755 driver/split/dist/ghc-split
/usr/local/lib/ghc-7.4.1
/usr/bin/install -c -m 755 -d /usr/local/bin
rm -f /usr/local/bin/ghci-7.4.1
create () { touch $1 chmod 755 $1 ; } create
/usr/local/bin/ghci-7.4.1
echo '#!/bin/sh' /usr/local/bin/ghci-7.4.1
echo 'exec /usr/local/bin/ghc-7.4.1 --interactive ${1+$@}'
/usr/local/bin/ghci-7.4.1
chmod +x /usr/local/bin/ghci-7.4.1
rm -f /usr/local/bin/ghci
ln -s ghci-7.4.1 /usr/local/bin/ghci
/usr/bin/install -c -m 755 -d /usr/local/lib/ghc-7.4.1/include
/usr/bin/install -c -m 755 -d /usr/local/lib/ghc-7.4.1/include/.
/usr/bin/install -c -m 644 includes/./*.h
/usr/local/lib/ghc-7.4.1/include/.//usr/bin/install -c -m 755
Re: parallel build fixes for 7.4.2
On 24/02/2012 08:16, Conrad Parker wrote: Hi, recently we've been tweaking our internal build system at Tsuru to handle parallel builds of both cabal packages via 'cabal-sort --makefile' and our local code tree via 'ghc -M'. In addition to the recompilation checker fixes of #5878, the following would be great to have in 7.4.2: 1) http://hackage.haskell.org/trac/ghc/ticket/5891 -- the patch fixes a race condition in creating parent directories for built object files Due to be merged. 2) master commit b6f94b5 Compile link .note section separately from main.c -- I think this is the patch that fixes link errors we've seen during parallel builds (via ghc -M) with 7.4.1, such as: /x/y/z.o: file not recognized: File truncated and: /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 internal error, aborting at ../../bfd/merge.c line 872 in _bfd_merged_section_offset I've asked Ian to merge this into the branch, so it will be in 7.4.2. Will everything currently in master already be included in the next release or is it a separate branch? (If it's a separate branch I'll do some more testing to confirm that b6f94b5 is the patch that fixes the link error). The branch is separate (ghc-7.4) and we merge specific fixes from master. The best way to make sure we don't forget something is to make a ticket for it, then it goes through the open-merge-fixed workflow. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Increasing number of worker tasks in RTS (GHC 7.4.1) - how to debug?
On 26/02/2012 02:23, Sanket Agrawal wrote: I have to take back what I said about the increase in worker tasks being related to some Mac OS pthread bug. I can now reproduce the issue on Linux (Redhat x86_64) too (and cause a segmentation fault once in a while). So, now, it seems the issue might be due to either some kind of interaction between GHC RTS, and C pthread mutexes, or a bug in my code. What I have done is to create a simple test case that reproduces the increase in number of worker threads with each run of Haskell timer thread (that syncs with C pthreads). I have put up the code on github with documentation on how to reproduce the issue: https://github.com/sanketr/cffitest I will appreciate feedback on whether it is a bug in my code, or a GHC bug that needs to be reported. What version of GHC is this? I vaguely remember fixing something like this. The rule of thumb is: if you think it is a bug then report it, and we'll investigate further. Cheers, Simon On Sat, Feb 25, 2012 at 3:41 PM, Sanket Agrawal sanket.agra...@gmail.com mailto:sanket.agra...@gmail.com wrote: On further investigation, it seems to be very specific to Mac OS Lion (I am running 10.7.3) - all tests were with -N3 option: - I can reliably crash the code with seg fault or bus error if I create more than 8 threads in C FFI (each thread creates its own mutex, for 1-1 coordination with Haskell timer thread). My iMac has 4 processors. In gdb, I can see that the crash happened in __psynch_cvsignal () which seems to be related to pthread mutex. - If I increase the number of C FFI threads (and hence, pthread mutexes) to =7, the number of tasks starts increasing. 8 is the max number of FFI threads in my testing where the code runs without crashing. But, it seems that there is some kind of pthread mutex related leak. What the timer thread does is to fork 8 parallel haskell threads to acquire mutexes from each of the C FFI thread. Though the function returns after acquiring, collecting data, and releasing mutex, some of the threads seem to be marked as active by GC, because of mutex memory leak. Exactly how, I don't know. - If I keep the number of C FFI threads to =6, there is no memory leak. The number of tasks stays steady. So, it seems to be pthread library issue (and not a GHC issue). Something to keep in mind when developing code on Mac that involves mutex coordination with C FFI. On Sat, Feb 25, 2012 at 2:59 PM, Sanket Agrawal sanket.agra...@gmail.com mailto:sanket.agra...@gmail.com wrote: I wrote a program that uses a timed thread to collect data from a C producer (using FFI). The number of threads in C producer are fixed (and created at init). One haskell timer thread uses threadDelay to run itself on timed interval. When I look at RTS output after killing the program after couple of timer iterations, I see number of worker tasks increasing with time. For example, below is an output after 20 iterations of timer event: MUT time (elapsed) GC time (elapsed) Task 0 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 1 (worker) :0.00s( 0.00s) 0.00s( 0.00s) ...output until task 37 snipped as it is same as task 1... Task 38 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 39 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 40 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 41 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 42 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 43 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 44 (worker) :0.52s( 10.74s) 0.00s( 0.00s) Task 45 (worker) :0.52s( 10.75s) 0.00s( 0.00s) Task 46 (worker) :0.52s( 10.75s) 0.00s( 0.00s) Task 47 (bound) :0.00s( 0.00s) 0.00s( 0.00s) After two iterations of timer event: MUT time (elapsed) GC time (elapsed) Task 0 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 1 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 2 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 3 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 4 (worker) :0.16s( 1.21s) 0.00s( 0.00s) Task 5 (worker) :0.16s( 1.21s) 0.00s( 0.00s) Task 6 (worker) :0.16s( 1.21s) 0.00s( 0.00s) Task 7 (worker) :0.16s( 1.21s) 0.00s( 0.00s) Task 8 (worker) :0.48s
Re: Records in Haskell
Gábor Lehel illissius at gmail.com writes: 2012/2/25 Gábor Lehel illissius at gmail.com: Please correct me if I've misunderstood or mischaracterized any aspect of DORF. Okay, I did end up misunderstanding and mischaracterizing at least two aspects of DORF. Re-reading the wiki page: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields Sorry, Gábor, but you've still mis-understood. I tried so hard to explain it clearly! it's clear that you would not have to write fieldLabel declarations for every single field of every single record, But yes you do have to declare every fieldLabel that's going to appear in a record decl within a module compiled under DORF. (Even if the field only appears once in one record -- sorry!) You can, though, mix records/fields from modules compiled under H98 monomorphs (providing no clash of names!) only for the ones you wish to be shared and usable polymorphically. By default, fields of individual records would be specific to that record (monomorphic in the type of the record), No! the record decl would (try to) generate an instance for every field of every record, then the compile would fail because there was no fieldLabel declared. So the difference between DORF and my variant would be: ... (You've misunderstood DORF, so got the next bit wrong.) It wasn't clear to me before that DORF retains record-monomorphic fields, ... (It doesn't!) In DORF you can presumably still use a record-monomorphic field selector to help infer the concrete type of the record Kind-of: you can declare a fieldLabel with a monomorphic type (if you want it to only appear in a single record), then it helps type inference. ... One troubling consequence of DORF -- again, if I'm understanding things correctly -- is that due to implicit field instances a module import can change the meaning of your program: No you aren't understanding correctly, so: no, a module import can't change the meaning. (It might mean the program fails to compile, due to name clash.) I've responded to same later posts to clarify this. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Enormous FFI speedup observed
On 27/02/2012 10:46, Joachim Breitner wrote: Hi, as I wrote on http://www.joachim-breitner.de/blog/archives/546-GHC-7.4.1-speeds-up-arbtt-by-a-factor-of-22.html I observe an enormous speed up (22×) in arbtt, and it seems to be related to FFI function calls. The release notes do not give a hint what has changed to result in this speed up, so I’m curious whether someone here knows the reason, or can make a good guess? A couple of guesses: Avoiding slop in pinned objects: http://hackage.haskell.org/trac/ghc/changeset/cc2ea98ac4a15e40a15e89de9e47f33e191ba393 Stack chunks: http://hackage.haskell.org/trac/ghc/changeset/f30d527344db528618f64a25250a3be557d9f287 but it's hard to know for sure without investigating more closely. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Henrik Nilsson nhn at Cs.Nott.AC.UK writes:
Hi,
Just checking my understanding here as I have not followed this thread
in all its details.
So, with both DORF ''', am I correct in understanding
that polymorphic fields, be it universally quantified as in
Good question Henrik! It's explicitly answered in the wiki, because it's a
tricky area. Briefly:
- both of those varieties of poly fields are possible
- both can be declared in records
- both can be extracted and applied in polymorphic contexts
- DORF supports updating the universally quantified,
including changing the type of the field and therefore of the record.
(Also there's a Quasifunctor proposal for SORF to do that.)
- Neither approach supports updating the existential/higher-ranked variety.
(There are all the complexities you discuss in detail. They are solved (with
quite a bit of complexity behind the scenes), except for updating h-r types.)
You can still use explicit data constructurs to pattern match and update h-r
fields.
Question for you: (you've already given an example of wanting to update a
universally quant'd field and change its type)
Do you want to update a h-r field?
If so, what's the use case?
AntC
data ARecordType a =
C1 {
...,
fieldX :: a,
...,
fieldY :: a - a,
...
}
or existentially quantified as in:
data AnotherRecordType =
forall a . C2 {
...,
fieldU :: a,
...,
fieldV :: a - Int,
...
}
would no longer be possible?
Note that the type variable a in both cases scope just over the
constructor(s) of the data type in question. So any attempt at
declaring the types of the fields outside of this context,
be it explicitly with the fieldLabel notation, or implicitly as
per your proposal, would not be possible. E.g.
fieldLabel fieldY :: a - a
would presumably mean
fieldLabel fieldY :: forall a . a - a
resulting in ARecordType becoming second-order polymorphic
where the value of fieldY would *have* to be a polymorphic function,
which is very different from the original definition.
Similarly, the whole point with the existentially quantification is
to allow a number of fields to share some specific but arbitrary type,
which again means that any attempt to type these fields outside of the
context of the datatype to which they belong would result in something
different.
Note that fieldU and fieldV cannot be used as projection functions
due to escaped type variables, but that field selection by pattern
matching is perfectly fine.
Both constructions above are very useful and, I'd argue that a design
that rules them out actually is a rather poor fit for a language like
Haskell.
To be completely honest, I, at least, would be much happier keeping
working around the present limitations of Haskell's named fields by
picking my field names carefully, than losing the above.
Or am I missing something? E.g. is the idea that sharing of fields
only applies to fields of monomorphic type, i.e. whose type can be
declared globally?
Best,
/Henrik
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
J. Garrett Morris jgmorris at cs.pdx.edu writes:
Has x f has no semantic content besides type x having an f field; Ord
has (at least in the programmer's mind, even if the language can't check
it) meaning beyond the simple presence of a compare function.
/g
Note that under both SORF and DORF, there are three arguments to the `Has`
class. The third is specifically to spec or constrain the type of the result.
A decl:
data Rec a = Ord a = Rec{ flda :: a }
Expects:
flda :: (r{ flda :: a }, Ord a) = r - a
Where the {...} in the constraint is sugar for the Has class. (DORF and SORF
differ slightly in how that's implemented.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Barney Hilken b.hilken at ntlworld.com writes: This should be used to generate internal constraints and not be exposed to the end user and not automatically abstract over fields. Barney, I'm not going to try to defend or explain what Greg means by that comment, but I do want to talk about: insistence that the Has class should be hidden from the user. ... I think the Has class would be useful to programmers and no harder to understand than other Haskel classes. It should not be hidden. Barney. I agree that what the `Has` class is doing is useful, and indeed the programmer needs to understand it. SPJ suggested syntactic sugar for the Has class. The DORF proposal embraces it whole-heartedly, and expects the programmer would use the sugar. There's two reasons for avoiding writing explicit `Has`: 1. It's tricky syntax and easy to get wrong. Specifically, all your examples in later posts have confused it. 2. The implementation of overloadable record fields (whether SORF or DORF) is going to be tricky to get right. We'll need equality and class constraints. There needs to be some space for the implementors to tune the design. I think the sugar is hiding the implementation, not the existence of the `Has` class -- as is good practice. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Greg Weber greg at gregweber.info writes: I looked at the DORF implementers view http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields /ImplementorsView It appears that we still have no solution for record updates that change the type of a polymorphic field. There's two varieties of polymorphic fields: - the type-changing variety DORF has a solution for update/changing the type of field and record (always has since the proof of concept in December) SORF has a speculative suggestion of Quasifunctor (looks like this needs tightening up??) - the higher-ranked variety neither proposal has a way of updating (well, DORF did but it's an unscalable hack [SPJ], I put it on the wiki anyway, in case somebody can improve it) AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Oliver Batchelor saulzar at gmail.com writes:
Hi,
Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to
access a record with a field `name` declared in module B. You'll get a 'no
instance' compile fail. Same familiar rules as for any instance resolution.
This is the crucial difference compared to SORF: which can't control the
scope
of its String Kind. (Apologies that I added a speculative discussion of
whether DORF could use String Kinds. I said that if doing so would open
the 'back door' to the abstraction, then I'll stick with types.)
Perhaps this situation could occur though?
Module A
fieldLabel name String
Module B
import A -- unknowingly picking up the name label
data Foo = Foo { name :: String } -- uses the name label by accident
So there'd have to be some syntax to make sure you intend to use a
label rather than accidentally use it?
(Not that this is a big issue, the situation is surely minor compared
to sharing unrelated labels all the time)
Oliver
Thanks Oliver, hmm ...
Did module B import A unqualified?
Did module B not have its own declaration of fieldLabel `name`?
And presumably module B has set the option to use DORF.
Then DORF is going to take it that you mean to share the `name`. (And actually
I don't see much harm resulting.)
Them's the rules.
If there's a fieldLabel `name` in Module B, Foo will use that.
If furthermore B imports A unqualified, that's a clash of fieldLabels, so
compile fail.
If module B is compiled with H98 style records, there's a name clash with the
H98 field selector function.
I think this is no worse (and no better) than business-as-usual 'accidental'
usage-without-declaration matching an unknowingly imported binding.
(As part of the 'minimal changes' requirement, I'm trying to avoid syntax
changes to record decls.)
AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Increasing number of worker tasks in RTS (GHC 7.4.1) - how to debug?
What version of GHC is this? I vaguely remember fixing something like this. The rule of thumb is: if you think it is a bug then report it, and we'll investigate further. Simon, it is in GHC 7.4.1. Yes, you fixed a bug #4262 (GHC's runtime never terminates worker threads). I have filed the bug report #5897, with code to reproduce it. This bug seems to be due to mvar callback from C FFI. If I remove mvar callback, the number of workers stay constant. But, it happens only if C FFI thread count exceed a threshold, 6 in my case. Also, I can consistently crash the code with segmentation fault/bus error on Mac if I increase the number of C FFI threads. On Linux too, the crash happens but not as often. This seems to be a big bug in my opinion because mvar callback is important for coordination between GHC threads and C FFI threads. I can work around it for now, by keeping the number of C FFI threads below the threshold that triggers the bug. I suspect this bug has been in GHC all along, but wasn't discovered until now because it happens only if C FFI thread count cross a threshold, and mvar callback is involved. Cheers, Simon On Sat, Feb 25, 2012 at 3:41 PM, Sanket Agrawal sanket.agra...@gmail.com mailto:sanket.agrawal@gmail.**comsanket.agra...@gmail.com wrote: On further investigation, it seems to be very specific to Mac OS Lion (I am running 10.7.3) - all tests were with -N3 option: - I can reliably crash the code with seg fault or bus error if I create more than 8 threads in C FFI (each thread creates its own mutex, for 1-1 coordination with Haskell timer thread). My iMac has 4 processors. In gdb, I can see that the crash happened in __psynch_cvsignal () which seems to be related to pthread mutex. - If I increase the number of C FFI threads (and hence, pthread mutexes) to =7, the number of tasks starts increasing. 8 is the max number of FFI threads in my testing where the code runs without crashing. But, it seems that there is some kind of pthread mutex related leak. What the timer thread does is to fork 8 parallel haskell threads to acquire mutexes from each of the C FFI thread. Though the function returns after acquiring, collecting data, and releasing mutex, some of the threads seem to be marked as active by GC, because of mutex memory leak. Exactly how, I don't know. - If I keep the number of C FFI threads to =6, there is no memory leak. The number of tasks stays steady. So, it seems to be pthread library issue (and not a GHC issue). Something to keep in mind when developing code on Mac that involves mutex coordination with C FFI. On Sat, Feb 25, 2012 at 2:59 PM, Sanket Agrawal sanket.agra...@gmail.com mailto:sanket.agrawal@gmail.**comsanket.agra...@gmail.com wrote: I wrote a program that uses a timed thread to collect data from a C producer (using FFI). The number of threads in C producer are fixed (and created at init). One haskell timer thread uses threadDelay to run itself on timed interval. When I look at RTS output after killing the program after couple of timer iterations, I see number of worker tasks increasing with time. For example, below is an output after 20 iterations of timer event: MUT time (elapsed) GC time (elapsed) Task 0 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 1 (worker) :0.00s( 0.00s) 0.00s( 0.00s) ...output until task 37 snipped as it is same as task 1... Task 38 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 39 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 40 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 41 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 42 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 43 (worker) :0.18s( 10.20s) 0.00s( 0.00s) Task 44 (worker) :0.52s( 10.74s) 0.00s( 0.00s) Task 45 (worker) :0.52s( 10.75s) 0.00s( 0.00s) Task 46 (worker) :0.52s( 10.75s) 0.00s( 0.00s) Task 47 (bound) :0.00s( 0.00s) 0.00s( 0.00s) After two iterations of timer event: MUT time (elapsed) GC time (elapsed) Task 0 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 1 (worker) :0.00s( 0.00s) 0.00s( 0.00s) Task 2 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 3 (worker) :0.07s( 0.09s) 0.00s( 0.00s) Task 4 (worker) :0.16s( 1.21s) 0.00s( 0.00s) Task 5 (worker) :
Re: Unpack primitive types by default in data
On Tue, Feb 28, 2012 at 1:11 AM, Simon Marlow marlo...@gmail.com wrote: I think there are some in GHC - I've been surprised occasionally when adding an UNPACK makes things worse. I just realized that there is a failure mode I didn't quite consider: having a mix of strict and non-strict primitive fields. While this can happen on purpose, I think it happens more often due to non-strict being the default. Having a field with such a mix might lead to more re-boxing. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Understanding the -A and the -H flags
On Tue, Feb 28, 2012 at 12:57 AM, Simon Marlow marlo...@gmail.com wrote: Ah, so I see where your confusion arises - this assumption is not true in general. Just discard the assumption, and I think everything will make more sense. Picking a size for -A around the L2 cache is often a good idea, but not always. GHC defaults to -A512K, but programs that benefit from much larger sizes are quite common. For more about the tradeoff, see my SO answer here: http://stackoverflow.com/questions/3171922/ghcs-rts-options-for-garbage-collection/3172704#3172704 Thanks for the explanation. One has to be very careful in selecting the size of the allocation area in benchmarks. If the allocation area is large enough the GC might not need to run at all for the duration of the benchmark, while in a real program it would run. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
Oliver Batchelor saulzar at gmail.com writes: I think the DORF approach is quite principled in it's namespacing. The labels are just normal functions which can be exported and imported between modules. I believe that is it's main strength - so I think to say it only solves the narrow name-spacing issue within a module. is not quite accurate. Thank you Oliver, yes you got it. And very restrained of you to say not quite accurate. In the following I shall try to do the 'egoless programmer' thing. Seeing as DORF's control over namespacing is a considerable improvement over SORF (in my view), I'm particularly miffed to see an allegation that it can't do EXACTLY WHAT IT'S DESIGNED TO DO. And since that allegation has been repeated in several places, just so there's no probable possible shadow of doubt, no possible doubt whatever, I've updated the wiki with an illustration: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields #ImportExportandRepresentationhiding and attached a working example to the implementor's page. The example shows that within a single record decl: 0. You can import fieldLabel decls. 1. You can create fields that share Labels with imports. 2. You can create fields that don't share, even with the same Label name. (That is, the module system continues to control the namespace.) 3. You can prevent using the wrong field selector with the wrong record type, even if they have the same Label name. Points 2 and 3 are there especially for all the people who want multiple `name`s that label String fields but don't mean the same thing. The example shows that if you use the wrong `name` selector with the wrong record type, you get an instance failure (even if the record type has a field `name`). Just before they slip on the straightjacket for all this mumbling about what's in a name, one further point: - if there's a difference of meaning going on, - you can use the type system to manage your meanings, - with a newtype to screen the representation. That's what Chris Done's example is doing, and it's a good discipline to manage complex data structures. (Thank you Greg for posting it back on to the Records wiki front page). http://hackage.haskell.org/trac/ghc/wiki/Records#Problemswithusingthecurrentmod ulenamespacemechanism Chris's post is what started me down the track of designing DORF, as an improvement over SORF, and to avoid the suggestions of sub-modules. AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
