precept

Preception!
john 2017-06-10T00:57:37.487199Z

Hey folks. Really cool lib!

mikegai 2017-06-10T01:02:22.506733Z

I posted this in #clara but probably of interest here: >>> Maybe something like this (in tuple / #precept syntax instead of default Clara):

(def-tuple-rule ready-exit-missing-password
  [[:app :state :login]]
  [[:login :state :ready]]
  [[_ :missing-email]]
  =>
  (insert-unconditional! [[:login :state :password-error]]))
a macro would expand the concise statechart syntax to rules like that. and then of course you could define/derive :missing-email elsewhere (edited) @jfntn do I have what you're thinking right?

mikegai 2017-06-10T01:03:34.511389Z

that's in response to asking how one could handle statecharts in the form

(def app-statechart
  {'Visitor
   {:login
    {'LoginForm
     {'Start          {:init 'Ready}
      'Ready          {:missing-password 'Password-Error
                       :missing-email    'Email-Error
                       :submit           'Submitting}
      'Password-Error {:change-password 'Ready}
      'Email-Error    {:change-email 'Ready}
      'Submitting     {:receive-success 'Success}}}
    :signup {... }}
   'User  {...}
   'Admin {...}})

mikegai 2017-06-10T01:05:25.518615Z

@john thanks!

john 2017-06-10T01:06:52.524330Z

My initial question from the docs was "why do I have to pass a whole namespace to session?" But I see that the rules namespace is being populated by macros.

đź‘Ť 1
john 2017-06-10T01:08:20.529939Z

Seems like a wart that would be worth smoothing over if it was possible, but I'm not sure if it's possible. I heard y'all were looking for feedback, so that's all I got 🙂 Super excited about the idea!

jfntn 2017-06-10T01:28:46.603655Z

@mikegai thanks for the explanation, I think I’m starting to see how this’d work. I haven’t played with clara or precept yet so I’m not clear on the syntax, would you please correct me: - the first tuple asserts the :app singleton’s :state property is :login (parent guard) - the second asserts that the :login state is :ready (node/child guard) - the third asserts any transition to :missing-email. Finally the rhs transitions the node/child state to :password-error?

alex-dixon 2017-06-10T03:01:46.890970Z

When app state is login and login state is ready and there is a missing email, then login state is password error

alex-dixon 2017-06-10T03:02:59.894843Z

@jfntn sorry best I can do on my phone :)

jfntn 2017-06-10T03:13:44.924302Z

Gotcha, thanks

mikegai 2017-06-10T17:32:40.279920Z

To clarify, I'd restate it as "then change login state to password error" instead of "then login state is password error". insert! means "so long as the condition is true, then the consequence is the case" (because it will be auto-retracted if the conditions go false, making it a sort of definition) while insert-unconditional! means "change/mutate"