Johannes Waldmann wrote:
Brian Hulley wrote:
In the long term, Haskell needs a better module system IMHO [...]
I agree with the symptoms that were described, but I draw a different
conclusion.
We don't need to change the language - we need better tools (IDEs)
that operate not at the textual
Ian Lynagh wrote:
On Fri, Jan 04, 2008 at 08:34:22AM +, Simon Peyton-Jones wrote:
| 4. A more radical change would be introducing hierarchical modules.
It's a pity that GHC.* is already used in base. I'm not sure what the
best thing to do is in the short term.
How about
Brian Hulley wrote:
Ian Lynagh wrote:
On Fri, Jan 04, 2008 at 08:34:22AM +, Simon Peyton-Jones wrote:
| 4. A more radical change would be introducing hierarchical modules.
Sorry I quoted what Simon PJ replied to not what he wrote so I should
have written:
Ian Lynagh wrote
Stefan O'Rear wrote:
On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote:
... I was
wondering if there are any plans to remove the GNU mp library from the
runtime
... http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
Thanks for the link.
... although the program
Duncan Coutts wrote:
On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley wrote:
.. For example, the LGPL requires you to give permission to people
to reverse engineer your application... thus it may
not even be possible for me to comply with the terms of the LGPL.
From the LGPL v3
Hi,
I know this is a sensitive issue and I absolutely don't want to start
any kind of discussion about the merits or otherwise of LGPL, but I was
wondering if there are any plans to remove the GNU mp library from the
runtime so that it would be possible to distribute native executables
Christian Maeder wrote:
Hi,
I would like haskell to accept the following (currently illegal)
expressions as syntactically valid prefix applications:
f = id \ _ - []
g = id let x = [] in x
h = id case [] of [] - []
i = id do []
j = id if True then [] else []
The rational is that expressions
skaller wrote:
The key thing for the building portability is that the C and C++
compilers are represented by Python classes. There is a pre-programmed
class for gcc, and another for MSVC++.
I suggest (for GHC) a Haskell class with instances for the different
combinations of
compilers and
Brandon Michael Moore wrote:
On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote:
I believe it is because a stack cannot be garbage collected, and must be
traversed as roots for every garbage collection. I don't think there are
any issues with a huge stack per se, but it does not
Neil Mitchell wrote:
Hi,
I've prepared a GHC 6.6.1 Windows installer. Before I offer this up as
an official installer, could people please test it?
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows-test1.exe
Thanks Neil,
This works perfectly!
Best regards, Brian.
Thanks to everyone for sending me info on how to install ghc6.6 on
Ubuntu. The way I used eventually was one sent to me off list and uses
the generic i86 linux at
http://www.haskell.org/ghc/download_ghc_66.html#x86linux
The exact steps I used after downloading the tarball at the above URL to
my
Simon Peyton-Jones wrote:
I don't think there is any reason in principle why GHC can't generate
DLLs that just work, but plainly it's deficient at the moment.
The fundamental reason is that the DLL mechanism itself doesn't allow
initialization/ shutdown do be hidden from the user of a DLL,
SevenThunders wrote:
Brian Hulley wrote:
SevenThunders wrote:
DllMain
if (reason == DLL_PROCESS_DETACH) {
shutdownHaskell();
return TRUE;
}
The above *may* be the problem: it is unsafe to do anything in
DllMain that...
Instead of trying to start/shutdown Haskell from DllMain
Hi,
For a 3d graphics library, I'd like to have a 4x4 matrix of floats which I
can pass from Haskell to C without having to copy all 16 floats each time,
something like:
data Mat44f = Mat44f Float# Float# ... Float#
foreign import ccall c_setWorldTransform :: Ptr Mat44f - IO ()
Bulat Ziganshin wrote:
Hello Brian,
Sunday, November 26, 2006, 5:34:51 PM, you wrote:
For a 3d graphics library, I'd like to have a 4x4 matrix of floats
which I can pass from Haskell to C without having to copy all 16
floats each time, something like:
Brian Hulley wrote:
Hi,
Has anyone else come across this crash with ghc 6.6 on Windows?
The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0).
First-chance exception at 0x7c90eb74 in main.exe: 0xC008:
An invalid HANDLE was specified.
Unhandled exception at 0x7c90eb74
Hi,
Has anyone else come across this crash with ghc 6.6 on Windows?
The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0).
First-chance exception at 0x7c90eb74 in main.exe: 0xC008:
An invalid HANDLE was specified.
Unhandled exception at 0x7c90eb74 in main.exe:
Mirko Rahn wrote:
In ghc-6.4.2 this works as expected, but ghc-6.5.20061001 says
B.hs:40:44:
A pattern type signature cannot bind scoped type variables `s'
unless the pattern has a rigid type context
Why are the rules for lexically scoped type variables so complicated?
Could we not
Ross Paterson wrote:
data T = forall a. MkT [a]
k :: T - T
k (forall a. MkT [t]) = MkT t3
where
t3::[a] = [t,t,t]
What was wrong with the example in the documentation?
k :: T - T
k (MkT [t::a]) = MkT t3
where
t3::[a] = [t,t,t]
The type of (t) is (a) -
Brian Hulley wrote:
Ross Paterson wrote:
data T = forall a. MkT [a]
k :: T - T
k (forall a. MkT [t]) = MkT t3
where
t3::[a] = [t,t,t]
What was wrong with the example in the documentation?
k :: T - T
k (MkT [t::a]) = MkT t3
where
t3::[a] = [t,t,t
Esa Ilari Vuokko wrote:
Hi,
My use case is in Win32-package, where we simply call a FFI
imported call and on failures call GetLastError to get extended
error code. GetLastError of course only works on same OS thread
and contains sensible results only before next Windows API call.
It's much
Simon Marlow wrote:
If the base package is upgraded without also replacing the other
libraries... this is where it gets really tricky. Binary
dependencies between library code tend to be very deep due to
cross-module inlining and optimisations, so right now the chances of
upgrading base without
Simon Marlow wrote:
So here's what I propose:
- A GHC source tree will contain a core set of packages. This is
what you will get if you download ghc-6.6-src.tar.bz2, or do
sh darcs-all get in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm,
Bulat Ziganshin wrote:
Hello Brian,
Tuesday, August 22, 2006, 5:52:29 PM, you wrote:
sh darcs-all get in a darcs repo. The core packages are:
base, haskell98, template-haskell, readline, stm,
Cabal, unix, Win32
Should mtl not also be included here too as it is a
Hi,
I'm starting to explore Template Haskell and I've got the following program:
-- almost directly from Template meta-programming in Haskell paper
module Duma.Template.Test
( Format(..)
, printf
) where
import Language.Haskell.TH
Bulat Ziganshin wrote:
Hello Brian,
Monday, August 21, 2006, 6:34:06 PM, you wrote:
-- almost directly from Template meta-programming in
Haskell paper
i should warn you that some TH details was changed in 6.4. these
changes described in second TH paper and afair, reifying is among
Arie Peterson wrote:
I seem to remember that 'reify' cannot be run in the IO monad. IIRC
ghci gives a nice error message saying this, so perhaps you can try
to execute 'main' from within ghci to corroborate my suspicion.
Yes you're right - ghci gives the error:
Can't do `reify' in the IO
Bulat Ziganshin wrote:
as you can see, it don't supports reification, recovery and
information about currently compiled module just because there is no
such information when program runs. and of course, you can't add new
fields or new functions at run-time. isntead typical technique is:
Hi,
I'm wondering if it is more efficient to pattern match against the
components of a record instead of using the field functions, though I'd
prefer to just use the field functions.
For example, if I write:
data R = R {_xRef :: !(IORef Int)}
foo :: Int - R - IO ()
foo i R{_xRef =
this:
-- |
-- Module: Prime.IORef
-- Author: Brian Hulley
-- License: Public Domain
--
-- Lifts (most of) Data.IORef to any MonadIO
-- This module should be used qualified so we can avoid
-- writing IORef everywhere
module Prime.IORef
( T
Bulat Ziganshin wrote:
btw, if you want beter efficiency, you may use unboxed
references (http://haskell.org/haskellwiki/Library/ArrayRef)
Thanks for the pointer to your ArrayRef library. I've downloaded it and it
will be very useful - its extremely neat that the fact that something is
Florian Weimer wrote:
This is the offending part:
* 3. All advertising materials mentioning features or use of this
software
*must display the following acknowledgement:
*This product includes cryptographic software written by
* Eric Young ([EMAIL PROTECTED])
*The word
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license is problematic for users of GHC
(it prohibits static linking of
Esa Ilari Vuokko wrote:
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Duncan Coutts wrote:
On Sun, 2006-07-30 at 11:53 +0100, Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum
library, BN. I have two questions concerning this:
From the ticket, this looks very scary:
but its LGPL license
Esa Ilari Vuokko wrote:
Hi Brian,
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote:
Still, a slight problem is that since there is one object file per
source file, the names of the object files give quite a lot of
information away about the structure of the program especially when
[EMAIL PROTECTED] wrote:
Brian,
The standard method of skirting the LGPL restriction and saving your
source code is to link dynamically in a separate step and then
distribute your program along with the dynamically linked LGPL'd
library. Compile with ghc -c (or with ghc -c -odir 'separate
Duncan Coutts wrote:
On Sun, 2006-07-30 at 17:33 +0100, Brian Hulley wrote:
I think the main problem here is that I'm using Windows, so there is
no way to dynamically link with the runtime libraries - the GHC
implementations available for Windows only produce statically linked
executables
Peter Tanski wrote:
[snip]
The advantage to free software is
that, like the Haskell language, you get to use some of the most
advanced programming available. So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell
Neil Mitchell wrote:
Hi Brian,
So here I am, trying to figure out
what I can do to help GHC, since right now GHC is the only actively
maintained, current Haskell compiler available.
nhc98 and Yhc are both compilers which are actively maintained.
(In any case, nhc98
uses GMP as well, so
Duncan Coutts wrote:
On Sun, 2006-07-30 at 20:02 +0100, Brian Hulley wrote:
[snip]
app. When the app runs, Windows will first look in the app's
directory and therefore find the correct set of DLLs.
Yes, it's fine for distributing applications but not much good for
libraries.
Hi Duncan
Simon Peyton-Jones wrote:
Brian
Actually re-reading my post I realised I may have sounded a bit
negative about the hard work you'd done to collate the various
responses to form the wiki proposal - my apologies
Thanks -- email is a fragile medium!
I've followed your suggestion and made a
Simon Peyton-Jones wrote:
1) Qualified names:
import A.B.C( T1 ) from foo
import A.B.C( T2 ) from bar
type S = A.B.C.T1 - A.B.C.T2
I'd suggest that the above should give a compiler error that A.B.C is
ambiguous (as a qualifier), rather than allowing T1 to disambiguate
it, because
Brian Hulley wrote:
Simon Peyton-Jones wrote:
compulsory. Perhaps you could improve the wording to make it more
unambiguous?
Indeed, if we've converged, would you like to fold into our draft
whatever you think is useful from yours?
[snip]
Therefore it seems best to just leave them
Simon Peyton-Jones wrote:
So instead of just taking this simple solution, the wiki proposal is
instead destroying the beauty of the per-package namespace idea by
incorporating into it the existing shared namespaces with their
attendant problems, instead of just letting the existing messy
system
Simon Peyton-Jones wrote:
Concerning other mail on this subject, which has been v useful, I've
revised the Wiki page (substantially) to take it into account.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Further input (either by email or by adding material to the Wiki)
would be welcome.
Brian Hulley wrote:
Simon Peyton-Jones wrote:
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
I think the following is a non-question:
An open question: if A.B.C is in the package being compiled,
and in an exposed package, and you say import A.B.C,
do you get an error
Marc Weber wrote:
I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module
Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we
might actually do so for GHC 6.6. Your message provoked us to write
up the design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads;
Brian Hulley wrote:
import Gtk/Widget.Button -- instead of grafting
In all cases I think it would be an absolute disaster to allow
modules to be imported without an explicit package id because this
would defeat the whole purpose of having a simple per-package
namespace for modules
Simon Marlow wrote:
Brian Hulley wrote:
I'm wondering if the monomorphism restriction is now just an
anachronism from Haskell 98 or if it is still needed for efficiency
ie should I just now use -fno-monomorphism-restriction when
compiling all my code to consign it to the dustbin of history
Hi -
I'm wondering if the monomorphism restriction is now just an anachronism
from Haskell 98 or if it is still needed for efficiency ie should I just now
use -fno-monomorphism-restriction when compiling all my code to consign it
to the dustbin of history? :-)
A related question is, if it
Simon Peyton-Jones wrote:
Right. The crash was definitely a bug, but it seems to have been
fixed.
The error message about ambiguity is just what you'd expect.
I must admit I can't understand where the ambiguity actually is.
bar has been defined as a - Int, so surely anything on the rhs of
Geoffrey Alan Washburn wrote:
Brian Hulley wrote:
I must admit I can't understand where the ambiguity actually is.
bar has been defined as a - Int, so surely anything on the rhs of an
equation for an instance of the bar method in Foo is therefore an Int
also, so having to explicitly write 1
Serge D. Mechveliani wrote:
People,
Who knows, please, how usable are currently recursive module imports
in Haskell, in GHC ?
Is it essentially more difficult to `make' and support a project
which has 50 modules, and half of all the module pairs import each
other?
Is recursive import in
Ross Paterson wrote:
On Wed, May 31, 2006 at 12:20:02PM +0200, Michael Marte wrote:
when importing Data.Queue in 6.4.2, I am told that it is deprecated
and that I should use Data.Sequence instead. However, Data.Sequence
is not part of the base package - it is there but it is missing from
the
Hi -
I've just downloaded and installed Edison using Cabal.
However I now see that Edison seems to have been already installed with the
ghc 6.4.2 installation, even though there's no mention of Edison in
/doc/html/libraries/index.html, because there are old Edison .hi files in
Robert Dockins wrote:
On Jun 1, 2006, at 6:36 AM, Brian Hulley wrote:
Hi -
I've just downloaded and installed Edison using Cabal.
How did that go for you? You appear to have had some success ;-) I
ask because 1.2rc4 has a new build system and I'm interested in your
experience. Also, have
Niklas Broberg wrote:
On 4/27/06, Robin Bate Boerop [EMAIL PROTECTED] wrote:
But, this code:
class CC a
type C x = CC a = a x
f, g :: C a - Int
f _ = 3
g x = f $ x -- the only change
The problem is exactly the use of $. $ is an operator, not a built-in
language construct, and it has type (a
Robin Bate Boerop wrote:
This code compiles properly (with -fglasgow-exts on GHC 6.4.1):
class CC a
type C x = CC a = a x
f, g :: C a - Int
f _ = 3
g x = f x
But, this code:
class CC a
type C x = CC a = a x
f, g :: C a - Int
f _ = 3
g x = f $ x -- the only change
gives this error:
Brian Hulley wrote:
f,g :: (forall a. CC a = a Int) - Int -- not allowed
delete the not allowed comment ;-)
It's not so simple as I'd thought so I'd be interested to know the reason
for $ making a difference too.
Regards, Brian.
___
Glasgow
Brian Hulley wrote:
Brian Hulley wrote:
f,g :: (forall a. CC a = a Int) - Int -- not allowed
delete the not allowed comment ;-)
It's not so simple as I'd thought so I'd be interested to know the
reason for $ making a difference too.
Actually I must undelete my not allowed comment above
Sigbjorn Finne wrote:
A candidate 6.4.2 installer for Windows is now available,
http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-2-20060421.msi
Unless any major issues show up over the weekend, I'll move it
into its proper directory early next week.
Thanks. I've installed it from the
Simon Marlow wrote:
Brian Hulley wrote:
Simon Marlow wrote:
[Snip]
We are able to release VH under a BSD license now. The code is in
darcs and BSD licensed: http://darcs.haskell.org/vshaskell/. I think
the current binary distribution still has the old license, but we'll
hopefully refresh
Simon Marlow wrote:
=
The (Interactive) Glasgow Haskell Compiler -- version 6.4.2
=
I notice that everything except the standalone Windows port is now available
Bulat Ziganshin wrote:
i'm tried to say that there is no such dynamic beast as virtual
functions in C++
I think you can use existential types to simulate virtual functions:
-- 'a' is a stream of b's
class StreamClass a b where
get :: a - IO b
-- hide the particular 'a' to get any stream
Simon Peyton-Jones wrote:
Would you like to add to the GHC FAQ, or even start a Hints about
using the FFI page?
http://haskell.org/haskellwiki/GHC:Documentation
(The section at the bottom called collaborative documentation is the
place.)
Hard-won experience like this should be captured. GHC's
Simon Peyton-Jones wrote:
Brian
I've committed a fix for this. By which I mean that you don't need to
write dropRenderM. You can just use RenderM as if it were IO.
The change won't be in 6.4.2, but it's in the HEAD and will be in 6.6
Thanks!
Cheers, Brian.
Hi -
I've discovered that the finalizer in the code below is always called with a
NULL pointer even though the pointer returned by the allocation routine is
always not NULL.
Is this a known bug, and if so, are there any workarounds?
I'm using ghc version 6.4:
data RawFont
newtype Font = Font
Hi -
When I use -O2 to compile, gcc gives a compilation error: too few arguments
to function duma_releaseFont
When I look at the ghc output with -ddump-cmm, this seems to be where the
bug is:
r2MP_entry() {
// SNIP - all kinds of stuff here
call ccall suspendThread((BaseReg,
Solved!
By just using the following syntax, GHC compiles everything correctly:
foreign import ccall
duma_releaseFont -- absolutely vital for FunPtr functions
duma_releaseFont
:: FunPtr (Ptr RawFont - IO ())
which now gives (correctly):
s36c_entry() {
// SNIP
call
[Helpful off-list suggestion to look at FFI spec for more closely]
Thanks. I'd read it several times before but hadn't understood the
difference between a function and the address of a function and so thought
'' was optional, as it is in C for functions:
void foo();
typedef void
H -
I'm wondering if there is any way to specify that certain sequences of
foreign calls can be merged into a single foreign call. For example, in a
common situation where a state of a foreign API is pushed and popped so that
the previous state is restored, I'd like successive pops to avoid
Benjamin Franksen wrote:
[snip]
Thus, GHC does nothing wrong, according to the addendum. That doesn't
mean allowing IO-equivalent newtypes wouldn't be a good idea. It is
just not written in the addendum.
Apologies for not reading the addendum properly and slighting the good
character of
John Meacham wrote:
On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
where the intention is that the callback will take the width and
height of the window and return a RenderM action, the problem is
that because the FFI does not allow RenderM to appear in a foreign
type
Simon Peyton-Jones wrote:
GHC does unwrap newtype result types, as in
foreign import foo :: Int - IO Boogle
newtype Boogle = B Int
which is what the manual meant. I'd never thought of newtyping the IO
monad itself. Why are you doing that, incidentally?
I'm designing a simple API for
Brian Hulley wrote:
With -O2 enabled, __ccall_GC duma_vertex3f is indeed called directly
instead of vertex3f, from a different module, so that proves that
different monads can indeed be used to wrap IO operations without any
performance penalty at all.
However I've just discovered
Duncan Coutts wrote:
Because ghc does compile via C and does use the C header files to get
the C function prototype. Well it can compile via C and it's
recommended when compiling FFI code since it allows the Haskell type
you've declared to be checked against the C prototype.
[snip]
There are
Krasimir Angelov wrote:
Hi Brian,
The problem is that hs_free_fun_ptr is defined in a static library
(the Haskell RTS) while you have declared it with
__declspec(dllimport). In this case the compiler is tring tp optimize
the call and it is using __imp__hs_free_fun_ptr instead of
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to
use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything,
finally using
Sven Panne wrote:
[snip]
being executed. The technical reason for this is that after returning
from Haskell land, the adjustor code might need to do some cleanup:
C - adjustor - stub - Haskell - stub - adjustor - C
It could be the case that the adjustor tail-jumps to the stub, but
this is
Hi,
I'm designing an API for a simple graphics window, and am trying to make the
correct usage of the API functions explicit and visible to the type system
by using different monads which ultimately just wrap the IO monad. For
example, in a callback for rendering stuff to the screen, only
Chris Kuklewicz wrote:
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to
[snip]
There should be no overhead for a newtype. The above can be
shortened to one line:
newtype VertexM a = VertexM (IO a) deriving (Functor,Monad,MonadIO)
Thanks
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to
use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything,
finally using
Hi -
I have the following declaration and code in part of a DLL I'm writing:
extern C {
typedef void (*HsFunPtr)();
extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp);
}
enum ECallback { ECallback_Render, ECallback_COUNT};
HsFunPtr callback[ECallback_COUNT];
... :-)
Brian Hulley wrote:
Hi -
I have the following declaration and code in part of a DLL I'm
writing:
extern C {
typedef void (*HsFunPtr)();
extern __declspec(dllimport) void hs_free_fun_ptr(HsFunPtr fp);
}
enum ECallback { ECallback_Render, ECallback_COUNT};
HsFunPtr
Hi -
I've got the beginnings of an API for a GUI system as follows:
data DWindow a
data DEdit a
type Window = DWindow
type Edit a = DWindow (DEdit a)
foreign import ccall duma_init :: IO ()
foreign import ccall duma_run :: IO ()
foreign import ccall duma_release :: FunPtr (Ptr (Window a) - IO
Esa Ilari Vuokko wrote:
On 3/15/06, Brian Hulley [EMAIL PROTECTED] wrote:
[snip]
(Not directly related, but maybe useful to know)
Stricly speaking, asynchronous exception may occur in between, and
this
code should in fact be surrounded by block to prevent resource
leaks.
createEdit = block
[EMAIL PROTECTED] wrote:
Brian Hulley [EMAIL PROTECTED] wrote:
My other question is what happens if I want to have a function that
takes more than one ForeignPtr as argument ie
foreign import ccall duma_test :: Ptr (Window a) - Ptr (Window a)
- IO ()
test :: ForeignPtr (Window
Simon Marlow wrote:
Brian Hulley wrote:
I've got the beginnings of an API for a GUI system as follows:
...
addTop :: ForeignPtr (Window a) - IO ()
addTop w = withForeignPtr w duma_addTop
This works, but it seems a bit of a pain to have to manually convert
between ForeignPtr's and Ptr's all
Brian Hulley wrote:
Hi -
I've got the beginnings of an API for a GUI system as follows:
foreign import ccall duma_createEdit :: IO (Ptr (Edit a))
createEdit :: IO (ForeignPtr (Edit a))
These should of course be:
foreign import ccall duma_createEdit :: IO (Ptr (Edit
Hi -
I've got a Haskell module with the following ffi import:
foreign import ccall duma_init :: Int - IO Int
However my problem is that I've got no idea what the type signature for the
corresponding C function should be, and when I compile the above module with
ghc -fglasgow-exts -fffi --make
Hi -
I've set up my Visual Studio environment so that ghc is an external tool,
where the output from ghc appears on the VS output pane. However when I use
this to compile and link a Haskell program (I'm just using the plain text
editor that comes with VC++ not the Haskell plugin because of its
Neil Mitchell wrote:
In unix you could wrap ghc in a script that would print Done if ghc
finished successfully. I am sure you can do it somehow in windows.
ghc --make Whatever
if errorfail 1 goto failed
echo Success :-)
goto end
failed
echo Failure :-(
end
Thanks Neil - the script below,
Bulat Ziganshin wrote:
Hello Brian,
Tuesday, March 7, 2006, 7:35:27 PM, you wrote:
foreign import ccall duma_init :: Int - IO Int
int duma_init(int);
Also, I really wanted to be able to use () - IO () but () doesn't
seem to be allowed in FFI...
void f(void);
foreign import ccall f :: IO
Hi -
I'd like to be able to use Haskell for the project I'm working on but the
problem is that I've already written a lot of code for a nice GUI using
DirectX in Visual C++.
I thought it might be possible to make up some kind of simple API for it
which I could call from Haskell, so I started
Ben Rudiak-Gould wrote:
David Menendez wrote:
Ben Rudiak-Gould writes:
forall a. (forall b. Foo a b = a - b) - Int
is a legal type, for example.
Is it? GHCi gives me an error if I try typing a function like that.
This works:
f :: forall a. (forall b. Foo a b = a - b) - Int
f
Brian Hulley wrote:
Thanks (also to Stefan) for clarifying that f's type is indeed legal.
However I still think that there is a bit of confusion about what the
syntax is supposed to mean, because:
f :: forall a. (forall b. Foo a b = a - b) - Int
is effectively being used
David Menendez wrote:
Ben Rudiak-Gould writes:
Also, the rule would not be quite as simple as you make it out to be,
since
forall a. (forall b. Foo a b = a - b) - Int
is a legal type, for example.
Is it? GHCi gives me an error if I try typing a function like that.
{-# OPTIONS
Bulat Ziganshin wrote:
Hello Brian,
Thursday, February 09, 2006, 9:38:35 AM, you wrote:
the past few months (!) and still can't understand why the following
is an illegal type:
forall a. ((Ord a = a- a) - Int)
i don't know right answer burt may be because Ord a restriction and
forall a
1 - 100 of 108 matches
Mail list logo
