Simon Marlow wrote:
But now we have all new silly combinations, like
foreign export "dynexp" foo :: ... and foreign export "dynimp" foo :: .... and foreign export "&foo" foo :: ...
the extent field needs to be separated into import-extent and export-extent, I think.
That's exactly what I had in mind.
Can we make the "static" optional? It wouldn't introduce any ambiguity, and it would save characters in the common case.
Well, it *would* introduce ambiguity (or we steal some names from C land): foreign import ccall "dynimp" dynimp :: ...
I like '&', but I'm less sure about '!' - this feels like we're getting a little too cryptic.
The reason for the "cryptic" '!' is avoiding ambiguity. Let's assume we introduce a modifier which looks like a valid C identifier. What should the following mean then? foreign import ccall "static foo bar" baz :: ... Is it an import of the C entity "foo" with the #include file "bar", or is it an import of the C entity "bar" with modifier "foo"? An alternative would be to make the include part somehow distinguishable from a C identifier, but I'm not sure if this would be less cryptical. And '!' is not that bad IMHO, the connotation "DANGER" should be obvious, and a single character doesn't clutter up the extent. *sigh* Syntax wars again... :-} Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
Sven Panne <Sven_Panne@BetaResearch.de> wrote,
I like '&', but I'm less sure about '!' - this feels like we're getting a little too cryptic.
The reason for the "cryptic" '!' is avoiding ambiguity. Let's assume we introduce a modifier which looks like a valid C identifier. What should the following mean then?
foreign import ccall "static foo bar" baz :: ...
Is it an import of the C entity "foo" with the #include file "bar", or is it an import of the C entity "bar" with modifier "foo"? An alternative would be to make the include part somehow distinguishable from a C identifier, but I'm not sure if this would be less cryptical. And '!' is not that bad IMHO, the connotation "DANGER" should be obvious, and a single character doesn't clutter up the extent.
Now that we require the include file to have the suffix `.h', the declaration should be unambigious without '!'. Or do I overlook anything? Manuel
"Manuel M. T. Chakravarty" wrote:
Now that we require the include file to have the suffix `.h', the declaration should be unambigious without '!'. Or do I overlook anything?
To be exact, we don't require a `.h' suffix, we just don't add `.h' stealthily. And if I read the ISO C spec correctly, this suffix is not required by it, so things are still ambiguous. But again, other people on this list would probably say: You have to write your own header file anyway, so you can give it a name including the `.h' suffix. :-P Just to restate my position: I'm against *always* wrapping the header file name in double quotes, unless #include "foo/bar.h" implies #include <foo/bar.h> if the first form is not found. I'm not sure about this, although it's guaranteed the other way round IIRC. It's a little bit awkward being forced to write a custom header when a system supplied one is the only thing one wants. But this is not a topic of paramount importance, so I'll probably surrender if there's no support for my position... :´-( ;-) Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
On 29-May-2001, Sven Panne <Sven_Panne@BetaResearch.de> wrote:
I'm against *always* wrapping the header file name in double quotes, unless
#include "foo/bar.h"
implies
#include <foo/bar.h>
if the first form is not found.
It does.
I'm not sure about this, although it's guaranteed the other way round IIRC.
You recall incorrectly. For <...>, the search is entirely implementation-defined [ISO C99 6.10.2#2]. For "...", the initial search is implementation-defined, but it if fails, then the search is retried as if for <...> [ISO C99 6.10.2#3]: Cheers, Fergus. ISO C99 6.10.2#2: | [#2] A preprocessing directive of the form | | # include <h-char-sequence> new-line | | searches a sequence of implementation-defined places for a | header identified uniquely by the specified sequence between | the < and > delimiters, and causes the replacement of that | directive by the entire contents of the header. How the | places are specified or the header identified is | implementation-defined. ISO C99 6.10.2#3: | [#3] A preprocessing directive of the form | | # include "q-char-sequence" new-line | | causes the replacement of that directive by the entire | contents of the source file identified by the specified | sequence between the " delimiters. The named source file is | searched for in an implementation-defined manner. If this | search is not supported, or if the search fails, the | directive is reprocessed as if it read | | # include <h-char-sequence> new-line | | with the identical contained sequence (including > | characters, if any) from the original directive. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson wrote:
On 29-May-2001, Sven Panne <Sven_Panne@BetaResearch.de> wrote:
[ "" implies <> ]
It does.
I'm not sure about this, although it's guaranteed the other way round IIRC.
You recall incorrectly. [...]
Well, at least I had a 50-50 chance! :-} OK, then let's auto-wrap... Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 29-May-2001, Sven Panne <Sven_Panne@BetaResearch.de> wrote:
I'm against *always* wrapping the header file name in double quotes, unless
#include "foo/bar.h"
implies
#include <foo/bar.h>
if the first form is not found.
It does.
I'm not sure about this, although it's guaranteed the other way round IIRC.
You recall incorrectly.
For <...>, the search is entirely implementation-defined [ISO C99 6.10.2#2]. For "...", the initial search is implementation-defined, but it if fails, then the search is retried as if for <...> [ISO C99 6.10.2#3]:
Oh, great - I should have read this message before replying to Sven's. Then, this issue should be settled. Thanks, Manuel
Sven Panne <Sven_Panne@BetaResearch.de> wrote,
"Manuel M. T. Chakravarty" wrote:
Now that we require the include file to have the suffix `.h', the declaration should be unambigious without '!'. Or do I overlook anything?
To be exact, we don't require a `.h' suffix, we just don't add `.h' stealthily. And if I read the ISO C spec correctly, this suffix is not required by it, so things are still ambiguous. But again, other people on this list would probably say: You have to write your own header file anyway, so you can give it a name including the `.h' suffix. :-P
Other people? Me! Requiring a .h prefix solves a problem and doesn't really complicated anything for users.
Just to restate my position: I'm against *always* wrapping the header file name in double quotes, unless
#include "foo/bar.h"
implies
#include <foo/bar.h>
if the first form is not found. I'm not sure about this, although it's guaranteed the other way round IIRC. It's a little bit awkward being forced to write a custom header when a system supplied one is the only thing one wants. But this is not a topic of paramount importance, so I'll probably surrender if there's no support for my position... :´-( ;-)
The if the first form is not found is not feasible, I think, because the Haskell compiler will have to commit to one when generating C code. I think, it is awkward to quote the quotes, but if there is a general feeling that we should allow optional '<' '>' around the header files to mean `use the system search path', that's ok with me. Cheers, Manuel
participants (3)
-
Fergus Henderson -
Manuel M. T. Chakravarty -
Sven Panne