@milesfrain Oh, I don’t give up so easily! I’ve taken Elm into account, but ultimately decided for Purescript, because:
Some of the planned projects will be CLI programs
Even if they weren’t, the students are in need of a general-purpose language with proper file IO, anyway (so that they can participate in programming contests)
They already know FP, so the new stuff will only be the “typed —” part of it, and that’s exactly the part where Elm doesn’t provide much room to grow (relatively to Purescript)
The course is tri-semestral and there’s no pre-set curriculum, so there’s plenty of time to work around the rough edges
They already have to transition from one language (Pyret) to another, and they would have to transition yet again if Elm didn’t fit our needs.
The course starts in March, but I think we’ll start doing real work in April — before that it’ll be just some simple CLI programs aimed at getting them used to the new syntax, types, and the different dev environment. So, plenty of time to finalise my plans regarding the interactive visual stuff.
@ajnsit Unless I’m misunderstanding something, I could use the existing canvas bindings and just make a Widget wrapping it all up, which shouldn’t be a problem. If you insist to spend your time on my issues (thanks!), could you please prioritise the issue I opened up yesterday at purescript-concur-react? It would help me draw a complete more picture of the framework landscape.
The problem is that React controls DOM elements not canvas drawings. I intend to create concur-canvas bindings which allow you to bind and compose drawings in the same way as widgets. It shouldn’t be hard and I’ll build something this weekend.
The biggest problem with Concur is lack of local persistent state (i.e. returning values and retaining state). I had not anticipated that would be such a big problem when I designed the API. I have a few solutions, and will work on them. Note I don’t recommend signals for this. Signals are great for limited usage but this is a problem that would pervade your application design and it’s going to be awkward building your entire application with signals (not to mention they are experimental and @bbarker has reported performance issues with them).
Meanwhile, there are other solutions you might want to try such as remoteWidget, or wires, or something like Aff-Bus to send messages between parent and children etc.
Thanks for the pointers, and for the help with canvas. Maintaining local state is where React really shines (note I have only used functional components with hooks); what are your thoughts on React? I really loved your comparison with Reflex/FRP, something in a similar vein for React would be awesome.
I wasn’t planning to share this until the documentation and examples were a little better, but it might be useful to you in this state anyway, and whether it is or isn’t, I could still use feedback!
Gesso is a canvas container/Halogen component intended to remove the friction from setting up a canvas with PureScript.
There are a handful of options, but basically, you can give it a render function and optional update and event functions. Then it manages your state and runs your update and render functions with requestAnimationFrame. It also has functions to deal with scaling so you can stretch or shrink your drawing depending on screen size. It doesn’t provide any Canvas API bindings because I originally created it in order to have a blank slate to experiment with different bindings — all the examples use purescript-canvas.
It can be used standalone or as a component in a Halogen application. There’s an example of a Halogen application with some buttons and stuff that interact with a canvas: https://github.com/smilack/purescript-gesso/tree/master/examples/paint-io. (There are two “paint” examples that look the same - they differ in how the canvas state interacts with the rest of the application. I/O uses Halogen queries and Global uses a shared mutable state.)
I’m happy to answer any questions if you think it might be useful!
Just to give an example and a shameless self-promo at the same time, I develop Hexfray which is based on a (nearly) hexagonal grid (there’s a great study material for proper hexagons in https://www.redblobgames.com/grids/hexagons/ in case you want to go that way).
It’s PureScript with Halogen and canvas on the front-end (and Haskell with Servant on the back-end). The game board is made out of transparent pngs stacked on top of each other and I simply re-render them one-by-one with every click and move (pre-rendering the map tiles into a single picture would be one of the optimisations to be made).
