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

Fatal error: Bad machine state in stepRobot: FApp of non-function #1796

Closed
kabuhr opened this issue Apr 4, 2024 · 2 comments
Closed

Fatal error: Bad machine state in stepRobot: FApp of non-function #1796

kabuhr opened this issue Apr 4, 2024 · 2 comments
Labels
Bug The observed behaviour is incorrect or unexpected.

Comments

@kabuhr
Copy link

kabuhr commented Apr 4, 2024

There appears to be a scoping problem with <- bindings that shadow pure bindings. The following commands on the base console generate a fatal "FApp of non-function" error:

> def x = \x.x end
> def foo = x <- return 0; noop end
> foo
it0 : unit = ()
> return (x 42)
it1 : int = 42
> foo; return (x 42)
[Fatal error: Bad machine state in stepRobot: FApp of non-function ∪· E· (return (0 ◂42▸))
@kabuhr kabuhr added the Bug The observed behaviour is incorrect or unexpected. label Apr 4, 2024
@kabuhr kabuhr closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2024
@kabuhr
Copy link
Author

kabuhr commented Apr 4, 2024

Looks like this is a duplicate of issue #681.

@byorgey
Copy link
Member

byorgey commented Apr 4, 2024

@kabuhr Yes, I think you're right that this is #681, but I appreciate the report! I think I know how to fix it, but unfortunately it is rather complex and I can't really give an estimate on when it will happen.

mergify bot pushed a commit that referenced this issue Jun 19, 2024
…tate (#1928)

The big idea of this PR is to add a new type of CESK machine state, `Suspended`, which is a state the base robot automatically goes into after completing execution of a program entered at the REPL.  It is as if the base robot is still within the local context of any definitions etc. entered previously, just printed out an "intermediate result", and is now waiting to find out what the next term to be executed will be.  This allows us to treat `def` as syntax sugar for `let` and results in a much cleaner way to manage the context of definitions, which in turn allows us to remove a whole lot of special cases and fixes several annoying bugs.  See #1087 for more explanation and discussion.

Things that are **deleted** (!) by this PR:
- `TDef` (`def` is now just syntax sugar for `let`) (#997)
- `VResult` (we no longer need to return anything other than plain values)
- `FUnionEnv`, `FDiscardEnv`, `FLoadEnv` (we no longer need machinery to collect up definitions while evaluating terms)
- `ProcessedTerm` (just a plain `TSyntax` (i.e. `Syntax' Polytype`) is now enough)
- `Module` (it only existed to package up some contexts with typechecked terms, but we don't need them anymore)
- `RobotContext` and `topContext` (we don't need to store those things separately any more, they are just stored in the `CESK` machine where they belong)

Additions/changes:
- The `Requirement` module is split into `Requirements.Type` and `Requirements.Analysis` to avoid circular module imports
- New `Suspended` state for the CESK machine
- `def` and `tydef` are now allowed anywhere (even nested inside other definitions etc.) since `def x = y end; z` is just syntax sugar for `let x = y in z` (see #349)
- Code size decreased slightly for many programs using `def`, since `def` is now a synonym for `let`, and consecutive `def`s therefore do not require a `bind`.

Closes #1087.  Fixes #681 (hence also #736, #1796). Fixes #1032. Closes #1047. Closes #997. Fixes #1900. Fixes #1466. Fixes #1424.

See also #636.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug The observed behaviour is incorrect or unexpected.
Projects
None yet
Development

No branches or pull requests

2 participants