Commit Graph

960 Commits

Author SHA1 Message Date
Nathan Braswell
8cdf41826b Starting to port over & self-host! 2022-03-03 00:33:25 -05:00
Nathan Braswell
4a273c9ba2 Bigfix error infinite recursion, error printing, wrap_level not being in hash_comb, extend to_compile.kp a bit 2022-03-02 01:44:20 -05:00
Nathan Braswell
dd0463d059 Comment out generated debugging and other log based code for large speedup - tried several other optimizations but they counterintitively made things worse 2022-02-28 23:47:02 -05:00
Nathan Braswell
3f26a3ad7d Finish porting mif and fixing up other inconsistancies. Fix bug for emitting signed numbers as hex in compile. Runs correctly in both Chez and Chicken interpreter now, which Chez being about 3x faster 2022-02-28 00:27:19 -05:00
Nathan Braswell
ea15f48d6f Implement dlambda and correct dlet. More attempt at Gambit 2022-02-23 16:43:03 -05:00
Nathan Braswell
54097ac074 Port the let+ macro from http://www.phyast.pitt.edu/~micheles/scheme/scheme15.html over mostly, and it works in both Chez and Chicken! Will massage some more to get it to be the same as our previous dlet, but it is working! 2022-02-23 00:56:46 -05:00
Nathan Braswell
f8bab2ada5 I caught the Chicken compiler red handed, it's compiled version has zip change behavior part way through, caught in the act with some prints. Where it does so changes based on optimization level, which is a bad sign. Starting a (hopfully quick) port to more standard scheme - looking to support Chez and Gambit in addition to Chicken, with at least some commented out code if not some sort of conditional compilation. We're off to a roaring start with define-syntax broken in Gambit 4.9.3, from 2019, but there was a new version released last month that I think should fix it. 2022-02-22 02:19:17 -05:00
Nathan Braswell
58f3d7858e Rework the destructuring lambda in what I'm now calling the true-macro-style, so that helper functions don't close over the dynamic env and cause it to not partially evaluate away 2022-02-20 23:42:09 -05:00
Nathan Braswell
2874be3332 Fix the bug with de getting seperate dynamic envs, now unified but no opts for now (doing it seperetly was broken because of tyring to access it from inner closures. Also add a lot more runtime logging 2022-02-20 22:12:21 -05:00
Nathan Braswell
7ce2db21ff Actually, make sure to always include it if there are other progress_idxs 2022-02-19 00:43:27 -05:00
Nathan Braswell
6cd9dd0831 Move over much more code, including the tricky destructuring lambda which revealed bug in the need_for_progress system - a call that takes in the dynamic env that failed and had to be re-constructed would set attempted on the call to true, but would not note the dynamic environment as one of the needed-for-progress idxs. Often I think it would be anyway, so this didn't come up too often, and of course finally revealed itself when doing nested let/lambda destructuring stuff. Fixed by having attempted record not just true or false, but in the case where it's a call that takes in the dynamic env, makes it that env's id, which gets added to the for_progress_idxs. 2022-02-19 00:14:36 -05:00
Nathan Braswell
dd2191f75d Made vapply and lapply primitives for efficiency/partial eval reasons. It means they can exist in emitted code without calling out to eval, which is good. to_compile.kp now both compiles and runs! Now to add more 2022-02-15 23:16:27 -05:00
Nathan Braswell
fd37fa9b00 Had missed handling the empty call case () as an error in compile, which will happen when specutively compiling as code a nil that should be passed unevaluated, etc 2022-02-12 12:10:08 -05:00
Nathan Braswell
d5ea55fa08 And we're compiling again! Smaller tests seem to work, including compiling and running a minor factorial (not Y comb). to_compile.kp errors out with a weird nil coming from somewhere, that will be have to be investigated tomorrow. 2022-02-12 02:05:45 -05:00
Nathan Braswell
bd00933763 Fixup cond to partially eval as much as it can without incuring infinate recursion! 2022-02-11 02:21:18 -05:00
Nathan Braswell
69fd587989 Fixed the Y combiner not partial evaluating as far as it should thing by adding infinite-recursion-blocking-hash-tracking to the needed_for_progress infrustracture. Only arrays need to track it, since at function boundries you won't want to reevaluate it anyway until the function is called. Having a hash from the IRBHT be not in your memo counts as a #t true need to re-partial eval. 2022-02-10 01:15:02 -05:00
Nathan Braswell
325afd773e Added partial_evaling to drop_redundent_veval (a bit hacky, have to pass partial_eval to it to break mutual recursion & had to add a 'force' option to partial_eval to force re-evaluation for situations where drop_rdundent_veval has changed something but the needed_for_progress wouldn't pick up on it.) This theme continues with the current problem with the Y combiner test, which is that recursion protection trips on the partial eval of the recursive application (x x) in the Y combiner, but it doesn't actually need any other external values, so when the time comes that it is actually needed as a value it skips it and ends up only evaluating a single level even for a value-only top level recursive invocation. Finally, still need to figure out a better situation for cond/vcond to partially evaluate itself without triggering even more infinate recursion (that's truely value-only, without a cond to stop it). 2022-02-09 22:49:06 -05:00
Nathan Braswell
6e18a66e3b Make drop_redundent_veval recursive, but realized we now need to re-partial eval in the cases where it does change. Added fail points with error messages for things I know I still need to do - veval is in a tricky space now because it *can't* have the main calling code re-evaluate it's parameters, but with the new prim comb works like regular change, it does. Maybe a negative evaluation level? 2022-02-09 01:11:13 -05:00
Nathan Braswell
5a67c704e0 Bugfixes and initial implementation for cond. Many tests passing now, though cond should further evaluate it's members without causing infinite recursion and drop_redundent_veval needs to be able to traverse for drops, since we allow returning whole function calls 2022-02-08 23:51:00 -05:00
Nathan Braswell
9daff0f482 Work in progress commit to make it so that anything unevaluated is already a value of the code that it is, which is the proper way to not have to ensure_unval which is fundamentally broken and causes mis-partial-evals. Refactor parameter evaluation and have prim combs mostly use that as well. Remaining is implementing cond properly and fixing bugs/typos 2022-02-08 02:48:40 -05:00
Nathan Braswell
931dd9a8f5 Implement drop_redundent_veval and make veval properly re-partially-eval and update the env it's called with. Y combiner test added and works now, map still seems not to, about to look at it 2022-02-07 00:31:51 -05:00
Nathan Braswell
31a8002a11 Finally excise what I belive to be the final exponential behavior, namely by adding memoization and better traversals to check_for_env_id_in_result 2022-02-06 16:34:47 -05:00
Nathan Braswell
76065d1957 Implement veval and combiner_return_ok enhancements, now let4.3 behaves like the proper macro expansion. Compiling our test doesn't work though, it doesn't partial evalaute the vaus away as expected - changing let1 implementations does have an effect. Will need to investigate, as well as add support for compiling away veval 2022-02-05 12:14:13 -05:00
Nathan Braswell
7310eeaee3 Fix up inverted condition on combiner_return_ok, fix regression on error checking for parameters in calls. Hopfully proper now, just needs better combiner_return_ok (both memo and allowing further partial eval) and allowing-further-partial-eval for eval 2022-02-04 01:28:18 -05:00
Nathan Braswell
a8f8f9df89 Removed check_for_symbols, which was a bad idea generally. Simplify into combiner_return_ok, and fix *eval bug* - it didn't check for any sort of combiner_return_ok like thing, even though it's doing the same thing as a function call basically, by changing the env something is evaluated in.
Also just re-write eval using the parital_eval wrapper, enforce it taking in total-values.

In the future, can allow more partial eval
        1) veval, returned from eval and posssibly others, essentailly (unwrap eval), which allows embedding partially-complete evals places without having to do something ugly like (eval (ensure_val partially_evaluated))
        2) Relax paramter is total-value to head-value and check for env_id inside it

Immediatly: Debug bad partial evaluation on main test cases & crash with list index out of range
2022-02-03 02:41:14 -05:00
Nathan Braswell
dd28087818 Some more updates based on feedback 2022-02-02 01:41:19 -05:00
Nathan Braswell
6f3d8d514b Added quote example 2022-02-01 00:50:36 -05:00
Nathan Braswell
c05a7bd2d5 More slides work, expanding examples, proof reading, adding explanation 2022-01-31 23:42:27 -05:00
Nathan Braswell
2f395926d3 Fix 2022-01-31 18:35:14 -05:00
Nathan Braswell
3086ad4b01 First draft of presentation 2022-01-31 00:08:37 -05:00
Nathan Braswell
df76ae51e2 Start to fill in Abstract/Introduction/Related Work/Issues/Solution 2022-01-30 20:20:16 -05:00
Nathan Braswell
7f220c97b8 Finally make a clean sweep and delete / organize old files. Add skeleton for LaTeX formal writeup in doc/ and change license (since this is all new code from the past few years) to BSD-2-Clause-Patent 2022-01-30 16:57:21 -05:00
Nathan Braswell
315ae20698 Clean up strip, have default memory allocation scale based on constants, added more until the next bug found, map seems not to be partially evaluating properly 2022-01-28 00:26:46 -05:00
Nathan Braswell
90750933fc Fixed the recursion! Memo has moved to just being the infinite recursion detector based on body and inner-env 2022-01-27 21:54:15 -05:00
Nathan Braswell
2746e1ca75 contains_symbols is/was exhibiting exponential behavior - probs memoizing or using needed_for_eval could fix it, but also it doesn't normally have to be called, so just doing that got us a 50x speedup or so 2022-01-26 23:43:50 -05:00
Nathan Braswell
c8df8742d1 Actualy I'm just going to disable memo except for recursion detection 2022-01-26 22:45:16 -05:00
Nathan Braswell
3748610dea Can finally compile let! The memoization of partial_eval was allowing re-introduction of fake envs somehow. Temporarily disabled, also added a bunch of debugging aids like str_strip only printing envs in full the first time, need_value being passed through compile to fail faster, etc 2022-01-26 22:41:29 -05:00
Nathan Braswell
9bc658a1a4 Ah, found additional infinate recursion. In the process of fixing the second, trickier one, caused by compile & partial eval together. Should be fixed? but there's a nil coming out somewhere 2022-01-26 01:55:38 -05:00
Nathan Braswell
d4752eddb4 Fixed the bug! ctx has env in it, and was being returned upwards, messing up the environment of subsequently compiled things. The key is to make sure things that modify the environment (compiling functions) return the env it was passed in the ctx 2022-01-25 16:51:06 -05:00
Nathan Braswell
77c7a05a28 Hopefully fixed the new exponential behavior by piggybacking on a now more accurate needed-for-eval tracking (that hopefully didn't introduce it's own exponential behavior but might have), and other fixes. We still have the same weird problem though 2022-01-23 14:16:07 -05:00
Nathan Braswell
94e2d62a10 Ok, finished fixing check_for_env_id_in_result, now works up to before. Weirdly, we're now just back to the previous error, and I think I might have reintroduced exponential behavior with the env_id searching 2022-01-22 00:56:02 -05:00
Nathan Braswell
99926cdb7c check_for_env_id_in_result fixed, I had accidentally left it unimplemented. Bug with envs escaping when they weren't real fixed, and most everything works, but compiling lapply fails now 2022-01-22 00:19:10 -05:00
Nathan Braswell
8a1e92cd70 Make partial_eval_helper fail gracefully as well, as per previous explanation of why it's required (called from compiler to opt eval side of maybe only vau calls). Gets farther than before, but has a new error now for compiling Y that I don't have time to debug tonight 2022-01-20 00:32:15 -05:00
Nathan Braswell
6602ff3151 The refactor has either caught up, or is close, and is much faster.
Need to make partial_eval_helper able to fail though, so that it can fail in the now fallible compiler.

Squashed commit of the following:

commit 283150d1e19cf9f74bc32e9c554f5e041d53582d
Author: Nathan Braswell <miloignis@gmail.com>
Date:   Tue Jan 18 00:14:51 2022 -0500

    Another bugfix, I think now we're truely running into the partial-eval needs to be able to fail part

commit c62c228a1e89e7922850d2070bc046e5f80af5a5
Author: Nathan Braswell <miloignis@gmail.com>
Date:   Mon Jan 17 23:34:19 2022 -0500

    Fixed needed check, added note on needing to support failing partial eval

commit d480e486210dd5c7c4842e3a3d3e447dc7a5274e
Author: Nathan Braswell <miloignis@gmail.com>
Date:   Mon Jan 17 22:14:58 2022 -0500

    Fixed compilation bugs, added debugging prints to running.

commit fc4dc4d3170bf1ceb4cd934cff54dd9ce6c8713a
Author: Nathan Braswell <miloignis@gmail.com>
Date:   Mon Jan 17 17:28:29 2022 -0500

    The unique id / ctx refactor is starting to work, with all basic test cases compiling & partial evaling, but mis-compile bugs remaining
2022-01-18 00:36:42 -05:00
Nathan Braswell
49c5e9da2f Added the lazy eval function thing.
Keeping it off is 5.3s
Turning it on is 6.8s
Forcing it on always, which I thought would cause compilation problems (and I guess just turns most optimization off, but does enough to remove vaus?): 2.8s
so using it the way I designed makes it worse
and using it to a degree I thought it would be buggy makes is way faster
Indeed, forcing it on all the time does cause it to error for larger cases, but it is interesting
So I'm not entirely sure where to go with that, I think smaller test cases and profiling number of calls or something is warrented
2022-01-10 01:26:56 -05:00
Nathan Braswell
74a7cb8a20 Don't repeatedly evaluate params in different cases - I thought this would be a larger optimization, but it seemed more like 1%... 2022-01-09 00:45:16 -05:00
Nathan Braswell
025b149c28 Implemented each marked node carrying the de Bruijn indicies that it needs to continue evauluating, but now it takes the exact same amount of time that it used to
And I think I've realized why - it's being too conservative about what it actually needs to be a value and includes the entire environment chain, which pretty much means anytime it would have been re-evaluated because a parent function was called or re-evaluated it will also be re-evaluated, and none of this changes anything
I think I can change it to more intelligently pull what's necessary based on what's used in the body of the function instead and get the optimization to work as I expected - fingers crossed
2022-01-09 00:17:57 -05:00
Nathan Braswell
6ef60c4cc6 I belive I fixed the bug revealed by the let definition - it was a similar thing where <comb>s were counted as values even if there were fake envs inside, and then thouse fake envs could be moved inside another env_stack and then later resolve to a wrong env, or at lest I think that's what was happening. The let test takes too long to run now - I killed it at 20 minutes and 48GB of RAM taken. Given that, it's now time to move on towards optimization 2022-01-07 22:08:29 -05:00
Nathan Braswell
b559bfdf90 Add note about compiling params meant for Vau & additional partial eval for that case to help in cases where it's legitimate. Eventually it should handle errors gracefully, but non-gracefully can be good enough for now. 2022-01-05 22:58:26 -05:00
Nathan Braswell
1aa9ca972a Fix & and error checking for compiling environments as code & value, add a todo for things deferred 2022-01-05 01:05:16 -05:00