You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More of a a backup, since it's not directly related to OSS contribution in general or to the F# compiler.
Description
Every Friday, Amplifying F# and their Champions prove that it's possible to change or enhance a real world compiler and it's tooling, without the need to ever having implemented an own language (+compiler), and without the need for being an expert in that field. It's indeed often possible to get things done by focusing on very particular areas of the compiler, without the need for knowing the interrelationships of all compiler parts and their details - and that's good, because doing so would be quite challenging (and time consuming).
But at some point when working on the F# compiler, questions might come up, which could be hard to answer, like why things are implemented the way they are, in which area could things possibly be located, which things could be influenced when touching something, which alternatives could be thinkable when trying to solve a problem?
Some time ago, I've written a compiler on my own out of a practical need (for an F# text template type provider called "Trulla"), which is quite small, but contains all the major parts of a real-world compiler. This is:
Parser implemented with FParsec, generating a sequence of text tokens from a given template.
Untyped AST that gets constructed from the parsed token sequence.
Type System and inference: There's a set of rules for assigning types to terms (type system), and an algorithm for solving. The result is the...
Typed AST, which is then used from the...
Code generator that produces resulting types and the code for rendering a template.
Why could that be interesting?
During implementation, there came up some questions, which I found quite interesting converning the relationship between Trulla and a major compiler like F#. For example: The implementation of Trulla's compiler parts seem quite straight forward. But could they stay the way they are when the language grows, when performance issues raise up, when editor tooling and 3rd party services need to be plugged-on, when error handling gets more important, etc.
Session Format
The session could be in that form:
Max. 1 hour (even less) of explaining and showing the Trulla compiler
Discussing / Q&A / Brainstorming how that related to F# compiler (see questions above).
I don't know if that session format could work, or be interesting to some people; I've never done it before.
The text was updated successfully, but these errors were encountered:
New Session: Build Your Own Compiler
Ronald Schlenker, Freelancer, in CEST would like to tackle:
https://github.com/RonaldSchlenker/Trulla
Extra
More of a a backup, since it's not directly related to OSS contribution in general or to the F# compiler.
Description
Every Friday, Amplifying F# and their Champions prove that it's possible to change or enhance a real world compiler and it's tooling, without the need to ever having implemented an own language (+compiler), and without the need for being an expert in that field. It's indeed often possible to get things done by focusing on very particular areas of the compiler, without the need for knowing the interrelationships of all compiler parts and their details - and that's good, because doing so would be quite challenging (and time consuming).
But at some point when working on the F# compiler, questions might come up, which could be hard to answer, like why things are implemented the way they are, in which area could things possibly be located, which things could be influenced when touching something, which alternatives could be thinkable when trying to solve a problem?
Some time ago, I've written a compiler on my own out of a practical need (for an F# text template type provider called "Trulla"), which is quite small, but contains all the major parts of a real-world compiler. This is:
Why could that be interesting?
During implementation, there came up some questions, which I found quite interesting converning the relationship between Trulla and a major compiler like F#. For example: The implementation of Trulla's compiler parts seem quite straight forward. But could they stay the way they are when the language grows, when performance issues raise up, when editor tooling and 3rd party services need to be plugged-on, when error handling gets more important, etc.
Session Format
The session could be in that form:
I don't know if that session format could work, or be interesting to some people; I've never done it before.
The text was updated successfully, but these errors were encountered: