John Meacham [EMAIL PROTECTED] wrote:
I generalized this primitive to
drop__ :: a - b - b
Also known in the Prelude as const...
The difference is that you propose it be primitive, with the intention
that a clever compiler should not be able to bypass it by inlining its
definition and
On Tue, Feb 21, 2006 at 10:15:59AM +, Malcolm Wallace wrote:
John Meacham [EMAIL PROTECTED] wrote:
I generalized this primitive to
drop__ :: a - b - b
Also known in the Prelude as const...
well, 'flip const' but yes.
The difference is that you propose it be primitive, with the
John Meacham wrote:
On Tue, Feb 21, 2006 at 10:15:59AM +, Malcolm Wallace wrote:
John Meacham [EMAIL PROTECTED] wrote:
I generalized this primitive to
drop__ :: a - b - b
Also known in the Prelude as const...
well, 'flip const' but yes.
The difference is that you propose it be
On Tue, Feb 21, 2006 at 11:04:40PM +, Simon Marlow wrote:
Your drop__ reminds me of GHC's touch#, which is like drop__ in the IO
monad. We use it to control lifetimes, eg. inside withForeignPtr. You
could implement drop in terms of touch#:
drop__ a b = case touch# a realworld# of
John Meacham wrote:
So, I finally decided that jhc needs real arrays, but am running into an
issue and was wondering how other compilers solve it, or if there is a
general accepted way to do so.
here is what I have so far
-- The opaque internal array type
data Array__ a
-- the array
After reading all the interesting responses I decided to go with a
slight generalization of my original idea, and it surprisingly turns out
to have other generally useful unintended uses, which is the point that a 'hack'
becomes a 'feature'. :)
before I had a primitive:
newWorld__ :: a - World__
Data.Array.ST has
runSTArray :: Ix i = (forall s . ST s (STArray s i e)) - Array i e
I think if you can implement that, then all your problems will be solved.
-- Ben
___
Haskell mailing list
Haskell@haskell.org
