Yes, I do need to update things there. I mentioned redefinition in the context of side-effects because I wanted to emphasize that you could isolate a Fexl function in a safe "sandbox" so you could prevent users from calling "print" or "unlink" directly, or even substitute a simulated file system so they can call "unlink" safely. But you're right, they are two separate issues.
On your second point, Fexl is definitely not eager. It is the laziest thing you'll ever see.
And no, you cannot mutate state in any way.
On the subject of "how are data structures handled", I do address that at the top in "RULE 1: Everything is a function." There I say that all data are represented as functions, and I do show a little link to some exposition below.
Thanks for the help on "selling" the language -- until now, I haven't been concerned about that because it's all for my own purposes. But I take your point.
Comments
Yes, I do need to update things there. I mentioned redefinition in the context of side-effects because I wanted to emphasize that you could isolate a Fexl function in a safe "sandbox" so you could prevent users from calling "print" or "unlink" directly, or even substitute a simulated file system so they can call "unlink" safely. But you're right, they are two separate issues.
On your second point, Fexl is definitely not eager. It is the laziest thing you'll ever see.
And no, you cannot mutate state in any way.
On the subject of "how are data structures handled", I do address that at the top in "RULE 1: Everything is a function." There I say that all data are represented as functions, and I do show a little link to some exposition below.
Thanks for the help on "selling" the language -- until now, I haven't been concerned about that because it's all for my own purposes. But I take your point.