Skip to content

Missing sub-expression variable declaration #974

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

Closed
barkmadley opened this issue Dec 5, 2016 · 2 comments
Closed

Missing sub-expression variable declaration #974

barkmadley opened this issue Dec 5, 2016 · 2 comments
Labels

Comments

@barkmadley
Copy link

barkmadley commented Dec 5, 2016

I ended up writing something like this expression at some point, and I'm not sure if I had hit a documented problem, or if bucklescript is missing some Javascript semantics:

let _ =
  Js.Undefined.to_opt (Js.Undefined.return "") = Some ""

This produces a runtime error regarding an undefined variable v, because of the generated Javascript:

// Generated by BUCKLESCRIPT VERSION 1.3.0 , PLEASE EDIT WITH CARE
'use strict';

var Caml_obj = require("bs-platform/lib/js/caml_obj");

Caml_obj.caml_equal((v = "", v === undefined ? /* None */0 : [v]), /* Some */[""]);

/*  Not a pure module */

It is simple enough to work-around by explicitly binding the Js.Undefined.return "" expression to a name, but it does seem like the bucklescript compiler should be able to declare new variables for any free ones it needs to create inside sub-expressions.

bsc.exe -v output:

The OCaml compiler, version BuckleScript 1.3.0 (Using OCaml4.02.3+BS )
Standard library directory: /home/bark/projects/bs-connect3/node_modules/bs-platform/lib/ocaml

Actually bs-platform is at version 1.3.1. I guess the -v output also needs to be updated.

@bobzhang
Copy link
Member

bobzhang commented Dec 5, 2016

Thanks for reporting the bug. @barkmadley I am travelling, will fix this when I come back

@bobzhang bobzhang added the bug label Dec 5, 2016
bobzhang added a commit that referenced this issue Dec 8, 2016
note current architecture requires primitive/ external call to return an expression(not a block), in the future, when refactoring, we should lift such restriction for better inlining
@bobzhang
Copy link
Member

bobzhang commented Dec 8, 2016

fixed in #982

bobzhang added a commit that referenced this issue Dec 8, 2016
@bobzhang bobzhang closed this as completed Dec 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants