- Glasgow-haskell-users

ghc-5.02.2 cannot parse string gaps
by Michael Marte 18 Feb '02

18 Feb '02

Hello *, Section 2.6. of the Haskell report says: A string may include a "gap"---two backslants enclosing white characters---which is ignored. This allows one to write long strings on more than one line by writing a backslant at the end of one line and at the start of the next. For example, "Here is a backslant \\ as well as \137, \ \a numeric escape character, and \^X, a control character." ghc-5.02.2 cannot parse string gaps. It accepts \ at the end of a line but not at the beginning of the following line. Michael

1 0

RE: Minor suggestion
by Simon Marlow 18 Feb '02

18 Feb '02

> The need to recompile everything after upgrading was recently > mentioned, I think, on this list. After upgrading from .1 to .2 > (trying to get profiling on track), ghci gave me a slightly cryptic > message about an unknow symbol ("stg_gc_enter_1"). No big deal, and > after I removed the .o's, everything seems fine. > > But perhaps ghc could tag files with its version, so that ghci (and > possibly ghc when used for linking?) could be a bit more explicit? Yes, I'm planning to do this at some point. Cheers, Simon

1 0

RE: The size of things
by Simon Marlow 18 Feb '02

18 Feb '02

> I'm building some stuff here that is basically a glorified and > specialized version of quicksort. It is very quick, and works like a > charm for my purposes, except that it consumes way too much space, > about 100 bytes times the size of the input list. Which means that, > for my data sets, the program exceeds available RAM and uses swap, > which in turn kills performance. > > Is there any guideline how much space the various constructs use? > E.g. how much for cons cells (or whatever that make up lists), how > much for a data type with only nullary data constructors -- should I > use Word8s instead? -- how much for tuples, and so on. I realize I > can (and I do somewhat) use profiling to determine heap use, but it'd > be nice to be able to do back-of-envelope calculations and have some > idea of what's the right approach. Ok, roughly speaking, in GHC every object requires one word plus one word for each field (a word is 4 bytes on a 32-bit machine). In other words, a cons cell will require 3 words. An Int requires two words. A Char usually requires no words (chars up to 256 are cached in the RTS). Nullary constructors require no dynamic storage. The smallest dynamic object is 2 words: ie. a Word8 requires 2 words, even though the useful data it contains is only a single byte. Of course, all of this just applies to fully-evaluated structures - any suspensions (thunks) will screw up the calculations, and certainly the amount of temporary allocation required to *generate* a particular structure is very rarely predictable. You can save storage by using strict constructor fields and using the -funbox-strict-fields flag. eg. data FloatList = FloatNil | FloatCons !Float FloatList requires 3 words for each float in the list, because its actual representation is data FloatList = FloatNil | FloatCons Float# FloatList (Float# is an unboxed float). We heartily recommend strict constructor fields: apart from saving space and time, they help avoid space leaks. Using -funbox-strict-fields is a good way to get the benefits of unboxed types without digging around in GHC's low-level primitive types & operations. Does that help? Cheers, Simon

2 2

Re: Instances of IArray
by Albert Lai 18 Feb '02

18 Feb '02

I had looked into the source code of IArray a bit. Like you have found, (!) is not a class method. In fact, none of the claimed class methods in the doc is a class method, and no class method of IArray is documented. Instead, IArray class methods seem to pertain to implementation details (I mean, "unsafeAt"!), and user operations such as (!) are constrained polymorphic functions, e.g., (!) :: (IArray a e, Ix ix) => a ix e -> ix -> e >From the user's point of view, there is little difference between a class method and a class-constrained polymorphic function when the provided instances are abstract types. So the documentation is telling a white lie. Of course, you see the difference when you roll your own IArray instance. I think the white lie is a balance between exposition simplicity and implementation tuning.

2 1

RE: The size of things
by Simon Marlow 18 Feb '02

18 Feb '02

> ketil(a)ii.uib.no (Ketil Z. Malde) writes: > > > Thanks for all your help, though! > > One interesting(?) observation, > > using a custom data type of > > data STuple = STuple !Int Foo > > is slightly less efficient than using a normal tuple > > (Int,Foo) Just checking... with -funbox-strict-fields, right? > Seems to go against theory, in which STuple should use three words > plus the Foo, while (,) should use three words plus the Foo, plus two > for the Int. Perhaps the Ints are constructed anyway, since they are > inserted from a function parameter? Sounds reasonable, I suppose; > memory use seemed to be the same (from "top"), and there was only a > speed difference. It's possible that the boxed Int is being reconstructed for some reason. You'll be able to see the difference more accurately using heap profiling. > And one more thing, would parametrised types make a difference? > E.g. my array is > > data MyArray label elts = MA label (Array Int elts) > > which means I have > > data Foo l a = Foo (MyArray l a) !Int > > and so on. As far as I can see, this shouldn't matter (a heap object > is a heap object), but am I seeing far enough, I wonder? A polymorphic strict field can't be unboxed - eg. data StrictList a = Scons !a | Snil will never result in the elements being unboxed, even in (StrictList Int). Apart from that, parameterised data types make no difference to the storage representation. Cheers, Simon

2 1

Strictness information?
by Till Dörges 17 Feb '02

17 Feb '02

Hi folks, during the struggle for speed of my program, I've tried to check the strictness of my functions, where most of the time is consumed. Unluckily the ghc documentation doesn't mention the strictness-types I found for the most part. :-( For the particular function in question it reads in the *.hi file: --- snip --- isSubPosnOf :: Posn -> Posn -> PrelBase.Bool {-## __A 2 __C __S VV __U (__inline_me (\ a2 :: Posn b :: Posn -> PrelBase.zaza (zddmzsze1 a2 b) (isPrefixOf b a2))) ##-}; --- snap --- If I understand it correctly I must look at '__S VV', but what does V mean? (The doc only talks about L,S,E,P,U,A). Thanks -- Till

1 0

RE: The size of things
by Jan-Willem Maessen 15 Feb '02

15 Feb '02

> Yes, I see. Would it be possible to have a standard strict list, > i.e. something equivalent of > > data SList a = SNil | SCons !a SList > > (which could be a member of the same class as the normal lists, and > have the usual functions (length, ++, isPrefixOf...) overloaded)? Unfortuantely, as I understand it the -funbox-strict-fields optimization doesn't apply to polymorphic fields. That is, you get the optimization for: > data SIntList = SINil | SICons !Int SIntList but not for > type SListOfInt = SList Int This is because "SList a" must have a uniform representation for every possible a, and the Ints must therefore be boxed. You could verify my instincts by trying this with your example and looking at the space usage... If "strict cons" is what's desired, than it shouldn't be hard to add it as a function and keep lists the way they are. It sounds like what's really wanted is an "unboxed list" class structure similar to the hierarchy of unboxed arrays. That's quite a bit more complicated. -Jan-Willem Maessen

1 0

RE: The size of things
by Simon Marlow 15 Feb '02

15 Feb '02

> Yes, I see. Would it be possible to have a standard strict list, > i.e. something equivalent of > > data SList a = SNil | SCons !a SList > > (which could be a member of the same class as the normal lists, and > have the usual functions (length, ++, isPrefixOf...) overloaded)? Yes, it would be possible, but we can't do it without making sweeping changes to standard libraries and deviating from Haskell 98 quite a bit. It's something to bear in mind should the topic of Haskell 2 come up, though. Cheers, Simon

3 3

RE: The size of things
by Simon Marlow 15 Feb '02

15 Feb '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > You can save storage by using strict constructor fields and using > > the -funbox-strict-fields flag. eg. > > This would be switched on automatically with -O, no? Actually no... but perhaps it's time to turn it on. The reason it's not on by default is that there are cases where it can make performance *worse* - storing the value unboxed occasionally requires us to reconstruct the boxed version eg. for passing to a polymorphic function or storing in an ordinary list. > > data FloatList = FloatNil | FloatCons !Float FloatList > > ..while without strictness, the compiler wouldn't be able to unbox it, > and then we'd have three words per cons, *plus* two words per Float, > right? Yes, spot on. > > requires 3 words for each float in the list, because its actual > > representation is > > > data FloatList = FloatNil | FloatCons Float# FloatList > > I'm going to sketch my data structure, and try to reason a bit about > it. Let's see > > I have an (Array Int Foo), where Foo is a set of nullary constructors > (in other words, cheap?). I have a list of Bar = Bar (Array Int Foo) > Int (where the array is the same for all elements), and construct a > list of tuples (Int, Bar). > > So the array shouldn't be too costly, I think - but perhaps an UArray > would reduce cost from three words to one word per element? It already costs one word per element (think of nullary constructors as free - we only have one copy of each nullary constructor which everybody points to). If the array is the same for each element, why store it in the list at all? > The list of Bars should require three words per cons cell, and three > words for each Bar, and then two words for the Ints (which could be > saved by an exclamation mark). Yes. > The list of tuples should again cost three words per cons, three per > tuple, plus two words per Int (with the Bars already existing and only > moved around). > > Summing up, the array is 3n, the first list is (3+3+2)n = 7n, and the > second list is (3+3+2)n = 7n, for a grand total of 17n, or multiplied > with four to get the bytes, 68n bytes. > > This isn't too far from what I observe, so I hope my analysis is > somewhat correct. :-) Yes, sounds right. > --- > > Now for improvement upon it: I'll try to use an UArray, and see if > that reduces the array size somewhat. I don't think it'll make a difference. > For the list of Bar's, I can strictify the Ints to save 2 words. But > if I defined > > data BarList = Bar (Array Int Foo) !Int (BarList) |BarNil, > > I should be able to get away with 4 words per Bar, shouldn't I > (disregarding the actual array, which is shared anyway)? > > And for the tuple-list, I could do > > data TupleList = Tuple !Int Bar TupleList | TupleNil > > and get 4n, which is equally good. > > --- > > This is assuming the compiler doesn't do any of this on its own... The compiler won't do any of this on its own. Remember that you can't pass a BarList to standard list functions like length, for example, because the types (and representations) are different. The compiler won't make data constructor fieds strict - except in simple cases it would need a sophisticated whole-program analysis to ensure that adding the annotation wouldn't change the behaviour of the program, and AFAIK no-one has attempted this. Cheers, Simon

2 2

RE: strange behavior with ghci version 5.02.2
by Martin Norbäck 15 Feb '02

15 Feb '02

fre 2002-02-15 klockan 10.48 skrev Simon Marlow: > > > After loading a module with > > > > > > :l Module > > > > > > you can't use the Prelude functions unqualified, you just get things > > > like > > > > > > <interactive>:1: Variable not in scope: `show' > > > > > > I am pretty sure that this worked some days ago, and I was using the > > > same version then. > > > > > > I feel totally confused. Has this happened to anyone else? > > > > Yes, for some modules it happens for others it doesn't. Kind > > of strange. > > SuSE 7.3 rpms here, v. 5.02.2 > > J.A. > > You're probably loading compiled versions of these modules. GHC 5.02.2 will only give you the exports of a compiled module when it is selected with :module. Yes, I was loading a compiled module, and indeed, removing the Module.o file, enables me to use Prelude functions after loading it with :l Module. A clean semantics for this in ghci would be to view the interpreter as a "module" and all modules with :module and :load are treated just as if imported into this module. So you could write :load qualified Module :load Module hiding (name) and so on. In any case, there should be no difference in semantics between loading an interpreted module and a compiled one. If there are big problems in keeping the semantics the same, then I suggest always interpreting the module :loaded, even if a compiled version exists. Regards, Martin -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. SIGBORE: Signature boring error, core dumped

1 0