English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
RE: [Caml-list] two unrelated questions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-05-01 (17:21)
From: Dave Berry <dave@k...>
Subject: RE: [Caml-list] two unrelated questions
Even a top level exception can escape its scope, e.g. if a signature doesn't
include an exception raised by one of the functions in the signature.  The
problem I (as an SMLer) cite most often is exceptions - not just local
exceptions - escaping their scope.

Having said that, I think it best to have two distinct features: exceptions
and breaks.  Exceptions are top-level, monomorphic, and comparatively easy
to track.  Breaks are declared in function bodies, potentially polymorphic,
and should be banned from exiting the scope of their declaration.  This
would entail limits on how breaks could be used, to make the flow control
tractable.  I don't know whether there is a suitable flow control algorithm
that would give reasonable flexibility while still ensuring this safety

-----Original Message-----
From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp]
Sent: Tuesday, May 01, 2001 2:31
To: bpr@best.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] two unrelated questions

That is, defining local exceptions (and local types also) is a very
fine way to shoot oneself in the foot. You end up having plenty of
exceptions (or types) with the same name (impossible to distinguish at
toplevel), but incompatible. 

For exceptions, logically a locally defined exception escaping its
scope should be a fatal error, but this is not the case (cannot be
really enforced). So you can end up at toplevel getting an exception
of an unknown name, impossible to catch. (This is the problem SMLers
cite most often).

To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr