GHC 5.02 works fine for this program. We're going to release it this
week.
Thanks for the test -- I've added it to our test suite!
Simon
| -Original Message-
| From: John Hughes [mailto:[EMAIL PROTECTED]]
| Sent: 19 September 2001 18:00
| To: [EMAIL PROTECTED]
| Subject: Type-checker
Ashley Yakeley [EMAIL PROTECTED] wrote,
The documentation for FFI in the GHC user's guide seems to be out of date
with regard to passing Ptrs across.
1. My reference is
http://www.haskell.org/ghc/docs/latest/set/ffi.html
(from
Ashley Yakeley [EMAIL PROTECTED] wrote,
The documentation for FFI in the GHC user's guide seems to
be out of date
with regard to passing Ptrs across.
1. My reference is
http://www.haskell.org/ghc/docs/latest/set/ffi.html
(from
At 2001-09-19 23:45, Manuel M. T. Chakravarty wrote:
What if the type is polymorphic (e.g.
declared as 'Storable a = Ptr a' rather than something like 'Ptr Word8')?
Also possible, as the argument to `Ptr' is just dummy.
What? What about 'withObject'? A Haskell 'Ptr a' is a C array-pointer
At 2001-09-20 02:14, Simon Marlow wrote:
I'll just add that the docs have been updated for 5.02,
Do you have a URL for that?
And don't forget that using foreignPtrToPtr is quite dangerous; much
better to use withForeignPtr instead, otherwise you might find the
ForeignPtr being finalised
At 2001-09-20 02:31, I wrote:
int foo (char selector,char* arg)
...
if (selector == 200)
I guess that should be
int foo (unsigned char selector,char* arg)
--
Ashley Yakeley, Seattle WA
___
Glasgow-haskell-users mailing list
At 2001-09-20 02:14, Simon Marlow wrote:
I'll just add that the docs have been updated for 5.02,
Do you have a URL for that?
Not yet, but the release is imminent (really!) so it'll be up on the web
site shortly.
And don't forget that using foreignPtrToPtr is quite dangerous; much
At 2001-09-20 02:46, Simon Marlow wrote:
No, it's not safe. The reason is that the compiler can track a
ForeignPtr to discover when it dies, in order to run the finalizer, but
it can't track a Ptr. As soon as you drop all references to the
ForeignPtr then the finalizer will run, even if you
If ForeignPtrs work the way I think they do, then I'm surprised they're
designed as pointers. I believe the 'pointer' functionality is orthogonal
to the 'finalisable' functionality and should be separated like this:
--
data Finalisable a -- abstract handle to finalisable object
instance
At 2001-09-20 06:55, Manuel M. T. Chakravarty wrote:
The FFI does not ensure any type consistency between the
arguments to `Ptr'/`ForeignPtr' and the corresponding C
types.
I've been using 'Ptr Word8' with newArray to pass lists of bytes to C
functions. They appear as unsigned char arrays in
Ashley Yakeley [EMAIL PROTECTED] wrote,
At 2001-09-20 06:55, Manuel M. T. Chakravarty wrote:
The FFI does not ensure any type consistency between the
arguments to `Ptr'/`ForeignPtr' and the corresponding C
types.
I've been using 'Ptr Word8' with newArray to pass lists of bytes to C
At 2001-09-20 19:32, Manuel M. T. Chakravarty wrote:
What I meant with the remark that you quote is that if you
would use
foreign import foo :: Ptr Int - IO Float
with
float foo (float *x)
{
return *x;
}
the system will not complain, but your program may dump
core.
What if the C
Consider goal-directed theorem prover (or proof checker). Two existing
samples are in Lawrence Paulson's ML for the Working Programmer, and
yours truly's http://www.cs.utoronto.ca/~trebla/fp/prover/index.html
The advantage of mine is it illustrates monads. The advantage of Paulson's
is it
As far as I can tell, the report doesn't allow (:) or []((:),
[]) in the
export list, yet the hugs prelude has the first and the GHC
prelude has
the second. Have I missed something that allows them or is
this a bug in
the preludes or the report?
(:) is allowed in an export list; it is
On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote:
As far as I can tell, the report doesn't allow (:) or []((:),
[]) in the
export list, yet the hugs prelude has the first and the GHC
prelude has
the second. Have I missed something that allows them or is
this a bug in
...or how about a web zine along the lines of (the Linux) Kernel Notes
and cousins (http://kt.zork.net/)? This is just a (couple of?) guy(s)
closely following the kernel mailing list, and summarizing, quoting
interesting mail, providing links where appropriate and so on.
Immensely useful for
I am using SocketPrim to send a udp packet to each of 254 addresses on a
network. The message packets have been preconstructed and placed in a
list, whose content has already been checked for correctness and appear
to meet the specifications in the appropriate RFC. When I go
through the list
Found the error. No need to follow up.
Apologies to anyone who objects to mail that turns out not to need
answering.
Murray Gross
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ian Lynagh writes:
On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote:
(:) is allowed in an export list; it is just a normal operator.
An export is
export - qvar
| qtycon [(..) | ( qcname1 , ... , qcnamen )] (n=0)
| qtycls [(..) | ( qvar1 , ... , qvarn )]
Ah, I forgot that you can't export a constructor on its own.
You can't?
I probably knew this once but looking at it now, it seems kinda
surprising. Haskell's module system is supposed to be just namespace
control --nothing more-- so why is it preventing me from doing something
which is
20 matches
Mail list logo
