AST-12 Implement show : <A>(A -> Text)

[nomeata]

the main purpose of this work is to explore type-driven code synthesis,
in particular looking forward to message serialization/deserialization.
But having a polymorphic show might be useful in itself.

What works:

• showing Nat, Int, Bool, Text
• showing option types
• showing tuple types
• showing arrays (mutable or non-mutable)

Multiple pieces work together:

• show is now a unary operator, neatly side-stepping all issues around polymorphism.
• The interpreter interprets show using Show.show_val, which is the specification.
• There is an IR-to-IR pass that replaces show x with a call
  to a monomorphic function that implements show for t properly.
  It is compositional and multiple calls to show in the same module
  share the code for common subtypes.

Still todo:

• Add more types, in particular objects types.
• show for Text does not escape the string yet.
• Recognizing a call to show fails when show is shadowed. not needed with an operator
• in the type-checker, complain about any unapplied reference to show. not needed with an operator

[nomeata]

Putting this up for an early preview.

[rossberg]

So, why not enable showing all types of values, using the same abstract representation like Value.to_string for ones that aren't transparent? That seems both useful and simpler.

[nomeata]

So, why not enable showing all types of values, using the same abstract representation like Value.to_string for ones that aren't transparent? That seems both useful and simpler.

You mean func for function etc?

I thought about that, and it would be doable, and maybe useful. Shall I do that?

Not sure why it would be simpler. We would still need Show.can_show to rule out, for example, abstract types. (And if we extend this pattern to other things, like hashing, we certainly need to be able to restrict the allowed types.)

[rossberg]

Why disallow abstract types? Print something abstract as well.

For hashing I think we can have a polymorphic function, piggybacking on the Shared bound to identify hashable types. (Obviously, only immutable types must be hashable, though I'm less sure about shared functions.)

[crusso]

This is nice - any reason you couldn't use some more helper from Construct.ml - that might make the transform more legible?

Also, I guess Unop show breaks the pattern that unop returns a value of the same type (assuming that was the convention). I'm wondering if, at some point, we should add a more generic PrimApp(p,es) for prims that can't be typed as functions (like show, or maybe because they take an l-value).

[rossberg]

I agree that show should not be an unop.

But at the risk of disappointing some folks, I don't think this should be landed in its current form anyway. This is cute, but a hack, and a very seductive one at that. Were we to land it I fear everybody would start relying on it quickly and we could not remove it anymore.

As an exercise for implementing type-directed internal ops this is great, but for something user-facing we should have a more scalable feature design. Since that is hard, I had hoped that we can get away without that for now and provide a modest combinator library instead. Otherwise we'll be forever distracted by reinventing half of Haskell classes or Scala implicits, including all their problems.

Remember, the mission here isn't to have the all-encompassing language from the beginning. Right now, simplicity is more important.

[nomeata]

Why disallow abstract types? Print something abstract as well.

I guess this is just my Haskell background. I expect show to statically fail when it can’t show something useful.

For hashing I think we can have a polymorphic function, piggybacking on the Shared bound to identify hashable types. (Obviously, only immutable types must be hashable, though I'm less sure about shared functions.)

I am pretty sure this does not work; let me re-iterate the argument that I already made in #157:

• We want a single, overloaded function hash<A <: Hashable>(A -> Word64) (or Shared, same problem).
• Type annotations ought not change the behavior of the program. In particular,

  let o = new {x = 1}; 
  assert (hash o == hash (o :  {}))
  

• The expressions (new {x = 1} : {}) and new {} are interchangeable in all contexts.

• assert (not (hash (new { x = 1 }) == hash (new { x = 2 })))
  

Because hashing (like showing and serialization) cannot work uniformly on its argument, it cannot simply be a polymorphic function with a bound.

This is nice - any reason you couldn't use some more helper from Construct.ml - that might make the transform more legible?

Yeah, some of that can migrate over. I used some from Construct alrady (e.g. textE). Initially it was easier to keep them in this module, as they are a bit specialized. Note that many helpers are already separated from the transform, so hopefully the transform code is already legible (once you scroll passed the helpers, clearly marked with a comment).

Also, I guess Unop show breaks the pattern that unop returns a value of the same type (assuming that was the convention).

Seems more like an coincidence of the choice of operators so far to me. If we had an |x| operator it would also be type-changing. (But I would also happily combine BinE and RelE to one AST node)…

a more generic PrimApp(p,es)

Since we are no longer attached to the surface syntax in the IR: How are built-in operators like # different from PrimApp? Shouldn’t all of them (e.g. unary operations, binary operations, relations, show) be PrimApps, at least in the IR?

I don't think this should be landed in its current form anyway.

Fair enough.

[nomeata]

So I guess I’ll close this, unless someone wants to champion this. (And with “this” I mean exposing type-directed functionality, such as show, but maybe others, on the surface.) @matthewhammer maybe?

[matthewhammer]

This is great because it exists, though I understand why @rossberg does not want us to start building lots of stuff using it, and begin to depend it if it's ultimately replaced with something else.

However, I see little risk in those kinds of problems manifesting in the short term: The ability to "show" things is most useful for debugging, and that code is naturally quite transitory.

What does the alternative look like, @rossberg? Specifically, is there an existing combinator library for pretty-printing that you think would be a good starting point, or at least, a good demonstration of what you have in mind?

It seems like all modern languages use typeclasses, or features like typeclasses (Rust traits), somewhat universally. Even OCaml has a "derive"-like feature now that mimics that stuff with ppx. This feature seems like a compromise, where the "deriving" feature is built into the compiler, which seems appropriate here.

[nomeata]

There is a bunch of basic functionality (equality testing, printing for debugging, maybe hashing) that our target audience will be pretty unhappy to have to implement manually. In particular because we can’t really provide nice combinators that work on objects (no way to abstract over objects with different field names, i.e. no good generic programming).

So I am hesitantly closing this, but I hope we can come up with a way to offer such basic convenience features eventually.

[matthewhammer]

I’ve written some tests of the produce exchange (PX), but to better inspect whether it’s doing what I think it’s doing, sometimes I just want to “dump everything”. I'd like to start doing that soon.

However, since PX uses a bunch of different boring record types, I thought it’d be nice if there was a systematic way to pretty-print each one, rather than hand write those routines. This PR seems like the perfect solution.

I don't want to open old wounds, but now that we have a compelling usecase for this PR, I'd like to revisit it, and the reasons for and against doing something like this. I understand the reasons "for", but I don't fully understand the reasons "against".

@rossberg says above:

for something user-facing we should have a more scalable feature design. Since that is hard, I had hoped that we can get away without that for now and provide a modest combinator library instead. Otherwise we'll be forever distracted by reinventing half of Haskell classes or Scala implicits, including all their problems.

After rereading it a few times, I have to admit that I don't fully understand this complaint.

Why does this feature need to be "scalable"? (Also, what does that mean?)

[matthewhammer]

I should add that I understand the “design purity” argument against adding special cases for type classes, but that should be weighed against the actual time and energy that AS programmers like myself will have to spend coping with the consequences of this somewhat puritanical stance.

Regarding “scalability”: writing all of this code by hand is not really scalable. : )