mirror of https://github.com/tbklang/tlang.git
Context's .container
deemed useless #53
Labels
No Label
dependency
emit
hashmapper
lebanonmapper
lexer
meta
needsfix
parser
qol
question
resolution
typing
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tlang/tlang#53
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What is
Context
?The
Context
is passed around to indicate InitScope of an item and the container of such a thing. However, many parser nodes have aparentOf
field, so this part of Context can actually be removed and is not needed.I believe the reason it probably was added was I realised that things like
Expression
in the parser had no parent information and then I added this but everything then started usingContext
. What would be a good fix would be to remove thecontainer
field fromContext
and switch up dependency to be able to work with just that as it, literally copies it across.For example, when we have a VariableDeclaration, something the parser could easily (and in this case probably already does) set the parent of, we call
generalPass(module, context)
:THis could be retrived, for the variable declaration itself, by the first argument of
generalPass
which is a container.We need to make sure everything is parented first in parser before such a switch can be made.
Original discussion
Notes
_ What was the reason for a Context object? Othee than for me to store InitScope
Container
which is where they live, andentity.setContext(context)
really just contains that copy of the Container (an object reference).
parentToContainer
in situations likeparseExpression()
where we needed to localise like where it could be used.Obviousl InitScope info was needed but we didn't like have
parentOF()
set for thingslike expressions, hence it was added as an after thought.
We really could have done that, and passed Context only really as for
stuff like InitScopre. It shouldn't be a huge work around but I will do it later.
Thankfully we only use Context wherever we go in the dependency generator.
Bump