I updated the ForeignBlocking wiki page with what I believe is the current state of this proposal; see http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ForeignBlo cking Cheers, Simon
I updated the ForeignBlocking wiki page with what I believe is the current state of this proposal; see
didn't I mention that "concurrent" may be inappropriate and misleading, and that I think it is bad practice to rely on the programmer annotating the dangerous cases, instead of the safe cases? wouldn't the safe approach be to assume that the foreign call may do anything, unless the programmer explicitly tells you about what things it won't do (thus taking responsibility). cheers, claus
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ForeignBlockin...
On Thu, Mar 30, 2006 at 09:39:44PM +0100, Claus Reinke wrote:
I updated the ForeignBlocking wiki page with what I believe is the current state of this proposal; see
didn't I mention that "concurrent" may be inappropriate and misleading, and that I think it is bad practice to rely on the programmer annotating the dangerous cases, instead of the safe cases?
I think dangerous is a misleading term here. you are already using the FFI, all bets are off. and it is not really dangerous to accidentally hold up your VM when you didn't expect, it is more just a simple bug. Unsafe or dangerous means potentially leading to undefined behavior, not just incorrect behavior or we'd have to label 2 as unsafe becaues you might have meant to write 3. :)
wouldn't the safe approach be to assume that the foreign call may do anything, unless the programmer explicitly tells you about what things it won't do (thus taking responsibility).
I think the worse problem will be all the libraries that are only tested on ghc that suddenly get very poor performance or don't compile at all when attempted elsewhere. However, the 'nonreentrant' case actually is dangerous in that it could lead to undefined behavior which is why that one was not on by default. John -- John Meacham - ⑆repetae.net⑆john⑈
didn't I mention that "concurrent" may be inappropriate and misleading, and that I think it is bad practice to rely on the programmer annotating the dangerous cases, instead of the safe cases?
I think dangerous is a misleading term here. you are already using the FFI, all bets are off. and it is not really dangerous to accidentally hold up your VM when you didn't expect, it is more just a simple bug.
perhaps "dangerous" was too strong a term, but if programmers don't annotate an ffi declaration, what is more likely: that they meant to state a property of that function, or that they didn't mean to? if there is a way to avoid simple bugs by not making assumptions about undeclared properties, then I'd prefer that to be the default route. if, on the other hand, programmers do annotate the ffi declaration, then it is up to them to make sure that the function actually has the property they claim for it (even in such cases, Haskell usually checks the declaration, but that isn't an option here).
Unsafe or dangerous means potentially leading to undefined behavior, not just incorrect behavior or we'd have to label 2 as unsafe becaues you might have meant to write 3. :)
you mean your compiler won't catch such a simple mistake?-) but, seriously, that isn't quite the same: if I write a Num, it's my responsibility to write the Num I meant, because the implementation can't check that. but if I don't write a Num, I'd rather not have the implementation insert one that'll make the code go fastest, assuming that would always be my main objective! (although that would be a nice optional feature!-)
wouldn't the safe approach be to assume that the foreign call may do anything, unless the programmer explicitly tells you about what things it won't do (thus taking responsibility).
I think the worse problem will be all the libraries that are only tested on ghc that suddenly get very poor performance or don't compile at all when attempted elsewhere.
- GHC and the other implementations should issue a warning for using non-standard or non-implemented features (that includes code that won't obviously run without non-standard features) - if an implementation doesn't implement a feature, there is no way around admitting that, standard or not - if adding valid annotations are necessary to make non-GHC implementations happy, then that's what programmers will have to do if they want portable code; if such annotation would not be valid, we can't pretend it is, and we can't pretend that other implementations will be able to handle the code - if only performance is affected, that is another story; different implementations have different strengths, and the standard shouldn't assume any particular implementation, if several are viable - but: if certain kinds of program will only run well on a single implementation, then programmers depending on that kind of program will only use that single implementation, no matter what the standard says (not all my Haskell programs need concurrency, but for those that do, trying to fit them into Hugs is not my aim)
However, the 'nonreentrant' case actually is dangerous in that it could lead to undefined behavior which is why that one was not on by default.
why not be consistent then, and name all attributes so that they are off by default, and so that implementations that can't handle the off case will issue a warning at least? cheers, claus
On Fri, Mar 31, 2006 at 12:52:11AM +0100, Claus Reinke wrote:
didn't I mention that "concurrent" may be inappropriate and misleading, and that I think it is bad practice to rely on the programmer annotating the dangerous cases, instead of the safe cases?
I think dangerous is a misleading term here. you are already using the FFI, all bets are off. and it is not really dangerous to accidentally hold up your VM when you didn't expect, it is more just a simple bug.
perhaps "dangerous" was too strong a term, but if programmers don't annotate an ffi declaration, what is more likely: that they meant to state a property of that function, or that they didn't mean to?
if there is a way to avoid simple bugs by not making assumptions about undeclared properties, then I'd prefer that to be the default route. if, on the other hand, programmers do annotate the ffi declaration, then it is up to them to make sure that the function actually has the property they claim for it (even in such cases, Haskell usually checks the declaration, but that isn't an option here).
Well, I would consider the performance bug the more serious one. in fact, they both are performance/scalability bugs rather than correctness ones. but one is obvious when you get it wrong, the other is subtle and could go unnoticed a long time and just make you think haskell is a slow language. we should make it so the obvious one is the more likely failure route so people fix it right away.
wouldn't the safe approach be to assume that the foreign call may do anything, unless the programmer explicitly tells you about what things it won't do (thus taking responsibility).
I think the worse problem will be all the libraries that are only tested on ghc that suddenly get very poor performance or don't compile at all when attempted elsewhere.
- GHC and the other implementations should issue a warning for using non-standard or non-implemented features (that includes code that won't obviously run without non-standard features) - if an implementation doesn't implement a feature, there is no way around admitting that, standard or not
well, there is if you didn't need the feature in the first place, but didn't realize it because it was obscured. the bigger danger is that the feature will be implemented, but very sub-optimally as in, hundreds of times slower than a fast call could easily be true so you get a very silent but fatal bug. FFI routines do need to be annotated correctly, sometimes for correctness and sometimes for performance. when correctness is at stake, you should err on the side of correct, when performance is at stake you should err on the side of what will cause the most rukus when you get it wrong :)
However, the 'nonreentrant' case actually is dangerous in that it could lead to undefined behavior which is why that one was not on by default.
why not be consistent then, and name all attributes so that they are off by default, and so that implementations that can't handle the off case will issue a warning at least?
yeah, that is what I originally proposed, but Simon brought up the good point (paraphrasing, I think this was his reasoning) that 'reentrant' is important for the safety of the system (as in, segfaults and corruption result when getting it wrong) while 'concurrent' is simply a choice on the part of the programmer as to what behavior they want. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Claus Reinke -
John Meacham -
Simon Marlow