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, but
"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 idea that the
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
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
If we want to rule cpp as out of bounds (a very worthwhile
but difficult goal),
then we need to think about how to avoid conditional compilation too.
I think the goal is not to avoid the use of cpp, but rather to avoid
mentioning it in the spec. In practice, many people will be using cpp
foreign import ccall "gtk/gtk.h: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. sys/types.h
sys/socket.h for socket(), and ordering is
Thu, 22 Feb 2001 12:08:22 -, Simon Marlow [EMAIL PROTECTED] pisze:
Don't forget you might need multiple includes, eg. sys/types.h
sys/socket.h for socket(), and ordering is important.
Easy with my proposal:
foreign import "socket" include "sys/types.h" include "sys/socket.h"
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
While on the subject of preprocessors, I thought I'd mention a need I've found
in distributing tools like Knit where the intended audience isn't expected to:
1) Care either way about it being implemented in Haskell
2) Have any desire to spend half a day installing lots of Haskell-related tools
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
Thu, 22 Feb 2001 11:41:20 -0700, Alastair Reid [EMAIL PROTECTED] pisze:
2) Have any desire to spend half a day installing lots of
Haskell-related tools (greencard, c2hs, happy, etc.) on their
machine before they can try out my tool. Getting them to install
a GHC binary is about the
hsc2hs is in ghc-4.11.
Did I miss the last 3 releases? I'm still stuck with something between 4.08.1
and 4.08.2 waiting for a debian package and freebsd port to appear for 4.08.2.
:-)
[Serious content of which is that I'm absolutely _not_ interested in subjecting
users of my tools to the
"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
agreement with
"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 undirected search
14 matches
Mail list logo
