[Caml-list] More OCaml+windowing system questions

[Caml-list] More OCaml+windowing system questions

[Walter B. Rader]

I am using OCaml and SDL (Software DirectMedia Layer, a
cross-platform graphics library) to create a windowing
system that runs on top of the user's existing OS+GUI (e.g.
Windows, MacOS, etc.) and provides similar services.  I
figure that writing it this way allows me to take advantage
of the services that the GUI and OS already offer, while at
the same time extending its capabilities.

The windowing system's capabilities (will) include
portability (offered to some degree by OCaml and to a larger
degree by SDL,) execution of byte-code compiled applications
that use the windowing system, network transparency, the
option to reconfigure at run-time UI behavior (e.g. for
"skins," users with assistive hardware such as screen-
readers, etc.) and so forth.

The project is still in its early stages and as such I don't
have a lot of technical details to add before launching into
my questions.  =)

I apologize if these are RT*M type questions - I am a bit
overwhelmed trying to learn OCaml and choosing THIS as my
first project =).  Feel free just to give me pointers to
information elsewhere on the web.


Question #1: Is OCaml a suitable language for this project?
Based on what others have done, it seems that I "should"
use a language like C or C++.  When enumerating the
advantages OCaml offers, I came up with the following:

o first-class functions (very handy)
o type safety
o automatic garbage collection
o terse source code
o programs that use the windowing system can be distributed
  in byte-code for enhanced portability

However, C and C++ are extremely portable, which is very
appealing to me.  Why would OCaml be more suited for this
project?


Question #2: How portable *is* OCaml?  I see that binaries
are available for Linux, MS Windows, and Macintosh.  Has
there been success in porting OCaml to other platforms?  If
not the native-code compiler, at least the byte-code compiler
and interpreter?


Question #3: As mentioned previously, I will support running
byte-code applications that use the windowing system.  I
would like to be able to load each in its own process space,
so that the OS scheduler can handle scheduling.

(The benefit being that I don't have to employ some kind of
cooperative multi-tasking system, which I would have to do
if the windowing system and all applications executed in it
ran in the same process.)

Is there a "good" (efficient, elegant, etc.) portable way to
handle communication between the windowing system process and
the application process(es)?


Thanks so much for your time!

Walter Rader


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] More OCaml+windowing system questions

[Xavier Leroy]

> Question #2: How portable *is* OCaml?  I see that binaries
> are available for Linux, MS Windows, and Macintosh.  Has
> there been success in porting OCaml to other platforms?  If
> not the native-code compiler, at least the byte-code compiler
> and interpreter?

The byte-code system works on essentially every Unix variant out there,
and the native-code compiler is supported for a dozen processor / Unix
variant combinations.  For a detailed list, see
        http://caml.inria.fr/ocaml/portability.html

So, OCaml is supported under Unix (including but not limited to
Linux), Windows, MacOS, and BeOS to some extent.  Other operating
systems (VMS, IBM's mainframe OSes, etc) haven't been tried, but they
are getting extinct :-)

> Question #3: As mentioned previously, I will support running
> byte-code applications that use the windowing system.  I
> would like to be able to load each in its own process space,
> so that the OS scheduler can handle scheduling.
> Is there a "good" (efficient, elegant, etc.) portable way to
> handle communication between the windowing system process and
> the application process(es)?

There's a built-in marshaler that lets you exchange complex data
structures over pipes or sockets.  There is no standard remote
function call infrastructure yet, but it's not hard to build one on
top of the marshaler; see for instance what the Unison team did.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] More OCaml+windowing system questions

[Andreas Rossberg]

"Walter B. Rader" wrote:
> 
> However, C and C++ are extremely portable, which is very
> appealing to me.

Sorry, I cannot resist commenting on that particular statement, because
it still seems to be such a frighteningly common misconception.

This statement confuses two issues: portability and availability. C
certainly is available on pretty much every system. But this says
nothing about portability of C code - C and C++ are definitely among the
least portable languages in use today. There effectively is no
non-trivial C program that is portable according to the language
standard (ie. does not explore undefined/unspecified behaviour one way
or the other - most times you are not even aware).

This is in stark contrast to high-level languages like OCaml, which are
clearly not as widely available, but which have mostly
system-independent and fully specified semantics[*]. So portability
rates very high.

Best regards,

	- Andreas

[*] Not completely true for OCaml - consider eg. evaluation order - but
still a vanishingly small issue compared to C.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] More OCaml+windowing system questions

[Warp]

> > However, C and C++ are extremely portable, which is very
> > appealing to me.
>
> Sorry, I cannot resist commenting on that particular statement, because
> it still seems to be such a frighteningly common misconception.

And so can't I resist to comment your comment :)

> This statement confuses two issues: portability and availability. C
> certainly is available on pretty much every system. But this says
> nothing about portability of C code - C and C++ are definitely among the
> least portable languages in use today. There effectively is no
> non-trivial C program that is portable according to the language
> standard (ie. does not explore undefined/unspecified behaviour one way
> or the other - most times you are not even aware).

I think that all the features of the C/C++ languages ARE portable. Why
shouldn't they be ? All you have to do is to compile with the good compiler
( gcc for instance ). BUT then, you have to be aware of some things that are
not permitted ( like DWORD access on odd memory addresses on Solaris ) and
to use a portable API - like ACE, or OpenGL - to do "special" things. In
fact, the limits of portability C/C++ are in the choice of the API you make,
and in the fact you CAN write very-low-level code when you should use an
API.

Thus, there is a big difference between portabily ( source code can be
recompiled on another machine and will work fine ) and "super-portability"
 compiled code will work fine - if you got the 'launcher' ) : and that's one
of the reasons of Java's sucess

Warp

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] More OCaml+windowing system questions

[Wolfgang Lux]

"Warp" wrote

> I think that all the features of the C/C++ languages ARE portable. Why
> shouldn't they be ? All you have to do is to compile with the good compiler

Because they are machine dependent by definition. For example the C standards 
have nothing to say about the size of an int or a short (except that 
sizeof(int) >= sizeof(short)). Depending on the architecture, compiler, and 
even programming model, int i = 1; i <<= 32; will either set i to 0 or to 
0x100000000 (even for gcc). Neither can you rely on the order of bytes in an 
integer (and casting an int* into a char* is certainly not forbidden by the 
standard) etc.

> ( gcc for instance ). BUT then, you have to be aware of some things that are
> not permitted ( like DWORD access on odd memory addresses on Solaris ) and
> to use a portable API - like ACE, or OpenGL - to do "special" things. In
> fact, the limits of portability C/C++ are in the choice of the API you make,
> and in the fact you CAN write very-low-level code when you should use an
> API.

No one is claiming that you cannot write portable code in C, you just have to 
take care and restrict yourself to the portable subset of C (or resort to some 
preprocessor magic in order to adapt to different platforms.)

Wolfgang



--
Wolfgang Lux				  Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik	    FAX: +49-251-83-38259
Universitaet Muenster		      Email: wlux@uni-muenster.de
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr