-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
[@bs] at application side treats f ()
as 0-arity application
#674
Comments
I took a look at this. Here are some thoughts:
Here are some suggestions for a new 0-arity application syntax:
let () = f () [@u0] (* or any other attribute different than [@u] *)
let () = Uncurried.apply0 f
let () = f $$u
let>$ () = f ()
let%u0 () = f () |
Sorry for the probably stupid questions, but I never understood this:
|
so 0-arity is different than n-arity for uncurried because:
|
Thanks for the explanation. About the options available, as a user, option 1 seems more "natural" to me, I am not sure about technical implications and how confusing it might be to other users. I am also surprised this didn't come up earlier? Sounds like a really strong limitation. 🤔 |
Is it possible to use Otherwise my vote is for option 1. |
|
It's technically possible, but that doesn't look like function application anymore. Something to ponder. |
This seems to come up especially for external make :
((resolve:(('a -> unit)[@u]) -> reject:((exn -> unit)[@u]) -> unit)
[@mel.uncurry]) ->
'a t = "Promise"
[@@mel.new] However, both So we could fix the immediate case with external make :
((resolve:('a -> unit) -> reject:(exn -> unit) -> unit)[@mel.uncurry]) -> 'a t
= "Promise"
[@@mel.new] This would be a breaking change, but so would changing the 0-arity application syntax. |
OK, I suppose the issue occurs when you pass type 'a t
external make :
((resolve:('a -> unit) -> reject:(exn -> unit) -> unit)[@mel.uncurry]) -> 'a t
= "Promise"
[@@mel.new]
external makeU :
((resolve:(('a -> unit)[@u]) -> reject:((exn -> unit)[@u]) -> unit)
[@mel.uncurry]) ->
'a t = "Promise"
[@@mel.new]
let r resolve =
Js.log "resolve normal";
resolve "normal"
let rU resolve =
Js.log "resolve uncurried";
resolve "uncurried" [@u]
let x = make (fun ~resolve ~reject -> r resolve)
let xU = makeU (fun ~resolve ~reject -> rU resolve) and the generated JS: $ melc -ppx melppx x.ml
// Generated by Melange
'use strict';
var Curry = require("melange.js/curry.js");
function r(resolve) {
console.log("resolve normal");
return Curry._1(resolve, "normal");
}
function rU(resolve) {
console.log("resolve uncurried");
return resolve("uncurried");
}
var x = new Promise((function (resolve, param) {
r(resolve);
}));
var xU = new Promise((function (resolve, param) {
rU(resolve);
}));
exports.r = r;
exports.rU = rU;
exports.x = x;
exports.xU = xU;
/* x Not a pure module */ |
Hm, and it seems that Input: type 'a t
external make :
((resolve:(('a -> unit)[@bs.uncurry]) -> reject:(exn -> unit) -> unit)[@bs.uncurry]) -> 'a t
= "Promise"
[@@bs.new]
let r resolve =
Js.log "resolve normal";
resolve "normal"
let x = make (fun ~resolve ~reject -> r resolve) Output: // Generated by Melange
import * as Curry from "melange.js/curry.js";
function r(resolve) {
console.log("resolve normal");
return Curry._1(resolve, "normal");
}
var x = new Promise((function (resolve, reject) {
r(resolve);
}));
export {
r ,
x ,
}
/* x Not a pure module */ |
I propose we postpone this for v3 to give us some more room for brainstorming. In the meantime, we should probably document this in the website as an edge case. |
#949 is progressing nicely, though a bit more invasive than I'd like. I didn't expect this would touch so much code. There are currently 2 open questions:
|
What about
This sounds great. |
probably worth it to be consistent indeed. I don't like Another option I thought about was |
I also prefer |
In our meeting today we decided to:
|
Consider this gist:
which errors with
The issue is that Melange treats
f ()[@bs]
syntax as 0-arity application.If we do
then it compiles.
I think 0-arity applications should have another syntax.
The text was updated successfully, but these errors were encountered: