On 01-Jun-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Fergus Henderson <[EMAIL PROTECTED]> wrote,
>
> > I would be fine to say that some other name, e.g. `c', means that.
> > But `ccall' already has an existing meaning, and it would be
> > terribly confusing if e.g. MSVC and GNU C
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 31-May-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> > Fergus Henderson <[EMAIL PROTECTED]> wrote,
> > > Making the semantics of a particular construct implementation-dependent is
> > > a good thing if the semantics that you want are
Michael Weber <[EMAIL PROTECTED]> wrote,
> On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote:
> > So, it all boils down to the question of whether this
> > (probably rare) case justifies the (not very large) extra
> > complexity of allowing header file names enclosed in <>.
>
On 31-May-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Fergus Henderson <[EMAIL PROTECTED]> wrote,
> > Making the semantics of a particular construct implementation-dependent is
> > a good thing if the semantics that you want are implementation-dependent.
> > Doing this allows the c
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 29-May-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> > Sven Panne <[EMAIL PROTECTED]> wrote,
> >
> > > Fergus Henderson wrote:
> > >
> > > > The calling convention should not necessarily default to 'ccall'.
> > > > That would not be
> No, it does not necessarily require <>. If you write
>
> #include "foo.h"
>
> the C compiler will *also* look in all places where it would
> look for
>
> #include
>
> The only case where <> is needed is where there are two
> versions of `foo.h'. One where only "foo.h" will find it
>
On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote:
> So, it all boils down to the question of whether this
> (probably rare) case justifies the (not very large) extra
> complexity of allowing header file names enclosed in <>.
>
> I am happy either way, but slightly tend to th
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> > * But all of these things can be done in a C header file. So all we
> > *need*
> > is the ability to include a single header file, gotten from the
> > current directory
> >
> > foo.h
>
> We don't want to force you to write a wrapper header fil
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote,
> So why not keep it simple? Just one header file, no directories, no
> search
> path, no <> brackets. Any of that stuff can be done in the file you
> #include
Just a note: Currently, we allow directories (at least that
is how I understand the s
> * But all of these things can be done in a C header file. So all we
> *need*
> is the ability to include a single header file, gotten from the
> current directory
>
> foo.h
We don't want to force you to write a wrapper header file in the case
where it would just contain a single #inclu
| > 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
|
Tue, 29 May 2001 10:37:54 +0200, Sven Panne <[EMAIL PROTECTED]> pisze:
> 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
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 29-May-2001, Sven Panne <[EMAIL PROTECTED]> wrote:
> > 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.
Sven Panne <[EMAIL PROTECTED]> 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
Fergus Henderson wrote:
> On 29-May-2001, Sven Panne <[EMAIL PROTECTED]> 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 a
On 29-May-2001, Sven Panne <[EMAIL PROTECTED]> wrote:
> 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.
> I'm not sure about this, although it's guaranteed
> th
On 29-May-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Sven Panne <[EMAIL PROTECTED]> wrote,
>
> > Fergus Henderson wrote:
> >
> > > The calling convention should not necessarily default to 'ccall'.
> > > That would not be appropriate for all implementations.
> >
> > Granted.
> >
"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 correctl
Sven Panne <[EMAIL PROTECTED]> 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
Sven Panne <[EMAIL PROTECTED]> wrote,
> Fergus Henderson wrote:
>
> > The calling convention should not necessarily default to 'ccall'.
> > That would not be appropriate for all implementations.
>
> Granted.
>
> > Instead, I think the default calling convention should be
> > implementation-dep
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-ex
> So let's simply say: The contents of the include part of
> extent are implictly
> wrapped into double quotes iff they don't start with '<' or
> '"', and no ".h"
> is appended. Easy rule, doesn't mix concepts, and is readable:
>
> foreign import ccall "static !myproc myinclude.h" myProc ::
Fergus Henderson wrote:
> The calling convention should not necessarily default to 'ccall'.
> That would not be appropriate for all implementations.
Granted.
> Instead, I think the default calling convention should be
> implementation-dependent.
Hmmm, this would make the semantics of the sourc
Simon Peyton-Jones wrote:
> [...] I'd go for automatically adding quotes. Acutally, I'd automatically
> add a '.h' too. Reason: you are really specifying the assembly or package
> where the function comes from, and that might be useful for linking as
> well as includes. If the package was call
>* Silly combinations like "an unsafe label" or
> "a dynamic import with a given C-name" don't exist.
But now we have all new silly combinations, like
foreign export "dynexp" foo :: ...
and
foreign export "dynimp" foo ::
and
foreign export "&foo" foo :: ...
| 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
On 12-May-2001, Sven Panne <[EMAIL PROTECTED]> wrote:
> callconv : -- defaulting to 'ccall'
> | 'ccall'
> | 'stdcall'
> | 'cplusplus'
> | 'jvm'
> | 'dotnet'
The calling convention should not necessarily default to 'ccall'.
That would not be
It's weekend and so it's time for a new syntax proposal... :-)
After the recent clarification of the role of "import" and "export" and
a few other suggestions, here's my next shot:
topdecl : 'foreign' impexp callconv exte
28 matches
Mail list logo
