Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
please note to send ALL REPLY e-mail direct to our Sales Representative at: [EMAIL PROTECTED] Hi, Thank you for expressing interest in ATGWS watches. We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces. You can view our large selection of Rolexes (including Breitling, Tag Heuer, Cartier etc) at: www.QualitySwissTime.com For all orders placed in the month of June, all shipping and handling charges will be free. As we are the direct manufacturers, you are guaranteed of lowest prices and highest quality each and every time you purchase from us. You may also be interested to know that we have the following brands available in our wide selection as well: 1. Leather band Daytona (ladies and men's) 2. Blancpain3. Fortis4. Jaeger LeCoutre5. Longines6. Mont Blanc7. Movado8. Oris9. Roger Dubuis10. Ulysse11. Zenith12. Audemar Piguet13. Breitling14. Bvglari15. Cartier16. Corum17. Dunhill18. Franck Muller19. Gerard Perregaux20. IWC21. IWC22. Panerai23. Patek Philippe24. Tag Heuer25. Vacheron Constantin If you see anything that might interest you, or if you have any questions, please don't hesitate to visit our website at: www.QualitySwissTime.com I certainly look forward to hearing from you. Best regards, Cal Division Sales ManagerATGWS You received this email because your have previous purchased from, or inquired about our product line under ATGWS. If you do not want to receive further mailings from ATGWS, unsubscribe by sending an email with the title heading: DELETE in the subject line to [EMAIL PROTECTED] please note to send ALL REPLY e-mail direct to our Sales Representative at:[EMAIL PROTECTED]
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 10
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 treated as an internal detail and ignored.] -- Alastair ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 10
"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 :: Point -> IO () > > > > I like the second idiom. You are right that there is no need for > > the application programmer to know whether pointers are involved, > > because even in the first style, it is not possible to 'peek' inside > > a Ptr Point to get the `actual' Point value. So why not hide the > > pointer altogether? Yes. > > I presume that should be 'newtype' rather than 'data'? True. Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 9
On Wed, Jun 04, 2003 at 11:09:43PM +1000, Manuel M T Chakravarty wrote: > StablePtr are used to export references to Haskell values to > C, where they are treated as abstract data. In C one > traditionally uses (void *) for that purpose (see "man > qsort(3)"). We want to make sure HsStablePtr is not to wide > to be passed as an argument to C functions expecting such > abstract types (such as qsort(3)). How does HsStablePtr differ from HsDouble in this respect? (except that the C side can do even less with HsStablePtr.) You know it somehow corresponds to a pointer on the Haskell side, but that doesn't seem relevant. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
> > > > 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 right that there is no need for > the application programmer to know whether pointers are involved, > because even in the first style, it is not possible to 'peek' inside > a Ptr Point to get the `actual' Point value. So why not hide the > pointer altogether? Yes. I presume that should be 'newtype' rather than 'data'? Cheers, Simon ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 10
> > 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 type with the same results. > > > > There definitely aren't any values of type Point, so I don't see why it > > needs a semantics. OK, I think I agree with all of this. > My main problem with this extension is the following: > > * As we have learnt, nhc98 and Hugs use `data T' for an > entirely different purpose than the one proposed by John > (namely to represent primitive external types). It may be > possible to abuse nhc98 and Hugs `data T' also in the way > John wants it (and GHC provides it), but this sounds less > straight forward than initially where the impression was > given that the three systems already implement the same > extension. Actually, I think both Hugs and nhc98 straightforwardly allow John's use. All three systems do implement the same extension. In fact it is the current usage of 'data T' for primitive types that is tricky. At the moment, basically they must be *internal* types, i.e. types already known to the Haskell runtime system. The idea of using them for external, previously unknown, types is entirely speculative. It would require somehow specifying storage sizes, and routines to marshal values into the heap, and perhaps more. None of these mechanisms yet exist. The question was raised as to whether we might one day want those facilities, because the natural place to specify them is in the FFI. But no-one even has a proposal for how it might work, so I think we can safely dismiss it at this stage. > > > 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 right that there is no need for the application programmer to know whether pointers are involved, because even in the first style, it is not possible to 'peek' inside a Ptr Point to get the `actual' Point value. So why not hide the pointer altogether? Yes. Regards, Malcolm ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 10
"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 (which might be called Point, > > MousePos, point_t, struct point or whatever) > > > > 2) that we have a pointer to it > > > > 3) that the thing we have a pointer to can take on a number > > of different > > values. We don't know what the values are but this doesn't > > mean they don't exist. > > 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. > > Additionally, the type argument to Ptr is used to resolve overloading > when doing marshalling using the Storable class, but we're not using > that facility here because no marshalling is going on. > > There definitely aren't any values of type Point, so I don't see why it > needs a semantics. The semantics of empty data declarations seems like > an entirely orthogonal issue, and I don't see any problem with the > current semantics for empty data declarations, which is a completely > natural degenerate case of ordinary data declarations. > > > > And what do you mean by a trick? > > > > It is possible that, since we cannot directly observe values > > of foreign types, > > we can safely model the type as having just one value > > (bottom) or, perhaps > > even no values at all. By this I mean that exactly the same > > properties can > > be proved whether we use an accurate model or a simplified model. > > > > But, it is a trick because we know that there is not just one > > (or zero) values in that type (at least, for most types). > > I don't agree with that last sentence: there's no trickery going on; it > doesn't matter how many values of the type Point there are. I could use > any Haskell type with the same results. > > Let me say this another way: the type argument to Ptr in no way > represents the type of the foreign data. It is used to resolve > overloading and to disciminate pointer types in Haskell marshalling > code, that's all. There is no link between the semantics of the Haskell > type and the semantics of the foreign type (whatever that might be), and > we shouldn't confuse the issue by pretending that there is. Exactly what I think, too. Empty data types are used as Skolem constants in the type checker. Alastair wrote earlier that `data T' is not inhibited (except by bottom as we have a lazy language). That's semantically exactly what we want. Hence, if the compiler wants to regard two values of type `T' to be the same, it is perfectly reasonable to do that. That's the point where IMHO Alastair's earlier argument was flawed (and what has led to the misunderstanding). My main problem with this extension is the following: * As we have learnt, nhc98 and Hugs use `data T' for an entirely different purpose than the one proposed by John (namely to represent primitive external types). It may be possible to abuse nhc98 and Hugs `data T' also in the way John wants it (and GHC provides it), but this sounds less straight forward than initially where the impression was given that the three systems already implement the same extension. * So far, the FFI addendum has managed to stay away from changing anything at H98's syntax other than adding `foreign'. I am reluctant to change that, but then it is really a very small change that won't break anything. BTW, I tend to use the following (which - suprise, suprise - is what c2hs generates in that situation): data Point = Point (Ptr Point) foreign import getMousePos :: Point -> IO () No need for an extension here and I hide from the application programmer the fact that the argument to `getMousePos' is a pointer. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
