The new wording:
\code{unsafePerformIO} may compromise typing; to avoid this, the programmer
should ensure that the result of \code{unsafePerformIO} has a monomorphic
type.
rules out the following:
my_hash :: Storable a = a - Int
my_hash a = fromIntegral $ unsafePerformIO
Malcolm Wallace [EMAIL PROTECTED] wrote,
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
vs
data Point = Point (Ptr Point)
foreign import getMousePos :: Point - IO
Simon Marlow [EMAIL PROTECTED] wrote,
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
vs
data Point = Point (Ptr Point)
foreign import getMousePos ::
ok, I'm convinced. The semantics of empty datatypes can be a type inhabited
only by bottom.
Hugs implements exactly that.
[Except in the special case of a few magical names (Int, Float, etc) when they
occur in the Prelude (and only then). Since it is only usable in the
Prelude, they can be
Ross Paterson [EMAIL PROTECTED] wrote,
Minor nits: there's a footnote saying Finalizers in Haskell cannot
be savely [sic] realised without requiring support for pre-emptive
concurrency. I'd suggest dropping pre-emptive: with cooperative
concurrency it's perfectly safe to collect the
Simon Marlow [EMAIL PROTECTED] wrote,
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
-=- Changes since RC 9
* 6.2: All the types in CTypes must be newtypes that are exported
abstractly.
This change makes things highly inconvenient in nhc98. A newtype
can
* 6.2: All the types in CTypes must be newtypes that are exported
abstractly.
How about exporting them non-abstractly for nhc98 only, and adding a
comment to explain why the workaround is necessary?
That's what I prefer, too.
OK, that's what I've done. The spec can
Simon Marlow [EMAIL PROTECTED] wrote,
We routinely use code like this:
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
The idea being that:
1) there is a foreign type
Let's be clear about the role of Point here: it is a dummy type
argument to Ptr, used to disambiguate the type 'Ptr Point' from any
other kind of Ptr. It is for type-safety in the Haskell code.
It doesn't matter how many values of the type Point there are. I could
use any Haskell
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
vs
data Point = Point (Ptr Point)
foreign import getMousePos :: Point - IO ()
I like the second idiom. You are
Alastair Reid writes:
I strongly agree that we should definitely add the ability to
declare types
whose definition is provided externally. (i.e., provide the
feature that empty datatype decls currently provide.)
Before adding them, we need to agree on the semantics and
syntax (in
On Monday 02 June 2003 2:32 pm, Simon Marlow wrote:
Ok. But I still don't understand why the whole discussion
isn't moot.
I can't see how to acquire a value of type T that isn't bottom.
Whether you can acquire values of this type or not, we need
to give it a semantics.
We know
We routinely use code like this:
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
The idea being that:
1) there is a foreign type (which might be called Point,
MousePos, point_t,
On Saturday 31 May 2003 10:11 pm, John Meacham wrote:
This was discussed here before and there seemed to be some support for
it, but how about adding the empty data declaration extension to the FFI
spec?
I strongly agree that we should definitely add the ability to declare types
whose
Dnia nie 1. czerwca 2003 23:55, Alastair Reid napisa:
introduces a type T whose only value is bottom.
]]
This semantics is obviously flawed though because it would suggest that any
two values of type T are equal (and equal to bottom) and that optimizations
based on that equality are
John Meacham wrote:
This was discussed here before and there seemed to be some support for
it, but how about adding the empty data declaration extension to the FFI
spec?
I agree, it would be a suitable addition to the FFI, since it is the
place where such types make most sense.
Alastair
On Monday 02 June 2003 11:14 am, Malcolm Wallace wrote:
How about something like:
The declaration
data T
declares an abstract datatype T, whose values and operations are
defined external to the Haskell language. Values of T follow
the semantics of the foreign language, in
I don't think we have much choice about whether undefined
values are part of
the type. If you can create a value of that type:
x - derefPtr (px :: Ptr T)
I'm not following this. what exactly is derefPtr? The only analogous
function I can think of is Foreign.peek:
peek :: Storable
I'm not following this. what exactly is derefPtr? The only analogous
function I can think of is Foreign.peek:
Sorry, I meant peek.
but peek will unmarshal the value at the end of the Ptr into T, so T
cannot be abstract.
Sorry, I was just trying to show how to create a value of type
T
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
-=- Changes since RC 9
* 6.2: All the types in CTypes must be newtypes that are exported
abstractly.
This change makes things highly inconvenient in nhc98. A newtype
can only be passed across the FFI in nhc98 if we
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
-=- Changes since RC 9
* 6.2: All the types in CTypes must be newtypes that are exported
abstractly.
This change makes things highly inconvenient in nhc98. A newtype
can only be passed across the FFI in nhc98 if we have enough
21 matches
Mail list logo
