- Haskell-Cafe - Haskell.org

RE: Record of STRefs better than STRef to a Record?
by Simon Marlow 27 Dec '02

27 Dec '02

> If I use an STRef to a record, will a new record be created > each time I want > to update a single field? Or can I expect GHC to optimize it > and have the field of the record updated in place? You'll get a new record for each update. This might not be so bad though, depending on the number of fields in your record. > Right now I'm using a record of STRefs, like: > data E s = E{ > refi :: STRef s Int, > refc :: STRef s Char > } > > but it can get a little messy, since thread s propagates to > every datatype that uses the record type in it's definition. Here's another trick if you use this route: data E s = E{ refi :: !STRef s Int, refc :: !STRef s Char } and compile with -funbox-strict-fields. This will eliminate the boxing of the STRefs. Cheers, Simon

4 4

ABD G��menlik/Green Card 2003 y�l� kay�tlar�m�z ba�lam��t�r...
by G��MENL�K/ABD 26 Dec '02

26 Dec '02

1 0

RE: Parsing date and time specifications
by Simon Marlow 26 Dec '02

26 Dec '02

> I was probably a bit quick on the trigger there. Sorry! > > It't been a while since I tried using CalendarTime and friends; I did > have some difficulty making things fit, and eventually gave up the > whole thing. My impression (which may well be a wrong one) was that > others also had trouble adapting the library to their uses, too, and > that the Time library was one of the less successful ones. That may well be true, and I've heard others suggest that the library is inconvenient. I'm trying to get at whether that is due to current bugs in the implementation, or whether the design is fundamentally broken. > Looking at it now, possible criticisms could arise from the data types > containing redundancy and non-uniqueness: e.g. one can easily > construct non-consistent CalendarTimes, Ok, I don't consider that to be a problem. The toClockTime operation should fail if the CalendarTime is inconsistent. Non-uniqueness isn't a problem: you can convert to a ClockTime which is unique. I think of the CalendarTime as a slightly more tractable representation of a date/time string; lots of date strings don't make sense either (eg. "31 February"). > and there are multiple ways > to represent the same interval as TimeDiff -- in fact, two TimeDiffs > may or may not be equal, depending on what CalendarTime they apply > to. (The 'deriving' of Eq makes this a moot point, perhaps, but > seems to make equality rather non-intuitive) I think this is the wrong way to look at it: two TimeDiffs should be equal if and only if all their components are respectively equal (i.e. the deriving Eq meaning). This is different from saying that "the effect of adding this TimeDiff is the same as adding this other TimeDiff", which depends entirely on what you're adding it to. So this cannot lead to a sensible meaning for Eq on TimeDiff. Ah - I've just realised one problem with the design. If you have a TimeDiff with multiple non-zero components (eg. one hour and one second), then the order in which you add them makes a difference, and this order isn't specified by the spec. That's probably why TimeExts has only single-unit differences. And another thing: it should be specified that diffClockTimes gives a TimeDiff in units of seconds & picoseconds, because these are the only forms of TimeDiff that have the same meaning independent of what ClockTime they are added to. > It seems that TimeDiffs perform two functions; deltas for ClockTimes > (in the functions) and intervals of calendar times (specification of > the data type), and I'm not sure it's a good idea to mix those. I think TimeDiffs are deltas for ClockTimes only. Why do you say they are intervals of calendar times too? If we were to have an operation which adds a TimeDiff to a CalendarTime, then its meaning should be the same as converting the CalendarTime to a ClockTime, adding the TimeDiff, and converting back to a CalendarTime again. > Oh well. I'm not using Time at the moment, so its not an issue that > will ruin my holiday for me :-) me either :) Cheers, Simon

2 1

Re: Interpret haskell within haskell.
by Christopher Milton 26 Dec '02

26 Dec '02

--- David Sankel <camio(a)yahoo.com> wrote: > I was wondering if there is any project that aims to > interpret haskell within haskell. http://www.haskell.org/implementations.html <quote type="partial"> GHC, the Glasgow Haskell Compiler The Glasgow Haskell compiler is a full implementation of Haskell. It is itself written in Haskell and is designed to act as a substrate for the research work of others. The source code is freely available. It produces fast code. </quote> The GHC interpreter is ghci. (It's not as slow anymore.) http://www.haskell.org/ghc/ The other Haskell interpreters also load and interpret users' Haskell source code, as well. If you have defined functions in "myprog.hs": :load myprog.hs then the functions defined in the file are available, or else you'll get error message(s) about problems found parsing "myprog.hs". __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

9 9

Space explosion
by Jyrinx 25 Dec '02

25 Dec '02

I'm tinkering with a little program I wrote a while back to generate probability distributions and averages for rolling various kinds and quanitities of dice and applying various rules (for instance, roll four six-sided dice, drop the lowest, and add the other three). I'm trying to optimize the thing, and I've run into a space leak. I've found that, if I tell it to roll four 20-sided dice and add, it finishes in under a second and heap usage peaks at under 2MB (not sterling, but not catastrophic); but if I make it five 20-sided dice, it runs out of stack space after thrashing for a while (and getting partway through the final output); for six dice, it thrashes into oblivion. (Running WinXP with 256MB memory.) What puzzles me is that, according to GHC's heap-usage-by-call-center graph, the hog isn't the code that generates every single outcome of rolling the dice (and we're talking about four 20-sided dice here ...), whose heap usage is constant (go GHC! :-) ), but the one that turns the list of outcomes (for instance, [2,3,3,4,4,4 ... 7,7,7,7,7,7 ... 11,11,12] for adding two 6-sided dice) into a probability distribution (like [(2,1),(3,2),(4,3) ... (7,6) ... (11,2),(12,1)]). It is this: > -- Specs contains the options for the simulation; rollBounds simply finds the lowest and highest possible rolls > -- type RollValue = Int > -- type RollValueDist = Array RollValue Int > probDist :: Specs -> [RollValue] -> RollValueDist > probDist specs rolls = > accumArray (+) 0 (rollBounds specs) [(r, 1) | r <- rolls] It should be doing an in-place array update as it evaluates the comprehension, but apparently something's being kept in memory longer than it has an excuse for. I tried another, more hand-coded version, to get rid of the mid-calculation comprehension and some possible overhead: > probDist specs = > foldl update orig > where orig = array bounds [(r, 0) | r <- range bounds] > update dist r = dist // [(r, 1 + dist!r)] > bounds = rollBounds specs But this one was even worse. I've sprinkled $! around quite liberally, to no avail; also, I'm compiling with -O, and I've tried various RTS options with no radical change in behavior. What's going on here? The array constructed has to be big, but not *that* big (77 Ints for four 20-sided) ... Is there an inherent inefficiency with GHC's arrays when used like this? I can't come up with a better algorithm - making a zeroed array with an element for each outcome, then adding 1 to the element for each outcome as it is read in seems straightforward enough. (Would a FiniteMap be any better? I'm not sure how ...) Thanks for any help ... I'm starting to get the hang of Haskell, but some of these semantic subtleties are driving me nutty ... Luke Maurer jyrinx_list(a)mindspring.com

1 0

Re: Interpret haskell within haskell.
by oleg＠pobox.com 23 Dec '02

23 Dec '02

Lauri Alanko wrote on Dec 22: > The magic is _here_: > (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) a) > ==> 6 > Here (interaction-enviroment) is a run-time representation of the > compile-time environment. It makes possible two-way interaction between the > stages. Essentially, first-class environments are all the magic you need to > implement eval. I'm sorry to act as a Grinch, but there is no magic. First, according to R5RS, (interaction-environment) is not a first-class environment. R5RS says (Section 6.5): > [[optional procedure]] (interaction-environment) > This procedure returns a specifier for the environment that contains > implementation-defined bindings, typically a superset of those listed > in the report. The intent is that this procedure will return the > environment in which the implementation would evaluate expressions > dynamically typed by the user. There is nothing there about interaction between phases. And in fact, this interaction does not work. If you put the following code (module aaa) (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) (display a) (newline)) into a file, _compile_ that file using Bigloo, and run the resulting a.out, you will see a message *** ERROR:bigloo:eval: Unbound variable -- a Nowhere the Scheme report talks about first-class environments. Please note that the result of (interaction-environment) is a _specifier_ for an environment. Some Scheme systems do provide first-class environments. For example, MIT Scheme has a form 'the-environment'. It comes at a price. In a post "Re: why isn't the environment explicit ?" on comp.lang.scheme on Mar 15, 2001, Joe Marshall wrote: > > Since you can (sort of) regard call/cc as making continuations > > explicit, why aren't environments explict ? > In MIT Scheme, they are. The special form (the-environment) returns > the current environment as a first-class object. > However. > The difficulty with using such a form is that it destroys any > possibility of compiler optimization. If you compile code with a > (the-environment) form in it (in MIT Scheme), the compiler essentially > throws up its hands and inserts code to call the interpreter. There is no Santa either.

1 0

Re: Interpret haskell within haskell.
by Jonathan.C.Cast-1 23 Dec '02

23 Dec '02

----- Original Message ----- From: Matt Hellige <matt(a)immute.net> Date: Friday, December 20, 2002 0:20 am Subject: Re: Interpret haskell within haskell. > In any case, here are my guesses at why Haskell doesn't have "eval": > - It is difficult to make the kind of run-time safety guarantees > that we are used to with Haskell/ML if we introduce constructs of > this kind. > - It would seem to require considerable typing information to be > carried around at run-time, which in general Haskell compilers > seem to rely on being able to avoid. More generally, it may > render unsafe a wide range of optimizing program transformations. > - It would require the run-time for potentially every program to be > considerably larger, carrying around an entire interpreter. > - It has not, historically, been a priority for the community. The > FP community has tended to focus more on safety and static > analysis, as well as efficiency of compiled output. The general > answer has > been, "Well, if you want that, you should be using > lisp/scheme/etc." > Are those reasons basically right, basically wrong, somewhere in the > middle? If it's actually mostly the final reason, I wonder if the idea > deserves more consideration. Has the idea been revisited in light of > monadic control flow, type classes and other relatively recent > developments? Would it be possible, in this case, to have our cake > and eat it too? Are you trying to argue here that monads, type classes, etc. remove the difficulties you list? Otherwise, it seems to me that supporting eval would remove just about every advantage Haskell has over imperative languages. > Matt > > -- > Matt Hellige matt(a)immute.net > http://matt.immute.net Jon Cast

1 0

Re: Interpret haskell within haskell.
by oleg＠pobox.com 21 Dec '02

21 Dec '02

David J. Sankel wrote: > I was referring to a haskell interpreter to be used > within haskell code. For instance: > main = do > user_configuration <- parseHaskell > title <- resolveFunction user_configuration "title" > :: String > putStr title This was exactly the gist of the message: http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html The message gave the working example. The end of the message posed that GHCi is better for these kinds of things. Simon Marlow's message shows that this is indeed the case.

2 1

Fail: <<loop>> ???
by Ingo Wechsung 21 Dec '02

21 Dec '02

Dear Haskellers, when I execute a program made with GHC (standard Haskell only, no optimization) I get Fail: << loop>> I have -W on, but it only tells me about a single overlapping pattern, which is ok. The same program crashes Hugs alltogether. Any hints for what I should look in my sources? MfG Ingo

3 2

Tree insert, lookup with keys
by Ingo Wechsung 20 Dec '02

20 Dec '02

Hi, perhaps I don't understand the type system fully yet: I want a tree that carrys some information of type s; data Tree s = TNil | Branch s Tree Tree; This is fine for String, Integer and other atomic types. ins :: Tree s -> s -> Tree s; ins Tnil s = Branch s Tnil Tnil; ins (Branch s l r) x = case compare x s of { LT -> Branch s (ins l x) r; EQ -> Branch s l r; GT -> Branch s l (ins r x); } So far so good, however, I do not always want to compare everything. What I really want is to have (compare (key x) (key s)) instead in the definition of ins. My attempt: class Keyed a where { -- Type a is keyed if it has a key function. key :: Ord b => a -> b; -- key is a function, that, when applied to a yields some b that is comparable } and then data Sym = Sym String Int Ty; -- Ty is another algebraic type instance Keyed Sym where { key (Sym a _ _) = a; -- use string as key } But I always get the following message: Cannot unify the type-signature variable `b` with the type `String` Expected type: b Inferred Type: String In the definition of `key': a Why is this? Has "key" to return the very same type for every instance? After all, I need type `b' in compare only so it should not matter what it really is. The compiler could check if for every instance key is defined so that the return type is some instance of Ord, couldn't he. Merry Christmas Ingo

3 2