[MLton-devel] Re: [MLton-user] new release of MLton
Mike Thomas
mthomas@gil.com.au
Tue, 15 Jul 2003 07:58:47 +1000
This is a multi-part message in MIME format.
------=_NextPart_000_0056_01C34AA6.EB99D620
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
PS.
I just went home sick so before curling up in bed to sulk for the day, here
is the test program (translated from the original MoscowML, below), attached
with makefiles, and the error messages. Basically I want to pass my SML
callback "display" into C land with "glutDisplayFunc" but it is apparently
not allowed to use a function type as an argument to an FFI function.
$ make -f Makefile.mlton
mlton test.cm
test.sml:31.3-31.18 Error: unify: can't unify
t1: unit
t2: unit -> unit
compilation aborted: type check reported errors
make: *** [test] Error 1
PPS.
Does anyone use PolySML to typecheck mlton FFI code?
PPPS
Having thought about it, I can't see how to use the approach Ken talks about
to achieve the above result without fixing the name of each particular type
of callback on the C side. Am I right?
----- Original Message -----
From: "Mike Thomas" <miketh@brisbane.paradigmgeo.com>
To: <MLton@mlton.org>
Cc: <mthomas@gil.com.au>
Sent: Tuesday, July 15, 2003 4:50 AM
Subject: RE: [MLton-user] new release of MLton
> Hi Stephen.
>
> | > I couldn't think of a way of actually passing those
> | > callback functions as SML side function arguments to functions
> | which in turn
> | > call _ffi C functions to set callbacks, for example, setting a redraw
> | > callback on the C side, but doing it entirely from the SML side.
> |
> | Ken Larsen described to us how they handle callbacks in mGTK
> | (http://mgtk.sf.net). Here's what he said.
> |
> .... GTK stuff cut....
>
> |
> | Would a similar approach for you? I could imagine having different
> | hash tables and dispatchers for different types of callbacks.
>
> I can probably simulate the Moscow ML callback setting constructs by this
> approach. I'll need to think about it. Having said that, it would be
nice
> for a games programmer (for example) to be able to work directly with the
> metal, although to be fair, they wouldn't be using the GLUT callbacks and
> event loop if they were serious.
>
> I'm pushing for ease of use and transparency both for myself in terms of
the
> FFI and for the end user. The original Moscow ML binding allows the SML
> approach to the OpenGL libraries to be intuitively the same as the C
> language bindings which are well known and well documented. This gives
two
> advantages for the average person already familiar with OpenGL or who
> already has a book on the subject:
>
> 1. It feels the same - less effort in switching to a nice language like
SML
> from C as the SML binding does not add an extra layer of effort in
> translating preexisting code.
>
> 2. Any OpenGL binding I produce for SML compiler A give will be portable
in
> terms of end-user SML code to SML compiler B.
>
> Here is some code - a direct and transparent translation of preexisting
C -
> each GL/GLUT function here is a direct FFi call to a C function:
>
> open GL;
> open GLut;
>
> fun display () =
> (
> glClearColor 0.0 0.0 1.0 1.0;
> glClear GL_COLOR_BUFFER_BIT;
> glFlush()
> )
>
> fun main () =
> let
> val args = ["shortest"] @ CommandLine.arguments()
> val argc = List.length(args)
> in
> glutInit argc args;
> glutCreateWindow "Short Test";
> glutDisplayFunc display; (* Register the display callback *)
> print("Click the close icon to close the window.");
> glutMainLoop()
> end
>
> val _ = main();
>
>
> | I am surprised that when you run make, you get no errors.
>
> Sorry about that - the old trap of writing a bug report and tweaking the
> example source at the same time.
>
> | You are correct that you cannot put .c files into .cm files. But
> | there is no need, since you can link with .o files on the command
> | line. So, if you change dynlib.cm to
> |
> | Group is
> | Dynlib.sig
> | Dynlib.sml
>
> Still it would be convenient. Having said that I suppose there is a
> compatibility issue with SML/NJ which presumably doesn't allow C source
code
> in CM files.
>
> |
> | and change your Makefile to
> ....
>
>
> As usual, you've been very helpful.
>
> Thanks
>
> Mike Thomas.
>
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 2003-07-04
------=_NextPart_000_0056_01C34AA6.EB99D620
Content-Type: application/octet-stream;
name="Makefile.mlton"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Makefile.mlton"
mlton = mlton
.PHONY: all
all: test
test: test.sml
$(mlton) test.cm
clean:
rm *.o *.exe
------=_NextPart_000_0056_01C34AA6.EB99D620
Content-Type: application/octet-stream;
name="test.cm"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="test.cm"
Group is
test.sml
------=_NextPart_000_0056_01C34AA6.EB99D620
Content-Type: application/octet-stream;
name="test.sml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="test.sml"
type GLenum =3D Word.word
val GL_COLOR_BUFFER_BIT =3D 0wx00004000
val glClear =3D _ffi "glClear": GLenum -> unit;
val glClearColor =3D _ffi "glClearColor" : real -> real -> real -> real =
-> unit;
val glFlush =3D _ffi "glFlush": unit -> unit;
val glutInit =3D _ffi "glutInit" : int -> string list -> unit;
val glutCreateWindow =3D _ffi "glutCreateWindow": string -> int;
val glutMainLoop =3D _ffi "glutMainLoop": unit -> unit;
val glutDisplayFunc =3D _ffi "glutDisplayFunc" : (unit -> unit) -> unit;
val display =3D _export "display": unit -> unit;
val _ =3D display (fn () =3D>
(
glClearColor 0.0 0.0 1.0 1.0;
glClear GL_COLOR_BUFFER_BIT;
glFlush()
)
)
fun main () =3D=20
let
val args =3D ["shortest"] @ CommandLine.arguments()
val argc =3D List.length(args)
in
glutInit argc args;
glutCreateWindow "Short Test";
glutDisplayFunc display;
print("Click the close icon to close the window.");
glutMainLoop()
end
val _ =3D main();
------=_NextPart_000_0056_01C34AA6.EB99D620--
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel