Browser frontend

[quchen]

Looking at the STG in a browser is probably nicer than in a console.

[quchen]

Some specific questions to answer:

• Evaluation model?
  • Pre-render everything: simple, does not allow infinite programs
  • Start a server that answers requests about program states? More complex frontend, allows infinite programs as it can answer on-demand
• What frontend technology to use?
  • Elm is user-friendly and seems to be quick to develop in, and I know people that I can ask support questions
  • Purescript is very interesting, but I'm completely unfamiliar with it
• How to send data to the frontend? Pre-render it, serialize it as JSON?
• What's a good design to show everything at the same time nicely?

[quchen]

Talked to @reinh on IRC, he proposed to add a React frontend if given a proper exchange format – awesome!

[reinh]

Regarding evaluation model, I say start with (1) and we can add (2) over time. It'll be nice to see something quickly even if we can't work with every program.

Regarding frontend: I do React for my day job atm so I would be most productive in that. I've done some tiny personal projects in Elm and Hello World apps with PureScript's pux and halogen so I don't have much experience but I do like both of those choices in theory.

Regarding the wire format, I see a few obvious options:

• Pre-rendered HTML with class names that are recognized by some highlighting system. Advantages: Can be injected directly into the DOM, styling "for free". Disadvantages: Can't be used for any other purpose or modified in any way.

• Pre-rendered HTML with semantic class names or other attributes. Advantages: Can be injected directly into the DOM, only needs a stylesheet. Disadvantages: Difficult to use for any purpose other than directly embedding into the DOM or to modify or pre-process in any way.

• JSON: Advantages: Very easy to use in JavaScript-land. Probably trivial to generate in Haskell-land. Can be processed or munged easily. Disadvantages: A slightly less nice format for representing a token stream than, say, XML. Requires a template system or similar for rendering to HTML, but that's basically what (say) React is anyway.

XML could theoretically be better than JSON here if it had reasonable support on both ends but it doesn't... and also who wants to use XML, seriously.

I think generic generation of ToJSON instances for a list of program states would be a reasonable first try for a wire format.

[quchen]

• I agree on the evaluation model. On the STGi side I have a list of program states anyway, so switching this to a more complex delivery model is just a matter of standard operations.
• Frontend: I don’t really care, the goal is having something usable and somewhat modern. I encourage using Elm and Purescript since I simply think they’re cooler, but that’s as far as my arguments go.
• Wire format: I’m currently rewriting the code to using my prettyprinter, for which I could easily write a HTML backend (or semi-HTML with custom tags, or whatever React likes to use). I agree JSON is preferrable, and indeed easy to provide, but shifts quite a bit of (redundant) layout work to the frontend. I think an HTML format with semantic tags (so we can easily create e.g. anchors/links for all memory addresses) is the best solution.