I printed out my examples to see what was really happening with them. I’ve been doing this thing for a while now called problem sets or problem statements, that detail the difference between the expected output and the output that is generated (by GenerateC, and by extension, by DeduceTypes2). The object of that exercise is that there is somewhere between the source code of the examples (and the accompanying standard library (alot of stubs in its current incarnation)), and the output, which is not generating the right results, and that is THE PROCESS. The process is a monster to debug – it’s not a terrible monster, but it’s a monster nevertheless. It’s a couple thousand lines of code. It’s really confusing. It’s spaghetti code – ravioli code, whatever you might want to call it. I been doing a couple of projects intended to help it get a little bit clearer – DeduceObjects are slowly creeping in. There is DeduceLocalVariable, which at this point I believe only does typeResolution, and it doesn’t do it completely and it doesn’t do it in all cases. In any event typeResolution is not depended upon (integrated with) by any other part of the program. We have a number of other classes which are pretty much stubs, which means that they are not doing anything right now, but the plan is to fill them out, fill them in and let them take some of the complexity out of DeduceTypes, having them in their own separate classes so that they can be TESTED. Hopefully we can get to something which can be tested. The classes as they stand are pretty much coupled with the Generated/Deduce layer – well let’s say they are related, in that there is the possibility of coupling if the design isn’t carefully thought out, and the design isn’t really even there yet. And I mean coupling for the sake of not having to generate mocks for their eventual tests – they of course have to use the defining classes of their environment.

So I printed out these examples, and I don’t know what was on my mind when I printed them out except that I wanted to figure out what was going on with them. And I don’t know how I got to the point where I created E-Log. E-Log, at the current moment, is a set of logical statements – facts – about the program as it’s understood. It’s not complete by any means. In other words, there’s information that is in the Deduce(Types2) layer that is not represented in the E-Log. I’ve been jumping back and forth between the Deduce layer, namely I started with dp.generatedClasses and use GeneratedNodes, and then we kind of jump into the elements. And until I get DeduceElements all the way up and running, it looks like its going to be like that for a while. The only other place (not true – DeduceTypes2 uses plenty of OS_Elements) where I jump between the Deduce layer (meaning GeneratedNodes and its ilk) and OS_Elements is where I’m translating the OS_Elements into GeneratedNodes, and that is GeneratedFunctions. And I was thinking that when this proof of concept gets finished or mature enough, then it can be moved over there. Maybe. Because I always want, part of my vision of the refactoring that I’ve been talking about to get the manipulation and analysis of data as close to the access (or creation) of the data as possible, so that there is only one function (or class) that touches each piece of data. I think that in certain languages, this is the norm, and Java doesn’t enforce that, and that why you get spaghetti code. Otherwise, maybe the code would have been much cleaner if I had chose a different paradigm. Maybe.

Anyway, I have this E-Log, and a lot of the facts I generate are primitive; they don’t represent the full knowledge of the program; and they’re incorrect – they don’t use the type system (and that’s another reason to integrate it – to get it into the type system). And instead of having a monolith, which is how I created DeduceTypes2 and GenerateFunctions (and DeduceTypes 1, that came before both), I envision small, type-centered modifications or transformations (or whatever word you’d like to use) to ensure types are correct. And E-Log is also not type correct. I want to do a type checker, but then that means I need to create a query language and execution engine taht would allow me to express what I call Conjectures. (Maybe I call individual facts predicates, or maybe the predicates are the clauses of the execution engine – this is all based on a Prolog-like imagining, and even though the syntax is different, it wouldn’t much trouble to translate what I have into standard Prolog, especially since I am in such early days. It would be a bigger deal to find a Prolog library and see how it works, and how it integrates with Java, and integrate all that into the final product in Elijah, though at second thought I don’t think this would be that hard. The difficulty I foresee is from it being in C (but remember I’m not writing any C, or minimal C at the most…), which I get less and less excited about every day, even less excited than about Java, but then, what choices do you have? There’s LLVM, and this other guy is having problems with LLVM (although I don’t know that status of LLVM in other projects like Haskell and Rust, and he chose an early version – the API stability might be solved by now), and we know that it’s really slow. And GCC is a beast to work with. Of course there are other languages, but it’s not like I’m mad about it.) The objective now is to all the facts are well formed – facts form a graph, just like the other representations of the program (in the Deduce layer especially, even if it’s not complete). This is a project to help me reason about this graph.

The reason why there is a dependency on OS_Elements is that I derived E-Log representation directly from the source of the examples, but with knowledge of what the type are supposed to be. DeduceTypes2 is supposed to provide help in the form of it’s namesake, that is, to deduce types from the source where they are not specified in the source.

Back to posts