Implement literals

[swazrgb]

Scripts can assign numbers and entities using literal numbers & strings:

let num: Value = 10;
let id: Value = "c_battery";

Entity & number pairs can be assigned using the value builtin function, or as a casted object.

let pair1 = value("c_battery", 10);
let pair2 = {
  id: "c_battery",
  num: 10
} as ItemNum;

Coordinates can be assigned using the coord builtin function, or as a casted 2-element number array.

let coord1 = coord(10, 20);
let coord2 = [10, 20] as Coord;

One drawback of the new typing system is that arthimetrics aren't allowed by default, and the Value type has to be coerced to a number first. Fortunately this is easy to do:

let v: Value = "c_battery";
v = +v + +v; // prefix with +
v = v as number + 1; // cast
v = 1 + v; // reverse the expression if adding a constant

[swazrgb]

@ribrdb ping

I've tried various alternatives since, mostly to work around having to write const v: Value = +v + +v for math, but nothing works well while still allowing literals such as "c_battery" or 5 to be assigned to Value typed variables: const v: Value = 5.

The best alternative would be requiring the usage of the value function in all cases, so const v: Value = value("c_battery") or const v: Value = value(5)

[ribrdb]

I've tried various alternatives since, mostly to work around having to write const v: Value = +v + +v for math, but nothing works well while still allowing literals such as "c_battery" or 5 to be assigned to Value typed variables: const v: Value = 5.

I was thinking of just adding num: number to the BaseVar interface so you could optionally use v = v.num + v.num instead of unary-plus. I haven't tested to see if that would work though.

The best alternative would be requiring the usage of the value function in all cases, so const v: Value = value("c_battery") or const v: Value = value(5)

Actually I kind of like that

[swazrgb]

I was thinking of just adding num: number to the BaseVar interface so you could optionally use v = v.num + v.num instead of unary-plus. I haven't tested to see if that would work though.

That should work. It feels a bit odd to me to provide a fake property for this. Internally the .num accessor would just be a no-op, existing purely to get the typescript to compile.

Actually I kind of like that

I don't mind it for variable assignments, but it's awkward for function calls. For example having to write entitiesInRange(5, value("v_mineable")) would be unfortunate.

This seems doable to support:

let v: Value; // Declare variable/params as Value
v = 5; // numbers are directly assignable
v = v + 5; // Values & numbers can be used in math as-is
v = value("metalore"); // string assingments must be wrapped in `value` 
v = value("metalore", 5); // NumPairs need the value function as well of course

v = "metalore"; // Not allowed! Must use value("metalore");

entitiesInRange(5, "v_mineable"); // literal strings can be supported as function arguments

I'll give this a go.

[swazrgb]

That was pretty straightforward. Could you please take another look, @ribrdb ?

[ribrdb]

Why is this needed when there's the coord function?
If we do need it we should probably check the array length. I could certainly see people trying to use general arrays and getting confused.

[swazrgb]

I implemented it because I saw the typescript definition type Coord = [number, number] which implies a user should be allowed to write this when specifying a coordinate. But I'd be happy to just get rid of it, the coord function is better ergonomics IMO.

[swazrgb]

Maybe change the Coord type to {x: number, y: number}, and allow this to be written literally? Just like {id: "metalore", num: 1} is also allowed to be written literally?

Or disallow writing both literally, and require usage of the coord and value functions? Then the type could change to:

class Coord {
  x: number;
  y: number;
  
  private constructor() {}
}

Or honestly maybe just class Coord {} (or just Value) because it's not like we can compile value.x (or value[0]) to anything sensible without calling separateCoordinates, which I'd prefer to be an explicit action.

[ribrdb]

Ah, I was only intending that to be used for arguments to functions which take a coordinate so you could enter a literal. You're right, an {x:, y:} object would probably be more clear.

[ribrdb]

This looks great, thanks! Just a couple comments