Open questions

  1. Exceptions and errors.
  • Tenet’s tagged unions give you a very robust way to return error values at the API level.
  • Thus, exportable functions should be “total” meaning that they can’t raise an error.
  • Primitive operations like arithmetic and accessing maps generally can’t be total.
    • There are proposals to do so.
    • They seem to introduce worse problems than division by zero.
  • This suggests a dual strategy for handling errors:
    1. Exportable errors are simply return values.
      • These may be re-thrown as exceptions in the host language if desired.
    2. Internal errors are generally handled immediately within the function.
      • Many primitive operations only have a single type of error.
      • Typical handling is to translate to a return value.
  • Need a guard syntax for internal errors
    • Should be very lightweight.
    • Should allow exception handling directly on the operations that may throw.
    • Ideally potential failures are all guarded, that is, exportable functions are total.
  • Out of scope: out of memory, IO errors, thread interrupted, etc.
  1. Numerics.
  • Tenet presently only has an unbound integer type.
  • Decimal fixed point requires bounds.
    • A major design requirement is Tenet doesn’t blow up.
    • Each multiplication of an unbound decimal adds to the numeric complexity.
    • That’s more complicated for a fractional type.
  • Floating point is far worse.
    • Binary floating point is presented as decimal, which is highly confusing.
    • IEEE 754 adds infinities and NaNs.
    • Non-C languages suppress exceptions and don’t offer rounding modes.
  • A numeric context would govern the results of arithmetic operations.
    • Parameters and literals are what they are.
    • The context dictates bounds, precision, scale, rounding, exceptions, etc.
    • Thus the results of operations are dictated by the context.
  • If we introduce floating point and allow infinities and NaNs…
    • Does that apply to integers?
    • What if they’re translated to pos_infinity~~, neg_infinity~~, NaN~~, n~55?
    • Safe arithmetic operators, +?, -?, &c could accept and return special values.
    • For many tasks like sorting, “larger than any other value” can be helpful.
  1. Strings and binary.
  • One kind of unicode string is “a list of code-points.”
  • Another kind is more semantic.
  • A string context might be similar to collation rules used in databases.
  • “Collating-maps” and “collating-sets” might key off the reduced form of the string.
  1. Type oddities.
  • a~b~c~"value" seems odd but is legit.
  • Same for {a: {b: {c:"value"}}}
  • Logically, numbers and strings are enumerations, but they’re distinct primitives in Tenet.
  • Presently types declarations are aliases, but there are many use cases for opaque types.
  1. Exporting.
  • A major open question is what are we exporting by default?
  • Need to work out the format of a Tenet manifest.