-
Couldn't load subscription status.
- Fork 38
implement syntax for arity zero vs arity one in uncurried application #139
Conversation
|
Not sure if there is any difference, but it might also be worth considering converting it into |
|
Hummmm not too sure |
|
@IwanKaramazow the proposal looks good to me. |
ab23e08 to
bb822fd
Compare
|
would my proposal make the implementation a bit more clean? @IwanKaramazow |
|
@bobzhang not 100%, it results in a type-error: https://rescript-lang.org/try?code=DYUwLgBAZgdhC8EAUA6CB9AlAgfMzA3AFBGyoDeADAUpgL6ZA It could be changed to: |
|
@IwanKaramazow it is because we are more strict with sequence types. @ryyppy 's proposal also makes sense, the idea is not to introduce a magic name in the generated code |
|
@IwanKaramazow @bobzhang I don't understand how I personally use |
|
Yea, let’s go with ignore(). Will finish this tomorrow |
a9ff68c to
c63102f
Compare
|
Ok, this PR is now ready to be merged. The semantics are summarised by the following table: |
|
@IwanKaramazow I am happy to merge it, would you resolve the conflicts? |
Since there is no syntax space for arity zero vs arity one,
we parse
`fn(. ())` into
`fn(. {let __res_unit = (); __res_unit})`
when the parsetree is intended for type checking
`fn(.)` is treated as zero arity application
b206460 to
d247724
Compare
|
@bobzhang rebased! Do we merge? |
|
yes! |

Since there is no syntax space for arity zero vs arity one, we parse
fn(. ())intofn(. {let __res_unit = (); __res_unit})when the parsetree is intended for type checking
fn(.)is treated as zero arity applicationFixes #138