[substation13]

Hello!

This looks really interesting to me.

There is a feature I would like that I have never seen in a scripting language, and I wonder if Scrap might support it:

> Monadic bind points and applicative join points in the script language

Hopefully an example can convey what I mean.

Bind:

    do {
      let! x = some_value_in_a_monad

      x + 1
    }

Applicative:

    do {
      let! x = some_value_in_a_monad
      and! y = another_value_in_a_monad

      (x + y) * y
    }

Now when I embed this script, I would like my runtime interpreter to provide implementations of `let!` and `and!`. The script author defines the bind points and the runtime defines the effects.

Is this possible in Scrap?

[andreypopp]

OCaml has a similar thing but purely on syntactic level — http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...

[debugnik]

Stricly speaking, F# can be used in scripts too, which is where I think you've taken that syntax from. Ionide however is quite broken when writing scripts (or anything else) though.

[surprisetalk]

Wow, I really like that syntax!

Juggling lots of monads can be annoying. But to keep scrapscript small like json, this is something I would try to solve with editor tools rather than the language itself.

[substation13]

How should users write async, futures, option, result, etc. in Scrap?

My hunch is that if you do not put the syntax into the language, then it will be hard for the community to standardize on one preprocessing tool.

OCaml (which I am a fan of!) struggles with fragmentation here.

[surprisetalk]

With managed effects, all of the async stuff gets pushed over to the platform.

I suspect that everybody will settle on a reusable `task` type, but each platform can determine its own async scheduling system.

Consider this example:

  | "/home" -> q -> res:success <| "<p>howdy " ++ name ++ "</p>"
    , name = q |> dict/get "name" |> maybe/default "partner"
  | "/contact" -> _ -> res:success "<a href="mailto:[e-mail]">email</a>"
  | _ -> _ -> res:notfound "<p>not found</p>"
  . res = : success text : notfound text

In this case, the platform creates a simple web server from the following type:

  text => query => res
  . res = : success text : notfound text

Because scrapscript stays out of the scheduling game, the platform is free to run this code on as many cores and servers as it wants in parallel.

But I 100% agree that community standardization is incredibly important! I just don't have a solution yet :) I will try my best to get everybody to work together though haha