[RFC] Type Mapping and Operator Semantics in PPL (`+` Operator)

Problem Statement

The + operator in PPL enforces strict type matching between operands. This results in errors for common real-world scenarios such as:

• Numeric values stored as strings in fields.
• Concatenating fields with mixed types (string + numeric).
• Chained operations where intermediate results flip between numeric and string representations.

This strictness forces users to add explicit casts.

Current State

• Literals: Literal + literal must be the same type. Mixed string/numeric literals cause errors.

  • "10" + "1" → "101" (concat)
  • 29 + 100 → 129 (numeric add)
  • "100" + 100 → error

• Fields: Mixed string/numeric fields with literals or other fields are rejected. No attempt is made to coerce values at runtime.

Gap Analysis & Behavioral Summary

Flexible runtime-coercion model (for comparison)

1. Literals: must be both strings (concat) or both numbers (add); otherwise error.

2. Fields: evaluated at runtime based on actual values:

   • If both operands are numeric-parsable → numeric add.
   • If a string literal participates → prefer concat.
   • If string field + numeric literal and the string isn’t numeric-parsable → null.
   • If field + field and one is non-numeric → concat.

3. Chaining matters: a concat that yields a numeric-looking string can enable numeric addition in subsequent steps (type mapping can flip over time).

4. Display ≠ type: outputs are often stringified for rendering; internal types should still drive subsequent semantics.

PPL vs. flexible model: behavioral gaps

• Mixed field–numeric operations: flexible model allows dynamic coercion (e.g., age + 1, fieldA + "100"); PPL rejects without casts.
• Chaining flips: flexible model permits concat → add transitions across steps; PPL does not.
• Literal–literal strictness: both models keep literals strict (e.g., "100" + 100 errors), but PPL extends strictness to most mixed cases involving fields unless explicitly cast.

Appendix: Examples

• Mixed field + numeric literal (parsable):
  eval x = age /* "29" */ + 1 → 30

• Mixed field + numeric literal (non-parsable):
  eval x = employer /* "Peticular" */ + 1 → null

• String literal preference for concat:
  eval s = age /* 29 */ + "hello" → "29hello"

• Chaining flip:

  eval s = age + "100"   → "29100"   // concat
  eval x = s + 100       → 29200     // numeric add (re-parsed)
  

Action:
We’re seeking community feedback on whether PPL should adopt a flexible runtime-coercion model

Start with the RFC's Problem Statement, Current State, and Appendix examples to understand the proposed type-mapping and operator semantics. The issue does not name implementation files or tests; it is done only when the community feedback results in a decided direction for PPL's + behavior.