it says:
A function or action taking a some kind of state and returning a pair consisting of a result and a new state, the result is the first element of the pair and the new state is the second, see e.g. Random.
unfortunatly, Random and the mapAccum{RL} functions don't agree at all. the accumulating map functions assume the state is in the first element and the new element is in the second, but random doesn't behave this way and it appears neither do the libraries. am i the only one bothered by this? i would prefer if at least the libraries would change and put the state in the first position of the pair. it's probably hopeless to get Random to change at this point, as with the mapAccum functions. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
So I just checked and what Java does is it always loads the unqualified import, so it doesn't do my stuff with automatically adding the package name to imports, which is reasonable. -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Wed, 27 Feb 2002, Hal Daume III wrote:
it says:
A function or action taking a some kind of state and returning a pair consisting of a result and a new state, the result is the first element of the pair and the new state is the second, see e.g. Random.
unfortunatly, Random and the mapAccum{RL} functions don't agree at all. the accumulating map functions assume the state is in the first element and the new element is in the second, but random doesn't behave this way and it appears neither do the libraries.
am i the only one bothered by this? i would prefer if at least the libraries would change and put the state in the first position of the pair. it's probably hopeless to get Random to change at this point, as with the mapAccum functions.
- Hal
-- Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
oops! that was supposed to be a follow up to my post about pacakge, not about this. sorry :) -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Wed, 27 Feb 2002, Hal Daume III wrote:
So I just checked and what Java does is it always loads the unqualified import, so it doesn't do my stuff with automatically adding the package name to imports, which is reasonable.
-- Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Wed, 27 Feb 2002, Hal Daume III wrote:
it says:
A function or action taking a some kind of state and returning a pair consisting of a result and a new state, the result is the first element of the pair and the new state is the second, see e.g. Random.
unfortunatly, Random and the mapAccum{RL} functions don't agree at all. the accumulating map functions assume the state is in the first element and the new element is in the second, but random doesn't behave this way and it appears neither do the libraries.
am i the only one bothered by this? i would prefer if at least the libraries would change and put the state in the first position of the pair. it's probably hopeless to get Random to change at this point, as with the mapAccum functions.
- Hal
-- Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (1)
-
Hal Daume III