Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tactical solution for collections and iterators #276

Closed
3 of 5 tasks
degory opened this issue Aug 19, 2020 · 1 comment
Closed
3 of 5 tasks

Tactical solution for collections and iterators #276

degory opened this issue Aug 19, 2020 · 1 comment
Labels
enhancement
Milestone
dotnet-bootstrap

Comments

@degory
Copy link
Owner

degory commented Aug 19, 2020 •
edited
Loading

Long term plan for collections and iterators is covered by #255, but need to handle having two kinds of collections + iterators as we start to bootstrap.

The issue is that L has one notion of iterators, which is derived from Java, and we're moving to .NET, which has incompatible iterators. At the point of bootstrap, the compiler will need to be compiled with the L back end, but target .NET and .NET iterators.

If we were only going to encounter this situation once, I could go through the source code and change every iterator usage from L to .NET and bootstrap. However, in practice, the bootstrapped compiler will initially be too buggy to use, and we will need a period of dual running. I don't want to fork the compiler source for this, as that will necessitate applying bug fixes in two places.

We cannot do a simple textural translation between the two kinds of iterator as the semantics are incompatible.

I think the simplest solution is probably:

  • for loops handle either type of iterator depending on the target
  • continue to use Iterator accessor to generate iterators, as this can be trivially IL-renamed to GetEnumerator()
  • add a conditional compilation mechanism that operates at least at the class + method level, and also per statement if needed (i.e. use pragmas - could be as simple as @if.dotnet and '@if.legacy`
  • Write .NET's System.Collections.Generic compatible wrappers for whatever subset of L collections is sufficient to compile the compiler (.NET compatible wrappers for L collection classes #350)
  • replace explicit references to hasMoreElements() and nextElement(), where practical with indexed references to the underlying List
@degory degory added this to the dotnet-core-bootstrap milestone Aug 19, 2020
@degory degory mentioned this issue Sep 24, 2020
Closed
degory added a commit that referenced this issue Oct 23, 2020
@degory
Convert references to legacy collections
904e0cc 
- Replace most of the remaining references to Generic.Vector with Collections.LIST and Generic.Map with Collections.MAP
- Only build the collection wrappers if building for legacy target
- Replace references to STACK that relied on behaviour not available on .NET with LIST

See Tactical solution for collections and iterators #276
degory added a commit that referenced this issue Oct 23, 2020
@degory
Bug fixes
b63a267 
- Default to producing a .NET executable
- Temporarily rename the .NET `System.IO` namespace to `System.IO2`, to prevent it hiding the L `IO` namespace (see #427)
- Flush output + error writers before exit
- Fix incorrect `System.Console.write_line` shim
- Fix issues with `System.Text.StringBuilder` shim
- Remove debug output

See #276 Tactical solution for collections and iterators
@degory degory mentioned this issue Oct 23, 2020
Merged
degory added a commit that referenced this issue Oct 23, 2020
@degory
Groundwork for bootstrap (#432)
250faf5 
Various prerequisites for bootstrap, that will allow compiling the same compiler source for both the legacy L and .NET targets (see #276 Tactical solution for collections and iterators):
- Replace most of the remaining references to Generic.Vector and Generic.Map with Collections.LIST and Collections.MAP respectively
- Add wrappers around IO.Reader and IO.Writer that mimic a minimal subset of System.IO.TextReader and System.IO.TextWriter
- Replace most references to IO.Reader and IO.Writer with these System.IO.TextReader and System.IO.TextWriter compatible wrappers
- Add shim classes with static methods that abstract away differences between L + .NET for strings, string buffer/builders and file handling
- Migrate various references to legacy methods with calls to these shims
- Temporarily rename the .NET System.IO namespace to System.IO2, to prevent it hiding the L IO namespace (see #427)
- Only build the collection wrappers if building for legacy target
- Replace references to STACK that relied on behaviour not available on .NET with LIST

Other fixes:
- Default to producing a .NET executable
- Default to type checking when building for legacy target
- Flush output + error writers before exit
degory added a commit that referenced this issue Oct 24, 2020
@degory
Work on shims for bootstrap
6b63739 
- Work on converting code over to use shims in preparation for bootstrap

See Tactical solution for collections and iterators #276
@degory degory mentioned this issue Oct 25, 2020
Merged
degory added a commit that referenced this issue Oct 25, 2020
@degory
Additional L to .NET compatibility shims for bootstrap (#434)
c558240 
- Add additional L to .NET compatibility shims
- Migrate code over to using new shims
- Migrate more references to L collections over to .NET collections

See #276 Tactical solution for collections and iterators
degory added a commit that referenced this issue Oct 25, 2020
@degory
Fix type check errors compiling against .NET stubs
2f56e51 
- Fix type check errors compiling compiler itself for .NET target
- Switch the type check build script over to the .NET target

See Tactical solution for collections and iterators #276
@degory degory mentioned this issue Oct 25, 2020
Merged
degory added a commit that referenced this issue Oct 25, 2020
@degory
Fix errors when type checking compiler against .NET stubs (#435)
7aceea0 
- Fix errors running type check on the compiler itself for .NET target
- Switch the type check build script and the CI type check jobs over to the .NET target

See Tactical solution for collections and iterators #276
@degory
Copy link
Owner Author

degory commented Nov 14, 2020

Complete, via a combination of .NET collection-like wrapper classes around L collections and conditional compilation.

@degory degory closed this as completed Nov 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
dotnet-bootstrap
Development

No branches or pull requests
1 participant
@degory