RSP-1 – AaribaScript Goals and Design

[ghost]

This RFC proposes a specification for a specific domain language to describe game desin rules. It will permits to change those rules within Renaissance without having to neither knowing Rust nor recompiling Lycan.

[Nemikolh]

If you agree, I would like to add a commit to that PR that clarifies the conventions about "effects". I still intend to write a separate PR about them to discuss their use and more broadly their precise definition.

Would that be okay for you ?

[ghost]

Please yourself!

[ghost]

If I undestand well the second part of your comment, you want to write a second file, that is a separate RFC, dedicated to Lycan effects?

[Nemikolh]

Yeah, you understood me correctly. I think it has many specifics that are non-relevant for this RFC like their creation / management.

[ghost]

Indeed! About that RFC, I will wait your commit before writting my own updates.

[Nemikolh]

I just realised while working on the rule-editor that our little script language should have a name.
Any ideas?

So far I opt for: RuleScript.

[ghost]

That's a very descriptive name! As a reminder, we decided the project should be called Aariba after the name of a SO goddess. So why not simply AaribaScript?

Thanks for the commit. I will try to add my own proposal as soon as possible.

[Nemikolh]

Oh! I completely forgot about that one! Yeah it is much more natural to call it like that. I'll refactor my classes for the rule editor.

[ghost]

Okay, so a busy week is coming. I will try to push my modification as soon as possible (probably tomorrow), but I cannot make any promises.

[Nemikolh]

I just realized while working on the if PEG implementation that we haven't described in the execution model if the block after the if should create a scope (like in C-like languages) or not (like in javascript). I tend to think that we should. What do you think @Ikyushii and @Vaelden ?

[ghost]

My first through was “of course, we need to have scoped variable”. And then I realized that in AaribaScript, definition matter and is testable so... Well, I don't know. I fear scripts will be less readable if we follow the javascript way.

[Nemikolh]

I tend to agree. To be fair adding scope support for the editor is just adding 4 lines of code so we can still go with it first and go backward if this was a bad idea.

Would you mind if I edit the RSP to add mention of it in the Execution Model section?

[ghost]

Before doing that, we should probably think about how to get out of a scope.
Basically what would cause problem is if for example we want just a default value:

if $a {
    dmg = $a;
} else {
    dmg = 0;
}
*** do lots of stuff here with dmg ***

If we don't have any way of getting this "dmg" local variable out of the scope (and I don't want to use a global for this), then we would have to entirely duplicate the code in each of the branches.

[ghost]

One can simply write:

dmg = default_value;
if $a {
    dmg = $a;
} else {
    dmg = 0;
}
*** do lots of stuff here with dmg ***

or even:

dmg = 0;
if $a {
    dmg = $a;
}
*** do lots of stuff here with dmg ***

For this particular point, we might also want to add a dedicated syntax? Something like dmg = <expression with variables>? <default_value> for instance? Such as:

dmg = $a ? 0;
// more complex
dmg = $a * $b ? 0;
// dmg = $a * $b if $a AND $b are defined, 0 if not

Beside, is it easy to deal with scope variable within Lycan?

[Nemikolh]

I completely agree with @Ikyushii here, and I think that default deserve a custom syntax.
We actually had discussed that with @Vaelden and we were thinking about using || instead of ?.
But after seen your examples, ? looks far better !! 👍

Coming back to if, The problem lies in the definition of ill-formed programs. If you consider the following:

if $effect_a {
    dmg = 23;
    $hp -= dmg;
}

if $effect_b {
    factor = 2;
    $hp += dmg / 2; // Oops, dmg was not defined !
}

This program could be well-formed as long as $a always exists when $b does. With scoped if variable it would always fail.

I would say that as we can still try first in the editor to see how does it feels to have scopes.
If people likes it, then we can move forward and implement it in the aariba crate.

[ghost]

OK so if I understand correctly, you want the scope to just restrict the variable creation. Does it really make sense in our particular case, as we don't have variable declaration and every instruction is an assignment?

[ghost]

as we don't have variable declaration and every instruction is an assignment?

It would be true if there were a default value for each type variable and for any variable name, you would be able to use it whenever you want, even before first assignment.

[Nemikolh]

Okay I just want to make a recap, to concise the discussion:

So far several problems encountered:

• else clause for and if (no a problem, but the RSP needs to be updated to take that into account)
  This was suggested by @Vaelden during the discussion.

• Adding default in an assignment with

  <ident> = <expression_potentially_ill_formed> ? <default>

  The ? is sort of a catch mechanism for expressions. This was suggested by @Ikyushii.

• Scope, 3 solutions here:

  • Every assignment shadow the variable in the outer scope:

  a = 23;
  b = 10;
  if $global {
     a = 42 + b; // a will be 52 for this scope only
     c = 12;
  }
  // a is now 23 again and c is "not defined".

  • Every assignment changes an outer scope variable or create a new scope variable if none existed in the outer scope:

  a = 23;
  b = 10;
  if $global {
     a = 42 + b; // a will be 52 for this scope only
     c = 12;
  }
  // a is 52 and c is "not defined"

  • No scope:

  a = 23;
  b = 10;
  if $global {
     a = 42 + b; // a will be 52 for this scope only
     c = 12;
  }
  // a is 52 and c is 12

What do you think, what do you think make more sense and is easier to understand?

[ghost]

I'm confused. What's the $ means in your examples? Shouldn't be

a = 23;
b = 10;
if $b {
   a = 42 + $b;
   c = 12;
}

I think the proposals 2 and 3 are are readable and “computable by head” without headache, on the contrary proposal 1 is a very bad idea, not intuitive at all..

I think we should go for proposal 2.

[ghost]

From an implementation point of view, what is far easier is:

• Not have the ? for the default value. The argument is that right now an expression (right hand side of the =) only has to deal with f64 as value. If now we can have Undefined as well, I have to be paranoiac and check for it in every single operator except ?. Besides, this could be easily replaced by a simple if, that is handled in the "rules" part and not "expression".
• Having no scope: it is already working this way

With this I think we can cover all the use cases, it is probably the easiest to understand, and makes the implementation much easier for a language that we don't expect to use very often.

If later we think we need to change that, we can probably port the few (probably 3) scripts written in this language to whatever new syntax we want, but at the moment I'd rather keep things simple and not spend to much time on this.

[Nemikolh]

$ doesn't mean anything, It's just the convention for globals variable (the only one we can check against their presence). I've updated my examples to avoid more confusion. They're written to cover all the subtleties of the scope that we need to account for.

[ghost]

@Nemikolh: it's clearer that way.

@Vaelden: I'm not sure to follow you, but it's because I didn't look at your implementation. So, correct me if I'm wrong.

My proposal with the ? operator is only syntactic sugar. One can write:

dmg = 0;
if $a {
    if $b {
        dmg = $a * $b;
    }
}

It will have exactly the same result as my dmg = $a * $b ? 0.

This syntax only concerns global variable. Hence, something like that will fail if a was not defined before using it.

dmg = a * $b ? 0

This being said, I don't think this syntactic sugar is neither really needed nor critical. If you prefer using proposal 3 (because it's how the things are done right now) it's fine for me. But how do you want to deal with something like that:

a = 23;
b = 10;
if $global {
   a = 42 + b; // a will be 52 for this scope only
   c = 12;
}
d = c;

c might not exist at this point, with the proposal 3...

[Nemikolh]

I personally think that implementations problems should be discussed elsewhere.
The only things that should matter for the proposal is semantics of the language and its readability.
Furthermore, be honest, do you truly feels that:

dmg = 0;
if $a {
    if $b {
        dmg = $a;
    }
}

is more readable than:

dmg = $a * $b ? 0;

?

Besides, I don't see dealing with Undefined discussed here. I think you're getting confused too ;)
This:

dmg = $a * $b ? $c;

would be ill-formed if $c does not exists. So we don't have anything like Undefined value if we add the default operator ?.

With this I think we can cover all the use cases, it is probably the easiest to understand, and makes the implementation much easier for a language that we don't expect to use very often.

It's not about use cases but about readability and script semantics. Again I don't think you should mention implementation as an argument, we're not doing implementation driven RSP as far as I know.

I'd rather keep things simple and not spend to much time on this.

This is exactly the point of the discussion: Keep things simple and understandable that express user intuition.

In the end, once we agreed on this, It won't take much time to implement in the editor and to start to play with it. So assuming, we need to refine or go backward we can easily do so.

If the rust implementation is boring you, you can eventually work on something else, the time we stabilize the scripting language.

[Nemikolh]

x)

Writing at the same time and giving the same example, that is funny!

After having seen the last example from @Ikyushii, I'm definitely convinced that proposal 2, is the more easy to use and will lead to script that can't fail at run-time.

So I equally vote for proposal 2.

[ghost]

I can help with static analysis of our scripts, in order to answer the question “is this script ill-formed?”.

For instance, the static analysis might help to determine if:

1. A global variable is only used inside a corresponding if or as a ? left-operand
2. A local variable has been defined before used
3. etc.

(I had some course about static analysis during my master degree)

[ghost]

I think we should split this RSP into two:

1. AaribaScript Design: globally what we are currently talking about. The grammar of the language, the notion of scope, etc.
2. AaribaScript used by Lycan: list of rules to implement, global variable available for each rule, notion of effects, how to use them, etc.

It should be much more clearer!

[Nemikolh]

I'm okay with that.

[ghost]

If everyone agree, I will make the split and propose some updates tonight. @Nemikolh, if you could wait before doing your own changes, it would be perfect.