Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use raises wrong exception #60

Closed
1 of 5 tasks
JohnReppy opened this issue Jul 15, 2022 · 1 comment
Closed
1 of 5 tasks

Use raises wrong exception #60

JohnReppy opened this issue Jul 15, 2022 · 1 comment
Assignees
Labels
bug Something isn't working compiler problem with compiler gforge bug (or feature request) ported from smlnj-gforge repository invalid This doesn't seem right

Comments

@JohnReppy
Copy link
Contributor

JohnReppy commented Jul 15, 2022

Version

110.96

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

vista

Processor

x86 (32-bit)

Component

Core system

Severity

Minor

Description of the problem

When exported code (i.e., by exportML or exportFn) calls "use" and the
used code raises an exception, the exception we get isn't the one that
was raised, but ExnDuringExecution instead.

This happens in any code exported by exportFn, and it happens in code
exported by exportML if "use" is called before the REPL goes back to
console for input.

Additional comments:
There's a workaround: always use exportML and use a script to send
console input to start the program. But that's really clunky.

Transcript

$ sml @SMLload=bug.x86-win32
[opening bug2.sml]
ExnDuringExecution

Expected Behavior

No response

Steps to Reproduce

(* bug1.sml *)

fun foo _ =
   (
   use "bug2.sml" handle exn => print (General.exnMessage exn);
   OS.Process.success
   );

SMLofNJ.exportFn ("bug", foo);
(* bug2.sml *)

(raise Div) : unit

Additional Information

No response

Email address

crary@cs.cmu.edu

Comments from smlnj-gforge

Original smlnj-gforge bug number 303

Submitted via web form by Karl Crary crary@cs.cmu.edu on 2022-03-28 at 14:53:00

comment by @dmacqueen on 2022-04-12 18:28:00 +000 UTC

This is not a bug but a "misuse" of the "use" function, which is only intended to work in the top-level REPL.

@JohnReppy JohnReppy added bug Something isn't working compiler problem with compiler gforge bug (or feature request) ported from smlnj-gforge repository labels Jul 15, 2022
@JohnReppy JohnReppy self-assigned this Jul 15, 2022
@JohnReppy JohnReppy added the invalid This doesn't seem right label Jul 24, 2022
@JohnReppy
Copy link
Contributor Author

I am classifying this issue as a "feature", not a bug.

The root of the problem is the combination of use and exportML (I'm assuming that use is the being applied to bug1.sml to build the heap image). The implementation of the use function tracks if it is invoked inside another instance of use. Since exportML preserves this state, the use of bug2.sml appears as if it is nested inside another instance of use. The clean workaround is to delay the exportML until after the code is compiled.

(* bug1.sml *)

fun foo _ = (
      use "bug2.sml" handle exn => print (General.exnMessage exn);
      OS.Process.success);

fun export () = SMLofNJ.exportFn ("bug", foo);

and then one can do the following in the shell:

echo "export();" | sml bug1.sml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler problem with compiler gforge bug (or feature request) ported from smlnj-gforge repository invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

1 participant