the function implementation is identical to ex_var with the exception of variable binding, of course.

sorry, I didn't get the difference

the internal logic is the same, it just does not resolve the variable by max_ex_var

        switch(argv->ex_type) {
                case ET_SYM:
                        if (argv->ex_flags & EX_F_TSYM)
                                optr->ex_ptr = gensym(argv->ex_ptr);
                        else
                                optr->ex_ptr = argv->ex_ptr;
                        return;

Well, sorry, I'm really confused. Are you saying you did create a new function named function?

Or is this just a PR that closes #2431 ? Meaning, if the PR is taken, can [expr var(a) = 2.5] work and set [v a] to '2.5' when taking a bang?

i'm not sure whether i groked function() either.

to assign values to symbols defined at run-time, how about using a value = assign(sym, value) function?
as in:

[list foo 10(
|
[expr assign($s1, $f2)]
|
|10\

i'm not sure whether i groked function() either.

after reading the code, i see that the problem is actually just one of bad wording in the description of this PR.
the newly introduced function is ref() (not function()), so the syntax would be:

[expr ref($s1) = $f2]

i still think an assign(name, value) function is easier to understand.

Assign makes more sense, or var could just take one or two arguments. If two, the second is assigned to the first

sorry for not being clear, i wasnt decided on the name thats why i wrote 'function', but your 'assign' actually makes more sense! and is considerably less messy

assign makes more sense, but I would avoid creating a new function altogether, and I like my idea of having an option for 2 args var() better and I believe Shahrokh will prefer that (I'm emailing him about this PR).

to be honest, i do not really see how var($s2, $f1) is really readable.
but anyhow, Shahrokh is the one to decide.

What about set(name, value)? Should be pretty self-explaining. I'd find this a bit more concise than assign, but I'd also be ok with the latter.

wouldn't preventing it from being callable before a = make the syntax less intuitive? if you can already assign a value to a variable like this: [expr x = 1], then calling set(name, value) to reassign a value might feel less intuitive.

depends.
name = value is certainly intuitive.
however, i find ref(name) = value less intuitive than set(name, value).

(i also think that = assignments shouldn't have gone into expr in the first place; there's a reason that s-expressions don't use it)

What about set(name, value)? Should be pretty self-explaining. I'd find this a bit more concise than assign, but I'd also be ok with the latter.

there's no 'upvote' on github so.. +1 vote for set
though I have to say also, the string processing and accessing variables make sense to be part of [expr] but imo setting variables seems somewhat out of scope, given that there's no 'real' control flow anyways it would probably encourage unnecessarily opaque/verbose/confounding expr instances

at some point you may as well include a small c compiler or interpreter or something instead (or I suppose you could keep extending the expr 'language' to include control flow and local variables etc.)