{"push_id":836280335,"size":6,"distinct_size":2,"ref":"refs/heads/master","head":"e220c9456bfa781a095f919ce389d64db18127db","before":"5e89b5ba838754a781ef3546f25063abd2731b80","commits":[{"sha":"cb5cc4483e6ac61de34b9d8cc32cf7a3e2b8d799","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Change the usage of the multi array syntax","distinct":true,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/cb5cc4483e6ac61de34b9d8cc32cf7a3e2b8d799"},{"sha":"25039dc4e77921614fd25d2c949ee96cca80416e","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Add a test for the arguments","distinct":false,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/25039dc4e77921614fd25d2c949ee96cca80416e"},{"sha":"dbea212fc64b10d889ed57eddb809c619f715ade","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Add test","distinct":false,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/dbea212fc64b10d889ed57eddb809c619f715ade"},{"sha":"b68b276a9325f492e1b1c719d97e11894bc756cd","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Reorder some structure and add a test","distinct":false,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/b68b276a9325f492e1b1c719d97e11894bc756cd"},{"sha":"25575d58cbd0f42b20e521dbbcba69f6c6675ed2","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Implement some basic ideas of table building.\n\nI'm still not certain how to go about this. First, the table needs to be built. My\nconcern is with how the tree is pruned. It doesn't seem that clean. I wish there was\nsome more formal mway of pruning the tree. Anyways. After pruning, I iterate the tree.\n\nAn idea is to have a table builder for each specific case. Say you get a keyword grant\nas the first child, delegate that to a special grant builder. Get a variable declaration,\ndelegate that...\n\nCurrently, the parse tree should ideally be transformed into a perfect abstract syntax\ntree. That would be ideal. However, what is the ideal abstract syntax tree? Hopefully\nI can prune the parse tree in such a way that it will be perfect. I also need to look\nif I can change the grammar slightly - to make it more suited. I won't prematurely\noptimize the parsing or lexing. Those are fine (even though the parser uses a binary\ntree lookup).\n\nSo, we get a 'perfect' AST. Then we need to generate a table from that. Yeah, sounds\nlike recursive definitions would be best. Just use small classes to identify their\nrespective sub-trees. How would this look for alias? Alias is one of the simplest\nones. Indeed, it would call upon the type subsystem to do its bidding. Okay... Hmm.\n\nLet's focus on a single thing at a time. We first compute all aliases to create a\ntable of aliases in a class. What will the table look like? Well, we know an alias\nis always a class name, so we get a function:\n\n\tgetAliasType(string) -> Type\n\non a table looking like\n\n\tMyAlias: sml.ComplicatedClassThatsWayTooLongToNormallyWrite\n\tAnotherAlias: 3u\n\tBool: 1u\n\tVertexArray: [3, float]\n\nOkay, good. So we now have an alias interface per module. Each module will have all\nits aliases in this place. Whenever we then go over any other code, we can look up\nthe type inside the alias section to check if the type is there.\n\nThe problem is that alias can also be used inside a function itself, so a function\nlocally needs to be able to declare stuff as well. A function will be tied to its\nsurroundings, but also acts as a single entity. For example, building the tree for\na function can be done independently of the surrounding scope because the function\nworks on its own. Unresolved types are just delayed and put into a table for unresolved\ntypes. Later on, all the unresolved types are resolved. If they are not, we have an\nerror. What happens next?\n\nSo for functions, we actually need to segment the code into different states. For\ninstance; we must create a vector of declarations and runnable code in that order:\n\n\t[Declaration(s), code, declarations, code, ...]\n\nThis is because declaring before use is important. If the code uses something that\nis not declared, then we have an error. A function would be able to utilize global\nand glocal variables, and these need to come from a bigger context. This should not\nbe too difficult, as the system can rercursively compile. Though, we can also say\nthat those are resolved at link time. Anyhow, let's focus on the single class. The\naliases don't care about declaration order, so they will always work. Inside the class,\nwe create a vector of code and declarations. How about branches? They are their own\nlittle functions - in a sense. They can use what has previously been declared, but\nanything declared inside them will not be available outside of the branch. I need\na way of structuring all this information.\n\n\tModule:\n\t\tAlias Table (AliasName, Type)\n\t\tGrant Table (GrantName, Assertions)\n\t\tVariable Members (Globality, Visibility, Name, Type)\n\t\tStatic Members (Globality, Visibility, Name, Type)\n\t\tMethod Members (Globality, Visibility, Name, Type)\n\t\tVisible Globals (Name, Type)\n\nThat is how a module will look like. Now let's think of methods of breaking this up.\nThe alias table is really just a table of names and types. The type will need to be\nrepresented in some kind of vector form:\n\n\tType: [ref, ptr, 32u].\n\nSince types are linear in composition, we can easily perform operations on them. For\nexample, saying:\n\n\tType.dereference()\n\nShould return a list that has removed the ptr from the beginning. Else, it will throw\nan error, because the first type is not a 'ptr'. Enumerations can be used for this.\nPerhaps even CrossTerminal, considering their availability. Alright. So types are\npretty easy to work with. Type is just a class. That's neat. What about the other\nstuff that's going on?\n\nGrant table with assertions? Hmm, well a GrantName is just a classname, so a string\nwill suffice. The assertions are a little different. Let's analyze how they would\nwork. An assertion is basically a function signature or a variable signature. In fact,\nthese are actually variable/static/method members without their actual content (such\nas default assignment, or method definition).\n\nThe type of a function is a little different.\n\n\tType: [function]\n\tReturn: [[name, Type], [name2, Type],...]\n\tIn: [[name, Type], [name2, Type],...]\n\nSo,... what happens now? What about nested functions? Well we need a \"functiontype\".\nSo a type can contain a \"functiontype\". The functiontype can contain more types, as\nit contains a list of in and output parameters. Okay, cool, we can then at least check\nif i/o params exist. We also need to overload on the types, such that types are part\nof the key to the table.\n\nLet's start with a table of types and take it from there.","distinct":false,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/25575d58cbd0f42b20e521dbbcba69f6c6675ed2"},{"sha":"e220c9456bfa781a095f919ce389d64db18127db","author":{"email":"bb006872d448ed65d3acd0ff0c8cd065774a9ff4@gmail.com","name":"BourgondAries"},"message":"Add some information regarding the table system.","distinct":true,"url":"https://api.github.com/repos/BourgondAries/Cxy/commits/e220c9456bfa781a095f919ce389d64db18127db"}]}