Question about value/reference semantic and closure capture

[statementreply]

Value/reference semantic

吾有一列。名之曰「甲」。
有列「甲」。名之曰「乙」。
充「乙」以一。
噫。夫「甲」。書之。
噫。夫「乙」。書之。

Should the code above print [] [1] or [1] [1]?

吾有一列。名之曰「空列」。
吾有一物。名之曰「甲」。其物如是。
	物之「「數」」者。數曰一。
	物之「「列」」者。列曰「空列」。
是謂「甲」之物也。
有物「甲」。名之曰「乙」。
昔之「乙」之「「數」」者。今二是矣。
夫「乙」之「「列」」。充其以三。
噫。夫「甲」之「「數」」。夫「甲」之「「列」」。書之。
噫。夫「乙」之「「數」」。夫「乙」之「「列」」。書之。

Should the code above print 1 [] 2 [3] or 1 [3] 2 [3] or 2 [3] 2 [3]?

吾有一術。名之曰「反」。欲行是術。必先得一數。曰「甲」。是術曰。
	乘「甲」以負一。昔之「甲」者。今其是矣。乃得「甲」。
是謂「反」之術也。

有數一。名之曰「乙」。
施「反」於「乙」。
噫。夫「乙」。書之。

Should the code above compile? If so, should it print 1 or -1?

吾有一術。名之曰「充」。欲行是術。必先得一列。曰「甲」。是術曰。
	充「甲」以一。乃得「甲」。
是謂「充」之術也。

吾有一列。名之曰「列」。
施「充」於「列」。
噫。夫「列」。書之。

Should the code above compile? If so, should it print [] or [1]?

吾有一術。名之曰「充」。欲行是術。必先得一列。曰「甲」。是術曰。
	吾有一列。名之曰「乙」。
	凡「甲」中之「丙」。充「乙」以「丙」也。
	充「乙」以一。昔之「甲」者。今「乙」是矣。
	乃得「甲」。
是謂「充」之術也。

吾有一列。名之曰「列」。
施「充」於「列」。
噫。夫「列」。書之。

Should the code above compile? If so, should it print [] or [1]?

Closure capture

吾有一術。名之曰「外」。是術曰。
	吾有一術。名之曰「內」。欲行是術。必先得二數。曰「甲」。曰「乙」。是術曰。
		加「甲」於「乙」。乃得矣。
	是謂「內」之術也。
	施「內」於一。乃得矣。
是謂「外」之術也。

施「外」。名之曰「甲」。
噫。施「甲」於一。書之。

Should the code above compile and print 2?

吾有一術。名之曰「外」。是術曰。
	有數一。名之曰「甲」。
	吾有一術。名之曰「內」。欲行是術。必先得一數。曰「乙」。是術曰。
		加「甲」於「乙」。乃得矣。
	是謂「內」之術也。
	乃得「內」。
是謂「外」之術也。

施「外」。名之曰「甲」。
噫。施「甲」於一。書之。

Should the code above compile and print 2?

吾有一術。名之曰「外」。是術曰。
	有數一。名之曰「甲」。
	吾有一術。名之曰「內」。欲行是術。必先得一數。曰「乙」。是術曰。
		加「甲」於「乙」。乃得矣。
	是謂「內」之術也。
	昔之「甲」者。今二是矣。
	乃得「內」。
是謂「外」之術也。

施「外」。名之曰「甲」。
噫。施「甲」於一。書之。

Should the code above compile? If so, should it print 2 or 3?

吾有一術。名之曰「外」。是術曰。
	有數零。名之曰「甲」。
	吾有一術。名之曰「內」。欲行是術。必先得一數。曰「乙」。是術曰。
		加「甲」以「乙」。昔之「甲」者。今其是矣。乃得「甲」。
	是謂「內」之術也。
	乃得「內」。
是謂「外」之術也。

施「外」。名之曰「甲」。
噫。施「甲」於一。書之。
噫。施「甲」於二。書之。
噫。施「甲」於三。書之。
施「外」。名之曰「乙」。
噫。施「乙」於三。書之。
噫。施「乙」於二。書之。
噫。施「乙」於一。書之。

Should the code above compile? If so, should it print 1 2 3 3 2 1 or 1 3 6 3 5 6 or 1 3 6 9 11 12?

[LingDong-]

@statementreply wow, deep questions.

Value/reference semantic

Currently in wenyan-lang arrays are aliased when assigned to a new variable, like in JavaScript, python, etc., and current behavior seems to reflect that correctly. Immutable types are copied on the other hand.

Feel free to suggest another behavior, e.g. shallow copy, deep-copy, copy-assignment in C++, etc. if you think there are reasons it should be preferred.

One thing I'm thinking is maybe we can utilize two different syntax (which are currently equivalent) to distinguish aliasing and copying.

// Hypothetically:
夫「甲」。名之曰「乙」。// alias
吾有一列。曰「乙」。名之曰「甲」// copy

Also, since I think 曰「乙」名之曰「甲」 can be a little bit confusing to read, I'm thinking about adding 同 to the syntax like so:

吾有一列。同「乙」。名之曰「甲」

Again, discussions are very welcome :)

Closure capture

I think current behavior is expected & desirable. What do you find wrong?

• In the third example, reassignment happens before calling of the inner function, so 3 is right.
• In the forth example, the inner function modifies 甲 in its parent scope, because itself does not have a definition for 甲, so the output is 1 3 6 3 5 6.

Thanks for bringing this up and feel free to discuss what you think would be better!

[antfu]

I would personally prefer alias/reference as default behaviors for arrays and objects (as most of languages did). I think we can have some methods in stdlib for deep cloning

[statementreply]

Closure capture... What do you find wrong?

Nothing wrong.

As we are already taking different paths from JavaScript (e.g. towards strong typing), I believe that eventually we'll need to decide whether wenyan should follow other JavaScript design choices.

Currently in wenyan-lang arrays are aliased

... another behavior, e.g. shallow copy, deep-copy, copy-assignment in C, etc.

I suggest that we do either of the following, but not a mixture of them (e.g. Java String), for each particular situation (數/爻/言/列/物/術 variables, function arguments, closure captures, etc.).

1. Value semantic

   • can't be nullable
   • default to default value (0/empty/...) if it exists; must be initialized if not
   • deep copy (copy content)
   • deep assignment (modify content)
   • deep comparison (compare content)
   • deep mutability (mutability of content; reference is always immutable)

   This is the current behavior of 數/爻.

2. Reference semantic

   • could be nullable
   • default to null if nullable; must be initialized if not
   • shallow copy (copy reference)
   • shallow assignment (modify reference)
   • shallow comparison (compare reference)
   • shallow mutability (mutability of reference; content mutability might be notated separately)

   This is close to the current behavior of 列/物, except that their default values are new Array and new Object.

3. Alias semantic

   • could be nullable
   • default to null if nullable; must be initialized if not
   • shallow copy (alias)
   • deep assignment (modify the linked object)
   • deep comparison (compare the linked objects)
   • deep mutability (mutability of the linked object; alias is always immutable)

   This is the current behavior of closure captures.