Unified Workspaces#117
Open
iwillspeak wants to merge 6 commits into
Open
Conversation
iwillspeak
added
feature
iwillspeak
force-pushed
the
feature/workspaces
branch
from
6492cd7 to
33120ea
Compare
Firethorn 1.0 changes TextLength from int to uint32. Centralise the int/uint32 boundary in Text.fs by adding TextDocument.advance, which converts an int character count to Firethorn.TextLength. Remove all #if USE_NEW_FIRETHORN conditional code paths now that the upgrade is complete. Benchmark results on the Scheme parser hot path (chibi-r7rs-tests.scm, BenchmarkDotNet v0.15.8, Linux, Intel i7-10750H, .NET 10.0.7): Firethorn 0.4.1: 16.08 ms, 15.9 MB allocated Firethorn 1.0.0: 13.33 ms, 14.14 MB allocated Ratio: 0.89x time, 0.89x memory (~11% less memory, ~17% faster)
iwillspeak
force-pushed
the
feature/workspaces
branch
from
c03db9f to
518b7f4
Compare
Not all CST nodes _are_ for a specific document. Fabricated syntax may not have a document at all. Documents will be fused to the CST in the Stx pass. The parser should return a root with the document and CST.
A CST Item's TextDocument is now held in the SyntaxRoot that the parser returns. This can either be discarded or retained by the caller. Later phases like the binder expect a SyntaxRoot<Program> or similar rather than just a Program so the document must be preserved. This brings all the tests back to passing. Still TODO: * Stop resolving the source locations when the Stx tree is created.
Replace the 96 bytes (+ padding) of TextLocation with a single compact 16 byte struct. This should reduce memory use on syntax trees and avoids us having to do the range -> location resolution in the Stx.ofExpr call. saving us a reasonably expensive search on each node we project.
iwillspeak
force-pushed
the
feature/workspaces
branch
from
c97446e to
f458ed2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A unifying solution to #101 and #111.
The rough sketch / plan here is to switch to a more incremental appraoch to compilation. A workspace
module will be introduced which manages source code in both the raw and parsed state. On top of this a compilation layer manages binding and symbols.
In addition we need to intorduce a true first class
Symboltype. ASymbolwill represent an item whichcan be bound or defined. We can then use these to refer to definitions and references to differen item
types (variables, macros, libraries, etc.). Symbols proivde the layer of abstraction to allow the bound tree
to build up semantic inforamation about a given item before we pin down its location (e.g. local, global. etc).
We can build on them later with attributes to facilitate things like "suggested names" for potential "phi" symbols
such as those referring to a
lambdadefinition, or type information from inference.WE only lower symbols to actual local / environment / argument slots or indicies in the later
Lowerpassonce semantic analysis has been completed.
This should then open us up to some more adanced refactorings such as inlining, escape analysis, and closure
lifting.