On 05/28/2010 11:06 PM, Stéphane Glondu wrote:
Is there a practical test to be sure whether natdynlink works or not?
The only way to test if natdynlink works that I know is to try it. In
the current trunk, set NATDYNLINK=true in config/Makefile after
configure, compile everything, and then
** Informaticiens de haut niveau
MLstate est une jeune entreprise innovante en campagne depuis 2008 pour la
reconquête du web. Notre objectif : réinventer les bases technologiques et
scientifiques des applications web, pour une toile plus saine, plus sûre et
plus sécurisée. Notre équipe RD
Richard Jones r...@annexia.org writes:
On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
What experience does people have to using alternatives to exceptions, such
as option types or exception monads? Does use of third part libraries that
still throws exceptions make such
type foo = Foo
let x = Foo
type foo2 = Foo | Bar
let y = Foo
let z = (x,y) ;;
I thought that re-using of algebraic labels was not allowed - but
apparently it is? Note that this means that it is impossible to text
print such structures and hope to recover them uniquely. This also
causes
Goswin von Brederlow a écrit :
Imho a good module should provide both an exception and option based
interface to fit the circumstances and programming style.
+1
It would be nice if the possible exceptions of a function would be part
of the type. E.g.
let f1 () = raise Not_found
val f1 :
But what when someone includes or opens a module with Foo after type
foo = Foo? What when someone opens it locally in an expression?
Does a variant value have a unique type with a unique path so that it
would be possible to guarantee that within this unique path there are
no type *definitions*
AFAIK you are allowed to shadow just about anything in
implementations. If you wanted to keep the exact same interface but
retain the ability to avvoid the shadowing issue on the labels you
could do:
module Foo = struct
type t = Foo
end
type foo = Foo.t = Foo
module Foo2 = struct
type t =
Lukasz Stafiniak wrote:
But what when someone includes or opens a module with Foo after type
foo = Foo? What when someone opens it locally in an expression?
I would be fine if type-level shadowing was disallowed for all those cases.
Does a variant value have a unique type with a unique
Goswin von Brederlow wrote:
snip
However if the exception is, say, an I/O error reading a disk file,
these should be thrown, and caught somewhere central where you can
display an error message to the user (for GUI programs) or abort the
current transaction (for server programs).
On Mon, 31 May 2010 16:36:22 +0200, Goswin von Brederlow goswin-...@web.de
wrote:
Richard Jones r...@annexia.org writes:
On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
What experience does people have to using alternatives to exceptions, such
as option types or
It would be nice if the possible exceptions of a function would be part
of the type. E.g.
let f1 () = raise Not_found
val f1 : unit - 'a [ Not_found ]
let f2 () = try f1 () with Not_found - ()
val f2 : unit - unit
let f3 f = try f () with Not_found - ()
val f3: (unit - 'a [ Not_found |
On Mon, May 31, 2010 at 9:30 PM, Nicolas Pouillard
nicolas.pouill...@gmail.com wrote:
Since having all functions in all flavours can lead to hard to interface
bloat, one should consider tiny functions to switch from a style to another.
It tends to be easier to start from an option type in the
I use a syntax extension that catches Not_found and raises a failure
instead, with the source location of the real offending call. I do
this mostly because OUnit catches exceptions so backtraces are of no
use.
I have encoutered the same problem and resolved it with explicit
backtrace handling
13 matches
Mail list logo
