Eww event handlers and state update syntax

[elkowar]

Hey everyone!
It's time for another one of these discussions, where I'm asking for feedback on design decisions!

In #324, we're planning to add local state -- variables that can be declared within a widget, so widgets can track their own internal state.
For this to be usable, we need some way to update these local variables from within the widgets. Specifically, from within event handlers (i.e. :onclick, :onhover, etc).

Currently, eww just expects a simple string, that will get executed as a shellscript. This system works, but leaves no way for eww to do anything internal -- even updating global variables has to be done by running eww update foo=whatever in the event handler.
This cannot work in the context of local variables -- we need a more powerful syntax and structure here.

Initially, my plan was to do the following:

(button :onclick (update foo "new-value")
  "click me")

This simple syntax would work well in this simple case, but it has a few issues:
Initially, my approach assumed that you'd always pass these Actions to the eventhandler directly, like shown in the previous example.
Cases in which the Action would need to be treated as a standard value (to be usable as arguments to custom widgets, to be able to be stored in variables themselves, contained inside lists / objects, etc) where not accounted for here.
Adding these Actions as first-class values is weird, as suddenly we'd have lisp-y syntax in eww expressions -- that is, you'd suddenly be able to do something like this:

(defvar foo "[(update foo 'a'), (update foo 'b')]")

which feels very odd, and is also just somewhat annoying to implement.

The obvious alternative would be to add these actions as some other syntax, or even functions, to the eww expression system.
That could simply look like regular assignment: foo = "a". However, this feels very out of place in the declarative nature of yuck, and isn't a complete solution:
To be able to actually use this construct productively, we'd need to add some sort of lambda syntax, i.e.:

(button :onclick {() => foo = "a"})

At which point I hope we all agree that this looks somewhat weird.
Another issue with this is that it'd introduce side-effects into eww expressions, which eww's state architecture may re-evaluate at random points in time -- although that could be seen as a case of "well, just don't do it, lol".

I'm somewhat out of ideas as to how to structure this. I feel as though having some sort of lambda syntax and adding actions to eww expressions that way would be the "cleanest" approach in many ways, but I can't come up with any better syntax or general structure for it.

Thus, I'd love for you all to give me some of your thoughts, opinions and ideas regarding the structure and syntax of this!

[Lazerbeak12345]

For the local definition, I'd recommend

(defwidget foo []
  (let [(something "default")]
    (button :onclick (set something "new value")
      "click me"))) 

in order to be more consistent with the style used by the general lisp community and by that you are using in widget params.

I have yet to make my own opinion on the set thing

[Vermoot]

In this example, is the button widget in the variable definition?

[MuhammedZakir]

In this example, is the button widget in the variable definition?

No. The list just after let is the variable definition. A let expression creates a new lexical scope with a list of variables and will return the last expression. The above roughly translated to a Lua-like lang:

defwidget( "foo", {}, function()
  var someting = "default";
  return button( {onclick = function() something = "new value"; end}, "click me" );
end)

[Lazerbeak12345]

I like that in your jump to translate to lua(like) you used a lambda on the onclick. Makes me wonder if a well-planned and designed lambda is the best way.

[Diegovsky]

You can copy scheme's lambda syntax for that, it looks nice and lispy

[elkowar]

And yea, that's my main issue - mixing lispy and non lispy syntax is problematic. I'd consider a rework of simplexpr, but given the goal of json support etc, it's not even really feasible to make it all that lispy, no matter what.

[Diegovsky]

Yeah, it does seem very problematic now that I think about the reevaluation. Maybe using a "new" datatype for simpleexpr that holds its state would be better, that way you can track its state and trigger a reevaluation of callbacks that depend on it and also you can keep state mutation contained.

[Lazerbeak12345]

So sortof like a monad or something?

[elkowar]

Triggering ui updates wouldn't even be an issue, I just doing like the idea of allowing for random spontaneous side effects at all ^^

[Diegovsky]

@Lazerbeak12345

So sortof like a monad or something?

ya

Triggering ui updates wouldn't even be an issue, I just doing like the idea of allowing for random spontaneous side effects at all ^^

Oh ok then :)

[Lazerbeak12345]

Down the rabbit hole for lambda-within-eww we go, as well:

Here's my idea:

(button :onclick {=> foo = "a"})

That's a thunk, but as mentioned we might need args. I woudn't reccomend () => ... as I feel like that'd be hard to parse, and is backwards from the rest of the library, sortof (name before args, vs args before name). => () ... might be easier to parse, and to read.

(button :onclick {=> () foo = "a"})

additionally, this gets into what argument separators you want to use. The two I know of that are frequently used is the comma (,) and the space ( ). I'm a lisp user, so I want to recommend commas, but since you likely aren't allowing commas in your variable names anyway, either might be fine. Spaces might look better when put into the context of sexps.

(my-grid :onclick {=> (x y) foo = x * y})

vs (with added white-space to look nice.

(my-grid :onclick {=> (x, y) foo = x * y})

That's of course assuming that you would support multiple arguments in the first place. If that's not something you'd like, the parens might not be needed, but this is ugly: => amount foo = amount so do this:

(my-scrollable-thing :onclick {amount => foo = amount})

Which takes us full circle.

As for the =>, I think it's okay. A bit like JavaScript (a language I only tolerate, not enjoy).

In a defunct language of my own design I played around a little bit with using raw curly brackets ({ and }) as lambdas, with a little-bit of work to get multiple arguments working, and it was actually pretty good looking. All this to say that => isn't the only option.

[dmfay]

I thought of a more pipes-esque syntax and haven't been able to poke a major hole in it yet:

; any number of arguments
(.... :onclick {x, y -> x * y -> foo})

; if only a single source argument and destination, store directly
(.... :onscroll {dir -> foo})

; execute functions
(.... :ondropped {uri -> replace(uri, 'regexp?', 'text') -> foo})

; source must be an argument list of the appropriate cardinality or a
; literal: this is equivalent to {x, y -> "updated" -> foo}
(.... :onclick {"updated" -> foo})

; error cases
(.... :onclick {foo}) ; must define at least a source & destination
(.... :onclick {x, y -> foo}) ; destination argument count mismatch
(.... :onclick {x, y, z -> x * y -> foo}) ; too many arguments

; not too bad stringified
(defvar handlers "[(x, y -> x * y -> foo), ('updated' -> foo)]")

I guess you could {x, y -> "update bar 'side effect time!'" -> foo} depending on how the handler is evaluated, but that at least feels appropriately unheimlich.

Another thing to think about: scopes and namespaces. Right now I have bar and calendar widgets, and in order to display the calendar when hovering the current time in the bar I have to define a var in the global scope, write it from the bar hover event (eww update cal_rev=true etc), and read it in the calendar widget :visible. It'd be convenient to define the var in the calendar widget scope, but then how to set it? :onhover {true -> cal.cal_rev}? How much of a minefield would it be to work with un-namespaced vars in the local scope, e.g. in cal :visible cal_rev potentially shadowing a global cal_rev?

[strinsberg]

Not sure if you are still trying to figure this out, but I had a couple of thoughts to share. Also, all of the ideas above seem like they would work well enough, once a person has understood how to program with s-expressions none of the proposals would be hard to pick up.

I am not sure there is a need to add special syntax for lambdas, they essentially already exist if one uses an expression for an event. For example, today I wrote this code

(button :onclick {SHOW_BOOKMARKS
                  ? "eww update SHOW_BOOKMARKS=false"
                  : "eww update SHOW_BOOKMARKS=true"}
  ...)

This already executes an expression body when there is a click event in the same way that a no argument lambda would execute its body. To support assignment to local or global variables all you need is to add an assignment operator.

(button :onclick {SHOW_BOOKMARKS
                  ? SHOW_BOOKMARKS=false
                  : SHOW_BOOKMARKS=true}
  ...)

However, the above example is only useful for places where we are attaching expressions without arguments to an event. For example, the slider widget provides a value for you to use when you change it. I have something like this in a widget

onchange "xbacklight -set {}%"

In this case the {} provides the argument for use in the string. However, I couldn't do something more complex (as far as I know) with the argument like

:onchange "xbacklight -set ${ {} > 50 ? ... : ...}"

because the {} argument is not exposed to the expression in the same way that it is to the string.

My suggestion is to do one of two things:

1. Borrowing from Clojure's small lambda expression use % as a stand-in for the argument when it is possible for one to be passed in by the event. So the above becomes

:onchange "xbacklight -set ${ % > 50 ? ... : ...}"

2. Do as has been suggested above with a named argument

:onchange "xbacklight -set  ${arg => arg > 50 ? ... : ...}"

This has the advantage of perhaps being a little more readable and could be used if you want to add a more complicated lambda structure
that might do more than just evaluate a single expression or needs multiple arguments. I.e. :onchange "cmd -o ${x, y => MY_VAR > 50 ? x : y}".

Neither of these require much additional syntax and they seem consistent with the current syntax of () being for widgets and {} being for expressions. However, as I said above, I am not sure you could go wrong with any of the suggestions.

This does not say anything about how you might introduce syntax for local state, but imo the use cases most people have for these widgets probably work just fine with global variables. I know as programmers we must accept them to be evil, but in this case they seem to work. I have been having a really great time using EWW and I think that it's paradigm of s-expressions for declaring widgets, CSS for styling, and calling shell scripts or programs for functionality works perfectly. It keeps it simple for you and for us. Much more accessible than using a general purpose programming language and a GUI framework to create the widgets. So THANKS for the fun tool 😄

[oldwomanjosiah]

Wish I had seen this before working on #578 🤦. Oh well.

On thing i'd bring up for consideration¹ is the swift closure syntax

{ arg1, arg2 -> return in /* body */ }

while that is a little heavy for what we'd need, using in as the separator would mirror the proposed (but not accepted) let in end syntax for simplexpr.

One thing to note, potentially against adding lambdas to simplexpr at all, is that there currently isn't a way to just run a side-effect-ful expression in simplexpr. We would need some <expr a>; <expr b> which evaluates a, then evaludates b in the context containing the side effects from a, but otherwise ignores its value. This (while doable) feels very much different in kind to the rest of simplexr.

(defwidget inc-button [?onchange]
  (let count 0 in
    (button
      :text { count == 0 ? "None!" : "Count ${count}" }
      :onclick {
        ; Using swift as stand in for lambda
        ;   `:=` for assignment
        ;   `()` for invoke
        ; Also note that this choice of expression chaining operator, while common, would conflict with comments.
        { in
          count := count + 1;
          ; also also note that this would probably be a common pattern peopel would try, so it
          ; would be pretty much necessary to have this run _with_ the side effect of the assignment.
          onchange != "" ? onchange(count) : ""
        }
      }

Footnotes

1. This is bike shedding, please regard as such ↩

[oldwomanjosiah]

Also, I'm not sure that simplexpr has to know about the scope graph. It might make more sense, from a architecture, change propogation, and self-invalidation identification perspective to have a simplexpr evaluation just provide a List<SideEffect> as a secondary output, with some

#[non_exhaustive]
enum SideEffect {
  WritableVarUpdate(VarRef, DynVal),
  ScriptExecution(String, Vec<String>)
}

yuck could then propogate those updates to the proper scope for simplexpr.

With my previous example a click on

(inc-button :onchange {{ new in global := new }})

would produce

[WritableVarUpdate("count", 1), WritableVarUpdate("global", 1)]

[rubyFeedback]

I dislike that the syntax is so lispy. Could we get an additional syntax if it has to go the lispy way?

Something a bit more like CSS rules; or if you need it java/javascript syntax secondarily (well,
ruby and python syntax would be even nicer but I don't know how much effort it is to have a
custom parser that is more elegant. I get that lispy syntax is easy to parse, I just hate
writing and reading lispy style ... evidently this is my personal preference so this may vary
for different people, I get that too)

[Lazerbeak12345]

I feel like this comment is out-of-scope. For that matter, we just moved from xml to yuck format (based on sexprs from lisp), and moving again would be frustrating. Adding a different file format would be too complicated, and not really worth it.

[autofool]

Why everyone wants lambda like expressions? Can't we just have normal functions like widget's syntax?

:onclick (my_func)
:onscroll (my_func :my_var1 "my_val1")
:onhover (my_func :my_var1 "my_val1" :my_var2 "my_val2")

Then function can be like widgets:

;--Missing f is intentional :)
(defunc my_func [my_var1 ?my_var2]
  ;-- Implement some variable manipulations
)

[EDIT] It'd be really nice to have if elif else conditional expression for internal variable manipulations.

[tigercoding56]

true

[Craksy]

I think the reason is that handlers often have very simple logic, so it's very convenient to be able to inline it.
Defining named functions outside of the widget might get very cluttered very fast.

Furthermore, if top-level functions are to manipulate local state, you need some way of providing them mutable access to it. That would mean either introducing mutable references (which feels incredibly out of place for a lisp) or being able to somehow access local state via eww update (see the second to last paragraph of my comment below), which seem to give rise to a whole bunch of new questions and design decisions.

What sets lambdas apart from named functions is that they can capture symbols from the scope in which they're defined.
This makes them ideal for manipulating local state.

That said, I still agree that named functions would be awesome to have. Luckily, they kind of go hand in hand, as named functions are literally just a lambda bound to a global symbol (again, see my comment below).
They're not mutually exclusive. Quite the contrary in fact.

[Craksy]

I must admit I haven't looked much at the Eww source (and the little I have was a long time ago) but I imagine that widgets are basically functions that Eww (may) reevaluate whenever internal state changes?

If that's the case, introducing lambdas as first class values, and letting widgets be a special form that receives an optional varlist, could be a way to separate local state and render logic.
Considering something like

(defwidget name []
  (let ((local1 "value1")
        (local2 "value2"))
    (button :onclick (set local1 "new value") local1)))

This wouldn't work without lifting the binding to handle it internally, and even then it would be misleading.

Instead the signature of defwidget could change from
(defwidget NAME ARGS &rest BODY)
to
(defwidget NAME ARGS &optional DOCSTRING VARLIST &rest BODY)
to be used like

(defwidget name []
    "My fancy example widget" 
    ((local1 "value1") (local2 "value2"))
  (button :onclick (lamb () (set local1 "new value")) local1))

(docstrings and implicit box/&rest argument were just things that seemed like a cute addition. not at all essential to the idea)
this would feel natural, and it does better at communicating that the binding belongs to the form, not the body.

It also kind of eliminates the whole "lambda vs regular functions" thing, as (defunc name [args] ...body) can conceptually be thought of as something like (set name (lamb [args] ...body)).

it would feel intuitive, and might open up for a bunch of other cool sutff.

It might however still be useful to be able to access local variables from the outside.
For that to work you would need some way to identify specific instances of a widget.
One solution could be something like a (tag) wrapper

(defwidget toggle-group []
  (box
    (regular-anonymous-widget)
    (tag "cb1" (my-checkbox-widget "label"))
    (tag "cb2" (my-checkbox-widget "foo"))))

and let eww update accept a path-like syntax to access locals, like
eww update win1/toggles1/cb2/checked=true

But I'm probably getting ahead of myself now.
Anyway, I think lambdas feels like a very reasonable way forward with this.

[andyp1xe1]

I think the most minimal way to internally do stuff, as opposed to through shell script, is to have a way to run eww commands internally, so instead of doing :onclick "eww update foo=bar", you could do simply :onclick (eww update foo=bar), basically having an internal interface for the eww command.
I see the benefits of having lisp syntax for defining structure, but I think there is nothing wrong of using other syntaxes for evaluating things.

On the other hand, if there already is (defvar foo "var"), I see no problem in using something like (setvar foo "var") either locally or after a condition.
And using a syntax similar when defining widgets:

(defvar my_var [arg1...]
    arg1 ? "nice" : "huh")

then, use something like:

:onclick  (setvar my_var :arg1 true)

or:

:onclick  (defvar local_var []
    (my_var :arg1 true))

this makes the syntax consistent in my opinion.

[mattatticus]

I would like to mention haskell's syntax for a lambda. It looks like this.

\foo -> foo + 1

Lambdas in haskell has to take one argument by design. So there is no syntax for a lambda with no args. But we could do something like this.

\[ ] -> foo

So in a config it would look like this.

(button :onclick (\[ ] -> foo = bar)
"click me"
)

[max-ishere]

I did some shower thinking and came up with a combination of things that I read above here and in #324. Basically how about we add a new let binding after []. And rework action handlers so they take a... lets call it lambda. Now this lambda can be either of these things (maybe I forgot something so the list is non-exhaustive):
A Lambda is defined as

• (lambda ${Lambda}+ ) We can also use fn because im tired of typing lambda is kinda hard to type imo.
• (shell "") Executes a shell command
• (if $cond ${Lambda}+ else ${Lambda}+) An if statement FINALLY
• (for $bind in $collection ${Lambda}+ ) A for loop
• (let $binding $value) Either creates a new local state (within the scope of this lambda) or updates the value of the widget's one.
  I don't know how exactly would you pass params into a lambda since there is not really a way to call them? Like, it gets called by the onclick thing. So lambdas don't get params. If you want to access global state, then just do it.

I've typed lambda too many times, lets use fn instead. 😫

Oh and here's an example:

(defwidget poweroff [] 
  (let confirm false)
  (let unused "Too many brackets, lets just have each var be its own let")
  (eventbox :onclick (fn
    (if !confirm 
      (let confirm true)
    else
      (shell systemctl poweroff)
    (for nothing in "[]" (shell echo $unused "$PATH")) ; or (shell "${unused}")
; (let cant_declare_here "because only after [] and before widgets")
))

Edits

• Add (return), (break), (continue)

[max-ishere]

However this one does not solve one other thing I need to do: I need to unflip the boolean after a delay and I'm not sure how I'd do that...

[max-ishere]

Eeeeh,,, I think this might work:

(if !confirm
  (let confirm true)
  (shell "sleep 3")
  (if confirm
    (let confirm true))
else
  (shell systemctl poweroff))

But it will only work if there can be multiple parallel instances of :onclick (fn

[max-ishere]

Nah actually this seems like a really bad idea so lets not do this parallel stuff...

[max-ishere]

I think it would be easier to just make one button invisible and the other one visible

[Lazerbeak12345]

If there's any threading, I think it should be done via (shell ""). Eww could be single-threaded, but the shell command would be a child process. Eww would wait for the process to terminate, but if some other function like (bg-shell "") also exists, that fn could also run as a child process, but eww ignores if it terminates. One could sleep 3 && eww update var=value without blocking the update thread

[Lirik-Keltran]

What about using the lisp QUOTE or its symbolic designation `. This would also hypothetically allow to realize the conditions

(button :onclick `(update foo "new-value")
  "click me")