Tue, 20 Feb 2001 18:54:05 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> Since I believe backward compatibility is very important, would
> anyone like to either modify Marcin's proposal, or make a new
> concrete proposal that is perhaps slightly more conservative but
> still achieves our
[EMAIL PROTECTED] wrote,
> I think we're all agreed now on the desirability of tweaking the FFI
> to permit
>
> (a) arbitrary new foreign languages to be added;
>
> (b) the "foreignname" specifier to be (potentially) richer, depending
> on the particular foreign language in question;
Wed, 21 Feb 2001 16:01:48 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> So, how about the following.
I must admit that I like my own proposal better :-)
> So, as Marcin pointed out, the only use for a library object
> spec for ccall is so that interpreters know which handle to
>
I've kept pretty quiet on this issue before, because I didn't have a
strong view. Now I'm concerned that some of the suggestions people are
making would take the design in the wrong direction.
* specifying libraries in the source isn't the right way to
go. Library names change indepen
> So, as Marcin pointed out, the only use for a library object
> spec for ccall is so that interpreters know which handle to
> pass to dlsym().
This may be the only use but I think it's a very important use.
> I am not too fond of the idea that the interpreter has to try
> a dlsym() on all libra
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> I've kept pretty quiet on this issue before, because I didn't have a
> strong view. Now I'm concerned that some of the suggestions people are
> making would take the design in the wrong direction.
>
>* specifying libraries in the source isn't th
>* specifying libraries in the source isn't the right way to
> go. Library names change independently of APIs, and can be
> platform-specific.
I like the high level goal this is heading towards and was in complete
agreement with implementing it in rules like this until I real
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> ps Just as a general remark on language design...
>
> User defined defaults are really tempting to add (my component programming
> language had them briefly and I am under constant pressure to add them back in)
> but they are kinda messy because:
>
>
The first time I read this syntax, I misinterpreted it.
I think my misinterpretation might be interesting so I'll give it below in case
anyone else likes it.
> foreign library C"" "-lcurses"
> foreign library java "blah" "blah"
>
> foreign import C"curses_function" cf ::
Wed, 21 Feb 2001 15:51:35 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> User defined defaults are really tempting to add (my component
> programming language had them briefly and I am under constant
> pressure to add them back in) but they are kinda messy because:
They are sometimes bessy, b
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> > So, as Marcin pointed out, the only use for a library object
> > spec for ccall is so that interpreters know which handle to
> > pass to dlsym().
>
> This may be the only use but I think it's a very important use.
>
> > I am not too fond of the ide
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> >* specifying libraries in the source isn't the right way to
> > go. Library names change independently of APIs, and can be
> > platform-specific.
>
> I like the high level goal this is heading towards and was in complete
> agreement wi
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
> >* specifying libraries in the source isn't the right way to
> > go. Library names change independently of APIs, and can be
> > platform-specific.
>
> I like the high level goal this is heading towards and was in complete
> agreement with implementing it in rules like this until
On Thu, 22 Feb 2001, Simon Marlow wrote:
> The package spec format is designed to be used with "read" (i.e. it's
> Haskell syntax), so Hugs could just read it using its built-in parser.
The format should be extensible, i.e. adding future fields should not
break old code which does not use these
On Thu, 22 Feb 2001, Simon Peyton-Jones wrote:
> I must say that I like Manuel's proposal below.
Please don't force to put header names in *every* foreign declaration!
For header names which are detected at configure time, we would have to
write forwarding headers in separate files and install
> On Thu, 22 Feb 2001, Simon Marlow wrote:
>
> > The package spec format is designed to be used with "read"
> (i.e. it's
> > Haskell syntax), so Hugs could just read it using its
> built-in parser.
>
> The format should be extensible, i.e. adding future fields should not
> break old code which
> foreign import ccall ":gtk_window_new"
> windowNew :: CInt -> IO (Ptr Window)
>
> If the <.> are omitted in the include specification, it
> corresponds to an #include"...".
Don't forget you might need multiple includes, eg. &
for socket(), and ordering is important. Multiple
include
Thu, 22 Feb 2001 12:08:22 -, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Don't forget you might need multiple includes, eg. &
> for socket(), and ordering is important.
Easy with my proposal:
foreign import "socket" include "" include ""
socket_c :: CInt -> CInt -> CInt -> IO CInt
incl
> Marcin just pointed out that you can use dlopen() in a way
> that it finds symbols without a library name. That should
> do, I think.
Note that finding a marginally easier way to do the lookup doesn't address my
concern that this undirected search will cause maintenance and porting problems
by
Thu, 22 Feb 2001 11:27:20 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> In fact, I expect that having dlopen do a search through the
> libraries that it thinks are relevant instead of Hugs performing a
> search through the list of libraries that it knows to be relevant
> probably makes things
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
>
> > >* specifying libraries in the source isn't the right way to
> > > go. Library names change independently of APIs, and can be
> > > platform-specific.
> >
> > I like the high level goal this is heading towards and was in complete
>
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> > Marcin just pointed out that you can use dlopen() in a way
> > that it finds symbols without a library name. That should
> > do, I think.
>
> Note that finding a marginally easier way to do the lookup doesn't address my
> concern that this undirect
On 22-Feb-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Thu, 22 Feb 2001 12:08:22 -, Simon Marlow <[EMAIL PROTECTED]> pisze:
>
> > Don't forget you might need multiple includes, eg. &
> > for socket(), and ordering is important.
>
> Easy with my proposal:
>
> foreign import
On Fri, 23 Feb 2001, Fergus Henderson wrote:
> OK, now how about things where you need to #define symbols before
> including the header file?
Choose one:
1. Write a forwarding header which #defines and #includes.
2. Use compiler-specific switches to get #defines (-D and -optc-D in ghc).
3. Exten
On Fri, 23 Feb 2001, Simon Marlow wrote:
> I agree. Would it be fixed by just #including Stg.h after any
> -#includes, or would that create more problems?
If HsFFI.h indirectly includes system headers, then I'm afraid it's
not enough for hsc2hs, which automatically includes HsFFI.h before
user-
> On Fri, 23 Feb 2001, Fergus Henderson wrote:
>
> > OK, now how about things where you need to #define symbols before
> > including the header file?
>
> Choose one:
> 1. Write a forwarding header which #defines and #includes.
> 2. Use compiler-specific switches to get #defines (-D and
> -optc
On 23-Feb-2001, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> I agree. Would it be fixed by just #including Stg.h after any
> -#includes, or would that create more problems?
ghc uses gcc global register variables on x86, doesn't it?
If so, they need to be declared first thing, before any functio
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote,
> On Fri, 23 Feb 2001, Fergus Henderson wrote:
>
> > OK, now how about things where you need to #define symbols before
> > including the header file?
>
> Choose one:
> 1. Write a forwarding header which #defines and #includes.
That's exact
29 matches
Mail list logo
