- Glasgow-haskell-users

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

RE: strange behavior with ghci version 5.02.2
by Simon Marlow 15 Feb '02

15 Feb '02

> > 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. This is one of the issues we've addressed recently, and the snapshot 5.03 release does a much better job. There was some discussion about how exactly we should handle scope at the prompt in GHCi; take a look at the archives: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-January/002779.… Cheers, Simon

1 0

scope in ghci. Reply
by S.D.Mechveliani 15 Feb '02

15 Feb '02

Martin Norb <martin.norback(a)safelogic.se> writes > I just noticed this behavior with ghci > > 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? Even if Prelude is visible, still the library items are not. (List.sort, Ratio ...). Maybe, this is natural, I do not know. But I believe, it is possible to control the scope. For example, create a module Universe.hs which re-exports Prelude, libraries and user programs. Then, :l Universe should bring to scope all these items. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Re: strange behavior with ghci version 5.02.2
by Jorge Adriano 14 Feb '02

14 Feb '02

> 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.

1 0

strange behavior with ghci version 5.02.2
by Martin Norbäck 14 Feb '02

14 Feb '02

I just noticed this behavior with ghci 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? Regards, Martin -- Martin Norbäck Safelogic AB martin.norback(a)safelogic.se Stena Center 1C +46 (0)31 772 81 70 S-412 92 GÖTEBORG http://www.safelogic.se SWEDEN

1 0

RE: problem with source 5.03
by Julian Seward (Intl Vendor) 14 Feb '02

14 Feb '02

| There seems to be a problem with the source tar.bz2 | distribution of the | 5.03 snapshot. The web page claims it's 5.3M, but the actualy file is | only 4117517 bytes and doesn't untar properly: | | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed Files, 0 | bytes, 0 tape blocks | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed | Files/Language Independent, 0 bytes, 0 tape blocks | tar: directory checksum error | | I was able to grab a CVS image, but someone should probably fix this. The web page is wrong. The file is OK. haskell:~/website/dist/5.03.20020204$ ls -l ghc-5.03.20020204-src.tar.bz2 -rw-rw-r-- 1 sewardj sewardj 4117517 Feb 5 09:17 ghc-5.03.20020204-src.tar.bz2 haskell:~/website/dist/5.03.20020204$ bzip2 -tv ghc-5.03.20020204-src.tar.bz2 ghc-5.03.20020204-src.tar.bz2: ok and I guess you are untarring it on solaris, using the solaris tar? If so try GNU tar? J

2 1

RE: CVS Build problem
by Simon Marlow 14 Feb '02

14 Feb '02

If you're building the CVS version of GHC, it usually helps to keep an eye on cvs-ghc(a)haskell.org where these kind of things are generally announced (in this case, I mentioned it in the commit message). The building guide tends to lag a little, but it will get updated. Cheers, Simon > -----Original Message----- > From: Hal Daume III [mailto:hdaume@ISI.EDU] > Sent: 13 February 2002 22:41 > To: Nicholas Nethercote > Cc: GHC users list > Subject: RE: CVS Build problem > > > Ah, thanks. I was having the same problem but was too shy to > ask about > it, figuring it must be my bad. This should probably be > mentioend in the > build documentation (hint, hint). > > - Hal > > -- > Hal Daume III > > "Computer science is no more about computers | hdaume(a)isi.edu > than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume > > On Wed, 13 Feb 2002, Nicholas Nethercote wrote: > > > On Wed, 13 Feb 2002, Nicholas Nethercote wrote: > > > > > That's what I did. It made ghc ok, but then when it > tries the 'make > > > boot' in hslibs it falls over. The same happens if I change into > > > $(BUILD)/hslibs and do 'make boot'... > > > > Ok, I've worked out the problem: I just checked out the > modules "ghc" and > > "hslibs". It seems that the standard library has just been > moved into a > > new separate module "libraries". So my build was missing > the standard > > library which was causing the problem. > > > > -- > > Nick Nethercote > > njn25(a)cam.ac.uk > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0