Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
OCaml's long range graphical direction?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: OCaml's long range graphical direction?
Hi Brian,

From: Brian Rogoff <>
> On Fri, 9 Feb 2001, Jacques Garrigue wrote:
> > Seriously, most Obj.magic in lablgtk amount to a cast of an external
> > after checking its validity, and I see no way to avoid that.
> Sure, but it seems to me that even if such things are implemented 
> with Obj.magic under the hood we ought to come up with new names and 
> eventually move "approved and safe usages" to the Sys module. I am 
> probably under the influence of Modula-3 and Ada here...

I checked again the cases, and they really amount to changing types
according to the dynamic type of some C value.  Since C has no dynamic
typing, we cannot go very far...
But you're right, this number could be considerably reduced by making
specialized versions of Obj.magic specifying a bit more about the
input and output type.  I just avoided that, in case people would
start using this function as a safe one.

> > The last problem is how to stay type safe when you load a text file.
> > Basically this means that you will be more verbose, and that will
> > compare badly with guile-gtk or python-gtk based applications.
> I think for this problem we need some dynamic typing in the language. It 
> seems the Clean and Mercury languages have or will adopt such a solution; 
> I don't know about Haskell. This is the same issue as with safe
> marshalling right, so we are told that there is some help on the way.  

Dynamic typing will still have a syntactic overhead. My point is that
a typed language should have its own better ways to do things easy
to do in scripting languages, and they can be different.

> > So, there might be something to do, but I'm not so much convinced it
> > will help with a language like ocaml.
> Then ocaml will have to become like something else. It won't be the
> first time. 

I'm not sure of what you mean by that, but if you want to do things
like add downcast to ocaml, then this is a discussion we had several
years ago.  Even if dynamic typing is introduced, it will probably
have a more type dispatching flavor, forcing (or helping) the
programmer to write exhaustive code.

The credo of type safety can be hard to follow at times. But
abandoning it just to be like other languages will not make us
progress.  We already know that at least for pure ML programming
(including interfacing to many external libraries), one can find
strongly typed ways to work.  If using some external tool creates
problem with that, I personally will prefer rethinking the external
tool (or the way to use it), rather than forget that credo.

It may seem like fanatism for the type religion, but for me ocaml is
really that: a _typed_ language.