On 7/2/21 6:18 PM, Kostas Michalopoulos wrote:
On 7/2/2021 4:38 PM, Sean Anderson wrote:
I have not. I'm not sure what changes I've made are compatible with the
vision he has for LIL. He's CC'd on this series, so perhaps he can
comment.
Yeah, sadly several of the changes i've seen in the code are not
backwards compatible and backwards compatibility is very important for
me
I don't intend to keep backward compatibility. The way I see it, U-Boot
has never had a LIL shell before, so there is nothing to break :)
(this is also why the callback setup is done through a lil_callback
function instead of exposing a struct: adding new callbacks in the
future wont break any existing code or application that links to the
library dynamically).
Well, C has a very nice ABI in some repects. As long as you only append
to that struct you will not break compatibility.
I might break it before a properly versioned release is made at some
point in the (not close) future, but that is usually unavoidable
changes to fix big issues (all cases where that happened are mentioned
in the site).
In terms of future changes, i do not plan making any *big* changes -
and certainly anything i'll make it'll be backwards compatible
(especially after a versioned release) but one thing that i need to do
is to improve the interpreter's performance, which will affect its
internals - two areas i might need to change are how values are
represented (everything is a string -and things must always behave
like that- but i may need to cache already parsed non-string values)
and how the code itself -e.g. in functions- is represented.
One of the nice side-effects of adding a separate parser is that it will
now be very easy to get some performance gains by parsing code once and
then re-using that parse on subsequent evaluations. For example,
functions could be parsed on first use, and cached. Loop bodies could
re-used for subsequent iterations.
Also i'll most likely add more functions to the library to expose and
alter internal state (the Free Pascal version of LIL already has some
of that), but that shouldn't affect much internally.
Beyond that it will be mainly bugfixes - like a use-after-free case
with "reflect this" i just fixed and uploaded :-P
As it happens, I ended up removing that because there was no longer a
"rootcode" after removing the parsing step. Perhaps at some point I will
add it back, but I do not see a pressing need for the same level of
dynamicness that you built in originally.
--Sean
