allow to write alternative implementations in config file

[srghma]

lean has implemented_by https://github.com/leanprover/lean4/blob/1f9bba9d398e207ebbb62696b84502ad764d39dc/src/Init/Data/Array/Basic.lean#L533

and I would like to implement optimizations like this purescript/purescript-json#9

proposal

module PureScript.Backend.Optimizer.Directives.Defaults where

defaultDirectives :: String
defaultDirectives =
  """
  ...

  JSON.fromBoolean implemented_by unsafeCoerce
  JSON.fromInt implemented_by unsafeCoerce
  JSON.fromString implemented_by unsafeCoerce
  JSON.fromJArray implemented_by unsafeCoerce
  JSON.fromJObject implemented_by unsafeCoerce
  JSON.Array.signleton implemented_by unsafeCoerce [unsafeCoerce x]
  JSON.Internals.toArray implemented_by unsafeCoerce
  JSON.Internals.fromArray implemented_by unsafeCoerce
  JSON.Internals.empty implemented_by unsafeCoerce []
  """

Alternative - implement js backend for lean :)

[natefaubion]

I'm not necessarily opposed to some sort of declarative rewrite system that piggy backs on the existing dispatch machinery, but there are some caveats, and it's more complicated than what you are presenting it as. As far as I can tell, Lean's implemented_by is an attribute that replaces one constant identifier with another, and that's it. You have a couple of examples that do more than that, and even involve some sort of syntactic binding for substitution, making your suggestion more akin to GHC's rewrite rules.

For things that are implemented in FFI as essentially unsafe coerce, at least in JS, I'd expect them to have the performance characteristics of a noop once optimized by the JIT. At the most it would be a blip in comparison to all the allocation overhead of either closures or Either for Monadic parsing. Optimizing them away is mostly an aesthetic concern. It occasionally helps with downstream optimizations, but I'm not sure that applies here.

I've done quite a bit of work in my personal time putting together various schemes of making JSON parsing in PS actually performant (at least relative to the status quo), but unfortunately the exposed interface of purescript-json makes that difficult to optimize in a simple/transparent way. Opaque discrimination via FFI (pseudo-portability) and optimization do not go well together.

If you want to reach out on discord or discourse, I'm happy to elaborate on JSON parsing in PS.