Ross Paterson <[EMAIL PROTECTED]> wrote,
> On Thu, Jul 03, 2003 at 06:51:31PM +1000, Manuel M T Chakravarty wrote:
> > Ross Paterson <[EMAIL PROTECTED]> wrote,
> >
> > > The new wording:
> > >
> > > \code{unsafePerformIO} may compromise typing; to avoid this, the programmer
> > > should ensu
On Thu, Jul 03, 2003 at 06:51:31PM +1000, Manuel M T Chakravarty wrote:
> Ross Paterson <[EMAIL PROTECTED]> wrote,
>
> > The new wording:
> >
> > \code{unsafePerformIO} may compromise typing; to avoid this, the programmer
> > should ensure that the result of \code{unsafePerformIO} has a monom
Ross Paterson <[EMAIL PROTECTED]> wrote,
> 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
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
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 t
"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)
>
> > > > 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 lik
> > 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 an
"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) t
> > > > * 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.
"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 n
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
> 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,
> MousePo
On Tuesday 03 June 2003 10:15 am, Simon Marlow wrote:
> > We know that T must contain bottom.
>
> Not necessarily - GHC's primitive types don't contain bottom.
Of course, GHC's primitive types aren't in the standard.
> But I'm probably just being awkward, since I really don't understand
> what i
> 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.
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 (
On 02-Jun-2003, Alastair Reid <[EMAIL PROTECTED]> wrote:
>
> > The Mercury compiler will generate appropriate glue code to marshal and
> > unmarshal values of that type.
>
> How does it figure out what concrete type to use? Does it use trial
> compilations a la autoconf?
No. We don't try to s
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 that T mus
> Using `newtype T = MkT Int8' or equivalent only works for foreign data
> types whose representation is known. How do you deal with C's "time_t",
> for example? Or with C "struct" types? The user doesn't want to make
> non-portable assumptions about what padding the C compiler is going
> to in
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> Are you suggesting we ought to be able to define new primitive types?
Sorry, yes indeed that was the suggestion.
Or at least, it is not so much a suggestion, as a recognition that
Hugs and nhc98 already use the 'data T' mechanism for this purpose,
so
> Using `newtype T = MkT Int8' or equivalent only works for foreign data
> types whose representation is known. How do you deal with
> C's "time_t",
> for example? Or with C "struct" types? The user doesn't want to make
> non-portable assumptions about what padding the C compiler is going
> t
On 02-Jun-2003, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> > On 02-Jun-2003, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > >
> > > I can't see how to acquire a value of type T that isn't bottom.
> >
> > By calling a function defined using the FFI, of course.
>
> But the FFI lists the types tha
On 02-Jun-2003, Alastair Reid <[EMAIL PROTECTED]> wrote:
> If all the compiler is given is:
>
> data T
>
> where T is not a builtin type, the compiler can't possible know how to
> represent or marshall it. (And since we can already do that using 'newtype T
> = MkT Int8' I don't think we need
> On 02-Jun-2003, Simon Marlow <[EMAIL PROTECTED]> wrote:
> >
> > I can't see how to acquire a value of type T that isn't bottom.
>
> By calling a function defined using the FFI, of course.
But the FFI lists the types that may be returned by a foreign function,
and T is not one of them.
Are
On 02-Jun-2003, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> I can't see how to acquire a value of type T that isn't bottom.
By calling a function defined using the FFI, of course.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
The University of Melbourne
On 02-Jun-2003, Alastair Reid <[EMAIL PROTECTED]> wrote:
>
> I was just trying to show how to create a value of type
> T which might be bottom. It would have been easier to use:
>
> t :: T
> t = undefined
The same issue arises for ghc's unboxed types, of course.
ghc has some complic
> > 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 crea
> 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 w
> 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 :: Sto
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,
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.
Alas
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
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 defin
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? They are used quite often to represent the abstract targets of
pointers as in:
data Foo
data Bar
foreign lookupBar :: Ptr Foo -> IO (Ptr Bar) --
> 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 n
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 enou
37 matches
Mail list logo
