HGL with GHC in Win32

[Alastair Reid]

> sounds familiar, and I've got to admit that the ffi part sounds more
> interesting;-)

I think I did the interesting part about a year and a half ago when I
first wrote an ffi-like system.  I'm now contemplating how to make the
configure system automagically detect how to build shared object files
and the interest level has fallen off considerably :-)

>> > and <dream>HOpenGL works with all Haskell
>> implementations</dream>, > perhaps HGL could be ported to HOpenGL -
>> to eliminate all further > portability issues (missing features
>> under X, etc.)..
>> 
>> I think the basic HGL API would work on a lot of platforms.  I
>> don't know enough about HOpenGL to be sure but I think it's easier
>> to implement HGL on than X11 or Win32 were.

> I'm not sure how to parse this, but the idea was that OpenGL is
> already available (and hardware-supported) on many platforms
> (www.opengl.org), and that it is the most likely route for more
> advanced graphics hackers.  So an HGL as a learner's 2d interface to
> the full thing might be interesting in itself, but it should also
> permit to merge the x11/win32/whatever branches into a single
> one.. (modulo some minor infelicities, of course)

What I meant by platform was:

- some sort of library for drawing graphics (win32, X11, postscript,
  HOpenGL, etc.)

- some sort of library for creating drawing regions (windows, boxes
  inside TCL/Tk widgets, texture maps, GIF files, fresh sheets of
  paper in printer, etc.)

- (optional?) some sort of library for getting input (I vaguely
  remember being told that OpenGL doesn't directly support that - but
  could be mistaken).

HGL's role is to present this platform in a uniform way and to take
care of any buffering of output, redrawing of freshly exposed windows,
allocation of colours, etc.

It'd be cool if supporting HOpenGL let us get rid of the Win32 and
X11-specific versions at the moment.

> The size problem is traceable to [Greencard's ffi code generation]

The problem seems to be present in the current repository.

Hmmm, I distinctly remember tracking this down and fixing it but it
doesn't look like I committed the change - I'll check in the morning.

> In light of this, ghc's win32 ought to be re-greencarded anyway
> (once greencard's ffi target is fixed for ghc, which seems to be in
> progress:), before the next release, no?

Well I'll fix it for Hugs and trust GHC to conform to the ffi spec.

> As an old fan of hugs, I'm glad that it keeps up with developments!-)

I guess I'm sentimentally attached to Hugs but I like the fact that
it's so portable and trivial to install.  I also think it's good to
have multiple Haskell implementations around.

Plus, it's easy to hack on Hugs.  Quite a few GHC features first
appeared in Hugs (TREX, imprecise exception handling, implicit
parameters, mudo, GreenCard version 1, constructor classes, zip
comprehensions (does GHC have those yet?), ...)  Incompatibilities have
tended to set in because the design gets improved in being ported to
GHC and the Hugs hackers are slow to see the light.

-- 
Alastair Reid   
alastair@reid-consulting-uk.ltd.uk  
http://www.reid-consulting-uk.ltd.uk/alastair/