Is it just me or does the FFI spec not explain what whitespace is needed between the components of the ccall impent? 4.1.1 is the obvious place for it to be. In particular, even after reading between the lines, questions like "are multiple spaces between static and fname allowed", "is a space between & and cid allowed (or required)" and "are tabs allowed" seem to remain unanswered. Thanks Ian
Ian Lynagh <igloo@earth.li> writes:
Is it just me or does the FFI spec not explain what whitespace is needed between the components of the ccall impent? 4.1.1 is the obvious place for it to be. In particular, even after reading between the lines, questions like "are multiple spaces between static and fname allowed", "is a space between & and cid allowed (or required)" and "are tabs allowed" seem to remain unanswered.
I remember wondering this when I implemented it in Hugs. My understanding of the spec is that the impents contain a sequence of tokens separated by whitespace. IIRC, I came to this belief not by finding something which spells it out but by deciding that any other interpretation made it impossible to parse the examples in the report using the grammar in the report. If it isn't spelled out explicitly already, it would be good to do that. In the meantime, I believe the story is that multiple spaces are allowed, tabs are allowed and any two tokens may be separated by spaces. If you catch Hugs behaving otherwise, I'll fix it. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
On Tue, Nov 05, 2002 at 09:53:52PM +0000, Alastair Reid wrote:
If it isn't spelled out explicitly already, it would be good to do that.
How about something like this? Maximal munch applies. token -> special | "&" | fname | cid | whitespace special -> "static" | "dynamic" | "wrapper" fname -> ... ".h" (... as I don't have [3] handy) cid -> ... excluding special (... as I don't have [3] handy) whitespace -> { ' ' | '\t' } ...strip whitespace tokens... ccall_impent -> [ "static" ] [ fname ] [ & ] [ cid | special ] | "dynamic" | "wrapper" Thanks Ian
token -> special | "&" | fname | cid | whitespace special -> "static" | "dynamic" | "wrapper" fname -> ... ".h" (... as I don't have [3] handy) cid -> ... excluding special (... as I don't have [3] handy) whitespace -> { ' ' | '\t' }
For what it's worth, Hugs uses 'any non-empty sequence of non-space characters' where you use '...' and uses different but probably equivalent contortions where you use specials. The practical difference from this is that Hugs would probably let you foreign import things called 'foo[42]' if you wanted. I guess this is not what the ffi report intends :-) -- Alastair
On Wed, Nov 06, 2002 at 12:04:22AM +0000, Ian Lynagh wrote:
On Tue, Nov 05, 2002 at 09:53:52PM +0000, Alastair Reid wrote:
If it isn't spelled out explicitly already, it would be good to do that.
How about something like this?
Maximal munch applies.
token -> special | "&" | fname | cid | whitespace special -> "static" | "dynamic" | "wrapper" fname -> ... ".h" (... as I don't have [3] handy) cid -> ... excluding special (... as I don't have [3] handy)
[3] tells me that cid is [_a-zA-Z][_a-zA-Z0-9]* (which I think should be in the FFI spec itself too) but I can't find a definition of fname in it. The C99 spec allows a lot of stuff I don't think makes sense after #include, but a header file is specified by either "[^"\n]+" or <[^>\n]+>. This only seems sensible if the "" or <> are also in the impent string which is not the case in the examples. Can someone clarify the intention for me please (and preferably also do so in the FFI spec)? Thanks Ian
Ian Lynagh <igloo@earth.li> wrote,
On Wed, Nov 06, 2002 at 12:04:22AM +0000, Ian Lynagh wrote:
On Tue, Nov 05, 2002 at 09:53:52PM +0000, Alastair Reid wrote:
If it isn't spelled out explicitly already, it would be good to do that.
How about something like this?
Maximal munch applies.
token -> special | "&" | fname | cid | whitespace special -> "static" | "dynamic" | "wrapper" fname -> ... ".h" (... as I don't have [3] handy) cid -> ... excluding special (... as I don't have [3] handy)
[3] tells me that cid is [_a-zA-Z][_a-zA-Z0-9]* (which I think should be in the FFI spec itself too) but I can't find a definition of fname in it.
The C99 spec allows a lot of stuff I don't think makes sense after #include, but a header file is specified by either "[^"\n]+" or <[^>\n]+>. This only seems sensible if the "" or <> are also in the impent string which is not the case in the examples.
Can someone clarify the intention for me please (and preferably also do so in the FFI spec)?
I have now included a formal definition of the two nonterminals in Section 2 (Lexical Structure) of the FFI report. I append the text below. cid is defined to be [_a-zA-Z][_a-zA-Z0-9]* (as you wrote above). However, chname (which now replaces fname) produces only a subset of those lexemes admitted by C99. I don't think there would be much point in trying to exactly mirror C99, as more complicated header file arrangements require a special purpose C header file for Haskell bindings anyway. Cheers, Manuel -=- To refer to objects of an external C context, we introduce the following phrases: % \begin{grammar} \grule[C header filename]{chname}{% \grepeat{\gnterm{chchar}} .\ h} \grule[C identifier]{cid}{% \gnterm{letter} \grepeat{\gnterm{letter} \galt\ \gnterm{ascDigit}}} \grule{chchar}{% \gnterm{letter} \galt\ \gnterm{ascSymbol}\gminus{\&}} \grule{letter}{% \gnterm{ascSmall} \galt\ \gnterm{ascLarge} \galt\ \_} \end{grammar} % The range of lexemes that are admissible for \gnterm{chname} is a subset of those permitted as arguments to the \code{\#{}include} directive in C. In particular, a file name \gnterm{chname} must end in the suffix \code{.h}. The lexemes produced by \gnterm{cid} coincide with those allowed as C identifiers, as specified in~\cite{C}.
participants (3)
-
Alastair Reid -
Ian Lynagh -
Manuel M T Chakravarty