brownplt/code.pyret.org

rendering tables

Closed this issue · 4 comments

Is there any chance of getting a useful torepr/tostring for tables?

Tables are a pretty useful data structure for reactor worlds, and having a default rendering means it's a lot easier to view/debug what is going on without having to create a complex rendering operation. Right now they just produce <table>.

Crappy sample program:

r = reactor:
  init: 3,
  on-key: 
    {(_, _):
      table: n
        row: random(100)
      end},
end

r.interact()

We specifically avoided this because thinking it through compositionally yielded really ugly results. Yes, for 1-column tables containing a single number, it's not bad (unless it's a rational with ludicrous denominators...). For wider tables with richer/larger values inside them, it got pretty bad. We didn't want to take a library dependency on a node package for table formatting, nor did we want to figure out the ASCII-art column layout arithmetic ourselves. And you had said that splitting rows onto multiple lines of text was so hideous you didn't want to consider it. So...that left us with <table>.

Well, the real problem I want to solve is not improving a table's tostring but making reactors more useful.

We already have a very nice renderer for tables! And for lists, and other things. (Even though lists and arrays and such are indeed rendered as strings right now, they are pretty useless with reactors when the data grow beyond very small sizes.)

So, any chance of just using the existing renderer inside the default reactor display?

That's...tricky, but maybe possible? The relevant code is

var textNode = jQuery("<pre>");
return runtime.safeCall(function() {
return runtime.toReprJS(world, runtime.ReprMethods._torepr);
}, function(str) {
textNode.text(str);
, which runs torepr on the value and creates a <pre> node containing the results. We might be able to call the CPO renderer instead, and just plop in the resulting DOM node, instead of rendering it as text. I.e. we could effectively call display instead of torepr. I don't know how that would interact with the window, though -- in particular, there's no easy way to set the reactor window size based on the rendered size of the value... @jpolitz ?