Re: concurrency guarentees clarification
John Meacham wrote: * every runnable thread is guarenteed to run in a finite amount of time if a program reaches a yield-point infinitly often. What happens if one of the thread ends up in an infinite loop that contains a yield point? Infinitely often is unclear (I think I know what you're trying to say, but this is because I think I know what you're trying to say overall, and not because of these words). I'd say something like if, after hitting a yield point, the program hits another yield point in a finite amount of time (the start of execution and program termination being considered yield points for the purposes of this rule). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: FFI proposal: allow some control over the scope of C headerfiles
On Tue, Apr 25, 2006 at 09:40:58AM +0100, Simon Marlow wrote: Admittedly I haven't tried this route (not including *any* external headers at all when compiling .hc files). It might be possible, but you lose the safety net of compiler-checked calls. yeah, perhaps a hybrid approach of some sort, when building the package, use the system headers, but then include generated prototypes inside the package-file and don't propagate #includes once the package is built. or just an intitial conformance check against the system headers somehow (?), but then only use your own generated ones when actually compiling haskell code. It would be nice to never need to include external headers in .hc files. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: control over the scope of C implementations?
On 24 April 2006 15:08, [EMAIL PROTECTED] wrote:
Perhaps (just a quick first attempt to get the idea across):
{-# INCLUDE_PRIVATE foo/bar.h foobar.o #-}
{-# INCLUDE_PACKAGE foo/bar.h -lfoobar #-}
I would have considered allowing just
{-# INCLUDE_PRIVATE foo/bar.h foobar #-}
I understand your reasoning, but I think it's wrong to name libraries in
the source code. Library names tend to be platform specific, and change
from version to version. Unlike header files, the package implementer
can't easily wrap a library dependency in a local library.
By the way, I do not think that an implementation
necessarily has to avoid inlining of limited imports;
I think it also could choose to keep the necessary information around
in the hidden parts of the package.
Users of the package just cannot add foreign imports using those .h
files, in the same way as they cannot import hidden Haskell modules.
The issue is whether the .h file is available to the client at all.
Making it available might impose an unnecessary burden on the client,
such as having to install a development package for an external library.
Actually it just occurred to me why using NOINLINE isn't the right thing
here. The compiler should be free to inline a foreign call that depends
on a private header, as long as the header isn't required for
compilation, such as when using the native code generator.
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
RE: FFI proposal: allow some control over the scope of C headerfiles
On 25 April 2006 09:51, John Meacham wrote: On Tue, Apr 25, 2006 at 09:40:58AM +0100, Simon Marlow wrote: Admittedly I haven't tried this route (not including *any* external headers at all when compiling .hc files). It might be possible, but you lose the safety net of compiler-checked calls. yeah, perhaps a hybrid approach of some sort, when building the package, use the system headers, but then include generated prototypes inside the package-file and don't propagate #includes once the package is built. or just an intitial conformance check against the system headers somehow (?), but then only use your own generated ones when actually compiling haskell code. It would be nice to never need to include external headers in .hc files. Hmm, the more I think about it, the more I like this idea. It means we could essentially forget about the public/private header file stuff, we don't need the extra pragmas, and there would be no restrictions on inlining of foreign calls. Also, I've just checked and we #include very little when compiling .hc files. Just inttypes.h and float.h for HsFFI.h, and I suspect that it isn't necessary to include HsFFI.h at all. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: concurrency guarentees clarification
John Meacham [EMAIL PROTECTED] writes: * Foreign concurrent calls, handle IO, and all IO actions that directly interact with the world outside the current process all must be yield-points. (in addition to any yield-points implied by the progress guarentee) If an IO call includes a long period of waiting, we don't only want it to yield before or after it. We want it to allow other threads to proceed during the whole wait. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: FFI proposal: allow some control over the scope of Cheaderfiles
On 25 April 2006 10:48, Duncan Coutts wrote: One downside would be that we would only be able to call C functions which conform to the standard platform ABI. As it is at the moment (perhaps somewhat by accident) we can call C functions that have non-standard ABI annotations in their prototype, eg: int foo (int) __attribute__((regparam(3))) ok that's a silly example, bu there are more sensible examples of ABI weirdness - especially on arches like mips which seem to support half a dozen different ABIs. Perhaps we don't care, I'm not sure I do. The FFI declaration is supposed to specify the ABI completely, so these differences should be reflected in the FFI syntax. As you say it works by accident now - but only when compiling via C, when using the NCG it'll go wrong. Cheers, SImon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: unsafePerformIO and cooperative concurrency
Marcin 'Qrczak' Kowalczyk wrote: I would prefer otherwise. Every implementation supports it, which proves that it's useful. And it's no less unsafe than FFI. It's not a matter just of safety, it's a matter of whether its use should be encouraged. FFI is clearly the right thing sometimes, unsafePerformIO rarely is. -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: unsafePerformIO and cooperative concurrency
It was pointed out that you can't necessarily know what routines to avoid in unsafePerformIO without mandating certain things _don't_ use concurrency, rather than that, how about the following: Whether an implementation can yield to another thread inside an unsafePerformIO action is implementation dependent, however an implementation should not 'go wrong' hmm.. better term than 'go wrong'? The intent is calling concurrent routines inside of unsafePerformIO is okay, but they perhaps might not yield to other threads or something like sharing might be lost (but correctness is preserved). I think implementations should be able to handle this. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
