On Sun, Dec 21, 2008 at 02:56:06AM -0700, Luke Palmer wrote: > 2008/12/21 Peter Todd <p...@petertodd.org> > > > If I could somehow arrange for the transform function to detect when it > > is being applied to a unevaluated thunk, and then modify the thunk in > > place, that would basically be the behavior I need. Any suggestions? > > > That is exactly what is already happening. Perhaps you want what you think > is happening: if a value *is* evaluated, you want to apply the > transformation right then instead of making a thunk.
Not quite. If I have a thunk, at the low level somewhere it must refer
to the transform function, the transform matrix, and the element that is
to be transformed. If I apply another transform to that unevaluated
thunk, my understanding is that haskell will represent it as such:
thunk transform Ta (thunk transform Tb e)
When I want the following:
thunk transform (Ta * Tb) e
This alternate definition of the Element structure might make more
sense:
data Element = Element {
elementOrigin :: V,
elementSubs :: [Element]
}
| ElementThunk T Element
transform :: T -> Element -> Element
transform t (ElementThunk t2 e) = ElementThunk (tmul t t2) e
transform t e = ElementThunk t e
transform t e = Element {
elementOrigin = tmulv t (elementOrigin e),
elementSubs = map (transform t) (elementSubs e)
}
This gives a behavior close to what I want, applying a transform to an
element results in a "thunk", and subsequent transforms simply modify
the thunk, the problem is that I don't see a way to implicitly coerce an
ElementThunk into an Element on demand for all the other code in the
program that expects elements. (such as the elementOrigin function)
> By the way, this is very operational thinking for Haskell. Haskell tries
> quite hard to abstract away operational thinking, so thinking on this level
> will be difficult and more work than you should be doing to write a program.
Yes, but this part of the program is library code, that will be used by
a whole pile of other stuff, so if I can get the right behavior
"magically" the rest of the program will be a lot easier to write.
FWIW this is EDA software, those "elements" refer to elements of a
printed circuit board layout, and the transform operations correspond to
stuff like moving a chip on the board. The representation of a simple IC
would consist of something like an element, with a bunch of sub-elements
for each pin, all of which have geometry data.
> May I ask why you want this behavior? Have you just tested it and observed
> that it is running too slowly and you are trying to speed it up?
I've written a previous version of this program in Python actually,
where I explicitly modeled the lazy evaluation behavior that I wanted.
It all worked great, but the overall speed was still quite slow. I was
hoping that Haskell, built around lazy evaluation already, would be a
better fit.
That, and in any case, other aspects of the program that I've re-written
in Haskell saw about a 5-1 redunction in code length... :)
--
http://petertodd.org 'peter'[:-...@petertodd.org
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
