cvs commit: hugs98/libraries/Hugs ConcBase.hs Exception.hs IOExts.hs Prelude.hs hugs98/src connect.h iomonad.c hugs98/tests/rts primexc.hs
ross 2003/01/30 17:40:47 PST Modified files: libraries/Hugs ConcBase.hs Exception.hs IOExts.hs Prelude.hs src connect.h iomonad.c tests/rts primexc.hs Log: Revert earlier change (removal of unused failure continuation from IO) as requested by Sigbjorn to restore binary compatibility. Revision Changes Path 1.12 +3 -3 hugs98/libraries/Hugs/ConcBase.hs 1.9 +2 -2 hugs98/libraries/Hugs/Exception.hs 1.10 +2 -2 hugs98/libraries/Hugs/IOExts.hs 1.20 +14 -11 hugs98/libraries/Hugs/Prelude.hs 1.63 +3 -3 hugs98/src/connect.h 1.42 +34 -14 hugs98/src/iomonad.c 1.7 +3 -3 hugs98/tests/rts/primexc.hs
Cheers,
if we ignore the issue of raising exceptions from within extension
DLLs, there's a way for old and new DLLs to co-exist:
In modules with a 'needPrim_hugs' declaration with a value
of 4 or below, the interpreter simply decrements by one the
arity of 'primitive's with IO results. Hacky, but it'll do the job.
--sigbjorn
----- Original Message -----
From:
ross 2003/01/30 17:40:47 PST
Modified files: libraries/Hugs ConcBase.hs Exception.hs IOExts.hs Prelude.hs src connect.h iomonad.c tests/rts primexc.hs Log: Revert earlier change (removal of unused failure continuation from IO) as requested by Sigbjorn to restore binary compatibility.
Revision Changes Path 1.12 +3 -3 hugs98/libraries/Hugs/ConcBase.hs 1.9 +2 -2 hugs98/libraries/Hugs/Exception.hs 1.10 +2 -2 hugs98/libraries/Hugs/IOExts.hs 1.20 +14 -11 hugs98/libraries/Hugs/Prelude.hs 1.63 +3 -3 hugs98/src/connect.h 1.42 +34 -14 hugs98/src/iomonad.c 1.7 +3 -3 hugs98/tests/rts/primexc.hs _______________________________________________ Cvs-hugs mailing list Cvs-hugs@haskell.org http://www.haskell.org/mailman/listinfo/cvs-hugs
On Thu, Jan 30, 2003 at 06:15:38PM -0800, Sigbjorn Finne wrote:
if we ignore the issue of raising exceptions from within extension DLLs,
There's no way for them to raise exceptions, is there?
there's a way for old and new DLLs to co-exist: In modules with a 'needPrim_hugs' declaration with a value of 4 or below, the interpreter simply decrements by one the arity of 'primitive's with IO results. Hacky, but it'll do the job.
How can we distinguish IO and pure primitives? Also, new and old ones would need different versions of returnIO.
"Ross Paterson"
On Thu, Jan 30, 2003 at 06:15:38PM -0800, Sigbjorn Finne wrote:
if we ignore the issue of raising exceptions from within extension DLLs,
There's no way for them to raise exceptions, is there?
Not via the HugsAPI, but the continuation is just sitting there on the stack, so there are no guarantees, but I'm not aware of any code that makes use of it.
there's a way for old and new DLLs to co-exist: In modules with a 'needPrim_hugs' declaration with a value of 4 or below, the interpreter simply decrements by one the arity of 'primitive's with IO results. Hacky, but it'll do the job.
How can we distinguish IO and pure primitives?
By looking at the type of a 'primitive' declaration. I'm assuming that modules which use FFI declarations are few (and fresh) and that their DLLs can simply be regenerated. I've got this implemented here, so if you set IOArity back to 1 again, I'll commit the changes. thx --sigbjorn
participants (3)
-
Ross Paterson -
ross＠glass.cse.ogi.edu -
Sigbjorn Finne