Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle loading code (unfreezing) #35

Open
mariari opened this issue Jul 5, 2022 · 0 comments
Open

Properly handle loading code (unfreezing) #35

mariari opened this issue Jul 5, 2022 · 0 comments

Comments

@mariari
Copy link
Member

mariari commented Jul 5, 2022

Currently I don't eval any code until It's time to extract. One runs the pipeline, and the function is transformed on the spot!

However it would be nice if code the user writes is ran right away all the way down to vampir and cached. However for testing purposes I'd prefer evals to freeze by default so I can run the pipeline myself manually to certain stages.

In order to accompany this i propose the following

(defparameter alu::*freeze* nil
   "determines if circuit definitions freeze by default or not")

this variable being set to true means that the circuit freezes as it does now, however if we set it to nil (which for the user it is by default!). Then the circuit will try to evaluate on the spot, warning the user if a function is missing. We should assume a function call is a function call and try to catch the warning with replacing it with an application call at the Alucard level.

If the type can be inferred then great, don't error, otherwise ask for more information.

This means we should also increase our caching system for new definitions. For circuits we define this is trivial, as we can setup a system that will notify the circuit on next dump if the cache needs to get renewed. For user defined functions this is also trivial, as we can make it also update this system.

However, if the user uses the base defun the situation is different as we can't determined if it's been changed, maybe with engineering even this too can be updated properly.

Thus we should define the following functions

(redefine-circuit-type new-type)
(redefine-function function-name)
(valid-cache? circuit-in-storage)
(recaluate-cache circuit-in-storage)

where redefine-circuit-type gets called if a defcircuit call changes type, as we must recommit type checking.

We can retype-check all locations now, and warn the user on type errors elsewhere on the system. Or simply delay it, while also giving the user a way to check what functions are affected..

redefine-function denotes that an inlined function has been redefined, and we need to re-run our generator. We can use this same feature for user redefined macros.

valid-cache? simply checks if the cache is still valid. A call to either of these two functions should trigger a nil from this call.

reavluate-cache just forces the re-evaluation of the body, whether we like it or not.

we may want to also add a force-recompile-all-calls to force the recaching of all functions which call the current one. We likely shouldn't do this by default as it can get quite expensive, and thus have users waiting at their listener on some very commonly used redefns

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant