Manuel
A couple of comments about the FFI spec.
I was trying to find out whether the automatic newtype unwrapping for
'foreign' declarations was part of the FFI spec. I searched for
'newtype'. Nothing.
Turns out that the *only* reference is in the sentence in 3.2:
"The argument types
Manuel
Would it be worth mentioning or amplifying this point in the FFI spec,
or perhaps in an accompanying Appendix/Commentary of examples and FAQs?
Else someone else is going to trip over it sooner rather than later.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL P
| I think the essence of Daan's proposal was that the goals we hope to
| achieve using 'bound', 'threadsafe', and other ffi annotations could
| be achieved by adding a small amount of additional functionality
| and wrappers and that benefits of doing this are:
That all sounds splendid. If only I u
| However, my proposal is not anywhere fundamentally difficult -- in its
essence, I just
| propose to move the implementation of the thread allocation strategy
from the RTS/C
| code, to a Haskell library. This gives programmers both a low-level
interface for
| explicit access and a high-level inte
have some kind of consensus, but you're the only one who can help us
understand your proposal.
Simon
| -Original Message-
| From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]
| Sent: 17 March 2003 22:06
| To: Daan Leijen; Wolfgang Thaller; [EMAIL PROTECTED]
| Subject: RE: Bou
| Now, what I don't like about my proposal and your proposal is
| that the user has to be aware of OS threads when making
| foreign calls by wrapping it in "threadSafe" or adding
| "threadsafe" sometimes -- but maybe that is unavoidable.
Actually, the proposal currently on the table, which no o
| Maybe, the forkOS/forkIO approach is flawed, but I think we
| should only rule it out when we can provide a convincing
| example where only the keyword approach would work, and where
| we can't use combinators to achieve the same effect.
Daan,
There has been extended discussion on this st
| First let me outline my current understanding of what 'bound' means.
| Consider the following scenario:
|
| Haskell program is running in OS thread 't1'
| Haskell program calls C function 'foo'.
| 'foo' forks a new OS thread 't2'.
| In parallel: 't1' calls Haskell function 'f1' and
|
[I've updated the "Semantics for foreign threads" document by
re-ordering the sections a bit. It'd benefit from having a bit more
formal syntax. No one has commented a single word on the operational
semantics. I don't know whether that's because it's so clear that no
discussion is needed, or so
| *) I am not convinced that thread synchronization should be done by
the
| FFI
Me neither! It was news to me that anyone was *relying* on the
(implementation-specific) fact that a "safe" call blocks other Haskell
threads. I'd always regarded "safe" as just like "threadsafe" except
that it was
Folks
There was a spirited debate about the relationship between native OS
threads and Haskell threads. I got very confused. To clear up my
brain, Simon and I wrote a little operational semantics that tries to
make precise what is going on. It's in CVS as
haskell-report/ffi/threads.tex
| I have recently spent some time improving GHC's support for
| "threadsafe" foreign calls.
| As a side effect of fixing a crashing bug, I made "safe" behave in
| exactly the same way as "threadsafe".
That's a positive advantage, provided there isn't a massive efficiency
cost. I'm all for nuki
| In the meantime, I'm glad we have got a new function
|atomicModifyIORef
| which I for one will use, when it gets into GHC's regular release.
Just before this gets out of the door... any chance of calling it
modifyIORef
and documenting that it's atomic? Sometimes names can get too
When it comes down to it, I don't think we are that far apart.
1. Everyone wants a C-finaliser interface; it's very convenient. So it
should be in the spec. It's probably a good plan to specify that such C
finalisers must obey the constraints of an 'unsafe' foreign import.
2. It is clear tha
Hi Alastair
| a comment on SimonM's finalizer document. I decided to comment rather
| than edit since my comments require more than tweaking the odd word
| here and there.
I suggest you edit directly, striving, as Simon did, to be even-handed.
I do have one comment on your rejoinders, though:
John
I'm not quite sure what you mean. I think you are saying that this is a
reason it's important to have Haskell finalizers, but I'm not sure. How
would you like to write a paragraph or two to explain the issue, and we
can put it in the document? That way it would say what you mean.
Simon
| (a) It was the first mention of MVars that I found in the docs.
| (b) I only really mentioned it because the type sigs are wrong.
Hmm. That's not very clever.
| Doesn't it block if another thread manages to sneak a putMVar into
| the middle? Maybe I should read your "Awkward Squad" paper to
| type MVar# s elt-- primitive
|
| newMVar#:: State# s -> (# State# s, MVar# s elt #)
| takeMVar# :: SynchVar# s elt -> State# s -> (# State# s, elt #)
| putMVar#:: SynchVar# s elt -> State# s -> State# s
Bad idea to look at the primops. The important things are
| I claim that the major thing that finalizers do is manipulate shared
| state.
That is certainly true. If they were pure, you'd never know they'd run!
| To get any benefit from writing finalizers in Haskell, I have to have
| MVars which protect against finalizers.
Nearly right, but not qu
| Am I right in thinking that you are proposing that we revert to
| writing Haskell finalizers but that Hugs and NHC programmers would
| have to avoid writing finalizers which manipulate Haskell state while
| GHC would use MVars to protect that state?
Yes, that's right. It is often the case tha
Alastair,
You didn't respond to my proposal, perhaps because it didn't seem like
one
(I've changed a few words)
| a) Haskell finalisers should be available on all systems
|
| b) Finalisers can run at any GC point. The programmer needs to be
aware
| of this. Often it does not matter (e.g. cal
| > c) On systems (like Hugs and NHC) that have no synchronisation
| > primitives, you have to roll your own by calling C procedures.
|
| Just to be clear about this.
|
| You are not rolling your own synchronization primitive, you are
| writing code that is guaranteed to contain no preemption po
| > (A mutex lock is required to ensure that the pending queue is not
| > traversed more than once, but that is all I think.)
|
| I don't understand how this would work in single-threaded systems
(like
| I understand NHC to be).
I haven't been following the details of this discussion, but I thin
I confess that I have not followed the twists and turns of this
discussion, but it seems to have gotten more complicated than necessary.
There are several separate issues.
1. Can a finaliser for a Haskell value be an arbitrary Haskell
computation? For GHC, yes. For Hugs, no (and for good reaso
| .NET is a different beast from other calling conventions in
| that you may want to compile Haskell ccalls to .NET
| intermediate language. In other words, it is about being
| able to implement ccall *on* .NET. Thus, the mix.
I think that is exactly the issue.
| At the moment, there doe
Manuel:
Do you agree that something in the FFI spec needs to be fixed?
And hence is on your to-do list?
(Just wanting to be sure this one doesn't fall off the radar.)
Simon
| -Original Message-
| From: Alastair Reid [mailto:[EMAIL PROTECTED]]
| Sent: 02 June 2002 18:03
| To: John Meac
Manuel
I've just had cause to look at the FFI spec. Here's an idea.
Since we have two productions, one for foreign import and one
for foreign export, let's separate the productions for "entity" into
"import_entity" and "export_entity". That way we don't have to
say "entity" in *both* 4.1 and
| > I'd say it has all the information you need - you were
| using it wrong.
|
| That's fine - but I think the FFI specification should state
| somewhere that the signature for a foreign import ccall
| should correspond to the type of the C call *after the C
| promotion rules have been applie
Manuel
Excellent stuff. Truly excellent.
Simon
* I have many small wording suggestions, but I'll just perform them
directly.
* Still uncontroversial, I found 3.2 to be in a funny order. I'll
re-organise it slightly.
* I found 4.1 pretty confusing, and I'm an unusually well-informed
reader
| (*) - ghc-5.00.2 give Int.sizeofInt{8,...} the type Int32;
| HDirect generated sources assume Word32 (as it should be). =>
| you may need to tweak the generated code in a select few
| places to make ghc-5.00.2 happy.
Sigbjorn:
Are you suggesting a change to the Int module? It would
be nic
| IMHO, this is not a very attractive solution. I'd prefer to
| complicate the ccall entity description slightly and go for
|
| foreign import ccall "myheader.h foo@mylib" foo :: Int -> Int
|
| Ie, we optionally allow the specification of the name of a
| dll. This is only a hint and ma
I'm trying to compile Haskell for the .NET platform.
For this platform it makes perfect sense to say
foreign import ccall "foo" foo :: Int -> Int
because you can make C calls on .NET as well as .NET calls.
The problem is that the call must specify which DLL the
function comes from. Th
| There is now a new revision of the definition at
|
| http://www.cse.unsw.edu.au/~chak/haskell/ffi.{ps.gz,tex}
Great stuff. It's looking good.
| > * You mention en passant that there's a new type CInt.
| Very good, but
| > the full set of types (and their operations) must be defined in th
| Is CCallable/CReturnable a useful part of the new
| multi-lingual ffi story (either in the ffi spec or in GHC's
| implementation of the ffi spec)?
Definitely not. It's a GHC implementation trick, that's all. Doesn't
belong in a spec
Simon
___
FFI
| Subject: FFI Report, CVS Id 1.4
|
| ...is available at
|
| http://www.cse.unsw.edu.au/~chak/haskell/ffi.{ps.gz,tex}
Good stuff, Manuel. Thanks!
Suggestion: would you like to add this to the CVS repository.
Then others can get hold of it, and even modify it (e.g. correct
typos, add example
| > Just to restate my position: I'm against *always* wrapping
| the header
| > file name in double quotes, unless
| >
| >#include "foo/bar.h"
| >
| > implies
| >
| >#include
| >
| > if the first form is not found.
|
| It does, but having "" and (ab)using it to mean <> would be
|
A process comment:
This FFI discussion is dragging. I really want to
get a conclusion because I want to implement it
for .NET. Manuel --- you are are Tzar. Whip us
into order!
(I don't think that any of the issues are do-or-die ones; i.e.
compromise is possible!)
| > > [...] What's
| Comments? We should really come to an agreement on the syntax soon...
Generally, I like it.
| An open point is the last case of the include production:
| Should we implicitly wrap double quotes around it or not? I
| don't really like such implicit things, but
|
| foreign import ccall "s
[Welcome back, Sigbjorn. Are you on the FFI mailing list?
Now you are back online you should be!]
| Export dynamic introduces a name, export static exports an
| existing name. For that reason putting this distinction in
| extent seems strange for me.
This seems like a good point to me.
| > language specific stuff inside the "..." string
| > language independent stuff outside
|
| But static/dynamic probably means different things, depending
| on the callconv.
I think it's arguable that static/dynamic should be inside the ext_ent
string. Indeed, one might use s
| * I'm not very happy with the fact that static/dynamic are
| only viewed
|as modifiers, like unsafe/safe. They almost completely change the
|meaning of a foreign declaration, including the typing rules. In my
|view, we have *5* different language constructs: `foreign import',
|
| In case you aren't aware of this, Windows DLL's by default, (actually
| always, as far as I know) use the stdcall (Pascal) calling convention.
|
| I personally hope that you won't drop anything which facilitates using
| Haskell under Windows.
Dead right. I wasn't proposing removing the funct
Is anyone actually specifying
stdcall
ccall
calling conventions in a foreign import? I want to pull it
out of GHC but I don't want to break anything.
Simon
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listin
One other thing. What did we decide about the 'calling convention'
field. I reckon it should vanish into the language-specific string,
or alternatively treat C as two languages that differ in their calling
convention.
No way C calling conventions deserve special treatment.
Simon
_
Manuel
| The FFI discussion seems to be completely stalled. Would
| you, as our Tsar, like to summarise the state of play, and
| re-invigorate it?
There was a bit of discussion, which led, I think to a simplification
of the library stuff. But we don't have a summary (even informal)
of the c
| I propose the following (basically my last proposal plus
| suggestions made by others):
|
| foreign import "gtk.h:foo" foo ::
|
| corresponds to a `#include "gtk.h"' and
|
| foreign import ":foo" foo ::
|
| corresponds to a `#include '. The former allows to
| have a custom `gtk.h' "ly
Manuel
The FFI discussion seems to be completely stalled. Would you,
as our Tsar, like to summarise the state of play, and re-invigorate it?
We don't have a plan at the moment; nor do we have even a draft FFI
document (the one you are going to write!). I'm concerned that
we'll just dribble on a
| I would also want to echo Simon's comment that the new hierarchical
| namespace and library proposal should go a long way to making the
| library situation better in the very near future. We are currently
| discussing a general layout and re-naming of the existing modules from
| hslibs. If Hug
| I am reasonably convinced by the need for an extensible
| attribute-style specification such as Marcin has been proposing.
I've been talking about the FFI stuff with Simon and Julian.
We aren't (yet, anyway) convinced by the need for anything
nearly as elaborate as what is now proposed.
Mos
What became of this suggestion of Sven's? Did we adopt it?
(While deprecating but not dropping Addr.)
Simon
| -Original Message-
| From: Sven Panne [mailto:[EMAIL PROTECTED]]
| Sent: 11 February 2001 16:01
| To: The Happy Bit Fiddlers
| Subject: Typing f.e.d.
|
|
| I have a small chan
I must say that I like Manuel's proposal below. I'm a bit alarmed
about the proliferation of features in the FFI, but Manuel's story
makes it seem more tractable. It's in the spirit of putting all
the language-specific info needed for a particular foreign import
into a single string.
The FFI
This looks plausible to me too --- but I agree with Alastair
that we should not remove support for Addr, including in f.e.d.
Backward compatibility is a pain, but lack of is a fast way
to lose customers.
Simon
| -Original Message-
| From: Sven Panne [mailto:[EMAIL PROTECTED]]
| Sent: 11
| For ("preferred" language, foreign language) pair, you define an
| "extrusion". This defines how to generate the appropriate code to
| interface with one foreign language in another.
All sounds very ingenious. Much of it, though, is quite Mercury
independent.
As you say, it's a way of maki
Here's a question from Koen that bears on the FFI.
Simon
-Original Message-
From: Koen Claessen [mailto:[EMAIL PROTECTED]]
Sent: 04 December 2000 12:55
To: Erik Meijer; Simon Peyton-Jones; Sigbjorn Finne
Subject: H/Direct
Hi H/Direct team,
I have been using H/Direct for quite a
| So, how about the following? Instead of the
|
| newtype Window = Window ForeignObj
|
| way of wrapping foreign ADTs that we used so far, should we
| use
|
| newtype WindowTag = WindowTag ()
| typeWindow= ForeignObj WindowTag
A fine idea. I accept what you say about ADTs, but
Dear foreigners
Simon and I noticed this morning that ForeignObj should
really be parameterised. The current type of newForeignObj is
newForeignObj :: Ptr a -> IO () -> IO ForeignObj
This immediately loses the type information on the Ptr!
Shouldn't it be
newForeignObj :: Ptr a -> IO () ->
I'm forwarding this to the FFI list in the hope that
someone can help Chris.
Simon
| -Original Message-
| From: Chris Ryder [mailto:[EMAIL PROTECTED]]
| Sent: 11 August 2000 12:05
| To: Simon Peyton-Jones
| Subject: HDirect + String Arrays.
|
|
| Hi,
|
| I'm trying t
57 matches
Mail list logo
