Re: Linking completely statically

On Mon, 10 Aug 2020 at 03:12, Bardur Arantsson wrote: > Once you have that bit set up, you can copy *most* of the libraries > .so's you're using to that folder on the install target and they'll be > loaded from there. (Copying libc.so is ill advised, but most of the > others will work just fine.

Re: [Haskell-cafe] Decorating exceptions with backtrace information

On Tue, 12 May 2020 at 17:30, Henning Thielemann < lemm...@henning-thielemann.de> wrote: > From your list of examples I deduce that the proposal is about programming > errors. But we have HasCallStack for that one. How does the proposal > improve or alter the HasCallStack solution? And how does it

Re: uninstalling libraries

I used to fight with a combination of system and cabal installed packages under debian testing. Then, about a year ago, the frustration became too much and I switched to using nix, intero in emacs, and stack with the nix resolver, all installed with nix on my debian machine. Couldn't be happier.

Re: suboptimal ghc code generation in IO vs equivalent pure code case

On 14/05/16 02:31 PM, Harendra Kumar wrote: The difference seems to be entirely due to memory pressure. At list size 1000 both pure version and IO version perform equally. But as the size of the list increases the pure version scales linearly while the IO version degrades exponentially. Here a

Re: Class instance specificity order (was Re: Fundeps and type equality)

On January 11, 2013 13:55:58 Simon Peyton-Jones wrote: > | The -XOverlappingInstances flag instructs GHC to allow more than one > | instance to match, provided there is a most specific one. For example, > | the constraint C Int [Int] matches instances (A), (C) and (D), but the > | last is more

RE: Class instance specificity order (was Re: Fundeps and type equality)

On Thu, 2013-01-10 at 22:17 +, Simon Peyton-Jones wrote: > Is > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap > > insufficiently clear? If so, let's clarify it. Thanks for getting back to me Simon. The document says "For example, cons

Class instance specificity order (was Re: Fundeps and type equality)

On January 10, 2013 13:56:02 Richard Eisenberg wrote: > Class instances that overlap are chosen among by order of specificity; Sorry to jump in the middle here, but this caught my attention as this sort of specificity determination is exactly what I had in mind when I was working on my "The shap

Re: Dynamic libraries by default and GHC 7.8

On November 27, 2012 22:02:33 Jens Petersen wrote: > > GHC HEAD now has support for using dynamic libraries by default (and in > > particular, using dynamic libraries and the system linker in GHCi) for a > > number of platforms. > > I am very happy to hear this news. > > I have long been a quiet

Re: Dynamic libraries by default and GHC 7.8

On November 28, 2012 04:45:57 Joachim Breitner wrote: > Am Dienstag, den 27.11.2012, 21:57 -0500 schrieb Tyson Whitehead: > > I was so excited for a bit thinking that this would finally mean that > > Debian would move to a dynamic system. Every haskell binary being 10s > >

Re: Dynamic libraries by default and GHC 7.8

On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote: > Am Dienstag, den 27.11.2012, 14:52 + schrieb Ian Lynagh: > > The various issues are described in a wiki page here: > > http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault > > > > If you have a few minutes to read it then we

Re: How to describe this bug?

On July 11, 2012 04:51:50 Christian Maeder wrote: > Is it not enough to store floats into memory just before equality tests > (or add rounding in the instance definitions of Float and Double in Eq > and Ord)? You have to be 100% consistent in how you do every operations in all cases otherwise dif

Re: How to describe this bug?

On July 10, 2012 10:39:41 Colin Adams wrote: > Sure they would be better modelled that way, but the whole point of using > floating point arithmetic is to sacrifice accuracy for performance, is it > not? True. I just find it interesting that some types have a builtin Nothing value. Some further

Re: How to describe this bug?

On July 10, 2012 09:28:27 Christian Maeder wrote: > Am 10.07.2012 13:06, schrieb Sönke Hahn: > > I've attached the code. The code does not make direct use of > > unsafePerformIO. It uses QuickCheck, but I don't think, this is a > > QuickCheck bug. The used Eq-instance is the one for Float. > > The

Modified layout for lambda-case

It seems my suggestion isn't getting too much traction. It occurs to me this may be because I jumped right into layout rules and didn't first give some simple motivating examples to get the idea across. SHORT VERSION: Assume '\' is a grouping construct. I proposed always interpreting ... \

Re: Call to arms: lambda-case is stuck and needs your help

On July 7, 2012 00:08:26 Tyson Whitehead wrote: > The very limited scope of this (i.e., it would only apply to lines that end > with a grouping construct where the next line is indented further than that > line) should also address Simon's concerns regarding things like > &

Re: Call to arms: lambda-case is stuck and needs your help

On July 6, 2012 11:49:23 Tyson Whitehead wrote: > Currently it depends on the depth of this new level of indentation relative > to all the groupings started on that line. I think most people would > expect it to just apply to the last grouping though. That is > > where { f x =

Re: Call to arms: lambda-case is stuck and needs your help

On July 6, 2012 05:25:15 Simon Marlow wrote: > > Why not just let enclosed scopes be less indented than their outer ones? Let me be entirely clear about what I was thinking about. The third case for the layout mapping in Section 9.3 of the report is L ({n}:ts) (m:ms) = { : (L ts (n:

Re: Call to arms: lambda-case is stuck and needs your help

On July 5, 2012 10:42:53 Mikhail Vorozhtsov wrote: > After 21 months of occasional arguing the lambda-case proposal(s) is in > danger of being buried under its own trac ticket comments. We need fresh > blood to finally reach an agreement on the syntax. Read the wiki > page[1], take a look at the ti

Re: parallel garbage collection performance

On June 18, 2012 04:20:51 John Lato wrote: > Given this, can anyone suggest any likely causes of this issue, or > anything I might want to look for? Also, should I be concerned about > the much larger gc_alloc_block_sync level for the slow run? Does that > indicate the allocator waiting to alloc

Re: default instance for IsString

On April 25, 2012 12:20:16 Johan Tibell wrote: > On Wed, Apr 25, 2012 at 8:19 AM, Tyson Whitehead wrote: > > Is there a technical reason this couldn't be done? The Haskell report > > only says doing this is not part of haskell. It doesn't say why. > > I think t

Re: default instance for IsString

On April 25, 2012 04:15:41 Yitzchak Gale wrote: > The only reason I don't like using OverloadedStrings > for typing string literals as Text and ByteString > is that when you turn on OverloadedStrings, you turn > it on for all types, not just Text and ByteString. > I don't want to be forced to do th

Re: [saj...@gmail.com: Google Summer of Code: a NUMA wishlist!]

On March 28, 2012 12:40:02 Sajith T S wrote: > Tyson Whitehead wrote: > > Intel is more recent to this game. I believe AMD's last non-NUMA > > machines where the Athalon XP series and Intel's the Core 2 series. > > > > An easy way to see what you'

Re: [saj...@gmail.com: Google Summer of Code: a NUMA wishlist!]

On March 28, 2012 04:41:16 Simon Marlow wrote: > Sure. Do you have a NUMA machine to test on? My understanding is non-NUMA machines went away when the AMD and Intel moved away from frontside buses (FSB) and integrated the memory controllers on die. Intel is more recent to this game. I believe

Re: How unsafe are unsafeThawArray# and unsafeFreezeArray#

On March 9, 2012 06:44:33 John Meacham wrote: > A weakness of jhc right now is its stop the world garbage collector, > so far, I have been mitigating it by not creating garbage whenever > possible, I do an escape analysis and allocate values on the stack > when possible, and recognize linear uses o

Re: Posting etiquette, was Re: Records in Haskell

On January 19, 2012 05:14:30 Malcolm Wallace wrote: > I find it completely unreasonable for a reply to a very long post to quote > the entire text, only to add a single line at the bottom (or worse, > embedded in the middle somewhere). +1 ___ Glasgow-ha

Re: Unit unboxed tuples

On January 11, 2012 08:41:04 Simon Marlow wrote: > On 10/01/2012 16:18, Dan Doel wrote: > > Does the difference have to do with unboxed types? For instance: > > foo :: () -> Int# > > foo _ = foo () > > bar :: () -> (# Int# #) > > bar _ = (# foo () #) > > > > baz = case ba

Re: Unit unboxed tuples

On January 10, 2012 12:18:13 wren ng thornton wrote: > On 1/10/12 11:18 AM, Dan Doel wrote: > > On Tue, Jan 10, 2012 at 11:14 AM, Dan Doel wrote: > >> On Tue, Jan 10, 2012 at 5:01 AM, Simon Marlow wrote: > >>> On 09/01/2012 04:46, wren ng thornton wrote: > Shouldn't (# T #) be identical to T

Re: Unit unboxed tuples

On January 8, 2012 23:49:47 wren ng thornton wrote: > An alternative is to distinguish, say, (# x #) and its spaceful > constructor (# #) from the spaceless (##); and analogously for the boxed > tuples, though that introduces confusion about parentheses for boxing vs > parentheses for grouping. I

Re: Unit unboxed tuples

On December 23, 2011 09:37:04 Ganesh Sittampalam wrote: > On 23/12/2011 13:46, Ian Lynagh wrote: > > On Fri, Dec 23, 2011 at 01:34:49PM +, Simon Peyton-Jones wrote: > >> Arguments Boxed Unboxed > >> 3 ( , , )(# , , #) > >> 2 ( , ) (# , #) > >> 1 > >> 0

Re: performance issues in simple arithmetic code

On April 27, 2011 23:01:50 Denys Rtveliashvili wrote: > Question 1: what is the meaning of those magic numbers > -9223372036854775808, -6677706553, -7418931981405, -8257271295304186? > Question 2: under which circumstances those strange branches of > execution will be used and what those results wo

Re: Tracing idea

On February 19, 2011 12:11:13 Edward Z. Yang wrote: > I was thinking it might be useful if we had a per-thread circular buffer in > memory for which we pushed a pointer to the info table we had just entered. > In the event of a crash, you could dump the contents of the buffer to see > what code ha

Re: Faster Array#/MutableArray# copies

On February 17, 2011 20:18:11 Johan Tibell wrote: > * Can we use SSE instructions? > > * Can we get the C memcpy code inlined into the C-- source (crazy, I > know). If so we could perhaps benefit directly from optimizations in > libc. From the standpoint of numerical code, it would be very nice

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

On November 18, 2010 05:12:11 Simon Marlow wrote: > On 17/11/2010 14:34, Christian Maeder wrote: > > ghc can be built without and with libffi. > > Which build option are you referring to here? libffi is required for > FFI support in GHCi, and for FFI "wrapper" imports. However on x86 and > x86_6

Re: libffi was:Re: ANNOUNCE: GHC version 7.0.1

On November 17, 2010 09:34:02 Christian Maeder wrote: > ghc can be built without and with libffi. What advantage do I gain in > the latter case? The packages that come with ghc (displayed by "ghc-pkg > dump") don't use it. I can't find this right now, but, from when I last looked through the code,

Re: Parallel Haskell: 2-year project to push real world use

On May 3, 2010 08:04:14 Johan Tibell wrote: > On Mon, May 3, 2010 at 11:12 AM, Simon Peyton-Jones > wrote: > > In truth, nested data parallelism has taken longer than we'd hoped to be > > ready for abuse :-). We have not lost enthusiasm though -- Manual, > > Roman, Gabi, Ben, and I talk on the ph

Re: Parallel Haskell: 2-year project to push real world use

On April 30, 2010 06:32:55 Duncan Coutts wrote: > In the last few years GHC has gained impressive support for parallel > programming on commodity multi-core systems. In addition to traditional > threads and shared variables, it supports pure parallelism, software > transactional memory (STM), and d

Literate files in the GHC source

I'm just wondering how exactly are the literate files in the GHC source suppose to be treated. I would like to read some of the documentation. The presence of various latex commands such as subsection strongly suggests they are done in latex. Running pdflatex, however, doesn't work. Nor does

Re: "static_wrapper" imports in the FFI

On March 16, 2010 20:01:32 Iavor Diatchki wrote: > Optionally disabling executable heap blocks would be a separate patch. > As far as I know, the only reason that the heap is executable is to > support the adjustor thunks used to implement "wrapper" imports. The > "static_wrapper" patch provides

Re: Feedback request: priority queues in containers

On March 16, 2010 13:24:32 k...@cas.mcmaster.ca wrote: > Just an aside (and shameless plug ;-): Since the signatures overlap so > much, it is in fact easy to wrap these modules into instances > for many possible different type classes Yes. I can see the preferred way would be to put the classes o

Re: Feedback request: priority queues in containers

On March 16, 2010 09:29:06 Louis Wasserman wrote: > I'd like to request some more feedback on the > proposedimplementation > for priority queues in containers. Mostly, I feel like > adding a new module to containers should be contentious, and there

Re: "static_wrapper" imports in the FFI

On March 15, 2010 19:54:52 Iavor Diatchki wrote: > In terms of notation, I like the directness of the "static_wrapper" > declaration (although not so much the "static_wrapper" name!) because > it avoids duplication, thus reducing clutter and potential errors. If it does get accepted, I would propo

Re: "static_wrapper" imports in the FFI

On March 15, 2010 12:48:02 Iavor Diatchki wrote: > I have implemented a small extension to the FFI which allows for > "static_wrapper" imports. These are a variation on "wrapper" imports > that do not use run-time code generation. This is important in > security sensitive contexts because it avoi

(read getLine) + (read getLine)

Consider what would happen if GHC optionally inserted a morphism on fexps (the expression at the head of an application) as it currently does with integer literals and optionally with string literals. A standard function call f x y would windup as morph (morph f x) y With the following

Re: Issue with type families

On March 3, 2010 21:10:56 Daniel Fischer wrote: > Well, GHC takes only the class head into account for instance selection, > and > > u -> (v -> w) > > matches both, > > a -> b -- (a == u, b == v -> w) > > and > > m (c -> d)-- (m == ((->) u), c == v, d == w), > > ... ... > > are indeed confl

Re: Issue with type families

On March 3, 2010 18:35:26 Daniel Fischer wrote: > Because: > > instance Applicative ((->) a) -- Defined in Control.Applicative > > so, from the instance Z (a -> b), with b == c -> d, we have an > > instance Z (a -> (b -> c)) > > and from instance Z (m (u -> v)), we have, with m == ((->) x), an > >

Issue with type families

The following code {-# LANGUAGE FlexibleInstances, TypeFamilies #-} import Control.Applicative class Z t where type W t z :: t -> W t instance Z (a -> b) where type W (a -> b) = a -> b z = id instance Z (IO (a -> b)) where type W (IO (a -> b)) = IO a ->

Re: C that setjmps -> haskell -> C that might longjmp

On March 2, 2010 06:17:46 Simon Marlow wrote: > For now I suggest you use setjmp. If you want to suggest an API to tell > the RTS about a longjmp, then perhaps we could implement something, but > I'm not sure what the API would look like, because you don't have a > handle to the in-progress calls.

C that setjmps -> haskell -> C that might longjmp

If I have the following call sequence C code -> Haskell code -> various C code bits where the various C code bits on the right might do a longjmp (their version of an exception) and jumping back to the C code on the left. Is it possible to have C code on the left then somehow tell GHC to cleanu

Re: Some great results on fused code with the LLVM backend

On February 21, 2010 20:57:25 Don Stewart wrote: > I tried out some of the vector and uvector fusion benchmarks with the > new LLVM backend > > http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghc >s-new-llvm-codegen/ > > and got some great results for the tight loops generat

Re: Shared GHC libraries and the runtime system

On February 22, 2010 17:00:25 Max Bolingbroke wrote: > Hi Tyson, > > This blog post > (/) might help explain the motivation (actually there are a few relevant > posts on the well-typed site). > > Essentially, I believe that this is done so that you can vary the RTS > by changing LD_LIBRARY_PATH. I

Shared GHC libraries and the runtime system

I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared li

GHC FFI stub files

I'm writing a perl module that interfaces some haskell code and its a bit of a pain because both perl and ghc have their own custom build system. Is there a way to get ghc to give you the gcc/as/ld options (library paths, include paths, flags, etc) required for the FFI stub files it generates?

Re: Quasi quoting

On February 2, 2010 19:48:27 Max Bolingbroke wrote: > It's a shame that TH is too widely used to be amenable to refactoring > into this sort of form. I thought the standard thing to do in this case was to add either a pragma that gives you the new behaviour or trigger it with an alternative synta

Re: Question regarding combinator call convention

On February 1, 2010 06:43:40 Simon Marlow wrote: > That's a very old document and is inaccurate in various ways. The > Commentary is more up to date: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts That's good to know. Thanks for the link. : ) Cheers! -Tyson signature.asc Descri

Question regarding combinator call convention

I was looking through the code for 6.12.1 and am a bit confused about 11.1.3 in the runtime system documentation docs/rts/rts.tex. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.641&rep=rep1&type=pdf It says the arguments passing convention to a known combinator differs from that o

Re: GHC core plugins

On January 27, 2010 05:44:00 José Pedro Magalhães wrote: > Alright, ticket created: http://hackage.haskell.org/trac/ghc/ticket/3843 > > In any case, for now I am willing to hard-code a new core-to-core pass on > the compiler. Any pointers for where I have to look at? Just wondering a couple of thi

Re: Question regarding the GHC users manual

Hi Max and Niklas, Thank you both for your answers. I get it now. I didn't read carefully enough to note that the explicit type on F a b was the type of F and the type of F (although, in retrospect, this last interpretation wouldn't have worked as we would have need at least * -> * -> *). Tha

Question regarding the GHC users manual

Hi all, Just wondering if there could be a typo in section 7.7.2.1 of the GHC manual (type family declarations) http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html Specifically, it says type family F a b :: * -> * -- F's arity is 2, -- al

Re: Porting to DragonFly BSD

On November 15, 2009 07:42:46 Goetz Isenmann wrote: > 001e5565 <__hscore_get_errno>: > 1e5565: 55 push %ebp > 1e5566: 89 e5 mov%esp,%ebp > 1e5568: 65 a1 00 00 00 00 mov%gs:0x0,%eax > 1e556e: 8b 15 00 00 00 00

Re: Porting to DragonFly BSD

On November 15, 2009 07:42:46 Goetz Isenmann wrote: > I am still not sure, but the generated code might be ok > > 001e5565 <__hscore_get_errno>: > 1e5565: 55 push %ebp > 1e5566: 89 e5 mov%esp,%ebp > 1e5568: 65 a1 00 00 00 00

Re: Porting to DragonFly BSD

On November 9, 2009 12:39:25 Goetz Isenmann wrote: > On Mon, Nov 09, 2009 at 10:44:47AM +, Simon Marlow wrote: > > We should get these patches into GHC. Most of them look > > straightforward, but I'm slightly suspicious of this: > > > > -STANDARD_OPTS += -DCOMPILING_RTS > > +STANDARD_OPTS += -

Lazy computation being repeated?

I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. The program in question goes like so. The results from the expensive calculation are s

Re: Closure elimination transformation (continuation style passing code)

Thanks for all the feedback guys, I already find it pretty amazing how well simple stuff expressed in a higher level manner compiles down to something decent, and it seems like the future is only going to get brighter. I can hardly wait... : ) In the meantime, I'll go back to trying to find t

Re: Closure elimination transformation (continuation style passingcode)

On May 20, 2009 05:50:54 Claus Reinke wrote: > I'm not at all sure what you're aiming for (the above doesn't compile), Yeah. The newtype Step a b was required to break the recursive types, and I dropped it when performing the various transformations, so they don't type check. Here it is again

Re: Closure elimination transformation (continuation style passing code)

On May 19, 2009 22:17:39 Tyson Whitehead wrote: > 2- specialize count for step = iter > > > > 3- specializing iter for next = count > > > I changed this just before sending it and managed to goof step two and three (the specializations). The whole thing, with the cor

Closure elimination transformation (continuation style passing code)

I was wondering about GHC's ability to optimize the following code module Test (test) where newtype Step a b = Step { unStep :: (a -> Step a b -> b) -> b -> b } iter :: [a] -> (a -> Step a b -> b) -> b -> b iter [] next done = done iter (x:xs) next done = next x (Step $ iter xs)

Re: No "last core parallel slowdown" on OS X

On April 21, 2009 04:39:40 Simon Marlow wrote: > > These ratios match up like physical constants, or at least invariants of > > my Haskell implementation. However, the user time is constant on OS X, so > > these ratios reflect the actual parallel speedup on OS X. The user time > > climbs steadily o

Re: No "last core parallel slowdown" on OS X

On April 18, 2009 16:46:44 Daniel Peebles wrote: > That looks great! I wonder what about Mac OS leads to such good > performance... > > Now if only we could get a nice x86_64-producing GHC for Mac OS too, I > could use all my RAM and the extra registers my Mac Pro gives me :) I was a bit surprised

Re: compilation of pattern-matching?

On March 25, 2009 21:38:55 Claus Reinke wrote: > If you don't have that kind of control, and generate code as if > there were no hardware-level optimizations, the resulting > mismatch will manifest in hard-to-predict variations in > performance, making it difficult to see how much or why > speed is

Re: compilation of pattern-matching?

On March 23, 2009 19:46:27 Claus Reinke wrote: > My idea was that case branches correspond to conditional jumps > (though the exact correspondence and optimization has been the > subject of countless papers). If I loop through a very long list, > most of the time the test for (:) will succeed, requ

GHC and Haskell Standard wrt floatRange...

I think there might be a difference between C/GHC and the Haskell Standard's idea of the range of the exponential. Specifically, the comment in gcc's float.h (i.e., where GHC appears to gets its definition from) says /* Minimum int x such that FLT_RADIX**(x-1) is a normalized float, emin */ wh

Re: Loop unrolling + fusion ?

On March 1, 2009 17:31:13 Max Bolingbroke wrote: > I am no assembly guru and haven't seen that last form of leaq either, > but I'm going to guess that: > > leaq(%rsi,%rsi,4), %rax > > Says that rax is rsi * ((1 + 1) * 2 ^ 4) = rsi * 32 > > leaq0(,%rax,8), %rsi If I recall

Re: Compiler optimizations questions for ghc 6.10...

On February 19, 2009 18:20:33 Krasimir Angelov wrote: > Oh. I looked at the primops.txt.pp for something suspicious but I > didn't checked the actual implementation of quot. I thought that quot > calls quotInt# directly. When I use quotInt in the code I can get the > real idiv assembly instruction.

Re: Compiler optimizations questions for ghc 6.10...

On February 18, 2009 12:42:02 Tyson Whitehead wrote: > On February 18, 2009 04:29:42 Max Bolingbroke wrote: > > Yes - GHC wants to share the work of (maxBound-x)`div`10 between > > several partial applications of "digit". This is usually a good idea, > > but in

Re: Compiler optimizations questions for ghc 6.10...

On February 18, 2009 04:29:42 Max Bolingbroke wrote: > > The part of the code under the first lambda in digit is as follows (I > > didn't keep the original dump, so the uniques have changed here). It's > > the second part of the Int overflow bounds check (i.e., y <= > > (maxBound-x)`div`10), and,

Re: Compiler optimizations questions for ghc 6.10...

On February 17, 2009 19:24:44 Max Bolingbroke wrote: > 2009/2/17 Tyson Whitehead : > > (compiled with ghc 6.10 with options -O2 -ddump-simpl) That should have been -ddump-stranal instead of -ddump-simpl. > > I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the

Re: Compiler optimizations questions for ghc 6.10...

On February 17, 2009 19:24:44 Max Bolingbroke wrote: > 2009/2/17 Tyson Whitehead : > > It also seems the extra levels of indirection are defeating the > > strictness analyzer on eta_s1CN in a_s1Gv as all code branches either > > directly force it or ultimately pass it to

Compiler optimizations questions for ghc 6.10...

(compiled with ghc 6.10 with options -O2 -ddump-simpl) I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at the bottom of this email as that is the only place it is ever referenced. It also seems the extra levels of indirection are defeating the strictness analyzer on et

Re: ST monad and monad tranformers

On February 2, 2009 14:50:10 Reid Barton wrote: > On Mon, Feb 02, 2009 at 06:03:15PM +0100, Josef Svenningsson wrote: > > > > I also needed something like this a while ago so I knocked up a really > > simple module and put it on hackage: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/packag

Re: ST monad and monad tranformers

On February 2, 2009 11:26:02 Tyson Whitehead wrote: > The STT type above is a version of ST like the ReaderT, StateT, etc. types. > > newtype STT s m a = STT ( State# s -> m (STTBox s a) ) > data STTBox s a = STTBox {-#UNPACK#-} !(State# s) {-#UNPACK#-} !a > > runSTT :: (Monad

ST monad and monad tranformers

I have a situation in which I believe I need a parameterizable version of the strict ST monad. My computation type is "StateT s' (STT s (ErrorT e m)) a" (i.e., fails or succeeds and has an internal state involving a state thread). The STT type above is a version of ST like the ReaderT, StateT,

Re: UVector overallocating for (Word/Int)(8/16/32)

On Friday 30 January 2009 04:07:19 you wrote: > This is in uvector, right? Then you should probably forward this to the > maintainer, i.e. Don Stewart . Done. Thanks for the follow up. Cheers! -Tyson signature.asc Description: This is a digitally signed message part.

UVector overallocating for (Word/Int)(8/16/32)

I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four, and two times, respectively, as much memory as actually required. That is, newMBU n = ST $ \s1# -> case sizeBU n (undefined::e) of {I# len# -> case newByteArray# len# s1# of {(# s2#, marr# #) -> (# s2

Questions regarding uvector 0.1.0.3

I've been looking at uvector and had some questions (hopefully this is the right mailing list for this, if not, sorry, and please direct me properly). First, is there any design thing deeper than just supporting things like the unit and pair arrays for layering UArr on top of the underlying BUAr

Re: Strictness in data declaration not matched in assembler?

On Thursday 16 October 2008 14:34:01 Don Stewart wrote: > FWIW, I get much nicer code with uvector (which uses type families > to select monomorphic instances of things, and aggressive inlining, to > yield much better code in practice). The DPH arrays library uses > a similar method. Thanks for th

Re: Strictness in data declaration not matched in assembler?

On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote: > On 16/10/2008, at 21:34, Simon Peyton-Jones wrote: > > BUT people who care probably UNPACK their strict fields too, which > > is even better. The time you can't do that is for sum types > >data T = MkT ![Int] > > You also can

Re: Strictness in data declaration not matched in assembler?

On Wednesday 15 October 2008 10:48:26 you wrote: > Strictness does not imply unboxing. > > To see why not, think about the fact that unboxing breaks sharing. By > keeping the pointer-indirection in place, we can share even strict > fields between related values. I believe I realize that. What I w

Strictness in data declaration not matched in assembler?

Consider the following code data Data = Data { unData :: !Int } func :: Data -> Int func x = case unData x of 1 -> 2 _ -> 0 Compiling with GHC 6.8.2 gives the following stg code Main.func = \r [x_slg] case x_slg of tpl_slx { Main.Data ipv_slj ->

Implicit Function Arguments

What do people think about implicit function argument? That is, named function arguments, possibly tagged with something special like a tilde, whereby scoped variables of the same name are automatically passed. The idea is to avoid the pain of a lots of pass through parameters while make it eas

Re: Recursive functions and constant parameter closures (inlining/strictness analyzer question)

On Friday 20 June 2008 21:34:14 Dan Doel wrote: > On Friday 20 June 2008, Max Bolingbroke wrote: > > Of course, if you have any suggestions for good heuristics based on > > your benchmarking experience then we would like to hear them! There > > was some discussion of this in the original ticket, >

Recursive functions and constant parameter closures (inlining/strictness analyzer question)

main = print $ foldl' (+) 0 [1..] with foldl' f y xs = foldl' y xs where foldl' y [] = y foldl' y (x:xs) = foldl' (f y x) xs runs indefinitely with very little memory consumption, while foldl' f y [] = y foldl' f y (x:xs) = foldl' f (f y x) xs rapidly consumes all the machine'