Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003959OCamltoplevelpublic2006-01-21 23:062017-02-27 14:56
ReporterMartin Jambon 
Assigned Togasche 
PlatformOSOS Version
Product Version3.09.0 
Target VersionFixed in Version 
Summary0003959: no exit on bad #use in ocaml scripts
DescriptionThe ocaml command or a custom toplevel, when used in non-interactive mode, does not stop when it encounters a directive with a valid name but an invalid argument:

1) Valid directive name, wrong argument (should exit):

[droopy] ~/tmp % cat
#use "abc";;
print_endline "hello";;
[droopy] ~/tmp % ocaml && echo success
Cannot find file abc.

2) Wrong directive name (works as expected):

[droopy] ~/tmp % cat
#abcde "abc";;
print_endline "hello";;
[droopy] ~/tmp % ocaml && echo success
Unknown directive `abcde'.
Additional InformationThis problem is present at least in OCaml 3.08.4 and OCaml 3.09.1 (x86 Linux).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
gasche (developer)
2014-08-15 17:16

In fact the toplevel currently ignores any error arising from running a directive, as long as the directive has been found and is passed arguments of the expected type and arity. This applies to #use but also to #load for example.

Do we really want to change this behavior, though? It's not a very hard change to make, but I'm worried people could actually rely on it.

A use-case I had in mind is the following: when working in a project with several compilation units (say {a,b,c}.ml), I would often create a local .ocamlinit file with the #loads in dependency order:
  #load "a.cmo";;
  #load "c.cmo";;
  #load "b.cmo";;

Then, running a toplevel would put me in an environment where the modules of the project are available. But if one source file was being modified and wouldn't compile (or its compiled unit were out-of-date with its new dependencies), the script would still work until the relevant point, and leave me in a state where the dependencies were available, only not the failing file.

That's not a terribly important use-case and I'm fine with changing the behavior. I still wonder whether some other people rely on this in more important ways.
Martin Jambon (reporter)
2014-08-15 18:41

Outside of a REPL, it seems proper behavior that any invalid instruction would cause the program to fail.

Invalid instructions can and should be tolerated when the user is present to read the error messages and react if the program goes haywire. For that, the current behavior is fine.
gasche (developer)
2014-08-15 20:09

I just commited a first approach in a dedicated branch [^]

the commit: [^]

the patch: [^]

I think the patch works as you would expect. That said, it changes the public interface of toplevel directives (which may be added by external users, eg. ocamlfind's #require directive); it is a non-invasive change as I added a new exception that is not used so far:
  exception Directive_failure

It should make us pause and wonder what a good interface for this new feature (signalling errors) is. I would naturally add a (string option) argument to the exception, to let users optionally attach an error message.
  exception Directive_failure of (string option)

I wonder whether this is a bug and a feature. If we can include a patch (this one or an improved version) to "fix" the bug, it can go in 4.02. If we find out it's a new feature that needs design consideration, it would be better to commit in trunk only.
Martin Jambon (reporter)
2014-08-15 20:59

I like the proposed solution with the Directive_failure exception and no argument.

I don't see what we would gain from having an optional error message string in the exception since it can be printed out before raising the exception anyway. However it might be worth asking someone who's familiar with writing custom directives or custom OCaml toplevels.
dim (developer)
2014-08-18 11:05

Having the error message as argument of the directive instead of printing would allow a custom toplevel to format it differently, for instance print it in red.
Martin Jambon (reporter)
2014-09-25 18:52

Just to be clear, I was nitpicking. I do like the proposed solution involving exception Directive_failure of (string option).
gasche (developer)
2016-04-18 21:03

We haven't worked on that since the last release, and I'm postponing to 4.04.

I considered rebasing my patch on top of the current trunk and sending a github pull request, but I'm not sure I like the idea anymore: adding an exception as a side-channel return means that code using Topdirs directives directly will break silently, for example utop. If we change the return mode of exceptions to contain some failure information (or messages to print to the user, etc.), maybe we should rather make them part of the type, so that the code of people relying on Topdirs breaks at compile-time rather than runtime.

Jérémie (dim), you are to my knowledge the main user of toplevel internals, what do you think?

- Issue History
Date Modified Username Field Change
2006-01-21 23:06 Martin Jambon New Issue
2006-03-29 16:32 doligez Status new => acknowledged
2006-03-29 16:42 doligez Category Incoming => OCaml general
2012-07-11 16:46 doligez Target Version => 4.01.0+dev
2012-07-31 13:37 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-11 14:20 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-07-02 16:19 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-07-02 16:20 doligez Status acknowledged => confirmed
2013-07-24 11:51 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-08-15 17:16 gasche Note Added: 0012010
2014-08-15 17:52 gasche Status confirmed => feedback
2014-08-15 18:41 Martin Jambon Note Added: 0012011
2014-08-15 18:41 Martin Jambon Status feedback => new
2014-08-15 20:09 gasche Note Added: 0012013
2014-08-15 20:24 gasche Status new => confirmed
2014-08-15 20:59 Martin Jambon Note Added: 0012014
2014-08-18 11:05 dim Note Added: 0012017
2014-08-18 15:13 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-25 16:28 doligez Target Version undecided => 4.03.0+dev / +beta1
2014-09-25 18:52 Martin Jambon Note Added: 0012206
2016-04-18 21:03 gasche Note Added: 0015795
2016-04-18 21:03 gasche Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2017-02-16 14:01 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-02-27 14:56 doligez Assigned To => gasche
2017-02-27 14:56 doligez Status confirmed => assigned
2017-02-27 14:56 doligez Category -OCaml general => toplevel
2017-02-27 14:56 doligez Target Version undecided =>

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker