DEV Community

loading...

Discussion on: Play: A new programming language that targets Web Assembly, based on Forth

robinheghan profile image
Robin Heggelund Hansen Author

The goal of Play is to be a general purpose programming language which focuses on immutability and controlled side effects. Factor favors mutable data structures. Play also wants to be fully portable by targetting web assembly.

In the future, I hope that Play can do all the things Factor can, and more.

Thread Thread
sarini68 profile image
sarini68

Thanks for your explanation. I hope so for your Play project!
I was figuring out the role of the stack in reaching Play's goals. Immunatibility and controlled side effects are keywords also for Elm, and, as far I've understood, the ELM architecture is designed to allow for this. Will the stack become the place of the world where side effects are controlled? The code of Play is pure inside, but effects act on the world mediated by the stack, but how ?(I was trying to imagine something as the Elm architecture data flow with a stack in the middle) It is also hard to me to keep distinct what happens on the stack (as an execution structure keeping both data and code (thanks to quotations)) and what happens to data defined by Play (I don't know if I explained clearly, I have some doubts and it is also difficult to describe them). By the way, thanks to some tests done in the Factor's listener, I was able to understand and to play with quotations also in Play's playground! Best, m

Thread Thread
robinheghan profile image
Robin Heggelund Hansen Author

I think all of this will become more clear as the project progresses. I'll definetly focus on improving the playground in future releases so it becomes easier to understand what happens on the stack. :)

But in comparison to Elm, here's what the counter demo in Elm could look like in Play:

deftype: Model
: count Int

defunion: Msg
: Inc
: Dec

deftype: Inc
deftype: Dec

def: init
type: Model
: 0 >Model

defmulti: update
type: Msg Model -- Model
when: Inc
  swap drop # get rid of message
  dup count> 1 + >count
when: Dec
  swap drop
  dup count> 1 - >count

def: view
type: Model -- (Html a)
: html/div attribute/empty
    html/button 
      attribute/init
           Inc attribute/on-click attribute/add
      attribute/finalize
      "Increment" html/text html/add-child
    html/add-child # button added to div
    "Count: " html/text html/add-child
    "count" html/placeholder html/add-child # creates placeholder
     html/button 
        attribute/init
           Dec attribute/on-click attribute/add
        attribute/finalize
        "-" html/text html/add-child
     html/add-child # button added to div
  swap # stack: Div Model
  count> "count" html/replace-placeholder # places count into placeholder
Enter fullscreen mode Exit fullscreen mode

This is just an example, it could very well end up looking differently, but I hope it makes things more clear.

Thread Thread
sarini68 profile image
sarini68

Many thanks for your prompt reply. I'll look at your code. Absolutely I agree with you, to involve people in playing with Play, it is very important to have the possibility to look at the content of the whole stack, as well as, to have the possibility to clear it. Using these features inside of the Factor's Listener gave me the opportunity to understand more easily the effects of my code. Best, m

Thread Thread
sarini68 profile image
sarini68

Thanks,
I looked and tested the code (for init and update, not view, as it seems not possible to use Html now).
I wrote a main fx to test the code. I attach the code here:

deftype: Model

: count Int

defunion: Msg

: Inc

: Dec

deftype: Inc

deftype: Dec

def: init

type: -- Model

: 9 >Model

def: inc
type: Int -- Int
: 1 +

def: dec
type: Int -- Int
: 1 -

defmulti: update

type: Msg Model -- Model

when: Inc

swap drop # get rid of message

dup count> inc >count

when: Dec

swap drop

dup count> dec >count

def: main
type: -- Int
entry: true
: init >Dec swap update count>