Custom named arguments #276

New Issue

2020-08-19T20:09:31+09:00

zxq9 commented

2020-08-19 20:09:31 +09:00

(Migrated from gitlab.com)

Created by: radrow

Named arguments usually make function declarations much more clear and can vanish a lot of unnecessary comments. Proposed syntax:

entrypoint fit(*X : matrix, *y : vector, *seed=0 : int) = ...

entrypoint train() =
   ...
   fit(X=data, y=labels)
   fit(X=data, y=labels, seed=123)

Adding * before the argument name would force the user to call the function by referring the name of this arg. There should also be an option to provide defaults for the named parameters.

~~In my vision this could be implemented in typed FATE calls as well – there should be a separated payload with named arguments of form [{name : string(), value : fate_value()}]~~

*Created by: radrow* Named arguments usually make function declarations much more clear and can vanish a lot of unnecessary comments. Proposed syntax: ``` entrypoint fit(*X : matrix, *y : vector, *seed=0 : int) = ... entrypoint train() = ... fit(X=data, y=labels) fit(X=data, y=labels, seed=123) ``` Adding `*` before the argument name would force the user to call the function by referring the name of this arg. There should also be an option to provide defaults for the named parameters. <s>In my vision this could be implemented in typed FATE calls as well – there should be a separated payload with named arguments of form `[{name : string(), value : fate_value()}]`</s>

zxq9 commented

2020-08-19 20:59:29 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

What is the case for carrying this through to FATE? Current named arguments (like signature in some oracle/name operations) are compiled to normal arguments in FATE. The advantage of not touching FATE is that then it won't break consensus.

*Created by: UlfNorell* What is the case for carrying this through to FATE? Current named arguments (like signature in some oracle/name operations) are compiled to normal arguments in FATE. The advantage of not touching FATE is that then it won't break consensus.

zxq9 commented

2020-08-19 21:16:27 +09:00

(Migrated from gitlab.com)

Created by: radrow

In my opinion it would provide good additional control over the remote calls. Currently we have only small predefined set of named arguments in certain functions – if we introduce more freedom in the naming I believe this would be a valuable assertion for example in protected calls.

*Created by: radrow* In my opinion it would provide good additional control over the remote calls. Currently we have only small predefined set of named arguments in certain functions – if we introduce more freedom in the naming I believe this would be a valuable assertion for example in protected calls.

zxq9 commented

2020-08-19 21:50:34 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

I don't think the extra assertions would be worth the implementation effort, consensus breakage, and gas overhead. Do you have a concrete scenario where this would be really valuable?

*Created by: UlfNorell* I don't think the extra assertions would be worth the implementation effort, consensus breakage, and gas overhead. Do you have a concrete scenario where this would be really valuable?

zxq9 commented

2020-08-24 20:07:24 +09:00

(Migrated from gitlab.com)

Created by: radrow

Any scenario where one would need to protect their calls that uses named args. For example I would expect that

con.entr(protected=true, amount=10, duration=20)

will verify whether this entrypoint actually exposes the values and that there is no typo in the argument names. If we are going to allow arbitrary named&positioned arguments without FATE extension we will need to somehow unify their order during the compilation process – most likely lexicographic, which can lead to some bad consequences in case of a typo;

contract C =
  entrypoint sort(*inplace : bool, *inverted : bool, stuff : list(int)) = ...

let c : C
c.sort(protected=true, inplace=true, inevrted=false, [1,2,3])

(note that "inplace" < "inverted" but "inplace" > "inevrted")

My point is that in Sophia we prefer defensive programming and being 101% that a contract is correctly set is crucial – and this solution would definitely boost it up.

*Created by: radrow* Any scenario where one would need to protect their calls that uses named args. For example I would expect that ``` con.entr(protected=true, amount=10, duration=20) ``` will verify whether this entrypoint actually exposes the values and that there is no typo in the argument names. If we are going to allow arbitrary named&positioned arguments without FATE extension we will need to somehow unify their order during the compilation process – most likely lexicographic, which can lead to some bad consequences in case of a typo; ``` contract C = entrypoint sort(*inplace : bool, *inverted : bool, stuff : list(int)) = ... ``` ``` let c : C c.sort(protected=true, inplace=true, inevrted=false, [1,2,3]) ``` (note that `"inplace" < "inverted"` but `"inplace" > "inevrted"`) My point is that in Sophia we prefer defensive programming and being 101% that a contract is correctly set is crucial – and this solution would definitely boost it up.

zxq9 commented

2020-08-24 20:44:44 +09:00

(Migrated from gitlab.com)

Created by: UlfNorell

This would be a type error at the Sophia level. No need to involve FATE.

I suppose it would protect against mistakes in the interface stub, but if you're not generating that from the source code of the contract you want to call all bets are off anyway.

At the end of the day, this is a major change to FATE, to catch a few more, not very common mistakes (and only if you actually use named arguments). I hardly think it's worth it.

*Created by: UlfNorell* This would be a type error at the Sophia level. No need to involve FATE. I suppose it would protect against mistakes in the interface stub, but if you're not generating that from the source code of the contract you want to call all bets are off anyway. At the end of the day, this is a major change to FATE, to catch a few more, not very common mistakes (and only if you actually use named arguments). I hardly think it's worth it.

zxq9 commented

2020-08-25 23:18:12 +09:00

(Migrated from gitlab.com)

Created by: radrow

Okay, moving it to the interface can do the job. Removing the consensus-breaking tag, let this issue focus just on the custom named arguments in the frontend

*Created by: radrow* Okay, moving it to the interface can do the job. Removing the `consensus-breaking` tag, let this issue focus just on the custom named arguments in the frontend

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#276