Improving JS semantic a little bit, and AST macros

[al6x]

Thinking about possible alterations of JS semantics, disabled by default and enabled with flag.

Customizable operators, on any object, a bit dirty, with types.

Following transformation required.

a in b # => b.contains(a)
a + b  # => a.plus(b)
a == b # => a.equals(b)
a < b  # => a.lessThan(b)

a[k]     # => a.get(k)
a[k] = v # => a.set(k, v)
etc.

And so it would be possible math support Vec(1, 2) + Vec(2, 4), Vec(1, 2)[1] sorting for arbitrary
objects if it defined compare, proper equality check, properly working in like 'a' in ['a', 'b'] # => true if contains defined, etc.

A bit dirty, as it would require to define Number/String/Etc.prototype.contains/plus/equals/etc but it shouldn't be that bad. Also it should work with TypeScript.

Extend Array and Object, clean, with types.

[1, 2]  # => _array([1, 2])
{ a: 1} # => _record({ a: 1 })

So it would be possible intercept object/array creation and alter it or return other implementation. So finally we don't need Object.keys(o) noncense, and it's going to be o.keys(). Maybe add more methods like o.merge(other), o.size() etc.

Same with Array, fix sort|reverse|etc mutable versions and replace it with immutable functions, implement sort properly with comparators. Improve Array interface.

Clean, changes isolated, no built-in or library code affected, and it also should work with TypeScript.

Method call interceptor, almost clean, not sure if types would work.

Relatively safely extend built in types, only one property extensions will be added to pototype, and some other use cases.

o.fn(x, y) => _call(o, "fn", [x, y])

With something like

function _call (o, fn, args) {
  (o.extensions[fn] || o.fn).call(o, args)
}
Object.prototype.extensions = {
  keys: function () { return Object.keys(this) }
  isEmpty: function () { for (let _ in this) return false; return true  }
}
String.prototype.extensions = {
  isEmpty: function () { return this.length == 0 }
}

Implementation

Could be done as plugins, if Civet would accept custom transform(ast): ast function, same way as babel does.

I created these transformations for babel for example the code for object and array wrappers done as. But it can't be done on the Civet output code, transformation needs to be done on the Civet AST.

...
if (path.type == 'ArrayExpression' && !wrapped.includes(path.node)) {
  wrapped.push(path.node)
  path.replaceWith(
    t.callExpression(t.identifier('_array'), [
      t.toExpression(path.node),
    ])
  )
}

if (path.type == 'ObjectExpression' && !wrapped.includes(path.node)) {
  wrapped.push(path.node)
  path.replaceWith(
    t.callExpression(t.identifier('_object'), [
      t.toExpression(path.node),
    ])
  )
}
...

[STRd6]

These are some pretty interesting ideas and something we would like to explore eventually. It has some overlap with #10 which we also want to explore in the future.

The current major roadblock is that the Civet AST isn't yet stable (though it is getting closer). It might also be nice to be able to scope the directives to specific blocks as well.

It may also take a bit of time to work out all the design details but having it be an experimental opt in flag would be a great way to start figuring things out.

Thanks for the suggestion!

[al6x]

Yes, it's more like experiment, maybe the easiest way could be a config option to supply transform(ast): ast like in babel, unstable, but easy to experiment and don't add too much burden to the core team.

[al6x]

I played with babel transformer and this approach a bit. The most useful feature is replacing default Array and Object literals with other implementations. Say[1, 2] -transpiled-> new List([1, 2]) and {k: v} -transpiled-> new Record({k: v}). And now you got powerful standard library with well implemented List and Record objects. And it could be easily implemented as Civet optional config, like custom_array_literal_class: List and custom_object_literal_class: Record.