[Caml-list] Call for Papers: HLPP 2010 (DEADLINE EXTENSION)
We apologize if you receive this CfP multiple times. Please distribute ! DEADLINE EXTENSION Fourth International Workshop on High-level Parallel Programming and Applications (HLPP 2010) Baltimore, Maryland, September 25, 2010 Affiliated to ICFP 2010 AIMS AND SCOPE As processor and system manufacturers adjust their roadmaps towards increasing levels of both inter and intra-chip parallelism, so the urgency of reorienting the mainstream software industry towards these architectures grows. At present, popular parallel and distributed programming methodologies are dominated by low-level techniques such as send/receive message passing, or equivalently unstructured shared memory mechanisms. Higher-level, structured approaches offer many possible advantages and have a key role to play in the scalable exploitation of ubiquitous parallelism. This workshop provides a forum for discussion and research about such high-level approaches to parallel programming. Topics We welcome submission of original, unpublished papers in English on topics including (but not limited to) the following aspects of multi-core, parallel, distributed, grid and cloud computing: * High-level programming and performance models (BSP, CGM, LogP, MPM, etc.) and tools * Declarative parallel programming methodologies * Algorithmic skeletons and constructive methods * Declarative parallel programming languages and libraries: semantics and implementation * Verification of declarative parallel and distributed programs * Applications using high-level languages and tools * Teaching experience with high-level tools and methods PROGRAMME COMMITTEE * Anne Benoit (ENS Lyon, France) * Murray Cole (University of Edinburgh, UK) * Alexandros Gerbessiotis (New Jersey Institute of Technology, USA) * Christoph Kessler (Linköpings Universitet, Sweden) * Herbert Kuchen (University of Muenster, Germany) * Rita Loogen (University of Marburg, Germany) * Frédéric Loulergue (University of Orléans, France) * Kiminori Matsuzaki (Kochi University of Technology, Japan) * Samuel Midkiff (Purdue University, USA) * Susanna Pelagatti (University of Pisa, Italy) * Sukyoung Ryu (Korea Advanced Institute of Science and Technology, Korea) * Kazunori Ueda (Waseda University, Japan) IMPORTANT DATES * Submission (EXTENDED): 14 June 2010, 11:59 AM GMT * Notification: 12 July 210 * Final version: 28 July 2010 SUBMISSION Papers must be submitted online via EasyChair: https://www.easychair.org/account/signin.cgi?conf=hlpp2010 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. The text should be in a 9pt font in two columns; the length is restricted to 10 pages. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the workshop by one of the authors. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. WEBSITE http://frederic.loulergue.eu/HLPP/hlpp2010/index.html ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Architectures with natdynlink support...
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 run the tests in testsuite/tests/lib-dynlink-native (from testsuite/: "make one DIR=tests/lib-dynlink-native"). Any other application that uses Dynlink in native code is also a sufficient test. What kind of "feedback" do you expect? Whether natdynlink works or not + the value of $host, $arch64 (and other relevant variables) in the configure script. As far as Debian is concerned, Coq dynamically loading ssreflect and compiling stuff works on all native architectures [2] (as of OCaml 3.11.2), that means: - powerpc (powerpc64-unknown-linux-gnu) - sparc (sparc-unknown-linux-gnu) - kfreebsd-i386 (i686-unknown-kfreebsd*-gnu) - kfreebsd-amd64 (x86_64-unknown-kfreebsd*-gnu) - hurd-i386 (i386-unknown-gnu0.3) - amd64, i386 (linux kernel) Thanks. The current list is now: case "$host" in *-*-cygwin*) natdynlink=true;; i[3456]86-*-linux*) natdynlink=true;; x86_64-*-linux*) natdynlink=true;; i[3456]86-*-darwin10.*) if test $arch64 == true; then natdynlink=true fi;; powerpc64-*-linux*) natdynlink=true;; sparc-*-linux*) natdynlink=true;; i686-*-kfreebsd*) natdynlink=true;; x86_64-*-kfreebsd*) natdynlink=true;; i386-*-gnu0.3)natdynlink=true;; esac > Maybe people on this list can also report working natdynlink on other systems. Indeed, this (or any comment on the list above) would be very useful. Regards, Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Offre d'emploi / Job offer
** 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 R&D compte une vingtaine de passionnés, docteurs ou ingénieurs en informatique, et est sur le point de s’agrandir. Si vous êtes informaticien de haut niveau, inspiré et ingénieux, si vous êtes doté d’une forte culture informatique et scientifique, d’une grande connaissance des langages fonctionnels et impératifs, de la compilation, des systèmes de types, contactez-nous. Le candidat idéal, docteur ou non, avec ou sans expérience industrielle, aura aussi des connaissances en distribution, parallélisme, bases de données, sera capable d’évoluer dans un environnement polyglotte et disposera de la finesse nécessaire pour construire des produits finis. Les problèmes à résoudre sont difficiles. Pour relever le défi, contactez-nous à care...@mlstate.com . ** High-level computer scientists Since its foundation, in 2008, Paris-based start-up MLstate has been campaigning to reconquer the web. Our objective: reinvent technological and scientific foundations of web applications, and make the web saner, safer and more secure. Our R&D team comprises about 20 enthusiastic computer scientists, doctors or engineers, and is now preparing to scale up. If you are a high-level computer scientist, inspired, resourceful, if you have a strong culture in computer science, in both functional and imperative programming languages, in compilation, in type systems, contact us. Ideal candidates, PhDs or not, with or without industry experience, will also have a background in distribution, concurrency, databases, will be able to live and work in a multilingual environment, and will have the subtlety necessary to build finish products. The problems we need to solve are difficult. If you are up to the challenge, contact us at care...@mlstate.com . -- David Rajchenbach-Teller Head of R&D MLstate ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Types Meeting 2010
Types Meeting 2010 Warsaw, 13 - 16 October 2010 First Announcement The 17-th Workshop "Types for Proofs and Programs" will take place in Warsaw, Poland, from October 13 (Wednesday) to October 16 (Saturday). The Types Meeting is a forum to present new and on-going work in all aspects of type theory and its applications, especially in formalized and computer assisted reasoning and computer programming. Invited speakers: * Henk Barendregt; * Yves Bertot; * Pierre-Louis Curien; * Aarne Ranta. Important information concerning accomodation in Warsaw is already available from the conference web page: http://types10.mimuw.edu.pl Details concerning registration, fees, and how to submit a talk will soon be posted there as well. We are looking forward to your participation. The Organizing Committee type...@mimuw.edu.pl ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
Richard Jones 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 approaches hard to use? Performance wise >> it seems to be comparable to catching exceptions or matching for options, so >> I guess the difference be might a question of programming style? > > Personally I've found that you should only throw those exceptions > which can be caught in a single place in the program. By this I mean > that an exception such as Not_found shouldn't be thrown, and instead > it would be better to use an option type (for stdlib functions which > throw Not_found, you have to be _very_ careful that the exception > cannot "escape"). Which needlessly complicates your code when it never happens. Imho a good module should provide both an exception and option based interface to fit the circumstances and programming style. > 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). Recovering from such > exceptions properly is still tricky though. Since OCaml lacks > 'finally', you either have to use a 'finally' impl from a library, or > modify your code to not need it (eg. turning calls to 'open_in' and > 'open_out' into a kind of continuation-passing style). Or for small > programs, abort the program and don't deal with recovery at all. > > All in all, this is not ideal for writing correct programs. Some sort > of exception analysis would be most welcome. 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 | 'B ]) -> 'a [ 'B ] and so on. Someone would have to write a new type system for that though. MfG Goswin ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Why is this allowed?
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 very subtle issues when Marshal'ing, and grave issues for code generation [think metaocaml]. Jacques ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
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 : 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 | 'B ]) -> 'a [ 'B ] and so on. Someone would have to write a new type system for that though. ocamlexc gave such results, but this tool is now discontinued and not compatible with latest compilers :( -- Florent Ouchet PhD Student CIS/VDS Team - TIMA Laboratory ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why is this allowed?
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* that override a variant name? On Mon, May 31, 2010 at 4:46 PM, Jacques Carette wrote: > 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? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why is this allowed?
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 = Foo | Bar end type foo2 = Foo2.t = Foo | Bar HTH, Till On Mon, May 31, 2010 at 10:46 AM, Jacques Carette wrote: > 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 very subtle > issues when Marshal'ing, and grave issues for code generation [think > metaocaml]. > > Jacques > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why is this allowed?
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 path so that it would be possible to guarantee that within this unique path there are no type *definitions* that override a variant name? That would be nice. Jacques On Mon, May 31, 2010 at 4:46 PM, Jacques Carette wrote: 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? ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Why is this allowed?
Nice trick - but my 'problem' [1] regards arbitrary valid OCaml code and how to serialize code values. The issue seems to be that one needs to attach an arbitrarily large typing environment to each part of a value, as there is no global typing environment which will do the job (because of shadowing). Jacques [1] Actually 'our' problem, in that this arose from some issues in metaocaml, and I am working with Oleg to figure out what is going on. Interestingly, this never arose in 3.09 and before. Till Varoquaux wrote: 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 = Foo | Bar end type foo2 = Foo2.t = Foo | Bar HTH, Till On Mon, May 31, 2010 at 10:46 AM, Jacques Carette wrote: 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 very subtle issues when Marshal'ing, and grave issues for code generation [think metaocaml]. Jacques ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] Static exception analysis or alternative to using exceptions
Goswin von Brederlow wrote: > > 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). Recovering from such > > exceptions properly is still tricky though. Since OCaml lacks > > 'finally', you either have to use a 'finally' impl from a library, or > > modify your code to not need it (eg. turning calls to 'open_in' and > > 'open_out' into a kind of continuation-passing style). Or for small > > programs, abort the program and don't deal with recovery at all. > > > > All in all, this is not ideal for writing correct programs. Some sort > > of exception analysis would be most welcome. > > 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 > | 'B ]) -> 'a [ 'B ] > > and so on. > > > Someone would have to write a new type system for that though. Would it be more practical to have that analysis as part of the .annot file? Presumably a patch which merged and updated the codebase of ocamlexc to produce exception-annotations in that manner might have a chance of making it into the OCaml compiler itself. I'm guessing that what you're getting at is the ability to see from your code that an exception could escape at any given point rather than trying to add Java-style "checked exceptions" to OCaml? David ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
On Mon, 31 May 2010 16:36:22 +0200, Goswin von Brederlow wrote: > Richard Jones 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 approaches hard to use? Performance wise > >> it seems to be comparable to catching exceptions or matching for options, > >> so > >> I guess the difference be might a question of programming style? > > > > Personally I've found that you should only throw those exceptions > > which can be caught in a single place in the program. By this I mean > > that an exception such as Not_found shouldn't be thrown, and instead > > it would be better to use an option type (for stdlib functions which > > throw Not_found, you have to be _very_ careful that the exception > > cannot "escape"). > > Which needlessly complicates your code when it never happens. > > Imho a good module should provide both an exception and option based > interface to fit the circumstances and programming style. 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 case of Not_found instead of the other way around for the following reason: * The typechecker does not remind us to catch the exception. * We need a custom handler per exception. * We need to take a thunk to delay the computation. let not_found_to_option f = try Some (f ()) with Not_found -> None On the contrary look at: let from_option exn = function | Some x -> x | None -> raise exn Example: from_option Not_found (List.find p xs) Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
> 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 | 'B ]) -> 'a [ 'B ] > > and so on. > This is what PML does ... and what is nice is that is does not even require the exception to be garded ... > > Someone would have to write a new type system for that though. > Yes, but this require very little new technology : a function having one type or two as return type is basically the same ... and polymorphic variant are very well suited to be the default practice for exception (as in your f3 example). The only questions (I think) are - complexity of the algorithm (I think it shoud be OK) - readability of inferred types (one could hide exception types by default ?) Cheers, Christophe > MfG > Goswin > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > signature.asc Description: OpenPGP digital signature ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
On 05/31/2010 08:24 PM, David Allsopp wrote:
> Goswin von Brederlow wrote:
>
>>> 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). Recovering from such
>>> exceptions properly is still tricky though. Since OCaml lacks
>>> 'finally', you either have to use a 'finally' impl from a library, or
>>> modify your code to not need it (eg. turning calls to 'open_in' and
>>> 'open_out' into a kind of continuation-passing style). Or for small
>>> programs, abort the program and don't deal with recovery at all.
>>>
>>> All in all, this is not ideal for writing correct programs. Some sort
>>> of exception analysis would be most welcome.
>>
>> 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
>> | 'B ]) -> 'a [ 'B ]
>>
>> and so on.
>>
>>
>> Someone would have to write a new type system for that though.
>
> Would it be more practical to have that analysis as part of the .annot file?
> Presumably a patch which merged and updated the codebase of ocamlexc to
> produce exception-annotations in that manner might have a chance of making
> it into the OCaml compiler itself. I'm guessing that what you're getting at
> is the ability to see from your code that an exception could escape at any
pattern-match like exhaustive check that all cases are covered could be
useful.
try
...
with Not_found -> ...
error: exception catch clause is not exhaustive, exceptions not covered:
.
Maybe using a separate keyword, or a compile-time flag for this?
> given point rather than trying to add Java-style "checked exceptions" to
> OCaml?
>
I think there are 2 things to watch out when looking at Java and exceptions:
- if a function throws too many exceptions, you sometimes see things
like "throws Exceptions", or "catch (Exception e) { // ignore }" in Java
code, which are completely useless, and might even lead to bugs
(silently ignoring all exceptions)
- throwing an exception when a lookup doesn't find something is not
always the best. Look at Java's class loader which throws an exception
when a class is not found (pretty common when loading plugins) instead
of returning null.
I think that lookup functions should come in 2 flavours:
- one that doesn't use exceptions (uses option types), for example
'find'. The key you are looking for may or may not be there
- one that uses exceptions, for example 'get'. You know that the key is
there (or should be there), and you want the value. If the key isn't
there its probably a bug, or a very rare condition so the exception is
good here. I think the exception variant could even be generated
automatically as a wrapper to the option variant (not viceversa)
Best regards,
--Edwin
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
On Mon, May 31, 2010 at 9:30 PM, Nicolas Pouillard 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 case of Not_found > instead of the other way around for the following reason: > > * The typechecker does not remind us to catch the exception. > * We need a custom handler per exception. > * We need to take a thunk to delay the computation. > > let not_found_to_option f = > try Some (f ()) > with Not_found -> None > > On the contrary look at: > > let from_option exn = function > | Some x -> x > | None -> raise exn > > Example: from_option Not_found (List.find p xs) > 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. When I use the unmodified calls, I always handle Not_found right away, close to call point -- either by directly catching it, or by using a higher-order function, like an iterator that expects Not_found instead of None from the callee. Anyway, I vote for "option"ising all of the standard library and providing the function "unsome" raising a string with source code location of its call. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Static exception analysis or alternative to using exceptions
> 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 in Printexc. I use the following function wrapper : let verbose_func func x = try func x with exn -> Printf.printf "Test error %s\n%!" (Pinrtexc.to_string exn); Printf.printf "%s\n%!" (Printexc.get_backtrace ()); raise exn in ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
