[mercury-users] Mercury for Win32 under Visual C? Was: Re: Mercury for Mac ?

[Alexander Voinov]

> > And what about the situation when a Mercury module should be incorporated
> > into existing Visual C/MFC based code?
> The current Mercury port to win32 uses gnu-win32, which is a fairly
> complete Unix emulation library.  I've been thinking about trying a
> more "native" port, still using some of the tools from gnu-win32 (e.g.
> GNU Make for Mmake, etc.), but using the gcc from mingw32, the
> "minimal" version of gnu-win32, which generates native Win32
> executables that don't depend on cygwin.dll.  From what I have heard,
> programs built with mingw32 can interface with Visual C/MFC code
> without difficulty.
> 
> As yet, I didn't get any further than downloading mingw32, though.
> As usual, volunteers are very welcome ;-)

I have also downloaded mingw32 recently (for one of my projects) and also
didn't get any further :-).

Is mingw32 stable enough, anyway?

I know how to work with mixture of MFC code and that of PDC Prolog (former
Turbo Prolog), which resembles Mercury for static typing and intention to
compilation. (BTW its current development team resides in St.Petersburg,
my native town :-)).
But PDC Prolog looks 100 times simpler (more naive?) than Mercury.
And compatibility with Microsoft C's is well built in.

If I knew Mercury better I would to try to do something like this with Mercury.
Probably after some learning and playing with under Unix...

There is theoretically a possibility to port MFC to gnu C++. There is a
"migration kit" (???). Some people reported that port is already done.
But g++ is not well suited to work with large
C++ libraries, esp. under slow file systems like fat and ntfs.
I have experience with TurboVision. (While compiling its headers,
the nt virtual dos machine, containing djgpp, grew up to 13M  -- and 7M
under Linux).

As an example: Python scripting language, originated from 
Unix environment, has quite "native" port to Win32 under Visual C
It is very useful. There is no "official" version of Python for gnu-win32 or
djgpp.
Also Tcl.

As I conclude seeing the mailing list, 
for the current stage of language development it
is not very appropriate to complicate things with ports to Mac, Win32 etc.
I understand and agree. Unix is quite enough to make the language itself stable.

Alexander