-
Notifications
You must be signed in to change notification settings - Fork 18
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
Debugging code involving lenses is hard #40
Comments
I agree that the call stacks are monstrous. I'm not really sure how that refactor would work; could you give an example? |
Here's ~what code of mine I changed since I posted this issue. This change made debugging much easier, so this should be happening automatically behind the scenes. (Yes, this is not lawful use of optics (it's fine if I only get nice debugging for lawful uses) and the code blocks are unequal and both wrong.)
|
The OP example fleshed out:
|
Yes, but the problem is that I don't know how to get from here to there. All the functions in the call stack are there to provide the abstraction necessary to allow all the lenses tools to compose together. Maybe some of those layers can be eliminated with clever tricks, but short of dynamically generating python code and then Or is that what you're proposing here: |
Yes, that's what I'm proposing! That your syntax is When I look at the type of a lens like |
I thought lenses were confusing enough without trying to jam dynamic recompilation into the middle of everything. I will admit that I find such a challenge tempting. I'll see if I can find time to do some experiments. No promises. |
Fallen at the first hurdle. Python doesn't show the source code when printing tracebacks from dynamically generated code because it looks up the filename and reads the file. For example, if you run I'm open to any other ways to make the tracebacks easier to read if anyone has ideas. |
I don't really want to write to a temporary file on every invocation of a lens. |
See it as just-in-time compilation! Have you ever written code such that you couldn't cache the compiled version per calling code location with length_of_tmp_code in O(length_of_calling_code)? |
The call stacks end up super deep and the order of operations strange. Have you considered a refactor where
lens.....get()
is compiled into a function block where.F(getter)
corresponds tostring2 = getter(int5)
,.Recur(Foo)
corresponds tofor foo in recur(Foo, bar):
, etc.? If the only reason against is months of tedious refactoring, say so - they might be the kind that AI tools these days solve.The text was updated successfully, but these errors were encountered: